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


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

Hi Andy,<= u>

=C2=A0

> Until the basic show-stoppers are solved, the r= edundant opstate objects are not important.

> Removing the foo-state objects means they are n= ow invisible wrt/ YANG constraints

> (must, when, leafref, min/max, etc).=C2=A0 IMO = this is a show-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.

=C2=A0

Nothing has been removed.=C2=A0 All the config false= nodes are still available, but now they=E2=80=99re no longer separated int= o a top-level /foo-state tree for the sole purpose of being able to report = opstate for system-generated objects.=C2=A0 Likewise, all YANG constraints continue to work, but rather than reference nodes in = /foo-state, they=E2=80=99ll now reference nodes in /foo.=C2=A0=C2=A0 Does t= his make sense?=C2=A0 Do you still have an issue?

=C2=A0

=C2=A0


This does not work. There are no config=3Dfalse nodes= if they are overlaid onto the config=3Dtrue nodes.
There is no w= ay 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 YA= NG says has 0 or 1 instance
(and therefore 0 or 1 value).

=C2=A0

Kent // as a contributor

=C2=A0

=C2=A0


Andy
=C2=A0

--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: 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 18:44:56 -0000 On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. > OK. So the client does the validation. What does the client do if the operational state it got is not valid according to the YANG constraints? /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 12:54:50 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 3E4AD129483; Thu, 12 Jan 2017 12:54:44 -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 78kEG4HcFJLI; Thu, 12 Jan 2017 12:54:41 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E116D129481; Thu, 12 Jan 2017 12:54:41 -0800 (PST) From: Alex Campbell To: Andy Bierman , Juergen Schoenwaelder Thread-Topic: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSaE0J1+3vtKka+km/wzqqYB4OMqEsVSSAgAAOqACABDhbgIAAA9SAgAADg4CAAGDRAIAAHFwAgAAJDoCAAAdCgIAAhzOAgACqYICAAAzRgIAADk0AgAAE0ACAAA7XgIAAA8uAgAAKVICAAA5/AIAAFi8AgAARsYCAALgOgIAAYfIAgAAc7QCAAAcCgIAANWWAgAEQd4CAAEwUAIAAA/MAgAABUgCAABJ4AP//nGXE Date: Thu, 12 Jan 2017 20:54:38 +0000 Message-ID: <1484254478595.50623@Aviatnet.com> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> , <20170112184452.GC21677@elstar.local> In-Reply-To: <20170112184452.GC21677@elstar.local> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 20:54:44 -0000 IMO it should be treated like any other protocol error.=0A= Which means that an ideal client will report an error - but in practice the= y'll end up ignoring the constraint violation because it's easier to not do= validation.=0A= =0A= This problem isn't specific to YANG - what happens if I make a request to a= n HTTP server ("GET / HTTP/1.1") and the server sends back nonsense ("FOOBA= R/-1.3i xyz Didn't feel like it")?=0A= A good client will report that there was an error parsing the response; a b= ad client might call atoi on the second field (recording the status code as= 0) and ignore the other fields.=0A= Is there anything we can do about that? I don't think there is.=0A= =0A= Alex=0A= =0A= ________________________________________=0A= From: netmod on behalf of Juergen Schoenwaelder <= j.schoenwaelder@jacobs-university.de>=0A= Sent: Friday, 13 January 2017 7:44 a.m.=0A= To: Andy Bierman=0A= Cc: Netconf; netmod@ietf.org=0A= Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revi= sed DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits=0A= =0A= On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote:=0A= > On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <=0A= > j.schoenwaelder@jacobs-university.de> wrote:=0A= >=0A= > > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote:=0A= > > >=0A= > > > YANG statements:=0A= > > > - It is not possible to define these statements so they are differ= ent=0A= > > > for config and oper=0A= > > > - must=0A= > > > - when=0A= > > > - unique=0A= > > > - key=0A= > > > - min-elements=0A= > > > - max-elements=0A= > > > - leafref (path)=0A= > > > - if-feature=0A= > > > - deviation=0A= > > > - type (or any sub-statements of type-stmt)=0A= > > > - status=0A= > > > - description=0A= > > > - reference=0A= > >=0A= > > Considering statements that constraint 'values', it is not entirely=0A= > > clear to me what they mean for state nodes. If a server has=0A= > > operational state that violates a must or range or ... constraint in=0A= > > the YANG model, what is the server expected to do?=0A= > >=0A= >=0A= > The client uses the YANG validation to check on what the server is sendin= g.=0A= > The server is buggy if it is sending data that violates YANG constraints.= =0A= > If any of these statements need to be different for config and oper=0A= > then the old style YANG has to be used instead.=0A= >=0A= =0A= OK. So the client does the validation. What does the client do if the=0A= operational state it got is not valid according to the YANG constraints?=0A= =0A= /js=0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Thu Jan 12 13:20: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 D4F0F129508; Thu, 12 Jan 2017 13:20:52 -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 Bj1MNpjqOIgE; Thu, 12 Jan 2017 13:20:47 -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 2E0E81294F9; Thu, 12 Jan 2017 13:20:47 -0800 (PST) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 9B6FE6098C; Thu, 12 Jan 2017 22:20:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484256045; bh=wXdmhO5M/zcD8LIIZyxHWyQmTat7IuyO6TeT8oWrijM=; h=From:Date:To; b=A81xucwZ1FW/9KPv4/JeNbmrUF00lX60T9RfIfWMsJ1N1f603kWs0QTFKqhDWhfzp rM8vUvxMZsfe8Ho4Gr1JkaRI3n3zCrrsh5SKNLhE/7EWu2woe3tCC+NbKEt0XCLBv3 0d4u5nFDQRZFEYfrdiwvmJ3Rc8NtLJSxN/NksTPQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170112184452.GC21677@elstar.local> Date: Thu, 12 Jan 2017 22:20:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> <20170112184452.GC21677@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@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 21:20:53 -0000 > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >>=20 >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: >>>>=20 >>>> 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 >>>=20 >>> 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? >>>=20 >>=20 >> 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. >>=20 >=20 > OK. So the client does the validation. What does the client do if the > operational state it got is not valid according to the YANG = constraints? Don't forget that data models also provide guidelines to server = implementors. It is not without reason to write a test suite that = validates server responses, including state data. 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 >=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 Thu Jan 12 13:28:02 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 CB4A41294F9; Thu, 12 Jan 2017 13:27:59 -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 ZzrFUnHbE1WH; Thu, 12 Jan 2017 13:27:57 -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 E1299129499; Thu, 12 Jan 2017 13:27:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B8B8680E; Thu, 12 Jan 2017 22:27:55 +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 yefyiHB053io; Thu, 12 Jan 2017 22:27:52 +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 22:27:55 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C53320091; Thu, 12 Jan 2017 22:27:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mpiohPqj-q3d; Thu, 12 Jan 2017 22:27:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8C5120090; Thu, 12 Jan 2017 22:27:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5D4153E0B77C; Thu, 12 Jan 2017 22:27:56 +0100 (CET) Date: Thu, 12 Jan 2017 22:27:55 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170112212755.GA22142@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , "netmod@ietf.org" References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) 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 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 21:28:00 -0000 On Thu, Jan 12, 2017 at 10:20:44PM +0100, Ladislav Lhotka wrote: > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder wrote: > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. > >> > > > > OK. So the client does the validation. What does the client do if the > > operational state it got is not valid according to the YANG constraints? > > Don't forget that data models also provide guidelines to server implementors. It is not without reason to write a test suite that validates server responses, including state data. > OK. But what do you expect a regular client 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 13:59: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 79B9E129459; Thu, 12 Jan 2017 13:59:39 -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 zivpO4lEUrq3; Thu, 12 Jan 2017 13:59:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A1124281; Thu, 12 Jan 2017 13:59:38 -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 465CD1AE01AA; Thu, 12 Jan 2017 22:59:37 +0100 (CET) Date: Thu, 12 Jan 2017 22:59:37 +0100 (CET) Message-Id: <20170112.225937.1113385078732083121.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@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: Thu, 12 Jan 2017 21:59:39 -0000 Ladislav Lhotka wrote: > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > wrote: > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. > >> > > > > OK. So the client does the validation. What does the client do if the > > operational state it got is not valid according to the YANG > > constraints? > > Don't forget that data models also provide guidelines to server > implementors. Yes, and that it is all that can be done currently. I don't think any implemention that receives a request today freezes the system in order to get a guaranteed consistent snapshot. Instead, the different subsystems will be queried, sequentially or in parallell, and the end result is shipped to the client. The result may or may not be consistent. /martin From nobody Thu Jan 12 14:04:06 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 68604128824 for ; Thu, 12 Jan 2017 14:04:05 -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 HZTYEowZ13gB for ; Thu, 12 Jan 2017 14:04:03 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 A5AF1120727 for ; Thu, 12 Jan 2017 14:04:02 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r144so42342538wme.1 for ; Thu, 12 Jan 2017 14:04:02 -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 :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=/H3RFV8+Bg122lQshVrhJMke/uVoDmB4IlvYaS70WfY=; b=Pn3shqYZgioKtVYVlV8sIkxSlZUy+QJQ452efdlmNw3KizilNh7e1VUsWj+mJQed62 3/hpFA8adVgmPyNuVGMctbZWr+2lgKuV+HZ5BkxrkDe176tyUUmDsZ9FnaRHxIFm7nj4 wwQoqyCAkY4c0QDVgD6kthr0I9ypajX/JvXSMlCFKhmrTg/9MHN5uSaXNwPJ3iHXAH/1 ONyOQ+2QObvRBL/HtB1GFpjBOYPCjAQ5lfe2RQR5yK4bZzRMWer6Wj5sjnnA2Zpaix7b W2kuO8+/Q+LhtOZWwabWhg6w08PA7wlPUYRaD3+IHASOdE7oYKIjxbGXKWsk86DHBzHJ Solw== 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 :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=/H3RFV8+Bg122lQshVrhJMke/uVoDmB4IlvYaS70WfY=; b=ddLJ4ekEIUX3SV8aNzprU9+FrGGmYMk4MgErvM7+AV+qRjU1oCKjJ4u3xQFoQX29MB 222fJIAJ2HTk5+NHBLcOVhlV4oQK4Yykr/KfzGluwSYf6lVQSsZ/J7lWshFaxaw3O6Li ElTbCwAWzhKPT01OlekM40f9yU1VQwhA6Scc82LDn2OONqpvuvmotPOOesaodKWqXbAG jBM+uiVI/xXZiacy3p3sOxan9B5RKP0o+qv9EOBtJjp4sBPxcbvDYlPna6DT2gOM8SdS n+2byg1JK3m5KCeHPoe445VRKUTOrFrNctTHZFfdghWHeSk7VPpgZsV/5fMu2IB3fzUq ONjw== X-Gm-Message-State: AIkVDXKhiDwe8DfcWTkuct8Q6tLOjORKc4RzI2+qMO1pZR3bQZSlWrZEwRKWbY6H/PbyAg== X-Received: by 10.223.143.45 with SMTP id p42mr10129147wrb.120.1484258640970; Thu, 12 Jan 2017 14:04:00 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B3407F9.dip0.t-ipconnect.de. [91.52.7.249]) by smtp.gmail.com with ESMTPSA id f126sm5775702wme.22.2017.01.12.14.03.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 14:04:00 -0800 (PST) From: "Mehmet Ersue" To: "'Ladislav Lhotka'" , "'Robert Wilton'" Date: Thu, 12 Jan 2017 23:03:59 +0100 Message-ID: <035b01d26d1f$c79e74b0$56db5e10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJtH8bUFvUWvjPpTcCAr7hMHGuTBQ== Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0208.5877FD50.0012,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'NetMod WG' Subject: [netmod] Generic DS concept WAS:RE: [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 22:04:05 -0000 Hi All, I started this thread for a discussion on the Intended Status of the Revised DS Draft. I think the discussion on technical issues of the DS concept can be discussed on one maillist. I call the new thread "Generic DS concept". Cheers, Mehmet -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Wednesday, January 11, 2017 4:37 PM To: Robert Wilton 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 > On 11 Jan 2017, at 16:18, Robert Wilton wrote: > > > > 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. 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. > >> >>> 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. 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 > > 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 >> >> >> >> >> >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jan 12 14:05:16 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 B0ECA1294FD for ; Thu, 12 Jan 2017 14:05:14 -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 xKIJdJmJVBuo for ; Thu, 12 Jan 2017 14:05:10 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 282A912941C for ; Thu, 12 Jan 2017 14:05:10 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id x49so31472780qtc.2 for ; Thu, 12 Jan 2017 14:05: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=GQt0Br9O5s2Hgpsy6ejma+NURrF292MKAMA0GqgCcvU=; b=J5eRustOnKjAzKmw5BK31jFJRKrMPQXjtLCXI+rny24aL7/xsTOKKT9zk8bSz4uHrJ ACB/YdtRkiAtvNJRJr+K9k2nL1KpLBMhc3BYAKhOl5fE8nMersOAu5GfMER6NDq9DsHW VuzarEZkjXUodhRjy8IAVN1phfnmKGWnW5MS51r0dUgd4TbXy9s7pYRyrN8ntX0dwbnw W54qfbF/lzLgaGbfVVJ/8UB/HBWKF1wbEeRBvRu1Qi/LjNmXUSJgCjrfaLwEuSY00beu 6kR9lK2Thvv57+uKWFsOt+S9V37uFc6U2ze/rjOJT6qpQgi1ujRcK/VhYHQSF7UiMLLe Qvgg== 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=GQt0Br9O5s2Hgpsy6ejma+NURrF292MKAMA0GqgCcvU=; b=AIij+Ga9cwTVFF0/tuukpI3VmQihY6meMOx713jmszwgawGcdUKil9owr8NqcI+hKn jcUWXY1aJ5ZjYNxYRJMMa71EC/L4mzf10gEVm7CguxiZKG7jO3r90dnr4FVuMRERMJXj uJR0KFLwTkeRrYvCt2qTbb23vWk4iG/ojvOjMZpsWKfsMYuvW2U6D+VL0+j1x6xjXH/y v7Z2iQPo1o5xrK90Aiv5/BEjqcXecw4swgI6qKp1tG0XAisvMLm/AIAyUdJ83kovkQHu 9jRkr5pSGbSyH5/vzTRtnOUwcb2sBFuYaKv2Vy3zZ3rrPTPGPf7tjd5J9NNEwNVKLfIJ xRfw== X-Gm-Message-State: AIkVDXKHKMuP5re8yjL55oZ6ELtAb3N+O00NWkCCljJIx4T+vRkuc6AkDmITa0JN3clewHwsteGRFJT0cjwqHg== X-Received: by 10.200.57.75 with SMTP id t11mr15774796qtb.274.1484258709155; Thu, 12 Jan 2017 14:05:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 14:05:07 -0800 (PST) In-Reply-To: <20170112.225937.1113385078732083121.mbj@tail-f.com> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> From: Andy Bierman Date: Thu, 12 Jan 2017 14:05:07 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113ef3581d63a90545ece92d 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 22:05:14 -0000 --001a113ef3581d63a90545ece92d Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > > wrote: > > > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. > > >> > > > > > > OK. So the client does the validation. What does the client do if the > > > operational state it got is not valid according to the YANG > > > constraints? > > > > Don't forget that data models also provide guidelines to server > > implementors. > > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. > > > So this thread is questioning why YANG allows constraints on config=false data nodes. >From the generic toolbuilder POV, it allows the YANG engine to report issues to the operator without custom programming for each little issue. Who knows why the foo-table requires 3 entries to be valid min-elements 3). The tool can report to the operator "foo-table does not have enough entries" and let the operator decide what to do about it. /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113ef3581d63a90545ece92d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > <j.sch= oenwaelder@jacobs-university.de> wrote:
> >
> > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote:
> >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > >> j.sch= oenwaelder@jacobs-university.de> wrote:
> >>
> >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wr= ote:
> >>>>
> >>>> YANG statements:
> >>>>=C2=A0 =C2=A0- It is not possible to define these stat= ements 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 (path)
> >>>>=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-statements of = type-stmt)
> >>>>=C2=A0 =C2=A0 =C2=A0 - status
> >>>>=C2=A0 =C2=A0 =C2=A0 - description
> >>>>=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 h= as
> >>> operational state that violates a must or range or ... co= nstraint in
> >>> the YANG model, what is the server expected to do?
> >>>
> >>
> >> The client uses the YANG validation to check on what the serv= er is
> >> sending.
> >> The server is buggy if it is sending data that violates YANG<= br> > >> constraints.
> >> If any of these statements need to be different for config an= d oper
> >> then the old style YANG has to be used instead.
> >>
> >
> > OK. So the client does the validation. What does the client do if= the
> > operational state it got is not valid according to the YANG
> > constraints?
>
> Don't forget that data models also provide guidelines to server > implementors.

Yes, and that it is all that can be done currently.=C2=A0 I don't think= any
implemention that receives a <get> request today freezes the system i= n
order to get a guaranteed consistent snapshot.=C2=A0 Instead, the different=
subsystems will be queried, sequentially or in parallell, and the end
result is shipped to the client.=C2=A0 The result may or may not be
consistent.



So this thread is questioning why YANG= allows constraints on config=3Dfalse data nodes.
From the generi= c toolbuilder POV, it allows the YANG engine to report issues to
= the operator without custom programming for each little issue.=C2=A0 Who kn= ows why the
foo-table requires 3 entries to be valid min-elements= 3).
The tool can report to the operator "foo-table does not= have enough entries"
and let the operator decide what to do= about it.


=C2=A0
/martin


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

--001a113ef3581d63a90545ece92d-- From nobody Thu Jan 12 18:14:33 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 1557C1297DE for ; Thu, 12 Jan 2017 18:14:32 -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 D2lCEVEh_83y for ; Thu, 12 Jan 2017 18:14:30 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561701296FD for ; Thu, 12 Jan 2017 18:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1995; q=dns/txt; s=iport; t=1484273670; x=1485483270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Fxb/8uQfvs0hZrxPDIrHhCrt/q9vZxNM1N+7arZHTEM=; b=OIkf/bvcoMnwl8hBvJmMIMw/KOqSOTMVEmyt6mZ5nxfDV77Bam9RXW6z SgzXtWm29soGIhkH4fxNjUri/D0fyKzBMvEgw4vF5xVC6pt9pRwG2GtCf jRCIiSQAcoMZFZaMPImCYHaIXe8IkcQSvIuV3MFKuO9FK2XSL6CXYtvst Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQC8N3hY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR9fgQkHjVGSFIgDjSiCDR8LhS5KAoIIPxQBAgEBAQE?= =?us-ascii?q?BAQFjKIRpAQEBAwEBAWwLBQsCAQgOCi4hBgslAgQBDQWIZQMQCA6vFg+DRYc2D?= =?us-ascii?q?YJJAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIRwiCV4JOgWIWhWQFj12LFzgBjVW?= =?us-ascii?q?EAZBtihCELYQmAR84gUQVOhABghOEC3OHWYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,220,1477958400"; d="scan'208";a="372122238" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2017 02:14:29 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0D2ETsn030284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2017 02:14:29 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 12 Jan 2017 21:14:28 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1210.000; Thu, 12 Jan 2017 21:14:28 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani , Balazs Lengyel Thread-Topic: [netmod] Tacacs and YANG Thread-Index: AQHSanJWwJBh7dqEC06RBRJ/GBWILqEw6egAgAUajgA= Date: Fri, 13 Jan 2017 02:14:28 +0000 Message-ID: <7CE7941D-FC28-4504-B639-615942765662@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.106.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" , =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= 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: Fri, 13 Jan 2017 02:14:32 -0000 > On 9 Jan 2017, at 20:18, Mahesh Jethanandani wr= ote: >=20 >=20 >> 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 pl= ans to develop a TACACS+ model for YANG? >>=20 >> How widely is TACACS+ used for remote authorization/accounting? einarnn> Quite widely. It is more capable than RADIUS for this task, and mo= st used where traceability and auditing are key requirements. >> As an outsider I would guess that remote authorization could really slow= down processing e.g. a big CLI script. einarnn> Yes. When it was humans typing at routers and switches it was not = such a big deal, but with the rise of screen scraping as a substitute for t= he now-more-common model based APIs, I have seen instances of customer brin= g both network devices and TACAS servers to their knees when command author= isation is enabled. Cheers, Einar > Of the customers that I am interacting with, both use TACACS+ for authori= zation and accounting. My take is that there would a requirement for NETCON= F to be able to interact with the server. >=20 > One way to deal with authorization is for the server to download the auth= orization rules and do local authorization instead of sending all the reque= sts to the server, which as you point out would otherwise slow authorizatio= n down.=20 >=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, w= hat is communication channel between them? >=20 > Thanks. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 13 00:09: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 DCEE1129B0E; Fri, 13 Jan 2017 00:09: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 cHeqx_MnMjnK; Fri, 13 Jan 2017 00:09:20 -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 A10C8129B0D; Fri, 13 Jan 2017 00:09:20 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id 41A0961153; Fri, 13 Jan 2017 09:09:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484294958; bh=mtomv78Lf6a7KQgSSz7sOCTJrhWmornty7FDmLNi6CE=; h=From:Date:To; b=yTT7iR7BPLXx+cSfMSPTbIOjDoHXAK6K3qs+8P8+G6+5hM0OXCBojlR5SMSqsdbFB 4qLmHgx+OF4u1xH83wGgOjzH8Q2SXDsqsz3hm64vv7bPfwc+bI/9gyL+HPACdevulX 35TyE3iP2EQY5uWiJj0520cRg8IVfiSBinfBUI1Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170112212755.GA22142@elstar.local> Date: Fri, 13 Jan 2017 09:09:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B70D0DB-AAAC-4C3A-A734-C7EBA7D12830@nic.cz> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112212755.GA22142@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@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: Fri, 13 Jan 2017 08:09:23 -0000 > On 12 Jan 2017, at 22:27, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 12, 2017 at 10:20:44PM +0100, Ladislav Lhotka wrote: >>=20 >>> On 12 Jan 2017, at 19:44, Juergen Schoenwaelder = wrote: >>>=20 >>> On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: >>>> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>=20 >>>>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: >>>>>>=20 >>>>>> 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 >>>>>=20 >>>>> 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? >>>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> OK. So the client does the validation. What does the client do if = the >>> operational state it got is not valid according to the YANG = constraints? >>=20 >> Don't forget that data models also provide guidelines to server = implementors. It is not without reason to write a test suite that = validates server responses, including state data. >>=20 >=20 > OK. But what do you expect a regular client to do? >=20 Complain to the vendor that their server is broken. Lada > /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 Fri Jan 13 00:22: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 4F9ED129B1E; Fri, 13 Jan 2017 00:22:16 -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 n0Ae7e6Et0Kt; Fri, 13 Jan 2017 00:22:14 -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 86C67129B08; Fri, 13 Jan 2017 00:22:14 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id 3809C6137F; Fri, 13 Jan 2017 09:22:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484295733; bh=QQxWAGeD9lE1E+sqAEf13B/Lm7zVuc7MKZdASKlGg8Q=; h=From:Date:To; b=vZKOCOzGGSSMFAX71sRjieD6UtczKswIfZRKZXVpB475fKwDykYLk+1DmI7WNCiH1 rhfHl0VB3hhIxoF5OV2h4c5UelpxJWXeEs/VKibFTP85dq0yoDLx6I6Ca4ncH2Y5t6 hZ4GmbPeyqVBVcTzuJkXeSWXZs4AHVEhxZyyUl3s= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170112.225937.1113385078732083121.mbj@tail-f.com> Date: Fri, 13 Jan 2017 09:22:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A8B650F-E224-42FC-8987-FBF15CA4D614@nic.cz> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.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: Fri, 13 Jan 2017 08:22:16 -0000 > On 12 Jan 2017, at 22:59, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 12 Jan 2017, at 19:44, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: >>>> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>=20 >>>>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: >>>>>>=20 >>>>>> 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 >>>>>=20 >>>>> 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? >>>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> OK. So the client does the validation. What does the client do if = the >>> operational state it got is not valid according to the YANG >>> constraints? >>=20 >> Don't forget that data models also provide guidelines to server >> implementors. >=20 > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different Which doesn't mean that inconsistent (format of) state data is = acceptable. My colleague develops a BGP looking glass, and it is really = a terrible work because he has to do a lot of screen-scraping. Each time = a vendor changes the data format, he has to update his software. I keep = telling him that our nice protocols would save him from this drudgery. Lada > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Jan 13 00:42: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 2E725129B3E; Fri, 13 Jan 2017 00:42:47 -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 GqOsw47QHYmr; Fri, 13 Jan 2017 00:42:44 -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 0AB0D129B36; Fri, 13 Jan 2017 00:42:43 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id A5372611C7; Fri, 13 Jan 2017 09:42:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484296961; bh=kxEC4UbwM+FpA/QBjX37cLj6kXP1vVaRUlbk6KvObdI=; h=From:Date:To; b=hT9cIyO3qNSAmAVYy4vVkaKYxhI7NF+BxMugd6CSVRSDpCV/5WLmqrzsu90bwq9NZ e7jIP5NgOO/fonYbURB7o0HmZJxuiXqdG40a77VHrrvQ49Z6ouPScecZNpWg0WtJgy qPAXcbUnCH3L3a9o2cOFAdhOp4H58AF5+nJ+vGW0= 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: Fri, 13 Jan 2017 09:42:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <971145C2-ACDC-4BB0-B041-0BE31173C1A4@nic.cz> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.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: Fri, 13 Jan 2017 08:42:47 -0000 > On 12 Jan 2017, at 23:05, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > > wrote: > > > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. > > >> > > > > > > OK. So the client does the validation. What does the client do if = the > > > operational state it got is not valid according to the YANG > > > constraints? > > > > Don't forget that data models also provide guidelines to server > > implementors. >=20 > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. >=20 >=20 >=20 > So this thread is questioning why YANG allows constraints on = config=3Dfalse data nodes. Partly it is a fault of YANG spec because RFC 7950 only says in sec. 8.1 = that The running configuration datastore MUST always be valid. This is exactly what I would like to remove. *Any* data tree for which = we have a corresponding YANG data model can be validated, and it is IMO = up to a particular management application (with a certain datastore = model) to decide what needs to be validated and what not. A particular workflow, datastore model and validation procedure can also = be standardized, but it should be done outside the YANG spec. Lada > =46rom the generic toolbuilder POV, it allows the YANG engine to = report issues to > the operator without custom programming for each little issue. Who = knows why the > foo-table requires 3 entries to be valid min-elements 3). > The tool can report to the operator "foo-table does not have enough = entries" > and let the operator decide what to do about it. >=20 >=20 > =20 > /martin >=20 >=20 > Andy > =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 Fri Jan 13 00:51: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 264C41294A0; Fri, 13 Jan 2017 00:51: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 AYE-eLZVhFb5; Fri, 13 Jan 2017 00:51:40 -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 ACB3E129489; Fri, 13 Jan 2017 00:51:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 17C1C8D0; Fri, 13 Jan 2017 09:51:38 +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 vZdhe2XMQRl9; Fri, 13 Jan 2017 09:51:34 +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, 13 Jan 2017 09:51:37 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AABAB20091; Fri, 13 Jan 2017 09:51:37 +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 q2DNpTtc1SlY; Fri, 13 Jan 2017 09:51:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2178A20090; Fri, 13 Jan 2017 09:51:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B17EE3E0C040; Fri, 13 Jan 2017 09:51:38 +0100 (CET) Date: Fri, 13 Jan 2017 09:51:38 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170113085137.GA23063@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.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: Fri, 13 Jan 2017 08:51:45 -0000 On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bierman wrote: > > So this thread is questioning why YANG allows constraints on config=false > data nodes. > The point I am trying to make is that for configuration data, we have a clear model what validation means and when it is applied. The basic idea is that the running configuration of a system is always valid and configuration changes will never leave the running configuration in an invalid state, i.e., configuration change requests are rejected if they would leave to invalid configuration state. For operational state data, it is not entirely clear where and when validation will occur or if it will occur at all. In fact, if a system is in a weird state, it might actually be useful for certain purposes to expose the weird state. And, as Martin pointed out, inconsistencies may also result from the technical difficulties to take a consistent snapshort of a system with several concurrent subsystems. For these reasons, the assumption that a server always returns valid operational state data is likely not true. > From the generic toolbuilder POV, it allows the YANG engine to > report issues to the operator without custom programming for each > little issue. Who knows why the foo-table requires 3 entries to be > valid min-elements 3). The tool can report to the operator > "foo-table does not have enough entries" and let the operator decide > what to do about it. Yes, it will be up to the client's functionality and its implemention specifics to deal with the question whether it is useful to validate operational state data or what to do if the received operational state data is invalid. While servers are expected to be strict about the validity of configuration data, I think clients need to be lenient about the validity of operational state data. /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 13 01:26: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 9C5A0129AB1; Fri, 13 Jan 2017 01:26: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 Q2vw04hLJQ50; Fri, 13 Jan 2017 01:26: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 B9D4C12944F; Fri, 13 Jan 2017 01:26:05 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id 355CF60FE4; Fri, 13 Jan 2017 10:26:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484299563; bh=QVqgqN9w+B1xUKiok5v8I2jrw9Oun6N4aPnwFc+RdrE=; h=From:Date:To; b=Ujob1znQIFJXWs8fXRxIsZiMOAtLPAMvKp4vb7G7zS2cufb7aXV2b8aXB00uMM9D6 2u99QlhwSthKuCQEfLTf0UhNe/7tBDI9Cq9OOULQb2nMmNY/QDiQBFYHzw1cbNA0ar PgIadc23GQ5NcWbELBoydTYewR25jhzhIFoYd0vw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170113085137.GA23063@elstar.local> Date: Fri, 13 Jan 2017 10:26:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> <20170113085137.GA23063@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@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: Fri, 13 Jan 2017 09:26:08 -0000 > On 13 Jan 2017, at 09:51, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bierman wrote: >>=20 >> So this thread is questioning why YANG allows constraints on = config=3Dfalse >> data nodes. >>=20 >=20 > The point I am trying to make is that for configuration data, we have > a clear model what validation means and when it is applied. The basic > idea is that the running configuration of a system is always valid and > configuration changes will never leave the running configuration in an > invalid state, i.e., configuration change requests are rejected if > they would leave to invalid configuration state. >=20 > For operational state data, it is not entirely clear where and when > validation will occur or if it will occur at all. In fact, if a system > is in a weird state, it might actually be useful for certain purposes > to expose the weird state. And, as Martin pointed out, inconsistencies > may also result from the technical difficulties to take a consistent > snapshort of a system with several concurrent subsystems. For these These are valid reasons and could IMO be lived with, but I think we have = to require "best effort" from the server. If we drop validity of state = data altogether, their invalidity will be commonplace, and (I suspect) = caused mainly by laziness of server implementors. That said, I would be in favour of decoupling data models of = configuration and state data. If a device produces native state data in = a format that's difficult to translate to a standard form, vendors could = be allowed to use a proprietary model for state data. It is IMO still = far better than declaring compliance to RFC XXXX on paper and then = sending something else. > reasons, the assumption that a server always returns valid operational > state data is likely not true. >=20 >> =46rom the generic toolbuilder POV, it allows the YANG engine to >> report issues to the operator without custom programming for each >> little issue. Who knows why the foo-table requires 3 entries to be >> valid min-elements 3). The tool can report to the operator >> "foo-table does not have enough entries" and let the operator decide >> what to do about it. >=20 > Yes, it will be up to the client's functionality and its implemention > specifics to deal with the question whether it is useful to validate > operational state data or what to do if the received operational state > data is invalid. >=20 > While servers are expected to be strict about the validity of > configuration data, I think clients need to be lenient about the > validity of operational state data. It is all about the Postel Principle: the server should be strict, and = the client may be lenient. It also depends on the character of the state = data and specific aspect of validity (broken leafref is not the same as = missing mandatory leaf). 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 >=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 Fri Jan 13 08:21:33 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 1161F1296B4; Fri, 13 Jan 2017 08:21: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_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 7W2qrCHs5MXJ; Fri, 13 Jan 2017 08:21:26 -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 C525012973A; Fri, 13 Jan 2017 08:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15533; q=dns/txt; s=iport; t=1484324486; x=1485534086; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=yJMr1wOOC5LU9Il7wl+a8/cdihZpntjl8qaHIBr0wHM=; b=ezYDK+vjK0j0XoCwF/fVREpK6qP+JBp+/5iQ3EQyOJN8biuGhZHbX2NR 6cPHBQCX2h+9R5+tn457GlQx05lfUo9D7stcDsvYrXj1QV0We36qkDtzB qVJ5MJtR/sGnk64W4SH3oOkYLXf5M2smYKZnKy6/V6xs0LPFEP6JvMifO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAQCV/XhY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAX4qX41YcpEFH49/hSuCDR8BCoUuSgKCUhQBAgEBAQE?= =?us-ascii?q?BAQFjKIRpAQEBBAEBbBsLEAgjBAcnHxEGAQwGAgEBF4hoDrMXK4lIAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWGRYICCIJXhDCFegWbMolxh2gCgXWIOCOGG4pqh3s?= =?us-ascii?q?fOIEVEggVFTqDfWyBRz41hisrghABAQE?= X-IronPort-AV: E=Sophos;i="5.33,222,1477958400"; d="scan'208,217";a="649777880" 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; 13 Jan 2017 16:21:21 +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 v0DGLK7r024357; Fri, 13 Jan 2017 16:21:21 GMT To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> From: Robert Wilton Message-ID: <95332531-0f4f-2070-9ced-79b6ed1a45b7@cisco.com> Date: Fri, 13 Jan 2017 16:21:20 +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="------------1C89EEE76C648913D286EDA2" 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: Fri, 13 Jan 2017 16:21:29 -0000 This is a multi-part message in MIME format. --------------1C89EEE76C648913D286EDA2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit [keeping netmod, bcc netconf] On 12/01/2017 22:05, Andy Bierman wrote: > > > On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund > wrote: > > Ladislav Lhotka > wrote: > > > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > > > wrote: > > > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. > > >> > > > > > > OK. So the client does the validation. What does the client do > if the > > > operational state it got is not valid according to the YANG > > > constraints? > > > > Don't forget that data models also provide guidelines to server > > implementors. > > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. > > > > So this thread is questioning why YANG allows constraints on > config=false data nodes. > From the generic toolbuilder POV, it allows the YANG engine to report > issues to > the operator without custom programming for each little issue. Who > knows why the > foo-table requires 3 entries to be valid min-elements 3). > The tool can report to the operator "foo-table does not have enough > entries" > and let the operator decide what to do about it. The constraint checking that you describe sounds more like a "should" statement than a "must" statement. I can't see that a server would want to validate must constraints on config false nodes when it is the source of that data, for several reasons: - it is unclear what, if anything, it could do if one of the constraints fails. - it wouldn't want the extra validation processing overhead. - there would be an assumption that the data generated should conform to the model anyway. Further, a client cannot reject a pushed notification or GET response from a server even if it doesn't conform with the constraints. I agree that the checking that you describe above could be useful to flag problems, although I'm not sure how easily an automated client would be able to deal with them anyway. One of the strong stated desired from the OpenConfig operators is that a device should accurately report what is is actually doing. The question I have is what should a device do if it wants to return a value outside of the allowable range. E.g. consider a schema that defines the maximum allowed value for leaf foo as 2, but due to some unexpected internal error, when the value is read from hardware it reports that the value is 3 instead. Another case would be if the server wanted to return a value outside the specified range for a given type. In these cases, depending on the encoding used, it may not be possible to return a value at all. If this is a GET request then the server can return a error for the particular leaf path. Does an equivalent solution for notifications also exist? Rob > > > /martin > > > Andy > > _______________________________________________ > 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 --------------1C89EEE76C648913D286EDA2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

[keeping netmod, bcc netconf]


On 12/01/2017 22:05, Andy Bierman wrote:


On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > <j.schoenwaelder@jacobs-university.de> wrote:
> >
> > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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.
> >>
> >
> > OK. So the client does the validation. What does the client do if the
> > operational state it got is not valid according to the YANG
> > constraints?
>
> Don't forget that data models also provide guidelines to server
> implementors.

Yes, and that it is all that can be done currently. I don't think any
implemention that receives a <get> request today freezes the system in
order to get a guaranteed consistent snapshot. Instead, the different
subsystems will be queried, sequentially or in parallell, and the end
result is shipped to the client. The result may or may not be
consistent.



So this thread is questioning why YANG allows constraints on config=false data nodes.
From the generic toolbuilder POV, it allows the YANG engine to report issues to
the operator without custom programming for each little issue. Who knows why the
foo-table requires 3 entries to be valid min-elements 3).
The tool can report to the operator "foo-table does not have enough entries"
and let the operator decide what to do about it.

The constraint checking that you describe sounds more like a "should" statement than a "must" statement.

I can't see that a server would want to validate must constraints on config false nodes when it is the source of that data, for several reasons:
- it is unclear what, if anything, it could do if one of the constraints fails.
- it wouldn't want the extra validation processing overhead.
- there would be an assumption that the data generated should conform to the model anyway.

Further, a client cannot reject a pushed notification or GET response from a server even if it doesn't conform with the constraints. I agree that the checking that you describe above could be useful to flag problems, although I'm not sure how easily an automated client would be able to deal with them anyway.

One of the strong stated desired from the OpenConfig operators is that a device should accurately report what is is actually doing. The question I have is what should a device do if it wants to return a value outside of the allowable range. E.g. consider a schema that defines the maximum allowed value for leaf foo as 2, but due to some unexpected internal error, when the value is read from hardware it reports that the value is 3 instead. Another case would be if the server wanted to return a value outside the specified range for a given type.

In these cases, depending on the encoding used, it may not be possible to return a value at all. If this is a GET request then the server can return a error for the particular leaf path. Does an equivalent solution for notifications also exist?

Rob




/martin


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

--------------1C89EEE76C648913D286EDA2-- From nobody Fri Jan 13 08:50: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 D0070129C7C for ; Fri, 13 Jan 2017 08:50:22 -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 FlDkXno8RWME for ; Fri, 13 Jan 2017 08:50:20 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C812B129C79 for ; Fri, 13 Jan 2017 08:50:19 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so52393797qtc.2 for ; Fri, 13 Jan 2017 08:50: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; bh=x9dOn4ZvYE/hKe+I57+XWMKEhPveTjb5AQvccmZBvXo=; b=VSjdgIr8bF3hQD6vI1f0L3XbazgyNJlM51hKf3hg1VWJHcbegHD3s7zc2dbP+Z5xb8 gVKg8/65ciW9LgWzGdUvMfnmYyCZ52eCTgcN405GFaFvbPCFLzjPGkDXl4a8xmdJAljs +olu+MLevgklA5eIFPvlKTKf4Y4wYhSLEeqgDrrh0gmRG3EQQXtvD/yOhzgEmbtYYg90 oMF2yo4ZU7c3PMRVHSK+o+JCQKknj9Tg+uMCONsin75gCTxpaUfbkLc7Z8SxcYCdv8Cp Gbz253U4s629JHHff0/F1iRKDlabCWppYW1affYSl8oVjQcUyHXBbQHtw6KBAEbsVViD yJ4Q== 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=x9dOn4ZvYE/hKe+I57+XWMKEhPveTjb5AQvccmZBvXo=; b=ijuiPP7AmRGBkxYGJSalflGyClvnrX+YHsxbzocIFKcmm2f0EJ4lAUx7JXcH3RNmXS /bSFRY+Kp+jQDkRDgzwnmmQ3zbhIdb3VUVPvIhEqa+9SfvfiphPUouKPwgm7qXk5J4AM IeU9yJBhTucMPKodzVme3/66WZKwz76x1/7/xXUUvXzCo7yfaO0MyA5Hn47oG4cZoi7w qIyvH8oWHcqb79pDP2P84/vNEJUBSrJGb/VkczFuN5l5frBLGRWMm4d3z25WqX/WUAlf Pup4CBRUynHGHGj3AuieILASEbiJtvUVkw4KbhzUsoxphy2ySpDsYYqAc4Nq6hefePUj TieA== X-Gm-Message-State: AIkVDXIpxiiaXqB0LVFKDsTk9CiAfVNvpa/Re2r0n/O33n/Z/Jv9gZCOd1SRaNizFmmOIHl5kX7J12rAmgslxQ== X-Received: by 10.237.59.203 with SMTP id s11mr19666692qte.46.1484326218952; Fri, 13 Jan 2017 08:50:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Fri, 13 Jan 2017 08:50:17 -0800 (PST) In-Reply-To: <20170113085137.GA23063@elstar.local> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> <20170113085137.GA23063@elstar.local> From: Andy Bierman Date: Fri, 13 Jan 2017 08:50:17 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf Content-Type: multipart/alternative; boundary=94eb2c1907ac03145b0545fca1e2 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: Fri, 13 Jan 2017 16:50:23 -0000 --94eb2c1907ac03145b0545fca1e2 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 12:51 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bierman wrote: > > > > So this thread is questioning why YANG allows constraints on config=false > > data nodes. > > > > The point I am trying to make is that for configuration data, we have > a clear model what validation means and when it is applied. The basic > idea is that the running configuration of a system is always valid and > configuration changes will never leave the running configuration in an > invalid state, i.e., configuration change requests are rejected if > they would leave to invalid configuration state. > > For operational state data, it is not entirely clear where and when > validation will occur or if it will occur at all. In fact, if a system > is in a weird state, it might actually be useful for certain purposes > to expose the weird state. And, as Martin pointed out, inconsistencies > may also result from the technical difficulties to take a consistent > snapshort of a system with several concurrent subsystems. For these > reasons, the assumption that a server always returns valid operational > state data is likely not true. > > > From the generic toolbuilder POV, it allows the YANG engine to > > report issues to the operator without custom programming for each > > little issue. Who knows why the foo-table requires 3 entries to be > > valid min-elements 3). The tool can report to the operator > > "foo-table does not have enough entries" and let the operator decide > > what to do about it. > > Yes, it will be up to the client's functionality and its implemention > specifics to deal with the question whether it is useful to validate > operational state data or what to do if the received operational state > data is invalid. > > While servers are expected to be strict about the validity of > configuration data, I think clients need to be lenient about the > validity of operational state data. > > Actually, a client that is not restricted by NACM can use the YANG validation just fine. There are opstate tables that churn but that is the exception. Also note that the rpc/input and action/input constraints are validated by the server, and MUST be implemented. The XPath in these contexts are allowed to reference state data (starting in YANG 1.1) > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c1907ac03145b0545fca1e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 12:51 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bier= man wrote:
>
> So this thread is questioning why YANG allows constraints on config=3D= false
> data nodes.
>

The point I am trying to make is that for configuration data, we have
a clear model what validation means and when it is applied. The basic
idea is that the running configuration of a system is always valid and
configuration changes will never leave the running configuration in an
invalid state, i.e., configuration change requests are rejected if
they would leave to invalid configuration state.

For operational state data, it is not entirely clear where and when
validation will occur or if it will occur at all. In fact, if a system
is in a weird state, it might actually be useful for certain purposes
to expose the weird state. And, as Martin pointed out, inconsistencies
may also result from the technical difficulties to take a consistent
snapshort of a system with several concurrent subsystems. For these
reasons, the assumption that a server always returns valid operational
state data is likely not true.

> From the generic toolbuilder POV, it allows the YANG engine to
> report issues to the operator without custom programming for each
> little issue. Who knows why the foo-table requires 3 entries to be
> valid min-elements 3). The tool can report to the operator
> "foo-table does not have enough entries" and let the operato= r decide
> what to do about it.

Yes, it will be up to the client's functionality and its implemention specifics to deal with the question whether it is useful to validate
operational state data or what to do if the received operational state
data is invalid.

While servers are expected to be strict about the validity of
configuration data, I think clients need to be lenient about the
validity of operational state data.



Actually, a client that is not restri= cted by NACM can use the YANG validation just fine.
There are ops= tate tables that churn but that is the exception.

= Also note that the rpc/input and action/input constraints are validated
by the server, and MUST be implemented.=C2=A0 The XPath in these con= texts
are allowed to reference state data (starting in YANG 1.1)<= /div>


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

--94eb2c1907ac03145b0545fca1e2-- From nobody Fri Jan 13 10:17: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 560E2129D1D for ; Fri, 13 Jan 2017 10:17:44 -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 iO-QJOfQTG7P for ; Fri, 13 Jan 2017 10:17:41 -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 2E3A4129533 for ; Fri, 13 Jan 2017 10:17:41 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u25so62358611qki.2 for ; Fri, 13 Jan 2017 10:17:41 -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=MiDIENcGdbcbw8H5mPMs0YjO/nO5JnA/kgG1ZcRdNPA=; b=ln/wEsA7Cu9SG+DVdntb352TquYnjl9DUHLLTtYF2EL8yafwaioV8l0EGteE9hujo3 8dDcKwUKq/JhObqqfX0fNNHzQTfgEDjx8iJGmJ8agLOPEEHPE/+pkMrlf07SWpCFjTYL hRvBmJIjVu43YefAmaI4FpalGUkC1BfOAm2lJBVWh5Dp7sb/7ricJos+BBmUaqM/5Xld WRFVNOfEhY1g2HZw7YX9P+asv1PshJiAn2hZyC+l1BIAqXKkn6u1tiYKkEZj2or8vPSY a794WPlUX5XTTVlc72uzjlGIF71gdPZlCthB7UXjEfDHYHsOtEA/F3zO6+CFncbwFMsL YyXw== 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=MiDIENcGdbcbw8H5mPMs0YjO/nO5JnA/kgG1ZcRdNPA=; b=O7ZaG8I+ACKU5JwQ1QvRmxBGNOtKG+unG+31PK4GaFypDmwwFIcICf9ifo4arAQt3u 6TutUU5+yOlyXDcUuIUtxUpdBrd3mZU9FJGz8uBZBLsqDdfx8yvaREL09VSI5YTlQaQU R/FB1oNHZojVT36Hem+r3lGOC3dlhDdCeCGJHGOCtaFG7n0hFAn9AHnjwNjcI0/TbMgE 9wQEdogC7euRxy8JYyeK1pWgla1G7RoLleQQOZKc5rE3T28CzUwmoKqNtlJ7CSmtJx8b cGtNBVk5RCL6xe4QAAZPMwUjjB7OT32I7bhTqv5KnBYdq3J+AeNuQ249agFH02t/arEb LaRA== X-Gm-Message-State: AIkVDXJXRgVqcGm+kulBDjeoqdW9K/k5P47EKMwnd9K54DUBQJHimaXIbNNOQduh7sDODjwTMJmt/HMGYGBz2g== X-Received: by 10.55.135.197 with SMTP id j188mr19608532qkd.71.1484331460059; Fri, 13 Jan 2017 10:17:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Fri, 13 Jan 2017 10:17:38 -0800 (PST) In-Reply-To: <95332531-0f4f-2070-9ced-79b6ed1a45b7@cisco.com> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> <95332531-0f4f-2070-9ced-79b6ed1a45b7@cisco.com> From: Andy Bierman Date: Fri, 13 Jan 2017 10:17:38 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=94eb2c0777e668011f0545fdd99b Archived-At: Cc: "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: Fri, 13 Jan 2017 18:17:44 -0000 --94eb2c0777e668011f0545fdd99b Content-Type: text/plain; charset=UTF-8 Hi, IMO the YANG data model constraints are too domain-specific to generalize. If the designer is adding a constraint (must, when. min-elements -- makes no difference) then if must matter to that specific data model. It is not a SHOULD, but a MUST. Otherwise YANG has no value to data model designers. Seems to me that your proposal combines 'applied' and 'operational' incorrectly. The only type of object that should be de-duplicated is the clone of config-foo for the sake of providing the oper-foo value (which could be supplied by the get-oper RPC instead). It is the 'applied' datastore that is not subject to validation, not the operational datastore. Combining trees doesn't work if the 'normal' config=false nodes are placed under a list or P-container. There is no way to instantiate these nodes unless the ancestor config nodes also exist. The openconfig design pattern is getting phased out. This never involved 2 trees anyway grouping config-X { .... } uses config-X { augment . { container oper { config false; uses config-X; } } } I don't see how combining the ancestor top-level node with another one makes any difference to the solution. Andy On Fri, Jan 13, 2017 at 8:21 AM, Robert Wilton wrote: > [keeping netmod, bcc netconf] > > On 12/01/2017 22:05, Andy Bierman wrote: > > > > On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >> > >> > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder >> > > wrote: >> > > >> > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. >> > >> >> > > >> > > OK. So the client does the validation. What does the client do if the >> > > operational state it got is not valid according to the YANG >> > > constraints? >> > >> > Don't forget that data models also provide guidelines to server >> > implementors. >> >> Yes, and that it is all that can be done currently. I don't think any >> implemention that receives a request today freezes the system in >> order to get a guaranteed consistent snapshot. Instead, the different >> subsystems will be queried, sequentially or in parallell, and the end >> result is shipped to the client. The result may or may not be >> consistent. >> >> >> > So this thread is questioning why YANG allows constraints on config=false > data nodes. > From the generic toolbuilder POV, it allows the YANG engine to report > issues to > the operator without custom programming for each little issue. Who knows > why the > foo-table requires 3 entries to be valid min-elements 3). > The tool can report to the operator "foo-table does not have enough > entries" > and let the operator decide what to do about it. > > > The constraint checking that you describe sounds more like a "should" > statement than a "must" statement. > > I can't see that a server would want to validate must constraints on > config false nodes when it is the source of that data, for several reasons: > - it is unclear what, if anything, it could do if one of the constraints > fails. > - it wouldn't want the extra validation processing overhead. > - there would be an assumption that the data generated should conform to > the model anyway. > > Further, a client cannot reject a pushed notification or GET response from > a server even if it doesn't conform with the constraints. I agree that the > checking that you describe above could be useful to flag problems, although > I'm not sure how easily an automated client would be able to deal with them > anyway. > > One of the strong stated desired from the OpenConfig operators is that a > device should accurately report what is is actually doing. The question I > have is what should a device do if it wants to return a value outside of > the allowable range. E.g. consider a schema that defines the maximum > allowed value for leaf foo as 2, but due to some unexpected internal error, > when the value is read from hardware it reports that the value is 3 > instead. Another case would be if the server wanted to return a value > outside the specified range for a given type. > > In these cases, depending on the encoding used, it may not be possible to > return a value at all. If this is a GET request then the server can return > a error for the particular leaf path. Does an equivalent solution for > notifications also exist? > > Rob > > > > > > > /martin >> >> > Andy > > >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > --94eb2c0777e668011f0545fdd99b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


IMO the YANG data mo= del constraints are too domain-specific to generalize.
If the des= igner is adding a constraint (must, when. min-elements -- makes no differen= ce)
then if must matter to that specific data model.=C2=A0 It is = not a SHOULD, but a MUST.
Otherwise YANG has no value to data mod= el designers.

Seems to me that your proposal combi= nes 'applied' and 'operational' incorrectly.

=
The only type of object that should be de-duplicated is the clon= e of config-foo
for the sake of providing the oper-foo value (whi= ch could be supplied by
the get-oper RPC instead).

=
It is the 'applied' datastore that is not subject to val= idation, not the operational datastore.

Combining = trees doesn't work if the 'normal' config=3Dfalse nodes are pla= ced under
a list or P-container. There is no way to instantiate t= hese nodes unless the ancestor
config nodes also exist.

The openconfig design pattern is getting phased out.
<= div>This never involved 2 trees anyway

=C2=A0 =C2= =A0grouping config-X { .... }

=C2=A0 =C2=A0uses co= nfig-X {
=C2=A0 =C2=A0 =C2=A0 augment . {
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0container oper {
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 uses config-X;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}

I don't see how combining the ancestor top-level node with another one=
makes any difference to the solution.

<= br>
Andy

On Fri, Jan 13, 2017 at 8:21 AM, Robert Wilton = <rwilton@cisco.com> wrote:
=20 =20 =20

[keeping netmod, bcc netconf]


On 12/01/2017 22:05= , Andy Bierman wrote:
=20


On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > <j.schoenwaelder@jacobs-university.de>= ; wrote:
> >
> > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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:
> >>>>=C2=A0 =C2=A0- It is not possible to def= ine 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 (path) > >>>>=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-= statements of type-stmt)
> >>>>=C2=A0 =C2=A0 =C2=A0 - status
> >>>>=C2=A0 =C2=A0 =C2=A0 - description
> >>>>=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 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.
> >>
> >
> > OK. So the client does the validation. What does the client do if the
> > operational state it got is not valid according to the YANG
> > constraints?
>
> Don't forget that data models also provide guideline= s to server
> implementors.

Yes, and that it is all that can be done currently.=C2=A0 I don't think any
implemention that receives a <get> request today freezes the system in
order to get a guaranteed consistent snapshot.=C2=A0 Instead, the different
subsystems will be queried, sequentially or in parallell, and the end
result is shipped to the client.=C2=A0 The result may or may not be
consistent.



So this thread is questioning why YANG allows constraints on config=3Dfalse data nodes.
From the generic toolbuilder POV, it allows the YANG engine to report issues to
the operator without custom programming for each little issue.=C2=A0 Who knows why the
foo-table requires 3 entries to be valid min-elements 3).
The tool can report to the operator "foo-table does n= ot have enough entries"
and let the operator decide what to do about it.

The constraint checking that you describe sounds more like a "should" statement than a "must" statement.

I can't see that a server would want to validate must constraints o= n config false nodes when it is the source of that data, for several reasons:
- it is unclear what, if anything, it could do if one of the constraints fails.
- it wouldn't want the extra validation processing overhead.
- there would be an assumption that the data generated should conform to the model anyway.

Further, a client cannot reject a pushed notification or GET response from a server even if it doesn't conform with the constraints.=C2=A0 I agree that the checking that you describe above could be useful to flag problems, although I'm not sure how easily an automated client would be able to deal with them anyway.

One of the strong stated desired from the OpenConfig operators is that a device should accurately report what is is actually doing.=C2=A0 The question I have is what should a device do if it wants to return a value outside of the allowable range.=C2=A0 E.g. consider a schema th= at defines the maximum allowed value for leaf foo as 2, but due to some unexpected internal error, when the value is read from hardware it reports that the value is 3 instead.=C2=A0 Another case would be if the server wanted to return a value outside the specified range for a given type.

In these cases, depending on the encoding used, it may not be possible to return a value at all.=C2=A0 If this is a GET request then the server can return a error for the particular leaf path.=C2=A0 Does = an equivalent solution for notifications also exist?

Rob




=C2=A0
/martin


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



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/m=
ailman/listinfo/netmod


--94eb2c0777e668011f0545fdd99b-- From nobody Fri Jan 13 13:13:37 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 C62D81294AE for ; Fri, 13 Jan 2017 13:13:35 -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 9My0GNkd1IaG for ; Fri, 13 Jan 2017 13:13:34 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 64E2D129736 for ; Fri, 13 Jan 2017 13:13:34 -0800 (PST) Received: (qmail 12904 invoked by uid 0); 13 Jan 2017 21:13:31 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 13 Jan 2017 21:13:31 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id XxDT1u0192SSUrH01xDWrg; Fri, 13 Jan 2017 14:13:31 -0700 X-Authority-Analysis: v=2.1 cv=O6eq4nNW 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=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=48vgC7mUAAAA:8 a=Hv_YnvB0JoLW7w7YuRUA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=0NTH88oSTiEePXcV0+9btT6cCSKN9UKq+dHPMG6vst4=; b=FxsLXQdBEVQRm/iiaSXx031UUe Lb7wEh5cDYlRJhf0P3hBJIkoNJA09usQ/K565yn3uoLvZQP0Tr+wgBrOQiIJojZJScPU9TM9ABluC vFt3K0MQI2bkGW9DOKwF0PFRJ; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:51922 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cS9A7-0000Fb-P7; Fri, 13 Jan 2017 14:13:27 -0700 To: NetMod WG References: From: Lou Berger Message-ID: <926ee573-ae87-22b1-99dc-ba78777a7422@labn.net> Date: Fri, 13 Jan 2017 16:13:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: 1cS9A7-0000Fb-P7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:51922 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04 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, 13 Jan 2017 21:13:36 -0000 All, This draft is adopted. Authors, please republish as draft-ietf-netmod-sub-intf-vlan-model-00 as being the only change. Thank you, Lou PS my apologies for not sending this last month. On 12/12/2016 6:31 PM, Lou Berger wrote: > All, > > This is start of a two week* poll on making > draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group > document. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > * Given the holiday, the poll ends December 28. > > Thank you, > NetMod WG Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Jan 16 07:48:09 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 3FA08129581 for ; Mon, 16 Jan 2017 07:48: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 VGfkp1oruyl0 for ; Mon, 16 Jan 2017 07:48: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 A64D0129549 for ; Mon, 16 Jan 2017 07:48:06 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 0638F1AE047A for ; Mon, 16 Jan 2017 16:48:04 +0100 (CET) Date: Mon, 16 Jan 2017 16:48:03 +0100 (CET) Message-Id: <20170116.164803.729427888661667991.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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: Subject: [netmod] example modules in 6087bis 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, 16 Jan 2017 15:48:08 -0000 Hi, It turns out that the recommendations on example modules are a bit unclear. Different drafts do very different things. Some examples: https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2 This example module really looks like a real module. It uses an IANA-controlled namespace, and the meta-statements indicate that this is a normative modules. But the module does not use the tags. https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1 This module is better, but it is written to follow RFC 6087 rules (pass pyang --ietf), with the result that it contains a bit of "noise" with some meaningless descriptions and meta-statements. It also does not use tags. A good example (IMO) is found in https://tools.ietf.org/html/rfc8022#appendix-C It uses descriptions when necessary (high s/n), no fake meta-statements etc. However, it might be a good idea to require example modules to have a "description" statement that explains what the module examplifies. For example, the example-rip could have: description "This example module demonstrates how the core routing data model can be extended to support a new control-plane protocol. It is intended as an illustration rather than a real definition of a data model for the Routing Information Protocol (RIP)."; I think that 6087bis is clear when it says: The guidelines in this document refer mainly to a normative complete module or submodule, but may be applicable to example modules and YANG fragments as well. I think this states that example modules do not have to pass pyang --ietf. In order to make this more clear, I suggest the following changes to draft-ietf-netmod-rfc6087bis-09 In the Terminology section 2.4: NEW: o Example module: A complete YANG module or submodule that is intended to illustrate some specific aspect, but not intended for actual use. In section 4: NEW: All normative modules or submodules, example modules or submodules, and example YANG fragments MUST be valid according to RFC 7950, except when they are used to illustrate some illegal constructs. In Section 4.2.1 "Example Modules": NEW: An example module SHOULD have a namespace on the form o http://example.com/ OR o urn:example: An example module SHOULD have a description statement that describes that it is an example module, and what it examplifies. An example module SHOULD NOT have any additional meta-statements (i.e., "organization", "contact", or "reference"). An example module SHOULD use the "description" statement in any definition where it is required to understand the example. /martin From nobody Tue Jan 17 04:29: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 05DC7129A30 for ; Tue, 17 Jan 2017 04:29:17 -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 MPrfqQW84yic for ; Tue, 17 Jan 2017 04:29:16 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0545D1293E9 for ; Tue, 17 Jan 2017 04:29:16 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 267501AE02EF for ; Tue, 17 Jan 2017 13:29:15 +0100 (CET) Date: Tue, 17 Jan 2017 13:29:13 +0100 (CET) Message-Id: <20170117.132913.781493366440105564.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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: Subject: [netmod] mount-point in anydata 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, 17 Jan 2017 12:29:17 -0000 Hi, Currently, the schema mount draft says that the "mount-point" extension only can be defined in an "anydata" node. However, this doesn't really work, since RFC 7950 says: An anydata node is treated as an opaque chunk of data. This data can be modified in its entirety only. But the idea with schema mount is to build a composite model that can be manipulated just like a normal model, or a model that is augmented. If we mount models in an "anydata" node, clients would have to replace the enitire mounted subtree in order to change e.g. a single leaf. For this reason, I propose that we go back to the previous model where "mount-point" would be allowed in "container" and "list". Note that a client that doesn't know anything about these mounts would see some nodes in some unknown namespace; just like in the case that there is an augment that the client doesn't know about. /martin From nobody Tue Jan 17 06:27:44 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 8A8681294AF for ; Tue, 17 Jan 2017 06:27:41 -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 y7NjiMKy4dmt for ; Tue, 17 Jan 2017 06:27:39 -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 7892212896F for ; Tue, 17 Jan 2017 06:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28170; q=dns/txt; s=iport; t=1484663258; x=1485872858; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=2khhUnuCNhw94q+DZrGEJYqCFgF6ibBSIh5rm017ZP8=; b=AjjGtg6m8FfKG2JCIh8gklkunhMJcpHZMwuwc6VDUn/n3cVWKBkcBgWP iWwKATqeSbFVKwieqFX14u/6/NljsHq2NLapoAwC/WPdR048rvy/FuXNj 1zlX0YNymVgrYgSQy0cBF5g/k8I6B6F3lN2/UwjlyC2dvyORAGMWLmQ+i s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAQBmKH5Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoPAQEBAQF+Aydfg1GKB3KRJpUsggsfAQqFLkoCglAYAQIBAQE?= =?us-ascii?q?BAQEBYyiEaQEBAQMBAQEhSwQHBQsJEgggAwQDAgInHxEGDQYCAQEVAohgCA6Rb?= =?us-ascii?q?Z1OgiUriWUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZFggKHF4Mcgl4FlS+GC4F?= =?us-ascii?q?LiCmHa4F3iDgjhhuKcYd7Hzg2XxIIFRU6g39sgUc+NYYdK4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208,217";a="651709810" 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; 17 Jan 2017 14:27:34 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0HERXMF003009; Tue, 17 Jan 2017 14:27:33 GMT To: Andy Bierman References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> <95332531-0f4f-2070-9ced-79b6ed1a45b7@cisco.com> From: Robert Wilton Message-ID: Date: Tue, 17 Jan 2017 14:27:28 +0000 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: Content-Type: multipart/alternative; boundary="------------60B1E49F9A8302570D6F25AC" Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] Combined config/state trees [was Re: 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, 17 Jan 2017 14:27:41 -0000 This is a multi-part message in MIME format. --------------60B1E49F9A8302570D6F25AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 13/01/2017 18:17, Andy Bierman wrote: > Hi, > > > IMO the YANG data model constraints are too domain-specific to generalize. > If the designer is adding a constraint (must, when. min-elements -- > makes no difference) > then if must matter to that specific data model. It is not a SHOULD, > but a MUST. > Otherwise YANG has no value to data model designers. > > Seems to me that your proposal combines 'applied' and 'operational' > incorrectly. > > The only type of object that should be de-duplicated is the clone of > config-foo > for the sake of providing the oper-foo value (which could be supplied by > the get-oper RPC instead). Yes, it is only the leaves in the "state tree" that duplicate the corresponding configuration leaves that are de-duplicated. All other config false leaves in the "-state" containers are just moved to the merged config/state tree to avoid needing to maintain separate config and state trees. > > It is the 'applied' datastore that is not subject to validation, not > the operational datastore. The "applied" datastore is a subset of the content in the operational state datatstore. But I don't think that either would necessarily be validated by a device. I think that it would just report what the operational state is. > > Combining trees doesn't work if the 'normal' config=false nodes are > placed under > a list or P-container. There is no way to instantiate these nodes > unless the ancestor > config nodes also exist. There is no problem here because the operational state datastore allows for these parent config nodes to exist for other reasons even if they haven't been configured in running configuration. They would have the meta-data annotation 'system' or 'dynamic' > > The openconfig design pattern is getting phased out. Phased out by whom? Do you mean for the IETF models (e.g BGP)? I've not heard from the OpenConfig folks that they are intending change the structural convention of their models. > This never involved 2 trees anyway > > grouping config-X { .... } > > uses config-X { > augment . { > container oper { > config false; > uses config-X; > } > } > } > > I don't see how combining the ancestor top-level node with another one > makes any difference to the solution. I think that a combined tree has various benefits: - it makes the model more concise and consistent, with less manual repetition between config and state, and without requiring the use of groupings that can reduce readability. - it provides a well defined way to report the actual applied configuration that is in use by the device (allowing for time delays, dynamic, and system controlled overrides). - it provides a consistent path for where corresponding state for a configuration node will be found. For some existing IETF models, the config and state trees seem to have diverged. This will make life harder for implementors since they will need to hard code the relationship between the the config and state tree. Having a single tree avoids this problem because it automatically forces the config and state to be consistently co-located. Rob > > > Andy > > > On Fri, Jan 13, 2017 at 8:21 AM, Robert Wilton > wrote: > > [keeping netmod, bcc netconf] > > > On 12/01/2017 22:05, Andy Bierman wrote: >> >> >> On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund > > wrote: >> >> Ladislav Lhotka > wrote: >> > >> > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder >> > > > > wrote: >> > > >> > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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. >> > >> >> > > >> > > OK. So the client does the validation. What does the >> client do if the >> > > operational state it got is not valid according to the YANG >> > > constraints? >> > >> > Don't forget that data models also provide guidelines to server >> > implementors. >> >> Yes, and that it is all that can be done currently. I don't >> think any >> implemention that receives a request today freezes the >> system in >> order to get a guaranteed consistent snapshot. Instead, the >> different >> subsystems will be queried, sequentially or in parallell, and >> the end >> result is shipped to the client. The result may or may not be >> consistent. >> >> >> >> So this thread is questioning why YANG allows constraints on >> config=false data nodes. >> From the generic toolbuilder POV, it allows the YANG engine to >> report issues to >> the operator without custom programming for each little issue. >> Who knows why the >> foo-table requires 3 entries to be valid min-elements 3). >> The tool can report to the operator "foo-table does not have >> enough entries" >> and let the operator decide what to do about it. > > The constraint checking that you describe sounds more like a > "should" statement than a "must" statement. > > I can't see that a server would want to validate must constraints > on config false nodes when it is the source of that data, for > several reasons: > - it is unclear what, if anything, it could do if one of the > constraints fails. > - it wouldn't want the extra validation processing overhead. > - there would be an assumption that the data generated should > conform to the model anyway. > > Further, a client cannot reject a pushed notification or GET > response from a server even if it doesn't conform with the > constraints. I agree that the checking that you describe above > could be useful to flag problems, although I'm not sure how easily > an automated client would be able to deal with them anyway. > > One of the strong stated desired from the OpenConfig operators is > that a device should accurately report what is is actually doing. > The question I have is what should a device do if it wants to > return a value outside of the allowable range. E.g. consider a > schema that defines the maximum allowed value for leaf foo as 2, > but due to some unexpected internal error, when the value is read > from hardware it reports that the value is 3 instead. Another > case would be if the server wanted to return a value outside the > specified range for a given type. > > In these cases, depending on the encoding used, it may not be > possible to return a value at all. If this is a GET request then > the server can return a error for the particular leaf path. Does > an equivalent solution for notifications also exist? > > Rob > > >> >> >> /martin >> >> >> Andy >> >> _______________________________________________ >> 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 >> > --------------60B1E49F9A8302570D6F25AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,


On 13/01/2017 18:17, Andy Bierman wrote:
Hi,


IMO the YANG data model constraints are too domain-specific to generalize.
If the designer is adding a constraint (must, when. min-elements -- makes no difference)
then if must matter to that specific data model.  It is not a SHOULD, but a MUST.
Otherwise YANG has no value to data model designers.

Seems to me that your proposal combines 'applied' and 'operational' incorrectly.

The only type of object that should be de-duplicated is the clone of config-foo
for the sake of providing the oper-foo value (which could be supplied by
the get-oper RPC instead).
Yes, it is only the leaves in the "state tree" that duplicate the corresponding configuration leaves that are de-duplicated.  All other config false leaves in the "-state" containers are just moved to the merged config/state tree to avoid needing to maintain separate config and state trees.


It is the 'applied' datastore that is not subject to validation, not the operational datastore.
The "applied" datastore is a subset of the content in the operational state datatstore.

But I don't think that either would necessarily be validated by a device.  I think that it would just report what the operational state is.



Combining trees doesn't work if the 'normal' config=false nodes are placed under
a list or P-container. There is no way to instantiate these nodes unless the ancestor
config nodes also exist.
There is no problem here because the operational state datastore allows for these parent config nodes to exist for other reasons even if they haven't been configured in running configuration.

They would have the meta-data annotation 'system' or 'dynamic'


The openconfig design pattern is getting phased out.
Phased out by whom?  Do you mean for the IETF models (e.g BGP)?

I've not heard from the OpenConfig folks that they are intending change the structural convention of their models.


This never involved 2 trees anyway

   grouping config-X { .... }

   uses config-X {
      augment . {
         container oper {
            config false;
            uses config-X;
         }
      }
   }

I don't see how combining the ancestor top-level node with another one
makes any difference to the solution.

I think that a combined tree has various benefits:
- it makes the model more concise and consistent, with less manual repetition between config and state, and without requiring the use of groupings that can reduce readability.
- it provides a well defined way to report the actual applied configuration that is in use by the device (allowing for time delays, dynamic, and system controlled overrides).
- it provides a consistent path for where corresponding state for a configuration node will be found.

For some existing IETF models, the config and state trees seem to have diverged.  This will make life harder for implementors since they will need to hard code the relationship between the the config and state tree.  Having a single tree avoids this problem because it automatically forces the config and state to be consistently co-located.

Rob




Andy


On Fri, Jan 13, 2017 at 8:21 AM, Robert Wilton <rwilton@cisco.com> wrote:

[keeping netmod, bcc netconf]


On 12/01/2017 22:05, Andy Bierman wrote:


On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > <j.schoenwaelder@jacobs-university.de> wrote:
> >
> > On Thu, Jan 12, 2017 at 09:38:46AM -0800, 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.
> >>
> >
> > OK. So the client does the validation. What does the client do if the
> > operational state it got is not valid according to the YANG
> > constraints?
>
> Don't forget that data models also provide guidelines to server
> implementors.

Yes, and that it is all that can be done currently.  I don't think any
implemention that receives a <get> request today freezes the system in
order to get a guaranteed consistent snapshot.  Instead, the different
subsystems will be queried, sequentially or in parallell, and the end
result is shipped to the client.  The result may or may not be
consistent.



So this thread is questioning why YANG allows constraints on config=false data nodes.
From the generic toolbuilder POV, it allows the YANG engine to report issues to
the operator without custom programming for each little issue.  Who knows why the
foo-table requires 3 entries to be valid min-elements 3).
The tool can report to the operator "foo-table does not have enough entries"
and let the operator decide what to do about it.

The constraint checking that you describe sounds more like a "should" statement than a "must" statement.

I can't see that a server would want to validate must constraints on config false nodes when it is the source of that data, for several reasons:
- it is unclear what, if anything, it could do if one of the constraints fails.
- it wouldn't want the extra validation processing overhead.
- there would be an assumption that the data generated should conform to the model anyway.

Further, a client cannot reject a pushed notification or GET response from a server even if it doesn't conform with the constraints.  I agree that the checking that you describe above could be useful to flag problems, although I'm not sure how easily an automated client would be able to deal with them anyway.

One of the strong stated desired from the OpenConfig operators is that a device should accurately report what is is actually doing.  The question I have is what should a device do if it wants to return a value outside of the allowable range.  E.g. consider a schema that defines the maximum allowed value for leaf foo as 2, but due to some unexpected internal error, when the value is read from hardware it reports that the value is 3 instead.  Another case would be if the server wanted to return a value outside the specified range for a given type.

In these cases, depending on the encoding used, it may not be possible to return a value at all.  If this is a GET request then the server can return a error for the particular leaf path.  Does an equivalent solution for notifications also exist?

Rob




 
/martin


Andy
 
_______________________________________________
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
--------------60B1E49F9A8302570D6F25AC-- From nobody Tue Jan 17 10:12:02 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 31D181293D8 for ; Tue, 17 Jan 2017 10:12: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=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 LjyLMkDsJ7wc for ; Tue, 17 Jan 2017 10:12:00 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 C4AD4128DF6 for ; Tue, 17 Jan 2017 10:11:59 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id x49so170486990qtc.2 for ; Tue, 17 Jan 2017 10:11:59 -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=mkp+4txRtV3h7H8gQcEXdyOny4yazAqYt8yfHbpf9c8=; b=rptyMGcVFB/MF1evMlp4NQlzzX1skVszVPK9OuXqEljErjRrZewfoWY0j/K43j5yDz e/fYG4swlSnrU95/ogjJCP6N1SjDIvlzdfV8eFZUPCOhs6foYyCL5nCaW6BIrEArdxDr smFEr7fsS1M+Mf0Fvi6sT2+85jT8hcVsfIhC2SSlAew9pia3EccKmh4k4gY1BE1eScvG ao5wG8ALSzmhvkL78oed0Nor6hTxU5OdxAMHjG/hm0kIocHtVHYC7PyztxWHhy9Jv3Oz R/Maiv86DkGttm7fE0kjcvVZX5bui7RjcJ46mrp5Mv6OXvU5V1GK34ghggwz+LMzEQRf VjAg== 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=mkp+4txRtV3h7H8gQcEXdyOny4yazAqYt8yfHbpf9c8=; b=deGyPjrbU4YkYF2UsTCOMRecH1TFkKD8esKZd8vcL8h5n1923mCfNojsz1FpzUA9Oz GWmkCBcfGpUJrH7UW4ydK/xz6lAnF9vXLZLJaV4I97ZNFJMS8TsOLh9i46iUSB275QA7 Ewd2AfLRDvgTtzF22DI9zEHzf5TbZ8Pt1EcRrIOT6SjSReZl+WU5nh2ce9EW15X2vi5v imQnKaJf1dIHDuSUmGw32823iHqQ/t+aY2rQ6gzAoxdVAcYrK2G0fGqFfOe/IY1uSWNu HymiLTxPl7pBXrahx+RNPQOJ+NEzO8Zr72IN/9twivhbes6UkwxgweJ5SdKHHs/LdUTG 5jww== X-Gm-Message-State: AIkVDXJJuonGYxXPJZm+pkn+2/1P9/KJY7ACcHE/PdbJYXVGJdXjQn0bWhc49CglOPykEP9z92EJsc2chiJs1g== X-Received: by 10.237.34.239 with SMTP id q44mr34050215qtc.18.1484676718408; Tue, 17 Jan 2017 10:11:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Tue, 17 Jan 2017 10:11:58 -0800 (PST) In-Reply-To: <20170116.164803.729427888661667991.mbj@tail-f.com> References: <20170116.164803.729427888661667991.mbj@tail-f.com> From: Andy Bierman Date: Tue, 17 Jan 2017 10:11:58 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113e7aee68584505464e3c27 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] example modules in 6087bis 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, 17 Jan 2017 18:12:02 -0000 --001a113e7aee68584505464e3c27 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 16, 2017 at 7:48 AM, Martin Bjorklund wrote: > Hi, > > It turns out that the recommendations on example modules are a bit > unclear. Different drafts do very different things. Some examples: > > https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology > -08#section-6.1.2 > > This example module really looks like a real module. It uses an > IANA-controlled namespace, and the meta-statements indicate that this > is a normative modules. But the module does not use the tags. > > This example needs to be redone. There are 2 conflicting goals that need to be addressed. 1) Clearly identify a module as an example; not meant to be implemented; only present to demonstrate protocol interactions with an example module 2) Teach people good YANG authoring habits Way too much cut-and-paste out there so maybe if the examples follow "pyang --ietf" people will learn the right way to construct a module > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1 > > This module is better, but it is written to follow RFC 6087 rules > (pass pyang --ietf), with the result that it contains a bit of "noise" > with some meaningless descriptions and meta-statements. It also does > not use tags. > > > A good example (IMO) is found in > https://tools.ietf.org/html/rfc8022#appendix-C > > It uses descriptions when necessary (high s/n), no fake > meta-statements etc. > > It does not have a revision-stmt, which is really important for real YANG modules. IMO the random set of description-stmts is no better or worse than the examples in the RESTCONF draft. > However, it might be a good idea to require example modules to have a > "description" statement that explains what the module examplifies. > For example, the example-rip could have: > > description > "This example module demonstrates how the core routing data model > can be extended to support a new control-plane protocol. It is > intended as an illustration rather than a real definition of a > data model for the Routing Information Protocol (RIP)."; > > > OK > > I think that 6087bis is clear when it says: > > The guidelines in this document refer mainly to a normative complete > module or submodule, but may be applicable to example modules and > YANG fragments as well. > > I think this states that example modules do not have to pass pyang > --ietf. > > I agree that examples do not need to pass with the --ietf flag. But is the guideline a SHOULD pass or MAY pass? (agree it is not MUST pass) > > In order to make this more clear, I suggest the following changes to > draft-ietf-netmod-rfc6087bis-09 > > In the Terminology section 2.4: > > NEW: > > o Example module: A complete YANG module or submodule that is > intended to illustrate some specific aspect, but not intended for > actual use. > > > In section 4: > > NEW: > > All normative modules or submodules, example modules or submodules, > and example YANG fragments MUST be valid according to RFC 7950, > except when they are used to illustrate some illegal constructs. > > > In Section 4.2.1 "Example Modules": > > NEW: > > An example module SHOULD have a namespace on the form > > o http://example.com/ OR > o urn:example: > > An example module SHOULD have a description statement that describes > that it is an example module, and what it examplifies. > > An example module SHOULD NOT have any additional meta-statements > (i.e., "organization", "contact", or "reference"). > > An example module SHOULD use the "description" statement in any > definition where it is required to understand the example. > > > new text is OK with me. I would make it clear that module description and revision SHOULD be present. All other optional clauses MAY be present. > > > /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113e7aee68584505464e3c27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 16, 2017 at 7:48 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

It turns out that the recommendations on example modules are a bit
unclear.=C2=A0 Different drafts do very different things.=C2=A0 Some exampl= es:

https://tools.ietf.org/= html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2

This example module really looks like a real module.=C2=A0 It uses an
IANA-controlled namespace, and the meta-statements indicate that this
is a normative modules.=C2=A0 But the module does not use the <CODE> = tags.



This example needs to b= e redone.

There are 2 conflicting goals that need = to be addressed.

1) Clearly identify a module as a= n example; not meant to be implemented;
=C2=A0 =C2=A0 only presen= t to demonstrate protocol interactions with an example module
2) Teach people good YANG authoring habits
=C2=A0 =C2= =A0 =C2=A0Way too much cut-and-paste out there so maybe if the examples
=C2=A0 =C2=A0 =C2=A0follow "pyang --ietf" people will lear= n the right way to construct a module



=C2=A0

https://tools.ietf.org/html/d= raft-ietf-netconf-restconf-18#appendix-C.1

This module is better, but it is written to follow RFC 6087 rules
(pass pyang --ietf), with the result that it contains a bit of "noise&= quot;
with some meaningless descriptions and meta-statements.=C2=A0 It also does<= br> not use <CODE> tags.


A good example (IMO) is found in
https://tools.ietf.org/html/rfc8022#appendix-C

It uses descriptions when necessary (high s/n), no fake
meta-statements etc.





than the examples in the RESTCONF draft.

=C2=A0
However, it might be a good idea to require example modules to have a
"description" statement that explains what the module examplifies= .
For example, the example-rip could have:

=C2=A0 description
=C2=A0 =C2=A0 "This example module demonstrates how the core routing d= ata model
=C2=A0 =C2=A0 =C2=A0can be extended to support a new control-plane protocol= .=C2=A0 It is
=C2=A0 =C2=A0 =C2=A0intended as an illustration rather than a real definiti= on of a
=C2=A0 =C2=A0 =C2=A0data model for the Routing Information Protocol (RIP).&= quot;;



OK
=C2=A0

I think that 6087bis is clear when it says:

=C2=A0 The guidelines in this document refer mainly to a normative complete=
=C2=A0 module or submodule, but may be applicable to example modules and =C2=A0 YANG fragments as well.

I think this states that example modules do not have to pass pyang
--ietf.



I agree that examples d= o not need to pass with the --ietf flag.
But is the guideline a S= HOULD pass or MAY pass?
(agree it is not MUST pass)
=C2=A0

In order to make this more clear, I suggest the following changes to
draft-ietf-netmod-rfc6087bis-09

In the Terminology section 2.4:

NEW:

=C2=A0 o=C2=A0 Example module:=C2=A0 A complete YANG module or submodule th= at is
=C2=A0 =C2=A0 =C2=A0intended to illustrate some specific aspect, but not in= tended for
=C2=A0 =C2=A0 =C2=A0actual use.


In section 4:

NEW:

=C2=A0 =C2=A0All normative modules or submodules, example modules or submod= ules,
=C2=A0 =C2=A0and example YANG fragments MUST be valid according to RFC 7950= ,
=C2=A0 =C2=A0except when they are used to illustrate some illegal construct= s.


In Section 4.2.1 "Example Modules":

NEW:

=C2=A0 An example module SHOULD have a namespace on the form

=C2=A0 =C2=A0 o=C2=A0 http://example.com/<module-name> OR
=C2=A0 =C2=A0 o=C2=A0 urn:example:<module-name>

=C2=A0 An example module SHOULD have a description statement that describes=
=C2=A0 that it is an example module, and what it examplifies.

=C2=A0 An example module SHOULD NOT have any additional meta-statements
=C2=A0 (i.e., "organization", "contact", or "refer= ence").

=C2=A0 An example module SHOULD use the "description" statement i= n any
=C2=A0 definition where it is required to understand the example.




new text is OK with me.=
I would make it clear that module description and revision
=
SHOULD be present. All other optional clauses MAY be present.

=C2=A0


/martin


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

--001a113e7aee68584505464e3c27-- From nobody Wed Jan 18 01:52:38 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 26C5F129411 for ; Wed, 18 Jan 2017 01:52:38 -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 cFjH7YNarpXD for ; Wed, 18 Jan 2017 01:52:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 538661289C4 for ; Wed, 18 Jan 2017 01:52:36 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 86BAE1AE0455; Wed, 18 Jan 2017 10:52:34 +0100 (CET) Date: Wed, 18 Jan 2017 10:52:33 +0100 (CET) Message-Id: <20170118.105233.931185398708684727.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20170116.164803.729427888661667991.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: netmod@ietf.org Subject: Re: [netmod] example modules in 6087bis 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, 18 Jan 2017 09:52:38 -0000 Andy Bierman wrote: > On Mon, Jan 16, 2017 at 7:48 AM, Martin Bjorklund wrote: > > > Hi, > > > > It turns out that the recommendations on example modules are a bit > > unclear. Different drafts do very different things. Some examples: > > > > https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology > > -08#section-6.1.2 > > > > This example module really looks like a real module. It uses an > > IANA-controlled namespace, and the meta-statements indicate that this > > is a normative modules. But the module does not use the tags. > > > > > > This example needs to be redone. > > There are 2 conflicting goals that need to be addressed. > > 1) Clearly identify a module as an example; not meant to be implemented; > only present to demonstrate protocol interactions with an example module Yes - maybe add this text to 6087bis? > 2) Teach people good YANG authoring habits > Way too much cut-and-paste out there so maybe if the examples > follow "pyang --ietf" people will learn the right way to construct a > module This assumes that people copy&paste from example modules. I'm not sure that this a real problem. If they do that when they develop IETF modules, Benoit's script will kick in anyway. > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1 > > > > This module is better, but it is written to follow RFC 6087 rules > > (pass pyang --ietf), with the result that it contains a bit of "noise" > > with some meaningless descriptions and meta-statements. It also does > > not use tags. > > > > > > A good example (IMO) is found in > > https://tools.ietf.org/html/rfc8022#appendix-C > > > > It uses descriptions when necessary (high s/n), no fake > > meta-statements etc. > > > > > > > It does not have a revision-stmt, which is really important > for real YANG modules. Yes, but it is not important for examples (typically). > IMO the random set of description-stmts is no better or worse > than the examples in the RESTCONF draft. > > > > > However, it might be a good idea to require example modules to have a > > "description" statement that explains what the module examplifies. > > For example, the example-rip could have: > > > > description > > "This example module demonstrates how the core routing data model > > can be extended to support a new control-plane protocol. It is > > intended as an illustration rather than a real definition of a > > data model for the Routing Information Protocol (RIP)."; > > > > > > > OK > > > > > > I think that 6087bis is clear when it says: > > > > The guidelines in this document refer mainly to a normative complete > > module or submodule, but may be applicable to example modules and > > YANG fragments as well. > > > > I think this states that example modules do not have to pass pyang > > --ietf. > > > > > > I agree that examples do not need to pass with the --ietf flag. > But is the guideline a SHOULD pass or MAY pass? > (agree it is not MUST pass) The current text implies MAY. Perhaps s/may/MAY/ in the original text in order to make this clear? /martin > > In order to make this more clear, I suggest the following changes to > > draft-ietf-netmod-rfc6087bis-09 > > > > In the Terminology section 2.4: > > > > NEW: > > > > o Example module: A complete YANG module or submodule that is > > intended to illustrate some specific aspect, but not intended for > > actual use. > > > > > > In section 4: > > > > NEW: > > > > All normative modules or submodules, example modules or submodules, > > and example YANG fragments MUST be valid according to RFC 7950, > > except when they are used to illustrate some illegal constructs. > > > > > > In Section 4.2.1 "Example Modules": > > > > NEW: > > > > An example module SHOULD have a namespace on the form > > > > o http://example.com/ OR > > o urn:example: > > > > An example module SHOULD have a description statement that describes > > that it is an example module, and what it examplifies. > > > > An example module SHOULD NOT have any additional meta-statements > > (i.e., "organization", "contact", or "reference"). > > > > An example module SHOULD use the "description" statement in any > > definition where it is required to understand the example. > > > > > > > > new text is OK with me. > I would make it clear that module description and revision > SHOULD be present. All other optional clauses MAY be present. > > > > > > > > > /martin > > > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Wed Jan 18 03:49: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 A0D951295D5 for ; Wed, 18 Jan 2017 03:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTO6qe1F1SXX for ; Wed, 18 Jan 2017 03:48:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703AD12940C for ; Wed, 18 Jan 2017 03:48:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 62A63B80FFD; Wed, 18 Jan 2017 03:48:58 -0800 (PST) To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170118114858.62A63B80FFD@rfc-editor.org> Date: Wed, 18 Jan 2017 03:48:58 -0800 (PST) Archived-At: Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (4911) 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, 18 Jan 2017 11:48:59 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911 -------------------------------------- Type: Technical Reported by: Ladislav Lhotka Section: 6.1.3 Original Text ------------- Within a double-quoted string (enclosed within " "), a backslash character introduces a special character, which depends on the character that immediately follows the backslash: \n new line \t a tab character \" a double quote \ a single backslash Corrected Text -------------- Within a double-quoted string (enclosed within " "), a backslash character introduces a special character, which depends on the character that immediately follows the backslash: \n new line \t a tab character \" a double quote \ a single backslash The backslash MUST NOT be followed by any other character. Notes ----- The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches: 1. report an error if another character follows the backslash 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x". 3. keep both the backslash and the character following it. This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Jan 18 05:22:28 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 16318129412 for ; Wed, 18 Jan 2017 05:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 X6rt4j7R9jkq for ; Wed, 18 Jan 2017 05:22:25 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8383E1270B4 for ; Wed, 18 Jan 2017 05:22:24 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C416D1CC01AA for ; Wed, 18 Jan 2017 14:22:25 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org Date: Wed, 18 Jan 2017 14:22:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] notifications 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, 18 Jan 2017 13:22:27 -0000 Hi, if NETCONF WG moves away from RFC 5277, what does it mean for YANG? In my opinion, we have two options: 1. remove references to 5277 from the YANG spec and define a notification as any data sent asynchronously by the server, or 2. generalize even more and treat a particular notification as just another type of data tree. BTW, the Terminology section in RFC 7950 doesn't contain a definition of a notification (unlike pretty much everything else). Is it just an omission or was it intentional? Lada -------------------- Start of forwarded message -------------------- From: "Mehmet Ersue" To: "'Netconf'" Date: Wed, 18 Jan 2017 00:06:14 +0100 Subject: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure ... B) NETCONF co-chairs further propose that NETCONF WG should use its energy in the future to complete and improve the new notification and subscription RFCs and stop maintaining RFC 5277 for issues other than errata. Note that it is required that RFC 5277 and all new work needs to gracefully co-exist in any deployment. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 18 05:55: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 78F18129721 for ; Wed, 18 Jan 2017 05:55:38 -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 AHZxluusZqxb for ; Wed, 18 Jan 2017 05:55:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D16B012970A for ; Wed, 18 Jan 2017 05:55:36 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 662211AE0455; Wed, 18 Jan 2017 14:55:34 +0100 (CET) Date: Wed, 18 Jan 2017 14:55:32 +0100 (CET) Message-Id: <20170118.145532.995038902796253716.mbj@tail-f.com> To: rfc-editor@rfc-editor.org From: Martin Bjorklund In-Reply-To: <20170118114858.62A63B80FFD@rfc-editor.org> References: <20170118114858.62A63B80FFD@rfc-editor.org> 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: netmod@ietf.org, joelja@bogus.com Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) 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, 18 Jan 2017 13:55:38 -0000 RFC Errata System wrote: > The following errata report has been submitted for RFC6020, > "YANG - A Data Modeling Language for the Network Configuration > Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911 > > -------------------------------------- > Type: Technical > Reported by: Ladislav Lhotka > > Section: 6.1.3 > > Original Text > ------------- > Within a double-quoted string (enclosed within " "), a backslash > character introduces a special character, which depends on the > character that immediately follows the backslash: > > \n new line > \t a tab character > \" a double quote > \ a single backslash > > > Corrected Text > -------------- > Within a double-quoted string (enclosed within " "), a backslash > character introduces a special character, which depends on the > character that immediately follows the backslash: > > \n new line > \t a tab character > \" a double quote > \ a single backslash > > The backslash MUST NOT be followed by any other character. > > Notes > ----- > The text doesn't state whether other characters may follow the > backslash, and if yes, what it means. Existing implementations have > used three approaches: > > 1. report an error if another character follows the backslash > 2. keep only the character following the backslash, i.e., for example, > "\x" is the same as "x". > 3. keep both the backslash and the character following it. > > This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly > adopted option #1. However, many modules are still being written using > YANG version 1.0, so it is important to clarify this issue in RFC 6020 > as well. I don't think this errata should be accepted. As stated, the spec is unclear, and YANG 1.1 has fixed this problem. But it is not clear that the original intention when RFC 6020 was written was #1. Accepting this errata now would make existing implementations and modules invalid. The solution moving forward is to use YANG 1.1. /martin From nobody Wed Jan 18 06:24:28 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 3F32112945A for ; Wed, 18 Jan 2017 06:24:27 -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 1C3fV9kKVjYq for ; Wed, 18 Jan 2017 06:24:25 -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 A8543129440 for ; Wed, 18 Jan 2017 06:24:24 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ded:9860:a06f:ffc4] (unknown [IPv6:2001:718:1a02:1:ded:9860:a06f:ffc4]) by mail.nic.cz (Postfix) with ESMTPSA id DA02C607AF; Wed, 18 Jan 2017 15:24:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484749462; bh=6TMpkMHPzrvSZnec0xSRMRUzi5PisXOyUnkzKBoEwE8=; h=From:Date:To; b=WGJRnBSK0vEX4llcafLye7kLOTwCu8QEYgAWdazyLzxkn2h6DItyyR9SxVcDxvkvv Q6FPspdbCP1FO/Hnlw7bmSEzxXY+FjBNgAFGXrJV4fsidiFtigl0C+UM61e3ZX3FXz 5TbYF4pfSsnY9Cprp0Bf32bmJhkG/+tP2LYuAEEA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170118.145532.995038902796253716.mbj@tail-f.com> Date: Wed, 18 Jan 2017 15:24:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69B83F1A-1FBC-44E9-B499-054966616C11@nic.cz> References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.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: netmod@ietf.org, joel jaeggli , RFC Editor Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) 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, 18 Jan 2017 14:24:27 -0000 > On 18 Jan 2017, at 14:55, Martin Bjorklund wrote: >=20 > RFC Errata System wrote: >> The following errata report has been submitted for RFC6020, >> "YANG - A Data Modeling Language for the Network Configuration >> Protocol (NETCONF)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D4911 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Ladislav Lhotka >>=20 >> Section: 6.1.3 >>=20 >> Original Text >> ------------- >> Within a double-quoted string (enclosed within " "), a backslash >> character introduces a special character, which depends on the >> character that immediately follows the backslash: >>=20 >> \n new line >> \t a tab character >> \" a double quote >> \ a single backslash >>=20 >>=20 >> Corrected Text >> -------------- >> Within a double-quoted string (enclosed within " "), a backslash >> character introduces a special character, which depends on the >> character that immediately follows the backslash: >>=20 >> \n new line >> \t a tab character >> \" a double quote >> \ a single backslash >>=20 >> The backslash MUST NOT be followed by any other character. >>=20 >> Notes >> ----- >> The text doesn't state whether other characters may follow the >> backslash, and if yes, what it means. Existing implementations have >> used three approaches: >>=20 >> 1. report an error if another character follows the backslash >> 2. keep only the character following the backslash, i.e., for = example, >> "\x" is the same as "x". >> 3. keep both the backslash and the character following it. >>=20 >> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly >> adopted option #1. However, many modules are still being written = using >> YANG version 1.0, so it is important to clarify this issue in RFC = 6020 >> as well. >=20 > I don't think this errata should be accepted. As stated, the spec is > unclear, and YANG 1.1 has fixed this problem. But it is not clear > that the original intention when RFC 6020 was written was #1. > Accepting this errata now would make existing implementations and > modules invalid. The problem is that the spec is clearly ambiguous and it is impossible = to decide whether such a module is valid or not and, if it is, what the = other backslash-escaped characters mean. Existing implementations can = already reject such modules - the fact that pyang (and probably other = tail-f tools) adopted one interpretation doesn't mean that everybody = does the same. >=20 > The solution moving forward is to use YANG 1.1. >=20 YANG 1.0 modules continue to be written, and I think it is important to = stop this problem from spreading further. I think tools should at least = issue a warning because otherwise future upgrades to YANG 1.1 may become = a nightmare - modules will suddenly break in unexpected places. If this erratum is rejected, what is the basis for accepting erratum = #4909 that started this discussion? Lada >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 18 06:37:46 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 AB2F2129463 for ; Wed, 18 Jan 2017 06:37: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 9IgIkYzJbA-Q for ; Wed, 18 Jan 2017 06:37:42 -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 0B114126FDC for ; Wed, 18 Jan 2017 06:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10281; q=dns/txt; s=iport; t=1484750262; x=1485959862; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=xUonJj1H5tDZ7iMXkLAeVbCfO94cjuKc6sJxtpO9G2c=; b=QCWe6at9imAZ7DFmtiyhhrFaXcoByzk5bdCdoewA+CGbekLL+A/UIbnM pba7DPKEOnWFQti4tHs2pay/vGY30V//Y24ux9REwB9szcZn3jpJ1XsDo wpCbKxCCRXwwMIITxzoi+4Iz8He1kqb77P/+R5jdlXqA+pGhAFUkmpp9z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQC5fH9Y/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM5AQEBAQF+A4EGjVlykQ+QAYUrggsqhXgCgjcYAQIBAQEBAQE?= =?us-ascii?q?BYyiEagEFeRALGC5XBgEMBgIBARYBiGgOLbFCK4l7AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYZLggWCaYE8gVCBMIVxBYh+EYdehEaGDokxiDGBd4g4hj6IHIJYh3s?= =?us-ascii?q?fOBCBBRIIFRWEcQ0PgWE9NQEThjKCOwEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,249,1477958400"; d="scan'208,217";a="649928565" 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; 18 Jan 2017 14:37:40 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0IEbdis001677; Wed, 18 Jan 2017 14:37:39 GMT To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.mbj@tail-f.com> <69B83F1A-1FBC-44E9-B499-054966616C11@nic.cz> From: Benoit Claise Message-ID: Date: Wed, 18 Jan 2017 15:37:41 +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: <69B83F1A-1FBC-44E9-B499-054966616C11@nic.cz> Content-Type: multipart/alternative; boundary="------------C87398C3EE29712F654A787C" Archived-At: Cc: joel jaeggli , netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) 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, 18 Jan 2017 14:37:45 -0000 This is a multi-part message in MIME format. --------------C87398C3EE29712F654A787C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Removing RFC Editor See in-line. >> On 18 Jan 2017, at 14:55, Martin Bjorklund wrote: >> >> RFC Errata System wrote: >>> The following errata report has been submitted for RFC6020, >>> "YANG - A Data Modeling Language for the Network Configuration >>> Protocol (NETCONF)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Ladislav Lhotka >>> >>> Section: 6.1.3 >>> >>> Original Text >>> ------------- >>> Within a double-quoted string (enclosed within " "), a backslash >>> character introduces a special character, which depends on the >>> character that immediately follows the backslash: >>> >>> \n new line >>> \t a tab character >>> \" a double quote >>> \ a single backslash >>> >>> >>> Corrected Text >>> -------------- >>> Within a double-quoted string (enclosed within " "), a backslash >>> character introduces a special character, which depends on the >>> character that immediately follows the backslash: >>> >>> \n new line >>> \t a tab character >>> \" a double quote >>> \ a single backslash >>> >>> The backslash MUST NOT be followed by any other character. >>> >>> Notes >>> ----- >>> The text doesn't state whether other characters may follow the >>> backslash, and if yes, what it means. Existing implementations have >>> used three approaches: >>> >>> 1. report an error if another character follows the backslash >>> 2. keep only the character following the backslash, i.e., for example, >>> "\x" is the same as "x". >>> 3. keep both the backslash and the character following it. >>> >>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly >>> adopted option #1. However, many modules are still being written using >>> YANG version 1.0, so it is important to clarify this issue in RFC 6020 >>> as well. >> I don't think this errata should be accepted. As stated, the spec is >> unclear, and YANG 1.1 has fixed this problem. But it is not clear >> that the original intention when RFC 6020 was written was #1. >> Accepting this errata now would make existing implementations and >> modules invalid. > The problem is that the spec is clearly ambiguous and it is impossible to decide whether such a module is valid or not and, if it is, what the other backslash-escaped characters mean. Existing implementations can already reject such modules - the fact that pyang (and probably other tail-f tools) adopted one interpretation doesn't mean that everybody does the same. > >> The solution moving forward is to use YANG 1.1. >> > YANG 1.0 modules continue to be written, and I think it is important to stop this problem from spreading further. I think tools should at least issue a warning because otherwise future upgrades to YANG 1.1 may become a nightmare - modules will suddenly break in unexpected places. Now two good news. First, pyang now includes a warning for YANG 1.0 modules: $ pyang ietf-ipfix-psamp@2012-09-05.yang ietf-ipfix-psamp@2012-09-05.yang:259: warning: the escape sequence "\S" is unsafe in double quoted strings - pass the flag --lax-quote-checks to avoid this warning Thanks Martin for the speedy update. Note that this error message it was already present for YANG 1.1, as this is covered by RFC 7950. Second, I ran all my scripts with the new pyang version, and no IETF YANG 1.0 modules face that issue (http://www.claise.be/IETFYANGPageCompilation.html) However, we observed that some proprietary YANG 1.0 modules face this issue. > > If this erratum is rejected, what is the basis for accepting erratum #4909 that started this discussion? Exact same question on my side. Regards, Benoit > > Lada > >> /martin > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > --------------C87398C3EE29712F654A787C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Removing RFC Editor <rfc-editor@rfc-editor.org>

See in-line.

      

        
On 18 Jan 2017, at 14:55, Martin Bjorklund <mbj@tail-f.com> wrote:

RFC Errata System <rfc-editor@rfc-editor.org> wrote:


        

          
The following errata report has been submitted for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911

--------------------------------------
Type: Technical
Reported by: Ladislav Lhotka <lhotka@nic.cz>

Section: 6.1.3

Original Text
-------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

\n      new line
\t      a tab character
\"      a double quote
\      a single backslash


Corrected Text
--------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

\n      new line
\t      a tab character
\"      a double quote
\      a single backslash

The backslash MUST NOT be followed by any other character.

Notes
-----
The text doesn't state whether other characters may follow the
backslash, and if yes, what it means. Existing implementations have
used three approaches:

1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example,
"\x" is the same as "x".
3. keep both the backslash and the character following it.

This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly
adopted option #1. However, many modules are still being written using
YANG version 1.0, so it is important to clarify this issue in RFC 6020
as well.


        

        
I don't think this errata should be accepted.  As stated, the spec is
unclear, and YANG 1.1 has fixed this problem.  But it is not clear
that the original intention when RFC 6020 was written was #1.
Accepting this errata now would make existing implementations and
modules invalid.


      

      
The problem is that the spec is clearly ambiguous and it is impossible to decide whether such a module is valid or not and, if it is, what the other backslash-escaped characters mean. Existing implementations can already reject such modules - the fact that pyang (and probably other tail-f tools) adopted one interpretation doesn't mean that everybody does the same.



      

        
The solution moving forward is to use YANG 1.1.



      

      
YANG 1.0 modules continue to be written, and I think it is important to stop this problem from spreading further. I think tools should at least issue a warning because otherwise future upgrades to YANG 1.1 may become a nightmare - modules will suddenly break in unexpected places.

    

    Now two good news.

    

    First, pyang now includes a warning for YANG 1.0 modules:

    
$ pyang ietf-ipfix-psamp@2012-09-05.yang 

      ietf-ipfix-psamp@2012-09-05.yang:259: warning: the escape sequence
      "\S" is unsafe in double quoted strings - pass the flag
      --lax-quote-checks to avoid this warning

    

    Thanks Martin for the speedy update. Note that this error message it
    was already present for YANG 1.1, as this is covered by RFC 7950.

    

    Second, I ran all my scripts with the new pyang version, and no IETF
    YANG 1.0 modules face that issue
    (http://www.claise.be/IETFYANGPageCompilation.html)

    

    However, we observed that some proprietary YANG 1.0 modules face
    this issue.
    

      

If this erratum is rejected, what is the basis for accepting erratum #4909 that started this discussion?

    

    Exact same question on my side.

    

    Regards, Benoit

    

      

Lada



      

        
/martin


      

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





.



    

    

  


--------------C87398C3EE29712F654A787C--


From nobody Wed Jan 18 06:44: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 3EB4B1293DF for ; Wed, 18 Jan 2017 06:44:22 -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 sLgq38gGm5WQ for ; Wed, 18 Jan 2017 06:44: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 B9BF212985F for ; Wed, 18 Jan 2017 06:44:14 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D2161AE0455; Wed, 18 Jan 2017 15:44:13 +0100 (CET)
Date: Wed, 18 Jan 2017 15:44:12 +0100 (CET)
Message-Id: <20170118.154412.1767958997070783224.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <69B83F1A-1FBC-44E9-B499-054966616C11@nic.cz>
References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.mbj@tail-f.com> <69B83F1A-1FBC-44E9-B499-054966616C11@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: netmod@ietf.org, joelja@bogus.com, rfc-editor@rfc-editor.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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, 18 Jan 2017 14:44:22 -0000

Ladislav Lhotka  wrote:
> 
> > On 18 Jan 2017, at 14:55, Martin Bjorklund  wrote:
> > 
> > RFC Errata System  wrote:
> >> The following errata report has been submitted for RFC6020,
> >> "YANG - A Data Modeling Language for the Network Configuration
> >> Protocol (NETCONF)".
> >> 
> >> --------------------------------------
> >> You may review the report below and at:
> >> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
> >> 
> >> --------------------------------------
> >> Type: Technical
> >> Reported by: Ladislav Lhotka 
> >> 
> >> Section: 6.1.3
> >> 
> >> Original Text
> >> -------------
> >> Within a double-quoted string (enclosed within " "), a backslash
> >> character introduces a special character, which depends on the
> >> character that immediately follows the backslash:
> >> 
> >> \n      new line
> >> \t      a tab character
> >> \"      a double quote
> >> \      a single backslash
> >> 
> >> 
> >> Corrected Text
> >> --------------
> >> Within a double-quoted string (enclosed within " "), a backslash
> >> character introduces a special character, which depends on the
> >> character that immediately follows the backslash:
> >> 
> >> \n      new line
> >> \t      a tab character
> >> \"      a double quote
> >> \      a single backslash
> >> 
> >> The backslash MUST NOT be followed by any other character.
> >> 
> >> Notes
> >> -----
> >> The text doesn't state whether other characters may follow the
> >> backslash, and if yes, what it means. Existing implementations have
> >> used three approaches:
> >> 
> >> 1. report an error if another character follows the backslash
> >> 2. keep only the character following the backslash, i.e., for example,
> >> "\x" is the same as "x".
> >> 3. keep both the backslash and the character following it.
> >> 
> >> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly
> >> adopted option #1. However, many modules are still being written using
> >> YANG version 1.0, so it is important to clarify this issue in RFC 6020
> >> as well.
> > 
> > I don't think this errata should be accepted.  As stated, the spec is
> > unclear, and YANG 1.1 has fixed this problem.  But it is not clear
> > that the original intention when RFC 6020 was written was #1.
> > Accepting this errata now would make existing implementations and
> > modules invalid.
> 
> The problem is that the spec is clearly ambiguous

Agreed.

> and it is
> impossible to decide whether such a module is valid or not and, if
> it is, what the other backslash-escaped characters mean. Existing
> implementations can already reject such modules - the fact that
> pyang (and probably other tail-f tools) adopted one interpretation
> doesn't mean that everybody does the same. 

This is exactly my point.

> > The solution moving forward is to use YANG 1.1.
> > 
> 
> YANG 1.0 modules continue to be written, and I think it is important
> to stop this problem from spreading further. I think tools should
> at least issue a warning because otherwise future upgrades to YANG
> 1.1 may become a nightmare - modules will suddenly break in
> unexpected places.

Sure, but that's a different story (I already added a warning for this
in pyang).

> If this erratum is rejected, what is the basis for accepting erratum
> #4909 that started this discussion?

That module relied on one interpretation, but as you write, the spec
is unclear and toold behave differently.  Thus, modules should avoid
this pattern.


/martin


From nobody Wed Jan 18 06: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 EB52A129856 for ; Wed, 18 Jan 2017 06:54:19 -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 LUw-mGzWcsXy for ; Wed, 18 Jan 2017 06:54:18 -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 72D0012943B for ; Wed, 18 Jan 2017 06:54:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4320; q=dns/txt; s=iport; t=1484751257; x=1485960857; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=qxdZgZJbQW8b2wAHz8th8pftkKBMxmYxUx38bPNNmd8=; b=jd5DI33g6kDMDK1ngMsNGukKepdKWSuTG6fW1fXK31cEB3TRF1jkcXl0 s0+cuaPRdlMIT0aI9Qm6Ng3uEujoWixdU08K0DsE//XzkdWFHgD4Dcwon FWo6BkNmKJSE9d4pJEr7PRPNObZkvaHHfa3+StM4yLLmLNs8EwVsf4z5s o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQArgX9Y/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM5AQEBAQF+A4EGjVlykHAflSyCCx8LhS5KAoI4GAECAQEBAQE?= =?us-ascii?q?BAWMohGoBAQQBATY2CxALGC4nMAYNBgIBAReIaA4tsUmKJgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GS4IFCIJhgTyBUIEwhXEFiH4Rh16KVIkxiDGKL4Y+inSHex8?= =?us-ascii?q?4EIEFEggVFTqENw0PgWA+NQEThjKCOwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,249,1477958400"; d="scan'208";a="651749757"
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; 18 Jan 2017 14:54: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-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0IEsE38008015; Wed, 18 Jan 2017 14:54:14 GMT
To: Ladislav Lhotka 
References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.mbj@tail-f.com> <69B83F1A-1FBC-44E9-B499-054966616C11@nic.cz>
From: Robert Wilton 
Message-ID: 
Date: Wed, 18 Jan 2017 14:54:14 +0000
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: <69B83F1A-1FBC-44E9-B499-054966616C11@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: joel jaeggli , netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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, 18 Jan 2017 14:54:20 -0000

Hi Lada,

I don't feel strongly, but basically agree with Martin.

The YANG 1.0 spec is ambiguous, YANG 1.1 has fixed that.  I guess that 
most pragmatic YANG 1.0 implementations would treat a backslash followed 
by something other than n,t,", or / as just a backslash character.

This issue seems to only come up in the context of pattern statements.

The best pragmatic answer that I've seen to this is from rfc6087bis 
section 5.11.2: "Patterns and Ranges" which states that implementations 
SHOULD use single quotes rather than double quotes for patterns and 
hence carefully side steps the issue.

This is the solution that we used to fix the issue in our proprietary 
modules, and also the one that I recommended to OpenConfig for their 
models (but I don't know whether they will implement this).

Rob


On 18/01/2017 14:24, Ladislav Lhotka wrote:
>> On 18 Jan 2017, at 14:55, Martin Bjorklund  wrote:
>>
>> RFC Errata System  wrote:
>>> The following errata report has been submitted for RFC6020,
>>> "YANG - A Data Modeling Language for the Network Configuration
>>> Protocol (NETCONF)".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>>>
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Ladislav Lhotka 
>>>
>>> Section: 6.1.3
>>>
>>> Original Text
>>> -------------
>>> Within a double-quoted string (enclosed within " "), a backslash
>>> character introduces a special character, which depends on the
>>> character that immediately follows the backslash:
>>>
>>> \n      new line
>>> \t      a tab character
>>> \"      a double quote
>>> \      a single backslash
>>>
>>>
>>> Corrected Text
>>> --------------
>>> Within a double-quoted string (enclosed within " "), a backslash
>>> character introduces a special character, which depends on the
>>> character that immediately follows the backslash:
>>>
>>> \n      new line
>>> \t      a tab character
>>> \"      a double quote
>>> \      a single backslash
>>>
>>> The backslash MUST NOT be followed by any other character.
>>>
>>> Notes
>>> -----
>>> The text doesn't state whether other characters may follow the
>>> backslash, and if yes, what it means. Existing implementations have
>>> used three approaches:
>>>
>>> 1. report an error if another character follows the backslash
>>> 2. keep only the character following the backslash, i.e., for example,
>>> "\x" is the same as "x".
>>> 3. keep both the backslash and the character following it.
>>>
>>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly
>>> adopted option #1. However, many modules are still being written using
>>> YANG version 1.0, so it is important to clarify this issue in RFC 6020
>>> as well.
>> I don't think this errata should be accepted.  As stated, the spec is
>> unclear, and YANG 1.1 has fixed this problem.  But it is not clear
>> that the original intention when RFC 6020 was written was #1.
>> Accepting this errata now would make existing implementations and
>> modules invalid.
> The problem is that the spec is clearly ambiguous and it is impossible to decide whether such a module is valid or not and, if it is, what the other backslash-escaped characters mean. Existing implementations can already reject such modules - the fact that pyang (and probably other tail-f tools) adopted one interpretation doesn't mean that everybody does the same.
>
>> The solution moving forward is to use YANG 1.1.
>>
> YANG 1.0 modules continue to be written, and I think it is important to stop this problem from spreading further. I think tools should at least issue a warning because otherwise future upgrades to YANG 1.1 may become a nightmare - modules will suddenly break in unexpected places.
>
> If this erratum is rejected, what is the basis for accepting erratum #4909 that started this discussion?
>
> Lada
>
>> /martin
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Jan 18 06:57: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 2EC661293E1 for ; Wed, 18 Jan 2017 06:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 XUPrO7lV_nx3 for ; Wed, 18 Jan 2017 06:57:01 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7BF127076 for ; Wed, 18 Jan 2017 06:57:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 668B41E565A; Wed, 18 Jan 2017 06:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gIEYG-zGehyw; Wed, 18 Jan 2017 06:56:48 -0800 (PST)
Received: from [192.168.1.127] (host5-81-223-185.range5-81.btcentralplus.com [5.81.223.185]) by c8a.amsl.com (Postfix) with ESMTPSA id B063F1E5656; Wed, 18 Jan 2017 06:56:47 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: William Lupton 
In-Reply-To: <20170118.145532.995038902796253716.mbj@tail-f.com>
Date: Wed, 18 Jan 2017 14:56:58 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.mbj@tail-f.com>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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, 18 Jan 2017 14:57:02 -0000

Reading RFC 6020 there is no =E2=80=9CObsoleted by RFC 7950=E2=80=9D or =
=E2=80=9CUpdated by RFC 7950=E2=80=9D. I expect that this is technically =
correct but it means that anyone reading RFC 6020 will not be aware of =
the existence of RFC 7950 and YANG 1.1. This seems unfortunate. W.

> On 18 Jan 2017, at 13:55, Martin Bjorklund  wrote:
...
> The solution moving forward is to use YANG 1.1.


From nobody Wed Jan 18 06:58: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 617CC129461 for ; Wed, 18 Jan 2017 06:58:13 -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 7_AkHV-aAzwo for ; Wed, 18 Jan 2017 06:58:11 -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 2D99312943B for ; Wed, 18 Jan 2017 06:58:11 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:ded:9860:a06f:ffc4] (unknown [IPv6:2001:718:1a02:1:ded:9860:a06f:ffc4]) by mail.nic.cz (Postfix) with ESMTPSA id C90D360932; Wed, 18 Jan 2017 15:58:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484751489; bh=Mpuqa0m0yfHa4fqL78IMux1pwZI2VXsSSCvBq6MPHfo=; h=From:Date:To; b=kE9w1ByPJ3h7UbAOzJv6989Zl6tvIlsT8adjQf2lWzqQxno1Lg4z6W/pNFUwbzDzb JCxHu6TbGhh9bRYzQp/zd1lE+3nCJwETLDh5nWGOeinL+jSwkxNH6haHlmUSOGs+HD 5zSEk3LVWXzdEqGoxuSPa1+e9kE9poJjCXrE9+S8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <20170118.154412.1767958997070783224.mbj@tail-f.com>
Date: Wed, 18 Jan 2017 15:58:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.mbj@tail-f.com> <69B83F1A-1FBC-44E9-B499-054966616C11@nic.cz> <20170118.154412.1767958997070783224.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: netmod@ietf.org, joel jaeggli , RFC Editor 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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, 18 Jan 2017 14:58:13 -0000

> On 18 Jan 2017, at 15:44, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 18 Jan 2017, at 14:55, Martin Bjorklund  wrote:
>>>=20
>>> RFC Errata System  wrote:
>>>> The following errata report has been submitted for RFC6020,
>>>> "YANG - A Data Modeling Language for the Network Configuration
>>>> Protocol (NETCONF)".
>>>>=20
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D4911
>>>>=20
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Ladislav Lhotka 
>>>>=20
>>>> Section: 6.1.3
>>>>=20
>>>> Original Text
>>>> -------------
>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>> character introduces a special character, which depends on the
>>>> character that immediately follows the backslash:
>>>>=20
>>>> \n      new line
>>>> \t      a tab character
>>>> \"      a double quote
>>>> \      a single backslash
>>>>=20
>>>>=20
>>>> Corrected Text
>>>> --------------
>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>> character introduces a special character, which depends on the
>>>> character that immediately follows the backslash:
>>>>=20
>>>> \n      new line
>>>> \t      a tab character
>>>> \"      a double quote
>>>> \      a single backslash
>>>>=20
>>>> The backslash MUST NOT be followed by any other character.
>>>>=20
>>>> Notes
>>>> -----
>>>> The text doesn't state whether other characters may follow the
>>>> backslash, and if yes, what it means. Existing implementations have
>>>> used three approaches:
>>>>=20
>>>> 1. report an error if another character follows the backslash
>>>> 2. keep only the character following the backslash, i.e., for =
example,
>>>> "\x" is the same as "x".
>>>> 3. keep both the backslash and the character following it.
>>>>=20
>>>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly
>>>> adopted option #1. However, many modules are still being written =
using
>>>> YANG version 1.0, so it is important to clarify this issue in RFC =
6020
>>>> as well.
>>>=20
>>> I don't think this errata should be accepted.  As stated, the spec =
is
>>> unclear, and YANG 1.1 has fixed this problem.  But it is not clear
>>> that the original intention when RFC 6020 was written was #1.
>>> Accepting this errata now would make existing implementations and
>>> modules invalid.
>>=20
>> The problem is that the spec is clearly ambiguous
>=20
> Agreed.

Then isn't it an error that needs to be corrected?

>=20
>> and it is
>> impossible to decide whether such a module is valid or not and, if
>> it is, what the other backslash-escaped characters mean. Existing
>> implementations can already reject such modules - the fact that
>> pyang (and probably other tail-f tools) adopted one interpretation
>> doesn't mean that everybody does the same.=20
>=20
> This is exactly my point.

But it means that different tools may give different results, e.g. when =
matching a string against such a pattern.

>=20
>>> The solution moving forward is to use YANG 1.1.
>>>=20
>>=20
>> YANG 1.0 modules continue to be written, and I think it is important
>> to stop this problem from spreading further. I think tools should
>> at least issue a warning because otherwise future upgrades to YANG
>> 1.1 may become a nightmare - modules will suddenly break in
>> unexpected places.
>=20
> Sure, but that's a different story (I already added a warning for this
> in pyang).
>=20
>> If this erratum is rejected, what is the basis for accepting erratum
>> #4909 that started this discussion?
>=20
> That module relied on one interpretation, but as you write, the spec
> is unclear and toold behave differently.  Thus, modules should avoid
> this pattern.
>=20

It might suffice to just warn readers of RFC 6020 that this issue exists =
and should be avoided by using single quotes. Unfortunately, RFC errata =
only seem to support explicit "patches" to the text but not such =
comments.

Lada

>=20
> /martin

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






From nobody Wed Jan 18 09:12:43 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 EBD5E1294C6 for ; Wed, 18 Jan 2017 09:12:42 -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 mRK3v4_WV_ur for ; Wed, 18 Jan 2017 09:12:41 -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 6CD16129426 for ; Wed, 18 Jan 2017 09:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13187; q=dns/txt; s=iport; t=1484759560; x=1485969160; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=u7K3G/mCwrJqCIOScCPLqcSTmj2f8jcsBxNwuYXvE88=; b=E3seVUpXKF0p0FYraClatzLDp305A7M/fYCHlKUCgl4SklGfLZ3YwNhG cmADUdwblp+n+D13BDOYDL3QR3hjg+jXmLmCR1zVJHZhlke7m2GuGMlHW m0xbd1ik9zNsvPvm6mOz6cEG9uxVapBtPO8epMn/+PaUycZb8C1BIoxX7 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAQCDoX9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAX8DgQaNWXKQcR+QAYUrggsfAQyFLEoCgkAYAQIBAQE?= =?us-ascii?q?BAQEBYyiEagEBAwEBAWwbCw44JzAGAQwGAgEBiHcIDrImK4oNAQEBAQEBAQMBA?= =?us-ascii?q?QEBAQEBAQEBAR2GS4IFCIJhii0FjyeGDIYOhl+DF4dsgXdRh2cjhhuKdId7Hzi?= =?us-ascii?q?BFRIIFRU6hjQ9NQEBhkQrghABAQE?=
X-IronPort-AV: E=Sophos;i="5.33,249,1477958400";  d="scan'208,217";a="648911932"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 17:12:36 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0IHCZeg003164; Wed, 18 Jan 2017 17:12:35 GMT
To: Martin Bjorklund , netmod@ietf.org
References: <20170116.164803.729427888661667991.mbj@tail-f.com>
From: Benoit Claise 
Message-ID: 
Date: Wed, 18 Jan 2017 18:12:38 +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: <20170116.164803.729427888661667991.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------3BD4F108162BE894FF2BAF91"
Archived-At: 
Subject: Re: [netmod] example modules in 6087bis
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, 18 Jan 2017 17:12:43 -0000

This is a multi-part message in MIME format.
--------------3BD4F108162BE894FF2BAF91
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Martin,
> Hi,
>
> It turns out that the recommendations on example modules are a bit
> unclear.  Different drafts do very different things.  Some examples:
>
> https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2
>
> This example module really looks like a real module.  It uses an
> IANA-controlled namespace, and the meta-statements indicate that this
> is a normative modules.  But the module does not use the  tags.
>
>
> https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1
>
> This module is better, but it is written to follow RFC 6087 rules
> (pass pyang --ietf), with the result that it contains a bit of "noise"
It takes a lot of YANG experience to be able to distinguish what is 
noise or not.
> with some meaningless descriptions and meta-statements.  It also does
> not use  tags.
>
>
> A good example (IMO) is found in
> https://tools.ietf.org/html/rfc8022#appendix-C
>
> It uses descriptions when necessary (high s/n), no fake
> meta-statements etc.
>
> However, it might be a good idea to require example modules to have a
> "description" statement that explains what the module examplifies.
> For example, the example-rip could have:
>
>    description
>      "This example module demonstrates how the core routing data model
>       can be extended to support a new control-plane protocol.  It is
>       intended as an illustration rather than a real definition of a
>       data model for the Routing Information Protocol (RIP).";
>
>
>
> I think that 6087bis is clear when it says:
>
>    The guidelines in this document refer mainly to a normative complete
>    module or submodule, but may be applicable to example modules and
>    YANG fragments as well.
>
> I think this states that example modules do not have to pass pyang
> --ietf.
>
>
> In order to make this more clear, I suggest the following changes to
> draft-ietf-netmod-rfc6087bis-09
>
> In the Terminology section 2.4:
>
> NEW:
>
>    o  Example module:  A complete YANG module or submodule that is
>       intended to illustrate some specific aspect, but not intended for
>       actual use.
It doesn't solve this issue, because 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09#section-4.2.1 
says:

      The  convention SHOULD be used for complete example
      modules, but not YANG fragments.

That implies to me that we have 3 types:
1. _complete _example modules => I read it that they must pass pyang 
-ietf, SHOULD have 
     If there is , it's because people will want to extract 
it, and play with it. So the tools chain must work
2. the other example modules. No . I guess they don't pass 
pyang
3. YANG fragments. No . I guess they don't pass pyang

In practice, 2 and 3 are the same. So we need just two definition

Scrap "complete" would help but that's not enough:

  The  convention SHOULD be used for example
  modules, but not YANG fragments.

We only need to clarify 3 points
     , yes/no
     pyang, yes/no
     pyang --ietf yes/no

I guess we want, putting all this together:

   o  Example module:  A complete YANG module or submodule that is
      intended to illustrate some specific aspect, but not intended for
      actual use. Example module MUST be valid according to RFC 7950,
      except when they are used to illustrate some illegal constructs.
      Example module MAY be valid according to the rules in this document.

   o  YANG fragment:  A incomplete YANG module or submodule that is
      intended to illustrate some specific aspect, but not intended for
      actual use. YANG fragments MUST be valid according to RFC 7950,
      except when they are used to illustrate some illegal constructs.


  The  convention SHOULD be used for example
  modules that pass validation according to RFC 7950.

  The  convention MUST NOT be used for YANG fragment
  and for example modules that are used to illustrate some illegal constructs
  (therefore failing validation according to RFC 7950).


>
> In section 4:
>
> NEW:
>
>     All normative modules or submodules, example modules or submodules,
>     and example YANG fragments MUST be valid according to RFC 7950,
>     except when they are used to illustrate some illegal constructs.
We wouldn't need this if you take my proposal
>
>
> In Section 4.2.1 "Example Modules":
>
> NEW:
>
>    An example module SHOULD have a namespace on the form
>
>      o  http://example.com/ OR
>      o  urn:example:
>
>    An example module SHOULD have a description statement that describes
>    that it is an example module, and what it examplifies.
>
>    An example module SHOULD NOT have any additional meta-statements
>    (i.e., "organization", "contact", or "reference").
>
>    An example module SHOULD use the "description" statement in any
>    definition where it is required to understand the example.
>
Fine.

Note that the RESTCONF RFC publication depends on this RFC6087bis 
convention. So let's quickly come to a conclusion.

Regards, Benoit
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--------------3BD4F108162BE894FF2BAF91
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Martin, 

    

    

      
Hi,

It turns out that the recommendations on example modules are a bit
unclear.  Different drafts do very different things.  Some examples:

https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2

This example module really looks like a real module.  It uses an
IANA-controlled namespace, and the meta-statements indicate that this
is a normative modules.  But the module does not use the <CODE> tags.


https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1

This module is better, but it is written to follow RFC 6087 rules
(pass pyang --ietf), with the result that it contains a bit of "noise"

    

    It takes a lot of YANG experience to be able to distinguish what is
    noise or not.

    

      
with some meaningless descriptions and meta-statements.  It also does
not use <CODE> tags.


A good example (IMO) is found in
https://tools.ietf.org/html/rfc8022#appendix-C

It uses descriptions when necessary (high s/n), no fake
meta-statements etc.

However, it might be a good idea to require example modules to have a
"description" statement that explains what the module examplifies.
For example, the example-rip could have:

  description
    "This example module demonstrates how the core routing data model
     can be extended to support a new control-plane protocol.  It is
     intended as an illustration rather than a real definition of a
     data model for the Routing Information Protocol (RIP).";



I think that 6087bis is clear when it says:

  The guidelines in this document refer mainly to a normative complete
  module or submodule, but may be applicable to example modules and
  YANG fragments as well.

I think this states that example modules do not have to pass pyang
--ietf.


In order to make this more clear, I suggest the following changes to
draft-ietf-netmod-rfc6087bis-09

In the Terminology section 2.4:

NEW:

  o  Example module:  A complete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use.

    

    It doesn't solve this issue, because
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09#section-4.2.1
    says:

    

      
 The <CODE BEGINS> convention SHOULD be used for complete example
 modules, but not YANG fragments. 

    

    That implies to me that we have 3 types:

    1. complete example modules => I read it that they must
    pass pyang -ietf, SHOULD have <CODE BEGINS>

      If there is <CODE BEGINS>, it's because people will want
    to extract it, and play with it. So the tools chain must work

    2. the other example modules. No <CODE BEGINS>. I guess they
    don't pass pyang

    3. YANG fragments. No <CODE BEGINS>. I guess they don't pass
    pyang

    

    In practice, 2 and 3 are the same. So we need just two definition

    

    Scrap "complete" would help but that's not enough:

    
 The <CODE BEGINS> convention SHOULD be used for example
 modules, but not YANG fragments. 

    We only need to clarify 3 points 

     <CODE BEGINS>, yes/no

     pyang, yes/no

     pyang --ietf yes/no

    

    I guess we want, putting all this together:

    

    
  o  Example module:  A complete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use. Example module MUST be valid according to RFC 7950,
     except when they are used to illustrate some illegal constructs.
     Example module MAY be valid according to the rules in this document.


    
  o  YANG fragment:  A incomplete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use. YANG fragments MUST be valid according to RFC 7950,
     except when they are used to illustrate some illegal constructs.


 The <CODE BEGINS> convention SHOULD be used for example
 modules that pass validation according to RFC 7950.  


    
 The <CODE BEGINS> convention MUST NOT be used for YANG fragment
 and for example modules that are used to illustrate some illegal constructs
 (therefore failing validation according to RFC 7950).

    

    

      

In section 4:

NEW:

   All normative modules or submodules, example modules or submodules,
   and example YANG fragments MUST be valid according to RFC 7950,
   except when they are used to illustrate some illegal constructs.

    

    We wouldn't need this if you take my proposal

    

      


In Section 4.2.1 "Example Modules":

NEW:

  An example module SHOULD have a namespace on the form

    o  http://example.com/<module-name> OR
    o  urn:example:<module-name>

  An example module SHOULD have a description statement that describes
  that it is an example module, and what it examplifies.

  An example module SHOULD NOT have any additional meta-statements
  (i.e., "organization", "contact", or "reference").

  An example module SHOULD use the "description" statement in any
  definition where it is required to understand the example.



    

    Fine.

    

    Note that the RESTCONF RFC publication depends on this RFC6087bis
    convention. So let's quickly come to a conclusion.

    

    Regards, Benoit

    

      


/martin

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



    

    

  


--------------3BD4F108162BE894FF2BAF91--


From nobody Wed Jan 18 10:00: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 0214712954E for ; Wed, 18 Jan 2017 10:00: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 i-uIUkLNP627 for ; Wed, 18 Jan 2017 10:00:25 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 5861012954D for ; Wed, 18 Jan 2017 10:00:25 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id l7so21605027qtd.1 for ; Wed, 18 Jan 2017 10:00:25 -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=zy0+HFKytZ/pm6nsE7lc2bz2EBHLlu58sc4CnTOTH5U=; b=alBUV0DSzeYqWWvb4MbaD7MQdkJk/05seTxAOI81A0fjRjiS84QgTNAu/2JO4PqYq1 fGweJjBA+AaoBybTQQ0sHhd0f/S85HpEpQft7gO02Ua/Gi54+DAnKWVDdlstE89nJgHW FLU8sXLlz80K4pl8yFKd+X0TvqHm3XSPoim5NQ7RZqYf/kCFG5rWqSXlVNnwYKfB8pJx N8k3P9AkXeyFDZGQVXv4m9KL8IdeE+GiDSaHZvwBiMBBbYYAR5BaU1lYgCRTSwlr+PG8 1cB9Iv9Xqvu/AI6iPdYWv6VwV9OSwy02QC7pQ3Z4dv5rB9ClGVFEql0+W/oVD8xaYq9n 5Iew==
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=zy0+HFKytZ/pm6nsE7lc2bz2EBHLlu58sc4CnTOTH5U=; b=PImpd5Aa8/KqP8w6yotV/KhNYtUFo1qegmTJN5KSSQdl5YSLIDS8b0TpSIrTCs3yT2 2PPFCUbVKw2wGgSY/IpuWxfYQh2ru7EusiXJNJdDvM9eMleEmxuUd4nvNjqAQPWfFZ8x 8gQtqn2BVxIpDZRTAV+OJRGCoItwOdeC4nQn+2Kg+6EyldDi6iT7+WV56j9d9PuQghdU CuEvIAVkN+dLnX7vGdjL4zIHusxYvwbnOmq6QWAu8Y79lqqxBfdO43Lr73Qd9cfPU3O2 2xJSFckXIf5NgT11RWiKyErSW+vuIpBQTaAJDQtYpof/lNsKKs1JW5cGs6cFpcZx0uQl qXMQ==
X-Gm-Message-State: AIkVDXJBOITFxHWJ25wN9FwLeAcd5E830bfedSf91GGJFArAoGpl4fn+KDSup5BUrtGUOxpPyZgJkGsQloIERg==
X-Received: by 10.237.59.203 with SMTP id s11mr4234031qte.46.1484762422245; Wed, 18 Jan 2017 10:00:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Wed, 18 Jan 2017 10:00:21 -0800 (PST)
In-Reply-To: 
References: <20170116.164803.729427888661667991.mbj@tail-f.com> 
From: Andy Bierman 
Date: Wed, 18 Jan 2017 10:00:21 -0800
Message-ID: 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=94eb2c1907acc11c03054662306b
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] example modules in 6087bis
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, 18 Jan 2017 18:00:28 -0000

--94eb2c1907acc11c03054662306b
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 18, 2017 at 9:12 AM, Benoit Claise  wrote:

> Martin,
>
> Hi,
>
> It turns out that the recommendations on example modules are a bit
> unclear.  Different drafts do very different things.  Some examples:
> https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2
>
> This example module really looks like a real module.  It uses an
> IANA-controlled namespace, and the meta-statements indicate that this
> is a normative modules.  But the module does not use the  tags.
>
> https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1
>
> This module is better, but it is written to follow RFC 6087 rules
> (pass pyang --ietf), with the result that it contains a bit of "noise"
>
> It takes a lot of YANG experience to be able to distinguish what is noise
> or not.
>

I agree.  I see Martin's point though -- maintenance clauses like contact
and organization
are not really needed for examples.


> with some meaningless descriptions and meta-statements.  It also does
> not use  tags.
>
>
> A good example (IMO) is found inhttps://tools.ietf.org/html/rfc8022#appendix-C
>
> It uses descriptions when necessary (high s/n), no fake
> meta-statements etc.
>
> However, it might be a good idea to require example modules to have a
> "description" statement that explains what the module examplifies.
> For example, the example-rip could have:
>
>   description
>     "This example module demonstrates how the core routing data model
>      can be extended to support a new control-plane protocol.  It is
>      intended as an illustration rather than a real definition of a
>      data model for the Routing Information Protocol (RIP).";
>
>
>
> I think that 6087bis is clear when it says:
>
>   The guidelines in this document refer mainly to a normative complete
>   module or submodule, but may be applicable to example modules and
>   YANG fragments as well.
>
> I think this states that example modules do not have to pass pyang
> --ietf.
>
>
> In order to make this more clear, I suggest the following changes to
> draft-ietf-netmod-rfc6087bis-09
>
> In the Terminology section 2.4:
>
> NEW:
>
>   o  Example module:  A complete YANG module or submodule that is
>      intended to illustrate some specific aspect, but not intended for
>      actual use.
>
> It doesn't solve this issue, because https://tools.ietf.org/html/
> draft-ietf-netmod-rfc6087bis-09#section-4.2.1 says:
>
>  The  convention SHOULD be used for complete example
>  modules, but not YANG fragments.
>
> That implies to me that we have 3 types:
> 1. *complete *example modules => I read it that they must pass pyang
> -ietf, SHOULD have 
>     If there is , it's because people will want to extract
> it, and play with it. So the tools chain must work
> 2. the other example modules. No . I guess they don't pass
> pyang
> 3. YANG fragments. No . I guess they don't pass pyang
>
> In practice, 2 and 3 are the same. So we need just two definition
>
> Scrap "complete" would help but that's not enough:
>
>  The  convention SHOULD be used for example
>  modules, but not YANG fragments.
>
> We only need to clarify 3 points
>     , yes/no
>     pyang, yes/no
>     pyang --ietf yes/no
>
> I guess we want, putting all this together:
>
>   o  Example module:  A complete YANG module or submodule that is
>      intended to illustrate some specific aspect, but not intended for
>      actual use. Example module MUST be valid according to RFC 7950,
>      except when they are used to illustrate some illegal constructs.
>      Example module MAY be valid according to the rules in this document.
>
>   o  YANG fragment:  A incomplete YANG module or submodule that is
>      intended to illustrate some specific aspect, but not intended for
>      actual use. YANG fragments MUST be valid according to RFC 7950,
>      except when they are used to illustrate some illegal constructs.
>
>
This is good
I prefer:
   - MUST use CODE BEGINS for a real module
   - MUST NOT use CODE BEGINS for an example module

   - MUST pass pyang --ietf for a real module
   - MUST pass pyang for example module

I have already received private emails about implementing the
example-jukebox
module in RESTCONF as part of the standard.  We already have operational
experience that people can be confused by the example modules, and
think they are supposed to be implemented for RFC compliance.


>
>  The  convention SHOULD be used for example
>  modules that pass validation according to RFC 7950.
>
>  The  convention MUST NOT be used for YANG fragment
>  and for example modules that are used to illustrate some illegal constructs
>  (therefore failing validation according to RFC 7950).
>
>
>
This text concerns me a little
We are not following the  anywhere for examples.
the tools are extracting anything that starts "module blah".
IMO this makes it easier to confuse real and example modules.
I would prefer to consider only real modules as Code Components.

(We collect broken modules to test the compiler in modules/test/fail folder,
so even bad modules might be extracted.)



In section 4:
>
> NEW:
>
>    All normative modules or submodules, example modules or submodules,
>    and example YANG fragments MUST be valid according to RFC 7950,
>    except when they are used to illustrate some illegal constructs.
>
> We wouldn't need this if you take my proposal
>
> In Section 4.2.1 "Example Modules":
>
> NEW:
>
>   An example module SHOULD have a namespace on the form
>
>     o  http://example.com/ OR
>     o  urn:example:
>
>   An example module SHOULD have a description statement that describes
>   that it is an example module, and what it examplifies.
>
>   An example module SHOULD NOT have any additional meta-statements
>   (i.e., "organization", "contact", or "reference").
>
>   An example module SHOULD use the "description" statement in any
>   definition where it is required to understand the example.
>
>
> Fine.
>
> Note that the RESTCONF RFC publication depends on this RFC6087bis
> convention. So let's quickly come to a conclusion.
>
> Regards, Benoit
>
>

Andy



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

--94eb2c1907acc11c03054662306b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 18, 2017 at 9:12 AM, Benoit Claise <bclaise@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Martin, 

    

    

      
Hi,

It turns out that the recommendations on example modules are a bit
unclear.  Different drafts do very different things.  Some examples:

https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-t=
opology-08#section-6.1.2

This example module really looks like a real module.  It uses an
IANA-controlled namespace, and the meta-statements indicate that this
is a normative modules.  But the module does not use the <CODE> tags.


https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#=
appendix-C.1

This module is better, but it is written to follow RFC 6087 rules
(pass pyang --ietf), with the result that it contains a bit of "noise&=
quot;

    

    It takes a lot of YANG experience to be able to distinguish what is
    noise or not.

I agree.=C2=A0 =
I see Martin's point though -- maintenance clauses like contact and org=
anization
are not really needed for examples.
=C2=A0

    

      
with some meaningless descriptions and meta-statements.  It also=
 does
not use <CODE> tags.


A good example (IMO) is found in
https://tools.ietf.=
org/html/rfc8022#appendix-C

It uses descriptions when necessary (high s/n), no fake
meta-statements etc.

However, it might be a good idea to require example modules to have a
"description" statement that explains what the module examplifies=
.
For example, the example-rip could have:

  description
    "This example module demonstrates how the core routing data model
     can be extended to support a new control-plane protocol.  It is
     intended as an illustration rather than a real definition of a
     data model for the Routing Information Protocol (RIP).";



I think that 6087bis is clear when it says:

  The guidelines in this document refer mainly to a normative complete
  module or submodule, but may be applicable to example modules and
  YANG fragments as well.

I think this states that example modules do not have to pass pyang
--ietf.


In order to make this more clear, I suggest the following changes to
draft-ietf-netmod-rfc6087bis-09

In the Terminology section 2.4:

NEW:

  o  Example module:  A complete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use.

    

    It doesn't solve this issue, because
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-=
09#section-4.2.1
    says:

    

      
 The <CODE BEGINS>=
 convention SHOULD be used for complete example
 modules, but not YANG fragments. 

    

    That implies to me that we have 3 types:

    1. complete example modules =3D> I read it that they must
    pass pyang -ietf, SHOULD have <CODE BEGINS>

    =C2=A0 =C2=A0 If there is <CODE BEGINS>, it's because people =
will want
    to extract it, and play with it. So the tools chain must work

    2. the other example modules. No <CODE BEGINS>. I guess they
    don't pass pyang

    3. YANG fragments. No <CODE BEGINS>. I guess they don't pass
    pyang

    

    In practice, 2 and 3 are the same. So we need just two definition

    

    Scrap "complete" would help but that's not enough:

    
 The <CODE BEGINS> c=
onvention SHOULD be used for example
 modules, but not YANG fragments. 

    We only need to clarify 3 points 

    =C2=A0=C2=A0=C2=A0 <CODE BEGINS>, yes/no

    =C2=A0=C2=A0=C2=A0 pyang, yes/no

    =C2=A0=C2=A0=C2=A0 pyang --ietf yes/no

    

    I guess we want, putting all this together:

    

    
  o  Example module:  A complete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use. Example module MUST be valid according to RFC 7950,
     except when they are used to illustrate some illegal constructs.
     Example module MAY be valid according to the rules in this document.


    
  o  YANG fragment:  A inc=
omplete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use. YANG fragments MUST be valid according to RFC 7950,
     except when they are used to illustrate some illegal constructs.


This is good
I prefe=
r:
=C2=A0 =C2=A0- MUST use CODE BEGINS for a real module
=C2=A0 =C2=A0- MUST NOT use CODE BEGINS for an example module
<=
br>
=C2=A0 =C2=A0- MUST pass pyang --ietf for a real module
=

=C2=A0 =C2=A0- MUST pass pyang for example module

=

I have already received private emails about implementing the example-=
jukebox
module in RESTCONF as part of the standard.=C2=A0 We alre=
ady have operational
experience that people can be confused by th=
e example modules, and
think they are supposed to be implemented =
for RFC compliance.
=C2=A0
 The <CODE BEGINS> convention SHOULD be used for example
 modules that pass validation according to RFC 7950. =20


    
 The <CODE BEGINS> c=
onvention MUST NOT be used for YANG fragment
 and for example modules that are used to illustrate some illegal construct=
s
 (therefore failing validation according to RFC 7950).

    

This text concerns me a litt=
le
We are not following the <CODE BEGINS> anywhere for exam=
ples.
the tools are extracting anything that starts "mod=
ule blah".
IMO this makes it easier to confuse real and exam=
ple modules.
I would prefer to consider only real modules as Code=
 Components.

(We collect broken modules to tes=
t the compiler in modules/test/fail folder,
so even bad modules m=
ight be extracted.)




    

      
In section 4:

NEW:

   All normative modules or submodules, example modules or submodules,
   and example YANG fragments MUST be valid according to RFC 7950,
   except when they are used to illustrate some illegal constructs.

    

    We wouldn't need this if you take my proposal

    

      
In Section 4.2.1 "Example Modules":

NEW:

  An example module SHOULD have a namespace on the form

    o  http://example.com/<module-=
name> OR
    o  urn:example:<module-name>

  An example module SHOULD have a description statement that describes
  that it is an example module, and what it examplifies.

  An example module SHOULD NOT have any additional meta-statements
  (i.e., "organization", "contact", or "reference&=
quot;).

  An example module SHOULD use the "description" statement in any
  definition where it is required to understand the example.



    

    Fine.

    

    Note that the RESTCONF RFC publication depends on this RFC6087bis
    convention. So let's quickly come to a conclusion.

    

    Regards, Benoit

    

      


Andy

=C2=A0
=

/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




--94eb2c1907acc11c03054662306b--


From nobody Wed Jan 18 10:59: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 13F5E12943E for ; Wed, 18 Jan 2017 10:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level: 
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ixXQv68--eSk for ; Wed, 18 Jan 2017 10:59:44 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30521293DA for ; Wed, 18 Jan 2017 10:59:43 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEU03881; Wed, 18 Jan 2017 18:59:39 +0000 (GMT)
Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 18:59:37 +0000
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Wed, 18 Jan 2017 10:57:32 -0800
From: Alexander Clemm 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] notifications
Thread-Index: AQHScY38ls6MI/oqo0u3d7TOTB7WQaE+lFZg
Date: Wed, 18 Jan 2017 18:57:32 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2ED53765@dfweml501-mbb>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.123]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.587FBB1C.0418, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: af00ce66278dd727a8f9a9ec773d89cb
Archived-At: 
Subject: Re: [netmod] notifications
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, 18 Jan 2017 18:59:47 -0000

Hi,

Per an earlier thread, it appeared to be sufficient to define a paragraph i=
n the new RFC which "Updates: RFC 7950", with text that explains how YANG-d=
efined notifications are encoded".  I do agree that conceptually, RFC 7950 =
should not contain dependencies on RFC 5277; short of making updates to RFC=
 7950 itself (not considered feasible) this should be a reasonable option. =
  =20

--- Alex

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Wednesday, January 18, 2017 5:22 AM
To: netmod@ietf.org
Subject: [netmod] notifications

Hi,

if NETCONF WG moves away from RFC 5277, what does it mean for YANG? In my o=
pinion, we have two options:

1. remove references to 5277 from the YANG spec and define a notification
   as any data sent asynchronously by the server, or

2. generalize even more and treat a particular notification as just
   another type of data tree.

BTW, the Terminology section in RFC 7950 doesn't contain a definition of a =
notification (unlike pretty much everything else). Is it just an omission o=
r was it intentional?

Lada

-------------------- Start of forwarded message --------------------
From: "Mehmet Ersue" 
To: "'Netconf'" 
Date: Wed, 18 Jan 2017 00:06:14 +0100
Subject: [Netconf] New Notification and Subscription Features WASFW: 3  Opt=
ions for Subscription & Event Notification draft structure

...

B) NETCONF co-chairs further propose that NETCONF WG should use its energy =
in the future to complete and improve the new notification and subscription=
 RFCs and stop maintaining RFC 5277 for issues other than errata.  Note tha=
t it is required that RFC 5277 and all new work needs to gracefully co-exis=
t in any deployment. =20

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

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


From nobody Wed Jan 18 11:13: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 4CF7E12945C for ; Wed, 18 Jan 2017 11:13:26 -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 iNtgeMqaHxVA for ; Wed, 18 Jan 2017 11:13:25 -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 AD3121293D9 for ; Wed, 18 Jan 2017 11:13:24 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7C6A66D3; Wed, 18 Jan 2017 20:13:23 +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 V-7PB9NoRcz9; Wed, 18 Jan 2017 20:13:21 +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, 18 Jan 2017 20:13:23 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2292B200A3; Wed, 18 Jan 2017 20:13:23 +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 8hA1lKdheqG3; Wed, 18 Jan 2017 20:13:22 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B253B200A5; Wed, 18 Jan 2017 20:13:22 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AA9DB3E2994C; Wed, 18 Jan 2017 20:13:26 +0100 (CET)
Date: Wed, 18 Jan 2017 20:13:26 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20170118191326.GB5811@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: 
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@ietf.org
Subject: Re: [netmod] notifications
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: Wed, 18 Jan 2017 19:13:26 -0000

The only references to RFC 5277 in the YANG 1.1 specification I found
refers to the  element. I do not see anything broken or
worth fixing.

/js

On Wed, Jan 18, 2017 at 02:22:22PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> if NETCONF WG moves away from RFC 5277, what does it mean for YANG? In my
> opinion, we have two options:
> 
> 1. remove references to 5277 from the YANG spec and define a notification
>    as any data sent asynchronously by the server, or
> 
> 2. generalize even more and treat a particular notification as just
>    another type of data tree.
> 
> BTW, the Terminology section in RFC 7950 doesn't contain a definition of
> a notification (unlike pretty much everything else). Is it just an
> omission or was it intentional?
> 
> Lada
> 
> -------------------- Start of forwarded message --------------------
> From: "Mehmet Ersue" 
> To: "'Netconf'" 
> Date: Wed, 18 Jan 2017 00:06:14 +0100
> Subject: [Netconf] New Notification and Subscription Features WASFW: 3
>  Options for Subscription & Event Notification draft structure
> 
> ...
> 
> B) NETCONF co-chairs further propose that NETCONF WG should use its energy
> in the future to complete and improve the new notification and subscription
> RFCs and stop maintaining RFC 5277 for issues other than errata.  Note that
> it is required that RFC 5277 and all new work needs to gracefully co-exist
> in any deployment.  
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Jan 18 11:34: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 85EE912987C for ; Wed, 18 Jan 2017 11:34:03 -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 4SFAlDLlUzIC for ; Wed, 18 Jan 2017 11:34:02 -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 37DF812987A for ; Wed, 18 Jan 2017 11:34:02 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0493A6D1; Wed, 18 Jan 2017 20:34: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 YvJZUOLfXfOW; Wed, 18 Jan 2017 20:33:58 +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, 18 Jan 2017 20:34:00 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E5CA200A5; Wed, 18 Jan 2017 20:34:00 +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 IilSrzM-MNI0; Wed, 18 Jan 2017 20:34:00 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 912F6200A3; Wed, 18 Jan 2017 20:33:59 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 87FE73E29C56; Wed, 18 Jan 2017 20:34:02 +0100 (CET)
Date: Wed, 18 Jan 2017 20:34:02 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20170118193401.GD5811@elstar.local>
Mail-Followup-To: Martin Bjorklund , rfc-editor@rfc-editor.org, netmod@ietf.org, joelja@bogus.com
References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170118.145532.995038902796253716.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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: Wed, 18 Jan 2017 19:34:03 -0000

On Wed, Jan 18, 2017 at 02:55:32PM +0100, Martin Bjorklund wrote:
> 
> I don't think this errata should be accepted.  As stated, the spec is
> unclear, and YANG 1.1 has fixed this problem.  But it is not clear
> that the original intention when RFC 6020 was written was #1.
> Accepting this errata now would make existing implementations and
> modules invalid.
>

+1

And I note that this is inline with the discussions we had when YANG
1.1 was put together. We should not waste cycles rehashing issues.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Jan 18 13:46: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 3CC0E129437 for ; Wed, 18 Jan 2017 13:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 qZ3dgtghvO1r for ; Wed, 18 Jan 2017 13:46:21 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0109.outbound.protection.outlook.com [104.47.37.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5E01294C9 for ; Wed, 18 Jan 2017 13:46:21 -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=w1Pmh+vEXejY61J64642w3sIUv7hWNL4WkqndfCyCUw=; b=fkn7WBiaAYEPhE29MiRFHFi6CGwCpdt1tR0SrFFy33oiMhyrK/Cj0oa7fm8Y3cAmFRctlHOV0jySrmnlHlb7eN7dPONar+z7vzkvEYki9Zn4D6cInwqQYeWDhOX5IyoKqQvybTvtey5zV9ZuA/S0ZqbQSTHDc3ed99anRMu7z4c=
Received: from BLUPR05CA0076.namprd05.prod.outlook.com (10.141.20.46) by BN3PR0501MB1281.namprd05.prod.outlook.com (10.160.183.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:20 +0000
Received: from BN1AFFO11OLC004.protection.gbl (2a01:111:f400:7c10::195) by BLUPR05CA0076.outlook.office365.com (2a01:111:e400:855::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:20 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; rfc-editor.org; dkim=none (message not signed) header.d=none; rfc-editor.org; dmarc=none action=none header.from=juniper.net; 
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11OLC004.mail.protection.outlook.com (10.58.53.75) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:19 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:13:03 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILD1Im013175; Wed, 18 Jan 2017 13:13:02 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0IL8vRB039097; Wed, 18 Jan 2017 16:08:58 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182108.v0IL8vRB039097@idle.juniper.net>
To: RFC Errata System 
In-Reply-To: <20170118114858.62A63B80FFD@rfc-editor.org>
Date: Wed, 18 Jan 2017 16:08:57 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(2980300002)(199003)(189002)(305945005)(1076002)(38730400001)(50466002)(68736007)(106466001)(48376002)(8936002)(86362001)(81166006)(81156014)(50986999)(54356999)(7696004)(54906002)(558084003)(229853002)(6916009)(2810700001)(8276002)(2950100002)(53416004)(8676002)(110136003)(5003940100001)(5660300001)(53936002)(92566002)(626004)(97736004)(7126002)(189998001)(105596002)(76506005)(47776003)(77096006)(2906002)(4326007)(356003)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1281; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC004; 1:fYCFQEjzQAjUNHrgjseF6knsWBRCVqavTgU51H+yzYfT0MJbHcwJn5aLGixeeCHl/lcKI92Urxa618g+JEzTLMfevgFFGbBttohDn5ytQXfmqIjZfwC67tPzaCz529JA40KttL2y8TLmNavB4Q1Ow57TUlD6E+HD8cO52gU/oDP8xX5NopLSsyMAfrje9x9RQIRcAv0/9BsDSAnYKbAAQwXEZ07qBYCXSZBAE5nHt/FZ7Pt9muaMAztRUoUgShYv63fojHkaCpO4+kreYnRfW0wT6v9KyRrEFkWP4mSljek+8F+Gt5vyfe55IQpLsu6J4h/QcDF4DbvXMyGgGPEFS296gANvkm2x4DpN9TN3tOX9CrfxTDfPkQ+37VRa5/DeeCZVMe4d5tCKmSr0pfs0imCmhMGAcDZ3Va8eIIiM8ijqu/x384rrJqPeyQu+9xrYMz0y/G55VLPPuER7rC494ocjbbIcpUYRfeOETbbJCh6KJ8cdbr8UazbbnRswNgJfDkJz6fPRFgOmeagCRxGmzuFEzOHUkUbO8h/6frAQHwU=
X-MS-Office365-Filtering-Correlation-Id: 39433bb5-a569-48e6-7e16-08d43feb708a
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1281; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1281; 3:6SyWzAnq8isfsHFdqx8H6Eheo5mHKPKinSG6CIDcE3j3FwOH0ZZ9pZsqBrMteEASrS90T3+zPQSSiUBlduzVcweTS06QSMDshJXWAzk80fGO4SITMw4vgJe3qEHNSfeKO6FYMNBXU5QPwRWXIhw616nafAis1Kkj44t1CqDK/csbLim2KXzzUA/3LDV+qb4tIjxQ619/Tfod5wcgwvXzx8MW/OVqpcnT3pe4OIXpxDN0KKlswBk7aY/hNJnJYeY5ghTAVQVQyKiR84u0S5jrnnCTVBRcCo4fEMJFmo2AiOtyZY4uWFi9+4T9CE1fnQpIFqxUc9LnHAiSyVHOrIPjNePZu37+wLTfgxtdIyCicS/g+m7YgTSVwQu/qRkfoTzQ; 25:+MyDUnikhIClhMGaI1vmpYOuKZ0oNqmVt+MUOSx2Xm/Ir/3WYhe5Lh0faR8YNDZNktfXcby+FZbeNrjtXWEkcwI61kN47QDQlrHFioFqPVIj8rq/pTrxt2jtCYy9lPuXSjPT7XvegPDIkQeEkU6XuTLEYS5WJVbN/RvKQYLtlwGhOvo+CH739PYCn4BqGHcPFlLk+lXq2VWPUeeOq57uEDFPdnA8tZfuEGQQOh8SFNbZL1WkBWlKM36SVHwaVq6tJM4BIndvd818miHB86GM2piFpHRshNJVxohhmNO2KP2/RbfDR48Whv69i0Y/OjjsSQ4iqC28C+rO4xJEDik2sBuKmXfymFtVN/s7XHgFQdWCKHn9p4mDNojpOByTL+/y93SvWALUxQ+gNuVjTaPl7OU1es8fy0Ae9tH7M/zGC8OtmnrNOMmUkEnelAgYw2eMLqHzmdsAy3SQz4mRMRdgmg==
X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1281; 31:EiPbxpBzCcF6479ZzLAEzFR2q3I4bdYMqMXzxeSv60W2mULc/BJ4+okR2A9YdNq6cSReVj8mNfgDYpm9CNEyOVmuxDccQnOhhJp19355LyRJGJvZIkfu+BuS32AHj3WnLjcgjjg2ku5t7EFkfqAoqzk3HGbbpgebsB6OqaMW0/ZoiCw/7SGNg1oreWHe/QOr9/cEKGILGp+Ne/614cICdyRdfpnD8FlgKOOa0/u9Yf4/YR9SVru0zsMuiwZTcH+07JFAxlBQWg3GWKK5voaU2A==; 20:pFNh+dmhCsvxxiBnKAt5e/gODfR0xKfp3IqBO6TnCHcpRyLdNCu5pn18jNl/tlEo8bLOKzYQQ7sfaIuknzg8GITAvy08XDoHUv8C3Gt1+wQSi3CR7vDxjJUaZwNgOhv1g93FtX71qdpYioMm0bxeDWil0hG6z02Hkl8Lj/ilnHykexcjFiPFZHN6lfYOIIfePBv0Y2PoOqd2cBOd2VUYWe73SlT4rlZ+Q5IH6bwgk/m0gejuRmgPyJeF3eW4gAxxAstNMGnhVXhFQaSLD8zNiTnhfi8DLWKFTKjclXgqWgtqP5b3jYcCEs00/4JAHgIdmLp26mNyJEZUBs/WbWJRTjLkDgFbVxguxIUziI93jGKnJ3LyBTDzkgWxzTQ9Ys6SHm7OXo56Cj+/i3zK1PQHvZHvi2qgsl46xRDhxLb4ngtEyHl/pAWVqRBY5UYstowdMaQqBF5atZVEzZxUolHT+4MVxOSdOKWkse2SdUs9zyq0CMUQnaeJpcWIiGTkj6ze
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)(13017025)(13023025)(13024025)(13015025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1281; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1281; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1281; 4:zrWRo4wpBjbza3L90y+eEulEiagm5l6rbBzhMXd6HxOfXF3BC0GnSmTPLlS9wjkm323JtK4CH4LMhFvmYD/o7XVMDTJipyPRtHyDeQNHKddxb5I9ySkHrEoU0JNgQoeet3Biocurmbu/cKe+EnhCWEDBukL6Hadm/s7YGz1jZaXCs6U4unCWrHbpf5QSHzl2eVm/LD8pdNQ0gNXtG6YpIxYtHA4keKfoDDXPsaMSuzvi/FTHF4eYmdroxefnBmgjKbgvQlYzcMD6v++2nm2f47TrMmJCX03lWGQ4oFy1T3MzfhBTlV0WP8S4BOInvdgAhcJ9pFZCwWa7rXgzmehM2KSMISWXrIMOHejFThz8YHr17S5xMAXLwtdU3sUK6msjaX6bHWdt6pwF6n5blFM/kQVkoTEHmZq4HTOpeOweNcesGPc6+GnCYPVb34IQ9/eA6bdm9tnGodmy7O/hOeZsZf3Y8MGFsHIZb5Cuzyl2tfmLr2erJuVfSy+NuQtK2lB6zcWVP3KqDxEh1N8cy9IKQUBCc1tu3mEnwpdctHzfucHZoC3ROTF2rouTW4oBCm6gMb5mcOdjNf5nlk5Gf+bzJWkFU/MrYMKUM4wh/F8d16u77MAEV/TEHCnXVT1cVatGQdiEp+/XDrIC5QKfd47vu2cFf09Sp05U2qjRiLd8dovhSRqxxJZ07vPzUPWq/1Ti
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1281; 23:JqAaNhydKkDY4P4zlWgPyR98gKxineXUeET3nkA?= =?us-ascii?Q?caRBZIkPSytQl1hLPd20oZ6//LTRhggx59CXLMdO0/Emg5EWL5RyKyDwgINO?= =?us-ascii?Q?rqBlSlonojiHsZXFTOlfToE7akyAVQkLF4Tb4zlMM51hdAzpvu4a1CXY9pBv?= =?us-ascii?Q?R+vhA4qie3EO4tQIW046SQdGnMZ7uqmgZuqZK4P9etE4bEaK+AV+YOJ7r1pp?= =?us-ascii?Q?yOYNyRp8NspZqSPrxWia5g8xYGmgIzBPFLkJX8WEenTV11XFJuP3oeY+JBND?= =?us-ascii?Q?xmRcE1EeExWNbECwtO15UJsRfGej1YTXQ41U7/nrevUgfZ4ZUOf/k016XJ5s?= =?us-ascii?Q?rdej4dFs3RHpYgCopMXk2kgQNL10EtV+7Td7L6MbC0yNijwR1xEkKyjQVzQ+?= =?us-ascii?Q?3ZCgu0n4Xc88TjNOk7G1oOyrKoQMIL1UwrVomps2kBGte/8dpjYvqeaRPAZQ?= =?us-ascii?Q?elLhi+9sWuYpt5+C1FgAZVRThi1QABpAc1qAWaT0H3WnaW6t+6Grz/v4b46f?= =?us-ascii?Q?1wXSqMSBoZOXHgwGzT3mJRNuvcAzIvJbdxwOxNWVPoEOGV9VbOdklVdAYslF?= =?us-ascii?Q?0oRImZGfC8QV1x+TkW2JGd57XN3MuKkIR8cwRG5U5GuXm4VbVKoh00SPxgn0?= =?us-ascii?Q?iMRQVYcvLNFQDCOruFE4k69Cih9N/BYhF2jsRfXI01zJYyn059FpFqJHfLqZ?= =?us-ascii?Q?lSz43q67Py6VjDzO1XeVYZRpsoxGDZCtc97C/HnJaoT4VS3Cbftousw5t5f4?= =?us-ascii?Q?SYDMkmcskKZ3g8lnDKnSN0PIcK/DLojARm7kdbtMz5hH984O8tUcV8/pnuAk?= =?us-ascii?Q?UnSLkRBhn+SkaNhA2RfKvDChIVeBiH5Dv0gfnYkRfv3Zg3Z+7s/XM+loMZRI?= =?us-ascii?Q?r6HBF4YNyv9nzVV5wZgyn5H9dfXUg0Y6xN1k1nF1KAaGr8YFsok7VNkWNgte?= =?us-ascii?Q?M1573qwJ2QMLuvpbMoM8RDg3+b89JRgufBN+LBhbnk8zGD4Ir/EpE6W0cNP5?= =?us-ascii?Q?dl4HAcTDSNwx8fmWXTKNlpkCCM+iiOTa0h953At/HrdlaO1YnoZMi0t7GEmi?= =?us-ascii?Q?goVpLkIeO2ADlN5Mh+JbAWMmeAeH+5ymQ1bg+FfidpDeW5yHaQ/qizuPZx6D?= =?us-ascii?Q?bL36XWdn3xp2AQ+zzBRcm4n/0EkUqYbJC03uG95e4l9am1EpKIPvm8rpzKUs?= =?us-ascii?Q?OGSNq0FduUEPvQFhY0lvzp0BDpwqhKJRL1/RtwVE8dQYhjpWr1JHJF35RnA?= =?us-ascii?Q?=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1281; 6:RZtMjtubjxCB4rfdZSmt4PYgOL7kP2SCwyBNqq/XJ4xIG8R7qFhV4NlTSlvuYDbLDO+6KJfkKndSz93HfsYkt0BMsZf4Qp1HyIwxgSM1jR3p8xbVEKqEwTmcdWH/4gmzvsAWTT2j6K4ttBt54cVLHioq39eh4GEf+w9/g+u1LVl0Sa4nViRYcemV1ruj3c4+gOJlcoVLm63pg3yDrE95nMnKeLbDdh09LOKfpxTs+5gZbbKb9E5EhWfs4YhEz1Sv5+Fj+9QX+wKNXdW1L5rgoDTiuvi1qTEuSDE9n+mCs7dTj5A5Zx3KDaCPXf8YbLPN/gEHJGjaAHFiC7YVe+ahkfK7yk05ukjOT9UKLwXOiYcdHihxaZU4I3Zrponc4YFbX/SQ4vp3XlEY9fB169VSEoWqQcwAku5XIjNWx9zP7BXFtR6arNBH8nQhF9iE3nGaDVNSjFUYvRx1jeRuZ6DkXw==; 5:yjXxeL6qsyIpDg1aJhL6la85ZNd7BNj0ejnLYpm7Jq84OQumxp3rM0L/xKKp38EGF+jqhdlqRhFNdw5XVryMUANvfasbmULIQ5RqciFUia+3v1nmG+DZjcF8PUVEpYCZa+rbdtw4K86XZlukksK34w==; 24:j1e7T/cxORgjKX/S/tMmqP4iTGAt0+Y2P19t7Hhx8pJAs9XfJHoNsZnc2ZkgeAIRbZLjUrlvXNkrg4/zNbUPS2Hh6qN8gWXg5KR5QoOTalQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1281; 7:8hyYoc7LA85moEbBN3YBX7BiUacu5N+ics5ijXqe9QQsv+OnKQ8uJkseTEh+QFzam/Egz6RVeLVbkhFBFfx3hSvYAd4uZ30HW/oj09SUf2S60Zdo1XLvYuGkfR6oT/4wOVmJVlHPZxuiao6npv/c5KOg5UtUJIDJivD05MtTtHJURvwxHNSwXWVSieuwYa4E0AabvAF8/Jw4yurBTvZLCG/utLaHmVXrqstXrMBJX2jKnO3T+dpFH03Y3+zU75/fYXO3EHsJh8izqtm04ysXTN/0PBKD7TfqOSEZ2Ac9dxXORwYWMPZbA/mD/t2SUdGBR6Vgc9prRpqWFABNoEQyIediM+BPAuxWhZoa5/y70NtVqAL8RhPX2fl5rcHKKjdV8vGPEd0gPxbF8dEc+7OaHT97yABMe9gAFtVeKjNa4Azq1zt3Fo36IUfDR+p8oasmhIoGhAfmjqDsNbnFtkyaCQ==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:19.7675 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1281
Archived-At: 
Cc: netmod@ietf.org, joelja@bogus.com
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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, 18 Jan 2017 21:46:23 -0000

RFC Errata System writes:
> \      a single backslash

Why isn't this "\\" like the other data ("\n")?

>The backslash MUST NOT be followed by any other character.

Seems reasonable.

Thanks,
 Phil


From nobody Wed Jan 18 13:46:44 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 55C731294C9; Wed, 18 Jan 2017 13:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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 xNaKCmO7z2EX; Wed, 18 Jan 2017 13:46:42 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0122.outbound.protection.outlook.com [104.47.33.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E9D1294E6; Wed, 18 Jan 2017 13:46:41 -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=iW6jsQv4C5pzHT4vE7S7e/Ocaj+fUApSPpq9dOHJ9uc=; b=HcZBdGyIHwfbt/tRReaI3rguPcvGQU3HsvOu10qVBrdReKI3r1/5Y/ROA4n0pOUgFO0qN6EinYyjeXpiHFF+YvDwaNCPnOrFof3vwpouW748i1NxP+pgWCfDBBb8ixPLGDY1lmQZg6HCwR85VjgdCMbbZQm++Gm8DU2eP9CDO9g=
Received: from BY2PR05CA026.namprd05.prod.outlook.com (10.141.250.16) by CY1PR0501MB1292.namprd05.prod.outlook.com (10.160.225.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:38 +0000
Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::142) by BY2PR05CA026.outlook.office365.com (2a01:111:e400:2c5f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:37 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:36 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:24:41 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILOeQ6015351; Wed, 18 Jan 2017 13:24:41 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILKbOB039223; Wed, 18 Jan 2017 16:20:38 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182120.v0ILKbOB039223@idle.juniper.net>
To: Juergen Schoenwaelder 
In-Reply-To: <20170113085137.GA23063@elstar.local>
Date: Wed, 18 Jan 2017 16:20:37 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(2980300002)(199003)(189002)(626004)(6916009)(8936002)(54906002)(2950100002)(2810700001)(1076002)(7696004)(38730400001)(110136003)(229853002)(5660300001)(48376002)(47776003)(81166006)(8676002)(81156014)(50466002)(86362001)(189998001)(77096006)(2906002)(92566002)(8276002)(69596002)(5003940100001)(4326007)(50986999)(54356999)(97736004)(106466001)(105596002)(53936002)(7126002)(53416004)(305945005)(356003)(76506005)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1292; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD032; 1:inCefVsGkLhwVsRow2xJzZ2HJvEkXfD0CIgSYuvZKHNRZ409nMk5dAj/Y9gwgvkCvlaIdMM5X7UPJ2ZBeSpawaXVsKYBGMo7AkYerzul2DiFSU0NZJLxes0sMDCI6o1PjzISazmBxTVGFWi3OE1oM7I8qTSGuCSTD6g1DWMbDCDJHGfpFGDIdwyRe3eV0BFzzps62wQf/+fB28bSNoVnMIljxXfxKJIBTOTewUPTrV6VFVUgntvqVK/cNb+XndBeiyJwPQVf5T4YVqgeFpJKrt814BCno+BKdR8JxwD8EzuB4zXrKjidlmS7uKqD3qQYsp3y7T2Xq+hNdsGtX8FB6kGsIylCeN74r+S3kE36J42GJGAKsACoLhfZVdRBhztHLUS0EOiZ7W9n6ckULnhJ9Wjq9znOSVueRqZ4ZrbJKgOPHCBIBOORilEYB/31bx7CQFKowTbfMcr68izTzfsXnIN22bxHJGPFtX8EwlN3CphHUE58b1DPBYwlKthBKLoOHKpYqCT18SJg+xrJTaiKqhP5ApZlsyYyDbTiWiDiN12aVIeyjG85wzIQlJ7v0dr2
X-MS-Office365-Filtering-Correlation-Id: 61983c56-bf0f-4799-d46a-08d43feb7a8b
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1292; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 3:A04Iqfc/CrHm03sMDVGK6p7Wjb8WO8tphQislLMe+/K6gcX/jlbVHexUHNQg7wDcHL+oF+AzjdcmvnR+BX4es2sm77mILgzpY8ou/n+Dd/0td/SRjFMxzJ6bllVwqXS28yqhzdkhzOIjA4hmJQtmFNnEI2sxlySzD38UvvxUpX+T2lILQZgorkagAq5pgcMsXNBlo4Gz5AtgzbU5R+iW3E+BEs65vFsFTn6XsSbpfKS8dCP76M3i1LAXvQnEUGBB4Ou5uqITVpTcgBMaPbHp9ZWlFAPnvL5PqkBGD9nKXfiE9BxfA7cMxr+zAjkySauQDtac8G8mSy34SSarZv/52/plHNlnbRDmXMFFOWrYacI0385qoY+gAnL8g+jXLzJZ
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 25:qHkkFLYE4RwOIm8IyjKQGW0I/9jPG7pidR5mEve8I2J49ja1oYXJazy7sWHav+6S+uGfSCzYiX0UTtciO+yWEKNoDsqm+/TNsQWSFQQZ2tbx2fVXcEfDQ2xQysEAfq/wV46GeiCslodXGrtiDOAkn08ij2gaXzMSVDAL5Vt4DHqKHWOvPOAeY6Nbakt2evS/CBDoFkcd2wwrPzy70Slh0oVUoFR6kfB3b3w2I2PLNMCpTxWw+oPVYgneZypfETi92hI1iQ1AMQbgjls2PhxVF6GsfXy9pYZM6JSZTpgSq199F66aLqVshqXiomkpPnpobAYBQq/nnRgJWNTkdN+sViiYWvPEqTvOSuUPFfa8Vb/QPRlHxm1v4LAYTohQTLPSzI6g82vvmZVri13W8dEXxwSmzpbgLVri3VtXytmb9EdXJjqo4baUsn3lrXykGRhaD8lw5GwcazTnTUpM74U13IVBcMWETX7rN7y6bdxA6AMKme2UY1tvrwNzkZBoRujvDtECJMr19+ND5alYAGGPrnriRwMmEN7WTUhPnSfJJoBlCac9ReZpJdrT2KXv5kmi1IM/PKykbV5n+7/yg1VS0KUHbhb5PRYAmP8IIlrjDAueX7/iVAxeCOJTPGuLrgGtHmY5KFZ+1kgy3gUhEFYEQZCi7Wp7I06/kg/XnwOGBZdpMJoX075Sou3KmGMShHjPracl/6c2AHlUao3Sm8agYZGKA9+o9QfR6u+PyWv/08jD6pDLNrQCpE4ns4xEOeyw+zesXkf/cwkjqArlqR4PbqktE4wlwdfk5Hr+xXzIsFo=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 31:2Y2A5dLcSvfYdJcEuPO0d4ry+xk+qQuWzlU/O6jNZe/P0wROdeKBqoRZpTKFTRWVZp8Prm6ndeJLItH9yeh3UlT5ux07zPoV7N5DSp9qfiMfBo1g/m55k86CrEcMODIZ8TjAQR9/bKV2B2wk4E3sFgtxo+H9/sqXiNeVQZBuSqhzxrD5ol5LiZWpzmmui9TBUMXd2h8t5xM9fQrvwK6YCSNadSTjpKkAOj0DzgdjyetFNP+MM1oQtHyhpl1JVbbVOegnL3l9RcJU9I0K9DyKwA==; 20:OfkztcBhvasZi7+u8Tw+T6LMflz3NTbfwlpiyKL2gF6P2CfWchGk1c2YpC9QQgYeszo9Ez8LIVCQEpksKn1H6/EBOPtULVWkgy7mHDGIsX/qh5BpAuerZHAB/azmN5XS5kUiPY4XbXFu9E1lDfyTwvSb0NDfHdHosphngF1jWmpcXWvsGAfG9PBwPMtPoc5wRlLdTMneEngS4uOZDDf5I3sH+T5X7LA5GXUuuDNRtShgRzLLGtWq0kNMPOTxDKHU/PSd7vmABxmGNadkYAME803cCLzqQk9hEVbDZioI+GoRsk+DL59XH+IeiTwFKgIEG0qL3MKlZaHZat7cjWtbVj2PLlDzHH0IZI5CfdQ34Ozz1HVuopzIJFcD8EPIn0TDAAikFRMoX8zmryKGOvVgn2wUDGT7IMe5aceaEF5DxK2Efp0LZjpUPZlBuL28PcI5DfWFPlJkyY6tkVwOfbsbP+sMZwollMjTnnN33jFLf41QuMbStvmQnC529YwZCUmO
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(211171220733660);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(13017025)(13023025)(13024025)(13015025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR0501MB1292; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1292; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 4:aSw0oVfq5J+Edaf1NHbiK1Tw2xY+cvp7vjKFfxFIdZldRoffEtqYlzDDTgjojhDJtrEDT7EnWnBQsUErTImKARp/P2e2BEyGOM6z0YWrrfkag9f4St0bSIecIFNLMVV5jCA6ShcTiQ6oSnKlNyKni1hXLZDRhCCBWhVdKNB92E498bFhDsjSZqqw8jmt6vjCSjZZ+6bq1eDmUz5HoKl8S9Fbee7F26i8xG9akpWLl6PqxRpxgXrzvxXljybxTJjDGVDUhCi9xiSQlW0Kw5fIL4ahQmpA0ZtWO2dLTD6cEFQbXp8Z4yGC/cQQ6R0EYPzUQt/MzGCnDBsh0c5PuScf8metka9na9vCdSMOg9jSXXZwrLEtF6kJzWkatdfz5ik76ksDzt/KPklhXoH7ucNc9GVcVrbipQPUUTkxaQ+jfOAFKGDR2IJzZYRHhikbSwXlViBOuBwuavJbyiYNb7Cu6AoNufCzagMVLzxA7v89yu+r225LO04w1bABy3mJPhiX3mNA3pD0y2Fog4wnrFTCrOMFaFRaxYKBOs78dADUBGAQc/BjaNCHTnsN4ZhwtPEFmbv26coIWoPlexJTcPycViozrOJEE8JiZ9FddMZmNhdeK8NGtrfrSi0yvuqhUbM107zyDR05AY1F5750oWT118Eew1C2Jz6pNDFcUeW2nglWSp/mj9M+T4oYcZR+53hGTcfxFAP3cY7HzbG9atZ9u/SWgiwL/dkEHywLlGWI63wdEusAPZ15Q030Ej4bR8qp
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1292; 23:xJ3XjSavUXr2zREsYayeTQJhHRt0UTbNOKfns4w?= =?us-ascii?Q?6BA35BybdwUJ15kx0lKht4PPLhWQKDZsX9c4P16YmmeK599Pdz24T6do51ti?= =?us-ascii?Q?xXaJ5c6ceSQdkIYqsJ5mmtNPteouRlAkjHPejiADX9J7EtWX5wZBTJ09Bcc5?= =?us-ascii?Q?e6pVy7e8YG/AtlYOMSuy4nE7pPV/NnO5IybyRujmlvKiJWUp2NOiqft/kDCa?= =?us-ascii?Q?SUwoBRJx5sTmF6IUK2Lm+yBhGLf1pLe3Bq5exnKi5B0HVUQZJ4g5r951fUq2?= =?us-ascii?Q?tDJTKdLCdhOKafEqSUmNiP56XfFUT/RM+ozp4RdJOTv9qMeg6DJpTCvcsorO?= =?us-ascii?Q?BwmwU/Mofwb9YQZf3Lemf0vtA5aeG9sOWsW0teoeu+5lTon46flTH3ZIfkU6?= =?us-ascii?Q?BVXruZxOJTYDVlREzLNnZkYWOkM/f8NtKPnBMxgAkfrMdLiYBTNbhF2zyYTp?= =?us-ascii?Q?HQM7+ulKZxuBw7qN95JYfQ/RNP4t5FGKuGH1zx8wz4/mj9nZ065xIOelL5Qp?= =?us-ascii?Q?uqKJKYwFE7RXzeEqHd73cJY6uYD02kLBahF+DTxDqONAU5jZnbgEV/gBnbnA?= =?us-ascii?Q?q5sIis/oFTQdFjhLJrtLeVeIrdJUSph4QsOQzZtZWHfFwNy45xxgWQQmLz42?= =?us-ascii?Q?fFjFHAD78/7mppBN/mj/5PFD91vA5jPWPi5y837f0pkKomB6Z40+UtpqaSg7?= =?us-ascii?Q?nLe6fb+ujd4S5+tOuYyAryOrGlz3faeOv+AyiPNzHhUfphXPK8J8h0dlH+wC?= =?us-ascii?Q?HAXmTGzSZZ5b2a2Q/s6VNEaePvYf0HwstIQ4fEhXUyuOFraNl6aFoaMT/6Gj?= =?us-ascii?Q?3gj9Ni6bFEhmTLTJnL0vUEtOog8LLdHLsWgVXEa/dB26Q49gkkHhE8CkSRY1?= =?us-ascii?Q?CvwahoiK64TRGqwvsafmPf/S2hcCKDjRqozlQnK5l4nKC0u4vMzWhNC555JY?= =?us-ascii?Q?tzet8JW/0GYOftsKePjnmByRj9XwmVL28yiIVGTNOZhIlolc1bpPTAln4QAC?= =?us-ascii?Q?nPS9eHCxnzNzoe4A/1za/VxKXAdjzTaQScb53rS+z6pUCufhA4Gj+6ZCPXPg?= =?us-ascii?Q?Bgv+k/IX7EmHV1E0X3U6hkOYHG2gxI1gtN9QgpiN2IvIXnzBWSwIGxQ1QnBM?= =?us-ascii?Q?FydpFU70V2WUBzBfQErf8hFVD2AGPg0/3+xTMn7Xxqbp8OCIvbIn9V4eidOc?= =?us-ascii?Q?jrAO5HOwTKZMi303ztgVYPZJQRRjp/dlGcmsC?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 6:2mT/mdqn5s6dq/6irz7x8Wv5HyskWSRgJYWC5d1WqHAye/N3wgG6iPbofjHe2SZWnbFh9Xvc3VFDLRwqQ55l59WkRB2cWeCaBzwyhQnh1Lr3bDpD56QGvNcBoz9+4ibYDk03+56czPO9hb0zgZgE/6zXlVnRwWgYr7z9rw0lUlSOnK5jYYkEfpLwfIeCHtVog2BAuowpn2vEp6tRZSlq0AEYFIBW9v1/K8DVgpK4QkZzsOa4N+5o6wq0TouT/YdsCVA+BCXMV857Fg28N1DEoTRvt2HBnhtlbFA7LyQZmBWOo3MWpOlYCJeFUGXLkxghJivDG4CgAog0EYqTq4+AZfgdDIO+Av3X1rEA4H4ieXzK8QNbiWP7Xv/qrbokhO1+hAc70tnGyVEB+tYhP4TjZ6hrSbhZUTNb1jvGlp98az3++BCUebrmyo0QjHW/X+gOic4T2NBpwp8XQDlaqzQ/yQ==; 5:II4/RuPq59y8rE9RwUzrYGx+g3PS48ms5KdZLVkCz6vrXNvPd1LYzPo4zvOQD3Clni7qbPjnRywdVSeM16aKDPnfK7AjJUA/2lMiGjHB4FFa8zYkWbLbT5+45AnigATc2hyIt8E5bAGdvYgAmQlU6A==; 24:srrBZUAeUowpSLpf3EjMO7aGjirOca0RN1TO4TPoy9fo3nwXMaK/SjXVDbIfgmWuQeuys/puKw4H0HX0dx75Xz40yCMKuCg6dDb1EUy12lE=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 7:Oc5ou5TNK0FPZs2SUZ5sBuXreK2RqITmkPIhv0TW63RXcux71VaZQ/GK7VR6x+KIpjbHixaAD2SihJGbA4nj41x1I6liQm8yhyAqIEt1JwlE3GAcLHEUrxZSqrF4/iDwwy3uxrZPTkqA3NDWPbfrLWV3AkHHnguT30kSQ4FcWiP6x8dfUDX9WYFZMVUp6E+B+ggz+JiDpeVC5Ck0ab0WZRw9u7/tre37Fm+OIS5GVYd9F0iNwWW/sReTSU+sKHGJgZ/XkGbt7vFYKm4sgvkwP6aYaMYsXabJshrauPCMAiYdMh4f8A6IMc3Gl1MDpFaHklrX5gAKn/oKH2mibFOSy+3P9WqZ3v9Fi/O5OcSaVKInXhpC7klIOTgUwLKURPkiRAZkkGJvYTyT/VjbRCyOp38ep1Wa+IvtEyK+w56nOHO5ugGQ6SoxV6DK/2JNj2PHnrsjmUHRas+9udRVsdMTag==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:36.8343 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1292
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: Wed, 18 Jan 2017 21:46:43 -0000

Juergen Schoenwaelder writes:
>For operational state data, it is not entirely clear where and when
>validation will occur or if it will occur at all. In fact, if a system
>is in a weird state, it might actually be useful for certain purposes
>to expose the weird state. And, as Martin pointed out, inconsistencies
>may also result from the technical difficulties to take a consistent
>snapshort of a system with several concurrent subsystems. For these
>reasons, the assumption that a server always returns valid operational
>state data is likely not true.

Amen.  It's more important to give data values that are accurate than
to give values that can be validated.  The client wants to see what's
going on right now; raw, real, and not sugar coated.

Consider the case where a list is limited to 1000 entries, but as
the device is reporting the list, entries are being created and
deleted.  The result may be that more than 1000 entries are emitted.
But we would not want the device to be forced to stop at 1000 just
to avoid breaking the constraints of the data model.

The client should be prepared to handle operational data that does
not conform to the constraints of the data model.  Or more exactly,
we should be describing the constraints that may be violated and
example scenarios where it might occur.   Some constraints (identifiers)
should never be violated.

Thanks,
 Phil


From nobody Wed Jan 18 13:46:51 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 595731294E6; Wed, 18 Jan 2017 13:46:45 -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 1j-LqyD13p5V; Wed, 18 Jan 2017 13:46:44 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAB6129485; Wed, 18 Jan 2017 13:46:44 -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=UF0Qa8l2HiHRV3r4cXfMf2Xio4BKWMti1KdQ9NE0kZE=; b=FWvViPYgvvVo/H3/Y4VJYXnVSiKsnWiDlIHocqoAPX02Vwxw3OCoRwJzlWZsiSQ8eqcSJPMVZ1/ylL3zmLwAAPYDRwB8Ywq00DmhFMCmos8dVpK2nkA++7zfwDM25A++/eyqmrLt3ED6y3+3n9iPZE2JwMG6r3DZGOs8xS3Nbqs=
Received: from BY2PR05CA025.namprd05.prod.outlook.com (10.141.250.15) by DM5PR05MB2937.namprd05.prod.outlook.com (10.168.176.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:42 +0000
Received: from BN1AFFO11OLC003.protection.gbl (2a01:111:f400:7c10::105) by BY2PR05CA025.outlook.office365.com (2a01:111:e400:2c5f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:41 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11OLC003.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:41 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:27:27 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILRQq6015814; Wed, 18 Jan 2017 13:27:26 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILNMdm039284; Wed, 18 Jan 2017 16:23:23 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182123.v0ILNMdm039284@idle.juniper.net>
To: Ladislav Lhotka 
In-Reply-To: <9A8B650F-E224-42FC-8987-FBF15CA4D614@nic.cz>
Date: Wed, 18 Jan 2017 16:23:22 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39410400002)(39850400002)(39450400003)(39840400002)(2980300002)(199003)(189002)(106466001)(50466002)(105596002)(50986999)(81166006)(8676002)(77096006)(1076002)(48376002)(229853002)(8936002)(38730400001)(97736004)(626004)(7126002)(76506005)(5003940100001)(4326007)(92566002)(68736007)(54356999)(53416004)(305945005)(86362001)(81156014)(47776003)(5660300001)(54906002)(69596002)(189998001)(110136003)(356003)(8276002)(2950100002)(6916009)(7696004)(2810700001)(53936002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2937; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC003; 1:AuHzWw98UVvI8UPwr3uMSRpxGN+InXVBwJ2bI4BW0a2dXIaAPn9ypet3b6PnfpgnQ9Z9kE4UE3sbedvRsEi+FNdtOk6nRcoXOSJUP4NYhATuWS6kN9JcjpJmZePZ9AQWaKv22p+a4mM3NKBykiERUO3TtGVey+gwBy+lAERjpkkBacEV0pijLXXBqIcBHDrUMSK5tGijhFhSLMJWU0VCaV7KQd34wtwzFK3ARxtI0yMpVOYnuAznwybPH/UWOnUBSGjbRf/cZYoVxnCRz63N543IlJfrkSBQOoHrUS4sVfsK6NW+PQhfejN5IzST253whCfqUc0Jfo7pk9AGQpBCHFNS2dVOxe/s3Lx2MQA4kHehFivwZeXr2iXlsijWKjfQcyV7HHDaONlwS9Qo11tZcvcDsRTAFN++I8I8pI6KgvxYwzf3WdgktCvSET5x9d5dK8QLTJo6TszojTxAFiozdDKhY/9/9en+09DN6UMO6JdA3HJ3lBIdzcIdQOdSLa+OoIqLilBFlne2+MhE6hM1rcGxGxs4J26TcNEwMd4Eioi7zGA7CFq3aSGhooPUdOL3
X-MS-Office365-Filtering-Correlation-Id: c3ebe50f-120a-431f-f455-08d43feb7d58
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR05MB2937;
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 3:RForVYdLJ1qlrW2e7jXL6HTBSAhfXgw7Myn11ZQ8Lbu8BQGmzZFtpu7U+9UwF3sod8UafKveTRJRYOqhdLcjkZn18hNxm5H9iGqeZ9Coo/UWPtiAYdn2I2CwQ0L4L/+r9YcSQ2DfaEWXOLt9BNU6PgpaU+sJZb2BVLn1qhbPcsT/dHuqmNZ8VDkqNWzZNiIgkt9uoneC/GsAKJmBq/m8as8d/pAR+jwxI34kadMQohlNTZhCh9tN9KV3nE9H0beAGK/SHOeSw8sQl6LRc9SKr3b1kqRVALJxg0liRkQqMGve5TgcVDAvOqFzCxOFu+EGFUPyEinQemBJ1iQfEGKKV2bHYwn+jK6GVWacs6tqa3QxHcYW9lBy3Nj43UO1micJ; 25:mho7XZdai7/wWeHkP1Xga/71thQlNjd5HHqHT2X3ukSs5Slsfwfus+YEj0kBlth1Dr+H0qQ6VSRDK7rrRXU01qc2jzAlIZ2H6T1S+An67zfnjLwTnUy9eGeP0JaiAdNEn1EhqBFnWMOE4WfLStzcryNktXwr1LqXjtNAQkB9FYJWiH2/nTy92hRTXuen6YlryXATEVRTxgNP6WSyQiUDfpZ/SCAuhnG0OP7yNtA8/U1xDlcm3/jMyjDs/zCcnUSeV8MgcWZYW0yJwWZIcfdWZSS2SAO6DmE3p650gYuEqgHE6Dfa+Z4/c9vTr3yl4BZDUl9HMMb0PkmnKIUOcpnN37KyDuqAiwAdEO5sovQyfeGQ65OT9WirSNJQCa3Hmq1sHw8Mdlf7eFbKEDn7W2pfMGD+9wfPnImgdSqyvKfY8+dChPNCoNpak4toPkOQE+g2hjPkXqQyAvVpoLrMn/2gVA==
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 31:bofFXnuVwQz1TmS64ca/iaxNtXMqQSyFX9BIe+IennD3+a3XrHQn08+PK2dDW7z5rLo6KBRvBEW1C+xGjoqoSSdkmTeUM5Kg7wx0kvXG5pMQ+/vTq4RN8tFBDUaAoirIwVDTOX+xvc6cTmCW6b+6x0ziwV8LA4EgTwIOMSstL80SZseJAg2aDxz95Nk5yD5RgTUFFhfdwlIp4ukRXRnEiHi9DOaL278KHNeHUbcGgnPcT6qzfHpcNg7Ydyp0pPaKNLe38XKxdVQIM8ZqZJ96ehH0qqpSe+ZOkepbwsg+gUo=; 20:2WcEZDqYIcrq5WD4rnUJiTrZa3DrVyyo/YyFyugbJaKVR6Tzil4KgbG9B2zMcC/sW0xNeHv+ypdw+r/k/T39IcmIR0CZrROctZsUrMSY85U4srVxs8hq++4heQvMwtTSBJ9+FES96eIHplw3j/ImkCUB+8z7GyN9ErsWAxFCnHHOdMcq1Z4p6nve+UnJtAyi8OCZwtxcCqr+fhmiQFsLVe+XJkxV3Mcv6xdiTFNEoMgxWgEY9nQDQxT/wlVUwBt28MVTzJCJCAG2qkwby5xL1KuEvmB/sTa+CAjmdiXGDS00m2fDp4N7vo2/40FaFqx+yvWeC7BzBqi/V36L5j+dOczG7JtzZV0Fa/YSnSIq6wF5iufucvP6cmKD9iMbfnXbAQp8AYz/dHfPFxY03pui6Ne5nQ3bYGf22FTLH0gO5leASFAfXkBGCpYCeZTmGYwxKQpTKzPs6Wj0Zrv/cBjuTTH6/9cWYv/RDj4E6fMz6AkWnNluqU3mx1nDbPDVxrwH
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(13024025)(13015025)(13023025)(13018025)(13017025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DM5PR05MB2937; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2937; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 4:Apdl7/1mejPH9z8EB5DnJSRK+L8uhtnvvySFmW1w4bnM4IxJvW49m5kMU6PkBQNvTcKY6u4jazHg3Hj73O0SZPwc/LENlKtfOC+N7a9z89SedMlG9X9ejRnOG8ffHPMEMxCmFFVlLy3Z+/PGu7Mbjy9zYDa+70VSnvDfBIiY4iS4wOXn2fMeVHGsTZoEKdG85sqvy7Hh+kkBt4enH0tfq/iWehyc3xme5551DpB21kNGw/WPUT7BK8xz2tHC/Qyvo6f2CmwgKaVQQkSRdP/ujJQARkOxfBQ1j1NQw4RJJjWLutgIucEImpq5SXDalKCCjR7nZOwNxI6zrCWXQuAXWT6kWiCVo5zGWCs/OCvPHnolHn4rVij6xtoAxgc7woau9WLzKLEgzk/hmEdwd+imxNN7jWbwW+kFDTln6YJ90q0pvbqdVOpavfZzG85w5oZUPlpOt/bjNkPThd6p50n3djNDpagLi7GeWd0ORX0T6y+krZpGc3uI9LveBH9QnvcSZ0dhitt5LDgKaVkMPwGPWCYGpkoQQ5LN8H4IGIxTDYJ28S90Z8BnkdHtJNAryNrFd4Ah2UdpzfjRyTGfEZXe8YOkQ4o/Enpf/kCJtNymCnDu5idN2ePCv8O+dffMYSpR4obYPZxoqO6GqbbsFFsmI9ak1Aa5+bcgXaQxKfv44l9N6d3v1h2ERVFbsUEZtn1r
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB2937; 23:sqScMQl7gZJTq5symCzs3pjrGuJDACI8ekM8nv39k?= =?us-ascii?Q?amZD4n2JCJdUWO11xUTyGRy/V3M037n7uxztkdPjzyMERWrcc8KD5NLX7Qj+?= =?us-ascii?Q?wVCr5MI+V0y89DNuWuAZWc8Dxl2gPcCYQV0dItAU/TJXdBit6wrERohxasNe?= =?us-ascii?Q?eiC+EjipB3KB/yIRm/gOpjJCgksMpfJRkIEFTobamxVPzB08y7gXjyK9ZWgo?= =?us-ascii?Q?wSZGCxLpoanpfdFp3qZrhTC58trefhmNfMDrTcMvc9M1fSksYzxwYUHJzUtl?= =?us-ascii?Q?fG7DeGx/eB7ni3MWCZfQ4mfuAxpxXTsvdwf70Ys7kDrVodzXhuP2lIYhq2WF?= =?us-ascii?Q?qnGLkQky7kOaaKqVIQNI/2Gaq0jGWSFAtWUJhl/jUde8Lu27xPwrk32IN+xJ?= =?us-ascii?Q?Pc08NhBRVonRDxg6efwsnvjqufIfefdPfdT9EE5COIV5hkFFPky3dwS4GUwX?= =?us-ascii?Q?eD0bDWVQXWEajN+EysCwyJ05mms891FodXVhrzs/Glecwsr3hTmEAl1YeIP6?= =?us-ascii?Q?YfczJK7QT3IZDu5TSDEOBGOED7yezfveFrUcv3LcAA74d04WaraB0BFyFqya?= =?us-ascii?Q?eRfEApF/leD08uaBPLnZKy/nV3y9/eKhn1NKS18hpEY11t/hWckjuWoAVZnW?= =?us-ascii?Q?kC+n5rJ4xk8+rcsYEXEeUKJ/HNx1TevEuzqcglGmRMH9Y59NClhWOvy3YWo0?= =?us-ascii?Q?YY9oj1GgPf1ra77aCjdcSFq50pENWcxggk32vvs/Olagn+ku0H4mgyFpqEUQ?= =?us-ascii?Q?oXbLdBFQia88IhkVIMJOdFu5LT1I7z+Mav19szsyFFLByMrsmvC8qBtuK2Yo?= =?us-ascii?Q?L5VZI9iJTQ5Y5YYZQL3pTczEnfuTOl23xiGjWOquifz57Oh5P/6wv+V3H4ZN?= =?us-ascii?Q?PPWK5ihiyLqiNVReLuhuKBygt4S1Q8EL53BPz0DX8o2qBof5DwQ/oxm9SaPh?= =?us-ascii?Q?7RH343rKtx/gXw5zO2zqB4uA/FCsUgprK0gEPz1fW01IzFy4PcpMgZKzphON?= =?us-ascii?Q?6Xtuzd/yZKJHTCM968VCvDQkmLfrHMtyj3IRopKdRAbpvaoTa8zngRZMwagR?= =?us-ascii?Q?HhjtRbqxgLfop7HGHmwZJYYkfZwb7U8VuVlVXPPozAFAcgB3luKYKmrSxacA?= =?us-ascii?Q?5Hv/CLRfBPymmHUNnLvM+Wh1cXRfV9+J8PBuqS7xxneuMU3frjnJgZiWaH+7?= =?us-ascii?Q?XGKy0LlCkUbMCVVKtBHVYFn7EHos+sakTCQ?=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 6:M8mDgdASCBDGcZrGkqaekkGZ03dfT9g9vPaHxF2pZNBNnJZyFyfiG7CY5xXRBaVdwhsI4TOtUj7Lrzk20jjKyk5D/brCMkKauo3YlCPHX4bV0Kvp97w0rqFCrAT5ujnVcuTlvAiCFxQtPylRnSzS6qRCEw7Hix1uHxXBGMtyo+mcihvZx71R5oT+tBmVrcmLmTv528UTBcwhy0uT03HwvkJHFJ5J+CoO6mwBrLQCvht/dnEMg+/aZxNAl5yaAw6Y+k57TlVO6+yVtHfWjUXXXq38u76slJydoVqUrQK6fRYTKrs3K6H6zCt8eXv/McK8ZAg+cN3p0wRHo8V04p5720ymtnUUjZCIzUZIM2QNSS1GBxnFsGRUf/IVfRxcMYv4Qa67i2UkGTMmM3zEho8MPF7uvxTf5pyJM4Xdo3lZKDrbgn7oByxzkPFPsdlpqALYSssk2Eahtn4Qgu46VFiH+A==; 5:+lvP7gpAVoGyjfxvlHspdeiy9nb2ZvtGQwe3Uz5AjYDa0nWn+uCrhDUZu5T1zcOmfmIYLaMvcoX9AuqkSxdYcftai4ZHnQzgDz8LXIJUhH/ui5liRme/V3Pue0EJnupVh1gDYQajdUb5hyZVKIMIyQ==; 24:Y1r/84r6Fzh+269wJ1voAeZTDQPbYnniqJ/wGY6lH/vN0qsqQ5Vn36VcNFJEDF1fsmC7SE0YIj50yf9GkozY5aehpshxdV/BlJ4rq6O4aNQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 7:LoJ58OB1DCb8t9vKTXPKhfoLc1f4Sae1Jh71ZXE0P2RS+njZSKlc6IVxpHUgXNAe2knL02QCsA8/O7N1TnMsT4+JTsS9bqTYJ+tjEp62tvXFgkCrpGd8Oc1FsNEkgEOS9gMHuMMdbUV+dBrVWAya973u+Wv1hnbH+ZVKR2XgvbZAOg5CYoo2KQRJ335tKnTrcu3Gj93uTLLlL+pSD3Gt5WO0OaOWIhjj+bYY4JWzFKgtyrJd24gMj3qXhvPUNG+f1yovqfIthuDNs5cuNefQgQqOb2BYElYl1zWhPiX7hcg+injIxEkF/ofr/z4m5Gm9RuoMhMJYn0NK8qIpkKSYDxBCeDVAo41oKas8TNgUKK8hv949OWzso+qu6C73mPQORdmfH7se3EsBjeorgy+RTewPfzSudOzmzzk35xYk5p+/ABEz3JyBxqwLIQruXzdC0j5qijeNH+kOEesHdJsZXw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:41.5340 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2937
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, 18 Jan 2017 21:46:45 -0000

Ladislav Lhotka writes:
>Which doesn't mean that inconsistent (format of) state data is
>acceptable. My colleague develops a BGP looking glass, and it is
>really a terrible work because he has to do a lot of screen-scraping.
>Each time a vendor changes the data format, he has to update his
>software. I keep telling him that our nice protocols would save him
>from this drudgery.

This exact scenario was the motivation for our XML API all those
years ago.  Your colleague should be happy using a NETCONF/YANG-based
solution.

Thanks,
 Phil


From nobody Wed Jan 18 13:46:58 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 87B3E129587; Wed, 18 Jan 2017 13:46:49 -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 gLreQu7rrxlf; Wed, 18 Jan 2017 13:46:48 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0106.outbound.protection.outlook.com [104.47.33.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F7A129437; Wed, 18 Jan 2017 13:46:47 -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=iCieYXPsWf8fopqp1f1IXRFsceRn+jCp00t/WxeZtLY=; b=jA3a1ntJKRXVKFRvft2oRKRbOgvQLYLvGXvgf7ixJfo2TUOewrBnlNtXHKnFNIazR1aA5Eu9WJofZ77bIPUum85t0BSgjxC9NVRTjrVR6VigH003vcfl9pL4kCbau4+XDyIBKYHOoWVNEsKjCZgtsWYQ6Sarxlyr2Evv0kveL0Q=
Received: from BY1PR0501CA0040.namprd05.prod.outlook.com (10.162.139.50) by DM5PR05MB2940.namprd05.prod.outlook.com (10.168.176.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:46 +0000
Received: from BN1AFFO11FD030.protection.gbl (2a01:111:f400:7c10::164) by BY1PR0501CA0040.outlook.office365.com (2a01:111:e400:4821::50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:46 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD030.mail.protection.outlook.com (10.58.52.168) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:45 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:30:16 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILUFug016389; Wed, 18 Jan 2017 13:30:16 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILQC6h039302; Wed, 18 Jan 2017 16:26:12 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182126.v0ILQC6h039302@idle.juniper.net>
To: Robert Wilton 
In-Reply-To: <67fae2eb-faa2-7bc3-4763-51a38296233b@cisco.com>
Date: Wed, 18 Jan 2017 16:26:12 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(2980300002)(189002)(199003)(1076002)(110136003)(5003940100001)(69596002)(76506005)(54356999)(2810700001)(7696004)(68736007)(50986999)(92566002)(86362001)(53416004)(229853002)(2906002)(4326007)(189998001)(38730400001)(47776003)(2950100002)(8276002)(7126002)(54906002)(356003)(106466001)(6916009)(626004)(5660300001)(81166006)(77096006)(81156014)(8676002)(305945005)(48376002)(97736004)(105596002)(50466002)(8936002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2940; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD030; 1:S8XP/YqNZrmPrTSlShAMwlrfpHG3UR0tGQx7gC7K6Yi+3H9XErXndx+CKUbiYOk4hDqQxSfA51QTrXkG3BbfOhIQ2nc/ARqhw0kZhAZkEaDFZPhNQqOurQiV4UDNpYOvH6RmVYx76PCQW5lMlCC4xYesi1EDbpic7/CnIcoFurZ3hDGeJu7AC6KGR65Xx4X0kpBebf6msyjGEr41/MY7k7TIk63V2aUkqKX0b6zLkFION6uQFuuvfpWoIwdhc1OB2ivKwIooiDqjazHEZOtlJGkqO5r1QIpMPKrcwrYNgLKH0kOLY5XLLAmehVb+/KKuoh66seZYbNLga2mf0bXi+qmrY6bpNc2jT4B+tyrvC59/bLn/eqIDtdWUxUvv7UMNx7auFC0uyLGpggeN3gSBEGnFu1X0+S5FHMKHs2M81/bj2JWddExwhM5eScFzQeYdWHEmiHTQrCB3wzxKc+93z6LXIrz2aAmruunm8LlABbo8E9KUlGGn+3qVOKsnz9teSrYEGDVwz/8Xmd4zme+Kcel/JcnRHcHxW4UJ54vcoz0UCCcubSF67IciH2BmIJjK
X-MS-Office365-Filtering-Correlation-Id: e5d1f461-ba64-411c-66ef-08d43feb7fe1
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR05MB2940;
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 3:z4vb5s01ZMATQXF+OMXbHisaKS81t4iTPH6ZorWV8qqxF/QAQBBDh/t9uduOubKKH5pA2/U9X0uuemBvcNhtmXUZhNKWZGa+y8j4rrMFxs2mffTek7rVYjcy7MuIHgvHjEb1dxvG/qrYEEvnpjBDCsYIaqNrLyWdsC3s1As7QwfCMBbARJ0DBX9HxePvt/oaAG5UCvtJheaW2F2sSNRmQarqmbIRmlfcdfiTOpTtSSbVmUQjTzCgS75Og0QHspgNguQFuWIeGu8jvgPlQ6PKWru3oOi/7wg6A4zWX0UeVXgWXhks+BT5cG/ZCpLsqScCpgGceWRx8hhQIiEsdZJpnOEatrbBwnqXlvYwnMO2zIiAvz0+br6zyzJyVKVo7ciZ
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 25:lxSGxTqjSYHnI04FFTgBFv5LeTv6eld9XjRQCfH+3AOmDzGfapgisYJnieyTrQY8GHym3A97Kj2wEg2+4fSPUsneSimEI3Eb+pkDrUEwWhpw8yP82d2csXFZ+y2CBJJ4/M4JlbGPAR2xmtDirI91lPwNWC2Dn3Wq2Q8AnH7s4xTxlbzalyMtby2DKN43FN399Bn0pR83uSaiWNnWJilWRnTKvyuGATLaSnSQicaMiSH2RnLXC4KWbRm4Wb4C0Jb6kmEEyC05g3OXv0c/5VUv4xxboMwe27IrNQVi8/RbqG2eaeSO5IRjy/bvXEKVpcPRbwrjslZJl8oHavywOIX7ojT0dCGgfmtPZe7Pmb4EZP8daIo/7y8FfQuwB7xdaDZNvZITzWmqkYQdZx3nZvKAoKFcue6oXavTWWBbsQ8HikTyiw6LqLKwDKMW/THD9og4wJgsaMBjmqI4yr6NoSrGxrImKhQwjIQtw6qb+PGxHkFKBr+c2XyxmiONXa7EdFFrPmpPJOv3QfvY049LDWJaY1DXXX0r+oQOUfGf3B7fiBTfCV02bOP1D48Z8CrEwK57TXyxonYJBSKTc4Tvfg0yLMNCkyJl0TPZg8hCAMD275LnsV5HdjNir2j0vmSmk9k0j0HA0TWNPEuRFi+Jpj3auLNLm8YMzdNzRr+LYXYf2KWNhhcKlCx97MMY7ibnE/l3HC9ncj7SpYWTiYlAf9X1Yh9HEMjTh9+DCex6D2lOpJTcBGnV8aLG8o3sr3P4TuNHpA8QNv5F2tbCT9HJ4uqZ+A856HeT8wqQ+KErNQGU5KEluo48S7TuSEbseLOsvVz6
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 31:a4UQGICSE6cl/x8ULBXAVU5jWIBhU5CAE4hR2dDGyciv7QJlej4yEd1C2E0ryXF4w+QcuOIB8/mO1B8wu0RDnMzLOSJGLaAljwiSbcL1UHut5f+DVjoju4UYlLf2fCzZS42hdyNmxazWju1ZNEu8ct2GAnZTgTLuWUum0c1fcuMDoIKl3384azyKQxISTWBxUUUEYKODrnqbINrbQKfMe+qVOtRzpBm/6H907srkOUlyBWUfrieG78+7d5S3adSIP8bQJQ3ARcR9Sl2QUrI3mQ==; 20:ndjw2vhkpkiVyaTputuxdsgHn7wD5i7pIaJIFBnpd3USztDIcKD/BGqfGBnbqTBibloV9dnnMiqf8yAf9boqfzalpCTvvHQv1jwKqve+VbnyD+SOTe6VeLBVRnm1LtrwraYPauKbk5sOVceicc/vC3NPO/ZlYP+x6uckyWG8V81uIk9senfHVyuW6iN+LSimoOh+yMQkR/m0VJoiArILt1SNqdfnELsWOCl6jZQPFYwomuAYJgXKzn1DWOusmJoBE04V7R31ZBPrD4X4mFkFbNJlAkBPKt07paEaZifIxZJXCcW3NYK4w/5xha2/RPPPNcDelNy+xZ7keyNE1clKhUB1sURQEpgPRtgwtUpdpqFcDpk4IBU495BAArYlGH7l4LM3s4fVdNg+GvQ2il2iMkqBsJfC6nwFXnjtKYhrMoZ8TZxTo4pLQBRQ8SBIDmrDbv3YQ5bOEFQiogGnIYXA5gWhlVA0M5VnRqtbr0ajA4HALefGihmB3nZaz9Ppf8KN
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(13024025)(13015025)(13023025)(13018025)(13017025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DM5PR05MB2940; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2940; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 4:PjB5w0vqLwxUGAHXcCGv5OMjX5DjryQ34jjtL7mLgbMhTujRLnt9/ZejbJCnYihyozlJqM16NFQL5MFJH+e4cCr6SFJ6xvcqIV+NwRyVv63dpW5A3yYih50UYtvBgFIfeCP/kOQDrQePzyr4X+nUXQ3v93f1RV0VrPGppVUS+yz1faR/J9tSp6bYssFBEe3TA6nnJgu4wEfyBKlSjFmNKd/hWyGYbjT/GhVcwoOo3LeLbGemgdyg3pliIkBz7YfvN/ta9dFHgvfQrS/Grtb7XC+weMF6UCtI2fuWXrm90Q3Cz3UHLAC4yWJeznug1C2/KThSokZBbGjgmjTrG/MPZ9KKwGf3LSDqh1H6JOpbou8/o7aAd8s7BedC9IPmTud4lkoDBQ4I82Gxus0x0JJDUsItMEQwDg6cd/phnTFWfMX5PAvYJDJbSH+WGwRtlT/Vgz5lxs+YLPkyWiu4TAzaexL7Eb+4hgtab31sInJ6AV7pYL/KhakvBMiELrkKHALcLzTeqh4r+Cu8fyuL4MZ9F5PepRsAOQ8lLz8d0l/zr2P2hieOksRVibvHj2PXeL8Iawp6r7cMcfujdVTJDpWkTe+vNjPOxtG6Dfz6GJ3kdKgiEdRRERW0uV2kpdwquKz4qFR5Bzpd/lC9tqdo4tgteXP7YtVbeBohMBae2D+LyIlP266b0WOPdmF2YkB4pFA73tLPvPnSbxWWq0dNLJLT1i3wbSpjyVg5aWA+dxfEr0Q=
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB2940; 23:zoQRsif4O7bNwGcT9vIH89lcyg7Ib+8wOMbYw/3bX?= =?us-ascii?Q?uFf7yCrdAAfP3fgio2gMPdZPUMN57NaSPYUIQcyn/2ibkt8DNzWdK90Gfquc?= =?us-ascii?Q?483eL6RYIP4O+2TFMMFjdBJPc6YSFoGB/s3fW6TAFZeC7rksJKJOfcxjsuAE?= =?us-ascii?Q?El1esOo3p+QkzskLGmVwt42yeVRctvME3+lqWLn7hir13oIORW3V5b/d/6CR?= =?us-ascii?Q?l3GvzgxwFPBQIBSW9SajfNSR6LLJUsC2ya8FIhsRkiHD3UTOUm+7vRiQGQfN?= =?us-ascii?Q?zxPYt8idfk8r4UWLOuEET8sofmXaqJrVKlXTd1AEg9IKxuyPb/z03V8NZxWa?= =?us-ascii?Q?RZTeRmhd/hS05ObSxrtexQ6Q4IvYlsSVdBIeooeE8swOwbStn7y/F+681KQ/?= =?us-ascii?Q?9H3oC+STQB8aCp3UwdzmETTFjCXQgCw1Ak7VIIa97a4JLeT1omIcxUIMlSGP?= =?us-ascii?Q?vJuoCitsJqv/UJ8dAp1HnEUOdbCUTZyP1ibg0ObjMG6Wfe+v5D5u9jem45LH?= =?us-ascii?Q?7PYJ3mzDvgqphZE0y+fkfOMaXcD3Xu5mHXcP3MBeBC3XsL2D//ANdLfeFvqT?= =?us-ascii?Q?ILwqKYc0eyfIcAGvvTbL57Do10tU2zpcycaInw82ZazFWHyHq9DDsAFneyza?= =?us-ascii?Q?nKiSlqXyYazQU/6dtjptT6fgjCwYokJWX9YkjpR8Ro58+gTjZPmxNlBYmc97?= =?us-ascii?Q?tEE6dEU5+ybG9PRiwuRBiY9eFL/lms4puKAnd/Ud3dvbsb8JauOQ5duwXdr3?= =?us-ascii?Q?dAWX7M5es0/7HE+fgy9hYFJZGV2cVOZptn0dYjmLgVyaj9Qpw0nBAuG1m/n4?= =?us-ascii?Q?iVQ2cz8dYrQJUmwjLxIAQiLVopmn2may1bHTBq1wJXOnyUbfe9iaW4WT1y3I?= =?us-ascii?Q?Qxi2jzfeDhiC23VF7tzbgExy76Ea8zfkqeZuf7zLgqt8toD9WXK12ApF6dpL?= =?us-ascii?Q?1oTJlGuh/neUKA/MhHWMc9pmeaKJ5oA+NOekHYmswN1RTUch8zbJw7y6BSyj?= =?us-ascii?Q?zktmkl03IjDKc4MGOMTXnARlAz6ZPIpOdE4vrw21pWtY1S5WRCvasEQs3cC2?= =?us-ascii?Q?PeFy/9wJZk8PBRBWzH6RTy0H3L64p6gilinBjRJ8jgwQ2vuYbvicqPtJ/2SN?= =?us-ascii?Q?fBqLtcH75WnbEtB7fhsiiJsGn4J0qkaa3baxliDzHotqwjr4DEkr4QhGPC2T?= =?us-ascii?Q?9AmQetrxtk1E4VKs+X9hNPOehSnrBPsN7FY?=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 6:is4cWJ9Dr8GdndGEYbP+fT4yvwJQymiKA51A22nRHbjqgbuytvNF/tnsAQXhhX5elKA3q0+y0RhYPvKXSH+Bx6OlW8ZjCXC1VscdU5DNgb/rEZF8MhexZhOHn468XUJQ1pAhIedBjX3CAQ+mrVDq8NATj6OZG1CL5nzebxLg3uHbKIIhCEdwdvYUDfkZc2bYla2oer5Lf2pvLo8/HnZF6QCC1inyd7gsep2rQ9W32zMs1+cr8omGLOsgxZrYWHBP59yiRiBgw/mL0OmQfbtZ0gVt/+USrIsLzwI/WvZrxCl5/p3rfVHGoa5L7mPOJJa/sUWHxjsGdY9XiT8f+fW7yDMJRduhhB7Lb8+JzzxIKdGNFWU9LXXMYlu3kCrkINU5hYOZtGsPvKoiHS5dqQQHm17SelwWujBoUkFQJaSC4CqC48xDQWFcAvQPpG6a10VEen7LNl9GlzLHdkKGoszzpw==; 5:vWORmfmWkBpWANm582sZynbK5sZ7EWCYmY0p9hDJP2/abWtyuoR0NMeIq4zcgv2NbGK6gHJHVLVDscnNPlipTDO8DSaydS78aynTkL119zhNGTOEDEGDXQqV9oZQaXEsEVjQAqhwmzL0KY3wJ0+aNw==; 24:n5d8T6UF/071KOvJaydjTEm+iWuDA4vyjkWrPFJVWUJkMitf7mEwD6cTnU9rphzklqylLuDP5lbxKU1tCX9r2/4E5OJ4++D75z5sQ7sqNxs=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 7:pDYoVbsowoqhdmDAXgpDP+LXoewxST4wMzS6Y2l44XD/mBHYKZXMMkQ5omcP/WQlV2TA1P8hyDdqEEdjgufvzw4IBC9j0qZBGIjJT13RAOKYBQC/sKs97+KElz6aAg5pac7ubZXlg9F3Y6IDGKp4eMLQw+Ki9cd6WCX3t2y2xyhmd3inCgfJvBXFvbLg5rvCYZ8mofaGHQy41YoHqknkD/zpU/2P7m9QUS0fyH1iiFQ8zcTaOXga4VcFQvlhS8Qc6O+vlZYSakc6Ht5qKzMiB5wb/Pjh05C63nYEVdv34DwA4mr0tLLrbxzVkWjTa0Mbp2j6H3rV0XPpBu4jrp5g5uFHvdQlQSyIg0xt1WWuRa6ng19lDDe90QACZeE1sE8Jh/YTgrNT3fNI+0WNy/1hkbqq2JXq1kexsrdre5Uo7mztzBeXQ1YjQuTlPzp1ZJeC7sX1eN8fV8ELqtlHh4lGmg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:45.7681 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2940
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: Wed, 18 Jan 2017 21:46:49 -0000

Robert Wilton writes:
>> 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.

We're trying to avoid a "separate state leaf" solution.  That's imho
the motivation for this whole exercise.

Thanks,
 Phil


From nobody Wed Jan 18 13:47: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 D824212958E for ; Wed, 18 Jan 2017 13:46:54 -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 1DuNI2HS8alR for ; Wed, 18 Jan 2017 13:46:53 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0110.outbound.protection.outlook.com [104.47.36.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2BF1295A9 for ; Wed, 18 Jan 2017 13:46:52 -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=eN3oANU6aLc3C4fGs90T9zjyxNR1/SVKmN6M6Gp2gro=; b=a1FU5NQUXCO8tS2Boke0twy+s9oe6h/axytfJxBl7PqxSvdeLC1t1DjBf2L5Hv+9bMNAxWQqS5Tj3LDyib7Dl6WBzpz19imgPnA02Gil63gPr46pFJWF2pkfanRKyNTRroqIvINg61KUviu9+OfGDotk9sHDxQEg7KmywwFU4Dg=
Received: from CO2PR05CA031.namprd05.prod.outlook.com (10.141.241.159) by BN3PR0501MB1283.namprd05.prod.outlook.com (10.160.183.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:51 +0000
Received: from BN1AFFO11FD019.protection.gbl (2a01:111:f400:7c10::119) by CO2PR05CA031.outlook.office365.com (2a01:111:e400:1429::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:50 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD019.mail.protection.outlook.com (10.58.52.79) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:48 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:32:37 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILWbxI017318; Wed, 18 Jan 2017 13:32:37 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILSYKe039335; Wed, 18 Jan 2017 16:28:34 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182128.v0ILSYKe039335@idle.juniper.net>
To: Balazs Lengyel 
In-Reply-To: 
Date: Wed, 18 Jan 2017 16:28:34 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39850400002)(39450400003)(39410400002)(2980300002)(189002)(199003)(97736004)(1076002)(53936002)(6916009)(106466001)(50986999)(626004)(48376002)(50466002)(2810700001)(5003940100001)(68736007)(7126002)(54356999)(8276002)(2950100002)(5660300001)(305945005)(47776003)(8676002)(7696004)(81156014)(8936002)(4326007)(356003)(2906002)(110136003)(81166006)(77096006)(38730400001)(92566002)(69596002)(53416004)(105596002)(76506005)(229853002)(54906002)(189998001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1283; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD019; 1:urGRkkEWK+i3C1tXl9G6sxD7/REO1przRRHbfKz/TDgrH3nwvJOfJiLpYqnc+k+DcYgjMSGvjO8fGXUoSFhiclD5qmn0aSsk6vBdT+N+je4+6jF30mY6O3MIZ5ELttd+/mv5+tM6W0lW5Je9G+2ksZg+hz8ODQmj4yLGOKByTzMGye/NKxWfrZS1ZpLzeSaWbJ53AQ2lWBy1IeQuBlhf/L8Nzgn0Hq4NWVbIZwNAORWYlnH5uXD4AHT4jONqLPgdnKrjQdqH2yc9oilsfrsfTDgG/ogFbluN3K9fHYyD1g4XJYaQjvO51SiOBJxe7318DIHOknhjiMwxwSMXKsoFOS/N7mo9eXoXuOI0/O2+S6nwKzvkEoN9DmnWfu7T4cnRUT7Uf+2+tAbdeQ5AuVaMg5oEVcgqTLlfYju1p3aKXXuckBxNgQmAV3NJCWXL3HiqQLtmj51hhr3ttoUVbM8wHYr3W7ps4u/GcSvhpIjaHreXvN1mT7YOz+0W48J2Zv2/6Wy/vIehBysCQi5EbcCpjD5h0iulr/WvLCcYuAsW7fg=
X-MS-Office365-Filtering-Correlation-Id: e1881c6b-bd8b-4f8d-4262-08d43feb81ce
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1283; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1283; 3:E+AWO7IzCzBuyLDOvXrjrug2g91R/pvhlPWWnsqyEexQs839nFwRs7tb4EoOpdjnfp4RZLv19IU7lJ5yVa24WOO/rMDO/tsgvucMm/lBsO/FFZ/eau9opzL8ChaUOPNRsL78KNi2s6jI1/kzav9ssfBK6ZStihFzwKpNX0gPRqOBmlaRc1hkzt02GsUnc/RxpHZcvSs6ORmQBvGo9Yhq/yQJSgoC6VjwBvtEEWbjouWydBLMzafVYeqIsdzA1v93NWIVT4eIdzPn1xYZpQ1dplZYGLCDgPlUD661pCtvW+paMoUGFKJZUD4Npmm/qXNBem9AMWqQEx2gOBmezCVzIwE1FZKjKTgo2R/VX7rmbXDdjX6EQjpVjTUzVvBawCH5
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1283; 25:O/BuN3hlNyg44Xlg4RwCLWEtdgA77HasBdnx1ZDTw0aIRDB+UZjemK2cLg0lVESPorXKtIjvVzhrLkkRr81PWik5c2oQGhb0x6q/xLCPZpJgkAxazPAHq1xe9VlOBFLUiXAEGrSSDcUzK5kPBuJ+6wqf8+q42qPqok2vlCakrKGxVRZ5h++7GM599hgX+OFKAhHh7///rn8HxKopMxn2XC/7bU2RmcOdg8lA7JTT4rVbb59gHrnddGbDPVCmPc89rDdgpbaNY+tDrQ6VAm1r+bMk87O4U1kcBlggkaFeawPgACUluqho35dt18+4Qh3zCWmOuafqjXH+4AaO/e4lkczfkHPrxR0+atIBXKzS+8GzC8pGBodg7NwyKw+kysAqSblQNbMS7GAC8L/9knKRYJfR3hI2MWjXXA5tN48wZOzT6cy4ZRn/694eoioxWkr21+SSN+cZjU1e4GsvidBytL5yz01sq+68gEtyw+QUwhj4+SHDA6ZRl8RAKD/BlblcO8WC7xNEpey4Im8l1ooB35SzKXZAqHDGE0ipL2w8IgSG74jh+3jvK9UlaxU4bxNFahZx9865m9cZaC9T1pf/AdZLUxsUEX790tesxv1Dbc6k1KDxWU0tkreYntEWd3boSdsZ5VWAsmjYc9DFUNKau9MsAmI9EyxJj0ZdBEBOXQfUzNvOKcYNTof1Dqo5yUqXyQpcvpTkTVeXB1VsLRaBqRNi5DhMaguYNYlgWDoTZYAZ7Q0JcIF7JNraWvyIo7xXP2Ef44R+2qav3nHzAUpul8afBT1JTZ4tEyHemu9gnfUDTjdP7/ST4pW2Zdr9AHv9
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1283; 31:stT4nyyjh7NOzecavcEHXrihTN3b9bZAzOPC+BPYMcAyN9Gr47btCwRIVH7gOFhfP23Aub5YSUeGVIjFyuxGfCLfmz7kNRHnm5W52oCjgXfhfPRdtDqglvG+gC0MdQ7qNUocf4IZtXEExyNyaLWAhUNiLizg/cjKnsOFAY2j49LIDLftTEdyB34vWiE+NFNVjM5Vc2B9SZN4JK3LLqYHJYXS8vfcNtW/6MxSU3+iuHhin/ELVifaVeB61eFZKhiaYq2P+yki9eWSezsY1L7aMQ==; 20:gm64Sm9SUJgX89PJVUdymGV6MZNF6njOg++QmF4/u6VDvVBJhRxlUeI+qnHKfbF9rAznUKzflF+4StaxFdAj6ACDEfC4FqHTv2iJ9Qbnh/Q/mVBh3NNcCTSGj9zW04+rKLjVRxyeY4obCbLBtTTu5mzOMXA6yypi5Z0gbwMGpAxPI6nDwXn2L8QljiAZInlgrWDbl7QnzW4SD4x69/psw2ViL6qiv17CwRJk6AnK7L3tz9VSsMrSmzlzCo6+y1h1v8eEiBcIWbNWQHFa+yZN0Az5aPSsVnVGqzoM82JPgYcikfKKsRbyLgG5ilZZJ5yOMDzXe7MWwBwYlLSgyS3bWzlE7S1Xdrp7Bvj9e3LrIB5GcN70uS9MBaATz5O4pBwBYeyGzAvZKS4pbqPEoiBdVbqLHfp76ig2UZwfhoTv4At4ZAoVMmT9tAYL/4wahbOX7qxCdI5Zj/tXTbSBiF8yGu2/vhEB72Rlp29yxNc6Zp8S3pjfgjHW1piiT1GbMFfJ
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)(13017025)(13023025)(13024025)(13015025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1283; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1283; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1283; 4:6G74Uik0B4Ll8cjdg7LWNQpMDSqg/vOatAqcGPQEmsLGzEM8QdWC4e7huOlveb/SMuOZmFRc7n0YRIN/I3iB38/fUITJ6kPyBNVjEKXDnq0VLOisAxdUhHCd7GoYH1+dV2YgS0+ZDg6Jmvj/6KLghMXBneN/KrqSUxgbkN/8/TB4rrDIrcDNptVdwCdqAjCjLmsqCY1hnc4HXnVlih8ey6Iw7xULAsTtzP7gf7h6C99N2BKFi47NZJeMxkJE1HXU37LBHoVSm8d0euvHWiDnkmkfLn2cJ1mXbDs44yjtunMi3ksmUywkm7CSsNonxFaCLI+Yat/2msfs/y/8V8l69vRAah3f1/mPIBJofnld4Vpc2DuEX7XDRaXjQRKILPGYDGEO+vPg7I+3GBhgh5wdOjjv02yGdY0SVrl1qclrlX6NRTFfD7axP7HytJAaM+AXo3VM6GFLFQqJOGID2J/BNmVBSyH2quMMH69phzDTGyGBohmKgGE+tiYBsp2391WbmMa0FFzKLj6+wg9wI0euVAOmC7i3ysL58FojTblg44n34mSTyd251abFHYIO6Ujren9J3Rtfj1bj3/TCpsCeBKGQwzVbRWjImuf80jYb7EUt8mvX2ot0Il5McYUq25q7yRSMKjrYEh3RQPa2ponTL1TXH+HjEcuVyY1Us9DUlsmTm13Ch0AUJwg0c7qNndSB
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1283; 23:1/OCBx79a3Er7ozX4RR71StkeiC4QkKahBdmzVF?= =?us-ascii?Q?L7x7JkuUKS0dKOrTd+Z7PBlPDppnj8uXQDWa5k64kYvmy3NtsAEPyGrNmZ09?= =?us-ascii?Q?7uldb4HwKlwcjyHmHDzepfUIBOIMKJ/EmBF8AfQoLmVSc2qi6pE7jIBk3igS?= =?us-ascii?Q?vlIGJWm6S9vfvYlqNXyCUhf5da/wrmsVL4ZNDedNkZy2s4B0NXnNxe5JCVRQ?= =?us-ascii?Q?w5g6p4LeDo126SqwuaHNy8iBcBSF3f75IpzJktf9BDaBqYy7vuAI3svYalmI?= =?us-ascii?Q?/wXIT3Oc9GtxUPQbUmVl/hl9CErLUGc0mZVPLg2K3wpQMOYHwXE4OeYU/nJO?= =?us-ascii?Q?jwHROXFy9jqYdK6eihvuovUjw/UcPp+v97xKonnfZu/FybPRkU6s2RmyDTaZ?= =?us-ascii?Q?9X5nfqrOkXJaCLeNst4Y9FL4Yjp5QYtebJ8RQxZkYpkNpr0LqgzI6EisupOU?= =?us-ascii?Q?/uYfWp53aJ+4rO+uxG+jF/gyHiLKmlf9+wL3ZaqsZew6C3XUxWfMAYRKeWUK?= =?us-ascii?Q?Gq1ousmvjw+C1gXCmVGe7N2IGOW9rHHi065+ej/UFVn/nl92YQ8X8TF7tjmj?= =?us-ascii?Q?E3hPKeUZSdfTNs9OwI6ntVwiVCgtgTZ8P7HG0w++vbBs+JI7IPf4qrFSeix/?= =?us-ascii?Q?tjMSvN0pQhBimeF+eKmpGA/H1xUOfErpRCLnJV/xbO64dFhiYbMEjubRsS5j?= =?us-ascii?Q?9toiWuKwYcuO8pVtnoDIt4QerfDTmkqEmVfwhn/cy9Nj09LKsL3C8s0AyTa1?= =?us-ascii?Q?AKQiRmf8j472dsLULh6UTKOk8puTWbSFSbuFvlGJ7I4AqmH9oKVvzlddJbbQ?= =?us-ascii?Q?43Wh0Zy6a1C4MXZFQqCREoiNbypOTMf70VQDrG2klWXCB8OAXMlmL+RiRM/Z?= =?us-ascii?Q?wE+F49glP5of6QNJ9JK7L8y9PQ/sV3OzuTKkTaWpTl8+VDa4e7XP1SQOvzNg?= =?us-ascii?Q?SD5TC4ZIanjAdJlDi+LPfBae6pbifS9E0MyWKJET86fUdQ9HCyOkoyOHAf+c?= =?us-ascii?Q?PfOhcw0y06YQ4Ga5stGuUdOOAK6gZ/T9f946mQcFphrV5+VY0m2gen9SaLA6?= =?us-ascii?Q?G0esYzn3jv5j2bgdtgjneAfJDa8Akl+P5XTiZXRWCC+BpNXIcFSO5i47q5O+?= =?us-ascii?Q?72X6I7mNOzi8QXYEBolXQInaq1KeZ5/26WKKpXtyZ1EatW9rYGggPR6zSrW+?= =?us-ascii?Q?nuj4wN1jwUzaBxjrAEKb6oVupbX6MqDcISGLq?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1283; 6:V01imqplAd9yXH34BpUMLOWVfXNOFcXxfo8zSlEuBDnCvjhaL1h0DW2hJQMiFyt9JYGFCvHBtxC3/S14E6f8c7Xv4wHkva9sl2L1g/RYzZhO5S+wDrwGNyiYHg/1qq24eIUNwOYnIYyhTPJ44y09UqKfIIxp/4FuStd7gHuWmwbw0JiTRJyRqHYvTDunuNGE0sR+f3+1zfOhpbQ0g5jJVi28x/UUSP3smetFP0kJctOcR4KTtTpOcNP2n7tbSIXWkCFfwKBfP5RdSIwlR7NSXUOBrC5VhNO1Eyd8Cnuvm0zbrwU140alB0/U0L+/tTefjxZ76f93oEhW5TQGx8ByEfxVwgPV6NnpsJFmHVuXyeG5Zfxzdab8WVwaat1t4BKDVP4Uacjm611YQaS3RskskKyM45Nm3KTt+JYyyNhcmALYXSDGSvltUyJn8CAJp8GwC4BeL7kGhdjjyrHPtrf0dw==; 5:VY+dMXsQRXAGlwmrN0iS8yac6kamgQr/+/cW1gLl9ND17Smh1f0nTW9UeD6e0aqj3h5cCR+S4lFSNl2VEzeaLh/8jBbbEKy6LvzJGfEOQN/8XshUQ3HzIgyccAXIp5wP2DtlOvwuka9dtfZ214Mv9g==; 24:xUPap3+sfSU0fQJrSq2tP6lJd9u94EkgR/AcCsxskQ6cpBYoLd4cruAS0/7afhwj4Eik6tyQ+gozo8T/7zBjQ94FeHOdbye5iQU3B8nCKQ8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1283; 7:1Er8Fm1xl6zSv2Irv0lrdBJHC35pniUDqSMD45TOioxPM8Z2kZqfFWSlN/xFsMd7zzmxS9RmF9FaWB3baikSA7itnjlScEmrXXg/x8D0wH2EqCQ3/L/0xbhGdS4H+lD9ZGT7xATn52tUpROfR7PlpNB+D18t+kwlFoMXG27F3EFRhbLYGTXR5m0Xviodcme0ua5TGCMqm4c+LCc6LmklV1MYXrTmZpDHPUc/6zXX07Uni4O/oUx5VppfdC2vdbcS+5JuNYr2uKJySDLlO4aQsi1xIVynMxQ/1V7tdnEY+MMBRQdLqyCj2Lo0xQ0VScWAOMC+y95QqpcQofu/F67uZ/kEivujkZyqD7t+a/q1hx2+VULGrNHvnXYmT2C8Kd4u/32H3bIczYHoYtQAkm7rJs3euEa54nxFrcPeNjoFF430PCjF+ELEQxakgXhBmNG0bY8ERq+BHVFAHz8ufM9oCg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:48.9669 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1283
Archived-At: 
Cc: "netmod@ietf.org" , =?UTF-8?B?QmFsw6F6cyBLb3bDoWNz?= 
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: Wed, 18 Jan 2017 21:46:55 -0000

Balazs Lengyel writes:
>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.

We use have clients using it.  Our fix for performance is to pre-load
regex-based constraints (from both radix and tacacs+ servers) to allow
pre-authorization of commands.  This also works during intermittent
networkings issues, which is vital for networking gear (assuming one
can do the initial login/pre-load operations).

Thanks,
 Phil


From nobody Wed Jan 18 13:47: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 E5470129530 for ; Wed, 18 Jan 2017 13:47:14 -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 U8phM_GDPmrH for ; Wed, 18 Jan 2017 13:47:13 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0109.outbound.protection.outlook.com [104.47.32.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EF7129978 for ; Wed, 18 Jan 2017 13:47:11 -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=EWOfQWC0fx5ozDrVpvudqgzJ3/LALK5BUI4K8Vr7djo=; b=BNsAinlzZxX0B6evtks1Ad0ltBMLxHA7WJZWfEqC0TOvphDPRFrGmCY8moeO1vhmpbaXw0xVi4AC3zvYa5LS4wSyNLetoeXZrif+vopaUJhOOWto1mniwrgsaqM704UFLrwQVDreL7TUP68LJCD6Kv7ERJhAk9rVvHGyRDFyxYc=
Received: from DM2PR0501CA0023.namprd05.prod.outlook.com (10.162.29.161) by CY1PR0501MB1290.namprd05.prod.outlook.com (10.160.225.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:47:10 +0000
Received: from BN1AFFO11FD020.protection.gbl (2a01:111:f400:7c10::190) by DM2PR0501CA0023.outlook.office365.com (2a01:111:e400:5148::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:47:10 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD020.mail.protection.outlook.com (10.58.52.80) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:47:08 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:36:47 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILakLp018516; Wed, 18 Jan 2017 13:36:47 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILWhfx039384; Wed, 18 Jan 2017 16:32:44 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182132.v0ILWhfx039384@idle.juniper.net>
To: Martin Bjorklund 
In-Reply-To: <20161222.114940.1495001277375813904.mbj@tail-f.com>
Date: Wed, 18 Jan 2017 16:32:43 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39850400002)(39860400002)(39840400002)(2980300002)(199003)(189002)(81156014)(229853002)(97736004)(2950100002)(47776003)(2810700001)(50466002)(110136003)(189998001)(7696004)(1076002)(2906002)(48376002)(6916009)(5003940100001)(4326007)(86362001)(54356999)(77096006)(106466001)(105596002)(8936002)(305945005)(626004)(69596002)(81166006)(76506005)(8676002)(5660300001)(50986999)(54906002)(68736007)(356003)(92566002)(38730400001)(7126002)(53936002)(8276002)(53416004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1290; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD020; 1:c4gCUx08cVNlh3dQjJzDCEA8UnmX0DUGoD/5vYYhjfq7kiEN11/vKNGdSFVLGAujQ9IqpcRXH2lwZaBCtJ2D6degGWn2uUgVfU89LsyP9RbY2uDqFRaJOvEvpKPmwBLubi5/SmicglQgde67kH/7ZW08Z62kFUqeBoSKJb9E8NxmC+Ji7yskd6VujZxmTnRGKNfafy0mw/ByMJ8jT7Pxbqeta6C15qK2sutygrRqn4xHV08Dca8ZWbSv6xm0uSuyuupNNwxyCnc5i06QA5utkjztnUNtTRbTaZQvyVHvDiw3miQBYSM93bAXCGEUw7EKwtynn4DWGnlChHbsgJAcH5XMnYpnanz2XVxKWcPyAqbgRrKNuowizvRnUt8LffeZpQzrJO8/vq8f7Cg0os0qNyTDCfLLf3Me9OFCx3d6A9Z0FfQqXRIORYhwNQwSXsMa+Ebvb4oGnV6c4hHLHSAIg0EJl6El7myH8cY5WVNO4CYKmVNj8tT8KaRFMOrdYNUm1qwC6DNBJc8LwZ927UnCwzSerMuiaZKmwoMZLYZGbj08A1Z/q+FBXZcrj/wib5qy
X-MS-Office365-Filtering-Correlation-Id: 29ad6eaa-1ab4-4868-db96-08d43feb8d76
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1290; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1290; 3:KpXRxMWwvHThHSmKkKW6ALIyO5qa3Qku0FXkSPMbuh7sgZ8vHzUX+/fHlauJKt0WbgaFJuMe/S7JPixCjb3GxxfeqkbchF4GP3WnCqmUNYA82QSnn8In2w6qqf570hW7TUX0alsG3yFe6ZMNztnMEJzQV7QAe2ON9+SHDLDRl+ARev7MDJXTtF+Jun91lEuhFx/DWOQauW19Qna4xHSd2Wi3VMvkFfIzydBVXFLZh0hFXrSBq3DKrNMKPFcOmv0bqOEqXyQixHBPBGBwqPTFcRY/TJSC6YiTsP58SnUUDtk5KUmpOzHD1D0l3I2uS0R4/wgLpvdOi9dALC6MSL343x+Z4JYmVRi2LjtmVj9PAmWPadl4EAo88BXfCgu/yy42; 25:zp5iD2B563ELgnfmQfmVu6uPjRVwmnq5zTqxYTGa7vdRRjNQNIVvE0QQXm1XhYmSVrzkYNIiOrBi8BtMbBLU2I98oPwYQiJ+5nLis5sHSEaM7r+V5yaTRo8o3dU8g7pRmsoyHrj83vUzqYu7zrPNdDxn9jM1vKFpqMWwqroEsVhD8IeU6dcNGBWwxE75A/r3KQaPQPBXKEt3DmQ1TowSRRDa3g+ONFxQ/cqnb7JrRgjNiuM2EOoCuS6AKL97Aod4n4n/+w8P0nEf99eokYkUES/CfmJMkUCZSC0gNlldeeDMG6frJF1gGHVzzAAASQkrbN/1lBAqPbJ86gAL+IuxUIlhbqZgwOXVHbaQw9bCFlR1IE9C3ZgIDxQmytrrKErUBM8a6g0Lo+Znc8cViFYWT4AIDk62IAqX2GlTQcFSiU6aQFvebEo7EzuLCgwSltSdyEkAd+Cnd9mcM6ijPAuwRA==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1290; 31:5P7E9q6A8OqPi4+C/4lNFJEkTq5JCDhRJiu2sm3KLv1ti/IHUgmtO6fUMKW6hPLOrDCdaYAnDT4nMi5Xaw+lMEttbMK6Aaa+c6GWN0MhQrZIDlFPLxVGQD5KtTpwLwlB9gQGwvAc3buROu9DGx54t8VocnNGV4QzH/bTwI2d7FeHV3BaLlM6N51xqLdPdg7opFGoWTOAoX6nkSFsySTIpIaJl/G6NkqpcY2tY3ST9WjwZZ+jUtad1Tu+WIYjgiYEgSbzd4Gk6jea+edNT2u6e+kS0kABoekS0qosxoNcmBY=; 20:ZVEC92Pc53l488LivtR1e5WuKxI/Sta/t8RE9O/IBE6dLSbzeG7Vd6r0Y5LhO4sG4qpC+bpWfTNAmAA8YNuKdU4ii8lfjlkmaMAfSUwx2qNGV2srNiAV/0TvvBKc/CJE5rZ0ZBobxf1s8qaEZAYcc5z1OXf4oksnfqUQoKcb05ux7k8k+D6TZVaqJLA88I4uGaqGyDn6qMbDWqXOyervNnnWMPvDHUuSCs+9uI2YmdR1KDIk8YAsRrBPij8qFCv4a4zMLkSfe8dmwFzuFN7OnlpwZRgpExA8kpWDxJPn0FD1rPfId4uUw/Z4MmwqPqSJTcFAzdEjpngKhqJ/HTfnSmoHvCcWmCvWl8anltSYO/FPiPzRUmq2UT38Cgg1jFsV6yLUU4tq/yI/K+JTz2L4EigK5fMnTMd6jR9hqax/0Qo6Yg6CVBr5rQfg/nLevJg9RqEz+ED4nHmOY73OV9IaU1jC6Cvt7JcUppDAMBt8BXWh4ZdUZ9nh4iuW2TgsPNfy
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(13024025)(13015025)(13023025)(13018025)(13017025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:CY1PR0501MB1290; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1290; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1290; 4:mOr8if5zTOoETpcY1pesPkZUAnGS5pa54e9PqE6/b9ixc3dHs+GBQN2pIauJMB6Jt7y2c/nTUZIP19CaGMuSiIzyDVwHuazYZEJAH+8C13Ivf2vY4fWXCsYddnHhgDZb8NbYq8YSsedyfsnQFLn8Ne/yCjb5oy53rNtq76mfkkhoMiFakxE47OUus9muha6bWZwTrRjaAGatnmS+IfpICadBbCLHQAbOYxKfzu5of+oP8KSl9ja4BAXTOKxc7xVmQHXXfiWLo8MhmKaeqs4BZ3SUI7iHiw7Oql9J/BFs2kkOYnd6BxyRBcGJI9phHVYKQ07X/oiJU+R8Pgw9J+Fhy1f54GKLSwSjeAYVPMqQU77CarkQT8zHQtxcM82XcJEf2gMD9OB2dpqnDvBtSv7gumOXB86iPHxrZxtCZuTwRshA32UC5Gf9+E5CkTGZ7ZmSqh9dNI4AUGDVbrVD9A3KbWjXj3vg5NlvMxVck9Aa49jxfwSKW+2+ww6Fh2Cht6t5ohqV7pMkbXnYmMxy6SnMSkYy1LiKfbUxmwxufrZASpoHAp7bU8KkMXKYmpOQiYaG/pK9kVbhclxeOipFiVuKvaCG4ZoqQ+a5jjomyREN52lWpznG7VASQvLn4EtwULkpSIsqGC+wtCdVlHfC5o4tgsGlgF+/acQjUi4TY39bu1FR+hgXYorT+qQF7NWQ1pdS
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1290; 23:9K/j8VKAsJ6BZJRBVVjA+tiwIk/pqw3u4pfnA9M?= =?us-ascii?Q?KCIGf8ozxJCGhBsGnf2e97dvRzoxCVgsAN9tb1RCY4hVqV5VeNwk4Qd1nBHv?= =?us-ascii?Q?UzXq8upOaxKKp7RV56HTcnSIB1zI6HyCLYkovRQTkU9SP9XOqLe/V2w5JR/N?= =?us-ascii?Q?iCVqB6Wyjjdu7YeamNWMWuDJlTkU2k0BWm1lunJRsSUmXuF4oGQf3sZPgUaz?= =?us-ascii?Q?lfPuSEnKFD87+A7foi8/rXBe9z1K+RS3KH9kV7Ic8xBP/zyKn30UC2bNeQpQ?= =?us-ascii?Q?R63Y26t73zJuGbj9ABVH5DImb4PwEpbH9roZq7fJGH0892qe5CrpqzVpgDLz?= =?us-ascii?Q?4RcWZ07gBXFSw/T0fujlwsK0i84s9iiEtIDyatyRNJaWZOyYSK/LxWoHQ5c6?= =?us-ascii?Q?NeLvH7RKbL7QmM94hBku6US/F35uSljJkwia8jvp5BnV+Jp1FQU+kBaF5Mer?= =?us-ascii?Q?8f8TrpZzsMX7t/BFzaGcv1SiNZKo8ovTxiIaoG6z8H4HgmhrP1PEMWvl6NKw?= =?us-ascii?Q?hxxsbhiSrblGnoUrXq0mQBBHLaCVz5yYaRUcK2tNeLdHeXhws/1xnSpZuFA6?= =?us-ascii?Q?2nklplO0er3gJv4u/ZqT7/b/eYLau3Q8+UZPA/hAFP03pUh9hUQUr87OcYQo?= =?us-ascii?Q?eoTJE+w0YH6Uc8RtFvc7pzWLYoBfO/I6ayjvLM47ax6ufvozsSS7FgHAIj8i?= =?us-ascii?Q?5hXIVu6sbrEAyDfG632OGvnh7CFkoa/fS07KLzVcC0QHhR+wIiVd8TKsgL62?= =?us-ascii?Q?DBCLnWz+ueoUNaVKzq44tMwtIgITUA6OROR601hkjKA/5oPMWT6KbnXGXLrJ?= =?us-ascii?Q?RHWJWlOqN0kUWGy09ayo8waxK65mOYChl12W/D9vJOQ8wJYGb9zqbTe7l8ZW?= =?us-ascii?Q?Zbyrtb3y3gRcOVHhN9neGr9lkU/Q74JaqlYMbQpA4//9LgPKCdKDIIiBhBLq?= =?us-ascii?Q?dAnfeWmNcPKsZvQZ+zvCTMoNZ5Wk1GXoIWba45PJ1UOzYYY87ErTTzDQUURO?= =?us-ascii?Q?51Ke9b7HsXifuv0HGWXacTKqsoHAehU452onxu4RSDEmBgwr/6a+Srl/BUf5?= =?us-ascii?Q?o0VnKuJbtc6mcgkOLoeExBzxNBjy8vKd3NxvJhorqAEO/m1LNelAcNTWP0CE?= =?us-ascii?Q?bRmwvNgEXBsskBkQVMNnwviqp8XCZ78yzxs3qvdozxzWRNtH/RR1rCev2KPK?= =?us-ascii?Q?Rpb0swz9/5CQYcePh3a3Bfd24au3/FJZ0Q8hW?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1290; 6:H2dINhVheniC3S+JFn1E2zkUBXLhWTmgFyYbBPuSWXBUAJVvFcSOf+iwIlJSzW4IVthAWESymjf5hEcbp/lB420WW3eARryVwhD6su7bJMfuBOAuleQ4CF9Fj5OX7AExlIiKRX7z7V/67h4ojWhV9eQPHCTOeQF1qi9QCY0zTSeCGVQAAqmlhtzA2nDScLuJdMk+iGpzE8tJWmVCYO1IVy4PZs4+dsKdlW0ZRBz4A8o3z6vL+WUzCdrfYXQTOMHiaCuWvleEeyxARRuATf/EzC6yjuwtLI/hlK8VokYN4/V0AtfJLAeCCP9FEICsiRuW2w/pdJaXeLf7ZbSxRJSziNERAPnAo35hQZ3FlMIXysx8mbSE6DGGTtbgCHZWBYe/JpPT0yq+K9dkIz+HVK1qa7lCOjLJtXzndoyyUGSb9xjTpewSaeJCvHtS2G8Bxt57UqyB8aK0NQJTUt6PuqwTww==; 5:OSDQi6Pgj1fEmGjeitlNeNB828cPoqeu5gy2xmfsDxnNNRlq9JRm2mGyCGgkmdE2Q8a0yNCUR/IpfjGhsjJI3SJtbiz0alV0BdMypF+U0nfAPkgRTuM6JZuioyACJxQOYCT7Ce5OxNZe41xWNudy4g==; 24:UgYK4G2HZnZ0PxgQIUox0pLBDsKZyd95pbiwZ7N1CWJmx2HFHEJYCUkPix+32cFexwRzn2Z1OTiaox+liv7F0wagAFr7QEwsFHzpNPix0Hg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1290; 7:UXhnwSkqya0Yq4XRw7IcX3dyes6dXAvi9O8XB2c50H5OOV1TKqzIhCC0/d1Yb4Oxnl+om25YfQ6sKxybRS1CQ+VyOHgoDWRQkbQOH0581jlkEhnPUVS36sosIL1toqOirXO7vLzraJCQyVPqKkp2yZKR2z0+5OaZhA/ZQwOr+eRDhZE4bLRfj4MLK9vfCJFO2uaxx0UPmf7Y/RGweXjx9/gKN8WxNqMuNzM1k+fZmeSQnJXfjAW1bEIl1yyLnpnXfy2TxMjD5LbqifCEi1g+QWDh6LcmSVI9EicKG7GxfRNWfh4sVoto6C4HK4hH5uJ2m3hD0D54noXZHuwcKh6WcQngD5OsT9ZA80OcPc3sU2V2cT/d8oqxFqNvZH5L7UzLx+U5YgBowD5Agz/fAB0YPWsjMoaCe9Fdxp+LNzOJAC36DWuQKG4madO45sS1qmxTcLapC8rYC1+UrgaRh2ON7w==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:47:08.5580 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1290
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 18 Jan 2017 21:47:15 -0000

Martin Bjorklund writes:
>But marking definition as obsolete in one module cannot automatically
>make definitions in *other* modules obsolete.
>
>(*) _maybe_ 7950 can be interpreted in this way when it says:
>
>   If a definition is "current", it MUST NOT reference a "deprecated" or
>   "obsolete" definition within the same module
>
>If you're in a good mood, you could argue that a child always
>"references" its parent.

That's a massively deforming interpretation of "references".

I'm not even sure this is a good rule at all.  Consider:

    leaf old-stuff {
        status deprecated;
        must not(../new-stuff);
    }
    leaf new-stuff {
        must not(../old-stuff);
    }

My new-stuff definitely references old-stuff which is deprecated,
but this is a _good_ data model and should not be "MUST NOT"d out
of existence.

Thanks,
 Phil


From nobody Wed Jan 18 13:47: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 77455129485 for ; Wed, 18 Jan 2017 13:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 WejycbTAFOGN for ; Wed, 18 Jan 2017 13:47:18 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0102.outbound.protection.outlook.com [104.47.42.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428341294C9 for ; Wed, 18 Jan 2017 13:47:14 -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=JFNSNozqKR+/Or6JFOkPV9nH38oFD5fDUbcdrfbvX24=; b=BvGNrFp7oMdXE22ssVSYGfuRsM8dzE5GeWu98+5I/SVTGYDn8XQ68hrCqL5f8YDknjMZCx+DUZyMXqgplW9EPdF8fSQq4Ii65Qu8R5xl+QCwPWf+sk9aZOfngWd383eXPtxVRjmUY/uWBoYdT3cEDFiNmFQssZNeR5RUvrv2is4=
Received: from BLUPR05CA0060.namprd05.prod.outlook.com (10.141.20.30) by CY4PR05MB2934.namprd05.prod.outlook.com (10.169.183.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:47:13 +0000
Received: from BN1AFFO11FD039.protection.gbl (2a01:111:f400:7c10::139) by BLUPR05CA0060.outlook.office365.com (2a01:111:e400:855::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:47:13 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD039.mail.protection.outlook.com (10.58.52.243) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:47:12 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:39:55 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILdsJK019007; Wed, 18 Jan 2017 13:39:55 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILZpx5039446; Wed, 18 Jan 2017 16:35:52 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182135.v0ILZpx5039446@idle.juniper.net>
To: Ladislav Lhotka 
In-Reply-To: <381D9948-23B1-4FFC-A476-4F96890C16BD@nic.cz>
Date: Wed, 18 Jan 2017 16:35:51 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39450400003)(39860400002)(2980300002)(199003)(189002)(189998001)(356003)(106466001)(76506005)(8276002)(53416004)(105596002)(53936002)(4326007)(47776003)(1076002)(8936002)(2906002)(2810700001)(77096006)(229853002)(38730400001)(81156014)(626004)(8676002)(81166006)(69596002)(2950100002)(86362001)(7126002)(7696004)(92566002)(54906002)(6916009)(305945005)(97736004)(5003940100001)(68736007)(50466002)(5660300001)(54356999)(50986999)(110136003)(48376002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB2934; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD039; 1:6vtUKZguDtteshANEgHNWQaHzlWQ4/4w/tpocT3ZxYn8kDzmExfX6DuXPEE/v88+63Nhj2DGcWF5ysppz4CmDkLHyDXyg7wmGudef0nGCJtNbTDdoZGcFcVBPM2t17hU+tWgu6TDQLcHYOx7N6b4sDlnJQwRmtaa1rcIQQ9hr+ybCrHvs87KrytjAAHwXAbjXi+OcvWKYp1PauHSdgPw5jIqYOhhD6iZKWeoxvYL/bYQOtHI+RqK5kzJM2Wa92v4AyKCJTtO2euTNWzCbOQeIUL1iokFbCIQs/H0+t1ZBFfLL2zNyP4tCPEL/SFByaFgd2bJE4X61fEmcZotKxslC6fnpQe2+hD2YCPsLs0swrGMk3hUB2aSu7Rny/1lftmDisDZmQuyS+TMucgs0qEBlD9sLP5jWqwby5GxmbLq1vtkhMlelhNXW0WSZSIEy3vaNhPn4RbqjZMAeehiZV256Nwr4zmuv61OVGiIPt7K8IljdIgqI1LgwtbVc2LFL7lhpCJJVHwuWsaVn4LiYYLPLln4fARsVLictPlZw1uqHUQmyywT3zdkQsI2g+Armv5d
X-MS-Office365-Filtering-Correlation-Id: 632c4372-ccb9-4155-b875-08d43feb8fde
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB2934;
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2934; 3:yHB2ugFfK13JCZMv/+dVoftykhDCHkcZ9IW4nTcwmVeWVQ8OucpY5JtEYyrKvSyj9vc2+rc2xTdNhFDNKXx8fINIU/PuZ2ERZOcSKsz7Ym3NMGwBI2buuzx2GF85RRUzPL6VYHOQKdkkHVcQQJmnwxv3VAAqxWL7Hqbir/T/T7uOynCLUkfFvnLjlBAgtPwQhWVvcO0BtkfpxUQHr+EQT8CiqhXKIyjS026I7CEbZ/mrPBvF7NSu3ZJKqG4T+IU+OqTYEehXAkh96NTF/46YEh5ZhCsTwcjGo6OD/z+GRf9DmDXbbxQtG/dRz7ZwReAB7+YNDGsSSjthvekhMVnWN5fIGlyafvx5SNUaAb0pL0WJSnQu7pXGmmQVjsqEJVPB; 25:D+iU4j404Ma4UsVeBKbEfkk1SQXb7Ru+mdNgtU2JPdMtla0m0+k6NbXwhj+iCF3v3njeCo2Ghl67f1tVTvR8GUpoRCLWobzuo4Z8uVy+dKScOF8pYBY911sSVcjTNnS3TwagtS+OaSHsC4ine5fnpsvC6+5pUkbcFYGGtLL5L85tRE5ibmve7inYIqiApRCEfIWc9zFUjrJuOA2S1xjymDlSfQryeHX3Gorqs8XZly40hp6PtOAYrmnhVgcBJtLEuz7b+CsT15o1mI9r4ZuyvGHiDofaUGp+sn6yMMewXP2tbjBnjBHmI8vbCTh0WEzhHuqQFR9rBwrHLQmA8vRHA0ZP/nkLSkhR5N+4UKXefBEz3gtRnzCU8/N0clWytg6f2em/bJEzoSVM1rJwkzeVwgl9y6r18DzoWTzhPcZT41gGsgHeIMudJkEKoQPa2YqNBkYfHwi9Rn7QsrO+0ei1rQ==
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2934; 31:mmpRkUzaoDG+4GFK1CJJWMkytvAUlqrEUzzZMLN8wFEaOaJzZuLxsUabyTPfaNvk7tL7PV7gHGaZELinkGtnDy/1h6gT/MEYYc5Q5sk8spczu/RAUYHOYtdJDvu10B45FgsRnpWDBHq7lIGI6hgH8i8G0UH8GOcnJH34wHMTxVzQbvXJWBD5Tvyo0s04UKr6U7W1GQtpD/HU8s6aBfGo9tKNDO+BbXXq2qHZPmtFnZ7N0JkCVu1Pp68epd8Hr62vqNZtQw7XPDcaCoJkC2oEs1D3XqHsGHPfTcI82edIw5yGmNb32Jm0xArC55lpFyNH; 20:tsx64nhRGrUAJpxdCc9ZzemYt7hIPV/KcTthGrQvzmHfP+4e5arTwwHQgj6VHfmnXmFjmWKR1mgf22zbHFfx4AG2d51jQjY39GdomlL1XpENEn3fAYVLY4grbEqH6IH6Ky9pv5QMJiYq5xv08RH2XXMF/7wpfN5okX755IGLRVUJQ2UJlHPkHeszxWIujhZYLA9o0UpKYBTSXzN/RxWEQ1gii3MpjGnz3TK7rsBXSshle9lfVZyNlPb/lj/j/0dGewhe8DC4ZlAhFhCx2eMRMeIVwdR55jzyw6C5yCKQhdHcnPvb171UImRqCDQTr7H18aG+88NXXGYkMbySBI1AGJ26d0gouwsJqgWmjpu4eXMQPVQQ7dDS4JlS6eOP5fE/IeXZxDVjRya+XSaKOgAYNosbB9zMcnw1kWLYqjvQ+dYpwSnVtR5iYk80QhRAG5nDC9iWvvUGeOqJcDB8PCpgaXorjmYO9n4VMaYZ/+CfgeyFGB2++kgiqzsr+WG6U0J+
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)(13017025)(13023025)(13024025)(13015025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY4PR05MB2934; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB2934; 
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2934; 4:PRbABwFMKd23I7do53VofUfzbGGbKr/tvCzi6Vyr4K/4igZ8+j5edMSRV9Z/as8nZEQYvC8KlRAn+X9Zrh6tf3zPHkylwoB5XUNeLf4CtqYqIgF10GDT7f1Be7MnZV5ooOe/U8J0HV3pqRFOSHwxzw9KvncC01igt28+bgyW5FH6vYHEm9o39fUoAh26x3B8yyBMxd9TtKm71s5hkA83l4F6SrZkD8ffGIBwKvJhI1jklIRk7DVz1UIgj3vd4cngPRyGf9iKVFvvCTDLZ2SV3NV8Fbvz7y6ahZr/jpniBV5gqichLml+Hl/DLpQ4WlBxTciVJgQEaS2Yq+oCGUblMWt5PtDS9aDTYPFCvMkUqApc3D23MuI1B97lLFs1BeS0MDKsZVYRFxjOaYuMjvqfyisBzBZJT/Z0a6puRftaiFAh3CiDP+3UNX13ZO9DkvjaI03Fl+nvOsGzH1L9xZNmxULJNSZNNfpD0clXXUWNnGTYxOVKvHFcY8jbaPwFrt5m9BNYs73LNmORCbl2ydtDWqKfy4HzV+VpVzVop8Mdetr3En7Kpc6NK/ItwBfbbZJNPLnqE66qq1yLcELWUEmjlSx4AN6lyTgilUHwMWvZyOo0s2yiVGy+0MoGC+5uFCPFxYTPCigqPHlhrhk4M7x3fZjaDhKo/64wXvceJRVa95VYj8qP9hB4U8JeXOFNpNDq
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB2934; 23:n2VzOFz7t59zpWV/wezJov9P0iiFq/Hcd52aRrxQ/?= =?us-ascii?Q?Ox9p/dKvO/lHP0KKAjFq7mwpRyUUqsk2yywNlQ5JqY4w1bdo86LZCYHgFPwF?= =?us-ascii?Q?mSegfDkvxw0JMhqhNup6VoTGQy9WIyYz4rqCUbQ6bVIEBrujY0Vpctjf7d6v?= =?us-ascii?Q?KI8M3OSY92MdAnS36dxQb062HYu4vAm6l9m1jo3+pxRDo8y/txf46WfvSejO?= =?us-ascii?Q?FeoTpjNW3Ar/at3SKiocZuTXCr82YfXE2I+ViE1/v/3Sb0JERJPyYX49o8JI?= =?us-ascii?Q?o5na9d8pmymEVNJEexnGx97l8seXNBUW0ASdopWZtdUSizEQa0rFsXm82Ixz?= =?us-ascii?Q?pPrrnNFdV48HmKzw1JYmxNy7IRWWKpdKZ8ydm8Rrt5RSn0sXcQvSJgxtpmVE?= =?us-ascii?Q?0QT6Csyjgm2RjjrKld5ujRfuUZUUIDKvyWnIgbOeGThoDStSLogaBG12UPwM?= =?us-ascii?Q?WJkBPfkRTK0Obce1S3yPOlOgOIhNUbyHtc+uVlYeNUtd/qus+1RB0SBW2d9p?= =?us-ascii?Q?pORdjvOw2BOWZGCnaueHe7NgSBZz83/Ra2tMTxHbTpL4aUaabprOQkMFoRH9?= =?us-ascii?Q?gIHHTeB3nED7lcTVWzEuUJiopHR1+yE6WS56joH1qluoV958BC/2/jq9iPo2?= =?us-ascii?Q?6LlUTBZNCmDsO2gAyI4L8A8J1c+YtesH7YZ1N2Oj/Yc7j/B/1R4twQyPu7O+?= =?us-ascii?Q?duHz3isnbMDTwp1/u6tMERnrE8GyyYRJPYIGQtA9zatYzxanTUzqmR4esILz?= =?us-ascii?Q?Ux77Ft9WMcrMt8GSs+G0QkSsQ9TBEhvWnvdYI77EHGqIBXbGr2KATlVKqSG9?= =?us-ascii?Q?uKwe4bJ2lPMAf6mdhxGLkHLHp7JCMiFeRC4VF3Na1jxgPkFoWdpj0VlZB1Ib?= =?us-ascii?Q?ORmNr588rPyx4YCKBnJNFDe15ZPpnzDzfSwLGUOMiuJ10RcNSPF/9Nhtp2Jd?= =?us-ascii?Q?Hg51oynWGEFXgbzeR0t0zyAu9aZ+hzBGdD2dmXBVgAS9reOaga6cU7NfYz4I?= =?us-ascii?Q?HyPuiunqfQ14N6ri2y3YkIurhHKOAjxgRoEIHdq3EeSdQ4jz6PWtZMJNjsRr?= =?us-ascii?Q?rYi4aF2L4YQUnTfJLM4RjiWGhqU6fPEgWjnImkwZbv7JO5zQ9GsPPLVItE2d?= =?us-ascii?Q?ZxM29Bd9fGs+g5u2+BC45HAmH3iAXoOMREEg570KO0cK+/MAs78RCrMAojdL?= =?us-ascii?Q?CM7byuv5tZaDVTsBZ/3lp8bNj6DKHggNFA0?=
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2934; 6:UUWBDWvR5/H060irX5Wdxdm5MhtFgPysOe3l6CguGT2O8dHXYENxjNuCwyShoYo4CDminnASTRplGCwgoPaHy3EGVnjHPVqkP5CqR92DHfaHxUXTDCPkUulK2t2A0JPKcsadbTlRikQqXagEFOntZ/YVFrELRWjdPEoiuYkjZ5ejI4TNgXMGocQxKucjIOMChoKF8fNvJ5ORPJX4b/MoEf0Y0Ju/LPwg2JLi97S4waWPUXF/5TFf3Y1NHAXFrSv+8y02fcWG9f5aYfzjuWKSEBavt7dlUpAuVY8hygLjer88lKsGzMk+DaykY0lSklgJjn9+ho52NkFDWYNx1Sk1CJ1Q/Pr1La/noN0stIPN5j7YuR0QxLK7SLJe+Ajhpnt7BRYt6lmQgdrxkiWXSZ/lvpYNjNGzqc+cnMAoCkNl7N+Af3SyxYn5zE506B6c8SoUOjGYeed023VpLhEN2rG8Kg==; 5:Zj42Voerdpn9tC9eD0bHznkWUtZ4UnFxOVsghNJuuQykDyX5TwUgLwEBzWk5UdltUpIz5xSBn9sbIWp7r37JkQv/XDBpkCBlxsV9JIm9O9bbmtUOWDS0v4KvhAJMHQGSP0PVcMysIrLt7gnxtRp+iw==; 24:9joX8LpkdU+jDko37fm4BuptdXrrSZCTsNk6xrNSnPEaK9zaqLVA8Z/Y6fLydbftnIM9/ifZ5K9LYQL2Q6RELbul4mNH9kyo8vSJieywqao=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2934; 7:l7abzCX3LABHeZsXcu5cuIs2bDUzmGZOeY9ta/k4p+wtfVcBrpxH1cqKJUSQB62Z9Ugz5q/fwRrm2rhmFa6o3ITJiFvUW59+44H1HsuqjMQAvVISTSkymaiWmAOtrGtBNOp2UBVmlH4+NYUf2TNAF+LNEK3BaExVYtyYWV9+cgFpCTRnDc+bpssOCqIpkoCodMKaiqwm7jH2dMTtEB9ZrEsacoJH0MmIl8GER+CKrBcxaeneBYjqrsR+aDnkNjoHy93VEnP7u43MwuJ3WXCw0OjNdZDattVAVQ8zvQqI3WH3HAOwQtZSOb9PFLJM6TVFolKYZQXwSLSDgWYSJ8Qe8QMIWbWF8IeR4fLDBUVcbyob8zvvesZdErYZOJM1JBb2pJnPW9cCYQF5fC+n1zaxwnfrKY5h/QHwqaNLfsIQTx5sevJAIlcUW7y4RAXP/cWHGJwJ9gEMpEtsSQuMZrmHSg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:47:12.6097 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2934
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] top-level mandatory nodes
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, 18 Jan 2017 21:47:19 -0000

Ladislav Lhotka writes:
>>> 6087bis says in sec. 5.10:
>>>  Top-level database data definitions MUST NOT be mandatory.
>Right - I think the following should do:
>OLD
>  Top-level database data definitions MUST NOT be mandatory.
>NEW
>  Top-level data nodes that represent configuration MUST NOT be mandatory.

[old news, but...]

I guess I'm missing the use case for mandatory top-level config=false
data models.  Can you please describe one?  I imagine that just because
my device implements a non-config data model, I should not be forced
to generate data for it when/if that data is not needed.  What's the
scenario where I need to be forced to make this data?

Thanks,
 Phil


From nobody Wed Jan 18 14:06: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 68C98126BF6 for ; Wed, 18 Jan 2017 14:06: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 a8JLNZA_I1a0 for ; Wed, 18 Jan 2017 14:06:26 -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 60EE1129437 for ; Wed, 18 Jan 2017 13:57:44 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id v23so33772966qtb.0 for ; Wed, 18 Jan 2017 13:57:44 -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=fwFwawqr1t5C9sJhCNTQlEQ57yhjUCRa/Ed9G9tnwvo=; b=elMpNNfJ7y9++I8cKDKbUgvr3r6LMdKx9AAxq/yVeoUe05zry4WVaEXi8rfFhj7yoG PpBv5u96NzOQ2jz254ew6FkJiuhMLHHCHeQG7wWl+jmgHsPCSP+/Jc68GyjTR9kmHesJ xxnnSPhxvPv9mNd7WpvCNVYJz9Z+CZYr2OB0w3hJFkrGKlDTNSJOrNEN4ajxqgfTi6D0 WnMIfGN4MuFLW4uRDk4ZYjQU3p/817x8gIUwY24IOzsuI/79DhTWs9xE+mHU+FV/v76L dX1eynXHghopkQAIgU8EnHmCmOxAv6iMsHR5j1Wc3Od5gz5lCftGbiA+MAp1dVVTP+JJ /Ing==
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=fwFwawqr1t5C9sJhCNTQlEQ57yhjUCRa/Ed9G9tnwvo=; b=l6s7v4Xzr5/6dBilqit4pvoJb08wRCRok9cz5f88dTw5J3J+ITnb2xANe9mey4qEKK RKoIsObTFksxqK18uDcQWHD25NHZ2XPsDyFy6fj+/vV6gFyzCGf1Xs/IA/129hjRvdjn p+3dPB1T3ZYd9AKZaksRJIAe0fXaKuD7ltFwhb3s6bvGp8kpuUA6U2IE6b6kdIeHDOot Cr7vCG07ZPg1SA9S71JYNdglV63wvyc8IrGAHRt3NVxMwwnQa7MymmHitQTfIZDgwv7g n2Vk9Nc4pXDbfvfrl8En8RGfsNPMhAyaZZGs+nocYXhvbRQ40YSN95Xza4jirXGm1nSX q0pg==
X-Gm-Message-State: AIkVDXK4CQWHQvaTyC04Nu6ma0OAuGyq4SVfdTuj2M5RyMF4+o1qOyvW6z1UM+BDKlF4JXf0mNKOqPWZzjqyFQ==
X-Received: by 10.55.20.137 with SMTP id 9mr4917862qku.237.1484776663544; Wed, 18 Jan 2017 13:57:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Wed, 18 Jan 2017 13:57:43 -0800 (PST)
In-Reply-To: <201701182135.v0ILZpx5039446@idle.juniper.net>
References: <381D9948-23B1-4FFC-A476-4F96890C16BD@nic.cz> <201701182135.v0ILZpx5039446@idle.juniper.net>
From: Andy Bierman 
Date: Wed, 18 Jan 2017 13:57:43 -0800
Message-ID: 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=001a1144d22699fcbc054665815b
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] top-level mandatory nodes
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, 18 Jan 2017 22:06:27 -0000

--001a1144d22699fcbc054665815b
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 18, 2017 at 1:35 PM, Phil Shafer  wrote:

> Ladislav Lhotka writes:
> >>> 6087bis says in sec. 5.10:
> >>>  Top-level database data definitions MUST NOT be mandatory.
> >Right - I think the following should do:
> >OLD
> >  Top-level database data definitions MUST NOT be mandatory.
> >NEW
> >  Top-level data nodes that represent configuration MUST NOT be mandatory.
>
> [old news, but...]
>
> I guess I'm missing the use case for mandatory top-level config=false
> data models.  Can you please describe one?  I imagine that just because
> my device implements a non-config data model, I should not be forced
> to generate data for it when/if that data is not needed.  What's the
> scenario where I need to be forced to make this data?
>
>
mandatory for config=false means it must exist in an  for a 
operation retrieval.  It is by definition "server-supplied", so there is no
server validation to worry about.

YANG constraints are used on clients.
Not that we are super-server-centric here, but client software
uses YANG, not just server software.




> Thanks,
>  Phil
>

Andy


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

--001a1144d22699fcbc054665815b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 18, 2017 at 1:35 PM, Phil Shafer <phil@juniper.net><=
/span> wrote:
Ladislav Lhotka writes:

>>> 6087bis says in sec. 5.10:

>>>=C2=A0 Top-level database data definitions MUST NOT be mandator=
y.

>Right - I think the following should do:

>OLD

>=C2=A0 Top-level database data definitions MUST NOT be mandatory.

>NEW

>=C2=A0 Top-level data nodes that represent configuration MUST NOT be ma=
ndatory.



[old news, but...]



I guess I'm missing the use case for mandatory top-level config=3Dfalse=


data models.=C2=A0 Can you please describe one?=C2=A0 I imagine that just b=
ecause

my device implements a non-config data model, I should not be forced

to generate data for it when/if that data is not needed.=C2=A0 What's t=
he

scenario where I need to be forced to make this data?



mandatory for config=3Dfalse means it =
must exist in an <rpc-reply> for a <get>
operation re=
trieval.=C2=A0 It is by definition "server-supplied", so there is=
 no
server validation to worry about.

YA=
NG constraints are used on clients.
Not that we are super-server-=
centric here, but client software
uses YANG, not just server soft=
ware.


=C2=A0

Thanks,

=C2=A0Phil

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--001a1144d22699fcbc054665815b--


From nobody Wed Jan 18 14:46: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 2528D129485 for ; Wed, 18 Jan 2017 14:46:37 -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 hKXiS5afMZsr for ; Wed, 18 Jan 2017 14:46:35 -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 40016129421 for ; Wed, 18 Jan 2017 14:46:35 -0800 (PST)
From: Alex Campbell 
To: Phil Shafer , Ladislav Lhotka 
Thread-Topic: [netmod] top-level mandatory nodes
Thread-Index: AQHSV5JowFSjgqzpnUODEPlBv+jO7KELFmeAgAADeQCANGLFgP//jTy+
Date: Wed, 18 Jan 2017 22:46:33 +0000
Message-ID: <1484779593654.22375@Aviatnet.com>
References: <381D9948-23B1-4FFC-A476-4F96890C16BD@nic.cz>, <201701182135.v0ILZpx5039446@idle.juniper.net>
In-Reply-To: <201701182135.v0ILZpx5039446@idle.juniper.net>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] top-level mandatory nodes
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, 18 Jan 2017 22:46:37 -0000

The purpose of a mandatory config=3Dfalse node is to say that the data is _=
always_ needed.=0A=
=0A=
In the case where the node is also top-level, if your server fails to provi=
de that data, then your server is not compliant with the YANG.=0A=
=0A=
If the data is sometimes not needed, then the module author should not have=
 marked it as mandatory.=0A=
=0A=
Alex=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of Phil Shafer =0A=
Sent: Thursday, 19 January 2017 10:35 a.m.=0A=
To: Ladislav Lhotka=0A=
Cc: NETMOD WG=0A=
Subject: Re: [netmod] top-level mandatory nodes=0A=
=0A=
Ladislav Lhotka writes:=0A=
>>> 6087bis says in sec. 5.10:=0A=
>>>  Top-level database data definitions MUST NOT be mandatory.=0A=
>Right - I think the following should do:=0A=
>OLD=0A=
>  Top-level database data definitions MUST NOT be mandatory.=0A=
>NEW=0A=
>  Top-level data nodes that represent configuration MUST NOT be mandatory.=
=0A=
=0A=
[old news, but...]=0A=
=0A=
I guess I'm missing the use case for mandatory top-level config=3Dfalse=0A=
data models.  Can you please describe one?  I imagine that just because=0A=
my device implements a non-config data model, I should not be forced=0A=
to generate data for it when/if that data is not needed.  What's the=0A=
scenario where I need to be forced to make this data?=0A=
=0A=
Thanks,=0A=
 Phil=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Wed Jan 18 14:53: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 8DA1D1295BD for ; Wed, 18 Jan 2017 14:53:09 -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 FnIaluTUaCtM for ; Wed, 18 Jan 2017 14:53:08 -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 173841294C5 for ; Wed, 18 Jan 2017 14:53:08 -0800 (PST)
Received: by mail-qt0-x22d.google.com with SMTP id v23so36298255qtb.0 for ; Wed, 18 Jan 2017 14:53:08 -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=NiN2e5RZHFpK7Re4idw5h0nPuscS8PhfKbDyj8/Db/Y=; b=mJI2IjvrXXltTZRDtBDUS2jw2VW0IB6xXw3lumBJqnGtMpHAqkZv0ooXZbz6sefybs gwWgeph77vG2lI7SzcoNKcxuN+hh3NqFUuqzayM0yJhuXsfEpgJKjiTX2QP7PtT6MXUP jSaZdHvO4CN266W8fnqYXyo6+1uytbYB7o6YOLd7jplaXPRbf3on3VX3Dz7hI366183g 8izaWB6/z9CzCOLxM6H6m7ZrC7PBtuLVDs6sj1hN6rRfOlEKoZ5UtIc5laMZVgkiqgF+ 0bkIZk6gSOgit/Hl44uJPlOLlysuqx+A0mGr8yMjWVQBHYYxIiijYqAX+Q3lx/CBXwK3 VSMQ==
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=NiN2e5RZHFpK7Re4idw5h0nPuscS8PhfKbDyj8/Db/Y=; b=gK7U91UTCQCtVY7mBN/27JtuU9sHfCyc8HgzmTH8vWIkkTd8axw42qPbfeK8ifvsqE sDYxWWwcafi+0WQz1SkO2zh+JfNjmkmfQUZlxTMxz6cl44yw/xoIauk6meyaWVuzba6j KIBEB4+lAyobiiT9cI6CVeBOW26APgmVY9bvlKSDcAkSaWAbU34Y7AFiBohFJdZv/joK owJ1lXIig2FwLP6qyRQwwEAUyPENhLaS7+v0Y6vudgdKuaa/S6hs4gS4aYu1vofVBk5e p4NYUEIZoH6Fb97fZ+HgpZ+Vl2vGxqcMkdzAgY5e1vOPIFmd1OgCTGjCtqD7wnuN3uo1 vzgA==
X-Gm-Message-State: AIkVDXLsPHxcJItxjGRqhq+n1th9p0NcnFEwsB5oa+usMfJPPZ5UcqWTKL9lIyf1Jw9+YXi/9jptzxbIqPh85A==
X-Received: by 10.55.152.4 with SMTP id a4mr5068554qke.69.1484779987265; Wed, 18 Jan 2017 14:53:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Wed, 18 Jan 2017 14:53:06 -0800 (PST)
In-Reply-To: <201701182132.v0ILWhfx039384@idle.juniper.net>
References: <20161222.114940.1495001277375813904.mbj@tail-f.com> <201701182132.v0ILWhfx039384@idle.juniper.net>
From: Andy Bierman 
Date: Wed, 18 Jan 2017 14:53:06 -0800
Message-ID: 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=94eb2c07ecfab60af805466647e6
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 18 Jan 2017 22:53:09 -0000

--94eb2c07ecfab60af805466647e6
Content-Type: text/plain; charset=UTF-8

Hi,

The reason the status-stmt is broken is because status=obsolete is not
inherited from the parent.  The status obsolete means it is gone from the
server.
Since YANG data is hierarchical, any descendants of the obsolete node
are no longer accessible in any way.


Andy



On Wed, Jan 18, 2017 at 1:32 PM, Phil Shafer  wrote:

> Martin Bjorklund writes:
> >But marking definition as obsolete in one module cannot automatically
> >make definitions in *other* modules obsolete.
> >
> >(*) _maybe_ 7950 can be interpreted in this way when it says:
> >
> >   If a definition is "current", it MUST NOT reference a "deprecated" or
> >   "obsolete" definition within the same module
> >
> >If you're in a good mood, you could argue that a child always
> >"references" its parent.
>
> That's a massively deforming interpretation of "references".
>
> I'm not even sure this is a good rule at all.  Consider:
>
>     leaf old-stuff {
>         status deprecated;
>         must not(../new-stuff);
>     }
>     leaf new-stuff {
>         must not(../old-stuff);
>     }
>
> My new-stuff definitely references old-stuff which is deprecated,
> but this is a _good_ data model and should not be "MUST NOT"d out
> of existence.
>
> Thanks,
>  Phil
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--94eb2c07ecfab60af805466647e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

The reason the status-stmt is broke=
n is because status=3Dobsolete is not
inherited from the parent.=
=C2=A0 The status obsolete means it is gone from the server.
Sinc=
e YANG data is hierarchical, any descendants of the obsolete node
are no longer accessible in any way.


Andy



On Wed, Jan 18, 2017 at 1:32 PM, Phil Shafe=
r <phil@juniper.net> wrote:
Martin Bjorklund writes:

>But marking definition as obsolete in one module cannot automatically
>make definitions in *other* modules obsolete.

>

>(*) _maybe_ 7950 can be interpreted in this way when it says:

>

>=C2=A0 =C2=A0If a definition is "current", it MUST NOT refere=
nce a "deprecated" or

>=C2=A0 =C2=A0"obsolete" definition within the same module

>

>If you're in a good mood, you could argue that a child always

>"references" its parent.



That's a massively deforming interpretation of "references".<=
br>


I'm not even sure this is a good rule at all.=C2=A0 Consider:



=C2=A0 =C2=A0 leaf old-stuff {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 status deprecated;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 must not(../new-stuff);

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 leaf new-stuff {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 must not(../old-stuff);

=C2=A0 =C2=A0 }



My new-stuff definitely references old-stuff which is deprecated,

but this is a _good_ data model and should not be "MUST NOT"d out=


of existence.



Thanks,

=C2=A0Phil



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--94eb2c07ecfab60af805466647e6--


From nobody Wed Jan 18 15:11: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 7F77E1295AB for ; Wed, 18 Jan 2017 15:11:41 -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 QDYjwKslncBg for ; Wed, 18 Jan 2017 15:11:40 -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 463031294E9 for ; Wed, 18 Jan 2017 15:11:40 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 10A726EC; Thu, 19 Jan 2017 00:11:39 +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 IP03LNFCz6os; Thu, 19 Jan 2017 00:11:36 +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, 19 Jan 2017 00:11:38 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C505F200A6; Thu, 19 Jan 2017 00:11:38 +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 ZrZXDMu32Osw; Thu, 19 Jan 2017 00:11:38 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7178E200A3; Thu, 19 Jan 2017 00:11:38 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 6A1AD3E29FFC; Thu, 19 Jan 2017 00:11:42 +0100 (CET)
Date: Thu, 19 Jan 2017 00:11:42 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20170118231142.GC6215@elstar.local>
Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" 
References: <20161222.114940.1495001277375813904.mbj@tail-f.com> <201701182132.v0ILWhfx039384@idle.juniper.net> 
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@ietf.org" 
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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: Wed, 18 Jan 2017 23:11:41 -0000

On Wed, Jan 18, 2017 at 02:53:06PM -0800, Andy Bierman wrote:
> Hi,
> 
> The reason the status-stmt is broken is because status=obsolete is not
> inherited from the parent.  The status obsolete means it is gone from the
> server.
> Since YANG data is hierarchical, any descendants of the obsolete node
> are no longer accessible in any way.
>

I am not convinced yet that the status-stmt is broken:

- Not all references in YANG are hierarchical nested nodes.

- References can cross module boundaries and also organizational
  boundaries.

- Tools can create warnings if non-obsolete definitions reference an
  obsolete definition so that editors can make proper updates.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Jan 18 15:42: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 7623D129410 for ; Wed, 18 Jan 2017 15:42:10 -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 AKGLGdfITdJG for ; Wed, 18 Jan 2017 15:42:09 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 26D5C126D74 for ; Wed, 18 Jan 2017 15:42:09 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id x49so38002400qtc.2 for ; Wed, 18 Jan 2017 15:42:09 -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=QDpKIH7EBVe9pbcr2grvreIjEuirTW4TDyLwp/2Dmz4=; b=IqXBsBpQOOGs1FO+fOP0dwk0jlpyoLXFPq70tRk8U8yyhTaniGqKYUYamXKc1PSPJH HndT4HWNcSjMcbNHfvI4TiKYQEG8hb2pGnSRAWU8rRK6sHlerM7A1dsR9nUZPDT1V1Pw 4YrMVC3SIZ7jQcqe+j4yvWtfAOPj/D4+9z1Ic/eFLd0PXNrr4sXlMNoxoY/XOOrhbLO5 ZYKNqQiWII/OqxEwullxqB2JOtGrYnHD1XMdgjU6zAWGsm9ad7yq3OlXxaew8WGC2XnQ g78sH09tZ1sgceeRczLv5LBW7ii61H00MyAQ53ZjuUXROtINFgjRX3+zpdPAATKwBByu a+oQ==
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=QDpKIH7EBVe9pbcr2grvreIjEuirTW4TDyLwp/2Dmz4=; b=twL1FnkiMDZI1UtgQQe0afbK3nJElz/HgvISwcMSFP5KidcQzrgIvyG0FdzWbdOHZE KjRMQeFityig2nPn+7VVkdrPHRVoTkWzMJj1N3MiOjIgZNSsq1erzEl1phiYsKwc9xDz ur21qC0b1EsGfX7ZH4x+ojv5rpnkmOIpV72VRzUkzleAI6IGqoiD9skcAmjhUiZdYdHm YjFiamfSaUxNpD4lZBPGyrlLSl3R9UV/9ZV/b1l++/ZP7RBQGs82dJkqgtjdD9OCahg4 zHgNuCGqTG4v+tdSgxzJ3twRHfyrjSy2ToU4pKJbJvhhiihnhB4p/fcTcQ0+cUm/afbb glvA==
X-Gm-Message-State: AIkVDXJ8Up9fGgMBa/2yY9nCZJCk3S77BPuQOX5MFQtHg5FPw8ofqteP0+XhGQP9bVrmEpnj46OzlIgw95iAoQ==
X-Received: by 10.200.34.77 with SMTP id p13mr5476077qtp.35.1484782928162; Wed, 18 Jan 2017 15:42:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Wed, 18 Jan 2017 15:42:07 -0800 (PST)
In-Reply-To: <20170118231142.GC6215@elstar.local>
References: <20161222.114940.1495001277375813904.mbj@tail-f.com> <201701182132.v0ILWhfx039384@idle.juniper.net>  <20170118231142.GC6215@elstar.local>
From: Andy Bierman 
Date: Wed, 18 Jan 2017 15:42:07 -0800
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Phil Shafer , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ff8b20094c5054666f79e
Archived-At: 
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 18 Jan 2017 23:42:10 -0000

--001a113ff8b20094c5054666f79e
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 18, 2017 at 3:11 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Jan 18, 2017 at 02:53:06PM -0800, Andy Bierman wrote:
> > Hi,
> >
> > The reason the status-stmt is broken is because status=obsolete is not
> > inherited from the parent.  The status obsolete means it is gone from the
> > server.
> > Since YANG data is hierarchical, any descendants of the obsolete node
> > are no longer accessible in any way.
> >
>
> I am not convinced yet that the status-stmt is broken:
>
> - Not all references in YANG are hierarchical nested nodes.
>
> - References can cross module boundaries and also organizational
>   boundaries.
>
> - Tools can create warnings if non-obsolete definitions reference an
>   obsolete definition so that editors can make proper updates.
>
>
yangdump-pro has warnings. pyang ignores the status-stmt.


The text that is broken is in sec. 7.21.2

    If a definition is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.

   If a definition is "deprecated", it MUST NOT reference an "obsolete"

      definition within the same module.


We do not seem to have any agreement on what it means to reference an
object.

It seems obvious that our intention was to disallow current child nodes
within an obsolete or deprecated parent node.

IMO we need Errata to clarify what it means.
The YANG compiler MUST generate errors for these 'MUST NOT' violations in
the YANG syntax.






> /js
>


Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--001a113ff8b20094c5054666f79e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 18, 2017 at 3:11 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jan 18, 2017 at 02:53:06PM -0800, Andy Bierman wrote:

> Hi,

>

> The reason the status-stmt is broken is because status=3Dobsolete is n=
ot

> inherited from the parent.=C2=A0 The status obsolete means it is gone =
from the

> server.

> Since YANG data is hierarchical, any descendants of the obsolete node<=
br>
> are no longer accessible in any way.

>



I am not convinced yet that the status-stmt is broken:



- Not all references in YANG are hierarchical nested nodes.



- References can cross module boundaries and also organizational

=C2=A0 boundaries.



- Tools can create warnings if non-obsolete definitions reference an

=C2=A0 obsolete definition so that editors can make proper updates.



yangdump-pro has warnings. pyang ignores the s=
tatus-stmt.


The text that is broken=
 is in sec. 7.21.2

    If a definition is "current", it MUS=
T NOT reference a "deprecated" or
   "obsolete" definition within the same module.

   If a definition is "deprecated", it MUST NOT reference an &quo=
t;obsolete"=C2=A0
=C2=A0 =C2=A0 =C2=A0 definition within the same module.


We do not seem to have any agreement=
 on what it means to reference an object.

It seems=
 obvious that our intention was to disallow current child nodes
w=
ithin an obsolete or deprecated parent node.

IMO w=
e need Errata to clarify what it means.
The YANG compiler MUST ge=
nerate errors for these 'MUST NOT' violations in the YANG syntax.




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





--001a113ff8b20094c5054666f79e--


From nobody Wed Jan 18 15:55: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 A4AEB12947F for ; Wed, 18 Jan 2017 15:55:29 -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 OtOnd951qtoN for ; Wed, 18 Jan 2017 15:55:26 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0135.outbound.protection.outlook.com [104.47.33.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97E71293FC for ; Wed, 18 Jan 2017 15:55:25 -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=ZUKYCJdKgzH7s9AbtmGAyOlerIBcJdprqKVMIbQXwKk=; b=eeNskTNavjMcH0Y3cJOY9jVQT2PIZ+O2kb1XrG3I6r/GmRgl3vnkys3ryo6JYEq1PL5NXcYIVk6A0iTbk6OaUCcK2FxK1wmCono84UkecG9IMckZu/V9J8XvEuWOCS7U4nkek7AwX7M3T/3Q+d3t9SFcCZQsp1MYm9vGVX1n5Oc=
Received: from BY2PR05CA045.namprd05.prod.outlook.com (10.141.250.35) by DM5PR05MB2939.namprd05.prod.outlook.com (10.168.176.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 23:55:24 +0000
Received: from BN1AFFO11FD025.protection.gbl (2a01:111:f400:7c10::173) by BY2PR05CA045.outlook.office365.com (2a01:111:e400:2c5f::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 23:55:24 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD025.mail.protection.outlook.com (10.58.52.85) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 23:55:23 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 15:55:09 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0INt8ZV021173; Wed, 18 Jan 2017 15:55:09 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0INp5DS040551; Wed, 18 Jan 2017 18:51:06 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182351.v0INp5DS040551@idle.juniper.net>
To: Alex Campbell 
In-Reply-To: <1484779593654.22375@Aviatnet.com>
Date: Wed, 18 Jan 2017 18:51:05 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(2980300002)(189002)(199003)(377454003)(2950100002)(110136003)(4326007)(5003940100001)(8676002)(53416004)(69596002)(50466002)(47776003)(8276002)(7126002)(2906002)(81156014)(54356999)(53936002)(2810700001)(50986999)(626004)(54906002)(6306002)(105596002)(81166006)(7696004)(356003)(305945005)(97736004)(229853002)(76506005)(48376002)(38730400001)(106466001)(86362001)(68736007)(189998001)(1076002)(77096006)(92566002)(6916009)(8936002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2939; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD025; 1:6fxJwhDNzVEJnSUD+/P6k0rqsOJDbm/PeEFkV0s6G5KkX3L9ey9pyN3gXfFQbl0SNo7ObycRLrUf5O9mw64MlmCwrB19vl/y/inVSTwOzP/Y+9ZL+IphI2Eh72WXSrPS++gcsA7ekM3+NeQy4AVuVBn5gEb4pUAC255s7hqf95zzGNOq8tY9YkKowkV8pClGag63PWWYoCniL2AllCGPPzhxSuZb4qQi9wLYlLncvnut4gESTewzwcA7jOSzS16bpMzOhJpA8WSEzGxR96PE/5wKFf0OApMBtdtzZpHPVFSut3Z/MnWY7U2NRXlv8PmWTgob5ttUTFHUkhe/Wh793VagDjymgNvOt8j6l3HgVV0Fts1zVBFOMRuZmolpAoCPKYeHB2TxHTCiYQHkdCupuqFwK1vGgfijfocW3cNiad8fVv+nLl3kNiGwsX4sUH00T+V2mvopitSQ9DLXjVP0J/AXipXE5PRzZp6NUxmzg8UYXQm+3OL3qowDJsK21Uw0X04BlER0HruSumvbHk1fFHZ534ZzgqymO6VFXwgqNouESVEUD25w7er1Zd2wyJAo
X-MS-Office365-Filtering-Correlation-Id: 34afd427-f164-47df-ed6d-08d43ffd77dc
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR05MB2939;
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2939; 3:0EXwB9EiUQT0qmOEEf//whRRsJXY6K4ryzFlvdBHIS1V0DkDBqvLZByNIY7wmHEoQ/RU+RAJJNxf5ejrpQlqCxNZeZhccgDn0Okt+Np1t5Z/6BUiX3HzYxHe9Zib8RUFDuJXqVJZcFmQ3CC3k3Ceu9GD8XH6ghGioj9BY1J8gzGpESEcuyACmhD8+9CfOcQkHF+Al2T4C8FZjjOUSr/q0m1mdYpAO/3FjhzugW0no581Jp82ufJQ5wmvkiao90qnEoTUdN4ryd7di0IyRpruLX6VLTkPTF9nwbdEgWhibkJ4b7Tl4YriI1binkRWFh4rrncUMvAKSXETNrU69hTsQQRCHnnff33UgDvNvCLwcxP2IR9BhuIIe0Q6wmkX5SFb; 25:6/PdUXaYQZJKjrxDXETSWH6Y/hXouwnAqNkE88udCfkhiV9vco6h+XxsUHhsXxenh5gcXVoHUPPLKhTxTrw9ibUUALMiMq2nfMpS0f5EoCGBAK8Zc6Dg0/vxSREv9yy1Jy3VH9CK3aqn8yJIwMA7NwRG5ZFQpPDT1/ApvWm4IAUWqBdId5FU5anGBhWu3Ip3JWH42VnAJ573paSfiarOa35mb1mU6g4KGCpFAP9SZrA0MCe7PRGhVgFysi9jCsVswDwDsZmzGf5PfdFmScSchogL+Tu/IahkM7bhbr5Yr0nrX5JY1VSoS0Fo5Y/so5MfEhKJPs9/AUEFkR41NSXk7SJ9uFcsByBYItoroeHadRkwKeVYLA3UUf4nyzkhlQUUtBFXjG9U9Bel2B0TpBssI7ftgM+4DzUT/Ppikcv1zIxaxLcxUqITf6Fyl5AYHldcvCynzfyhqErNU+oNZquNTQ==
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2939; 31:b3c37MPduW77qypWq5dAROwi5BpvHdA9EiKKciUGNwBgOVyohC3DYWeqcupgWP1r00GqzPFSnr2h/3+HgXrtBSaQc3PqLVVuKYXOqiGsvsX2oiKaSCl8R1Zs8xZoZyjpEn6ROYOZthrWylSy6X/R+RVj0khcHeoJ4BhMEoylCiiAaEs0V7qu2UXTRRkT31MBenxiPsn9czIQaDeuyWGfriuzBbU8MB9EjbqJgNpGryo4clkzAsWssJtFE7smbs5kT7Z6GBvyFINdhuHZJQJwMw==; 20:IGKvTh0PK4TZnc1FawFvypUtH0+UhFuSEonjma9ZQgePyXsAHXtZm6nqPrkd5ChWSEourn5i8zFf3+6748JaKFWUvYJMfACQTLCbeI7/OO1XiSFUXJygHUZT+n6jOCIZfUANAQl3m1Sk5BYuVjDH5cTRjoRbXzocDJXznhDEjFVy+asxcKrGf2tY27Iy31TRQYJSvZAqEEazKZO8gEVT/0RP2u3uG4bdVclmFkv9Qhw66bv6z63AMFb1K0BfqYuZIUSxqqm7FtK5kDreX2HN73ExiNtKsBbAY1onNjXvSoKBF4nvVsPkBp6jdtJY1iJYABzx30rLl5HCYvoMVBY/mstNcB989zy7c9Qb1uWbmiGGi9dVdI0W4zAweI8WV28+O78fyA70XW/VoKwV1SJTp3WhZR/fcHChIdvUk1dbzm6lLqoGC+QtLNIj/rx1bSpP9PWvKwlI45Nd4+9wq0n2VlEUOqd15CaXaRYPJYWqI1ce9XsG1ZmGvcluAWKXfKzF
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(13017025)(13015025)(13024025)(13023025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:DM5PR05MB2939; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2939; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2939; 4:8RvlC5RrTgPdUw5WfblETSO2Xllf195mo5X26FILJh0JxRo3vvv4Vy+DCTA+xa3ONOk1uBg2s71WZd3pHgbvT4Ed6IcJPo6AgvUTda2Cx3KF9SLoC6rp+4DfI29+SZ5TEgk4HuCr06KtZniYFy+YA6otn84pwvNAW3T85So+Rl9gcBr+zw9EimOjxF6zMMYccGShfkBXFxx/spKQouQkPi3PKsHDkamc9f1irB/FFwzNghJEOpUd9NPf472a6p7/cdepLyoPCK+QgvOkEV7+6zUMhnGXHjUvDhAxcwy9gm6S51FbDV9ueemi4xH+UysBLv+NlS+JZEw3q6TDF/YO7a1bdYEM7IBYDvvDT3HCawuyGMe6LASlnxc5vNnlLDElee06UMmHzelG+83+i/uFsYbSFWgyDHvvFQ1yRhQXVr8/uF8l9UwrQEe9s3bDk+qm2TN+ndsLbL8pB36RAU8kp+DCizIszfCkvH6ofiLQS1BycIfq9WFedxaHlPANAHP/cGUaXs08e/G62bZMvIBdB4bcH3yH7AvcE4rg/lxfcwHz+F4eF0SLmL8shxp2jLvwkwclklKE2UD83eUon4Tv2wlMheuAztaFQci2jLMX4c6WeeNeUW86qiffE9wYXlCu3esViKrYwWndojzyaopNTlf0pWQbn4mUg8gdjrRxrbcmK+owoN4kQoyeG2KnYavW2mRTiVCchOI+rsKZou+hF+jSEuq1JoKg/uw2fXaq29eUbMf10Xg91HyhMkFlXobEdYdP2GyoUKPOZv6PIuMywA==
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB2939; 23:05OHxwdRV2DQJakkqF8byy0h89EibgdvoI23JZqRP?= =?us-ascii?Q?9vTTZkjiLc8IuillEyPZMbx8JYYkbFL9+GbU58NhrkMib+VSzpv5IfigmhlY?= =?us-ascii?Q?K7W8Y9kDhJkdCslxSPpm6yTIWMWzx+cnoaUrHFCXMkNb2xcQzDIMhXi1CX6I?= =?us-ascii?Q?VeidpI1nIpy4N7MS8l6A4rpzXvSIRRRC4vU1PYqk8jgRgFjj0YTzRKh2T+Fn?= =?us-ascii?Q?7O1j+zCPQxltfqZicBSlJHqweMQSGECc0MAFUZL1VzgvlY1ixP3h+J8gSWXH?= =?us-ascii?Q?uSH4Y5KxjgKmoSdK15WEsEXzS0CtcKIj1hYEbX6YHU/pJpgto/1eU3OZrOHe?= =?us-ascii?Q?8kuZBS8U9F50cmNRKJKSCD5Fcy9lxcfoibzTW+TGUaBKrvoyPlla4SbfAVZf?= =?us-ascii?Q?nzZrq16clUezHJEaVyiLiM/saqYiCfrb8MKGuK/Vi5JeINdvu0ImZDdl2twJ?= =?us-ascii?Q?SyEcXIgq3glOBgJJRBR3RVse2aNOmqm9mrB8XKm/lQMzuzOlX2n83U40H3Xs?= =?us-ascii?Q?KSePUCB9p2+IfCArUyBKe0hXkvTh7vGkCaFI4eLFDtLynPuzA+ZYRy90UJ2d?= =?us-ascii?Q?DYkOThjpPVAquLhv3nkYGTHE+KkpU6rsh3jn4oluCaN7SZLFhRMODKtNcK2c?= =?us-ascii?Q?dNvm90/yxl/Dqvdi6qJb/oeYhSLApAKrwBRezFVHrJikFYM9+X2XRD66zfWd?= =?us-ascii?Q?UvGb2Q05OKQjZbARU4FBB7JjLT7G1PaDbDYoYIpYPyjy2l049N631r5b6YFs?= =?us-ascii?Q?ZSopLaKH7LdclEce3+2k1RiFW13qge/OtwrekBuzSUMFk4KCvPWCR39D9IOX?= =?us-ascii?Q?w+2txe4ZGTpuIC+ZhAbnS4ZLAc0TxbjOm1IYkXBBNRs6wwSqANMUw5q2FhKz?= =?us-ascii?Q?ZR6Wr12dcE+neH+5tGB4rShUtlTWvxeJJwRob2xC02TjDfvga7mUbU2tYvAP?= =?us-ascii?Q?EPYmlVFVqtmY5whmFAY2F/aLIUg22Adv+Ro/+Zq5Xt9goyOJY4OCxgPB0b1/?= =?us-ascii?Q?7WBagoFKTqFxFHj/eyjf315aNsmDj0ZudU6netzKtybUMex6pdYMq/hPqWQ0?= =?us-ascii?Q?1vu6+pqTnnevkaIOKiP3UzccU5OkTHRz7/DMDy6+v0Q1SPMd5MwNAav2tbzQ?= =?us-ascii?Q?OhTabkV/862nAMPQcUnTsJ8tP/GbdSTD5Z5aV/YboHqTdn6bj0kpYxqzr3h9?= =?us-ascii?Q?f1xtd/wdxsUeYzaPkSGZGHXu9JkCgxHdD/0/ehJXV7HzKSu9STs0QbStFfpq?= =?us-ascii?Q?Eg39FTa42705w1HcAE=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2939; 6:I9Yl7VUMzKzHmFK9nv77HAv94L02NOA2Zo9iGvaP7x2lIXBEUqzKa4fRiCL3zZuPf0+XAb8ftO0tWV+/FX8sUvT/5KPmsj+x5tmhBHxqaSbzcPI46+fciY8pUWtsy2t99H+3bFdCPX+i/HHXp0by70oiUt9vJMKB14TztimPyGTYORVuMIahZSDixRo0UJOEsFskwIiCc3H57kKrYRe5dj0bY/+0RNFmnW27meh9ai1rEOhLumqLXh0g4uuhQiZbqTbFfySnmpSgcLKT0GXlCyzlojKD1FoQFKzK5q2lqtfr/OSsWgkMgBw6AkvZOibzlp/q6vNvqqHXLrt/altsBp52VJ3N6mMPio6fXC2QO1gRQSK14xu7nnPrRaWkNz8q0RTyJPMqHoyDj/89P6cMjmqSpkPL2ZS60v2AKLyFNc8o0AuIJI2oq/zunZKU+Dp9QH7RGF30MvdLLZnELbsVyQ==; 5:zxj2U0Q6c3Vc2kZ8pIidgM3haW2dQui+V1ZU5r/D1gB4+V24wDFtMC2c5MhG38Lj4coXf1szylQmbsvfYW9Lp/tq/3e1zVzULe8Yb+/loAIaXL26zc2RtG2cWidmdppESQFHkkm86NVt33Eu2cmyiQ==; 24:Spf479k5Zx2mX/i6avTt999DlnRAJWoecu1vYhXlO6iTwhy3Pf/7tV0VLZy4GBD7kHo5i70oO5QUH4LdtnlWMOVr2iH6BkZ4mTKhgV8+c74=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2939; 7:bf53uf+PtXSfvZsCwd8zpy22awkRutx0DeRGwT2XnMYhFA2r0ET5+Dqp3D+mLVM0ZUpaSSOI56+S2vndcpCUsv/uC8ds2eMIEFaq4cWoATU7mnhUlxEBWmjtdL9rlj0uCSnElN1kql8lpZPJlzu9IQqI9i4VQPdA2a7eDAPlqxWRVn1TuYYe5eYgC9Nbtnkpu5NeoCPHCRZvsev/WXd3yHPALVEefHqjGlMbb9jjK2wz+vZV+iFWTAzHhiSKrGYZ/195iBZ67YDV4Y9FXQjgChllGl+ms1gW79gix6ANQH+yDBNq2F6K2uppx7Zz+ly+KfogZ8Z+kXKOYqLgk78mwQTyyM7RRZpam65fgcvkpsOuzHeEkTz8pNg9n8Fe9Gl+P4Dt9O/V2riB6ff5xGVLSH9PEGEkwbW0l3uMgGnehwi/xT6+AIwdT25c0zeqZxcl2GzJgVKHKtAg0T5miFZiYg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 23:55:23.2268 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2939
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] top-level mandatory nodes
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, 18 Jan 2017 23:55:29 -0000

I was really looking for a use case.  What's is a specific scenario
where one would want a device to always report data even when there
is no interesting data to report (since interesting data would mean
the device would want to report it)?

I've seen this misused where the modeler wants the device to say
"I've got no TLA data", where the model should be happy that being
implicit in the lack of data.

Thanks,
 Phil



Alex Campbell writes:
>The purpose of a mandatory config=false node is to say that the data is _always_ needed.
>
>In the case where the node is also top-level, if your server fails to provide that data,
> then your server is not compliant with the YANG.
>
>If the data is sometimes not needed, then the module author should not have marked it as
> mandatory.
>
>Alex
>
>________________________________________
>From: netmod  on behalf of Phil Shafer 
>Sent: Thursday, 19 January 2017 10:35 a.m.
>To: Ladislav Lhotka
>Cc: NETMOD WG
>Subject: Re: [netmod] top-level mandatory nodes
>
>Ladislav Lhotka writes:
>>>> 6087bis says in sec. 5.10:
>>>>  Top-level database data definitions MUST NOT be mandatory.
>>Right - I think the following should do:
>>OLD
>>  Top-level database data definitions MUST NOT be mandatory.
>>NEW
>>  Top-level data nodes that represent configuration MUST NOT be mandatory.
>
>[old news, but...]
>
>I guess I'm missing the use case for mandatory top-level config=false
>data models.  Can you please describe one?  I imagine that just because
>my device implements a non-config data model, I should not be forced
>to generate data for it when/if that data is not needed.  What's the
>scenario where I need to be forced to make this data?
>
>Thanks,
> Phil
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Jan 18 15:57: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 A03E71293FC for ; Wed, 18 Jan 2017 15:57:10 -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 40kyJCB3yAPZ for ; Wed, 18 Jan 2017 15:57:09 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.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 9952D126D74 for ; Wed, 18 Jan 2017 15:57:08 -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=xWDXR/PYeyIjDYoD3+leNK6o5L+X11DqgQQz5IEeYGE=; b=QQZPLjY/XtXrPjJNCSiEIbIqlZn82Nl99CcbStmD7nKaaCvaVoxCTGv707E8yM2xUA6MBJ/Kw1+DtpkSgskGYXdi1UOVaEmxFuBe/Pmr+hyPTigEc+bwibcC7I8RpiC12CD9MXCgFq86gteerXIdBspogwmu3ZSUpOvZsGSAZBA=
Received: from MWHPR05CA0009.namprd05.prod.outlook.com (10.168.242.147) by MWHPR05MB2944.namprd05.prod.outlook.com (10.168.246.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 23:57:07 +0000
Received: from BN1AFFO11FD007.protection.gbl (2a01:111:f400:7c10::106) by MWHPR05CA0009.outlook.office365.com (2603:10b6:300:59::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 23:57:06 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD007.mail.protection.outlook.com (10.58.52.67) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 23:57:05 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 15:57:05 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0INv4HI021494; Wed, 18 Jan 2017 15:57:04 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0INr1SU040570; Wed, 18 Jan 2017 18:53:02 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701182353.v0INr1SU040570@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Wed, 18 Jan 2017 18:53:01 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(39450400003)(39840400002)(39850400002)(39860400002)(39410400002)(2980300002)(189002)(199003)(68736007)(189998001)(2810700001)(53936002)(229853002)(38730400001)(54356999)(50986999)(1076002)(97736004)(77096006)(54906002)(69596002)(81156014)(8676002)(81166006)(76506005)(48376002)(47776003)(110136003)(5003940100001)(86362001)(53416004)(8936002)(626004)(106466001)(8276002)(50466002)(7126002)(6916009)(4326007)(7696004)(92566002)(105596002)(2950100002)(2906002)(5660300001)(305945005)(356003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2944; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD007; 1:UgSXGyR0I8169HIg3SQXu6OMYFlUtbWg6UvjOIRLTsMlVF03tBRmfxiX/h1XPLY7xo8JX2ym5FHmp1CL9gXhfOrL+SqFz7AiQBEa4pC2ZN9eVoZrsQ7SaY5K5Q2FOXWfc18O7+0QXWEI6l91pgbYNr/FSKdXfyqSwSimYc2FLsrnzIf/9S56jC4s02ovl/pP8pkVMnKR8h1QnQy4micbd3AIr6dGbQ9ZzH3lbJzybRAi75BMB5izGgNKJmBNTq+ikRkdsO572yXZ8X0o9E9l+TnilHJyN/VUo3xojv3oTDDiGtoL9gmzilez3/TE0zTNF0oCBuTaYZcsXJcYcE8nKt3e/b07if7AU+CbkDGjkSEgRsIqp2c98ZI7urWla0R9bAdqa6xshLQuz8hhWMsdHoD9JfxASoc1bTLyTk9JUWasJkO2jsFfWvgPyhHzey3Gg5bjKsSIT9kzolbdFkQbth1AacyR2rnCp0aszUG89c3pgwlB+QOBEyDzdli+hznGp5TBBLNVeYkt36ryBFZ2hBomzdVqTGxCg/Auq7YRdFeS+3veuNVkCiaers4WfP33
X-MS-Office365-Filtering-Correlation-Id: 26779fec-b744-46c4-a01b-08d43ffdb4ca
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR05MB2944;
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2944; 3:GLwbVXG83EJN2ZKSsnVIvCqnzx9GOK0/bCahviAxKw4knNTKT+MrNZV4kN7mfdtu1+f+ov6Sp3+iUsoeGeVRL2EpSezHfVdEZFG8gaBd23fdF2lfSTRIudkf3zyyCnQlKu0gLZf9832jY5ShddoclrWNFGJaGJDy7epmEtzdnYQPFWUnt1DMddGtV7YBQ//S9Rx38OIDp0iVcwO7bys01xMze1nWCvmxI0XHgcpfgYybtXA8ECYPRC/7thGtm9Yb/4lwT03LcZuKKw8pW3c0t9IC6DwHYCstlWo2ZzW+9YfgiuTW2vWUGItL9o5SvFyJxU+qoFxRAjxbkdBV7OsWfuS/s46NQQUgUd+eHOpmNNkt5IUAoWFB7pJWSJzrb/Gr; 25:kHzS9OaLM/lDerRdIVJows1ZgLcAcZD9kfQFOa5tsYmaikc7Z/wXisFJyt24uMlJhG5XGnzJB6zIuPPPCzT8mlJLp3Uj9OeHtt1PISHCR5kUEiy7ADzIyriSjNM85oxYxxl8rBB/G+0ICtQSmdeY1bbE66IXAdcVKcOeHrf4VwngmF9HP3PufUDvMn0HtHXRt/MxoJiVFZyXEbWKwtQSnwVIh7+8PjnKoVtQaUEdMFg9NqQ7C+eHYQOD2/mztwoIhKLyG1uJqsSVuo73U3f5BCiWHF05HU/RTXEX7458Zq/rw6CIVx/tAS6B7EB6wWTd444sKVNJPF2EjA0qzn2IgOvkh9QlB67vnjYT6UVe43P2NOTzXV3TSJ5uQfLHjxqAJ3m2XvRIvH8VoD40eA4KqHs2bssB2DGNDp7YnMkzL0bL69P6Xf0DIku0QRWHt+y2Uh8/v/XuwFyNlriCyyDyBw==
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2944; 31:nF30es8C6TiXoaTT61FvorZwIS2sM0NZVNaujga7ONybxmZSexm0tucXZRrgU5Iogv+hwN/27Ip6cvPvLCkjCy0zyeU7VkGluEvBFL/sDSUAyNJCw+/hZDGDsgterxuAx445l8t22Jt/o04Qi22p2oh18LNt/x8JMgnnaTCXvEn+2dhiB8nmYXXplpzGQSWFUH/r8759h544ZMbJ0lwMwYvBADMoRzLmjcBKCnMb7IBFHRZlWBOpYl0uxdyksxAKMapiu1GCVSCQv/Sb8Kvnow==; 20:i5quuKzH0fuJ5qXKGQfpT3xMjQXZ7yJWATNuX7ry4nXkDrKQWOzCIPd91WkJclLskvkHcqTXgK3kpERBVNv+9OsNPHe1LLlOMu+dPjANjwq5SCEoEPM+tH0XKO9gS6UyvyAwfQ3UfYPrWrJriDlKacjRDir7QNHgPG0gLUqDj0LPzIvNNaOUcYOCSdWRLurKz5xqOicTvrwJ6BLj38/VSY3RrIWCCKFF/r3gd63L6KKNbKo2dn8W2GO1CqORYyACs35q7iuTE30OQka2Jwzd1Vxbsk5PAnhrnPWWHVcmJKbrkN8YsVEglRhVous2wqbkZcIm0ZWSBCOT/u+Oq9ZI40ibhd0KAaBMn9dh/7DVInSvHxZgrwnGfV4g1Cy1EjqtHNuGOczLePVhUI7tGD6w+/UX1qO7QbBVHZymYGRBLBDtUagz2bIbIKoAH+i01hK4PTSiZYOpFRuMR7807W2Umbx1LPxntzSPDPIRnJqfeEvfvA9uY717O7NnHGMtUIy3
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(13023025)(13017025)(13015025)(13018025)(13024025)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:MWHPR05MB2944; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2944; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2944; 4:immaeogjBWcIp9kuR+hZ+pDPfP/Ybz5VSSnUXIyfb3c6bKEvo8jI7X6T/j9D3P38mKD7dlwC694870u3BuRX4EUeWiFQMD50sLyhwOhol/o9lVkH+3aeecO70QM7i2gFd5z6jT07dUlUCGL/Ax1Iev5PDd96+J1xf4Soz0zcz/2IFzWbrqsxL9IjFtTyrZm/2udFpRTokRCVufUtqtKX67bRRq7yjynt24qDwm4KclCPhqLjvl+Jx0xO+SjGuTeOhjtbfZv04Ms68/lNayuni8l5hnao/5gJcmSxq/2eAaZJKvhRrUm64fv1KYgzMUqz1iV7gNHz+dNMeO56br86Z83RBaiao9waytLtsy9d7UlYSKENYnia6Ks+jOzw5NUvEC3sxCPNBvg2ra+vpUj7I0gcA3TON+A18MtCP26j2ugeAPRcdrcRVXEHSganq352T2FeKt2gQz6riSLyzqYGhTYj7ltHFmNQAho0Ta81T/V7xk6eDxVSsL1DemMakdGssmsd8lN5YlYkbZH+cSVJ7qvKYdKd8NFWFTA7fvD0Az41IALdgLJU5N5xQAzwl2VC5UZJqMAwsaNDOdS94/ubZtCfKSFNmP62wW4rn21mpSoZsX8jl+9G9JXXVLgJb/Jy20nY8UZdOkKWXa0wN8wc70D9dpQJwTPcXr98R0s6ixEHff3Op7jagGEY9dbhsoDCEAadsUbp/aUjs9HbKXbE5L+2sGhEZmhEm7ZRVSTi4mo=
X-Forefront-PRVS: 01917B1794
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB2944; 23:UyHHQJl12+AB/tHntDGyBnUvgyR+UeqYg5kctnoKu?= =?us-ascii?Q?D1b0E7pf2Rvw8PyZMpJ9ypk5O0xEf6CsUtaZRefE76FY1JT1Nfa0smIQsoEr?= =?us-ascii?Q?ZD4F15jBXXc5VAe11iflXCs35WtzvxWR1EV7H4ZchokSeIaE4/vMMOq6vPpw?= =?us-ascii?Q?Ryn+rtI/MfDKfp3x6jozH4+dob7CpBPGC66yOjpmo/hKjsOrplqg2Nn1ByLK?= =?us-ascii?Q?/J20ndttwIV7rxPNa+69om+6lPRApV1FLGR0cIuZ4YBi1wUiKUCMMQrrE6+F?= =?us-ascii?Q?bBQKY4YVbhzUVKY9ox7EFXbTGsE4y9eJcWvqw8n80v42lfCI/f9XlnPfHCE/?= =?us-ascii?Q?v8K+uhepfjqOIwUPCPsA7orMVYYtYs2mf+jPJPZi7abgRXbZMRMZJFzIWjgk?= =?us-ascii?Q?2wiV55xUZ9ILsBINCrbP7vkGovEs+EurQ7YJuY2qn2ran0dWjsh+oCsy6Nji?= =?us-ascii?Q?NP0VChZ1c7kHyunEPgPby1tPjYX8XiyL+PNqhXoMi4mGb4HA7EF8CLlLpz0e?= =?us-ascii?Q?PC4Z98ntxA+sWBz2KrEIisWem7J+vZJiFbK14HBtJvMhfKKf7WVb5Z6h7bSY?= =?us-ascii?Q?xnUEZnDY3BxbTAjHgf1I8lIulaQ6Kwx8VM+GEMEcGj7CquXAIwWegKwpxQeB?= =?us-ascii?Q?06lkpPEErfeyqlQlvQoo9AGPq5oUJx1UuXeIz4/9YPbPa/bShSZUw7hoFjdz?= =?us-ascii?Q?4PtF7ro00IZCYinXrSF+Jy9kwv2gvQN0upGwOQaBAvXhuVHtYAIEdcHrE4yC?= =?us-ascii?Q?VGunLL58XtuLAdYBej35JInoOaZrE52qeiepMVgAhZONi7Z4LNrja3/nhZRJ?= =?us-ascii?Q?nbOFO9kGp6lx9SJ/mFiu+CD+L54VWv+gTCtmx86zyez3oWifl1s12MV/d8KZ?= =?us-ascii?Q?pwI2OopEq046q3JRQEM73aXqnNF3L+pJr2cdczBCbz3q5x22CEivMmUQy7MZ?= =?us-ascii?Q?cF0qwwdKOdwUpJyJcZgnUclTESful85q/SAAHNKKJxEWNeT7vRQSlqBcv5Oo?= =?us-ascii?Q?FaaXB1TP/8Dl53ZTQMz6fDfNEvwUOeMucjnDWBdgaUDTKMFIDp3aDrt4w5Jx?= =?us-ascii?Q?7JwGwTTXOhPMz2e9kjTMCC9R3JxpD5b52M3VP2rkb01BjVCb/CohaRmB5f59?= =?us-ascii?Q?24QF46hUU4QJJA5+mN0Zw6S14/ZkLYpkoXlir0dj6wulvt4euBQ34kCdO/x5?= =?us-ascii?Q?0ljE7PaWkz9ePxegVdCObgSBFFd7TwT9UegAGe2fd+p5b64DC4ICCUD5YrfW?= =?us-ascii?Q?1jd5WQu6e8ZeESPOU3x4QDTOOeGSkrH4s5aIDVCLKbAD6wmYfXBwsRI6xRFN?= =?us-ascii?B?dz09?=
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2944; 6:pMqKa0ewHi8RrwK/HIOcPe+GGgyyLri08TooFgZ+LETac1BOizxUmCakiRux43duxjSGWYWQR4Ro5g5cAs6OhQ3rBkq+6H6beH8KX3/Ghzt8SllKCCze+fmHha4I+AEkPPxcXklo/zGM10jgmAT1L4XbfsERuts4N0Pou44iJj9BNDkPYI5xqY1kLhpJJ2kAoBIZHNoayrAAmeQlHlgb+cA3rKJ1J3kYJ0tbSaOIPh3ViaC/UBTSP/tGHRBXgE1u2oHWiNlY719SUSTGmRPeCX7S8O0un5pQ7GTJ04H+jk//mCiJMEqJdaNubR+zxmVKLxtTKjTojKUfv8+tazbxvPUoy3CyX91KlLXC/HB0v5l7g04OCdELi3IMav07S+H7z09ICZDnB7hxO8GdRBqi4P7Zefo6/XxeCu30C7iPFsh7tVxOPlNi15VTynrM/3AHXXVT238RsRwTPouHNSCdZQ==; 5:HAU3ZR3rxbBk8AAlgjaJ7RI2g4oBaFrMESA+p4d1GYR+4CgTaTJzkpS3vtEcK+jKaksK259OFca8poP9iv9ApxxWJY4Hb/c8ioCzUB8Bftw9coTHm2/zkYhqPqlSV6UT59Cc/SWRQMaHuxLrZE17NA==; 24:F3hm02LblYVFzFDR+IdpRMq9SJS8qFaKBvG/lmqcdgIwYZa1YT3LnEi5bOmG44reto1TDdzOwUF4p6x+dBgIR2p3pwzGJNn3YVrNXu6FYzA=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB2944; 7:2SO5bk/7OtfyZfhpvSAYQmx7/aLkedkoUVgOXCGpWzTOqG+F+8iTTJupyx1PDIzTIvNAqrOrE5mIT/EEWpsYdEGO/6pmYvVA0KezjPK6W1qSOnejNJ9pHmjfGxKECFkGMdDYaPQ9GWnzFzmhN/G5zGFU5D0Sv80fcy3JGkj5s98e7EUawMu/sfFSY3v+P7jqbhxewxye2D5Jsye9ItmzGCmEqa9giBhYCEhN0sPZo+DMwh5IL3BnSVux1gLiUWD0vFxsxhkraNsgR0yN36ACalSX5Fj9HqQYOi/RquIGhB1oJT+SlXT21IrpLdUWF/FK1VHrAlXN8S7r3qvRu29I9UzpB4biKvCnPjl6wZMFzRRes4mrqnpKQv5tGeRbPrsZ/+FjUNQLY1yxCpFrva83JQvyCzlYptRAZ/3eLKX84wPqbfC6jDDorEl0N6zCVW565X79exzqW2aF0oEVb7UTNg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 23:57:05.6976 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2944
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] top-level mandatory nodes
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, 18 Jan 2017 23:57:10 -0000

Andy Bierman writes:
>mandatory for config=false means it must exist in an  for a 
>operation retrieval.  It is by definition "server-supplied", so there is no
>server validation to worry about.
>
>YANG constraints are used on clients.
>Not that we are super-server-centric here, but client software
>uses YANG, not just server software.

I must be missing your meaning here.  Can you please give a
use case for when the data modeler would use "mandatory true"
for a "config false" top-level node?

Thanks,
 Phil


From nobody Wed Jan 18 16:00: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 30E87129505 for ; Wed, 18 Jan 2017 16:00:21 -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 hxlas2uQNVVO for ; Wed, 18 Jan 2017 16:00:19 -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 7F39B1293FC for ; Wed, 18 Jan 2017 16:00:19 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 57B107A6; Thu, 19 Jan 2017 01:00:18 +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 HFS_puiuAuVq; Thu, 19 Jan 2017 01:00:15 +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, 19 Jan 2017 01:00:17 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3D7B200A5; Thu, 19 Jan 2017 01:00:17 +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 wsh8kLQnecw1; Thu, 19 Jan 2017 01:00:17 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43D05200A3; Thu, 19 Jan 2017 01:00:17 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 29DEA3E2A17B; Thu, 19 Jan 2017 01:00:21 +0100 (CET)
Date: Thu, 19 Jan 2017 01:00:21 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20170119000021.GA6410@elstar.local>
Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" 
References: <20161222.114940.1495001277375813904.mbj@tail-f.com> <201701182132.v0ILWhfx039384@idle.juniper.net>  <20170118231142.GC6215@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@ietf.org" 
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 19 Jan 2017 00:00:21 -0000

On Wed, Jan 18, 2017 at 03:42:07PM -0800, Andy Bierman wrote:
> On Wed, Jan 18, 2017 at 3:11 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Wed, Jan 18, 2017 at 02:53:06PM -0800, Andy Bierman wrote:
> > > Hi,
> > >
> > > The reason the status-stmt is broken is because status=obsolete is not
> > > inherited from the parent.  The status obsolete means it is gone from the
> > > server.
> > > Since YANG data is hierarchical, any descendants of the obsolete node
> > > are no longer accessible in any way.
> > >
> >
> > I am not convinced yet that the status-stmt is broken:
> >
> > - Not all references in YANG are hierarchical nested nodes.
> >
> > - References can cross module boundaries and also organizational
> >   boundaries.
> >
> > - Tools can create warnings if non-obsolete definitions reference an
> >   obsolete definition so that editors can make proper updates.
> >
> >
> yangdump-pro has warnings. pyang ignores the status-stmt.
> 
> 
> The text that is broken is in sec. 7.21.2
> 
>     If a definition is "current", it MUST NOT reference a "deprecated" or
>    "obsolete" definition within the same module.
> 
>    If a definition is "deprecated", it MUST NOT reference an "obsolete"
> 
>       definition within the same module.
> 
> 
> We do not seem to have any agreement on what it means to reference an
> object.
> 
> It seems obvious that our intention was to disallow current child nodes
> within an obsolete or deprecated parent node.
> 
> IMO we need Errata to clarify what it means.
> The YANG compiler MUST generate errors for these 'MUST NOT' violations in
> the YANG syntax.
>

But:

 - References can cross module boundaries and thereby also
   organizational boundaries.

I think we have to accept that at least temporarily the MUST NOT may
be violated in reality. I think the errata should actually modify the
MUST NOT to a SHOULD NOT in the quoted text.

I also note that obsolete does not _require_ to remove implementation:

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

If I have something worthwhile referencing something marked obsolete,
I may decide to keep the referenced obsolete something.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Jan 18 16:04:51 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 9F1C4126D74 for ; Wed, 18 Jan 2017 16:04:50 -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 dd8lAyfBwj1X for ; Wed, 18 Jan 2017 16:04:49 -0800 (PST)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491EA12947F for ; Wed, 18 Jan 2017 16:04:49 -0800 (PST)
From: Alex Campbell 
To: Phil Shafer 
Thread-Topic: [netmod] top-level mandatory nodes
Thread-Index: AQHSV5JowFSjgqzpnUODEPlBv+jO7KELFmeAgAADeQCANGLFgP//jTy+gACYjID//3yuaw==
Date: Thu, 19 Jan 2017 00:04:47 +0000
Message-ID: <1484784287403.32552@Aviatnet.com>
References: <1484779593654.22375@Aviatnet.com>, <201701182351.v0INp5DS040551@idle.juniper.net>
In-Reply-To: <201701182351.v0INp5DS040551@idle.juniper.net>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] top-level mandatory nodes
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, 19 Jan 2017 00:04:50 -0000

Here's a straightforward, hypothetical use case where a mandatory top-level=
 non-config leaf makes sense (in my opinion anyway):=0A=
=0A=
    module example-uptime {=0A=
        prefix uptime;=0A=
        namespace urn:X-example:example-uptime;=0A=
=0A=
        import ietf-yang-types {=0A=
            prefix yang;=0A=
        }=0A=
=0A=
        leaf uptime {=0A=
            type yang:timeticks;=0A=
            config false;=0A=
            mandatory true;=0A=
=0A=
            description "The amount of time since the server was last power=
ed on or restarted.";=0A=
        }=0A=
    }=0A=
=0A=
- Alex=0A=
=0A=
________________________________________=0A=
From: Phil Shafer =0A=
Sent: Thursday, 19 January 2017 12:51 p.m.=0A=
To: Alex Campbell=0A=
Cc: Ladislav Lhotka; NETMOD WG=0A=
Subject: Re: [netmod] top-level mandatory nodes=0A=
=0A=
I was really looking for a use case.  What's is a specific scenario=0A=
where one would want a device to always report data even when there=0A=
is no interesting data to report (since interesting data would mean=0A=
the device would want to report it)?=0A=
=0A=
I've seen this misused where the modeler wants the device to say=0A=
"I've got no TLA data", where the model should be happy that being=0A=
implicit in the lack of data.=0A=
=0A=
Thanks,=0A=
 Phil=0A=
=0A=
=0A=
=0A=
Alex Campbell writes:=0A=
>The purpose of a mandatory config=3Dfalse node is to say that the data is =
_always_ needed.=0A=
>=0A=
>In the case where the node is also top-level, if your server fails to prov=
ide that data,=0A=
> then your server is not compliant with the YANG.=0A=
>=0A=
>If the data is sometimes not needed, then the module author should not hav=
e marked it as=0A=
> mandatory.=0A=
>=0A=
>Alex=0A=
>=0A=
>________________________________________=0A=
>From: netmod  on behalf of Phil Shafer =0A=
>Sent: Thursday, 19 January 2017 10:35 a.m.=0A=
>To: Ladislav Lhotka=0A=
>Cc: NETMOD WG=0A=
>Subject: Re: [netmod] top-level mandatory nodes=0A=
>=0A=
>Ladislav Lhotka writes:=0A=
>>>> 6087bis says in sec. 5.10:=0A=
>>>>  Top-level database data definitions MUST NOT be mandatory.=0A=
>>Right - I think the following should do:=0A=
>>OLD=0A=
>>  Top-level database data definitions MUST NOT be mandatory.=0A=
>>NEW=0A=
>>  Top-level data nodes that represent configuration MUST NOT be mandatory=
.=0A=
>=0A=
>[old news, but...]=0A=
>=0A=
>I guess I'm missing the use case for mandatory top-level config=3Dfalse=0A=
>data models.  Can you please describe one?  I imagine that just because=0A=
>my device implements a non-config data model, I should not be forced=0A=
>to generate data for it when/if that data is not needed.  What's the=0A=
>scenario where I need to be forced to make this data?=0A=
>=0A=
>Thanks,=0A=
> Phil=0A=
>=0A=
>_______________________________________________=0A=
>netmod mailing list=0A=
>netmod@ietf.org=0A=
>https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Wed Jan 18 16:05: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 B87F4129410 for ; Wed, 18 Jan 2017 16:05:53 -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 xru5gZkS6JoT for ; Wed, 18 Jan 2017 16:05:52 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0123.outbound.protection.outlook.com [104.47.40.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3682126D74 for ; Wed, 18 Jan 2017 16:05:51 -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=Vh2MHLiGJBT2fJn3O2ixErBBbRxMdgi4G028/EA5ORY=; b=RyEO+is1mmY2JAnzu7tPTu19rbLraO0Iv5jWXfQm3U37NutFFAy4uh5ESHmLzjwLMhwxpvsyWrKncm08PqQX9N01ZR8P/APK67MfUeBJlMZLc5udk/oFbkPiwJ1skhZJ/UppAOKYwD+3f1tKrEHsiim71pNOTMufQdflN8oPrMo=
Received: from BY2PR05CA061.namprd05.prod.outlook.com (10.141.250.51) by DM2PR0501MB1293.namprd05.prod.outlook.com (10.160.130.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 00:05:50 +0000
Received: from BN1AFFO11FD010.protection.gbl (2a01:111:f400:7c10::152) by BY2PR05CA061.outlook.office365.com (2a01:111:e400:2c5f::51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Thu, 19 Jan 2017 00:05:50 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD010.mail.protection.outlook.com (10.58.52.70) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Thu, 19 Jan 2017 00:05:49 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 16:05:30 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0J05TdH023539; Wed, 18 Jan 2017 16:05:29 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0J01QmR040698; Wed, 18 Jan 2017 19:01:26 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701190001.v0J01QmR040698@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Wed, 18 Jan 2017 19:01:25 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(2980300002)(24454002)(199003)(377454003)(189002)(2950100002)(50986999)(6916009)(106466001)(105596002)(53936002)(1076002)(54356999)(5003940100001)(189998001)(2906002)(8676002)(53416004)(97736004)(76506005)(626004)(54906002)(5660300001)(2810700001)(305945005)(4326007)(356003)(7126002)(69596002)(92566002)(38730400001)(110136003)(81166006)(8936002)(81156014)(7696004)(86362001)(68736007)(8276002)(50466002)(48376002)(47776003)(77096006)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1293; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD010; 1:bnVueXNu3W5UKaXVyJTBHRW4YiVbgiONIMwFt1OAUpDTF2xhlGU0PZ16BTH6lXGp+NLjlzUbVc04ch97jES9X84w0+98czeKFnG5DzU4SzhEx4VNqcg+KO27EKNBY3VwurNSof7Lup1XlMMV5XoJBkl6rGhfy6pLSUA3Aq/D6rJlIO84zF05ryKGMBOml+WSKD6TbOvfT7KABBLRYRHQNU1stJNAPS8QxfXEvQjCqsVMv3HGDQjd7Rg1kmAz6/H6twVEodby0m8e5xtfATUvdpATYvnthkbOfCuyo0iFZLKK/pMIDmL5Q5uYQIt8x4rendH+/Q4AMzPnnhyY7bA97Fca0YBlII0R8NIraOvVSOeVL4wb3JCv41Z26Amd18eXv7Pbw8u30KaY3JLu0CwdFljN8UIEhfJkqNpSbTXHCrP5KT3hGw28GsNomsLKZy+jl1JXs6AJpYEaa93IF4IutYgYtPMesJuZpki9U4ncB8Oa6h0xErJ9SuIHYhuMuGDb3Xvak0wcVMMNr4Azbkbyt4NMPcp8yojIqHv/Ir5iCAgouzLFrMC1PMrVjcGHFvqW
X-MS-Office365-Filtering-Correlation-Id: 99ae08c3-9e75-4a77-a4f7-08d43ffeed29
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DM2PR0501MB1293; 
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1293; 3:tTsJHjObFHPN3HRFqPKjxu4xQPRgtrHvxcJ+r6Z20uhjInqznBsCIzmIVwmytGYElw8NDCPzGKx+ZoTDt7h3/ReR64tR9mTV221CQYY4GPhHCPpu3zxnM0Ip/vnMb7Ukb3LyP0scUNsPtdmRx9pvXIIYQFg+Q+ZltWl8AV3gFcNKOiTbr1eE5g+o+cLbPuwkMWEw0a2K5tENlwu9pVu5yN9kxpf/DVS4i8yD0WtOiD45Ww/yuiUhiVDQwOfna3RSHrdm2IrGIhsZdQ/cHDaRart90bkwFpyDpXF3uA9SljGsW9D/66lOfnre2Ql6sgC8Tf6TF/RBzGjNpwPsR9Y1jjSgA/vg0QV6y4FW12K/DE1eKb4n8LQbu/Ez5/oTn9xt; 25:eJJnLb3vvl1gTohrnh/HRJ2iDcDYt3MevjFY/ex5HbV0rnCeA4nGjiCP2+3qWlkZlIGNSZ+2JFMC61xf6Sl012bhSQk7S6ZAbnLPB8etqRbMhc1t/DtUOkIxWZTNZwQEEpjau+oHnD2UTBR0EXBLfK2fpE1GbwI/8hNHaacnPwtjylzep9hvxazgYZf3PTS0vfW9NAMRII6jhGHg95vU4aaKkGtcrkXsOF5od/p8+aP6WPtH7aP/jHV8oddWc6TXjaI5LmZJCqCzB/Bp1nr1xG8dx1UMM32AReKZrkdUD2XycZ1rGU9nWuQ/r1zKOdIUody5bNZaGbCvHFHwjevdqH43V0I8GJ7FUvhBuiE7bjycm9E0VnwkxQ1+gagC0jL8964Dlpm3MB2DouzWObNNZHToCwEb+25+mkzC603PKQb1kHnxxyaNnjt5Oy95tCt/Z+MytD1+hxBBp4AuUn1eGA==
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1293; 31:24N8sU7Mrzf+FzK0zZlATvRtG+marcH2oNjRNn6EbG5sm2kMTmJ67Y52n/3QKWejqdSFdFoG70Bf/yfzDuRojUMkXmo+UGxEu8QYz6lh43i2TZjRiDm2sTGAH+ocAwKwxSy4rslVN03MWocNngzVEP9qIdU0Skqpe1rUTB02ZSQy3xzKN3UmfSYPva0bPIDyLxLRhckKLUdftRLoXuE3ih4AtDnG39tabg8pbWqDebLiRFdKZleWxuNz3RCNMwroj9OfnG2nLtJoiWYGNVdw5w==; 20:SLZXMgos8/ERuHkYL6zievfA8T3sgxVL0D2QrOL04ftMFS0gtwLcOZbw/+q0llEfdEEpFoagJ7jN9vGaVwRPZR9ChrWnGK2J7IXEDByxWvW+rd4H84zrCRLC7QcQcfDYs+Ztp67j1BCK1HclqwYbYdD+j0OOIc42EKaE+IMMSuK7JinVrpNyGGXpSP5xMw8EfBGqI1MPJuWW/4QOkovZ1oowItUkMJHc4D68/FlE8FxB828RvKqMYerrhLrknMZ0MFYZyh+uHnPdCftUxPx+c6fgRmp7RxYV1kXig8iWF/3eCXt0RajYuopMtvC2Y+jHowYqSrrM9COMm+dy+u6fNg1ADFR6v1/G7yvb+B1C8+C4X4WwXI7naBE4t3h6rQFrneG5juS19U/sO/UfvV4o8G6Wokiak/olMjL64dzg1V9IrdhmPVFSsk+YWphhZIp+gEcqs+Z31aK4oiCC2e1dj5JiyK+yMaT3S5UFtSIp9bLW3EMMXRhJOpFPpj9FsOGg
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(13018025)(13015025)(13017025)(13023025)(13024025)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123558021)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:DM2PR0501MB1293; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1293; 
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1293; 4:aUkHlZSLvmqqW9oPdwZPAxN54Rsv8vMgVGSHS8ZiXEdf/27b4ZFYRTcIz/ZnA4MQ8FixcdTA9yPSLilf4MA6BCDGDWxk+Dms4zAq12e66DIZ5Tj6VzHiSSk1HJGD3bBNcfGRLhJhUJV/W33VYBHDUJA+J0SwHB5QuZSG4I4JVE0pjQFsrxyZmcVEwkEK3uNrx+hQ5XHZUaH3e03eTJLSWTniweuOBR7ju8WlY2JHpFbZ3AsdveVsbvQ180TYa5gLfeNMMdgkGpTHtcMQ0+OfHxDLLCY4yWSlX5YE5iyF+KK87VuTRQq4C7L19bR1dzOmM+nEeayFwKGFTpk3Z4byiHSmQ1zyujCpmeTvoH82WJsYvuABtDtTC8GDZeq9N9wVsVbFFH3pj/sTZseWEkJpshMYx+TwzCmiOR4Oetd/6vre/QWMErSdB2EJBWQ+QOJ3QSueg2NxfoNXobJhpc0rK/QjcxAn6y2wVBSK5mggoEcVOOSWtFPOIjXcj36Yis2b7NmbynNPm/gGpeqEuUgzO1aTQe/xyD167xbutKsuAHP5gn8vVayDKKECYNG2rkJ4CrHbhLFG9dBxzpQ05Q8kFWDzarqrC+A+EChk0zq1pHHiC2MLTiKJuKpSosh92WfvZTijy3jPArq17BxYJnViRfWLLFrMhwvbusPpaCuSU84YKff6OQ8O6ZpBhNpnzAVmeAFA1KPm0oO1Yu+2PF8s9DhPiyR58d9wUYG6h/TD27vAKfbh71SqEschrVbCg+OpjcWTjiwjKgrv9j/VgdTXwg==
X-Forefront-PRVS: 0192E812EC
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB1293; 23:bnBb+dh1fOQZv79Ed6BdjqQsdarPlkLytYNgkuB?= =?us-ascii?Q?EBjogjE7wwKQeYnYz2N6CVvnyIOdW5YHAzBoGnLwGW77OHf8FC8M0HOZwDiX?= =?us-ascii?Q?USBH2xAgI5XzXXigoyr+xpGQOsNI1fjeAJcYNpEHsBrTgbNk9GmpsQTXljyD?= =?us-ascii?Q?W6dYaUjC8Rq1qwrdk6S1jZuRI1FBfRxcT5Usw323Wj6RB6GkrFwJrRwKyPjR?= =?us-ascii?Q?NFb+RE/v4Hat01EqjX0uAgAzIMu3cYIcsIbbvs7d1O4CKrgiZYGgQeOguTz1?= =?us-ascii?Q?tF5QdJnddCM+LfUJe8Qtf809sFPv8bS3JNSrhozycMpqg49MhJYQyUTpLp5X?= =?us-ascii?Q?ZZj5CF9babIh/QgU8mPO+L0Z62kROsnVo9vw5mc0Eh+cyaSQdLEf76qKugH8?= =?us-ascii?Q?/EF/KTOr41xVaGUzhdlchqSEVnWjYEUhBxgES1ctSBDM9/RNOE77Yeo4YLLW?= =?us-ascii?Q?k7agVJ+8ZLWRSPuJTTQJwku1UHCiwyd8akAuo9Uw6Pux0v+h0yxJyf3XuP/0?= =?us-ascii?Q?fhn6VokxrEcpuX6wFXHRE8CSwzG5ycdxz1/TdIKJYX4AUv5ZjI1vGXFm0g9i?= =?us-ascii?Q?WCUSl9xeQ36Lrk/IwKFljZkcmK4ZOT1DdLMUwgqRAOm6tKZSCEAVP6rH/3j3?= =?us-ascii?Q?Yj9uvzIQS3vWZQeOReXzOYNLuHKxZnvwzE/pGKra+v5XQQqXhvAchLi1GqmB?= =?us-ascii?Q?2UnGB38+hNduQcpUV8/zQnHyjAcuE12ospfaTEGk17YZijGmAcfCxlVS6KeL?= =?us-ascii?Q?44DddGPi4N16Gv8FCVCxYcG0ubLcS/nY8GU/5sVVSH8nl3hUtxwoN0yMQ1qf?= =?us-ascii?Q?InXeEJAxUfVYZ25Zh3hkUOP5GR/s0ON/G+z9WlwgI/yWtWI1wrKzJ1xEPBeM?= =?us-ascii?Q?+WwHHpGJb0i/aX458fxq5+4SmwqT8s3bBBvUcO+wkJWpjF1F6TT0bl8EeP3m?= =?us-ascii?Q?aU1WBWBqIYGPFKCdbRM4V30j/JqOfD5JNZ7NUeVlKioG0xw+PR8+BLHtc0gE?= =?us-ascii?Q?BMkojHVAQzWqMHrdTR4xt5wMhIDV+3nLJpSjNleYfrgwexq+IiTW2bb65ruv?= =?us-ascii?Q?dBkaKoDMxCvWxQEtz+IZ1oSu0SUPksmleDyq5Zr4RS/R5v0f1PdD0F2q8Dr8?= =?us-ascii?Q?nSbRjklA44wx5w3hn273JVPRV3LfudZ5RnDVbSJMK8LqBNKYu4fgr5dkFMK8?= =?us-ascii?Q?BbmUoCO9G2GxGoto58+N46xA3OYAAHEygkMNJzllbHQ/M7L2PiM+q8aT7rQU?= =?us-ascii?Q?gs3jnB6tTDs/BJuluVhg=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1293; 6:gLv4+vudjdELY/GLbOSHtAOQgDWxj3Wvmqd4zU4IF9RZT5Zmmlz75bOWZfAwyD1OAPVhTifjXsZlFofUOfqBX7O05vSAp+2NpDma7wYZllloAlj/8zoQK0upD5b1xLF/DMuwMZF5j1c59O6R/jnXoa9d0188CtEUfdevU+ynIuiZLUbGDk5BrE/HjKaqlM0qeNmH8Z25jVmiE6P4Qcik6m53NJlKc8bbgw4bLad9pP6vs+otcvXlCiHespyGda+2AqV0OBc3aR6Php6aCP3CbCxkovCzeEiSAB+YfPCKlHpEwkq5W68/k0CQX0q/3Io3QxLnEVoclBKuEw7zZADLcnJKJro9eCC0oiNbUD+ktXib7dnGna7j/R/Zz87fezB1K0pn0JdBOqlkxkyDN9wMvp/TWRARkHMmq6c1rYUtZGdxiTgr9QwtwZgy9k1aD0spPphWmbiJ1UxDA17nHE1qlw==; 5:6brgLRb5IvyAoO39QRrjcgElnWaMI4NpzJCyJChFDFAty0tF7uDezXxvj8oiLrnRvEwCJul0Gt7OdnqwfgReej01dEo1NfGkGPXhKBp6otayzn67ZxQhwigBQv0PKDdme3o7T/1FqAxnATFU3m3Smg==; 24:Z1aD4op1CCjS4pE44MjsbYOyxizdeFhL0lsD6rc6ULtkwTf0FSarA9ObiPDM1aej6wtHarenfznlEZ62+Wz4KAfZ6c0HMMMbEYMqnOiV59Q=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1293; 7:xlTZTEbBzQl7HwxMbWoO8lHZ+bE1dMbf3jZJ/OZoZBiVn7H2hQUqstlez7HhJjcgBhUOBGDA3btTNKcImLSV88HSlzdMhTxWe9W5QWaPUMrK/Ubh4Wq8zSSdVuKSBPA+Pozx5+RVq0vfJNxUx/erk8MhoGPz/cZWAZ97qDDg2Tdh2fHiWPJ5ovBSY/+WfYQ8mKCly3jzK5kkSUCejicjPu3Lszw15XuPDNnMNjV4o8s5EJupxeR5ilNaLS2iTu7CNpRdMKdVwRcV9UI5kb3be5jUuVegGj0uxITdy33qGfP2zMXAASSUwveQXEzgvjXNW4ui/c9fkFM293xYUuKAo8REGFY41OF8yT34fVgpBUdOiYdWZBTpMIxyVN9Al/gZwid/VW4EZc9FPdphnE/WILUBkQU8dVu1dAXH1fXDyYTVDy4IXsHiR1OhFBSydFM4AP06D9YtN/0873QqF22klw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2017 00:05:49.5510 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1293
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 19 Jan 2017 00:05:54 -0000

Andy Bierman writes:
>The reason the status-stmt is broken is because status=obsolete is not
>inherited from the parent.  The status obsolete means it is gone from the
>server.

No: '"obsolete" means that the definition is obsolete and SHOULD NOT be
implemented and/or can be removed from implementations.'  It's not
gone, just that it _can_ be removed.

>Since YANG data is hierarchical, any descendants of the obsolete node
>are no longer accessible in any way.

This is not true.  "deprecated" and "obsolete" nodes can continue
to exist for decades.  They are accessible by normal mechanisms.
The "status" affects expectations, not implementations, which
tend to not remove features that might affect paying customers.

In any case, my main contention is that the rule:

    If a definition is "current", it MUST NOT reference a "deprecated" or
    "obsolete" definition within the same module

is not workable, since nodes may need to reference deprecated and
obsolete nodes to block the interactions between new and old nodes,
as depicted in my example.

Thanks,
 Phil

>On Wed, Jan 18, 2017 at 1:32 PM, Phil Shafer  wrote:
>> Martin Bjorklund writes:
>> >But marking definition as obsolete in one module cannot automatically
>> >make definitions in *other* modules obsolete.
>> >
>> >(*) _maybe_ 7950 can be interpreted in this way when it says:
>> >
>> >   If a definition is "current", it MUST NOT reference a "deprecated" or
>> >   "obsolete" definition within the same module
>> >
>> >If you're in a good mood, you could argue that a child always
>> >"references" its parent.
>>
>> That's a massively deforming interpretation of "references".
>>
>> I'm not even sure this is a good rule at all.  Consider:
>>
>>     leaf old-stuff {
>>         status deprecated;
>>         must not(../new-stuff);
>>     }
>>     leaf new-stuff {
>>         must not(../old-stuff);
>>     }
>>
>> My new-stuff definitely references old-stuff which is deprecated,
>> but this is a _good_ data model and should not be "MUST NOT"d out
>> of existence.
>>
>> Thanks,
>>  Phil


From nobody Wed Jan 18 20:36: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 D7757128B38 for ; Wed, 18 Jan 2017 20:36:11 -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 NpiHGW4eaGwZ for ; Wed, 18 Jan 2017 20:36:10 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 19923128B37 for ; Wed, 18 Jan 2017 20:36:10 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id l7so48465447qtd.1 for ; Wed, 18 Jan 2017 20:36: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=YfwX+jzdCKpdwB93VCShpqpisfDS94TyQSoRfliQo/k=; b=CgVi4lVgzfEYbDJy24Q7DKLW9DIIGG8YYcZxVdchUrAVGp8eTnxmjWA4WAULr/HTkN h76J74+iWChD0UOZS6icaZXQ7iRRCVMgG6KXOcuDGRNFwGiWUtm9hWo9VzokzRIyozOH ZmN8azwTw9u6a84LfFPqBNKacYBSnkMLDqaKsulD/y34y9sN5l2rg3CUkrA1R/i/AnKz ppOrTqV82vZnf711p7QIhxc6Ps69zm4o5rDZRLi5/eh2ybFWsM3GDQyt3+ziwHkRyzQc 6ACTgdizLqsPKZTXoENNSLWQBmuU4PQzKikxdVwmikh/WFpnEuECFgs3ioN6DK1cmwKd gjSw==
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=YfwX+jzdCKpdwB93VCShpqpisfDS94TyQSoRfliQo/k=; b=ofaJeOD1t3OtC/AQ3AGYqtvrF5pyZ7Y2B9mboJpwWk8Q+9PdiIlDVJYlCNGRrxJnG6 hItCAG/KJEQPIQx/yvHkYzOyJ+Zspa9vHSSZS35CUqOxHW21vWO9+DaN2g0pykRcLqR7 xhveB8HL0QJA/XDnO4k/SgqYxtmatK+b2zRIL6Tqi3Bm/QUkqF41/kJDl0Vf2xxN+fGG ceAADmJmr67QvrSI0m9drP6AqVixy680oUl2Xdlad1O1VKAQEzzoRKkHV/iPjpb4ER1V I1z7MH1Oc8mQQNh/L8z0bQXGs/K1SoJn8MdSFbp2xiVFwdzERrsa4zdiR8QeriB2leYt U3GA==
X-Gm-Message-State: AIkVDXKdxP2MAR1WTg2HhDgK0TMBr8FfFta+pbVd5ovAdx4HDGoPY6V9erBmRVYtPO2VjBtLiDx7IaqIMuGlFA==
X-Received: by 10.55.7.2 with SMTP id 2mr6885763qkh.228.1484800569221; Wed, 18 Jan 2017 20:36:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.137.27 with HTTP; Wed, 18 Jan 2017 20:36:08 -0800 (PST)
In-Reply-To: <201701190001.v0J01QmR040698@idle.juniper.net>
References:  <201701190001.v0J01QmR040698@idle.juniper.net>
From: Andy Bierman 
Date: Wed, 18 Jan 2017 20:36:08 -0800
Message-ID: 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=001a114c877c7db85005466b1288
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 19 Jan 2017 04:36:12 -0000

--001a114c877c7db85005466b1288
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 18, 2017 at 4:01 PM, Phil Shafer  wrote:

> Andy Bierman writes:
> >The reason the status-stmt is broken is because status=obsolete is not
> >inherited from the parent.  The status obsolete means it is gone from the
> >server.
>
> No: '"obsolete" means that the definition is obsolete and SHOULD NOT be
> implemented and/or can be removed from implementations.'  It's not
> gone, just that it _can_ be removed.
>
>
OK.  If the parent object gets removed, then NETCONF and RESTCONF can
no longer access the descendant nodes.



> >Since YANG data is hierarchical, any descendants of the obsolete node
> >are no longer accessible in any way.
>
> This is not true.  "deprecated" and "obsolete" nodes can continue
> to exist for decades.  They are accessible by normal mechanisms.
> The "status" affects expectations, not implementations, which
> tend to not remove features that might affect paying customers.
>
>

I mean in a given server, if that server has removed obsolete /foo
then you cannot access and descendants of /foo

The status-stmt is for the benefit of the client developer, not just
the server developer.  They are forewarned that servers SHOULD
remove obsolete nodes, and it might be wise to find a different data node
to use.


In any case, my main contention is that the rule:
>
>     If a definition is "current", it MUST NOT reference a "deprecated" or
>     "obsolete" definition within the same module
>
> is not workable, since nodes may need to reference deprecated and
> obsolete nodes to block the interactions between new and old nodes,
> as depicted in my example.
>
>
OK


> Thanks,
>  Phil
>


Andy


>
> >On Wed, Jan 18, 2017 at 1:32 PM, Phil Shafer  wrote:
> >> Martin Bjorklund writes:
> >> >But marking definition as obsolete in one module cannot automatically
> >> >make definitions in *other* modules obsolete.
> >> >
> >> >(*) _maybe_ 7950 can be interpreted in this way when it says:
> >> >
> >> >   If a definition is "current", it MUST NOT reference a "deprecated"
> or
> >> >   "obsolete" definition within the same module
> >> >
> >> >If you're in a good mood, you could argue that a child always
> >> >"references" its parent.
> >>
> >> That's a massively deforming interpretation of "references".
> >>
> >> I'm not even sure this is a good rule at all.  Consider:
> >>
> >>     leaf old-stuff {
> >>         status deprecated;
> >>         must not(../new-stuff);
> >>     }
> >>     leaf new-stuff {
> >>         must not(../old-stuff);
> >>     }
> >>
> >> My new-stuff definitely references old-stuff which is deprecated,
> >> but this is a _good_ data model and should not be "MUST NOT"d out
> >> of existence.
> >>
> >> Thanks,
> >>  Phil
>

--001a114c877c7db85005466b1288
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 18, 2017 at 4:01 PM, Phil Shafer <phil@juniper.net><=
/span> wrote:
Andy Bierman writes:

>The reason the status-stmt is broken is because status=3Dobsolete is no=
t

>inherited from the parent.=C2=A0 The status obsolete means it is gone f=
rom the

>server.



No: '"obsolete" means that the definition is obsolete and SHO=
ULD NOT be

implemented and/or can be removed from implementations.'=C2=A0 It's=
 not

gone, just that it _can_ be removed.



OK.=C2=A0 If the parent object gets re=
moved, then NETCONF and RESTCONF can
no longer access the descend=
ant nodes.

=C2=A0

>Since YANG data is hierarchical, any descendants of the obsolete node
>are no longer accessible in any way.



This is not true.=C2=A0 "deprecated" and "obsolete" nod=
es can continue

to exist for decades.=C2=A0 They are accessible by normal mechanisms.

The "status" affects expectations, not implementations, which

tend to not remove features that might affect paying customers.




I mean in a given serve=
r, if that server has removed obsolete /foo
then you cannot acces=
s and descendants of /foo

The status-stmt is for t=
he benefit of the client developer, not just
the server developer=
.=C2=A0 They are forewarned that servers SHOULD
remove obsolete n=
odes, and it might be wise to find a different data node
to use.<=
/div>



In any case, my main contention is that the rule:



=C2=A0 =C2=A0 If a definition is "current", it MUST NOT reference=
 a "deprecated" or

=C2=A0 =C2=A0 "obsolete" definition within the same module



is not workable, since nodes may need to reference deprecated and

obsolete nodes to block the interactions between new and old nodes,

as depicted in my example.



OK
=C2=A0

Thanks,

=C2=A0Phil


Andy
=C2=A0



>On Wed, Jan 18, 2017 at 1:32 PM, Phil Shafer <phil@juniper.net> wrote:

>> Martin Bjorklund writes:

>> >But marking definition as obsolete in one module cannot automa=
tically

>> >make definitions in *other* modules obsolete.

>> >

>> >(*) _maybe_ 7950 can be interpreted in this way when it says:<=
br>
>> >

>> >=C2=A0 =C2=A0If a definition is "current", it MUST N=
OT reference a "deprecated" or

>> >=C2=A0 =C2=A0"obsolete" definition within the same m=
odule

>> >

>> >If you're in a good mood, you could argue that a child alw=
ays

>> >"references" its parent.

>>

>> That's a massively deforming interpretation of "reference=
s".

>>

>> I'm not even sure this is a good rule at all.=C2=A0 Consider:<=
br>
>>

>>=C2=A0 =C2=A0 =C2=A0leaf old-stuff {

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status deprecated;

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must not(../new-stuff);

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

>>=C2=A0 =C2=A0 =C2=A0leaf new-stuff {

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must not(../old-stuff);

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

>>

>> My new-stuff definitely references old-stuff which is deprecated,<=
br>
>> but this is a _good_ data model and should not be "MUST NOT&q=
uot;d out

>> of existence.

>>

>> Thanks,

>>=C2=A0 Phil





--001a114c877c7db85005466b1288--


From nobody Wed Jan 18 23:00:16 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 597B112940E for ; Wed, 18 Jan 2017 23:00:15 -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 xFhvGp8RZ-8d for ; Wed, 18 Jan 2017 23:00:10 -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 E24F11294E7 for ; Wed, 18 Jan 2017 23:00:09 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:4832:4aae:79dd:a6d0] (unknown [IPv6:2001:718:1a02:1:4832:4aae:79dd:a6d0]) by mail.nic.cz (Postfix) with ESMTPSA id 6F6CF60AD4; Thu, 19 Jan 2017 08:00:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484809206; bh=TMuyah80B+ur0CexsmLA0xfbc/K5k7aKZZzKE8EtetI=; h=From:Date:To; b=f2sMM0UfHGEtFWJ1BdOSB4mK0ByXuE8wrmZ3x0R8gZYUPaXVIKbja2TrL/C6AlWdp rsL52CXPi5mtSEyYltrU4PsvvcAISGa1NGVkFB/ERHJ45ks1GgeDdCFDb4ASwY+x/8 Iqi4FZc2eVBalrIrPYZbgFwVSAAE6kwGS/jMytqU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <20170118191326.GB5811@elstar.local>
Date: Thu, 19 Jan 2017 08:00:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20170118191326.GB5811@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@ietf.org
Subject: Re: [netmod] notifications
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, 19 Jan 2017 07:00:15 -0000

> On 18 Jan 2017, at 20:13, Juergen Schoenwaelder =
 wrote:
>=20
> The only references to RFC 5277 in the YANG 1.1 specification I found
> refers to the  element. I do not see anything broken or
> worth fixing.

Configuration and state data, RPC operations and everything else is =
defined in Section 3, either directly or by reference to RFC 6241. =
Notifications aren't.

Lada

>=20
> /js
>=20
> On Wed, Jan 18, 2017 at 02:22:22PM +0100, Ladislav Lhotka wrote:
>> Hi,
>>=20
>> if NETCONF WG moves away from RFC 5277, what does it mean for YANG? =
In my
>> opinion, we have two options:
>>=20
>> 1. remove references to 5277 from the YANG spec and define a =
notification
>>   as any data sent asynchronously by the server, or
>>=20
>> 2. generalize even more and treat a particular notification as just
>>   another type of data tree.
>>=20
>> BTW, the Terminology section in RFC 7950 doesn't contain a definition =
of
>> a notification (unlike pretty much everything else). Is it just an
>> omission or was it intentional?
>>=20
>> Lada
>>=20
>> -------------------- Start of forwarded message --------------------
>> From: "Mehmet Ersue" 
>> To: "'Netconf'" 
>> Date: Wed, 18 Jan 2017 00:06:14 +0100
>> Subject: [Netconf] New Notification and Subscription Features WASFW: =
3
>> Options for Subscription & Event Notification draft structure
>>=20
>> ...
>>=20
>> B) NETCONF co-chairs further propose that NETCONF WG should use its =
energy
>> in the future to complete and improve the new notification and =
subscription
>> RFCs and stop maintaining RFC 5277 for issues other than errata.  =
Note that
>> it is required that RFC 5277 and all new work needs to gracefully =
co-exist
>> in any deployment. =20
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=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 Wed Jan 18 23:05:09 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 A454412940E for ; Wed, 18 Jan 2017 23:05: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 1BfdQDf7dMP9 for ; Wed, 18 Jan 2017 23:05:07 -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 1E529127058 for ; Wed, 18 Jan 2017 23:05:07 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:4832:4aae:79dd:a6d0] (unknown [IPv6:2001:718:1a02:1:4832:4aae:79dd:a6d0]) by mail.nic.cz (Postfix) with ESMTPSA id C405D60AD4; Thu, 19 Jan 2017 08:05:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484809505; bh=l2mdxuDtc7v4CyaZXVYYLt3W077cgvgL0Yq8G8CeqoQ=; h=From:Date:To; b=Bfpo0SOhJ+Gx2M9Xinx5SPkAHTuSzBQ5do9QolukESjJS2llFOAVrEewgDTXFH26X ZCN1XRx+5iyn49kLeXsOlIatRrh+Kk1uzVhO2QaRNNSjuEdilBGJr8TBZRSDBNW+wd GVct4xb4yrJx/zmOzVcvRKNjTMb4CWkR5UC9HwPg=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <201701182108.v0IL8vRB039097@idle.juniper.net>
Date: Thu, 19 Jan 2017 08:05:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <63EAB42D-76B8-44AD-8FD9-88B06B51A3BD@nic.cz>
References: <201701182108.v0IL8vRB039097@idle.juniper.net>
To: Phil Shafer 
X-Mailer: Apple Mail (2.3259)
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org, RFC Errata System 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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, 19 Jan 2017 07:05:08 -0000

> On 18 Jan 2017, at 22:08, Phil Shafer  wrote:
>=20
> RFC Errata System writes:
>> \      a single backslash
>=20
> Why isn't this "\\" like the other data ("\n")?

The second backslash was eaten along the way. On the errata web page it =
is correct.

Lada

>=20
>> The backslash MUST NOT be followed by any other character.
>=20
> Seems reasonable.
>=20
> Thanks,
> Phil
>=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 Thu Jan 19 02:00: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 7B679129428 for ; Thu, 19 Jan 2017 02:00:54 -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 6nZcbOP9i2lU for ; Thu, 19 Jan 2017 02:00:52 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A66D5127ABE for ; Thu, 19 Jan 2017 02:00:52 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id BFCD21AE018A; Thu, 19 Jan 2017 11:00:51 +0100 (CET)
Date: Thu, 19 Jan 2017 11:00:50 +0100 (CET)
Message-Id: <20170119.110050.821999647646840232.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20170116.164803.729427888661667991.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: netmod@ietf.org
Subject: Re: [netmod] example modules in 6087bis
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, 19 Jan 2017 10:00:54 -0000

Andy Bierman  wrote:
> On Wed, Jan 18, 2017 at 9:12 AM, Benoit Claise  wrote:
> 
> > Martin,
> >
> > Hi,
> >
> > It turns out that the recommendations on example modules are a bit
> > unclear.  Different drafts do very different things.  Some examples:
> > https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2
> >
> > This example module really looks like a real module.  It uses an
> > IANA-controlled namespace, and the meta-statements indicate that this
> > is a normative modules.  But the module does not use the  tags.
> >
> > https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1
> >
> > This module is better, but it is written to follow RFC 6087 rules
> > (pass pyang --ietf), with the result that it contains a bit of "noise"
> >
> > It takes a lot of YANG experience to be able to distinguish what is noise
> > or not.
> >
> 
> I agree.  I see Martin's point though -- maintenance clauses like contact
> and organization
> are not really needed for examples.
> 
> 
> > with some meaningless descriptions and meta-statements.  It also does
> > not use  tags.
> >
> >
> > A good example (IMO) is found inhttps://tools.ietf.org/html/rfc8022#appendix-C
> >
> > It uses descriptions when necessary (high s/n), no fake
> > meta-statements etc.
> >
> > However, it might be a good idea to require example modules to have a
> > "description" statement that explains what the module examplifies.
> > For example, the example-rip could have:
> >
> >   description
> >     "This example module demonstrates how the core routing data model
> >      can be extended to support a new control-plane protocol.  It is
> >      intended as an illustration rather than a real definition of a
> >      data model for the Routing Information Protocol (RIP).";
> >
> >
> >
> > I think that 6087bis is clear when it says:
> >
> >   The guidelines in this document refer mainly to a normative complete
> >   module or submodule, but may be applicable to example modules and
> >   YANG fragments as well.
> >
> > I think this states that example modules do not have to pass pyang
> > --ietf.
> >
> >
> > In order to make this more clear, I suggest the following changes to
> > draft-ietf-netmod-rfc6087bis-09
> >
> > In the Terminology section 2.4:
> >
> > NEW:
> >
> >   o  Example module:  A complete YANG module or submodule that is
> >      intended to illustrate some specific aspect, but not intended for
> >      actual use.
> >
> > It doesn't solve this issue, because https://tools.ietf.org/html/
> > draft-ietf-netmod-rfc6087bis-09#section-4.2.1 says:
> >
> >  The  convention SHOULD be used for complete example
> >  modules, but not YANG fragments.
> >
> > That implies to me that we have 3 types:
> > 1. *complete *example modules => I read it that they must pass pyang
> > -ietf, SHOULD have 
> >     If there is , it's because people will want to extract
> > it, and play with it. So the tools chain must work
> > 2. the other example modules. No . I guess they don't pass
> > pyang
> > 3. YANG fragments. No . I guess they don't pass pyang
> >
> > In practice, 2 and 3 are the same. So we need just two definition
> >
> > Scrap "complete" would help but that's not enough:
> >
> >  The  convention SHOULD be used for example
> >  modules, but not YANG fragments.
> >
> > We only need to clarify 3 points
> >     , yes/no
> >     pyang, yes/no
> >     pyang --ietf yes/no
> >
> > I guess we want, putting all this together:
> >
> >   o  Example module:  A complete YANG module or submodule that is
> >      intended to illustrate some specific aspect, but not intended for
> >      actual use. Example module MUST be valid according to RFC 7950,
> >      except when they are used to illustrate some illegal constructs.
> >      Example module MAY be valid according to the rules in this document.
> >
> >   o  YANG fragment:  A incomplete YANG module or submodule that is
> >      intended to illustrate some specific aspect, but not intended for
> >      actual use. YANG fragments MUST be valid according to RFC 7950,
> >      except when they are used to illustrate some illegal constructs.
> >
> >
> This is good

Fine with me.

> I prefer:
>    - MUST use CODE BEGINS for a real module
>    - MUST NOT use CODE BEGINS for an example module

I agree (see below)

>    - MUST pass pyang --ietf for a real module
>    - MUST pass pyang for example module

Yes, this follows from Benoit's proposed text above.

> I have already received private emails about implementing the
> example-jukebox
> module in RESTCONF as part of the standard.  We already have operational
> experience that people can be confused by the example modules, and
> think they are supposed to be implemented for RFC compliance.
> 
> 
> >
> >  The  convention SHOULD be used for example
> >  modules that pass validation according to RFC 7950.
> >
> >  The  convention MUST NOT be used for YANG fragment
> >  and for example modules that are used to illustrate some illegal constructs
> >  (therefore failing validation according to RFC 7950).
> >
> >
> >
> This text concerns me a little
> We are not following the  anywhere for examples.
> the tools are extracting anything that starts "module blah".
> IMO this makes it easier to confuse real and example modules.
> I would prefer to consider only real modules as Code Components.

I agree.



/martin


> 
> (We collect broken modules to test the compiler in modules/test/fail folder,
> so even bad modules might be extracted.)
> 
> 
> 
> In section 4:
> >
> > NEW:
> >
> >    All normative modules or submodules, example modules or submodules,
> >    and example YANG fragments MUST be valid according to RFC 7950,
> >    except when they are used to illustrate some illegal constructs.
> >
> > We wouldn't need this if you take my proposal
> >
> > In Section 4.2.1 "Example Modules":
> >
> > NEW:
> >
> >   An example module SHOULD have a namespace on the form
> >
> >     o  http://example.com/ OR
> >     o  urn:example:
> >
> >   An example module SHOULD have a description statement that describes
> >   that it is an example module, and what it examplifies.
> >
> >   An example module SHOULD NOT have any additional meta-statements
> >   (i.e., "organization", "contact", or "reference").
> >
> >   An example module SHOULD use the "description" statement in any
> >   definition where it is required to understand the example.
> >
> >
> > Fine.
> >
> > Note that the RESTCONF RFC publication depends on this RFC6087bis
> > convention. So let's quickly come to a conclusion.
> >
> > Regards, Benoit
> >
> >
> 
> Andy
> 
> 
> 
> > /martin
> >
> > _______________________________________________
> > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >


From nobody Thu Jan 19 02:40: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 6599C129444 for ; Thu, 19 Jan 2017 02:40:40 -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 60fsY5WchXSm for ; Thu, 19 Jan 2017 02:40:38 -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 A678E126BF7 for ; Thu, 19 Jan 2017 02:40:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1319; q=dns/txt; s=iport; t=1484822437; x=1486032037; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=1X9mAmcrdhCvUxJicV9/Y6ahq5h7F8OkuVD3fC2Rpw0=; b=lqg2wVuFCCJBqRxbr+3SgOBiNk9nL8mYAR8sd5n2E1fm8nATeHxZqjPM 0s3oiT2UcL6K4zzdUY/DsC3gHY8OoOti2C02qCob57EZKv3tiRUiD/tI5 Nn+A7oejV3UWMdDZTb6/CZJ7ciYGIpcENrQfRPJ4axnTJwAQ+FMWXZDMX o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAgDfloBY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAYECJ48qkRCTHYQbhiICgjoVAQIBAQEBAQEBYyiEagE?= =?us-ascii?q?FOEEQCxguVwYBDAgBAYh/sheKPAEBAQEBAQEBAQEBAQEBAQEBASCGS4IFgmmKL?= =?us-ascii?q?QEEm0SRZYowhj6KdId8NSKBFxIIFRWGcT6KGQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,253,1477958400"; d="scan'208";a="651777382"
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; 19 Jan 2017 10:40:32 +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 v0JAeVqv007602; Thu, 19 Jan 2017 10:40:31 GMT
To: Phil Shafer , Martin Bjorklund 
References: <201701182132.v0ILWhfx039384@idle.juniper.net>
From: Robert Wilton 
Message-ID: 
Date: Thu, 19 Jan 2017 10:40:26 +0000
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: <201701182132.v0ILWhfx039384@idle.juniper.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 19 Jan 2017 10:40:40 -0000

Hi Phil,

Wouldn't you just write this without the back reference to the 
deprecated/obsolete leaf.

E.g. wouldn't the following be sufficient to enforce the desired constraint?

     leaf old-stuff {
         status deprecated;
         must not(../new-stuff);
     }
     leaf new-stuff {
     }

Thanks,
Rob


On 18/01/2017 21:32, Phil Shafer wrote:
> Martin Bjorklund writes:
>> But marking definition as obsolete in one module cannot automatically
>> make definitions in *other* modules obsolete.
>>
>> (*) _maybe_ 7950 can be interpreted in this way when it says:
>>
>>    If a definition is "current", it MUST NOT reference a "deprecated" or
>>    "obsolete" definition within the same module
>>
>> If you're in a good mood, you could argue that a child always
>> "references" its parent.
> That's a massively deforming interpretation of "references".
>
> I'm not even sure this is a good rule at all.  Consider:
>
>      leaf old-stuff {
>          status deprecated;
>          must not(../new-stuff);
>      }
>      leaf new-stuff {
>          must not(../old-stuff);
>      }
>
> My new-stuff definitely references old-stuff which is deprecated,
> but this is a _good_ data model and should not be "MUST NOT"d out
> of existence.
>
> Thanks,
>   Phil
> .
>


From nobody Thu Jan 19 02:56:44 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 38859129441; Thu, 19 Jan 2017 02:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.7
X-Spam-Level: 
X-Spam-Status: No, score=-16.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, 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 Xf1Le9OBGyu8; Thu, 19 Jan 2017 02:56:38 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACC012943A; Thu, 19 Jan 2017 02:56:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2577; q=dns/txt; s=iport; t=1484823398; x=1486032998; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FxertJDErNDgBb70H9WXhu4ULAtTl8+ielQkvYJxrHs=; b=ib7Qc52oJFA/SVVK7sBYS5XsFoiorzyWBTJOpyQoIkAm9e9Hx/Ek7tSg ttsB4K8p4HyOEn7P+szMR6bR89hVsMAR3haRBii4Obj2kciLLpmVT5JVH 0wUoKniXTP/7v6OFlpE0XDxgYt6zTZhJwLcHpN+qyZtcnr8z5GOaC8ZYa 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQA6moBY/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR9gfA0HjVKRV5VYggwfC4V4AiaBUj8YAQIBAQEBAQE?= =?us-ascii?q?BYyiEYQkCBAEBODQLEAIBCDYQJwslAhIFhXKDEQ6xd4o8AQEBAQEBBAEBAQEBA?= =?us-ascii?q?QEhizmDDIRUgk0Fm0QBhmCLBIF3UoQ9iWiSbwEfOIFGFRgiXwuFTXOIV4ENAQE?= =?us-ascii?q?F?=
X-IronPort-AV: E=Sophos;i="5.33,253,1477958400"; d="scan'208";a="199997903"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2017 10:56:37 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0JAub3H007228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 10:56:37 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 19 Jan 2017 05:56:36 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 19 Jan 2017 05:56:36 -0500
From: "Acee Lindem (acee)" 
Thread-Topic: I-D Action: draft-ietf-rtgwg-yang-key-chain-13.txt
Thread-Index: AQHSckK0ovkAVP+npESQ+e4y1kcrKg==
Date: Thu, 19 Jan 2017 10:56:36 +0000
Message-ID: 
References: <148482273303.10461.13311488338617348540.idtracker@ietfa.amsl.com>
In-Reply-To: <148482273303.10461.13311488338617348540.idtracker@ietfa.amsl.com>
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.116.152.201]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <763B584D362B1C42BAD07CA1B5C91E8C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: NETMOD WG , "rtgwg@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-rtgwg-yang-key-chain-13.txt
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, 19 Jan 2017 10:56:40 -0000

This version uses NETCONF Access Control Model (NACM) rules, as defined in
RFC 6536, to make key-strings inaccessible by default. The key-strings are
now retrievable in the operational state as long as the proper NACM rules
are defined.=20

Thanks,
Acee=20

On 1/19/17, 5:45 AM, "rtgwg on behalf of internet-drafts@ietf.org"
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Routing Area Working Group of the IETF.
>
>        Title           : Routing Key Chain YANG Data Model
>        Authors         : Acee Lindem
>                          Yingzhen Qu
>                          Derek Yeung
>                          Ing-Wher Chen
>                          Jeffrey Zhang
>                          Yi Yang
>	Filename        : draft-ietf-rtgwg-yang-key-chain-13.txt
>	Pages           : 24
>	Date            : 2017-01-19
>
>Abstract:
>   This document describes the key chain YANG data model.  A key chain
>   is a list of elements each containing a key, send lifetime, accept
>   lifetime, and algorithm (authentication or encryption).  By properly
>   overlapping the send and accept lifetimes of multiple key chain
>   elements, keys and algorithms may be gracefully updated.  By
>   representing them in a YANG data model, key distribution can be
>   automated.  Key chains are commonly used for routing protocol
>   authentication and other applications.  In some applications, the
>   protocols do not use the key chain element key directly, but rather a
>   key derivation function is used to derive a short-lived key from the
>   key chain element key (e.g., the Master Keys used in the TCP
>   Authentication Option.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-13
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-yang-key-chain-13
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>rtgwg mailing list
>rtgwg@ietf.org
>https://www.ietf.org/mailman/listinfo/rtgwg


From nobody Thu Jan 19 04:57:58 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 D45EA129478 for ; Thu, 19 Jan 2017 04:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 hdpTdB9oPCqc for ; Thu, 19 Jan 2017 04:57:54 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A24D1129444 for ; Thu, 19 Jan 2017 04:57:54 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5FC791CC0339; Thu, 19 Jan 2017 13:57:56 +0100 (CET)
From: Ladislav Lhotka 
To: Phil Shafer , Andy Bierman 
In-Reply-To: <201701182353.v0INr1SU040570@idle.juniper.net>
References: <201701182353.v0INr1SU040570@idle.juniper.net>
Date: Thu, 19 Jan 2017 13:57:53 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] top-level mandatory nodes
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, 19 Jan 2017 12:57:56 -0000

Phil Shafer  writes:

> Andy Bierman writes:
>>mandatory for config=false means it must exist in an  for a 
>>operation retrieval.  It is by definition "server-supplied", so there is no
>>server validation to worry about.
>>
>>YANG constraints are used on clients.
>>Not that we are super-server-centric here, but client software
>>uses YANG, not just server software.
>
> I must be missing your meaning here.  Can you please give a
> use case for when the data modeler would use "mandatory true"
> for a "config false" top-level node?

An existing use case is the NACM module in RFC 6536:

      +--rw nacm
         +--rw enable-nacm?            boolean
         +--rw read-default?           action-type
         +--rw write-default?          action-type
         +--rw exec-default?           action-type
         +--rw enable-external-groups? boolean
         +--ro denied-operations       yang:zero-based-counter32
         +--ro denied-data-writes      yang:zero-based-counter32
         +--ro denied-notifications    yang:zero-based-counter32
         ...

The top-level node "nacm" contains three mandatory counters, and this
makes it mandatory as well. My understanding is that if a client asks
for complete state data, these counters must always be present in the
reply.

The situation here is a bit trickier because "nacm" is configuration but
I guess it is just an artefact caused by putting configuration and state
data inside the same container.

Lada

>
> Thanks,
>  Phil

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


From nobody Thu Jan 19 05:27: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 97183129439 for ; Thu, 19 Jan 2017 05:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5zUVNFkb86Qa for ; Thu, 19 Jan 2017 05:27:27 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BD1A41293E8 for ; Thu, 19 Jan 2017 05:27:26 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 367B91CC021B; Thu, 19 Jan 2017 14:27:28 +0100 (CET)
From: Ladislav Lhotka 
To: Benoit Claise , Martin Bjorklund , netmod@ietf.org
In-Reply-To: 
References: <20170116.164803.729427888661667991.mbj@tail-f.com> 
Date: Thu, 19 Jan 2017 14:27:24 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] example modules in 6087bis
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, 19 Jan 2017 13:27:28 -0000

Benoit Claise  writes:

> Martin,
>> Hi,
>>
>> It turns out that the recommendations on example modules are a bit
>> unclear.  Different drafts do very different things.  Some examples:
>>
>> https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2
>>
>> This example module really looks like a real module.  It uses an
>> IANA-controlled namespace, and the meta-statements indicate that this
>> is a normative modules.  But the module does not use the  tags.
>>
>>
>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1
>>
>> This module is better, but it is written to follow RFC 6087 rules
>> (pass pyang --ietf), with the result that it contains a bit of "noise"
> It takes a lot of YANG experience to be able to distinguish what is 
> noise or not.

I think it is up to the document author to design the example module so
as to convey the idea that the example illustrates, and sometimes it's
best to use bare statements, and descriptions would really be just
noise.

>> with some meaningless descriptions and meta-statements.  It also does
>> not use  tags.
>>
>>
>> A good example (IMO) is found in
>> https://tools.ietf.org/html/rfc8022#appendix-C
>>
>> It uses descriptions when necessary (high s/n), no fake
>> meta-statements etc.
>>
>> However, it might be a good idea to require example modules to have a
>> "description" statement that explains what the module examplifies.
>> For example, the example-rip could have:
>>
>>    description
>>      "This example module demonstrates how the core routing data model
>>       can be extended to support a new control-plane protocol.  It is
>>       intended as an illustration rather than a real definition of a
>>       data model for the Routing Information Protocol (RIP).";
>>
>>
>>
>> I think that 6087bis is clear when it says:
>>
>>    The guidelines in this document refer mainly to a normative complete
>>    module or submodule, but may be applicable to example modules and
>>    YANG fragments as well.
>>
>> I think this states that example modules do not have to pass pyang
>> --ietf.
>>
>>
>> In order to make this more clear, I suggest the following changes to
>> draft-ietf-netmod-rfc6087bis-09
>>
>> In the Terminology section 2.4:
>>
>> NEW:
>>
>>    o  Example module:  A complete YANG module or submodule that is
>>       intended to illustrate some specific aspect, but not intended for
>>       actual use.
> It doesn't solve this issue, because 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09#section-4.2.1 
> says:
>
>       The  convention SHOULD be used for complete example
>       modules, but not YANG fragments.
>
> That implies to me that we have 3 types:
> 1. _complete _example modules => I read it that they must pass pyang 
> -ietf, SHOULD have 
>      If there is , it's because people will want to extract 
> it, and play with it. So the tools chain must work
> 2. the other example modules. No . I guess they don't pass 
> pyang
> 3. YANG fragments. No . I guess they don't pass pyang
>
> In practice, 2 and 3 are the same. So we need just two definition
>
> Scrap "complete" would help but that's not enough:
>
>   The  convention SHOULD be used for example
>   modules, but not YANG fragments.
>
> We only need to clarify 3 points
>      , yes/no
>      pyang, yes/no
>      pyang --ietf yes/no
>
> I guess we want, putting all this together:
>
>    o  Example module:  A complete YANG module or submodule that is
>       intended to illustrate some specific aspect, but not intended for
>       actual use. Example module MUST be valid according to RFC 7950,
>       except when they are used to illustrate some illegal constructs.
>       Example module MAY be valid according to the rules in this document.
>
>    o  YANG fragment:  A incomplete YANG module or submodule that is
>       intended to illustrate some specific aspect, but not intended for
>       actual use. YANG fragments MUST be valid according to RFC 7950,
>       except when they are used to illustrate some illegal constructs.
>
>
>   The  convention SHOULD be used for example
>   modules that pass validation according to RFC 7950.
>
>   The  convention MUST NOT be used for YANG fragment
>   and for example modules that are used to illustrate some illegal constructs
>   (therefore failing validation according to RFC 7950).
>

One option for automatic tools might be to parse module registrations in
IANA Considerations, and require --ietf compliance only for these
modules. Other modules demarcated with  would just
need to be plain valid, as you write.

Lada

>
>>
>> In section 4:
>>
>> NEW:
>>
>>     All normative modules or submodules, example modules or submodules,
>>     and example YANG fragments MUST be valid according to RFC 7950,
>>     except when they are used to illustrate some illegal constructs.
> We wouldn't need this if you take my proposal
>>
>>
>> In Section 4.2.1 "Example Modules":
>>
>> NEW:
>>
>>    An example module SHOULD have a namespace on the form
>>
>>      o  http://example.com/ OR
>>      o  urn:example:
>>
>>    An example module SHOULD have a description statement that describes
>>    that it is an example module, and what it examplifies.
>>
>>    An example module SHOULD NOT have any additional meta-statements
>>    (i.e., "organization", "contact", or "reference").
>>
>>    An example module SHOULD use the "description" statement in any
>>    definition where it is required to understand the example.
>>
> Fine.
>
> Note that the RESTCONF RFC publication depends on this RFC6087bis 
> convention. So let's quickly come to a conclusion.
>
> Regards, Benoit
>>
>>
>> /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


From nobody Thu Jan 19 06:14:43 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 8D90E1270B4 for ; Thu, 19 Jan 2017 06:14:41 -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 2V_fxcAUmHmr for ; Thu, 19 Jan 2017 06:14:40 -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 BECF11295ED for ; Thu, 19 Jan 2017 06:14:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3983; q=dns/txt; s=iport; t=1484835279; x=1486044879; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=7rvZum9yH9IhGCOiyUdoDDJ0/eVxnBGW667Nnn1i0Tk=; b=QSylDi+LAsesy3/FnR9fhEyyX9brfpRYYzkR5s6pZ2W62G/7gILwPwbI M6d8tJOi6QDbcVs50JfOxsTx7XsL/axKkvNe0mTEtrpO1iGPtaMkdANNF 5M/UjLqjRbDSzV5FgmVgYQJmSpmoeYOfHyg40MavxlDCDtkvHITcigjFY w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAQCWyIBY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9QAQEBAQGBAieOOHKREZABgxyCD4IMhiICgj0YAQIBAQEBAQE?= =?us-ascii?q?BYyiEaQEBAQMBeRALBBQjC1cGDQgBAReIYAiyECuKFAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GS4IFgmmEM4V6BZtEkWWKMIY+inSHfB84gRcSCBUVhSmBSD6KGQE?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.33,254,1477958400";  d="scan'208,217";a="649964450"
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; 19 Jan 2017 14:14: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-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0JEEb3a007562; Thu, 19 Jan 2017 14:14:37 GMT
To: Phil Shafer 
References: <201701182126.v0ILQC6h039302@idle.juniper.net>
From: Robert Wilton 
Message-ID: <5f5bed10-d84e-fcb8-fdaa-722e00078dbb@cisco.com>
Date: Thu, 19 Jan 2017 14:14:32 +0000
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: <201701182126.v0ILQC6h039302@idle.juniper.net>
Content-Type: multipart/alternative; boundary="------------F17D467CC4070C9E726606B9"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 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, 19 Jan 2017 14:14:41 -0000

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

[Dropping netconf from the reply]

Hi Phil,

On 18/01/2017 21:26, Phil Shafer wrote:
> Robert Wilton writes:
>>> 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.
> We're trying to avoid a "separate state leaf" solution.  That's imho
> the motivation for this whole exercise.
Yes, I agree that we are trying to avoid separate state leaves where 
possible.  But there are some cases where the value space for the 
operational value may differ from the value space that may be configured.

For these point cases, adding an additional config false leaf should be 
fine.  E.g. section 6.4 of draft-nmdsdt-netmod-revised-datastores-00 states:

    o  There may be some differences in the value set of some nodes that
       are used for both configuration and state.  At this point of time,
       these are considered to be rare cases that can be dealt with using
       different nodes for the configured and state values.


Rob

>
> Thanks,
>   Phil
> .
>


--------------F17D467CC4070C9E726606B9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
[Dropping netconf from the reply]

    

    Hi Phil,

    

    
On 18/01/2017 21:26, Phil Shafer wrote:

    

    

      
Robert Wilton writes:


      

        

          
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.


      

      
We're trying to avoid a "separate state leaf" solution.  That's imho
the motivation for this whole exercise.

    

    Yes, I agree that we are trying to avoid separate state leaves where
    possible. But there are some cases where the value space for the
    operational value may differ from the value space that may be
    configured.

    

    For these point cases, adding an additional config false leaf should
    be fine. E.g. section 6.4 of
    draft-nmdsdt-netmod-revised-datastores-00 states:

    

    
   o  There may be some differences in the value set of some nodes that
      are used for both configuration and state.  At this point of time,
      these are considered to be rare cases that can be dealt with using
      different nodes for the configured and state values.

    

    Rob

    

    

      

Thanks,
 Phil
.



    

    

  


--------------F17D467CC4070C9E726606B9--


From nobody Thu Jan 19 06:37: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 87DBA129605; Thu, 19 Jan 2017 06:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wlw2bDYSY-up; Thu, 19 Jan 2017 06:37:18 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA3512941A; Thu, 19 Jan 2017 06:37:14 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0JEbCIl031986; Thu, 19 Jan 2017 14:37:12 GMT
Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0JEbAAN031974 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2017 14:37:11 GMT
From: "Adrian Farrel" 
To: 
Date: Thu, 19 Jan 2017 14:37:13 -0000
Message-ID: <062301d27261$870b13d0$95213b70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJyYXTNzlKw7Qe5TOOiHtOFQNy44Q==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22832.007
X-TM-AS-Result: No--2.088-10.0-31-10
X-imss-scan-details: No--2.088-10.0-31-10
X-TMASE-MatchedRID: Mw7VPR8g6Ol7Zz8UIZpY+zDfgfM3Zc/RH5SN+D7shh+SXo7SF5OkbwOR 3tZA0vji4vM1YF6AJbZcLc3sLtjOt7bmZosI/5Zy3QfwsVk0UbvqwGfCk7KUs7kgAfAT6npfG3H 5y60871ZZkG4q8FR5J4Fd7MGzaXGFj0+veSYdz9unyLbqIYI358P9zZjybGuKTVn51J26DC8gSR GZYS1q0EMMprcbiest
Archived-At: 
Cc: draft-ietf-netmod-yang-model-classification@ietf.org
Subject: [netmod] Reference error in draft-ietf-netmod-yang-model-classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 14:37:19 -0000

Hi,

I think [YANG-Data-Model-for-L3VPN-service-delivery] should point to
draft-ietf-l3sm-l3vpn-service-model not (the old) draft-l3vpn-service-yang.

Indeed, in general, if you end up having to point to a tools copy of an I-D not
a datatracker version, this is usually an indication that you are pointing to an
expired draft.

Thanks,
Adrian


From nobody Thu Jan 19 08:25: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 DEFD012964C; Thu, 19 Jan 2017 08:25:22 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 9nfj-vpZ-hDw; Thu, 19 Jan 2017 08:25:21 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90DE129630; Thu, 19 Jan 2017 08:25:20 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0JGPHhx013266; Thu, 19 Jan 2017 16:25:17 GMT
Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0JGPEle013161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2017 16:25:16 GMT
From: "Adrian Farrel" 
To: 
Date: Thu, 19 Jan 2017 16:25:16 -0000
Message-ID: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJycEnw/7BBgfqES8aIslF6yofdUQ==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22834.001
X-TM-AS-Result: No--2.395-10.0-31-10
X-imss-scan-details: No--2.395-10.0-31-10
X-TMASE-MatchedRID: dm4twJuyasFdFN0T1voiz6+dYEguu4aVnvBHr/aFnM60Vg+MnSE2GE9k rTmEDheM6NaGQbD1MQotcf0T9OPlmKucHbFRvOwLkkRQ7aojOUtBXoFkn1Z4VtlQ+Mh6O7dgnCV oYY7P13dTu7CL9BmESD3tqM9S6C/ny5j7H7ClYgdCnGIuUMP0VZlhiS3ydre3TiKNDvuWVeEzAS kv5eYpN/IdglT1fbSd/53wujJtGosdj9vNGYhpkaDH6drx3JPVZuNx7eknjx6tj24Xqh0yXKgTP HjMLlQlnROnM8/nlYXuldQ+DXnr+vGU4m5A0eV94t2mucDkRBGeimGtNywjtpsoi2XrUn/JyeMt MD9QOgDGlDvsLUDW2o6HM5rqDwqt2qZHwIa3ykzJZid1t7cvJk7AdmqkseA/Ibxljy87+6mPSB7 6+qMMPSILIX4uwY/We11BpB573ugxQ37Yfz8VfFCPaV/RzzgXJeJ1WMCERkGtftyYo2KwDjKpoR vzNKOP9DB8M7tiaMAWbf9vijls8w==
Archived-At: 
Cc: opsawg@ietf.org, draft-ietf-netmod-yang-model-classification@ietf.org
Subject: [netmod] Question on draft-ietf-netmod-yang-model-classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 16:25:23 -0000

Hi,

We've been trying to ensure that draft-wu-opsawg-service-model-explained is
consistent with the latest version of
draft-ietf-netmod-yang-model-classification. In discussions with Tianran a
question has come up.

In section 2 you have a nice definition of Network Service YANG Modules and this
definition maps nicely to our definition of "service delivery models".
Furthermore, your figure 1 shows Network Service YANG Modules on the interface
between OSS/BSS and the various network services.

We have further defined "customer service models" at a higher layer still. That
is, on the interface to the customer. This (of course?) assumes that the OSS/BSS
is not customer code :-)

However, your discussion of Network Service YANG Modules in section 2.1 seems
slightly at odds, although this may be just ambiguity.

For example, when you say, "Network Service YANG Modules describe the
characteristics of a service, as agreed upon with consumers of that service,"
this is not the same as, "This model is used in the discussion between a
customer and a service provide to describe the characteristics of a service."
That is, the former case could be arrived at after processing based on the
latter case - processing that we have called "service orchestration" but might
(of course) be what leads to the operator poking the OSS/BSS.

This might all be fine and good, but later in the same section you say "Network
Service YANG Modules define service models to be consumed by external systems.
These modules are commonly designed, developed and deployed by network
infrastructure teams." And there you introduce two terms that are previously
undefined and only server to add ambiguity. Specifically "external to what?" I
could make and argument that the OSS is developed and deployed by network
infrastructure teams, ad also that the OSS is external to the network itself.

And, in between these two quoted pieces of text, you have...

   As an example, the Network Service YANG Module defined in
   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
   model for Layer 3 IP VPN service configuration.

Per my other email, this reference needs to be fixed. But I struggle to see the
L3SM module as consistent with your figure. It may or may not be consistent with
your text dependent on the interpretation.

In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show how we
(the authors) think L3SM fits into your classification. Here we place L3SM
further up the layering stack.

[Apologies for not spotting this sooner. The citation
"YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
delivery" which I took to imply a different module.]

Thanks,
Adrian


From nobody Thu Jan 19 09:21: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 5E01A129456 for ; Thu, 19 Jan 2017 09:21:17 -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=ham 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 QjRz6OhfZ-1U for ; Thu, 19 Jan 2017 09:21:15 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id D1CF1129447 for ; Thu, 19 Jan 2017 09:21:15 -0800 (PST)
Received: (qmail 6464 invoked by uid 0); 19 Jan 2017 17:21:12 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 19 Jan 2017 17:21:12 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id aHM81u00W2SSUrH01HMBJw; Thu, 19 Jan 2017 10:21:12 -0700
X-Authority-Analysis: v=2.1 cv=YuCcGeoX 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=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=48vgC7mUAAAA:8 a=5iXfCOrpXH0-oAzJj94A:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WOwf+2EfZPkBSUrScjws9n1LxqPQKfiLquL2S2XWibo=; b=wK/Sn+HZgdpdMULmQHgcL/36Dv lKmFAnR8ww6SSC8Jq3O9fIQZr0u1kiOL8ePZD00Ycgs98hVcz1NFKDekRCbUgSQrMQLQOVw6jLJsu GyIgXtBPVpMCSuGj8UrfnIP6x;
Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:49109 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUGOa-0005rA-1i; Thu, 19 Jan 2017 10:21:08 -0700
To: Martin Bjorklund , netmod@ietf.org
References: <20170117.132913.781493366440105564.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <0a200394-d2c0-a20d-eae8-a41bb2fd2c18@labn.net>
Date: Thu, 19 Jan 2017 12:21:04 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170117.132913.781493366440105564.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
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: 1cUGOa-0005rA-1i
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:49109
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: Re: [netmod] mount-point in anydata
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, 19 Jan 2017 17:21:17 -0000

Martin,

On 1/17/2017 7:29 AM, Martin Bjorklund wrote:
> Hi,
>
> Currently, the schema mount draft says that the "mount-point"
> extension only can be defined in an "anydata" node.  However, this
> doesn't really work, since RFC 7950 says:
>
>    An anydata node is treated as an opaque chunk of data.  This data
>    can be modified in its entirety only.
>
> But the idea with schema mount is to build a composite model that can
> be manipulated just like a normal model, or a model that is
> augmented.  If we mount models in an "anydata" node, clients would
> have to replace the enitire mounted subtree in order to change e.g. a
> single leaf.
>
> For this reason, I propose that we go back to the previous model where
> "mount-point" would be allowed in "container" and "list".  Note that a
> client that doesn't know anything about these mounts would see some
> nodes in some unknown namespace; just like in the case that there is
> an augment that the client doesn't know about.

would it be better to have the  schema mount draft updates 7950 to allow
for sub-tree changes under anydata?  It "feels" cleaner and I'd expect
to have no real impact on servers as this would only impact servers
supporting the draft.  I'm unsure about client impact though...

Thanks,
Lou

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


From nobody Thu Jan 19 09:24: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 B52D0129456 for ; Thu, 19 Jan 2017 09:24:03 -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=ham 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 0wVv8cvzDHkS for ; Thu, 19 Jan 2017 09:24:02 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id EBD1912942F for ; Thu, 19 Jan 2017 09:24:01 -0800 (PST)
Received: (qmail 3934 invoked by uid 0); 19 Jan 2017 17:23:59 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 19 Jan 2017 17:23:59 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id aHPv1u0172SSUrH01HPysz; Thu, 19 Jan 2017 10:23:59 -0700
X-Authority-Analysis: v=2.1 cv=JsBi8qIC 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=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=BqEg4_3jAAAA:8 a=KWfyCvO_KRk7Rjgaix8A:9 a=pILNOxqGKmIA:10 a=mhd2NDuUijAA:10 a=0mFWnFbQd5xWBqmg7tTt:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=C61lE/YlzoYYpY8k6+D2Z4groGXxmVr02dYmhJpEeyI=; b=GpuWY5Sc8NAvHQTsgJIgMoXTg1 AfxRsDTdSudXdLtTwnfv8/+Z0L6AQ5VblxWSZ/vOEyVqTXjD2sJzvB5ufqgAd2t5LUI8UTv7awKrG mTKBkSDd4kETZZ1549fAbPUec;
Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:60042 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUGRH-0006AI-IA; Thu, 19 Jan 2017 10:23:55 -0700
To: Martin Bjorklund , rfc-editor@rfc-editor.org
References: <20170118114858.62A63B80FFD@rfc-editor.org> <20170118.145532.995038902796253716.mbj@tail-f.com>
From: Lou Berger 
Message-ID: 
Date: Thu, 19 Jan 2017 12:23:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170118.145532.995038902796253716.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
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: 1cUGRH-0006AI-IA
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:60042
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911)
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, 19 Jan 2017 17:24:04 -0000

Martin,


On 1/18/2017 8:55 AM, Martin Bjorklund wrote:
> RFC Errata System  wrote:
>> The following errata report has been submitted for RFC6020,
>> "YANG - A Data Modeling Language for the Network Configuration
>> Protocol (NETCONF)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Ladislav Lhotka 
>>
>> Section: 6.1.3
>>
>> Original Text
>> -------------
>> Within a double-quoted string (enclosed within " "), a backslash
>> character introduces a special character, which depends on the
>> character that immediately follows the backslash:
>>
>>  \n      new line
>>  \t      a tab character
>>  \"      a double quote
>>  \      a single backslash
>>
>>
>> Corrected Text
>> --------------
>> Within a double-quoted string (enclosed within " "), a backslash
>> character introduces a special character, which depends on the
>> character that immediately follows the backslash:
>>
>>  \n      new line
>>  \t      a tab character
>>  \"      a double quote
>>  \      a single backslash
>>
>> The backslash MUST NOT be followed by any other character.
>>
>> Notes
>> -----
>> The text doesn't state whether other characters may follow the
>> backslash, and if yes, what it means. Existing implementations have
>> used three approaches:
>>
>> 1. report an error if another character follows the backslash
>> 2. keep only the character following the backslash, i.e., for example,
>> "\x" is the same as "x".
>> 3. keep both the backslash and the character following it.
>>
>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly
>> adopted option #1. However, many modules are still being written using
>> YANG version 1.0, so it is important to clarify this issue in RFC 6020
>> as well.
> I don't think this errata should be accepted.  As stated, the spec is
> unclear, and YANG 1.1 has fixed this problem.  But it is not clear
> that the original intention when RFC 6020 was written was #1.
> Accepting this errata now would make existing implementations and
> modules invalid.
>
> The solution moving forward is to use YANG 1.1.
>

IMO this highlights why 1.1 probably should have at least been
identified as updating 1.0...

I have no idea that it would take to just change this, but I suspect it
might be a new RFC.  I'll ask the rfc-editor about the process (no
change being made at this time...)

Lou
> /martin
>


From nobody Thu Jan 19 09:55: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 0E82E129406 for ; Thu, 19 Jan 2017 09:55:24 -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 ZewUaqOQRrJK for ; Thu, 19 Jan 2017 09:55:22 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79EE21293DB for ; Thu, 19 Jan 2017 09:55:22 -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 764951AE018A; Thu, 19 Jan 2017 18:55:21 +0100 (CET)
Date: Thu, 19 Jan 2017 18:55:21 +0100 (CET)
Message-Id: <20170119.185521.426199483109430578.mbj@tail-f.com>
To: lberger@labn.net
From: Martin Bjorklund 
In-Reply-To: <0a200394-d2c0-a20d-eae8-a41bb2fd2c18@labn.net>
References: <20170117.132913.781493366440105564.mbj@tail-f.com> <0a200394-d2c0-a20d-eae8-a41bb2fd2c18@labn.net>
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: netmod@ietf.org
Subject: Re: [netmod] mount-point in anydata
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, 19 Jan 2017 17:55:24 -0000

Lou Berger  wrote:
> Martin,
> 
> On 1/17/2017 7:29 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > Currently, the schema mount draft says that the "mount-point"
> > extension only can be defined in an "anydata" node.  However, this
> > doesn't really work, since RFC 7950 says:
> >
> >    An anydata node is treated as an opaque chunk of data.  This data
> >    can be modified in its entirety only.
> >
> > But the idea with schema mount is to build a composite model that can
> > be manipulated just like a normal model, or a model that is
> > augmented.  If we mount models in an "anydata" node, clients would
> > have to replace the enitire mounted subtree in order to change e.g. a
> > single leaf.
> >
> > For this reason, I propose that we go back to the previous model where
> > "mount-point" would be allowed in "container" and "list".  Note that a
> > client that doesn't know anything about these mounts would see some
> > nodes in some unknown namespace; just like in the case that there is
> > an augment that the client doesn't know about.
> 
> would it be better to have the  schema mount draft updates 7950 to allow
> for sub-tree changes under anydata?  It "feels" cleaner and I'd expect
> to have no real impact on servers as this would only impact servers
> supporting the draft.  I'm unsure about client impact though...

Actually, this would have bigger impact on servers, than on clients; a
client could still treat the entire thing as an opaque blob - but
that's not what we want.  I prefer a solution that doesn't change the
core YANG semantics.  The text in 7950 is pretty clear, e.g.,:

   Any "operation" attributes present on subelements of an anydata node
   are ignored by the NETCONF server.



/martin


From nobody Thu Jan 19 13:27: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 318F3129413 for ; Thu, 19 Jan 2017 13:27:12 -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 OjYwwCyJc6cO for ; Thu, 19 Jan 2017 13:27:10 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0130.outbound.protection.outlook.com [104.47.32.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 4134A12959B for ; Thu, 19 Jan 2017 13:27:10 -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=xtuT9jxjz2lFITbjiiZw5ZkphRKFf4heR+skbyJBsHg=; b=KYSC0GM8bnu0khULttr3dOJTqqHsDigjpx++qF4FMHyTK4jJGZs9n1ASUxO1au8t/4HbJW0s82Z9Gv+T/42PXYYifa5jYF3qLOuQxtjUnVj1KamQWCI1yBp8wOdEyJaBq1HLXxZCmCngaQ0bE17s31/Aa5yyl4MPN2fuQNc7AQw=
Received: from BL2PR05CA0031.namprd05.prod.outlook.com (10.255.226.31) by DM5PR05MB2938.namprd05.prod.outlook.com (10.168.176.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 21:27:08 +0000
Received: from BN1AFFO11FD048.protection.gbl (2a01:111:f400:7c10::165) by BL2PR05CA0031.outlook.office365.com (2a01:111:e400:c04::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Thu, 19 Jan 2017 21:27:08 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD048.mail.protection.outlook.com (10.58.53.63) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Thu, 19 Jan 2017 21:27:08 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Jan 2017 13:27:06 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0JLR52R026457; Thu, 19 Jan 2017 13:27:06 -0800	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0JLN2wu052590; Thu, 19 Jan 2017 16:23:02 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201701192123.v0JLN2wu052590@idle.juniper.net>
To: Robert Wilton 
In-Reply-To: 
Date: Thu, 19 Jan 2017 16:23:02 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(8276002)(5003940100001)(7126002)(8936002)(50986999)(5660300001)(110136003)(54356999)(68736007)(189998001)(626004)(7696004)(356003)(92566002)(81166006)(8676002)(81156014)(305945005)(97736004)(54906002)(229853002)(47776003)(4326007)(50466002)(48376002)(77096006)(86362001)(38730400001)(105596002)(53416004)(2906002)(2810700001)(53936002)(2950100002)(6916009)(106466001)(1076002)(69596002)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2938; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD048; 1:l1EcSjxChIALr/1uorVIH/kaH3u88XlEK+ow8Z7a+K3IOgS236USwAS/xwV7Fo0rHQoz46zf5DE8fRbWGSKM6H5KO5ibUGIk6uxIb8UpRikY0k35IeZrPSQlONxMbE33UBRhGF+bNty4Ab4Xo+RtWVAGPZxE46U+Q+0G/b/seYimKd2WrBOsaFe12ZG5APvcBIRVXNiVtpNqvpeK55+xk2SmMLkHG3aCQRRK9zjihxE69DQUeQm/L1uzdvhgZgNrWWgkpQfyDZaqoRrW3UR4VrWa6m4F/jAbmiSCkvVAPJsCYVB17m1MJ4xYfVJLRzMKkJeHgNgyN24ZgMHB3wKhDfZebt2o3w13IZqFuDEyzCJqv+1egexFuLGVdv9bCuVzLm7VXyiRMlMXOIFgdn0E9JMrYZAXWeP073icZCfmPc+nIvwjMulpagA+qqUbzoDMKxTUeTNbxF6XLn1qcr4IRx7RhCKyI1TnHMOiNMQYFtcX0Ey0ybFwySzZMmBcSL8fpoL1LdPtLmsenEHL0HZVoAgVuQ8xNRgGbahv+ApvRlbpIvyax/ru+N3EBmiW6hRy
X-MS-Office365-Filtering-Correlation-Id: d6b493f0-ef0c-4b3f-6eea-08d440b1ec5d
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR05MB2938;
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2938; 3:/soLkeQQ/dxEDsOc6z71l5PXF8EqiR7DWTig81ckXkn23y15hAUQdFhDLVzmCMgDRI/APSvCWsiAuB/4yTbf60uWyx1xgHOqXvRf6G+FcpNdbQqK0WY75c9SQ9E3f8K9pSKYin0Yg8q7nV0EYTuRCUxghz2rL8HOaYo/HcY1su4YFTLRCQZRRd+Tj89Z9+W3LFyLb9IqAvAdkMa4U1YiRzvSZa7gTiPSNBfn3pTGltiIPgq7CyMTvma4xiMZ/k7aX5/RIxHL3bDvT0I2rY5AxAZk6nhfom2796q+Hfu6UsK7pv8JP1cUYCmpBcZxFniXbJNNga0ON7ggyzwMlMxbWW0jInLIkmI+IX1oWcb/KnAF1A/fk0HZT3Lvp+cHdfrV
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2938; 25:5TVoTbP2J9qCjZIIz9mS3+lhvaFVImhFpmsxVy2HhG84qQAgCGHwkI2vEeIH1wDZIG5l2q8YbKgxDbCIwTavQN0r4OH2RraGZ1ZpgCufjG0fS6vC8RexDFQgyR3flYWheYBL/MhaTxYWU8wU5+aZ2fpkxumUyoHuEu3CQmI89m+OfInXy/HUJZ+C5n4Gy0cE79+5gRI7XmAs+iOx6RjkipXqsAp2nz3FZtBoybyY+rhxdD0xfRNm7efashzayMgOEcMz7+XfT3p4Nitcf70r04QI3kFYGS18Zeh4b0AU1N+KjFLw/mQK2tqjl67LXqIH5oDBoll9Se9+Qt+vrRjjAnFCVfr1S8DxniDxW2c/mfqjMVhgg4qWGHKoVhOlPcup+mT+KObhngyjDdS0gjvC4VHbLKbl5P7bzogUWZXKMD73mEgH91rNxXfkxbdd++NhDguJXzZ98Ay1u7/Z8kQuAjONhBTnnEI8d5tbzlIHn8+YptINLIoqjaVg5AxDWBxF3SP06TaB4y9jOXVo7qsTDAsb5V2LIGP1VNpcT34pU0Ur9JzmcGR5hUrYo9QJJ8zdP0N2106c2E7j4Z/SqDJkaU7po81Ng4ppJ+tydGi9r3NNiM5QWavvCa8gxu6TWDH4dh5LycPLixPLlDe0A9DnHmn/K/t2EMJ8zJjyTc0cfeGA3WST4H5tx/c3GJA/JpfEwpa5r2NfxlHuswf/JQ5B4WD52H9sUy2Nd0Sh+lT61No2tNF1hkQ5DQEbRflfVY+VZptu2fRPB6aN2EbrdctJxehMCn3qNbT9h6twPeb5opk=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2938; 31:H+LW4YqyJ+FkRvtUJihIMcf19lhbUHKeafwT5sRD6jdPa0zZLH/eccycyC+43gSzHacB9gjkaVjA4bdXfLbDFehEBhmLKNq4g/0GqOTi8Toh7htH1nF8ge1RSMVZ0K2thIk+A2hoHRaAC5o7QxqKUSPVNxs0je6BuEbzW4enb2hWjKxIrNqE1eW7in+KZvNTW2Ivka5jk7ESAybqS22cPZBd/rMtNjsOLYrlMrG4fiBOGRCjN9tLEzXt4CR2yRGUH++gGau5X9ooWssDpMygtB85BqN2PdG79/gL85rlTJo=; 20:0bQXPPP+K6/zJjVJV7wk8XTdiOJxcPwVJQO4KI6CHK/5p2y9gvgrWSx5fNmK0KF3LlZmmb21WCZmCfNP1REQs5m+gFc9Mntzr7MDwAJnrCmM14/inFEACwGXsNbU4e6rXf+2jROiU0kTTJ+1oNIhDBzpGI/pM9v+ytj8uPQ5NmQ/Mc64Ci3KQlFKGOW6f+I0Yn6T2eoRu3ViHEC8hXARO9gcAj79n906wFtTM4fGIn3Y+FIp6IzE2UM+NSsi9mMYZyRboVHy3FuP0tDx+zmcCYiG+/Ow4LDAWJTY8CT9im9k0ILsU6zz4qzqzyHIa4PZo9cftf0FfXYXYKZgK3Wo3rLCNdVCJQzSrFDJmuhPuvsKbr/nWnD7BuH0v5TlOn94AdEUk9GUno4lQ/Ndp3ZLDi82wLtMgg/lXWyVnEWA3wE2X44VUo9H7L8m3csEd7MccnzG3khhfQRHDcF3RpoD4uGs6zJHjSUSrkRnAELA0zRY/V+lPuA6HKTyAPJh1d0O
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)(13015025)(13017025)(13024025)(13023025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148)(6042181); SRVR:DM5PR05MB2938; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2938; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2938; 4:sA8G3q62ailrTR0eZ8P215yntXTAgfbcz3CtmoM6tFChCrBc/FR3LQVyPThKP6t5QbAe9GiAcaPreyUr/4rJSObv5we6Ku1spwyYlPjcr/VcIBaObWBIBS7lrDdDFrTZ3Ia5jVa4g+CgG/pWcSBDp55bjxARyX8TXNj68scrxQn1WlFF9BKkPnThkaJdAq3E1BArv1gM3XtY6nDDbSQrNxajgE12/QFLKOKANb6sJIFGTRg1zCGwWhJxKdpj6fsQHblBirSIWYeVPX9MO7HGJakQryPa+2hB/DuW8pfzQmYAjePvh36dASoVl0FjCqzE9kY2Xx1PznkdNAweeqwlps+XKpQVRTykwEf9ppj3Zzv+E4Vrg+T+lCK3dAnp6Q2mX04c2rfx6rtcX7DYOwAtjH2kn/vg35PVBb1EoDVx+nxtGlPw/RaT2pJSHBAZAg9ckKLlocHINdAs9WTD2E4/dN+XHuXit36echX4dQfRALY6c6yf/EdyCRpzHDyzbB/vqm0LOQDU3aN0rDBkurKNvf6SeP859rd6rGpZKof47zB4kSt+IY6bD4Eeimo4UVwuBWj1g30XAWDT2DvtyM3yXCUU6HCZxC8DSyueVlU+pzxqUMB8cR2XeonRKWCbfZCi1zwtnpmZlfROBjVKI7zU5LWjEJx5ggk/vLriyWcrQrTbZhZh3BDn8gQhX1b5hg9AQCajDkEMTbN2jtRfcRPPgQ==
X-Forefront-PRVS: 0192E812EC
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB2938; 23:0J0b74xvs+fJDZ5GWEU4MGjvwaonmAyGpH9CpknZ+?= =?us-ascii?Q?lBl4Z+nxWrsiLbpMUNcanJZrQj0D+JhkMKqS+DokLAulF7clnQ4gmjKysUGp?= =?us-ascii?Q?PdfuJ+/OnWRj5bhzgrKIod+K1jfJFHwlpHvRM7QqspgEKapppVcqjQLB8Www?= =?us-ascii?Q?eaa79BSIJ9WR4vBljV4j4JuZP6qO30pNu9ahiSPwbHMeqzgzEmQnoiN77+qh?= =?us-ascii?Q?xf/Yb6/dIvZTU/oSnsm+JSq4rsTk6Iyh09joGh0u1OPc4XZnKaACBpJnwAHW?= =?us-ascii?Q?3wJysqrlB3lzjTer+7qIr7bIXs+5k4W0l76jGInO18KhOXhu/TCLKSK36kqk?= =?us-ascii?Q?+wcPb1kjeDZEZU3gfY0D0HWLtHAzG3I7QZsZ6ins3TvmzUj/USkZjs++h1tz?= =?us-ascii?Q?meN16LgxWXG1gXjiOEA9ny2xN7tynKGgtFqJPA3an+Ik+DahKO3XFVGPV2AZ?= =?us-ascii?Q?jsECDYIC8hvoshq4/rvmp22h1BDHz7EN36T1CqdW8N0++x1JCvamwRdjaTcV?= =?us-ascii?Q?YDcKn3dlaa06uVZ8Q6ebYi9hmx+GVZtzx4QHeN7EHneX/4ft3PltfM9Lsyp1?= =?us-ascii?Q?FPEda16ya0SPOnVbzpamA9Kl9sRC62y4p+yINt/huTXPrRuvCO1jn8rnRrrI?= =?us-ascii?Q?z+AOvWAc+SFEeDdlO83jEeWE0EvajPGx/wuJ52J1T2qJRkBfcfX5nvErbLCq?= =?us-ascii?Q?BXrHuov0pm6E5Zx1lEEvGyl6GQLRHC+/uskmky8EstH2/+9sT4MrnRKi4Z7z?= =?us-ascii?Q?Tvyp6S5Brjly27ccAwEYfvkZr/okbC3TryUHqTp0LBBOvxCL//LyCWyvPdJD?= =?us-ascii?Q?5A4RU2uOHm4lnuncM4735bBA3w2EXrmO0wDU1bOAIc/PkKoezV1pZT7LirGg?= =?us-ascii?Q?zbrT2vjDHJiAIZBP4yuMlVDZufyyZJ6j72aiGgdbFLhV1Xrm7Y9FmY56IuPf?= =?us-ascii?Q?06PVkTOnSWCrpnms6nwVmWWRg3DNpR2Hhz9+AzBFv0JEI1S9b++yfBCjq9A5?= =?us-ascii?Q?tm4XA0iar7Ft5kpFcujMy2gJn8p3RXJC93Z3K4rc/jmAeH4ohnt9PJ1L6eD1?= =?us-ascii?Q?DHlIIM=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2938; 6:hazJ5ZK3HgDDLaRbLvV2BI/gVBzXXBbHgltnkxbNNgaFpke7+Ng3yGbq0hJpfcS3KHir1WwE4zP/OhoL4Qg36pZlRFUG7rupHiHWu7g1Jm90QVXTKvXJnDj+GhdAibyg1A2TvJCCguxjeYNBn1hm75GffaCzTNQusdR4m2dfSbIpJcP0Wsx782sIVcy2G4rSVB2yqAwsJpWFxgMwlmcutOGmhd6AgcMl8Zkphk0jJMejHyPbSZpCpx8pDZ3IT2kA9Zoh0cgxe27JaPTx7TU8imzq4E7peCaDpLG3TcvdjZjBdqQJanndDkc/SBP03iZiWMqimwp9fsIJX/iqUyjqxvAQHQvDv3dFMIUS/Xa5625pZjgiCFjoJtK1t+WGpJoMc9Zc3GQq6DUxd9sIJeFtV6WyIVg6ieuZRdDgFtzqmyXF879sLwo96c0/rRuGJJYxk3HAVqRpnw3RQPa2s4GYiQ==; 5:t+rfFiFKBPmDGfA9WeAqQIQ+jSjIqtPzovGRhnjA+RRwXnt+kCaGOlgnXlN6w2FHA6uJEahxVT6OQ+ISuEYAy42ku7Q0TMhPsuaH9+0E6rI3KEfHy8StsJRnEwq+dh9wUUG1OJrcTqrlNRyg9EgZO6I1sMpXPbwRLh6vM8qeeB8=; 24:n60rlkzdbmQyAgAglig5rZs3FHMV5SxpcoI4vVuPMDugbDs0rgGoChBCVdzbF1NBmFKDEM+0xJUbReNpo8lz/a7HnXRKyYSL/CLkSfdv0SM=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2938; 7:YjZ6W7ib/9n3spjIbrvVhIFomzP3ItygXZKFam4aAgYDACgCWC1WPUAjWt+9zvY8uLz9gjmoHKNUOo6go4ER6yILM5jgwPvoLQK681NFExriNZtRgGfyEUvWFQfFuvU/zUuKy6fShW8LOnbEV+07hEB+tbN6wJYG5RpQLEcb3b8Mbeon7KVAumuNFU5OpQjqYfYnIcWht5zTRizUTsHOt8o8C9QiZtNj2oIchkk63u25M72CnVGFDsBy86GfztbdhzxnCueoRIWG3NtCtKxEZDV8hLPyRUshypq88oMFaMsta2yZppt/yj00J/HC7b9Wh1JssrWnAJVejaLGckK4r78FzP7dvUQZzkn5q+l/JjQflB7d5zuHzb38pLaBuqXYKHbmdgzwbVfwhWt+D7Id9m0wCXTsa8Z/S1acIc/DRvBdU5ooeD57jgVtbEeNtbPJIyFYfVHhGzFwrd+8GwlYaw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2017 21:27:08.1273 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2938
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?
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, 19 Jan 2017 21:27:12 -0000

Robert Wilton writes:
>Wouldn't you just write this without the back reference to the 
>deprecated/obsolete leaf.
>E.g. wouldn't the following be sufficient to enforce the desired constraint?
>     leaf old-stuff {
>         status deprecated;
>         must not(../new-stuff);
>     }
>     leaf new-stuff {
>     }

Very True.  But imagine if the deprecated bits are in one module
and the new-stuff is in another.  The old-stuff cannot refer to the
new-stuff.

Thanks,
 Phil


From nobody Thu Jan 19 15:52:36 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 AF6581296BF for ; Thu, 19 Jan 2017 15:52:34 -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 I_THt0BLG9cS for ; Thu, 19 Jan 2017 15:52:32 -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 C2ADB1294E9 for ; Thu, 19 Jan 2017 15:52:32 -0800 (PST)
Received: from [10.137.2.13] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 92C5A2401A2; Fri, 20 Jan 2017 00:52:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1484869949; bh=D0Zl83zU6ZnJZ06OH+l0z4qy1i0RsaoevcgkmpFndok=; h=Subject:To:References:From:Date:In-Reply-To; b=lhDJchDvDTitM5f8GF69N+jOkI1ac1b5IfhRRFaSzFGud2tdvePe9BrhtWz8CO2th 73bzi7z7wPToXLDRoD54Sw+vO/NxfVHCnwOM6pXR89uY1qrDMZjLgygqlJCaDXfaHw mrPLUlDAOzDq3E6jd6xFREaOexhQn35xo+lumawo=
To: Martin Bjorklund , netmod@ietf.org
References: <20170117.132913.781493366440105564.mbj@tail-f.com>
From: Robert Varga 
Message-ID: <0aef5ef5-1ff2-f23e-d2aa-6a6dbab356fe@hq.sk>
Date: Fri, 20 Jan 2017 00:52:15 +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: <20170117.132913.781493366440105564.mbj@tail-f.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x53CtiD7IlhPhFBXtxOohHDpabusF9cxq"
Archived-At: 
Subject: Re: [netmod] mount-point in anydata
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, 19 Jan 2017 23:52:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--x53CtiD7IlhPhFBXtxOohHDpabusF9cxq
Content-Type: multipart/mixed; boundary="kd6bof6x8cuCw0f0NoafT3bdKfOGgAQ7i";
 protected-headers="v1"
From: Robert Varga 
To: Martin Bjorklund , netmod@ietf.org
Message-ID: <0aef5ef5-1ff2-f23e-d2aa-6a6dbab356fe@hq.sk>
Subject: Re: [netmod] mount-point in anydata
References: <20170117.132913.781493366440105564.mbj@tail-f.com>
In-Reply-To: <20170117.132913.781493366440105564.mbj@tail-f.com>

--kd6bof6x8cuCw0f0NoafT3bdKfOGgAQ7i
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 01/17/2017 01:29 PM, Martin Bjorklund wrote:
> For this reason, I propose that we go back to the previous model where
> "mount-point" would be allowed in "container" and "list".  Note that a
> client that doesn't know anything about these mounts would see some
> nodes in some unknown namespace; just like in the case that there is
> an augment that the client doesn't know about.

+1, although I think the situation is not quite equal to an unknown
augmentation: the mount point itself would be in an unknown namespace,
but the nodes beneath it could actually match a namespace known to the
client, right?

Thanks,
Robert


--kd6bof6x8cuCw0f0NoafT3bdKfOGgAQ7i--

--x53CtiD7IlhPhFBXtxOohHDpabusF9cxq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIoBAEBCgASBQJYgVEwCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDTfDwQAKg3Fe5y
SyX/VvvPVxMEe7pZMoLZk1JYhidLgOigRlAAR2pc9b4rIAQWxok6dVgK6Q/hTVTH
AP9NUeePd2vNQdjBw7HKsg+YnDXCKSEqj/TDRzeJb/h9Enx2IcobtG4odlnBbMsP
6JTTx0neH7tRL91hK7Pi3qBVNR2ZfPioxLAxPHXE6u6mQ0Pmgo1dkfeNkE+HjW8u
WXfHKk3ZOYno1igL82MM21k7qXoNh2Zq20xaA+7bHp/7iH2VmR2bElMKmnwpcJqD
S7+KwLo39G6Oqt7VzIIwfYtfB0u/K3YuRf8bm8OBzPV/9uPfJ+nknOdoRWlTqt5u
vQvU0bK6sMfq5zKv4CpLInru3Nm4nhY3D9grnT/8KjdM4vzFRRCFUnKoYbPPiZyO
h6g4TBwzrn+hzmgLoia+zEgdG/tRNj566rg+1l+OFY/mOz6mdaywXf637foCiQSv
nbv5b622CeJZIUCv1NxjwYOw77pAjzqczYGf7gFQR1zxu9tsOQu/a4UWBZFoxipf
/c7hBuN0sG4iZZKBZ2LBEos35ep9lB4t3tcg8ZswFTh5lZPdIlOoHxGupT4YsYvg
TeNiK9QVjsgo1qnxhpkDQBZhdJYRrFVFgFchwqNvCuoOEcil64j37SKUSjVVRRta
ADqhibJE5z8rIexCn4htBEmJ3xrhmIUwOsFl
=WcHU
-----END PGP SIGNATURE-----

--x53CtiD7IlhPhFBXtxOohHDpabusF9cxq--


From nobody Thu Jan 19 23:35: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 B1406129A57 for ; Thu, 19 Jan 2017 23:35:54 -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 J1Mi9Jz-sZNM for ; Thu, 19 Jan 2017 23:35:53 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF07129A5B for ; Thu, 19 Jan 2017 23:35:53 -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 B64251AE02EF; Fri, 20 Jan 2017 08:35:51 +0100 (CET)
Date: Fri, 20 Jan 2017 08:35:51 +0100 (CET)
Message-Id: <20170120.083551.970804629897913074.mbj@tail-f.com>
To: nite@hq.sk
From: Martin Bjorklund 
In-Reply-To: <0aef5ef5-1ff2-f23e-d2aa-6a6dbab356fe@hq.sk>
References: <20170117.132913.781493366440105564.mbj@tail-f.com> <20170117.132913.781493366440105564.mbj@tail-f.com> <0aef5ef5-1ff2-f23e-d2aa-6a6dbab356fe@hq.sk>
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: netmod@ietf.org
Subject: Re: [netmod] mount-point in anydata,Re:  mount-point in anydata
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, 20 Jan 2017 07:35:55 -0000

Robert Varga  wrote:
> On 01/17/2017 01:29 PM, Martin Bjorklund wrote:
> > For this reason, I propose that we go back to the previous model where
> > "mount-point" would be allowed in "container" and "list".  Note that a
> > client that doesn't know anything about these mounts would see some
> > nodes in some unknown namespace; just like in the case that there is
> > an augment that the client doesn't know about.
> 
> +1, although I think the situation is not quite equal to an unknown
> augmentation: the mount point itself would be in an unknown namespace,
> but the nodes beneath it could actually match a namespace known to the
> client, right?

Yes, the namespace might be known to the client, but in a different
place.


/martin


From nobody Mon Jan 23 01:04:28 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 268141294BA; Mon, 23 Jan 2017 01:04:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.com>
Date: Mon, 23 Jan 2017 01:04:27 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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: Mon, 23 Jan 2017 09:04:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

        Title           : A YANG Data Model for Hardware Management
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Jie Dong
                          Dan Romascanu
	Filename        : draft-ietf-netmod-entity-02.txt
	Pages           : 40
	Date            : 2017-01-23

Abstract:
   This document defines a YANG data model for the management of
   hardware on a single server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jan 23 01:08: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 42C5612956B for ; Mon, 23 Jan 2017 01:08:31 -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 uGAL_17ZzNAN for ; Mon, 23 Jan 2017 01:08:29 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2312949E for ; Mon, 23 Jan 2017 01:08:29 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D54A1AE0285 for ; Mon, 23 Jan 2017 10:08:28 +0100 (CET)
Date: Mon, 23 Jan 2017 10:08:26 +0100 (CET)
Message-Id: <20170123.100826.682455648369749133.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.com>
References: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.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: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 23 Jan 2017 09:08:31 -0000

Hi,

The main changes in this version of the hardware model is that
pre-provisioning is supported according to the ML discussion.  Also,
the leaf-list "contained-in" is changed to a leaf "parent", in order
to match "parent-rel-pos".

With this version, the authors believe that all known issues are
resolved, and that the document is ready for WGLC.


/martin



internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
> 
>         Title           : A YANG Data Model for Hardware Management
>         Authors         : Andy Bierman
>                           Martin Bjorklund
>                           Jie Dong
>                           Dan Romascanu
> 	Filename        : draft-ietf-netmod-entity-02.txt
> 	Pages           : 40
> 	Date            : 2017-01-23
> 
> Abstract:
>    This document defines a YANG data model for the management of
>    hardware on a single server.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-entity-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Jan 23 01:32: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 A8E2012949E; Mon, 23 Jan 2017 01:32:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level: 
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JO-tjOmEKBgh; Mon, 23 Jan 2017 01:32:17 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D327812956B; Mon, 23 Jan 2017 01:32:16 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZH85728; Mon, 23 Jan 2017 09:32:14 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 23 Jan 2017 09:32:11 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 23 Jan 2017 17:32:05 +0800
From: Tianran Zhou 
To: "adrian@olddog.co.uk" , "netmod@ietf.org" 
Thread-Topic: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
Thread-Index: AdJycEnw/7BBgfqES8aIslF6yofdUQC6EoZg
Date: Mon, 23 Jan 2017 09:32:36 +0000
Message-ID: 
References: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk>
In-Reply-To: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5885CD9E.0388, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: cf6e4f1d70fdc389f971a1a5cb84c709
Archived-At: 
Cc: "opsawg@ietf.org" , "draft-ietf-netmod-yang-model-classification@ietf.org" 
Subject: Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
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, 23 Jan 2017 09:32:20 -0000

To add more comments:=20

On the L2SM meeting, several people (4 or more) believed the 3 service deli=
very model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], [I-D.ietf-bess-l2vpn=
-yang] and [I-D.ietf-bess-evpn-yang]) are actually device models.

I think both of the two I-Ds ([draft-ietf-netmod-yang-model-classification]=
 and [draft-wu-opsawg-service-model-explained]) can check if those YANG mod=
els are device models or service models.

Regards,
Tianran

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Friday, January 20, 2017 12:25 AM
> To: netmod@ietf.org
> Cc: opsawg@ietf.org;
> draft-ietf-netmod-yang-model-classification@ietf.org
> Subject: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
>=20
> Hi,
>=20
> We've been trying to ensure that draft-wu-opsawg-service-model-explained
> is consistent with the latest version of
> draft-ietf-netmod-yang-model-classification. In discussions with Tianran
> a question has come up.
>=20
> In section 2 you have a nice definition of Network Service YANG Modules
> and this definition maps nicely to our definition of "service delivery
> models".
> Furthermore, your figure 1 shows Network Service YANG Modules on the
> interface between OSS/BSS and the various network services.
>=20
> We have further defined "customer service models" at a higher layer still=
.
> That is, on the interface to the customer. This (of course?) assumes that
> the OSS/BSS is not customer code :-)
>=20
> However, your discussion of Network Service YANG Modules in section 2.1
> seems slightly at odds, although this may be just ambiguity.
>=20
> For example, when you say, "Network Service YANG Modules describe the
> characteristics of a service, as agreed upon with consumers of that servi=
ce,"
> this is not the same as, "This model is used in the discussion between a
> customer and a service provide to describe the characteristics of a servi=
ce."
> That is, the former case could be arrived at after processing based on th=
e
> latter case - processing that we have called "service orchestration" but
> might (of course) be what leads to the operator poking the OSS/BSS.
>=20
> This might all be fine and good, but later in the same section you say "N=
etwork
> Service YANG Modules define service models to be consumed by external
> systems.
> These modules are commonly designed, developed and deployed by network
> infrastructure teams." And there you introduce two terms that are previou=
sly
> undefined and only server to add ambiguity. Specifically "external to wha=
t?"
> I could make and argument that the OSS is developed and deployed by netwo=
rk
> infrastructure teams, ad also that the OSS is external to the network its=
elf.
>=20
> And, in between these two quoted pieces of text, you have...
>=20
>    As an example, the Network Service YANG Module defined in
>    [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
>    model for Layer 3 IP VPN service configuration.
>=20
> Per my other email, this reference needs to be fixed. But I struggle to
> see the L3SM module as consistent with your figure. It may or may not be
> consistent with your text dependent on the interpretation.
>=20
> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show
> how we (the authors) think L3SM fits into your classification. Here we pl=
ace
> L3SM further up the layering stack.
>=20
> [Apologies for not spotting this sooner. The citation
> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
> delivery" which I took to imply a different module.]
>=20
> Thanks,
> Adrian
>=20
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


From nobody Mon Jan 23 01:42:37 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 0AB041295DB for ; Mon, 23 Jan 2017 01:42:36 -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 aB8sF4G0JV4E for ; Mon, 23 Jan 2017 01:42:34 -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 790F91295CF for ; Mon, 23 Jan 2017 01:42:34 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4FA6E6E3 for ; Mon, 23 Jan 2017 10:42:33 +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 Rnxxvzd76sDM for ; Mon, 23 Jan 2017 10:42:32 +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 for ; Mon, 23 Jan 2017 10:42:32 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7678200A8 for ; Mon, 23 Jan 2017 10:42:32 +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 N0svb5ps3R_z; Mon, 23 Jan 2017 10:42:32 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED00E200A7; Mon, 23 Jan 2017 10:42:31 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E5EDF3E464D0; Mon, 23 Jan 2017 10:42:34 +0100 (CET)
Date: Mon, 23 Jan 2017 10:42:34 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20170123094232.GC29022@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 23 Jan 2017 09:42:36 -0000

Hi,

I wonder when we use 'state' and when 'status' - is there a subtle
distinction or should be just consistently use lets say 'state', i.e.,
changed to alalarm-status to alarm-state and standby-status to
standby-state?

I also wonder about the mapping of the MIB object names to YANG leaf
names:

   +-------------------------------------+-----------------------------+
   | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
   | state/component/sensor-data         |                             |
   +-------------------------------------+-----------------------------+
   | data-type                           | entPhySensorType            |
   | data-scale                          | entPhySensorScale           |
   | precision                           | entPhySensorPrecision       |
   | value                               | entPhySensorValue           |
   | oper-status                         | entPhySensorOperStatus      |
   | sensor-units-display                | entPhySensorUnitsDisplay    |
   | value-timestamp                     | entPhySensorValueTimeStamp  |
   | value-update-rate                   | entPhySensorValueUpdateRate |
   +-------------------------------------+-----------------------------+

Is the 'data-' prefix needed? If so, why is the a prefix not used for
'precision' (scale and precision really go hand in hand). Why is it
'sensor-units-display' and not just 'units-display'? One option could
be:

  value-type
  value-scale
  value-precision
  value
  oper-status
  units-display
  value-timestamp
  value-update-rate

RFC 3433 points out that entPhySensorType and entPhySensorScale and
entPhySensorPrecision SHOULD NOT change during operation. What about
the YANG objects? I actually do not know what the SHOULD buys a client
since you can't rely on it. To be robust, you have to fetch an n-tuple
anyway and be prepared that a sensor may have changed its properties.
Should there be explicit text providing guidance that it is better to
fetch the whole n-tuple? Or alternatively, if supporting caching of
values is a goal, we may need to provide a
'sensor-data/properties-last-changed' object that allows to make
caching of value properties robust.

/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 23 02:29: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 CCDE71294F8 for ; Mon, 23 Jan 2017 02:29: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 DFKnN_4TZWj9 for ; Mon, 23 Jan 2017 02:29:31 -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 84CAE129B11 for ; Mon, 23 Jan 2017 02:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9370; q=dns/txt; s=iport; t=1485167370; x=1486376970; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=yMofqgJSQrBijV51UxO4R6G6Qv6obV2JwtKXxprLarc=; b=BI/ulY0M/nvm92wahpIlfvW4wKRhkvkUne1HeCqrZ98TzcmO7y3Tsa3o HUAzDc7pg2pWImaedYIp8aEIYJ9P+uEaxq795lgT5c7C7P6LzcXHg/c/K Nubiwtk/5qDp/hc/6gQMVlrVnRecnGaKeBdgoYl00JyPXiAa4imRXaM5q o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQC62oVY/xbLJq1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9AQEBAQF/AydfjVtykROQA4Urgg0shXYCgl0YAQIBAQEBAQE?= =?us-ascii?q?BYyiEagZyBxALRlcHDAYCAQEXiHEOLa4LK4oUAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHYZLggWBYoEJgTyBUIchBYkAEYdhilmGYoJUiDSBd4UPgyqGPogfglmHfh8?= =?us-ascii?q?4EYEGEwgVFRiEWw0PgWI9NQETh28BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,274,1477958400";  d="scan'208,217";a="651894898"
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; 23 Jan 2017 10:29:28 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0NATRdC011702; Mon, 23 Jan 2017 10:29:27 GMT
To: mbj@tail-f.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net
References: <20170118114858.62A63B80FFD@rfc-editor.org>
From: Benoit Claise 
Message-ID: 
Date: Mon, 23 Jan 2017 11:29: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: <20170118114858.62A63B80FFD@rfc-editor.org>
Content-Type: multipart/alternative; boundary="------------5C13EB695ECCC66D04FCF411"
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 10:29:33 -0000

This is a multi-part message in MIME format.
--------------5C13EB695ECCC66D04FCF411
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Let me summarize the situation.
     - The RFC 6020 spec is clearly ambiguous.
     - The solution is to use YANG 1.1
     - RFC 7950 doesn't update or obsolete RFC 6020 (*)
     - We should stop this problem from spreading further: updating 
tooling is one good aspect, we should update the spec. too to at least 
warn the users.

There is no perfect solution.
Because of (*), I believe I should accept this errata.
Any strong objections? If you have, propose a better plan. And I don't 
believe that "do nothing" is sufficient.

Regarding the "update" solution, see the RFC 7950 writeup at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/

    (16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header, listed
    in the abstract, and discussed in the introduction? If the RFCs are not
    listed in the Abstract and Introduction, explain why, and point to the
    part of the document where the relationship of this document to the
    other RFCs is discussed. If this information is not in the document,
    explain why the WG considers it unnecessary.

       No. YANG 1.0 [RFC6020] is not expected to change its status since
       there are data models on the standards-track that conform to YANG
       1.0. YANG 1.0 may be considered for retirement once all data models
       have naturally been updated to a future version of YANG.

Regards, Benoit
> The following errata report has been submitted for RFC6020,
> "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>
> --------------------------------------
> Type: Technical
> Reported by: Ladislav Lhotka 
>
> Section: 6.1.3
>
> Original Text
> -------------
> Within a double-quoted string (enclosed within " "), a backslash
> character introduces a special character, which depends on the
> character that immediately follows the backslash:
>
>   \n      new line
>   \t      a tab character
>   \"      a double quote
>   \      a single backslash
>
>
> Corrected Text
> --------------
> Within a double-quoted string (enclosed within " "), a backslash
> character introduces a special character, which depends on the
> character that immediately follows the backslash:
>
>   \n      new line
>   \t      a tab character
>   \"      a double quote
>   \      a single backslash
>
> The backslash MUST NOT be followed by any other character.
>
> Notes
> -----
> The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
>
> 1. report an error if another character follows the backslash
> 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
> 3. keep both the backslash and the character following it.
>
> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6020 (draft-ietf-netmod-yang-13)
> --------------------------------------
> Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
> Publication Date    : October 2010
> Author(s)           : M. Bjorklund, Ed.
> Category            : PROPOSED STANDARD
> Source              : NETCONF Data Modeling Language
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> .
>


--------------5C13EB695ECCC66D04FCF411
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear all,

      

      Let me summarize the situation.

       - The RFC 6020 spec is clearly ambiguous.

       - The solution is to use YANG 1.1

       - RFC 7950 doesn't update or obsolete RFC 6020 (*)

       - We should stop this problem from spreading further: updating
      tooling is one good aspect, we should update the spec. too to at
      least warn the users.

      

      There is no perfect solution. 

      Because of (*), I believe I should accept this errata.

      Any strong objections? If you have, propose a better plan. And I
      don't believe that "do nothing" is sufficient.

      

      Regarding the "update" solution, see the RFC 7950 writeup at
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/

      

        
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No. YANG 1.0 [RFC6020] is not expected to change its status since
  there are data models on the standards-track that conform to YANG
  1.0. YANG 1.0 may be considered for retirement once all data models
  have naturally been updated to a future version of YANG.

      

    

    Regards, Benoit

    

      
The following errata report has been submitted for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911

--------------------------------------
Type: Technical
Reported by: Ladislav Lhotka <lhotka@nic.cz>

Section: 6.1.3

Original Text
-------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n      new line
 \t      a tab character
 \"      a double quote
 \      a single backslash


Corrected Text
--------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n      new line
 \t      a tab character
 \"      a double quote
 \      a single backslash

The backslash MUST NOT be followed by any other character.

Notes
-----
The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:

1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
3. keep both the backslash and the character following it.

This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6020 (draft-ietf-netmod-yang-13)
--------------------------------------
Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
Publication Date    : October 2010
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.



    

    

  


--------------5C13EB695ECCC66D04FCF411--


From nobody Mon Jan 23 02:47: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 EC430129B09 for ; Mon, 23 Jan 2017 02:46:59 -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 Ope4JhGoTQnq for ; Mon, 23 Jan 2017 02:46:58 -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 EBF941294F8 for ; Mon, 23 Jan 2017 02:46:57 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C20EB6A9; Mon, 23 Jan 2017 11:46:56 +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 QpiRzqP2tnTR; Mon, 23 Jan 2017 11:46:55 +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, 23 Jan 2017 11:46:56 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0570E200A8; Mon, 23 Jan 2017 11:46:56 +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 YvajvJSziGzy; Mon, 23 Jan 2017 11:46:55 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C09A8200A7; Mon, 23 Jan 2017 11:46:54 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7194A3E467E5; Mon, 23 Jan 2017 11:46:56 +0100 (CET)
Date: Mon, 23 Jan 2017 11:46:55 +0100
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20170123104655.GA29877@elstar.local>
Mail-Followup-To: Benoit Claise , mbj@tail-f.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net, netmod@ietf.org
References: <20170118114858.62A63B80FFD@rfc-editor.org> 
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: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 10:47:00 -0000

Benoit,

RFC 6020 is ambiguous and this is just how it is. The solution for
YANG 1 is simply to give advice to module writers to avoid ambiguous
character sequences (and avoiding ambiguity can be easily done).

YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
YANG 1 is a change of YANG 1, i.e., it might turn a conforming
implementation into a non-conforming implementation. Hence, this may
go beyond the scope of an errata.

If tools generate proper warnings, I think we are fine and we do not
need to change YANG 1. These kind of issues are caught by tools, not
by humans reading language specifications.

If you feel strongly that an errata is needed, then the errata should
simply clearly spell out that certain backslahs sequences are
ambiguous and provide advice that they should not be used. This is
backwards compatible. Making them illegal is not backwards compatible.

/js

PS: This is also my recollection of the discussion of issue Y06 when
    YANG 1.1 was put together.

On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
> Dear all,
> 
> Let me summarize the situation.
>     - The RFC 6020 spec is clearly ambiguous.
>     - The solution is to use YANG 1.1
>     - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>     - We should stop this problem from spreading further: updating tooling
> is one good aspect, we should update the spec. too to at least warn the
> users.
> 
> There is no perfect solution.
> Because of (*), I believe I should accept this errata.
> Any strong objections? If you have, propose a better plan. And I don't
> believe that "do nothing" is sufficient.
> 
> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
> 
>    (16) Will publication of this document change the status of any
>    existing RFCs? Are those RFCs listed on the title page header, listed
>    in the abstract, and discussed in the introduction? If the RFCs are not
>    listed in the Abstract and Introduction, explain why, and point to the
>    part of the document where the relationship of this document to the
>    other RFCs is discussed. If this information is not in the document,
>    explain why the WG considers it unnecessary.
> 
>       No. YANG 1.0 [RFC6020] is not expected to change its status since
>       there are data models on the standards-track that conform to YANG
>       1.0. YANG 1.0 may be considered for retirement once all data models
>       have naturally been updated to a future version of YANG.
> 
> Regards, Benoit
> > The following errata report has been submitted for RFC6020,
> > "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
> > 
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
> > 
> > --------------------------------------
> > Type: Technical
> > Reported by: Ladislav Lhotka 
> > 
> > Section: 6.1.3
> > 
> > Original Text
> > -------------
> > Within a double-quoted string (enclosed within " "), a backslash
> > character introduces a special character, which depends on the
> > character that immediately follows the backslash:
> > 
> >   \n      new line
> >   \t      a tab character
> >   \"      a double quote
> >   \      a single backslash
> > 
> > 
> > Corrected Text
> > --------------
> > Within a double-quoted string (enclosed within " "), a backslash
> > character introduces a special character, which depends on the
> > character that immediately follows the backslash:
> > 
> >   \n      new line
> >   \t      a tab character
> >   \"      a double quote
> >   \      a single backslash
> > 
> > The backslash MUST NOT be followed by any other character.
> > 
> > Notes
> > -----
> > The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
> > 
> > 1. report an error if another character follows the backslash
> > 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
> > 3. keep both the backslash and the character following it.
> > 
> > This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
> > 
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> > 
> > --------------------------------------
> > RFC6020 (draft-ietf-netmod-yang-13)
> > --------------------------------------
> > Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
> > Publication Date    : October 2010
> > Author(s)           : M. Bjorklund, Ed.
> > Category            : PROPOSED STANDARD
> > Source              : NETCONF Data Modeling Language
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> > .
> > 
> 

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


-- 
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 23 02:58:47 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 A0D361295DD for ; Mon, 23 Jan 2017 02:58:45 -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 2stigm65bPnn for ; Mon, 23 Jan 2017 02:58:44 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 851121295DC for ; Mon, 23 Jan 2017 02:58:44 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 71FAD1AE0285; Mon, 23 Jan 2017 11:58:43 +0100 (CET)
Date: Mon, 23 Jan 2017 11:58:41 +0100 (CET)
Message-Id: <20170123.115841.723508035325803360.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20170123094232.GC29022@elstar.local>
References: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.com> <20170123094232.GC29022@elstar.local>
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: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 23 Jan 2017 10:58:45 -0000

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I wonder when we use 'state' and when 'status' - is there a subtle
> distinction or should be just consistently use lets say 'state', i.e.,
> changed to alalarm-status to alarm-state and standby-status to
> standby-state?

The reason in this case is that we just used the MIB names.  This
said, I agree that "standby-state" and "alarm-state" are better.

BTW, RFC 4268, which defines the original objects, says:

   The terms "state" and "status" are used interchangeably in this memo.


> I also wonder about the mapping of the MIB object names to YANG leaf
> names:
> 
>    +-------------------------------------+-----------------------------+
>    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
>    | state/component/sensor-data         |                             |
>    +-------------------------------------+-----------------------------+
>    | data-type                           | entPhySensorType            |
>    | data-scale                          | entPhySensorScale           |
>    | precision                           | entPhySensorPrecision       |
>    | value                               | entPhySensorValue           |
>    | oper-status                         | entPhySensorOperStatus      |
>    | sensor-units-display                | entPhySensorUnitsDisplay    |
>    | value-timestamp                     | entPhySensorValueTimeStamp  |
>    | value-update-rate                   | entPhySensorValueUpdateRate |
>    +-------------------------------------+-----------------------------+
> 
> Is the 'data-' prefix needed? If so, why is the a prefix not used for
> 'precision' (scale and precision really go hand in hand).

Unclear.  I think I'm the one to blame for this inconsistency, and it
goes back to the very first commit, but I can't remeber why.

> Why is it
> 'sensor-units-display' and not just 'units-display'? One option could
> be:
> 
>   value-type
>   value-scale
>   value-precision
>   value
>   oper-status
>   units-display
>   value-timestamp
>   value-update-rate

Yes this is better.

> RFC 3433 points out that entPhySensorType and entPhySensorScale and
> entPhySensorPrecision SHOULD NOT change during operation. What about
> the YANG objects? I actually do not know what the SHOULD buys a client
> since you can't rely on it. To be robust, you have to fetch an n-tuple
> anyway and be prepared that a sensor may have changed its properties.
> Should there be explicit text providing guidance that it is better to
> fetch the whole n-tuple?

This is certainly the simplest solution.   Any comments?

> Or alternatively, if supporting caching of
> values is a goal, we may need to provide a
> 'sensor-data/properties-last-changed' object that allows to make
> caching of value properties robust.


/martin


From nobody Mon Jan 23 03:06: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 116C712956B for ; Mon, 23 Jan 2017 03:06:04 -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 vB1OdmA6qZ4s for ; Mon, 23 Jan 2017 03:06:02 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA81294F8 for ; Mon, 23 Jan 2017 03:06:02 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 733881AE0285; Mon, 23 Jan 2017 12:06:01 +0100 (CET)
Date: Mon, 23 Jan 2017 12:05:59 +0100 (CET)
Message-Id: <20170123.120559.2013170813371878100.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20170123104655.GA29877@elstar.local>
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local>
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: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 11:06:04 -0000

Hi,

I agree with what Juergen writes below.

Also, if we *really* wanted to change RFC 6020 in this regard (which I
don't think we should!), I think the change should be the equivalent
of Y06-01:

  Clarify that "\x" means the two characters '\' and 'x', i.e.,
  "\x" is equivalent to '\x'.

  This is how several known implementations have interpreted the text.

I think that this was the original intention of the text.  (Yes, I
know that there are issues with this design, but that's not the point
here).


/martin


Juergen Schoenwaelder  wrote:
> Benoit,
> 
> RFC 6020 is ambiguous and this is just how it is. The solution for
> YANG 1 is simply to give advice to module writers to avoid ambiguous
> character sequences (and avoiding ambiguity can be easily done).
> 
> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> implementation into a non-conforming implementation. Hence, this may
> go beyond the scope of an errata.
> 
> If tools generate proper warnings, I think we are fine and we do not
> need to change YANG 1. These kind of issues are caught by tools, not
> by humans reading language specifications.
> 
> If you feel strongly that an errata is needed, then the errata should
> simply clearly spell out that certain backslahs sequences are
> ambiguous and provide advice that they should not be used. This is
> backwards compatible. Making them illegal is not backwards compatible.
> 
> /js
> 
> PS: This is also my recollection of the discussion of issue Y06 when
>     YANG 1.1 was put together.
> 
> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
> > Dear all,
> > 
> > Let me summarize the situation.
> >     - The RFC 6020 spec is clearly ambiguous.
> >     - The solution is to use YANG 1.1
> >     - RFC 7950 doesn't update or obsolete RFC 6020 (*)
> >     - We should stop this problem from spreading further: updating tooling
> > is one good aspect, we should update the spec. too to at least warn the
> > users.
> > 
> > There is no perfect solution.
> > Because of (*), I believe I should accept this errata.
> > Any strong objections? If you have, propose a better plan. And I don't
> > believe that "do nothing" is sufficient.
> > 
> > Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
> > 
> >    (16) Will publication of this document change the status of any
> >    existing RFCs? Are those RFCs listed on the title page header, listed
> >    in the abstract, and discussed in the introduction? If the RFCs are not
> >    listed in the Abstract and Introduction, explain why, and point to the
> >    part of the document where the relationship of this document to the
> >    other RFCs is discussed. If this information is not in the document,
> >    explain why the WG considers it unnecessary.
> > 
> >       No. YANG 1.0 [RFC6020] is not expected to change its status since
> >       there are data models on the standards-track that conform to YANG
> >       1.0. YANG 1.0 may be considered for retirement once all data models
> >       have naturally been updated to a future version of YANG.
> > 
> > Regards, Benoit
> > > The following errata report has been submitted for RFC6020,
> > > "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
> > > 
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
> > > 
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Ladislav Lhotka 
> > > 
> > > Section: 6.1.3
> > > 
> > > Original Text
> > > -------------
> > > Within a double-quoted string (enclosed within " "), a backslash
> > > character introduces a special character, which depends on the
> > > character that immediately follows the backslash:
> > > 
> > >   \n      new line
> > >   \t      a tab character
> > >   \"      a double quote
> > >   \      a single backslash
> > > 
> > > 
> > > Corrected Text
> > > --------------
> > > Within a double-quoted string (enclosed within " "), a backslash
> > > character introduces a special character, which depends on the
> > > character that immediately follows the backslash:
> > > 
> > >   \n      new line
> > >   \t      a tab character
> > >   \"      a double quote
> > >   \      a single backslash
> > > 
> > > The backslash MUST NOT be followed by any other character.
> > > 
> > > Notes
> > > -----
> > > The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
> > > 
> > > 1. report an error if another character follows the backslash
> > > 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
> > > 3. keep both the backslash and the character following it.
> > > 
> > > This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
> > > 
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". If necessary, please
> > > use "Reply All" to discuss whether it should be verified or
> > > rejected. When a decision is reached, the verifying party
> > > can log in to change the status and edit the report, if necessary.
> > > 
> > > --------------------------------------
> > > RFC6020 (draft-ietf-netmod-yang-13)
> > > --------------------------------------
> > > Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
> > > Publication Date    : October 2010
> > > Author(s)           : M. Bjorklund, Ed.
> > > Category            : PROPOSED STANDARD
> > > Source              : NETCONF Data Modeling Language
> > > Area                : Operations and Management
> > > Stream              : IETF
> > > Verifying Party     : IESG
> > > .
> > > 
> > 
> 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> 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 23 03:08: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 81D911295DD for ; Mon, 23 Jan 2017 03:08: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 sC-8KN-DLFEV for ; Mon, 23 Jan 2017 03:08:51 -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 416191294F8 for ; Mon, 23 Jan 2017 03:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5791; q=dns/txt; s=iport; t=1485169731; x=1486379331; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=BMseR5hoce7k18UBVAf3bS8xcRtJUazqpP4tnpfOY7M=; b=Hoex9YJyHVAzISbpcfe43FdvkkDbx9sLt/NCWuybB+YknZoJxiY0crmy +oRgt+u7lstXGiJHD9sAEBylixGMiHd8xtPemNz2TDeqss//zHT0bvNho 9QX5piY+SXnkqdTCBYzIjrZ2FMUMypEtaweHghdN7WgCNDD8nSeThWnAI 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuAQBv44VY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9AQEBAQF/AydfjVtykHQflS6CDR8NhSxKAoIzGAECAQEBAQE?= =?us-ascii?q?BAWMohGoBAQQBATY2BBcLGC4nMAcMBgIBAReIcQ4trgeKPgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBASCGS4IFCIFagQmBPIFQhyEFiQARh2GKWYZiglSINIF3hQ+DKoY+iB+?= =?us-ascii?q?CWYd+HzgRgQYTCBUVGCKEOQ0PgWI9NQETh28BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,274,1477958400"; d="scan'208";a="650075898"
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; 23 Jan 2017 11:08:48 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0NB8jgw022293; Mon, 23 Jan 2017 11:08:46 GMT
To: mbj@tail-f.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net, netmod@ietf.org
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local>
From: Benoit Claise 
Message-ID: 
Date: Mon, 23 Jan 2017 12:08:45 +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: <20170123104655.GA29877@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 11:08:53 -0000

On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
> Benoit,
>
> RFC 6020 is ambiguous and this is just how it is. The solution for
> YANG 1 is simply to give advice to module writers to avoid ambiguous
> character sequences (and avoiding ambiguity can be easily done).
>
> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> implementation into a non-conforming implementation. Hence, this may
> go beyond the scope of an errata.
>
> If tools generate proper warnings, I think we are fine and we do not
> need to change YANG 1. These kind of issues are caught by tools, not
> by humans reading language specifications.
>
> If you feel strongly that an errata is needed, then the errata should
> simply clearly spell out that certain backslahs sequences are
> ambiguous and provide advice that they should not be used.
That would work.
Can we modify the errata this way.

Regards, Benoit
> This is
> backwards compatible. Making them illegal is not backwards compatible.
>
> /js
>
> PS: This is also my recollection of the discussion of issue Y06 when
>      YANG 1.1 was put together.
>
> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
>> Dear all,
>>
>> Let me summarize the situation.
>>      - The RFC 6020 spec is clearly ambiguous.
>>      - The solution is to use YANG 1.1
>>      - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>>      - We should stop this problem from spreading further: updating tooling
>> is one good aspect, we should update the spec. too to at least warn the
>> users.
>>
>> There is no perfect solution.
>> Because of (*), I believe I should accept this errata.
>> Any strong objections? If you have, propose a better plan. And I don't
>> believe that "do nothing" is sufficient.
>>
>> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>>
>>     (16) Will publication of this document change the status of any
>>     existing RFCs? Are those RFCs listed on the title page header, listed
>>     in the abstract, and discussed in the introduction? If the RFCs are not
>>     listed in the Abstract and Introduction, explain why, and point to the
>>     part of the document where the relationship of this document to the
>>     other RFCs is discussed. If this information is not in the document,
>>     explain why the WG considers it unnecessary.
>>
>>        No. YANG 1.0 [RFC6020] is not expected to change its status since
>>        there are data models on the standards-track that conform to YANG
>>        1.0. YANG 1.0 may be considered for retirement once all data models
>>        have naturally been updated to a future version of YANG.
>>
>> Regards, Benoit
>>> The following errata report has been submitted for RFC6020,
>>> "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>>>
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Ladislav Lhotka 
>>>
>>> Section: 6.1.3
>>>
>>> Original Text
>>> -------------
>>> Within a double-quoted string (enclosed within " "), a backslash
>>> character introduces a special character, which depends on the
>>> character that immediately follows the backslash:
>>>
>>>    \n      new line
>>>    \t      a tab character
>>>    \"      a double quote
>>>    \      a single backslash
>>>
>>>
>>> Corrected Text
>>> --------------
>>> Within a double-quoted string (enclosed within " "), a backslash
>>> character introduces a special character, which depends on the
>>> character that immediately follows the backslash:
>>>
>>>    \n      new line
>>>    \t      a tab character
>>>    \"      a double quote
>>>    \      a single backslash
>>>
>>> The backslash MUST NOT be followed by any other character.
>>>
>>> Notes
>>> -----
>>> The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
>>>
>>> 1. report an error if another character follows the backslash
>>> 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
>>> 3. keep both the backslash and the character following it.
>>>
>>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
>>>
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --------------------------------------
>>> RFC6020 (draft-ietf-netmod-yang-13)
>>> --------------------------------------
>>> Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
>>> Publication Date    : October 2010
>>> Author(s)           : M. Bjorklund, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : NETCONF Data Modeling Language
>>> Area                : Operations and Management
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> .
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Mon Jan 23 04:37:37 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 10797129B2D for ; Mon, 23 Jan 2017 04:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 2k7NI403xdqW for ; Mon, 23 Jan 2017 04:37:34 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C15DC129B2C for ; Mon, 23 Jan 2017 04:37:33 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EF5DD18215AC; Mon, 23 Jan 2017 12:36:35 +0000 (UTC)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Benoit Claise 
In-Reply-To: <20170123104655.GA29877@elstar.local>
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local>
Date: Mon, 23 Jan 2017 13:37:30 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 12:37:36 -0000

Juergen Schoenwaelder  writes:

> Benoit,
>
> RFC 6020 is ambiguous and this is just how it is. The solution for
> YANG 1 is simply to give advice to module writers to avoid ambiguous
> character sequences (and avoiding ambiguity can be easily done).
>
> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> implementation into a non-conforming implementation. Hence, this may
> go beyond the scope of an errata.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

>
> If tools generate proper warnings, I think we are fine and we do not
> need to change YANG 1. These kind of issues are caught by tools, not
> by humans reading language specifications.
>
> If you feel strongly that an errata is needed, then the errata should
> simply clearly spell out that certain backslahs sequences are
> ambiguous and provide advice that they should not be used. This is
> backwards compatible. Making them illegal is not backwards compatible.

This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Lada

>
> /js
>
> PS: This is also my recollection of the discussion of issue Y06 when
>     YANG 1.1 was put together.
>
> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
>> Dear all,
>> 
>> Let me summarize the situation.
>>     - The RFC 6020 spec is clearly ambiguous.
>>     - The solution is to use YANG 1.1
>>     - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>>     - We should stop this problem from spreading further: updating tooling
>> is one good aspect, we should update the spec. too to at least warn the
>> users.
>> 
>> There is no perfect solution.
>> Because of (*), I believe I should accept this errata.
>> Any strong objections? If you have, propose a better plan. And I don't
>> believe that "do nothing" is sufficient.
>> 
>> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>> 
>>    (16) Will publication of this document change the status of any
>>    existing RFCs? Are those RFCs listed on the title page header, listed
>>    in the abstract, and discussed in the introduction? If the RFCs are not
>>    listed in the Abstract and Introduction, explain why, and point to the
>>    part of the document where the relationship of this document to the
>>    other RFCs is discussed. If this information is not in the document,
>>    explain why the WG considers it unnecessary.
>> 
>>       No. YANG 1.0 [RFC6020] is not expected to change its status since
>>       there are data models on the standards-track that conform to YANG
>>       1.0. YANG 1.0 may be considered for retirement once all data models
>>       have naturally been updated to a future version of YANG.
>> 
>> Regards, Benoit
>> > The following errata report has been submitted for RFC6020,
>> > "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
>> > 
>> > --------------------------------------
>> > You may review the report below and at:
>> > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>> > 
>> > --------------------------------------
>> > Type: Technical
>> > Reported by: Ladislav Lhotka 
>> > 
>> > Section: 6.1.3
>> > 
>> > Original Text
>> > -------------
>> > Within a double-quoted string (enclosed within " "), a backslash
>> > character introduces a special character, which depends on the
>> > character that immediately follows the backslash:
>> > 
>> >   \n      new line
>> >   \t      a tab character
>> >   \"      a double quote
>> >   \      a single backslash
>> > 
>> > 
>> > Corrected Text
>> > --------------
>> > Within a double-quoted string (enclosed within " "), a backslash
>> > character introduces a special character, which depends on the
>> > character that immediately follows the backslash:
>> > 
>> >   \n      new line
>> >   \t      a tab character
>> >   \"      a double quote
>> >   \      a single backslash
>> > 
>> > The backslash MUST NOT be followed by any other character.
>> > 
>> > Notes
>> > -----
>> > The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
>> > 
>> > 1. report an error if another character follows the backslash
>> > 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
>> > 3. keep both the backslash and the character following it.
>> > 
>> > This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
>> > 
>> > Instructions:
>> > -------------
>> > This erratum is currently posted as "Reported". If necessary, please
>> > use "Reply All" to discuss whether it should be verified or
>> > rejected. When a decision is reached, the verifying party
>> > can log in to change the status and edit the report, if necessary.
>> > 
>> > --------------------------------------
>> > RFC6020 (draft-ietf-netmod-yang-13)
>> > --------------------------------------
>> > Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
>> > Publication Date    : October 2010
>> > Author(s)           : M. Bjorklund, Ed.
>> > Category            : PROPOSED STANDARD
>> > Source              : NETCONF Data Modeling Language
>> > Area                : Operations and Management
>> > Stream              : IETF
>> > Verifying Party     : IESG
>> > .
>> > 
>> 
>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
> -- 
> 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

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


From nobody Mon Jan 23 05:39:43 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 EF61D1295FD for ; Mon, 23 Jan 2017 05:39:40 -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 L-wANYDdDQ7v for ; Mon, 23 Jan 2017 05:39:39 -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 C786812950B for ; Mon, 23 Jan 2017 05:39:38 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9F5EF71A; Mon, 23 Jan 2017 14:39:37 +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 Uxm2ZZqFzO5S; Mon, 23 Jan 2017 14:39:36 +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, 23 Jan 2017 14:39:37 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44E02200A8; Mon, 23 Jan 2017 14:39:37 +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 joQHWPwKCFHg; Mon, 23 Jan 2017 14:39:36 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 262EC200A7; Mon, 23 Jan 2017 14:39:35 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E48093E46CF7; Mon, 23 Jan 2017 14:39:39 +0100 (CET)
Date: Mon, 23 Jan 2017 14:39:39 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20170123133939.GA30288@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Benoit Claise , joelja@bogus.com, netmod@ietf.org
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@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: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 13:39:41 -0000

On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > Benoit,
> >
> > RFC 6020 is ambiguous and this is just how it is. The solution for
> > YANG 1 is simply to give advice to module writers to avoid ambiguous
> > character sequences (and avoiding ambiguity can be easily done).
> >
> > YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> > YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> > implementation into a non-conforming implementation. Hence, this may
> > go beyond the scope of an errata.
> 
> But it is not really the case here because it cannot be decided what
> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
> don't think it is less conforming than any other.

Exactly. But other interpretations are legal as well. We can not
retroactively turn so far conforming implementations of the RFC into
non-conforming implementations (via an errata that introduces a MUST
that was not there in the beginning).

> This would be fine for the "Notes" part but RFC Errata require also
> "Original Text" and "Corrected Text". Any suggestion for this?
 
Corrected Text
-------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

  \n      new line
  \t      a tab character
  \"      a double quote
  \\      a single backslash

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

/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 23 06:00: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 BBBD3129B82 for ; Mon, 23 Jan 2017 06:00:15 -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 jF_ARYUHTXQT for ; Mon, 23 Jan 2017 06:00:14 -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 26A5E1295F9 for ; Mon, 23 Jan 2017 06:00:14 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:702b:48b7:1fbc:5366] (unknown [IPv6:2001:718:1a02:1:702b:48b7:1fbc:5366]) by mail.nic.cz (Postfix) with ESMTPSA id B53F2615DA; Mon, 23 Jan 2017 15:00:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485180012; bh=qPa4jRmqaloNt7g8YkHtKyDWBhAjQB8zj0WOADlpnL4=; h=From:Date:To; b=bETSmLRfRaOwHccI3ac4sATmyeEnQfX/RMHXnxbkZtJuJ+eKAAhsqs8MPR0ECqXJe L9WwtLb4ALPpwKMh3HPI5hAl4kBenAz0mykwZaTZuNBqyqWa/tdrhvtnsA9eSg0bfT tfoeHTkx/iQlGGTdTpTJCwexYPlJ2J+xMdKzZEw0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <20170123133939.GA30288@elstar.local>
Date: Mon, 23 Jan 2017 15:00:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local>  <20170123133939.GA30288@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: joel jaeggli , netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 14:00:15 -0000

> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder =
 wrote:
>=20
> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>>=20
>>> Benoit,
>>>=20
>>> RFC 6020 is ambiguous and this is just how it is. The solution for
>>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>>> character sequences (and avoiding ambiguity can be easily done).
>>>=20
>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>>> implementation into a non-conforming implementation. Hence, this may
>>> go beyond the scope of an errata.
>>=20
>> But it is not really the case here because it cannot be decided what
>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
>> don't think it is less conforming than any other.
>=20
> Exactly. But other interpretations are legal as well. We can not
> retroactively turn so far conforming implementations of the RFC into
> non-conforming implementations (via an errata that introduces a MUST
> that was not there in the beginning).
>=20
>> This would be fine for the "Notes" part but RFC Errata require also
>> "Original Text" and "Corrected Text". Any suggestion for this?
>=20
> Corrected Text
> -------------
> Within a double-quoted string (enclosed within " "), a backslash
> character introduces a special character, which depends on the
> character that immediately follows the backslash:
>=20
>  \n      new line
>  \t      a tab character
>  \"      a double quote
>  \\      a single backslash
>=20
> The interpretation of any other character then the ones listed above
> following a backslash is undefined. Authors are advised to avoid using
> such backslash sequences in double-quoted strings in their YANG
> modules.

OK, this looks good. Benoit, will you first reject the existing errata?

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 Mon Jan 23 07:26: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 9722B129628 for ; Mon, 23 Jan 2017 07:26:11 -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 fm-O7-We9N-p for ; Mon, 23 Jan 2017 07:26:10 -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 A3A39129623 for ; Mon, 23 Jan 2017 07:26:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2568; q=dns/txt; s=iport; t=1485185169; x=1486394769; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=tAKD1pUY+jF6LcjDssJxp6lEwTjCsK6umtgdehC+zZ4=; b=fE2TV0c7zyAJRy3KxhMjDNW5PAQyw+/7ug5VWLEIq/xFBevx+C4D5XMV NCPcBpIxZRDjBZNU/iK3Dy1oi9RCNQrSaQqAezOBE6yWg4k0zvU+oD6Tq 8CKVX9pAVx9YCCKBd+pWHDPitHI+3IOKG/LHYXAswJRIO3zSkyBb6anmL M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAwDfH4ZY/xbLJq1DFwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPQEBAQEBfypfjk2RE5Uugg0qhXgCgjMXAQIBAQEBAQEBYyi?= =?us-ascii?q?EaQEBAQMBOEEOAgsQCC4bPAYBDAYCAQEXiGkIDi2uMopDAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHQWGRoIFgmuBPIFQgV4mhR0FiQARh2GKWZFqgXeFD4Mqhj6KeId?= =?us-ascii?q?+IQE1EYEGEwgVFYRzDQ+BYj01AYgCAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,274,1477958400"; d="scan'208";a="649064738"
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; 23 Jan 2017 15:26:07 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0NFQ6LQ020009; Mon, 23 Jan 2017 15:26:07 GMT
To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= 
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local>  <20170123133939.GA30288@elstar.local> 
From: Benoit Claise 
Message-ID: 
Date: Mon, 23 Jan 2017 16:26:07 +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: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: joel jaeggli , netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 15:26:11 -0000

On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:
>> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder  wrote:
>>
>> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
>>> Juergen Schoenwaelder  writes:
>>>
>>>> Benoit,
>>>>
>>>> RFC 6020 is ambiguous and this is just how it is. The solution for
>>>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>>>> character sequences (and avoiding ambiguity can be easily done).
>>>>
>>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>>>> implementation into a non-conforming implementation. Hence, this may
>>>> go beyond the scope of an errata.
>>> But it is not really the case here because it cannot be decided what
>>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
>>> don't think it is less conforming than any other.
>> Exactly. But other interpretations are legal as well. We can not
>> retroactively turn so far conforming implementations of the RFC into
>> non-conforming implementations (via an errata that introduces a MUST
>> that was not there in the beginning).
>>
>>> This would be fine for the "Notes" part but RFC Errata require also
>>> "Original Text" and "Corrected Text". Any suggestion for this?
>> Corrected Text
>> -------------
>> Within a double-quoted string (enclosed within " "), a backslash
>> character introduces a special character, which depends on the
>> character that immediately follows the backslash:
>>
>>   \n      new line
>>   \t      a tab character
>>   \"      a double quote
>>   \\      a single backslash
>>
>> The interpretation of any other character then the ones listed above
>> following a backslash is undefined. Authors are advised to avoid using
>> such backslash sequences in double-quoted strings in their YANG
>> modules.
> OK, this looks good. Benoit, will you first reject the existing errata?
Instead of rejected, I modified the errata 4911.
A final check please before I approve it.
https://www.rfc-editor.org/errata_search.php?eid=4911

Regards, Benoit

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


From nobody Mon Jan 23 07:34: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 BEB0012962F for ; Mon, 23 Jan 2017 07:34: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 9ZY95UaBcS66 for ; Mon, 23 Jan 2017 07:34:01 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A557712962A for ; Mon, 23 Jan 2017 07:34:01 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id A52D11AE0285; Mon, 23 Jan 2017 16:34:00 +0100 (CET)
Date: Mon, 23 Jan 2017 16:33:59 +0100 (CET)
Message-Id: <20170123.163359.902681262209964828.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20170123133939.GA30288@elstar.local>  
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: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 15:34:02 -0000

Benoit Claise  wrote:
> On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:
> >> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
> >>  wrote:
> >>
> >> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
> >>> Juergen Schoenwaelder  writes:
> >>>
> >>>> Benoit,
> >>>>
> >>>> RFC 6020 is ambiguous and this is just how it is. The solution for
> >>>> YANG 1 is simply to give advice to module writers to avoid ambiguous
> >>>> character sequences (and avoiding ambiguity can be easily done).
> >>>>
> >>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> >>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> >>>> implementation into a non-conforming implementation. Hence, this may
> >>>> go beyond the scope of an errata.
> >>> But it is not really the case here because it cannot be decided what
> >>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
> >>> don't think it is less conforming than any other.
> >> Exactly. But other interpretations are legal as well. We can not
> >> retroactively turn so far conforming implementations of the RFC into
> >> non-conforming implementations (via an errata that introduces a MUST
> >> that was not there in the beginning).
> >>
> >>> This would be fine for the "Notes" part but RFC Errata require also
> >>> "Original Text" and "Corrected Text". Any suggestion for this?
> >> Corrected Text
> >> -------------
> >> Within a double-quoted string (enclosed within " "), a backslash
> >> character introduces a special character, which depends on the
> >> character that immediately follows the backslash:
> >>
> >>   \n      new line
> >>   \t      a tab character
> >>   \"      a double quote
> >>   \\      a single backslash
> >>
> >> The interpretation of any other character then the ones listed above
> >> following a backslash is undefined. Authors are advised to avoid using
> >> such backslash sequences in double-quoted strings in their YANG
> >> modules.
> > OK, this looks good. Benoit, will you first reject the existing
> > errata?
> Instead of rejected, I modified the errata 4911.
> A final check please before I approve it.
> https://www.rfc-editor.org/errata_search.php?eid=4911

Hmm, I still just see the orignal errata text when I follow this link.


/martin


From nobody Mon Jan 23 07:41: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 5B53612963E for ; Mon, 23 Jan 2017 07:41:09 -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 x1Zqa6rOPrMg for ; Mon, 23 Jan 2017 07:41: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 7DD1D12962F for ; Mon, 23 Jan 2017 07:41:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2525; q=dns/txt; s=iport; t=1485186067; x=1486395667; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=D0mku+1qGpcqLm+O2sqzD5Yb2cLHkj9nDznX/Ms31wc=; b=mQXNrxzg7JXDGLTWmTo998caEVI0SzbXbogz327UUfUBWJQn5vOc8Qqt wlEvZiKITnv+6opHSEUmheA4H+bd4eCmaSjHwzSJqe8R6MopVFIXCjLNs mz3fIUaD92rstXNp1Vog4XXwAQHnscRrmyFd/Kse+3IZsz2SousG7spAs 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAQC3IoZY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9AQEBAQF/Kl+NW3KRE5Uugg0qhXgCgjMYAQIBAQEBAQEBYyi?= =?us-ascii?q?EagEFOEEQCw4CCC5XBg0GAgEBF4hxDi2uK4pDAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWGS4IFgmuBPIFQhyEBBIkAEYdhilmRaoF3hQ+DKoY+iniHfh84EYEGEwg?= =?us-ascii?q?VFYRzDQ+BYj01AYgCAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,274,1477958400"; d="scan'208";a="650086698"
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; 23 Jan 2017 15:41:05 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0NFf4R3000379; Mon, 23 Jan 2017 15:41:05 GMT
To: Martin Bjorklund 
References: <20170123133939.GA30288@elstar.local>   <20170123.163359.902681262209964828.mbj@tail-f.com>
From: Benoit Claise 
Message-ID: 
Date: Mon, 23 Jan 2017 16:41:05 +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: <20170123.163359.902681262209964828.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 15:41:09 -0000

On 1/23/2017 4:33 PM, Martin Bjorklund wrote:
> Benoit Claise  wrote:
>> On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:
>>>> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
>>>>  wrote:
>>>>
>>>> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
>>>>> Juergen Schoenwaelder  writes:
>>>>>
>>>>>> Benoit,
>>>>>>
>>>>>> RFC 6020 is ambiguous and this is just how it is. The solution for
>>>>>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>>>>>> character sequences (and avoiding ambiguity can be easily done).
>>>>>>
>>>>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>>>>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>>>>>> implementation into a non-conforming implementation. Hence, this may
>>>>>> go beyond the scope of an errata.
>>>>> But it is not really the case here because it cannot be decided what
>>>>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
>>>>> don't think it is less conforming than any other.
>>>> Exactly. But other interpretations are legal as well. We can not
>>>> retroactively turn so far conforming implementations of the RFC into
>>>> non-conforming implementations (via an errata that introduces a MUST
>>>> that was not there in the beginning).
>>>>
>>>>> This would be fine for the "Notes" part but RFC Errata require also
>>>>> "Original Text" and "Corrected Text". Any suggestion for this?
>>>> Corrected Text
>>>> -------------
>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>> character introduces a special character, which depends on the
>>>> character that immediately follows the backslash:
>>>>
>>>>    \n      new line
>>>>    \t      a tab character
>>>>    \"      a double quote
>>>>    \\      a single backslash
>>>>
>>>> The interpretation of any other character then the ones listed above
>>>> following a backslash is undefined. Authors are advised to avoid using
>>>> such backslash sequences in double-quoted strings in their YANG
>>>> modules.
>>> OK, this looks good. Benoit, will you first reject the existing
>>> errata?
>> Instead of rejected, I modified the errata 4911.
>> A final check please before I approve it.
>> https://www.rfc-editor.org/errata_search.php?eid=4911
> Hmm, I still just see the orignal errata text when I follow this link.
Now saved :-)

B.
>
>
> /martin
> .
>


From nobody Mon Jan 23 07:52: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 763E9129637 for ; Mon, 23 Jan 2017 07:52:00 -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 wB0hAdLv2Ppc for ; Mon, 23 Jan 2017 07:51:58 -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 391D9129601 for ; Mon, 23 Jan 2017 07:51:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10390; q=dns/txt; s=iport; t=1485186718; x=1486396318; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=XwVmC08oPBtiEl6h5/JJ8nsvLywQxVvV1VEVzIm3O0E=; b=Xho07hOYfnTL/8YTXBwqfpCfPuaug/04bLmZDkU62hsVyADAvm6BJlqE rQsnIZPhgceStbSjnqDA2qEvlYpR0rhuv+NX+YpqfPGOogpacim4GCkju JITjGDsA7Luh7XURvXkKeXsPNwdYkM/mz6Je46M/WYtLyoFcXXDaLhH7C I=;
X-IronPort-AV: E=Sophos;i="5.33,274,1477958400";  d="scan'208,217";a="691628316"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2017 15:51:56 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0NFpuAD026584; Mon, 23 Jan 2017 15:51:56 GMT
To: Benoit Claise 
References: <20170123133939.GA30288@elstar.local>   <20170123.163359.902681262209964828.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: 
Date: Mon, 23 Jan 2017 15:51:55 +0000
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: 
Content-Type: multipart/alternative; boundary="------------50C9EE8722F7587D496B23B8"
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 15:52:00 -0000

This is a multi-part message in MIME format.
--------------50C9EE8722F7587D496B23B8
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

I would suggest tweaking the order of the words slightly:

Old:

The interpretation of any *other character then* the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

New:

The interpretation of any *character other than* the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

Thanks,
Rob


On 23/01/2017 15:41, Benoit Claise wrote:
> On 1/23/2017 4:33 PM, Martin Bjorklund wrote:
>> Benoit Claise  wrote:
>>> On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:
>>>>> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
>>>>>  wrote:
>>>>>
>>>>> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
>>>>>> Juergen Schoenwaelder  writes:
>>>>>>
>>>>>>> Benoit,
>>>>>>>
>>>>>>> RFC 6020 is ambiguous and this is just how it is. The solution for
>>>>>>> YANG 1 is simply to give advice to module writers to avoid 
>>>>>>> ambiguous
>>>>>>> character sequences (and avoiding ambiguity can be easily done).
>>>>>>>
>>>>>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>>>>>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>>>>>>> implementation into a non-conforming implementation. Hence, this 
>>>>>>> may
>>>>>>> go beyond the scope of an errata.
>>>>>> But it is not really the case here because it cannot be decided what
>>>>>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
>>>>>> don't think it is less conforming than any other.
>>>>> Exactly. But other interpretations are legal as well. We can not
>>>>> retroactively turn so far conforming implementations of the RFC into
>>>>> non-conforming implementations (via an errata that introduces a MUST
>>>>> that was not there in the beginning).
>>>>>
>>>>>> This would be fine for the "Notes" part but RFC Errata require also
>>>>>> "Original Text" and "Corrected Text". Any suggestion for this?
>>>>> Corrected Text
>>>>> -------------
>>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>>> character introduces a special character, which depends on the
>>>>> character that immediately follows the backslash:
>>>>>
>>>>>    \n      new line
>>>>>    \t      a tab character
>>>>>    \"      a double quote
>>>>>    \\      a single backslash
>>>>>
>>>>> The interpretation of any other character then the ones listed above
>>>>> following a backslash is undefined. Authors are advised to avoid 
>>>>> using
>>>>> such backslash sequences in double-quoted strings in their YANG
>>>>> modules.
>>>> OK, this looks good. Benoit, will you first reject the existing
>>>> errata?
>>> Instead of rejected, I modified the errata 4911.
>>> A final check please before I approve it.
>>> https://www.rfc-editor.org/errata_search.php?eid=4911
>> Hmm, I still just see the orignal errata text when I follow this link.
> Now saved :-)
>
> B.
>>
>>
>> /martin
>> .
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--------------50C9EE8722F7587D496B23B8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I would suggest tweaking the order of the words slightly:

    Old:

    

    The interpretation of any other character then the ones
    listed above

    following a backslash is undefined. Authors are advised to avoid
    using

    such backslash sequences in double-quoted strings in their YANG

    modules. 

    

    New:

    

    The interpretation of any character other than the ones
    listed above

    following a backslash is undefined. Authors are advised to avoid
    using

    such backslash sequences in double-quoted strings in their YANG

    modules. 

    

    Thanks,

    
Rob

      

      

      On 23/01/2017 15:41, Benoit Claise wrote:

    

    
On 1/23/2017 4:33 PM, Martin Bjorklund wrote:
      

      
Benoit Claise <bclaise@cisco.com>
        wrote:
        

        
On 1/23/2017 3:00 PM, Ladislav Lhotka
          wrote:
          

          

            
On 23 Jan 2017, at 14:39, Juergen
              Schoenwaelder
              

              <j.schoenwaelder@jacobs-university.de> wrote:
              

              

              On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka
              wrote:
              

              
Juergen Schoenwaelder
                <j.schoenwaelder@jacobs-university.de> writes:
                

                

                
Benoit,
                  

                  

                  RFC 6020 is ambiguous and this is just how it is. The
                  solution for
                  

                  YANG 1 is simply to give advice to module writers to
                  avoid ambiguous
                  

                  character sequences (and avoiding ambiguity can be
                  easily done).
                  

                  

                  YANG 1.1 fixes the ambiguity in YANG 1 but backporting
                  this fix to
                  

                  YANG 1 is a change of YANG 1, i.e., it might turn a
                  conforming
                  

                  implementation into a non-conforming implementation.
                  Hence, this may
                  

                  go beyond the scope of an errata.
                  

                

                But it is not really the case here because it cannot be
                decided what
                

                conforming means. I chose YANG 1.1 behaviour for my JS
                parser, and I
                

                don't think it is less conforming than any other.
                

              

              Exactly. But other interpretations are legal as well. We
              can not
              

              retroactively turn so far conforming implementations of
              the RFC into
              

              non-conforming implementations (via an errata that
              introduces a MUST
              

              that was not there in the beginning).
              

              

              
This would be fine for the "Notes"
                part but RFC Errata require also
                

                "Original Text" and "Corrected Text". Any suggestion for
                this?
                

              

              Corrected Text
              

              -------------
              

              Within a double-quoted string (enclosed within " "), a
              backslash
              

              character introduces a special character, which depends on
              the
              

              character that immediately follows the backslash:
              

              

               \n new line
              

               \t a tab character
              

               \" a double quote
              

               \\ a single backslash
              

              

              The interpretation of any other character then the ones
              listed above
              

              following a backslash is undefined. Authors are advised to
              avoid using
              

              such backslash sequences in double-quoted strings in their
              YANG
              

              modules.
              

            

            OK, this looks good. Benoit, will you first reject the
            existing
            

            errata?
            

          

          Instead of rejected, I modified the errata 4911.
          

          A final check please before I approve it.
          

          https://www.rfc-editor.org/errata_search.php?eid=4911
          

        

        Hmm, I still just see the orignal errata text when I follow this
        link.
        

      

      Now saved :-)
      

      

      B.
      

      

        

        

        /martin
        

        .
        

        

      

      

      _______________________________________________
      

      netmod mailing list
      

      netmod@ietf.org
      

      https://www.ietf.org/mailman/listinfo/netmod
      

      .
      

      

    

    

  


--------------50C9EE8722F7587D496B23B8--


From nobody Mon Jan 23 08:12: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 CB748129644 for ; Mon, 23 Jan 2017 08:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.157
X-Spam-Level: 
X-Spam-Status: No, score=-3.157 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, SPF_PASS=-0.001] autolearn=ham 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 qpYV5l6PxLnD for ; Mon, 23 Jan 2017 08:12:37 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 6E504129601 for ; Mon, 23 Jan 2017 08:12:37 -0800 (PST)
Received: (qmail 6303 invoked by uid 0); 23 Jan 2017 16:12:32 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 23 Jan 2017 16:12:32 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id bs9u1u00b2SSUrH01s9xjv; Mon, 23 Jan 2017 09:09:57 -0700
X-Authority-Analysis: v=2.1 cv=H75InYoi 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=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=5mljRTJBPNmTqbC7hLEA:9 a=afl1QGrh2RY3cLpC:21 a=GZNgnuBoW0IfgMrD:21 a=pILNOxqGKmIA:10 a=mhd2NDuUijAA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=0mFWnFbQd5xWBqmg7tTt:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OPbvtuQXGAOoNS+ieAzA0eRYZE9wMFHQIZoFE9I174o=; b=yvWTGV6x3y/oKXadUCWS+ksZiW aAfCPkCYS0PfXAzjxWWHRlWIPVGGb03eYX9v9/iMsnL1MqOUwXFnZQyjplgSzxAHWzPsyz4mPJCCL MI/rY1c1XnpBAT+vESjFu3BUs;
Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:48004 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cVhBr-0003pw-5o; Mon, 23 Jan 2017 09:09:55 -0700
To: Benoit Claise , mbj@tail-f.com, joelja@bogus.com, kwatsen@juniper.net, netmod@ietf.org
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local> 
From: Lou Berger 
Message-ID: <2fbe2a73-b290-619c-6f68-9d222c8253d9@labn.net>
Date: Mon, 23 Jan 2017 11:09:53 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
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: 1cVhBr-0003pw-5o
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:48004
X-Source-Auth: lberger@labn.net
X-Email-Count: 15
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 16:12:38 -0000

How do you feel about an errata on 1.0 that it should be considered to
be updated by 1.1?

Lou


On 1/23/2017 6:08 AM, Benoit Claise wrote:
> On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
>> Benoit,
>>
>> RFC 6020 is ambiguous and this is just how it is. The solution for
>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>> character sequences (and avoiding ambiguity can be easily done).
>>
>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>> implementation into a non-conforming implementation. Hence, this may
>> go beyond the scope of an errata.
>>
>> If tools generate proper warnings, I think we are fine and we do not
>> need to change YANG 1. These kind of issues are caught by tools, not
>> by humans reading language specifications.
>>
>> If you feel strongly that an errata is needed, then the errata should
>> simply clearly spell out that certain backslahs sequences are
>> ambiguous and provide advice that they should not be used.
> That would work.
> Can we modify the errata this way.
>
> Regards, Benoit
>> This is
>> backwards compatible. Making them illegal is not backwards compatible.
>>
>> /js
>>
>> PS: This is also my recollection of the discussion of issue Y06 when
>>      YANG 1.1 was put together.
>>
>> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
>>> Dear all,
>>>
>>> Let me summarize the situation.
>>>      - The RFC 6020 spec is clearly ambiguous.
>>>      - The solution is to use YANG 1.1
>>>      - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>>>      - We should stop this problem from spreading further: updating tooling
>>> is one good aspect, we should update the spec. too to at least warn the
>>> users.
>>>
>>> There is no perfect solution.
>>> Because of (*), I believe I should accept this errata.
>>> Any strong objections? If you have, propose a better plan. And I don't
>>> believe that "do nothing" is sufficient.
>>>
>>> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>>>
>>>     (16) Will publication of this document change the status of any
>>>     existing RFCs? Are those RFCs listed on the title page header, listed
>>>     in the abstract, and discussed in the introduction? If the RFCs are not
>>>     listed in the Abstract and Introduction, explain why, and point to the
>>>     part of the document where the relationship of this document to the
>>>     other RFCs is discussed. If this information is not in the document,
>>>     explain why the WG considers it unnecessary.
>>>
>>>        No. YANG 1.0 [RFC6020] is not expected to change its status since
>>>        there are data models on the standards-track that conform to YANG
>>>        1.0. YANG 1.0 may be considered for retirement once all data models
>>>        have naturally been updated to a future version of YANG.
>>>
>>> Regards, Benoit
>>>> The following errata report has been submitted for RFC6020,
>>>> "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Ladislav Lhotka 
>>>>
>>>> Section: 6.1.3
>>>>
>>>> Original Text
>>>> -------------
>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>> character introduces a special character, which depends on the
>>>> character that immediately follows the backslash:
>>>>
>>>>    \n      new line
>>>>    \t      a tab character
>>>>    \"      a double quote
>>>>    \      a single backslash
>>>>
>>>>
>>>> Corrected Text
>>>> --------------
>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>> character introduces a special character, which depends on the
>>>> character that immediately follows the backslash:
>>>>
>>>>    \n      new line
>>>>    \t      a tab character
>>>>    \"      a double quote
>>>>    \      a single backslash
>>>>
>>>> The backslash MUST NOT be followed by any other character.
>>>>
>>>> Notes
>>>> -----
>>>> The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
>>>>
>>>> 1. report an error if another character follows the backslash
>>>> 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
>>>> 3. keep both the backslash and the character following it.
>>>>
>>>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
>>>>
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party
>>>> can log in to change the status and edit the report, if necessary.
>>>>
>>>> --------------------------------------
>>>> RFC6020 (draft-ietf-netmod-yang-13)
>>>> --------------------------------------
>>>> Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
>>>> Publication Date    : October 2010
>>>> Author(s)           : M. Bjorklund, Ed.
>>>> Category            : PROPOSED STANDARD
>>>> Source              : NETCONF Data Modeling Language
>>>> Area                : Operations and Management
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>> .
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Mon Jan 23 08:26: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 B820E1295C4 for ; Mon, 23 Jan 2017 08:26:23 -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 ze_L2bLRGS8N for ; Mon, 23 Jan 2017 08:26:22 -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 08FC2129599 for ; Mon, 23 Jan 2017 08:26:22 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:702b:48b7:1fbc:5366] (unknown [IPv6:2001:718:1a02:1:702b:48b7:1fbc:5366]) by mail.nic.cz (Postfix) with ESMTPSA id A34DF60FDC; Mon, 23 Jan 2017 17:26:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485188780; bh=R+Ppg+ZpurgUjMJXAuOGxwBi8uYYFPvgmg2/YehK3c8=; h=From:Date:To; b=x5l9gTzcfkEPM12Nz2Z1UGmop5sKbPnVx5oA1FSKI3X0yDv8rm9x1ra1UEuL3RXX2 c8Y+Bjxr5cDDIMwnDFKBpzjfLnnzfBsPvBhq/tZmKV3PQtO2XLoFOwhhK5PO72+xpV 5rK583hka9B2Up6f2/MFja5bkjnNNI7jiOv9OJt4=
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, 23 Jan 2017 17:26:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20170123133939.GA30288@elstar.local>   <20170123.163359.902681262209964828.mbj@tail-f.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: joel jaeggli , netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 16:26:23 -0000

> On 23 Jan 2017, at 16:51, Robert Wilton  wrote:
>=20
> I would suggest tweaking the order of the words slightly:
>=20
> Old:
>=20
> The interpretation of any other character then the ones listed above
> following a backslash is undefined. Authors are advised to avoid using
> such backslash sequences in double-quoted strings in their YANG
> modules.=20
>=20
> New:
>=20
> The interpretation of any character other than the ones listed above
> following a backslash is undefined. Authors are advised to avoid using
> such backslash sequences in double-quoted strings in their YANG
> modules.

+1

Otherwise I like the text.

Lada

> =20
>=20
> Thanks,
> Rob
>=20
>=20
> On 23/01/2017 15:41, Benoit Claise wrote:
>> On 1/23/2017 4:33 PM, Martin Bjorklund wrote:=20
>>> Benoit Claise  wrote:=20
>>>> On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:=20
>>>>>> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder=20
>>>>>>  wrote:=20
>>>>>>=20
>>>>>> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:=20=

>>>>>>> Juergen Schoenwaelder  =
writes:=20
>>>>>>>=20
>>>>>>>> Benoit,=20
>>>>>>>>=20
>>>>>>>> RFC 6020 is ambiguous and this is just how it is. The solution =
for=20
>>>>>>>> YANG 1 is simply to give advice to module writers to avoid =
ambiguous=20
>>>>>>>> character sequences (and avoiding ambiguity can be easily =
done).=20
>>>>>>>>=20
>>>>>>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix =
to=20
>>>>>>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming=20=

>>>>>>>> implementation into a non-conforming implementation. Hence, =
this may=20
>>>>>>>> go beyond the scope of an errata.=20
>>>>>>> But it is not really the case here because it cannot be decided =
what=20
>>>>>>> conforming means. I chose YANG 1.1 behaviour for my JS parser, =
and I=20
>>>>>>> don't think it is less conforming than any other.=20
>>>>>> Exactly. But other interpretations are legal as well. We can not=20=

>>>>>> retroactively turn so far conforming implementations of the RFC =
into=20
>>>>>> non-conforming implementations (via an errata that introduces a =
MUST=20
>>>>>> that was not there in the beginning).=20
>>>>>>=20
>>>>>>> This would be fine for the "Notes" part but RFC Errata require =
also=20
>>>>>>> "Original Text" and "Corrected Text". Any suggestion for this?=20=

>>>>>> Corrected Text=20
>>>>>> -------------=20
>>>>>> Within a double-quoted string (enclosed within " "), a backslash=20=

>>>>>> character introduces a special character, which depends on the=20
>>>>>> character that immediately follows the backslash:=20
>>>>>>=20
>>>>>>    \n      new line=20
>>>>>>    \t      a tab character=20
>>>>>>    \"      a double quote=20
>>>>>>    \\      a single backslash=20
>>>>>>=20
>>>>>> The interpretation of any other character then the ones listed =
above=20
>>>>>> following a backslash is undefined. Authors are advised to avoid =
using=20
>>>>>> such backslash sequences in double-quoted strings in their YANG=20=

>>>>>> modules.=20
>>>>> OK, this looks good. Benoit, will you first reject the existing=20
>>>>> errata?=20
>>>> Instead of rejected, I modified the errata 4911.=20
>>>> A final check please before I approve it.=20
>>>> https://www.rfc-editor.org/errata_search.php?eid=3D4911=20
>>> Hmm, I still just see the orignal errata text when I follow this =
link.=20
>> Now saved :-)=20
>>=20
>> B.=20
>>>=20
>>>=20
>>> /martin=20
>>> .=20
>>>=20
>>=20
>> _______________________________________________=20
>> netmod mailing list=20
>> netmod@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/netmod=20
>> .=20
>>=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 Mon Jan 23 09:08: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 90E67129671 for ; Mon, 23 Jan 2017 09:08:08 -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 fo2a4hOCTZmy for ; Mon, 23 Jan 2017 09:08:06 -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 0AE351295B6 for ; Mon, 23 Jan 2017 09:08:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8CD0D78A; Mon, 23 Jan 2017 18:08:04 +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 6NbgTVOr3Wth; Mon, 23 Jan 2017 18:08:02 +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, 23 Jan 2017 18:08:03 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A3FA200A8; Mon, 23 Jan 2017 18:08:03 +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 40qrPy72Dw6G; Mon, 23 Jan 2017 18:08: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 71A09200A7; Mon, 23 Jan 2017 18:08:02 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 508A53E4721E; Mon, 23 Jan 2017 18:08:05 +0100 (CET)
Date: Mon, 23 Jan 2017 18:08:03 +0100
From: Juergen Schoenwaelder 
To: Lou Berger 
Message-ID: <20170123170803.GA32752@elstar.local>
Mail-Followup-To: Lou Berger , Benoit Claise , mbj@tail-f.com, joelja@bogus.com, kwatsen@juniper.net, netmod@ietf.org
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local>  <2fbe2a73-b290-619c-6f68-9d222c8253d9@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2fbe2a73-b290-619c-6f68-9d222c8253d9@labn.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 17:08:08 -0000

Lou,

RFC 7950 does not update anything in RFC 6020.

In hindsight, the proper tag would have been 'Obsoletes: RFC 6020' but
that was considered too 'aggressive' at that time and now it is too
late to put it in.

I suggest to leave it alone. People who simply google 'yang rfc' will
hopefully find the latest version. ;-)

/js

On Mon, Jan 23, 2017 at 11:09:53AM -0500, Lou Berger wrote:
> How do you feel about an errata on 1.0 that it should be considered to
> be updated by 1.1?
> 
> Lou
> 
> 
> On 1/23/2017 6:08 AM, Benoit Claise wrote:
> > On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
> >> Benoit,
> >>
> >> RFC 6020 is ambiguous and this is just how it is. The solution for
> >> YANG 1 is simply to give advice to module writers to avoid ambiguous
> >> character sequences (and avoiding ambiguity can be easily done).
> >>
> >> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> >> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> >> implementation into a non-conforming implementation. Hence, this may
> >> go beyond the scope of an errata.
> >>
> >> If tools generate proper warnings, I think we are fine and we do not
> >> need to change YANG 1. These kind of issues are caught by tools, not
> >> by humans reading language specifications.
> >>
> >> If you feel strongly that an errata is needed, then the errata should
> >> simply clearly spell out that certain backslahs sequences are
> >> ambiguous and provide advice that they should not be used.
> > That would work.
> > Can we modify the errata this way.
> >
> > Regards, Benoit
> >> This is
> >> backwards compatible. Making them illegal is not backwards compatible.
> >>
> >> /js
> >>
> >> PS: This is also my recollection of the discussion of issue Y06 when
> >>      YANG 1.1 was put together.
> >>
> >> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
> >>> Dear all,
> >>>
> >>> Let me summarize the situation.
> >>>      - The RFC 6020 spec is clearly ambiguous.
> >>>      - The solution is to use YANG 1.1
> >>>      - RFC 7950 doesn't update or obsolete RFC 6020 (*)
> >>>      - We should stop this problem from spreading further: updating tooling
> >>> is one good aspect, we should update the spec. too to at least warn the
> >>> users.
> >>>
> >>> There is no perfect solution.
> >>> Because of (*), I believe I should accept this errata.
> >>> Any strong objections? If you have, propose a better plan. And I don't
> >>> believe that "do nothing" is sufficient.
> >>>
> >>> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
> >>>
> >>>     (16) Will publication of this document change the status of any
> >>>     existing RFCs? Are those RFCs listed on the title page header, listed
> >>>     in the abstract, and discussed in the introduction? If the RFCs are not
> >>>     listed in the Abstract and Introduction, explain why, and point to the
> >>>     part of the document where the relationship of this document to the
> >>>     other RFCs is discussed. If this information is not in the document,
> >>>     explain why the WG considers it unnecessary.
> >>>
> >>>        No. YANG 1.0 [RFC6020] is not expected to change its status since
> >>>        there are data models on the standards-track that conform to YANG
> >>>        1.0. YANG 1.0 may be considered for retirement once all data models
> >>>        have naturally been updated to a future version of YANG.
> >>>
> >>> Regards, Benoit
> >>>> The following errata report has been submitted for RFC6020,
> >>>> "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
> >>>>
> >>>> --------------------------------------
> >>>> You may review the report below and at:
> >>>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
> >>>>
> >>>> --------------------------------------
> >>>> Type: Technical
> >>>> Reported by: Ladislav Lhotka 
> >>>>
> >>>> Section: 6.1.3
> >>>>
> >>>> Original Text
> >>>> -------------
> >>>> Within a double-quoted string (enclosed within " "), a backslash
> >>>> character introduces a special character, which depends on the
> >>>> character that immediately follows the backslash:
> >>>>
> >>>>    \n      new line
> >>>>    \t      a tab character
> >>>>    \"      a double quote
> >>>>    \      a single backslash
> >>>>
> >>>>
> >>>> Corrected Text
> >>>> --------------
> >>>> Within a double-quoted string (enclosed within " "), a backslash
> >>>> character introduces a special character, which depends on the
> >>>> character that immediately follows the backslash:
> >>>>
> >>>>    \n      new line
> >>>>    \t      a tab character
> >>>>    \"      a double quote
> >>>>    \      a single backslash
> >>>>
> >>>> The backslash MUST NOT be followed by any other character.
> >>>>
> >>>> Notes
> >>>> -----
> >>>> The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
> >>>>
> >>>> 1. report an error if another character follows the backslash
> >>>> 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
> >>>> 3. keep both the backslash and the character following it.
> >>>>
> >>>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
> >>>>
> >>>> Instructions:
> >>>> -------------
> >>>> This erratum is currently posted as "Reported". If necessary, please
> >>>> use "Reply All" to discuss whether it should be verified or
> >>>> rejected. When a decision is reached, the verifying party
> >>>> can log in to change the status and edit the report, if necessary.
> >>>>
> >>>> --------------------------------------
> >>>> RFC6020 (draft-ietf-netmod-yang-13)
> >>>> --------------------------------------
> >>>> Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
> >>>> Publication Date    : October 2010
> >>>> Author(s)           : M. Bjorklund, Ed.
> >>>> Category            : PROPOSED STANDARD
> >>>> Source              : NETCONF Data Modeling Language
> >>>> Area                : Operations and Management
> >>>> Stream              : IETF
> >>>> Verifying Party     : IESG
> >>>> .
> >>>>
> >>> _______________________________________________
> >>> 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

-- 
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 23 09:18: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 DDF181295A7; Mon, 23 Jan 2017 09:18:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level: 
X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy_ZthJA9sKs; Mon, 23 Jan 2017 09:18:19 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B021295A8; Mon, 23 Jan 2017 09:18:19 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 540A4B80FFD; Mon, 23 Jan 2017 09:18:19 -0800 (PST)
To: lhotka@nic.cz, mbj@tail-f.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170123171819.540A4B80FFD@rfc-editor.org>
Date: Mon, 23 Jan 2017 09:18:19 -0800 (PST)
Archived-At: 
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Verified] RFC6020 (4911)
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, 23 Jan 2017 17:18:21 -0000

The following errata report has been verified for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911

--------------------------------------
Status: Verified
Type: Technical

Reported by: Ladislav Lhotka 
Date Reported: 2017-01-18
Verified by: Benoit Claise (IESG)

Section: 6.1.3

Original Text
-------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n      new line
 \t      a tab character
 \"      a double quote
 \      a single backslash


Corrected Text
--------------
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n      new line
 \t      a tab character
 \"      a double quote
 \      a single backslash


The interpretation of any character other than the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

Notes
-----
The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:

1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
3. keep both the backslash and the character following it.

This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.

--------------------------------------
RFC6020 (draft-ietf-netmod-yang-13)
--------------------------------------
Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
Publication Date    : October 2010
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Jan 23 09:18:51 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 64CED1295A8 for ; Mon, 23 Jan 2017 09:18: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 0cBTbGlT1wKa for ; Mon, 23 Jan 2017 09:18:48 -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 296B91295A7 for ; Mon, 23 Jan 2017 09:18:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3954; q=dns/txt; s=iport; t=1485191928; x=1486401528; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8K6oE8yoAB6Wg+bbW/F4xdUJUtK7bhgJR2HMubwX1AA=; b=F1lbMdMDDigq3JfsC6jY2lDzKBVPU6yTJzK4J6Jg8sbkotIDFsqeyUdF CHItX2A3sISgK/RLQsi4W2AtIL8e4ayRjLqPgaOkk9Si6zaihSiG1HFd2 3e5b5ETNwMOdqEiy2L/YUlltWIdpfNmqswcrj7ARsUCidhXV1TXIyLZr4 8=;
X-IronPort-AV: E=Sophos;i="5.33,274,1477958400"; d="scan'208";a="651910233"
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; 23 Jan 2017 17:18:46 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0NHIjCB024353; Mon, 23 Jan 2017 17:18:46 GMT
To: Ladislav Lhotka , Robert Wilton 
References: <20170123133939.GA30288@elstar.local>   <20170123.163359.902681262209964828.mbj@tail-f.com>   
From: Benoit Claise 
Message-ID: 
Date: Mon, 23 Jan 2017 18:18:46 +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: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: joel jaeggli , netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 17:18:50 -0000

On 1/23/2017 5:26 PM, Ladislav Lhotka wrote:
>> On 23 Jan 2017, at 16:51, Robert Wilton  wrote:
>>
>> I would suggest tweaking the order of the words slightly:
>>
>> Old:
>>
>> The interpretation of any other character then the ones listed above
>> following a backslash is undefined. Authors are advised to avoid using
>> such backslash sequences in double-quoted strings in their YANG
>> modules.
>>
>> New:
>>
>> The interpretation of any character other than the ones listed above
>> following a backslash is undefined. Authors are advised to avoid using
>> such backslash sequences in double-quoted strings in their YANG
>> modules.
> +1
>
> Otherwise I like the text.
Good.
Errata approved.

Regards, B.
>
> Lada
>
>>   
>>
>> Thanks,
>> Rob
>>
>>
>> On 23/01/2017 15:41, Benoit Claise wrote:
>>> On 1/23/2017 4:33 PM, Martin Bjorklund wrote:
>>>> Benoit Claise  wrote:
>>>>> On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:
>>>>>>> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
>>>>>>>  wrote:
>>>>>>>
>>>>>>> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
>>>>>>>> Juergen Schoenwaelder  writes:
>>>>>>>>
>>>>>>>>> Benoit,
>>>>>>>>>
>>>>>>>>> RFC 6020 is ambiguous and this is just how it is. The solution for
>>>>>>>>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>>>>>>>>> character sequences (and avoiding ambiguity can be easily done).
>>>>>>>>>
>>>>>>>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>>>>>>>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>>>>>>>>> implementation into a non-conforming implementation. Hence, this may
>>>>>>>>> go beyond the scope of an errata.
>>>>>>>> But it is not really the case here because it cannot be decided what
>>>>>>>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
>>>>>>>> don't think it is less conforming than any other.
>>>>>>> Exactly. But other interpretations are legal as well. We can not
>>>>>>> retroactively turn so far conforming implementations of the RFC into
>>>>>>> non-conforming implementations (via an errata that introduces a MUST
>>>>>>> that was not there in the beginning).
>>>>>>>
>>>>>>>> This would be fine for the "Notes" part but RFC Errata require also
>>>>>>>> "Original Text" and "Corrected Text". Any suggestion for this?
>>>>>>> Corrected Text
>>>>>>> -------------
>>>>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>>>>> character introduces a special character, which depends on the
>>>>>>> character that immediately follows the backslash:
>>>>>>>
>>>>>>>     \n      new line
>>>>>>>     \t      a tab character
>>>>>>>     \"      a double quote
>>>>>>>     \\      a single backslash
>>>>>>>
>>>>>>> The interpretation of any other character then the ones listed above
>>>>>>> following a backslash is undefined. Authors are advised to avoid using
>>>>>>> such backslash sequences in double-quoted strings in their YANG
>>>>>>> modules.
>>>>>> OK, this looks good. Benoit, will you first reject the existing
>>>>>> errata?
>>>>> Instead of rejected, I modified the errata 4911.
>>>>> A final check please before I approve it.
>>>>> https://www.rfc-editor.org/errata_search.php?eid=4911
>>>> Hmm, I still just see the orignal errata text when I follow this link.
>>> Now saved :-)
>>>
>>> B.
>>>>
>>>> /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
>
>
>
>
>
> .
>


From nobody Mon Jan 23 09:19: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 281FE129690 for ; Mon, 23 Jan 2017 09:19:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5Licz5Fxyq53 for ; Mon, 23 Jan 2017 09:18:59 -0800 (PST)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511361295A7 for ; Mon, 23 Jan 2017 09:18:59 -0800 (PST)
Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0NH7RBY001974 for ; Mon, 23 Jan 2017 09:18:59 -0800
Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 285nmjr4jj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 23 Jan 2017 09:18:58 -0800
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 10:18:57 -0700
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 18:18:56 +0100
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1210.000; Mon, 23 Jan 2017 18:18:55 +0100
From: William Ivory 
To: "netmod@ietf. org netmod@ietf.org netmod@ietf. org (netmod@ietf.org)" 
Thread-Topic: Query about invalid XPATH paths in YANG
Thread-Index: AdJ1m9ZZTDt+X1fUS2y3zpVZg/3VlQ==
Date: Mon, 23 Jan 2017 17:18:31 +0000
Deferred-Delivery: Mon, 23 Jan 2017 17:18:09 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.252.48.7]
Content-Type: multipart/alternative; boundary="_000_f92db8a7b45f4d15b3fa2800b3bb8c61EMEAWPEXMB11corpbrocade_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-23_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701230222
Archived-At: 
Subject: [netmod] Query about invalid XPATH paths in 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, 23 Jan 2017 17:19:00 -0000

--_000_f92db8a7b45f4d15b3fa2800b3bb8c61EMEAWPEXMB11corpbrocade_
Content-Type: text/plain; charset="us-ascii"

Hi,

I'd appreciate clarification on whether a YANG path in an XPATH statement in a must or when statement must point to a valid YANG path or not.  You might wonder why we'd have an invalid path (as opposed to one that's simply not configured right now) but it is occasionally helpful when sharing groupings.  (Possibly we should remodel the YANG but that's another matter!).

As a simple example, is the following allowed?

Container foo {
        Leaf bar {
                Type string;
                Must "not(../nonExistentSiblingNode)";
        }
}

I don't see that this should be any different to a must statement path pointing to an unconfigured node, returning an empty nodeset in both cases.

The reason I ask is that we are seeing a NETCONF client differentiating between unconfigured (ok) and non-existent (error) cases.  It would be useful to know one way or the other, ideally with a pointer to the relevant part of the spec that makes this clear.

Thanks,

William


--_000_f92db8a7b45f4d15b3fa2800b3bb8c61EMEAWPEXMB11corpbrocade_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I’d appreciate clarification on whether a YANG path in an XPATH =
statement in a must or when statement must point to a valid YANG path or no=
t.  You might wonder why we’d have an invalid path (as opposed t=
o one that’s simply not configured right now) but
it is occasionally helpful when sharing groupings.  (Possibly we shoul=
d remodel the YANG but that’s another matter!).


 


As a simple example, is the following allowed?


 


Container foo {


        Leaf bar {


           &nbs=
p;    Type string;


           &nbs=
p;    Must “not(../nonExistentSiblingNode)”;

        }


}


 


I don’t see that this should be any different to a must statemen=
t path pointing to an unconfigured node, returning an empty nodeset in both=
 cases.


 


The reason I ask is that we are seeing a NETCONF client differentiatin=
g between unconfigured (ok) and non-existent (error) cases.  It would =
be useful to know one way or the other, ideally with a pointer to the relev=
ant part of the spec that makes this
clear.


 


Thanks,


 


William


 





--_000_f92db8a7b45f4d15b3fa2800b3bb8c61EMEAWPEXMB11corpbrocade_--


From nobody Mon Jan 23 09: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 12C501295BD for ; Mon, 23 Jan 2017 09:20:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-nRQc0IRF23 for ; Mon, 23 Jan 2017 09:20:57 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7EF129557 for ; Mon, 23 Jan 2017 09:20:57 -0800 (PST)
Received: from [::1] (port=35238) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1cViIV-0003mW-Ln; Mon, 23 Jan 2017 20:20:51 +0300
To: Benoit Claise , mbj@tail-f.com, joelja@bogus.com, kwatsen@juniper.net, netmod@ietf.org
References: <20170118114858.62A63B80FFD@rfc-editor.org>  <20170123104655.GA29877@elstar.local>  <2fbe2a73-b290-619c-6f68-9d222c8253d9@labn.net> <20170123170803.GA32752@elstar.local>
From: Lou Berger 
Message-ID: <6e051ee9-8645-5e85-f589-1ba71ecf3054@labn.net>
Date: Mon, 23 Jan 2017 12:20:48 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170123170803.GA32752@elstar.local>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?
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, 23 Jan 2017 17:20:59 -0000

I think we need something.  BTW I'm fine with obsoletes ;-)


On 1/23/2017 12:08 PM, Juergen Schoenwaelder wrote:
> Lou,
>
> RFC 7950 does not update anything in RFC 6020.
>
> In hindsight, the proper tag would have been 'Obsoletes: RFC 6020' but
> that was considered too 'aggressive' at that time and now it is too
> late to put it in.
>
> I suggest to leave it alone. People who simply google 'yang rfc' will
> hopefully find the latest version. ;-)
>
> /js
>
> On Mon, Jan 23, 2017 at 11:09:53AM -0500, Lou Berger wrote:
>> How do you feel about an errata on 1.0 that it should be considered to
>> be updated by 1.1?
>>
>> Lou
>>
>>
>> On 1/23/2017 6:08 AM, Benoit Claise wrote:
>>> On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
>>>> Benoit,
>>>>
>>>> RFC 6020 is ambiguous and this is just how it is. The solution for
>>>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>>>> character sequences (and avoiding ambiguity can be easily done).
>>>>
>>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>>>> implementation into a non-conforming implementation. Hence, this may
>>>> go beyond the scope of an errata.
>>>>
>>>> If tools generate proper warnings, I think we are fine and we do not
>>>> need to change YANG 1. These kind of issues are caught by tools, not
>>>> by humans reading language specifications.
>>>>
>>>> If you feel strongly that an errata is needed, then the errata should
>>>> simply clearly spell out that certain backslahs sequences are
>>>> ambiguous and provide advice that they should not be used.
>>> That would work.
>>> Can we modify the errata this way.
>>>
>>> Regards, Benoit
>>>> This is
>>>> backwards compatible. Making them illegal is not backwards compatible.
>>>>
>>>> /js
>>>>
>>>> PS: This is also my recollection of the discussion of issue Y06 when
>>>>      YANG 1.1 was put together.
>>>>
>>>> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
>>>>> Dear all,
>>>>>
>>>>> Let me summarize the situation.
>>>>>      - The RFC 6020 spec is clearly ambiguous.
>>>>>      - The solution is to use YANG 1.1
>>>>>      - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>>>>>      - We should stop this problem from spreading further: updating tooling
>>>>> is one good aspect, we should update the spec. too to at least warn the
>>>>> users.
>>>>>
>>>>> There is no perfect solution.
>>>>> Because of (*), I believe I should accept this errata.
>>>>> Any strong objections? If you have, propose a better plan. And I don't
>>>>> believe that "do nothing" is sufficient.
>>>>>
>>>>> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>>>>>
>>>>>     (16) Will publication of this document change the status of any
>>>>>     existing RFCs? Are those RFCs listed on the title page header, listed
>>>>>     in the abstract, and discussed in the introduction? If the RFCs are not
>>>>>     listed in the Abstract and Introduction, explain why, and point to the
>>>>>     part of the document where the relationship of this document to the
>>>>>     other RFCs is discussed. If this information is not in the document,
>>>>>     explain why the WG considers it unnecessary.
>>>>>
>>>>>        No. YANG 1.0 [RFC6020] is not expected to change its status since
>>>>>        there are data models on the standards-track that conform to YANG
>>>>>        1.0. YANG 1.0 may be considered for retirement once all data models
>>>>>        have naturally been updated to a future version of YANG.
>>>>>
>>>>> Regards, Benoit
>>>>>> The following errata report has been submitted for RFC6020,
>>>>>> "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
>>>>>>
>>>>>> --------------------------------------
>>>>>> You may review the report below and at:
>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>>>>>>
>>>>>> --------------------------------------
>>>>>> Type: Technical
>>>>>> Reported by: Ladislav Lhotka 
>>>>>>
>>>>>> Section: 6.1.3
>>>>>>
>>>>>> Original Text
>>>>>> -------------
>>>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>>>> character introduces a special character, which depends on the
>>>>>> character that immediately follows the backslash:
>>>>>>
>>>>>>    \n      new line
>>>>>>    \t      a tab character
>>>>>>    \"      a double quote
>>>>>>    \      a single backslash
>>>>>>
>>>>>>
>>>>>> Corrected Text
>>>>>> --------------
>>>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>>>> character introduces a special character, which depends on the
>>>>>> character that immediately follows the backslash:
>>>>>>
>>>>>>    \n      new line
>>>>>>    \t      a tab character
>>>>>>    \"      a double quote
>>>>>>    \      a single backslash
>>>>>>
>>>>>> The backslash MUST NOT be followed by any other character.
>>>>>>
>>>>>> Notes
>>>>>> -----
>>>>>> The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
>>>>>>
>>>>>> 1. report an error if another character follows the backslash
>>>>>> 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
>>>>>> 3. keep both the backslash and the character following it.
>>>>>>
>>>>>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
>>>>>>
>>>>>> Instructions:
>>>>>> -------------
>>>>>> This erratum is currently posted as "Reported". If necessary, please
>>>>>> use "Reply All" to discuss whether it should be verified or
>>>>>> rejected. When a decision is reached, the verifying party
>>>>>> can log in to change the status and edit the report, if necessary.
>>>>>>
>>>>>> --------------------------------------
>>>>>> RFC6020 (draft-ietf-netmod-yang-13)
>>>>>> --------------------------------------
>>>>>> Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
>>>>>> Publication Date    : October 2010
>>>>>> Author(s)           : M. Bjorklund, Ed.
>>>>>> Category            : PROPOSED STANDARD
>>>>>> Source              : NETCONF Data Modeling Language
>>>>>> Area                : Operations and Management
>>>>>> Stream              : IETF
>>>>>> Verifying Party     : IESG
>>>>>> .
>>>>>>
>>>>> _______________________________________________
>>>>> 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


From nobody Mon Jan 23 09:46:50 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 50CC91296CB for ; Mon, 23 Jan 2017 09:46:49 -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 Q7T9a_OVpLxE for ; Mon, 23 Jan 2017 09:46:47 -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 C784D1296CA for ; Mon, 23 Jan 2017 09:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19498; q=dns/txt; s=iport; t=1485193606; x=1486403206; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=pRP40XLpZPlZF6Hifn2Rg4TqPy69v6+KuXCs543NdRY=; b=Kmv4YtebXuv+LZi2Qs+7WcHisu/5zdLmFQs/7pBac+e9F6Z08IYIvUvB /m3HAPUlrxDJqeMo/ltOvCogiG6Cjn+nsXQE9jEE31jmFHWMy87KZkpQD dKC6Gd+HA5zIebs8zO01nwh+NytTqOB6f7A3Mdp17nldEZ+FCEX3KOpI5 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAgC+QIZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAX8qX4NTgQSJBHKRE5ADhSuCDR8BDIUsSgKCPhgBAgE?= =?us-ascii?q?BAQEBAQFjKIRqAQEEAQEhSwsQCxgnAwICJx8RBg0GAgEBiQgOrFqCJSuKIwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2GS4IFgmuEVYJ6gl4FjyyMH4ZigxmHb4F3Uod?= =?us-ascii?q?nI4YbiniHfh84gRcTCBUVOoQBgjY9NQEBhV8rghABAQE?=
X-IronPort-AV: E=Sophos;i="5.33,275,1477958400";  d="scan'208,217";a="649068788"
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; 23 Jan 2017 17:46:43 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0NHkhNp020432; Mon, 23 Jan 2017 17:46:43 GMT
To: Andy Bierman 
References: <20170116.164803.729427888661667991.mbj@tail-f.com>  
From: Benoit Claise 
Message-ID: <003354d9-841f-37b2-a594-6e9983110984@cisco.com>
Date: Mon, 23 Jan 2017 18:46:44 +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: 
Content-Type: multipart/alternative; boundary="------------DA9CDEE87A46C1F7EBD367CA"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] example modules in 6087bis
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, 23 Jan 2017 17:46:49 -0000

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

On 1/18/2017 7:00 PM, Andy Bierman wrote:
>
>
> On Wed, Jan 18, 2017 at 9:12 AM, Benoit Claise  > wrote:
>
>     Martin,
>>     Hi,
>>
>>     It turns out that the recommendations on example modules are a bit
>>     unclear.  Different drafts do very different things.  Some examples:
>>
>>     https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2
>>     
>>
>>     This example module really looks like a real module.  It uses an
>>     IANA-controlled namespace, and the meta-statements indicate that this
>>     is a normative modules.  But the module does not use the  tags.
>>
>>
>>     https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1
>>     
>>
>>     This module is better, but it is written to follow RFC 6087 rules
>>     (pass pyang --ietf), with the result that it contains a bit of "noise"
>     It takes a lot of YANG experience to be able to distinguish what
>     is noise or not. 
>
> I agree.  I see Martin's point though -- maintenance clauses like 
> contact and organization
> are not really needed for examples.
>
>>     with some meaningless descriptions and meta-statements.  It also does
>>     not use  tags.
>>
>>
>>     A good example (IMO) is found in
>>     https://tools.ietf.org/html/rfc8022#appendix-C
>>     
>>
>>     It uses descriptions when necessary (high s/n), no fake
>>     meta-statements etc.
>>
>>     However, it might be a good idea to require example modules to have a
>>     "description" statement that explains what the module examplifies.
>>     For example, the example-rip could have:
>>
>>        description
>>          "This example module demonstrates how the core routing data model
>>           can be extended to support a new control-plane protocol.  It is
>>           intended as an illustration rather than a real definition of a
>>           data model for the Routing Information Protocol (RIP).";
>>
>>
>>
>>     I think that 6087bis is clear when it says:
>>
>>        The guidelines in this document refer mainly to a normative complete
>>        module or submodule, but may be applicable to example modules and
>>        YANG fragments as well.
>>
>>     I think this states that example modules do not have to pass pyang
>>     --ietf.
>>
>>
>>     In order to make this more clear, I suggest the following changes to
>>     draft-ietf-netmod-rfc6087bis-09
>>
>>     In the Terminology section 2.4:
>>
>>     NEW:
>>
>>        o  Example module:  A complete YANG module or submodule that is
>>           intended to illustrate some specific aspect, but not intended for
>>           actual use.
>     It doesn't solve this issue, because
>     https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09#section-4.2.1
>     
>     says:
>
>           The  convention SHOULD be used for complete example
>           modules, but not YANG fragments.
>
>     That implies to me that we have 3 types: 1. _complete _example
>     modules => I read it that they must pass pyang -ietf, SHOULD have
>          If there is , it's because people
>     will want to extract it, and play with it. So the tools chain must
>     work 2. the other example modules. No . I guess they
>     don't pass pyang 3. YANG fragments. No . I guess they
>     don't pass pyang In practice, 2 and 3 are the same. So we need
>     just two definition Scrap "complete" would help but that's not
>     enough:
>
>       The  convention SHOULD be used for example
>       modules, but not YANG fragments.
>
>     We only need to clarify 3 points     , yes/no    
>     pyang, yes/no     pyang --ietf yes/no I guess we want, putting all
>     this together:
>
>        o  Example module:  A complete YANG module or submodule that is
>           intended to illustrate some specific aspect, but not intended for
>           actual use. Example module MUST be valid according to RFC 7950,
>           except when they are used to illustrate some illegal constructs.
>           Example module MAY be valid according to the rules in this document.
>
>        o  YANG fragment:  A incomplete YANG module or submodule that is
>           intended to illustrate some specific aspect, but not intended for
>           actual use. YANG fragments MUST be valid according to RFC 7950,
>           except when they are used to illustrate some illegal constructs.
>
> This is good
> I prefer:
>    - MUST use CODE BEGINS for a real module
>    - MUST NOT use CODE BEGINS for an example module
>    - MUST pass pyang --ietf for a real module
>    - MUST pass pyang for example module
Fine with me. Consistency is key here. Is it time to conclude this 
discussion? Regards, Benoit
> I have already received private emails about implementing the 
> example-jukebox
> module in RESTCONF as part of the standard.  We already have operational
> experience that people can be confused by the example modules, and
> think they are supposed to be implemented for RFC compliance.
>
>       The  convention SHOULD be used for example
>       modules that pass validation according to RFC 7950.
>
>       The  convention MUST NOT be used for YANG fragment
>       and for example modules that are used to illustrate some illegal constructs
>       (therefore failing validation according to RFC 7950).
>
> This text concerns me a little
> We are not following the  anywhere for examples.
> the tools are extracting anything that starts "module blah".
> IMO this makes it easier to confuse real and example modules.
> I would prefer to consider only real modules as Code Components.
> (We collect broken modules to test the compiler in modules/test/fail 
> folder,
> so even bad modules might be extracted.)
>
>>     In section 4:
>>
>>     NEW:
>>
>>         All normative modules or submodules, example modules or submodules,
>>         and example YANG fragments MUST be valid according to RFC 7950,
>>         except when they are used to illustrate some illegal constructs.
>     We wouldn't need this if you take my proposal
>>     In Section 4.2.1 "Example Modules":
>>
>>     NEW:
>>
>>        An example module SHOULD have a namespace on the form
>>
>>          ohttp://example.com/ OR
>>          o  urn:example:
>>
>>        An example module SHOULD have a description statement that describes
>>        that it is an example module, and what it examplifies.
>>
>>        An example module SHOULD NOT have any additional meta-statements
>>        (i.e., "organization", "contact", or "reference").
>>
>>        An example module SHOULD use the "description" statement in any
>>        definition where it is required to understand the example.
>>
>     Fine. Note that the RESTCONF RFC publication depends on this
>     RFC6087bis convention. So let's quickly come to a conclusion.
>     Regards, Benoit
>
> Andy
>
>>     /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
>      
>

--------------DA9CDEE87A46C1F7EBD367CA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 1/18/2017 7:00 PM, Andy Bierman
      wrote:

    

    

      
      


        


          
On Wed, Jan 18, 2017 at 9:12 AM,
            Benoit Claise <bclaise@cisco.com>
            wrote:

            

              

                
Martin,
                  

                

                

                  
Hi,

It turns out that the recommendations on example modules are a bit
unclear.  Different drafts do very different things.  Some examples:

https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2

This example module really looks like a real module.  It uses an
IANA-controlled namespace, and the meta-statements indicate that this
is a normative modules.  But the module does not use the <CODE> tags.


https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1

This module is better, but it is written to follow RFC 6087 rules
(pass pyang --ietf), with the result that it contains a bit of "noise"

    

    It takes a lot of YANG experience to be able to distinguish what is
    noise or not.



I agree.  I see Martin's point though -- maintenance clauses like contact and organization
are not really needed for examples.
 

    

      
with some meaningless descriptions and meta-statements.  It also does
not use <CODE> tags.


A good example (IMO) is found in
https://tools.ietf.org/html/rfc8022#appendix-C

It uses descriptions when necessary (high s/n), no fake
meta-statements etc.

However, it might be a good idea to require example modules to have a
"description" statement that explains what the module examplifies.
For example, the example-rip could have:

  description
    "This example module demonstrates how the core routing data model
     can be extended to support a new control-plane protocol.  It is
     intended as an illustration rather than a real definition of a
     data model for the Routing Information Protocol (RIP).";



I think that 6087bis is clear when it says:

  The guidelines in this document refer mainly to a normative complete
  module or submodule, but may be applicable to example modules and
  YANG fragments as well.

I think this states that example modules do not have to pass pyang
--ietf.


In order to make this more clear, I suggest the following changes to
draft-ietf-netmod-rfc6087bis-09

In the Terminology section 2.4:

NEW:

  o  Example module:  A complete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use.

    

    It doesn't solve this issue, because
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09#section-4.2.1
    says:

    

      
 The <CODE BEGINS> convention SHOULD be used for complete example
 modules, but not YANG fragments. 

    

    That implies to me that we have 3 types:

    1. complete example modules => I read it that they must
    pass pyang -ietf, SHOULD have <CODE BEGINS>

        If there is <CODE BEGINS>, it's because people will want
    to extract it, and play with it. So the tools chain must work

    2. the other example modules. No <CODE BEGINS>. I guess they
    don't pass pyang

    3. YANG fragments. No <CODE BEGINS>. I guess they don't pass
    pyang

    

    In practice, 2 and 3 are the same. So we need just two definition

    

    Scrap "complete" would help but that's not enough:

    
 The <CODE BEGINS> convention SHOULD be used for example
 modules, but not YANG fragments. 

    We only need to clarify 3 points 

        <CODE BEGINS>, yes/no

        pyang, yes/no

        pyang --ietf yes/no

    

    I guess we want, putting all this together:

    

    
  o  Example module:  A complete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use. Example module MUST be valid according to RFC 7950,
     except when they are used to illustrate some illegal constructs.
     Example module MAY be valid according to the rules in this document.


    
  o  YANG fragment:  A incomplete YANG module or submodule that is
     intended to illustrate some specific aspect, but not intended for
     actual use. YANG fragments MUST be valid according to RFC 7950,
     except when they are used to illustrate some illegal constructs.



This is good
I prefer:
   - MUST use CODE BEGINS for a real module
   - MUST NOT use CODE BEGINS for an example module


   - MUST pass pyang --ietf for a real module
   - MUST pass pyang for example module
Fine with me. Consistency is key here.

Is it time to conclude this discussion?

Regards, Benoit



I have already received private emails about implementing the example-jukebox
module in RESTCONF as part of the standard.  We already have operational
experience that people can be confused by the example modules, and
think they are supposed to be implemented for RFC compliance.
 
 The <CODE BEGINS> convention SHOULD be used for example
 modules that pass validation according to RFC 7950.  


    
 The <CODE BEGINS> convention MUST NOT be used for YANG fragment
 and for example modules that are used to illustrate some illegal constructs
 (therefore failing validation according to RFC 7950).

    



This text concerns me a little
We are not following the <CODE BEGINS> anywhere for examples.

the tools are extracting anything that starts "module blah".
IMO this makes it easier to confuse real and example modules.
I would prefer to consider only real modules as Code Components.



(We collect broken modules to test the compiler in modules/test/fail folder,
so even bad modules might be extracted.)







    

      
In section 4:

NEW:

   All normative modules or submodules, example modules or submodules,
   and example YANG fragments MUST be valid according to RFC 7950,
   except when they are used to illustrate some illegal constructs.

    

    We wouldn't need this if you take my proposal

    

      
In Section 4.2.1 "Example Modules":

NEW:

  An example module SHOULD have a namespace on the form

    o  http://example.com/<module-name> OR
    o  urn:example:<module-name>

  An example module SHOULD have a description statement that describes
  that it is an example module, and what it examplifies.

  An example module SHOULD NOT have any additional meta-statements
  (i.e., "organization", "contact", or "reference").

  An example module SHOULD use the "description" statement in any
  definition where it is required to understand the example.



    

    Fine.

    

    Note that the RESTCONF RFC publication depends on this RFC6087bis
    convention. So let's quickly come to a conclusion.

    

    Regards, Benoit

    

      




Andy


 
/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












--------------DA9CDEE87A46C1F7EBD367CA--


From nobody Mon Jan 23 10:17: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 5BDE6129722 for ; Mon, 23 Jan 2017 10:17:29 -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 P2ioB6Dcko7z for ; Mon, 23 Jan 2017 10:17:28 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5B129721 for ; Mon, 23 Jan 2017 10:17:28 -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 88D0C1AE0285; Mon, 23 Jan 2017 19:17:27 +0100 (CET)
Date: Mon, 23 Jan 2017 19:17:27 +0100 (CET)
Message-Id: <20170123.191727.2281365809408713783.mbj@tail-f.com>
To: wivory@Brocade.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=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Query about invalid XPATH paths in 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, 23 Jan 2017 18:17:29 -0000

William Ivory  wrote:
> Hi,
> 
> I'd appreciate clarification on whether a YANG path in an XPATH
> statement in a must or when statement must point to a valid YANG path
> or not.  You might wonder why we'd have an invalid path (as opposed to
> one that's simply not configured right now) but it is occasionally
> helpful when sharing groupings.  (Possibly we should remodel the YANG
> but that's another matter!).
> 
> As a simple example, is the following allowed?
> 
> Container foo {
>         Leaf bar {
>                 Type string;
>                 Must "not(../nonExistentSiblingNode)";
>         }
> }

Yes this is allowed.  Many YANG compilers give warnings for this kind
of expression, but it is legal.

> I don't see that this should be any different to a must statement path
> pointing to an unconfigured node, returning an empty nodeset in both
> cases.
> 
> The reason I ask is that we are seeing a NETCONF client
> differentiating between unconfigured (ok) and non-existent (error)
> cases.  It would be useful to know one way or the other, ideally with
> a pointer to the relevant part of the spec that makes this clear.

It follows from how XPath works, and the fact that there is no text in
RFC 7950 (or 6020) that limits XPath to something non-standard.


/martin


From nobody Mon Jan 23 10:34: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 4E123129705 for ; Mon, 23 Jan 2017 10:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 y080Za6Awsqg for ; Mon, 23 Jan 2017 10:34:31 -0800 (PST)
Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC88E129771 for ; Mon, 23 Jan 2017 10:34:30 -0800 (PST)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0NIP7X5031055; Mon, 23 Jan 2017 10:34:30 -0800
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 284654ny2e-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Jan 2017 10:34:30 -0800
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 11:34:27 -0700
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 19:34:26 +0100
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1210.000; Mon, 23 Jan 2017 19:34:26 +0100
From: William Ivory 
To: Martin Bjorklund 
Thread-Topic: [netmod] Query about invalid XPATH paths in YANG
Thread-Index: AdJ1m9ZZTDt+X1fUS2y3zpVZg/3VlQAALuKAAAKhHMA=
Date: Mon, 23 Jan 2017 18:34:01 +0000
Deferred-Delivery: Mon, 23 Jan 2017 18:33:55 +0000
Message-ID: <5147c71d8cc4463db0c0188f96860a8f@EMEAWP-EXMB11.corp.brocade.com>
References:  <20170123.191727.2281365809408713783.mbj@tail-f.com>
In-Reply-To: <20170123.191727.2281365809408713783.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.252.48.7]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-23_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701230236
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Query about invalid XPATH paths in 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, 23 Jan 2017 18:34:32 -0000

Hi Martin,

Thanks for the confirmation.

Regards,

William

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: 23 January 2017 18:17
To: William Ivory 
Cc: netmod@ietf.org
Subject: Re: [netmod] Query about invalid XPATH paths in YANG

William Ivory  wrote:
> Hi,
> 
> I'd appreciate clarification on whether a YANG path in an XPATH 
> statement in a must or when statement must point to a valid YANG path 
> or not.  You might wonder why we'd have an invalid path (as opposed to 
> one that's simply not configured right now) but it is occasionally 
> helpful when sharing groupings.  (Possibly we should remodel the YANG 
> but that's another matter!).
> 
> As a simple example, is the following allowed?
> 
> Container foo {
>         Leaf bar {
>                 Type string;
>                 Must "not(../nonExistentSiblingNode)";
>         }
> }

Yes this is allowed.  Many YANG compilers give warnings for this kind of expression, but it is legal.

> I don't see that this should be any different to a must statement path 
> pointing to an unconfigured node, returning an empty nodeset in both 
> cases.
> 
> The reason I ask is that we are seeing a NETCONF client 
> differentiating between unconfigured (ok) and non-existent (error) 
> cases.  It would be useful to know one way or the other, ideally with 
> a pointer to the relevant part of the spec that makes this clear.

It follows from how XPath works, and the fact that there is no text in RFC 7950 (or 6020) that limits XPath to something non-standard.


/martin


From nobody Tue Jan 24 01:11: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 60F671294AC for ; Tue, 24 Jan 2017 01:11:38 -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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbt0shtQXw8k for ; Tue, 24 Jan 2017 01:11:36 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) by ietfa.amsl.com (Postfix) with ESMTP id C6B90129458 for ; Tue, 24 Jan 2017 01:11:36 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id C15EE6052B; Tue, 24 Jan 2017 10:11:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1485249094; bh=OZu0/L578YfYzwddgqJYZOjcBK3jSQVx3cUgkoOA6t4=; h=To:Date:Subject:From; b=dbETSAGdGgBHUHanM8H77MRk5MyZrhJPIe5bGyxYj1Bo2ej6nfSfL2Qcoraj5fx2e B+nJRpzFgHmZRPngnV/YnLJIIT1bIqt06FDTN826aYU/By+p5I7/bFp/aYS0VPbihl vIDktMMH2/Aw/1hDfD3yLK7GD6peXLUsr5TEhIKI=
Content-Type: text/plain; charset="utf-8"
To: "netmod" 
User-Agent: SOGoMail 2.3.19
MIME-Version: 1.0
Date: Tue, 24 Jan 2017 10:11:34 +0100
Message-ID: <79d3-58871a80-f-4410ef80@3855248>
X-Forward: 2001:67c:1220:80c:b56a:f165:17b6:8ac5
From: =?utf-8?q?Michal_Va=C5=A1ko?= 
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [netmod] augment target statements
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, 24 Jan 2017 09:11:38 -0000

Hi,
we have noticed that RFC 7950 page 120, when mentioning augment substat=
ements targeting container, list, case, input, output, and notification=
, skips "anydata" and "anyxml". Based on the next section 7.17.1. and t=
he grammar, it seems not intentional and we wanted to submit errata.

Also, in the same paragraph, the target notification is allowed and men=
tioned, but action not. Again, is that intentional or just an oversight=
? Thanks.

Kind regards,
Michal Vasko


From nobody Tue Jan 24 01:15: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 36F6812949A for ; Tue, 24 Jan 2017 01:15:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level: 
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 Yjq2wTQWJ1ct for ; Tue, 24 Jan 2017 01:15:20 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 CEEC0129458 for ; Tue, 24 Jan 2017 01:15:19 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 042EC72AC769F; Tue, 24 Jan 2017 09:15:16 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0O9FHcF011296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 09:15:17 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0O9ETlR004533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jan 2017 09:15:14 GMT
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 24 Jan 2017 10:14:55 +0100
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
Thread-Index: AQHSdWfAf/FYBL+YEEyl/cflFrMGvqFHUN8Q
Date: Tue, 24 Jan 2017 09:14:55 +0000
Message-ID: 
References: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.com> <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.mbj@tail-f.com>
In-Reply-To: <20170123.115841.723508035325803360.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_012D_01D2762A.B4BC77C0"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 09:15:22 -0000

------=_NextPart_000_012D_01D2762A.B4BC77C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

If I'm not mistaken, the following BBF addition was also proposed as to be
added to the IETF entity model.  Is there no consensus about this one?

1. Enabling a reset of an entity by means of an action

module bbf-entity-reset-action {
  yang-version 1.1;

  namespace "urn:broadband-forum-org:bbf-entity-reset-action";

  prefix "bbf-entity-reset-action";

  import ietf-entity {
    prefix ent;
  }
  ...

  identity reset-type {
    description
        "Type of reset requested of entity.  Examples of resets can be:
           hardware-reset, reset-with-selftest, reset-without-selftest,
           software-reset, possibly others.";
  }

  identity hardware-reset {
    base reset-type;
    description
        "Hardware reset";
  }

  augment "/ent:entity-state/ent:physical-entity" {
    description
        "Augment entity model with an action to request a reset of the
          entity";
    action reset {
      description "Request a reset of the entity";
      input {
        leaf reset-type {
          type identityref {
            base "reset-type";
          }
            description
                "Type of reset requested of entity";
        }
      }
    }
  }
}

Best regards - Vriendelijke groeten,
Bart Bogaert

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund
Sent: 23 January 2017 11:59
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I wonder when we use 'state' and when 'status' - is there a subtle 
> distinction or should be just consistently use lets say 'state', i.e., 
> changed to alalarm-status to alarm-state and standby-status to 
> standby-state?

The reason in this case is that we just used the MIB names.  This said, I
agree that "standby-state" and "alarm-state" are better.

BTW, RFC 4268, which defines the original objects, says:

   The terms "state" and "status" are used interchangeably in this memo.


> I also wonder about the mapping of the MIB object names to YANG leaf
> names:
> 
>    +-------------------------------------+-----------------------------+
>    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
>    | state/component/sensor-data         |                             |
>    +-------------------------------------+-----------------------------+
>    | data-type                           | entPhySensorType            |
>    | data-scale                          | entPhySensorScale           |
>    | precision                           | entPhySensorPrecision       |
>    | value                               | entPhySensorValue           |
>    | oper-status                         | entPhySensorOperStatus      |
>    | sensor-units-display                | entPhySensorUnitsDisplay    |
>    | value-timestamp                     | entPhySensorValueTimeStamp  |
>    | value-update-rate                   | entPhySensorValueUpdateRate |
>    
> +-------------------------------------+-----------------------------+
> 
> Is the 'data-' prefix needed? If so, why is the a prefix not used for 
> 'precision' (scale and precision really go hand in hand).

Unclear.  I think I'm the one to blame for this inconsistency, and it goes
back to the very first commit, but I can't remeber why.

> Why is it
> 'sensor-units-display' and not just 'units-display'? One option could
> be:
> 
>   value-type
>   value-scale
>   value-precision
>   value
>   oper-status
>   units-display
>   value-timestamp
>   value-update-rate

Yes this is better.

> RFC 3433 points out that entPhySensorType and entPhySensorScale and 
> entPhySensorPrecision SHOULD NOT change during operation. What about 
> the YANG objects? I actually do not know what the SHOULD buys a client 
> since you can't rely on it. To be robust, you have to fetch an n-tuple 
> anyway and be prepared that a sensor may have changed its properties.
> Should there be explicit text providing guidance that it is better to 
> fetch the whole n-tuple?

This is certainly the simplest solution.   Any comments?

> Or alternatively, if supporting caching of values is a goal, we may 
> need to provide a 'sensor-data/properties-last-changed' object that 
> allows to make caching of value properties robust.


/martin

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

------=_NextPart_000_012D_01D2762A.B4BC77C0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew
ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj
YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN
MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo
MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K
soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6
tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG
ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ
Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL
BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK
H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0
dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD
ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2
p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR
BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st
NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10
I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG
MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh
dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy
OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ
kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl
bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf
kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb
xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi
UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt
Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV
AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr
4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0
ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j
b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3
dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93
d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl
GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb
EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy
7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf
RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6
/XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq
hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu
dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD
Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1
MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0
QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw
mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y
HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0
QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o
lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj
V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG
AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG
AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB
gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI
hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9
1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB
TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl
MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp
ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z
ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB
BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl
MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl
cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF
BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB
BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi
Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs
Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA
do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX
EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR
qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB
hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT
8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1
Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTI0MDkxNDU0WjAjBgkqhkiG9w0B
CQQxFgQULlUlKarLxb0E/VoekJFEhCqGq4IwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQCG
n3DU0RzuQ6Ru9yUiWmFWjH+ahBZ2Kv0U97em7PivRpHG5kxWGBaqKZ149/37GyZa9A5Q9z8PW/Zi
SsndnaYug2mWFKbBBBysepX+0SspJ2J3m4NEMUtI5LMNRUIDzA2iBBB0P/2xBU0OROgoE4GzIEbR
aEU4ZAUGAVLsv1mcT57vtZXpnifXZOSztBTj7ZKeoexPgxd852a4s//7LpbmNV8keV/wyo9iwlz6
7czLwnpw43YFPUODWUegNytj92Zgl0ZVhj450wcYiMh5St/oSLmOANzzSgUWf1JdIXIRISgJyv1q
pdJ9mVRQ8ruZ0ACWQ6VVs3lEqePoaiUz+KaCAAAAAAAA

------=_NextPart_000_012D_01D2762A.B4BC77C0--


From nobody Tue Jan 24 01:22: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 55B671294C8 for ; Tue, 24 Jan 2017 01:22:46 -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 piv_OC8l_x4c for ; Tue, 24 Jan 2017 01:22:45 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D61FF1294B7 for ; Tue, 24 Jan 2017 01:22:44 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A7D81AE01AA; Tue, 24 Jan 2017 10:22:43 +0100 (CET)
Date: Tue, 24 Jan 2017 10:22:41 +0100 (CET)
Message-Id: <20170124.102241.529914951480970461.mbj@tail-f.com>
To: mvasko@cesnet.cz
From: Martin Bjorklund 
In-Reply-To: <79d3-58871a80-f-4410ef80@3855248>
References: <79d3-58871a80-f-4410ef80@3855248>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] augment target statements
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, 24 Jan 2017 09:22:46 -0000

Hi,

Michal Va=A8ko  wrote:
> Hi,
> we have noticed that RFC 7950 page 120, when mentioning augment
> substatements targeting container, list, case, input, output, and
> notification, skips "anydata" and "anyxml".

This is correct; the *target* of an "augment" cannot be "anydata" or
"anyxml".

> Based on the next section
> 7.17.1. and the grammar, it seems not intentional and we wanted to
> submit errata.

7.17.1 lists substatemets to the "augement" statement, i.e., valid
nodes to *add to* the target node.

> Also, in the same paragraph, the target notification is allowed and
> mentioned, but action not. Again, is that intentional or just an
> oversight? Thanks.

Intentional.  The target of an augment cannot be an "action" (or
"rpc").  Note that the target can be "input" or "output".  (And note
that the "input" and "output" nodes always exist as children to
rpc/action)


/martin


From nobody Tue Jan 24 01:28: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 A931512949A for ; Tue, 24 Jan 2017 01:28:18 -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 uia9FmUv-hWf for ; Tue, 24 Jan 2017 01:28:16 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AB37F1297C5 for ; Tue, 24 Jan 2017 01:28:03 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 35B851AE01AA; Tue, 24 Jan 2017 10:28:02 +0100 (CET)
Date: Tue, 24 Jan 2017 10:28:00 +0100 (CET)
Message-Id: <20170124.102800.608993362937407790.mbj@tail-f.com>
To: bart.bogaert@nokia.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.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: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 09:28:18 -0000

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi,
> 
> If I'm not mistaken, the following BBF addition was also proposed as to be
> added to the IETF entity model.  Is there no consensus about this one?

Not many spoke up.  I think there was just one comment, and that was
not in favor of adding this.



/martin


> 
> 1. Enabling a reset of an entity by means of an action
> 
> module bbf-entity-reset-action {
>   yang-version 1.1;
> 
>   namespace "urn:broadband-forum-org:bbf-entity-reset-action";
> 
>   prefix "bbf-entity-reset-action";
> 
>   import ietf-entity {
>     prefix ent;
>   }
>   ...
> 
>   identity reset-type {
>     description
>         "Type of reset requested of entity.  Examples of resets can be:
>            hardware-reset, reset-with-selftest, reset-without-selftest,
>            software-reset, possibly others.";
>   }
> 
>   identity hardware-reset {
>     base reset-type;
>     description
>         "Hardware reset";
>   }
> 
>   augment "/ent:entity-state/ent:physical-entity" {
>     description
>         "Augment entity model with an action to request a reset of the
>           entity";
>     action reset {
>       description "Request a reset of the entity";
>       input {
>         leaf reset-type {
>           type identityref {
>             base "reset-type";
>           }
>             description
>                 "Type of reset requested of entity";
>         }
>       }
>     }
>   }
> }
> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> 
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund
> Sent: 23 January 2017 11:59
> To: j.schoenwaelder@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> Juergen Schoenwaelder  wrote:
> > Hi,
> > 
> > I wonder when we use 'state' and when 'status' - is there a subtle 
> > distinction or should be just consistently use lets say 'state', i.e., 
> > changed to alalarm-status to alarm-state and standby-status to 
> > standby-state?
> 
> The reason in this case is that we just used the MIB names.  This said, I
> agree that "standby-state" and "alarm-state" are better.
> 
> BTW, RFC 4268, which defines the original objects, says:
> 
>    The terms "state" and "status" are used interchangeably in this memo.
> 
> 
> > I also wonder about the mapping of the MIB object names to YANG leaf
> > names:
> > 
> >    +-------------------------------------+-----------------------------+
> >    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
> >    | state/component/sensor-data         |                             |
> >    +-------------------------------------+-----------------------------+
> >    | data-type                           | entPhySensorType            |
> >    | data-scale                          | entPhySensorScale           |
> >    | precision                           | entPhySensorPrecision       |
> >    | value                               | entPhySensorValue           |
> >    | oper-status                         | entPhySensorOperStatus      |
> >    | sensor-units-display                | entPhySensorUnitsDisplay    |
> >    | value-timestamp                     | entPhySensorValueTimeStamp  |
> >    | value-update-rate                   | entPhySensorValueUpdateRate |
> >    
> > +-------------------------------------+-----------------------------+
> > 
> > Is the 'data-' prefix needed? If so, why is the a prefix not used for 
> > 'precision' (scale and precision really go hand in hand).
> 
> Unclear.  I think I'm the one to blame for this inconsistency, and it goes
> back to the very first commit, but I can't remeber why.
> 
> > Why is it
> > 'sensor-units-display' and not just 'units-display'? One option could
> > be:
> > 
> >   value-type
> >   value-scale
> >   value-precision
> >   value
> >   oper-status
> >   units-display
> >   value-timestamp
> >   value-update-rate
> 
> Yes this is better.
> 
> > RFC 3433 points out that entPhySensorType and entPhySensorScale and 
> > entPhySensorPrecision SHOULD NOT change during operation. What about 
> > the YANG objects? I actually do not know what the SHOULD buys a client 
> > since you can't rely on it. To be robust, you have to fetch an n-tuple 
> > anyway and be prepared that a sensor may have changed its properties.
> > Should there be explicit text providing guidance that it is better to 
> > fetch the whole n-tuple?
> 
> This is certainly the simplest solution.   Any comments?
> 
> > Or alternatively, if supporting caching of values is a goal, we may 
> > need to provide a 'sensor-data/properties-last-changed' object that 
> > allows to make caching of value properties robust.
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jan 24 01:48: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 0FFD71294B7 for ; Tue, 24 Jan 2017 01:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level: 
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 lVIim0w66yoc for ; Tue, 24 Jan 2017 01:48:09 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4A55612949A for ; Tue, 24 Jan 2017 01:48:09 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DC9B0D0FB0B3; Tue, 24 Jan 2017 09:48:04 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0O9m6IQ020846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 09:48:06 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0O9m0cD025381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jan 2017 09:48:04 GMT
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Tue, 24 Jan 2017 10:48:01 +0100
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
Thread-Index: AQHSdWfAf/FYBL+YEEyl/cflFrMGvqFHUN8Q///73ACAABOm0A==
Date: Tue, 24 Jan 2017 09:48:00 +0000
Message-ID: 
References: <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.mbj@tail-f.com>  <20170124.102800.608993362937407790.mbj@tail-f.com>
In-Reply-To: <20170124.102800.608993362937407790.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013F_01D2762F.53EAE850"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 09:48:12 -0000

------=_NextPart_000_013F_01D2762F.53EAE850
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: 24 January 2017 10:28
To: Bogaert, Bart (Nokia - BE) 
Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi,
> 
> If I'm not mistaken, the following BBF addition was also proposed as 
> to be added to the IETF entity model.  Is there no consensus about this
one?

Not many spoke up.  I think there was just one comment, and that was not in
favor of adding this.
[Bart Bogaert] Ok... don't these people require the need to offer an
explicit reset capability of a HW entity to operators?  I would expect that
this is something that could be made available generically (possibly under a
feature if not everybody wants to implement this) rather than having various
own implementations to achieve the same...

Bart

/martin


> 
> 1. Enabling a reset of an entity by means of an action
> 
> module bbf-entity-reset-action {
>   yang-version 1.1;
> 
>   namespace "urn:broadband-forum-org:bbf-entity-reset-action";
> 
>   prefix "bbf-entity-reset-action";
> 
>   import ietf-entity {
>     prefix ent;
>   }
>   ...
> 
>   identity reset-type {
>     description
>         "Type of reset requested of entity.  Examples of resets can be:
>            hardware-reset, reset-with-selftest, reset-without-selftest,
>            software-reset, possibly others.";
>   }
> 
>   identity hardware-reset {
>     base reset-type;
>     description
>         "Hardware reset";
>   }
> 
>   augment "/ent:entity-state/ent:physical-entity" {
>     description
>         "Augment entity model with an action to request a reset of the
>           entity";
>     action reset {
>       description "Request a reset of the entity";
>       input {
>         leaf reset-type {
>           type identityref {
>             base "reset-type";
>           }
>             description
>                 "Type of reset requested of entity";
>         }
>       }
>     }
>   }
> }
> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> 
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin 
> Bjorklund
> Sent: 23 January 2017 11:59
> To: j.schoenwaelder@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> Juergen Schoenwaelder  wrote:
> > Hi,
> > 
> > I wonder when we use 'state' and when 'status' - is there a subtle 
> > distinction or should be just consistently use lets say 'state', 
> > i.e., changed to alalarm-status to alarm-state and standby-status to 
> > standby-state?
> 
> The reason in this case is that we just used the MIB names.  This 
> said, I agree that "standby-state" and "alarm-state" are better.
> 
> BTW, RFC 4268, which defines the original objects, says:
> 
>    The terms "state" and "status" are used interchangeably in this memo.
> 
> 
> > I also wonder about the mapping of the MIB object names to YANG leaf
> > names:
> > 
> >    +-------------------------------------+-----------------------------+
> >    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
> >    | state/component/sensor-data         |                             |
> >    +-------------------------------------+-----------------------------+
> >    | data-type                           | entPhySensorType            |
> >    | data-scale                          | entPhySensorScale           |
> >    | precision                           | entPhySensorPrecision       |
> >    | value                               | entPhySensorValue           |
> >    | oper-status                         | entPhySensorOperStatus      |
> >    | sensor-units-display                | entPhySensorUnitsDisplay    |
> >    | value-timestamp                     | entPhySensorValueTimeStamp  |
> >    | value-update-rate                   | entPhySensorValueUpdateRate |
> >    
> > +-------------------------------------+-----------------------------+
> > 
> > Is the 'data-' prefix needed? If so, why is the a prefix not used 
> > for 'precision' (scale and precision really go hand in hand).
> 
> Unclear.  I think I'm the one to blame for this inconsistency, and it 
> goes back to the very first commit, but I can't remeber why.
> 
> > Why is it
> > 'sensor-units-display' and not just 'units-display'? One option 
> > could
> > be:
> > 
> >   value-type
> >   value-scale
> >   value-precision
> >   value
> >   oper-status
> >   units-display
> >   value-timestamp
> >   value-update-rate
> 
> Yes this is better.
> 
> > RFC 3433 points out that entPhySensorType and entPhySensorScale and 
> > entPhySensorPrecision SHOULD NOT change during operation. What about 
> > the YANG objects? I actually do not know what the SHOULD buys a 
> > client since you can't rely on it. To be robust, you have to fetch 
> > an n-tuple anyway and be prepared that a sensor may have changed its
properties.
> > Should there be explicit text providing guidance that it is better 
> > to fetch the whole n-tuple?
> 
> This is certainly the simplest solution.   Any comments?
> 
> > Or alternatively, if supporting caching of values is a goal, we may 
> > need to provide a 'sensor-data/properties-last-changed' object that 
> > allows to make caching of value properties robust.
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

------=_NextPart_000_013F_01D2762F.53EAE850
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew
ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj
YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN
MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo
MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K
soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6
tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG
ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ
Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL
BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK
H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0
dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD
ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2
p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR
BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st
NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10
I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG
MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh
dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy
OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ
kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl
bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf
kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb
xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi
UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt
Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV
AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr
4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0
ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j
b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3
dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93
d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl
GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb
EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy
7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf
RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6
/XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq
hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu
dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD
Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1
MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0
QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw
mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y
HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0
QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o
lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj
V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG
AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG
AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB
gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI
hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9
1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB
TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl
MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp
ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z
ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB
BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl
MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl
cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF
BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB
BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi
Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs
Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA
do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX
EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR
qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB
hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT
8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1
Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTI0MDk0NzU5WjAjBgkqhkiG9w0B
CQQxFgQUbH0wJmat6sQahwPPH4+S824yXFIwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBn
OE3aD5RSgaC4stpaK6EoYOWRBcf94A4FrY3PD5PMfiwKVKgcD+QDyjR9qlGvtK6bSKq65Fu3lKxb
2mn1019NSeg/U476gCr7KYkB3FF3BjpVUfBEfvi7wTzBwW41CpLXUdn4rmIVUDTAzt0nLWBWHHw+
qOfsV/QkvFV9dRNlgTvruaLRAVVEije1dRL4qbBlBdF7A8TiCSk3gAbfphciQcRpOrNHK6495NYX
iIUagczF4X2RT3wgq3TP+TF3JuHdCPjhl28lzsYeK6QFubyES2SufX6B67ewfWy/8VNFHov1kJmk
Vitb9LSFUiCqJuw5r2M7Z3bfDewRJAgp4vIMAAAAAAAA

------=_NextPart_000_013F_01D2762F.53EAE850--


From nobody Tue Jan 24 01:54:35 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 A9D7C129543 for ; Tue, 24 Jan 2017 01:54:34 -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 a8hze35ljdph for ; Tue, 24 Jan 2017 01:54:32 -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 71F1612949A for ; Tue, 24 Jan 2017 01:54:32 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F01EA787; Tue, 24 Jan 2017 10:54:30 +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 T2rXwP-mYUMT; Tue, 24 Jan 2017 10:54:28 +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, 24 Jan 2017 10:54:30 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28499200A8; Tue, 24 Jan 2017 10:54:30 +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 323t6vt-8rGq; Tue, 24 Jan 2017 10:54:29 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5084B200A7; Tue, 24 Jan 2017 10:54:29 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 397D83E48BBD; Tue, 24 Jan 2017 10:54:31 +0100 (CET)
Date: Tue, 24 Jan 2017 10:54:31 +0100
From: Juergen Schoenwaelder 
To: "Bogaert, Bart (Nokia - BE)" 
Message-ID: <20170124095431.GA35667@elstar.local>
Mail-Followup-To: "Bogaert, Bart (Nokia - BE)" , Martin Bjorklund , "netmod@ietf.org" 
References: <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.mbj@tail-f.com>  <20170124.102800.608993362937407790.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: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 09:54:34 -0000

Assuming that not all hardware components support the same set of
reset types (or resets at all), how do I find out which reset types I
can apply to a specific hardware component? Or is the idea to let the
management system do trial and error pushing of reset buttons?

/js

On Tue, Jan 24, 2017 at 09:48:00AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com] 
> Sent: 24 January 2017 10:28
> To: Bogaert, Bart (Nokia - BE) 
> Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Hi,
> > 
> > If I'm not mistaken, the following BBF addition was also proposed as 
> > to be added to the IETF entity model.  Is there no consensus about this
> one?
> 
> Not many spoke up.  I think there was just one comment, and that was not in
> favor of adding this.
> [Bart Bogaert] Ok... don't these people require the need to offer an
> explicit reset capability of a HW entity to operators?  I would expect that
> this is something that could be made available generically (possibly under a
> feature if not everybody wants to implement this) rather than having various
> own implementations to achieve the same...
> 
> Bart
> 
> /martin
> 
> 
> > 
> > 1. Enabling a reset of an entity by means of an action
> > 
> > module bbf-entity-reset-action {
> >   yang-version 1.1;
> > 
> >   namespace "urn:broadband-forum-org:bbf-entity-reset-action";
> > 
> >   prefix "bbf-entity-reset-action";
> > 
> >   import ietf-entity {
> >     prefix ent;
> >   }
> >   ...
> > 
> >   identity reset-type {
> >     description
> >         "Type of reset requested of entity.  Examples of resets can be:
> >            hardware-reset, reset-with-selftest, reset-without-selftest,
> >            software-reset, possibly others.";
> >   }
> > 
> >   identity hardware-reset {
> >     base reset-type;
> >     description
> >         "Hardware reset";
> >   }
> > 
> >   augment "/ent:entity-state/ent:physical-entity" {
> >     description
> >         "Augment entity model with an action to request a reset of the
> >           entity";
> >     action reset {
> >       description "Request a reset of the entity";
> >       input {
> >         leaf reset-type {
> >           type identityref {
> >             base "reset-type";
> >           }
> >             description
> >                 "Type of reset requested of entity";
> >         }
> >       }
> >     }
> >   }
> > }
> > 
> > Best regards - Vriendelijke groeten,
> > Bart Bogaert
> > 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin 
> > Bjorklund
> > Sent: 23 January 2017 11:59
> > To: j.schoenwaelder@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> > 
> > Juergen Schoenwaelder  wrote:
> > > Hi,
> > > 
> > > I wonder when we use 'state' and when 'status' - is there a subtle 
> > > distinction or should be just consistently use lets say 'state', 
> > > i.e., changed to alalarm-status to alarm-state and standby-status to 
> > > standby-state?
> > 
> > The reason in this case is that we just used the MIB names.  This 
> > said, I agree that "standby-state" and "alarm-state" are better.
> > 
> > BTW, RFC 4268, which defines the original objects, says:
> > 
> >    The terms "state" and "status" are used interchangeably in this memo.
> > 
> > 
> > > I also wonder about the mapping of the MIB object names to YANG leaf
> > > names:
> > > 
> > >    +-------------------------------------+-----------------------------+
> > >    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
> > >    | state/component/sensor-data         |                             |
> > >    +-------------------------------------+-----------------------------+
> > >    | data-type                           | entPhySensorType            |
> > >    | data-scale                          | entPhySensorScale           |
> > >    | precision                           | entPhySensorPrecision       |
> > >    | value                               | entPhySensorValue           |
> > >    | oper-status                         | entPhySensorOperStatus      |
> > >    | sensor-units-display                | entPhySensorUnitsDisplay    |
> > >    | value-timestamp                     | entPhySensorValueTimeStamp  |
> > >    | value-update-rate                   | entPhySensorValueUpdateRate |
> > >    
> > > +-------------------------------------+-----------------------------+
> > > 
> > > Is the 'data-' prefix needed? If so, why is the a prefix not used 
> > > for 'precision' (scale and precision really go hand in hand).
> > 
> > Unclear.  I think I'm the one to blame for this inconsistency, and it 
> > goes back to the very first commit, but I can't remeber why.
> > 
> > > Why is it
> > > 'sensor-units-display' and not just 'units-display'? One option 
> > > could
> > > be:
> > > 
> > >   value-type
> > >   value-scale
> > >   value-precision
> > >   value
> > >   oper-status
> > >   units-display
> > >   value-timestamp
> > >   value-update-rate
> > 
> > Yes this is better.
> > 
> > > RFC 3433 points out that entPhySensorType and entPhySensorScale and 
> > > entPhySensorPrecision SHOULD NOT change during operation. What about 
> > > the YANG objects? I actually do not know what the SHOULD buys a 
> > > client since you can't rely on it. To be robust, you have to fetch 
> > > an n-tuple anyway and be prepared that a sensor may have changed its
> properties.
> > > Should there be explicit text providing guidance that it is better 
> > > to fetch the whole n-tuple?
> > 
> > This is certainly the simplest solution.   Any comments?
> > 
> > > Or alternatively, if supporting caching of values is a goal, we may 
> > > need to provide a 'sensor-data/properties-last-changed' object that 
> > > allows to make caching of value properties robust.
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod



-- 
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 24 02:13: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 D2BD9129590 for ; Tue, 24 Jan 2017 02:13:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level: 
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 VEQO_6IixMzO for ; Tue, 24 Jan 2017 02:13:54 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B9860129587 for ; Tue, 24 Jan 2017 02:13:53 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C1CCADB9D6724; Tue, 24 Jan 2017 10:13:49 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0OADpx6028986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 10:13:51 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v0OADKcp000410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jan 2017 10:13:49 GMT
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Tue, 24 Jan 2017 11:13:46 +0100
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
Thread-Index: AQHSdWfAf/FYBL+YEEyl/cflFrMGvqFHaKsQ
Date: Tue, 24 Jan 2017 10:13:46 +0000
Message-ID: 
References: <148516226715.29498.6381011685248407321.idtracker@ietfa.amsl.com> <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.mbj@tail-f.com>
In-Reply-To: <20170123.115841.723508035325803360.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0160_01D27632.ED3BB040"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 10:13:56 -0000

------=_NextPart_000_0160_01D27632.ED3BB040
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

One more comment: 

The BBF proposal defines 'contained-in' as a leafref, the current version of
the hardware model has defined 'parent' as a string.  In the state container
parent is defined as a leafref.  Parent type should be the same in both
config and state container.

Best regards - Vriendelijke groeten,
Bart Bogaert
-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund
Sent: 23 January 2017 11:59
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I wonder when we use 'state' and when 'status' - is there a subtle 
> distinction or should be just consistently use lets say 'state', i.e., 
> changed to alalarm-status to alarm-state and standby-status to 
> standby-state?

The reason in this case is that we just used the MIB names.  This said, I
agree that "standby-state" and "alarm-state" are better.

BTW, RFC 4268, which defines the original objects, says:

   The terms "state" and "status" are used interchangeably in this memo.


> I also wonder about the mapping of the MIB object names to YANG leaf
> names:
> 
>    +-------------------------------------+-----------------------------+
>    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
>    | state/component/sensor-data         |                             |
>    +-------------------------------------+-----------------------------+
>    | data-type                           | entPhySensorType            |
>    | data-scale                          | entPhySensorScale           |
>    | precision                           | entPhySensorPrecision       |
>    | value                               | entPhySensorValue           |
>    | oper-status                         | entPhySensorOperStatus      |
>    | sensor-units-display                | entPhySensorUnitsDisplay    |
>    | value-timestamp                     | entPhySensorValueTimeStamp  |
>    | value-update-rate                   | entPhySensorValueUpdateRate |
>    
> +-------------------------------------+-----------------------------+
> 
> Is the 'data-' prefix needed? If so, why is the a prefix not used for 
> 'precision' (scale and precision really go hand in hand).

Unclear.  I think I'm the one to blame for this inconsistency, and it goes
back to the very first commit, but I can't remeber why.

> Why is it
> 'sensor-units-display' and not just 'units-display'? One option could
> be:
> 
>   value-type
>   value-scale
>   value-precision
>   value
>   oper-status
>   units-display
>   value-timestamp
>   value-update-rate

Yes this is better.

> RFC 3433 points out that entPhySensorType and entPhySensorScale and 
> entPhySensorPrecision SHOULD NOT change during operation. What about 
> the YANG objects? I actually do not know what the SHOULD buys a client 
> since you can't rely on it. To be robust, you have to fetch an n-tuple 
> anyway and be prepared that a sensor may have changed its properties.
> Should there be explicit text providing guidance that it is better to 
> fetch the whole n-tuple?

This is certainly the simplest solution.   Any comments?

> Or alternatively, if supporting caching of values is a goal, we may 
> need to provide a 'sensor-data/properties-last-changed' object that 
> allows to make caching of value properties robust.


/martin

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

------=_NextPart_000_0160_01D27632.ED3BB040
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew
ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj
YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN
MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo
MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K
soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6
tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG
ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ
Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL
BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK
H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0
dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD
ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2
p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR
BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st
NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10
I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG
MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh
dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy
OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ
kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl
bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf
kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb
xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi
UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt
Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV
AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr
4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0
ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j
b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3
dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93
d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl
GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb
EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy
7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf
RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6
/XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq
hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu
dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD
Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1
MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0
QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw
mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y
HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0
QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o
lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj
V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG
AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG
AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB
gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI
hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9
1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB
TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl
MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp
ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z
ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB
BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl
MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl
cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF
BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB
BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi
Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs
Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA
do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX
EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR
qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB
hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT
8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1
Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTI0MTAxMzQ0WjAjBgkqhkiG9w0B
CQQxFgQUlOnhj48nmjo7xt2nftpfg6P8CeswgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAF
j2v8Fji/zuSGW82hIn9co0GkgXtuBWvoUvSj7t65/6+sdVyfMeb/GEuaWs/PmB7DtJDfudnhOmTv
3f7d2ty18aaoRS34gBbcwaB6xzo9w1lDVJTetyZOPYfUxkK6Yb9p/w1B+glXtOCCK9dRI8vV35D9
vG+ydlSqhbDNUHu6bBmNKuAlY/o3ow6ilaDxDPDkbUgRT/U36R4LZMZ4h0uB92kobK7UEAxzxXK0
R832rvYC5jVym47ebXrGAQHPcrJT5IX1s3KUyfZu9XiY1Yx5/vi8q2EQBHma+X2qrq095bp5MHbQ
dMpAgtUEp5l79mAAkUFefsszV+dPFuTrXp2OAAAAAAAA

------=_NextPart_000_0160_01D27632.ED3BB040--


From nobody Tue Jan 24 02:29:09 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 894B9129586 for ; Tue, 24 Jan 2017 02:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level: 
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 JVDr4W1twiDr for ; Tue, 24 Jan 2017 02:29:05 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B955A12949E for ; Tue, 24 Jan 2017 02:29:04 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 627ECFAB4EABA; Tue, 24 Jan 2017 10:29:00 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0OAT2DZ001489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 10:29:02 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0OASjsx022060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jan 2017 10:28:58 GMT
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 24 Jan 2017 11:28:53 +0100
From: "Bogaert, Bart (Nokia - BE)" 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
Thread-Index: AQHSdWfAf/FYBL+YEEyl/cflFrMGvqFHUN8Q///73ACAABOm0P//88OAgAAZaeA=
Date: Tue, 24 Jan 2017 10:28:52 +0000
Message-ID: 
References: <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.mbj@tail-f.com>  <20170124.102800.608993362937407790.mbj@tail-f.com>  <20170124095431.GA35667@elstar.local>
In-Reply-To: <20170124095431.GA35667@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_016A_01D27635.09616DD0"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 10:29:07 -0000

------=_NextPart_000_016A_01D27635.09616DD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Juergen,

I've been discussing internally here after observing that the current action
definition has no output and hence it is not possible to report whether the
reset is supported for a specific hardware instance.  Further reflection is
required on this.

Best regards - Vriendelijke groeten,
Bart Bogaert
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Sent: 24 January 2017 10:55
To: Bogaert, Bart (Nokia - BE) 
Cc: Martin Bjorklund ; netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Assuming that not all hardware components support the same set of reset
types (or resets at all), how do I find out which reset types I can apply to
a specific hardware component? Or is the idea to let the management system
do trial and error pushing of reset buttons?

/js

On Tue, Jan 24, 2017 at 09:48:00AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 24 January 2017 10:28
> To: Bogaert, Bart (Nokia - BE) 
> Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Hi,
> > 
> > If I'm not mistaken, the following BBF addition was also proposed as 
> > to be added to the IETF entity model.  Is there no consensus about 
> > this
> one?
> 
> Not many spoke up.  I think there was just one comment, and that was 
> not in favor of adding this.
> [Bart Bogaert] Ok... don't these people require the need to offer an 
> explicit reset capability of a HW entity to operators?  I would expect 
> that this is something that could be made available generically 
> (possibly under a feature if not everybody wants to implement this) 
> rather than having various own implementations to achieve the same...
> 
> Bart
> 
> /martin
> 
> 
> > 
> > 1. Enabling a reset of an entity by means of an action
> > 
> > module bbf-entity-reset-action {
> >   yang-version 1.1;
> > 
> >   namespace "urn:broadband-forum-org:bbf-entity-reset-action";
> > 
> >   prefix "bbf-entity-reset-action";
> > 
> >   import ietf-entity {
> >     prefix ent;
> >   }
> >   ...
> > 
> >   identity reset-type {
> >     description
> >         "Type of reset requested of entity.  Examples of resets can be:
> >            hardware-reset, reset-with-selftest, reset-without-selftest,
> >            software-reset, possibly others.";
> >   }
> > 
> >   identity hardware-reset {
> >     base reset-type;
> >     description
> >         "Hardware reset";
> >   }
> > 
> >   augment "/ent:entity-state/ent:physical-entity" {
> >     description
> >         "Augment entity model with an action to request a reset of the
> >           entity";
> >     action reset {
> >       description "Request a reset of the entity";
> >       input {
> >         leaf reset-type {
> >           type identityref {
> >             base "reset-type";
> >           }
> >             description
> >                 "Type of reset requested of entity";
> >         }
> >       }
> >     }
> >   }
> > }
> > 
> > Best regards - Vriendelijke groeten, Bart Bogaert
> > 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin 
> > Bjorklund
> > Sent: 23 January 2017 11:59
> > To: j.schoenwaelder@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> > 
> > Juergen Schoenwaelder  wrote:
> > > Hi,
> > > 
> > > I wonder when we use 'state' and when 'status' - is there a subtle 
> > > distinction or should be just consistently use lets say 'state', 
> > > i.e., changed to alalarm-status to alarm-state and standby-status 
> > > to standby-state?
> > 
> > The reason in this case is that we just used the MIB names.  This 
> > said, I agree that "standby-state" and "alarm-state" are better.
> > 
> > BTW, RFC 4268, which defines the original objects, says:
> > 
> >    The terms "state" and "status" are used interchangeably in this memo.
> > 
> > 
> > > I also wonder about the mapping of the MIB object names to YANG 
> > > leaf
> > > names:
> > > 
> > >
+-------------------------------------+-----------------------------+
> > >    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object
|
> > >    | state/component/sensor-data         |
|
> > >
+-------------------------------------+-----------------------------+
> > >    | data-type                           | entPhySensorType
|
> > >    | data-scale                          | entPhySensorScale
|
> > >    | precision                           | entPhySensorPrecision
|
> > >    | value                               | entPhySensorValue
|
> > >    | oper-status                         | entPhySensorOperStatus
|
> > >    | sensor-units-display                | entPhySensorUnitsDisplay
|
> > >    | value-timestamp                     | entPhySensorValueTimeStamp
|
> > >    | value-update-rate                   | entPhySensorValueUpdateRate
|
> > >    
> > > +-------------------------------------+-----------------------------+
> > > 
> > > Is the 'data-' prefix needed? If so, why is the a prefix not used 
> > > for 'precision' (scale and precision really go hand in hand).
> > 
> > Unclear.  I think I'm the one to blame for this inconsistency, and 
> > it goes back to the very first commit, but I can't remeber why.
> > 
> > > Why is it
> > > 'sensor-units-display' and not just 'units-display'? One option 
> > > could
> > > be:
> > > 
> > >   value-type
> > >   value-scale
> > >   value-precision
> > >   value
> > >   oper-status
> > >   units-display
> > >   value-timestamp
> > >   value-update-rate
> > 
> > Yes this is better.
> > 
> > > RFC 3433 points out that entPhySensorType and entPhySensorScale 
> > > and entPhySensorPrecision SHOULD NOT change during operation. What 
> > > about the YANG objects? I actually do not know what the SHOULD 
> > > buys a client since you can't rely on it. To be robust, you have 
> > > to fetch an n-tuple anyway and be prepared that a sensor may have 
> > > changed its
> properties.
> > > Should there be explicit text providing guidance that it is better 
> > > to fetch the whole n-tuple?
> > 
> > This is certainly the simplest solution.   Any comments?
> > 
> > > Or alternatively, if supporting caching of values is a goal, we 
> > > may need to provide a 'sensor-data/properties-last-changed' object 
> > > that allows to make caching of value properties robust.
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod



-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         

------=_NextPart_000_016A_01D27635.09616DD0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew
ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj
YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN
MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo
MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K
soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6
tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG
ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ
Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL
BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK
H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0
dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD
ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2
p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR
BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st
NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10
I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG
MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh
dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy
OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ
kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl
bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf
kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb
xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi
UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt
Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV
AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr
4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0
ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j
b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3
dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93
d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl
GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb
EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy
7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf
RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6
/XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq
hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu
dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD
Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1
MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0
QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw
mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y
HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0
QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o
lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj
V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG
AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG
AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB
gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI
hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9
1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB
TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl
MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp
ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z
ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB
BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl
MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl
cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF
BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB
BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi
Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs
Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA
do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX
EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR
qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB
hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT
8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1
Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTI0MTAyODUwWjAjBgkqhkiG9w0B
CQQxFgQUW8Xg90lQLkzR50YqDFpt2Cnks5gwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBX
Kd4eTnAFND4HLBB1juMAW5Z6Rgfmkfk3of5uUjAldEVM9WZUbsrvbGf9cz0qNNt63q7AGrZbnnI6
6PaFCUQ7toqd+nUndYQM1ftaCQ3RCQEJQKT47BgwJ1dMLrGAj2yHgOGlTVEruDavW6m2KivdiG8q
+qqnzDMmHfV2kUva7x6mAW/6KTXdED364GBLH/GHpJxZHBfh8LrR8QvPUrATJWxo2dMy6OnRCQm1
RJ7RCzn5gIpz/9RsSWKxMP0M95xjPzVrnUD+ErLKgHS1+Mpaclk4SkL2jeODwb5MCixPZlyId/FJ
Scj1ohlVjy0RU+J548CY2jj1Uuvgf+QGAMxKAAAAAAAA

------=_NextPart_000_016A_01D27635.09616DD0--


From nobody Tue Jan 24 02:37:09 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 16D3612958E for ; Tue, 24 Jan 2017 02:37:09 -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 18OBHqAU7zK8 for ; Tue, 24 Jan 2017 02:37:07 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C448129583 for ; Tue, 24 Jan 2017 02:37:07 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id BB2601AE01AA; Tue, 24 Jan 2017 11:37:05 +0100 (CET)
Date: Tue, 24 Jan 2017 11:37:03 +0100 (CET)
Message-Id: <20170124.113703.2074026980970865406.mbj@tail-f.com>
To: bart.bogaert@nokia.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.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: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 10:37:09 -0000

"Bogaert, Bart (Nokia - BE)"  wrote:
> One more comment: 
> 
> The BBF proposal defines 'contained-in' as a leafref, the current version of
> the hardware model has defined 'parent' as a string.  In the state container
> parent is defined as a leafref.  Parent type should be the same in both
> config and state container.

The reason for the 'string' in the config tree is that when it is
pre-configured, it doesn't really refer to a component in the state
tree.  If it eventually matches a real component, the server will
instantiate an entry in the state tree, and at this point the parent
*is* a proper reference to another component.

Note that the underlying type is the same in both cases.


/martin


> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund
> Sent: 23 January 2017 11:59
> To: j.schoenwaelder@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> Juergen Schoenwaelder  wrote:
> > Hi,
> > 
> > I wonder when we use 'state' and when 'status' - is there a subtle 
> > distinction or should be just consistently use lets say 'state', i.e., 
> > changed to alalarm-status to alarm-state and standby-status to 
> > standby-state?
> 
> The reason in this case is that we just used the MIB names.  This said, I
> agree that "standby-state" and "alarm-state" are better.
> 
> BTW, RFC 4268, which defines the original objects, says:
> 
>    The terms "state" and "status" are used interchangeably in this memo.
> 
> 
> > I also wonder about the mapping of the MIB object names to YANG leaf
> > names:
> > 
> >    +-------------------------------------+-----------------------------+
> >    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
> >    | state/component/sensor-data         |                             |
> >    +-------------------------------------+-----------------------------+
> >    | data-type                           | entPhySensorType            |
> >    | data-scale                          | entPhySensorScale           |
> >    | precision                           | entPhySensorPrecision       |
> >    | value                               | entPhySensorValue           |
> >    | oper-status                         | entPhySensorOperStatus      |
> >    | sensor-units-display                | entPhySensorUnitsDisplay    |
> >    | value-timestamp                     | entPhySensorValueTimeStamp  |
> >    | value-update-rate                   | entPhySensorValueUpdateRate |
> >    
> > +-------------------------------------+-----------------------------+
> > 
> > Is the 'data-' prefix needed? If so, why is the a prefix not used for 
> > 'precision' (scale and precision really go hand in hand).
> 
> Unclear.  I think I'm the one to blame for this inconsistency, and it goes
> back to the very first commit, but I can't remeber why.
> 
> > Why is it
> > 'sensor-units-display' and not just 'units-display'? One option could
> > be:
> > 
> >   value-type
> >   value-scale
> >   value-precision
> >   value
> >   oper-status
> >   units-display
> >   value-timestamp
> >   value-update-rate
> 
> Yes this is better.
> 
> > RFC 3433 points out that entPhySensorType and entPhySensorScale and 
> > entPhySensorPrecision SHOULD NOT change during operation. What about 
> > the YANG objects? I actually do not know what the SHOULD buys a client 
> > since you can't rely on it. To be robust, you have to fetch an n-tuple 
> > anyway and be prepared that a sensor may have changed its properties.
> > Should there be explicit text providing guidance that it is better to 
> > fetch the whole n-tuple?
> 
> This is certainly the simplest solution.   Any comments?
> 
> > Or alternatively, if supporting caching of values is a goal, we may 
> > need to provide a 'sensor-data/properties-last-changed' object that 
> > allows to make caching of value properties robust.
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jan 24 02:41: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 7393C129581 for ; Tue, 24 Jan 2017 02:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level: 
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 lNb5KfQRSRK4 for ; Tue, 24 Jan 2017 02:40:57 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2E54912949E for ; Tue, 24 Jan 2017 02:40:57 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 2C2E06FE2CA4E; Tue, 24 Jan 2017 10:40:53 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0OAesO4005349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 10:40:55 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0OAeTmc029281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jan 2017 10:40:51 GMT
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 24 Jan 2017 11:40:47 +0100
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
Thread-Index: AQHSdWfAf/FYBL+YEEyl/cflFrMGvqFHaKsQ///3W4CAABFAAA==
Date: Tue, 24 Jan 2017 10:40:47 +0000
Message-ID: 
References: <20170123094232.GC29022@elstar.local> <20170123.115841.723508035325803360.mbj@tail-f.com>  <20170124.113703.2074026980970865406.mbj@tail-f.com>
In-Reply-To: <20170124.113703.2074026980970865406.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0188_01D27636.B39391B0"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
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, 24 Jan 2017 10:40:59 -0000

------=_NextPart_000_0188_01D27636.B39391B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: 24 January 2017 11:37
To: Bogaert, Bart (Nokia - BE) 
Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

"Bogaert, Bart (Nokia - BE)"  wrote:
> One more comment: 
> 
> The BBF proposal defines 'contained-in' as a leafref, the current 
> version of the hardware model has defined 'parent' as a string.  In 
> the state container parent is defined as a leafref.  Parent type 
> should be the same in both config and state container.

The reason for the 'string' in the config tree is that when it is
pre-configured, it doesn't really refer to a component in the state tree.
If it eventually matches a real component, the server will instantiate an
entry in the state tree, and at this point the parent
*is* a proper reference to another component.

Note that the underlying type is the same in both cases.
[Bart Bogaert] Having it as leafref allows to verify that the parent being
configured is actually existing in the entity model (or defined in the same
transaction).  Why would we remove the modelling capability to check this
consistency?

Bart


/martin


> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin 
> Bjorklund
> Sent: 23 January 2017 11:59
> To: j.schoenwaelder@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> Juergen Schoenwaelder  wrote:
> > Hi,
> > 
> > I wonder when we use 'state' and when 'status' - is there a subtle 
> > distinction or should be just consistently use lets say 'state', 
> > i.e., changed to alalarm-status to alarm-state and standby-status to 
> > standby-state?
> 
> The reason in this case is that we just used the MIB names.  This 
> said, I agree that "standby-state" and "alarm-state" are better.
> 
> BTW, RFC 4268, which defines the original objects, says:
> 
>    The terms "state" and "status" are used interchangeably in this memo.
> 
> 
> > I also wonder about the mapping of the MIB object names to YANG leaf
> > names:
> > 
> >    +-------------------------------------+-----------------------------+
> >    | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
> >    | state/component/sensor-data         |                             |
> >    +-------------------------------------+-----------------------------+
> >    | data-type                           | entPhySensorType            |
> >    | data-scale                          | entPhySensorScale           |
> >    | precision                           | entPhySensorPrecision       |
> >    | value                               | entPhySensorValue           |
> >    | oper-status                         | entPhySensorOperStatus      |
> >    | sensor-units-display                | entPhySensorUnitsDisplay    |
> >    | value-timestamp                     | entPhySensorValueTimeStamp  |
> >    | value-update-rate                   | entPhySensorValueUpdateRate |
> >    
> > +-------------------------------------+-----------------------------+
> > 
> > Is the 'data-' prefix needed? If so, why is the a prefix not used 
> > for 'precision' (scale and precision really go hand in hand).
> 
> Unclear.  I think I'm the one to blame for this inconsistency, and it 
> goes back to the very first commit, but I can't remeber why.
> 
> > Why is it
> > 'sensor-units-display' and not just 'units-display'? One option 
> > could
> > be:
> > 
> >   value-type
> >   value-scale
> >   value-precision
> >   value
> >   oper-status
> >   units-display
> >   value-timestamp
> >   value-update-rate
> 
> Yes this is better.
> 
> > RFC 3433 points out that entPhySensorType and entPhySensorScale and 
> > entPhySensorPrecision SHOULD NOT change during operation. What about 
> > the YANG objects? I actually do not know what the SHOULD buys a 
> > client since you can't rely on it. To be robust, you have to fetch 
> > an n-tuple anyway and be prepared that a sensor may have changed its
properties.
> > Should there be explicit text providing guidance that it is better 
> > to fetch the whole n-tuple?
> 
> This is certainly the simplest solution.   Any comments?
> 
> > Or alternatively, if supporting caching of values is a goal, we may 
> > need to provide a 'sensor-data/properties-last-changed' object that 
> > allows to make caching of value properties robust.
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

------=_NextPart_000_0188_01D27636.B39391B0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew
ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj
YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN
MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo
MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K
soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6
tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG
ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ
Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL
BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK
H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0
dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD
ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2
p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR
BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st
NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10
I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG
MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh
dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy
OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ
kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl
bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf
kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb
xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi
UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt
Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV
AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr
4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0
ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j
b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3
dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93
d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl
GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb
EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy
7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf
RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6
/XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq
hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu
dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD
Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1
MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0
QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw
mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y
HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0
QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o
lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj
V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG
AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG
AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB
gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI
hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9
1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB
TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl
MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp
ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z
ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB
BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl
MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl
cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF
BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB
BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi
Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs
Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA
do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX
EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR
qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB
hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT
8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1
Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTI0MTA0MDQ2WjAjBgkqhkiG9w0B
CQQxFgQUdlKNgk9aJ1mVvoD+HVjs5Dy2J1QwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQCG
5rEYqRBHS3/r9tbboAz08IkNMLUbL4osXP5B1jEg2BZEKpMCT2NbumaM54aIZQ+JhT9Eh/o5Yw0U
S+ph/Ys0YKPCFXZNkGqh5YB6A9hh2/sFilHIXhlYDyukcD9dNyjhmidRH2bf0fYY11MssUgi4qDx
+Ornrh+RIxoPt4FR0d08BvHSRsuu/DYsaA6syHVCgkttVB8GjTbV6XqqA8b2FCKdmxEt7IIxobR0
4r+tguO/xjUKyWdMuKm/h/gi63cGnBX1h6wFqgGWVVYmGKLy7IznYiMFHWbyhIljY7gekJlyC0JP
oz0F4Fe8HtdApnLjPz156tKq0hTktZpdnnI6AAAAAAAA

------=_NextPart_000_0188_01D27636.B39391B0--


From nobody Tue Jan 24 03:04:47 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 05823129591 for ; Tue, 24 Jan 2017 03:04:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level: 
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnr3JMKgRWo5 for ; Tue, 24 Jan 2017 03:04:44 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) by ietfa.amsl.com (Postfix) with ESMTP id E9C95129581 for ; Tue, 24 Jan 2017 03:04:42 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 00BBE6052B; Tue, 24 Jan 2017 12:04:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1485255880; bh=ZWqjMFOCSOflUYvUB77aKuCTAjWYUToVSjwtn/A8MRc=; h=In-Reply-To:From:Date:Cc:To:Subject; b=v3cH6LtnR+6GyNYDzAFXYvZQ4xfchWQ0VFuMQwutXHUU0BydeZzQt/djCkgeu0xiR Ae5o3rFwsU5bW05SH0aAV+ibju6gxD+q/50OER8nZ3kpnPOgi4+3rvNsw3cL/Z+Xk9 Iz1KBzvR58e/MprCF0+kG3MWTdiS4ApspTV8i1w0=
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <20170124.102241.529914951480970461.mbj@tail-f.com>
From: =?utf-8?q?Michal_Va=C5=A1ko?= 
X-Forward: 2001:67c:1220:80c:b56a:f165:17b6:8ac5
Date: Tue, 24 Jan 2017 12:04:39 +0100
To: "Martin Bjorklund" 
MIME-Version: 1.0
Message-ID: <641-58873500-cf-65604a80@63863935>
User-Agent: SOGoMail 2.3.19
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__augment_target_state?= =?utf-8?q?ments?=
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, 24 Jan 2017 11:04:46 -0000

 
 
 
On Tuesday, January 24, 2017 10:22 CET, Martin Bjorklund  wrote: 
 
> Hi,
> 
> Michal Va=C5=A1ko  wrote:
> > Hi,
> > we have noticed that RFC 7950 page 120, when mentioning augment
> > substatements targeting container, list, case, input, output, and
> > notification, skips "anydata" and "anyxml".
> 
> This is correct; the *target* of an "augment" cannot be "anydata" or=

> "anyxml".

Okay, I was ambiguous and actually wanted to ask, whether "anydata" or =
"anyxml" can be a substatement of an augment targeting container, list,=
 case, input, output, or notification. If not, then I wonder why.

> > Based on the next section
> > 7.17.1. and the grammar, it seems not intentional and we wanted to=

> > submit errata.
> 
> 7.17.1 lists substatemets to the "augement" statement, i.e., valid
> nodes to *add to* the target node.
> 
> > Also, in the same paragraph, the target notification is allowed and=

> > mentioned, but action not. Again, is that intentional or just an
> > oversight? Thanks.
> 
> Intentional.  The target of an augment cannot be an "action" (or
> "rpc").  Note that the target can be "input" or "output".  (And note=

> that the "input" and "output" nodes always exist as children to
> rpc/action)
 
Right, of course.

Regards,
Michal Vasko


From nobody Tue Jan 24 04:26: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 A792F129581 for ; Tue, 24 Jan 2017 04:26: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 IY0yEWRT1p-X for ; Tue, 24 Jan 2017 04:26:01 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 866EB1294BA for ; Tue, 24 Jan 2017 04:26:01 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 1204D1AE01AA; Tue, 24 Jan 2017 13:25:59 +0100 (CET)
Date: Tue, 24 Jan 2017 13:25:57 +0100 (CET)
Message-Id: <20170124.132557.1147018497133778489.mbj@tail-f.com>
To: mvasko@cesnet.cz
From: Martin Bjorklund 
In-Reply-To: <641-58873500-cf-65604a80@63863935>
References: <20170124.102241.529914951480970461.mbj@tail-f.com> <641-58873500-cf-65604a80@63863935>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] augment target statements
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, 24 Jan 2017 12:26:02 -0000

Michal Va=A8ko  wrote:
>  =

>  =

>  =

> On Tuesday, January 24, 2017 10:22 CET, Martin Bjorklund
>  wrote:
>  =

> > Hi,
> > =

> > Michal Va=A8ko  wrote:
> > > Hi,
> > > we have noticed that RFC 7950 page 120, when mentioning augment
> > > substatements targeting container, list, case, input, output, and=

> > > notification, skips "anydata" and "anyxml".
> > =

> > This is correct; the *target* of an "augment" cannot be "anydata" o=
r=0D
> > "anyxml".
> =

> Okay, I was ambiguous and actually wanted to ask, whether "anydata" o=
r
> "anyxml" can be a substatement of an augment targeting container,
> list, case, input, output, or notification. If not, then I wonder why=
.=


Aha.  So you really wanted to ask about:

OLD:

   If the target node is a container, list, case, input, output, or
   notification node, the "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used within the "augment"
   statement.

NEW:

   If the target node is a container, list, case, input, output, or
   notification node, the "anydata", "anyxml", "container", "leaf",
   "list", "leaf-list", "uses", and "choice" statements can be used
   within the "augment" statement.


Yes, this is a bug in the spec.


/martin




> =

> > > Based on the next section
> > > 7.17.1. and the grammar, it seems not intentional and we wanted t=
o=0D
> > > submit errata.
> > =

> > 7.17.1 lists substatemets to the "augement" statement, i.e., valid
> > nodes to *add to* the target node.
> > =

> > > Also, in the same paragraph, the target notification is allowed a=
nd
> > > mentioned, but action not. Again, is that intentional or just an
> > > oversight? Thanks.
> > =

> > Intentional.  The target of an augment cannot be an "action" (or
> > "rpc").  Note that the target can be "input" or "output".  (And not=
e=0D
> > that the "input" and "output" nodes always exist as children to
> > rpc/action)
>  =

> Right, of course.
> =

> Regards,
> Michal Vasko
> =


From nobody Tue Jan 24 04:47: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 437431295DB for ; Tue, 24 Jan 2017 04:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level: 
X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZprNske9AiR for ; Tue, 24 Jan 2017 04:47:17 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B65B1295D9 for ; Tue, 24 Jan 2017 04:47:17 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 6A187B8011E; Tue, 24 Jan 2017 04:47:16 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170124124716.6A187B8011E@rfc-editor.org>
Date: Tue, 24 Jan 2017 04:47:16 -0800 (PST)
Archived-At: 
Cc: netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC7950 (4916)
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, 24 Jan 2017 12:47:18 -0000

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7950&eid=4916

--------------------------------------
Type: Technical
Reported by: Michal Vasko 

Section: 7.17.

Original Text
-------------
If the target node is a container, list, case, input, output, or
notification node, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used within the "augment"
statement.

Corrected Text
--------------
If the target node is a container, list, case, input, output, or
notification node, the "anydata", "anyxml", "container", "leaf",
"list", "leaf-list", "uses", and "choice" statements can be used
within the "augment" statement.

Notes
-----
It was forgotten to mention "anydata" and "anyxml" as valid substatements in this case.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Jan 24 11:05: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 066F5129653 for ; Tue, 24 Jan 2017 11:05:17 -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 nRzQg4fnYyOV for ; Tue, 24 Jan 2017 11:05:15 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0138.outbound.protection.outlook.com [104.47.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5667129650 for ; Tue, 24 Jan 2017 11:05:14 -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=oUSaT36g024wqpsc1sjaIzYzLMn4sTHkz3U7ehEThsQ=; b=hX8acZJ/okMdaf0Cj+ir8oMcADUXOtUZg1VC7DP5lX1zWty8MPa20UxqToETaQ5MUYV6n7aooBfWapZD6JAgXDaa/FqBLNhYAkCXUSPzvI2CqgpA1rp36Dzg1b26uz5yKTl7IrDJNrGcNMggzrjKzJSZGlyXhFt9Akax7FV+gfw=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 24 Jan 2017 19:05:10 +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.0874.012; Tue, 24 Jan 2017 19:05:10 +0000
From: Kent Watsen 
To: Benoit Claise , Andy Bierman 
Thread-Topic: [netmod] example modules in 6087bis
Thread-Index: AQHScA/x1/KtZni970SPgZ3dihSO36E+fAMAgAANVYCAB9faAIABVGyA
Date: Tue, 24 Jan 2017 19:05:10 +0000
Message-ID: <093ED4A3-081D-418A-B233-E75148133635@juniper.net>
References: <20170116.164803.729427888661667991.mbj@tail-f.com>   <003354d9-841f-37b2-a594-6e9983110984@cisco.com>
In-Reply-To: <003354d9-841f-37b2-a594-6e9983110984@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1e.0.170107
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 562be236-7091-4047-5002-08d4448beb87
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1443; 
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:rfTMEKyFljKi7k7/UV7qchnW4inKgf5tcHoc/vOd1Z+nKNv2Zi73UNuw0thcdHJCGkwLtRXwWIFJ7XfkPAhaRG2RMuKOAZKMv6JGHSuP+W/5GXc5d6GQaH6KZBYAaew3ZTNzthwVQgrtyEYrXuc7JW0t7TGnUcDt9a1I3VTBuWjFzsT8cFlPUbmW/rTs7Ye0G1xHF3aPNK8AXo/MW5n4aY6DSO26d1YittaRgvTujHEQiY4vsZRV9PltZIEmDougXxNCgxkdpfBGAbeBGZfod4jt6xCjg/zO3vOjWXoueugZZUlyQwKp3vuxjU8Nk/PP+0skWZhsE+g1gi5a14IrFQMROJOL8LzG6iKH8ZzFWdDhtgHg1DOEefHZIoMVRTGsYvqG0/0h6YYzvoBTzElHMVTRFbPSvd7tXaEZMJfvztdjuG1O+3iE+R3VDOSGyfSGr3WGcflim7QSnE9RT+UcTQ==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; 
x-forefront-prvs: 0197AFBD92
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(199003)(189002)(158454003)(54356999)(6512007)(76176999)(6306002)(82746002)(2950100002)(83506001)(99286003)(86362001)(92566002)(97736004)(5001770100001)(2900100001)(15395725005)(106356001)(68736007)(53936002)(122556002)(101416001)(4001350100001)(6436002)(105586002)(25786008)(6506006)(106116001)(229853002)(38730400001)(36756003)(77096006)(6486002)(93886004)(5660300001)(50986999)(83716003)(1720100001)(8936002)(189998001)(3660700001)(6116002)(3846002)(102836003)(4326007)(81156014)(8676002)(3280700002)(81166006)(2906002)(305945005)(7736002)(66066001)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; 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: <51DB0E9ABC939542B00ECC87767B612C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2017 19:05:10.6687 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] example modules in 6087bis
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, 24 Jan 2017 19:05:17 -0000

SGkgQW5keSwNCg0KSSB0aGluayB0aGlzIGRpc2N1c3Npb24gaGFzIGNvbWUgdG8gYSBoZWFkLiAg
UGxlYXNlIHN1Ym1pdCBhbiB1cGRhdGVkIDYwODdiaXMgYXMgc29vbiBhcyB5b3UgY2FuLiAgU29t
ZSBjb21tZW50czoNCg0KDQoxKSBvbiB0aGUgM3JkIGxpbmUgYmVsb3csIHNob3VsZCB0aGUgdGV4
dCBjbGFyaWZ5IHRoYXQgLS1pZXRmIGlzIG9ubHkgZm9yIElFVEYgbW9kdWxlcz8gIEFsc28sIGhv
dyBkb2VzIHRoZSBNVVNUIGhlcmUgaml2ZSB3aXRoIHRoZSBTSE9VTEQgaW4gU2VjdGlvbiA0LjEw
Pw0KDQogICAtIE1VU1QgdXNlIENPREUgQkVHSU5TIGZvciBhIHJlYWwgbW9kdWxlDQogICAtIE1V
U1QgTk9UIHVzZSBDT0RFIEJFR0lOUyBmb3IgYW4gZXhhbXBsZSBtb2R1bGUNCiAgIC0gTVVTVCBw
YXNzIHB5YW5nIC0taWV0ZiBmb3IgYSByZWFsIG1vZHVsZQ0KICAgLSBNVVNUIHBhc3MgcHlhbmcg
Zm9yIGV4YW1wbGUgbW9kdWxlDQoNCg0KMikgcmVsYXRlZCB0byAjMSwgU2VjdGlvbiA1IHNheXMg
IkluIGdlbmVyYWwsIG1vZHVsZXMgaW4gSUVURiBTdGFuZGFyZHMgVHJhY2sgc3BlY2lmaWNhdGlv
bnMgTVVTVCBjb21wbHkgd2l0aCBhbGwgc3ludGFjdGljIGFuZCBzZW1hbnRpYyByZXF1aXJlbWVu
dHMgb2YgWUFORyBbUkZDNzk1MF0uIg0KDQogICBGaXJzdCwgd2hhdCBkb2VzICJJbiBnZW5lcmFs
Li4uTVVTVCIgbWVhbj8gIC0gbWF5YmUgdGhlIA0KICAgc2VudGVuY2Ugc2hvdWxkIHN0YXJ0IHdp
dGggIk1vZHVsZXMgaW4gSUVURi4uLiI/DQoNCiAgIFNlY29uZCwgY2FuIHdlIGFkZCBhIHN0YXRl
bWVudCBmb3Igbm9uLUlFVEYgU0RPcyB0aGF0IG1pZ2h0DQogICBoYXZlIG90aGVyIGNvbnZlbnRp
b25zL3Jlc3RyaWN0aW9ucz8gIFdvdWxkIHdlIHJlY29tbWVuZA0KICAgLS1zdHJpY3QgZm9yIHN0
YXJ0ZXJzLCB1bnRpbCB0aGV5IGNhbiBhZGQgYW4gU0RPLXNwZWNpZmljDQogICBmbGFnIChlLmcu
LCAtLTxzZG8+KSB0byBweWFuZz8NCg0KDQozKSBUaGUgZmlyc3QgcGFyYWdyYXBoIGluIFNlY3Rp
b24gNC42IGlzbid0IGNsZWFyLCBob3cgYWJvdXQgdGhpcz8NCg0KIE9MRA0KICAgVGhpcyBzZWN0
aW9uIGNvbnRhaW5zIHRoZSBtb2R1bGUocykgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbi4N
CiAgIFRoZXNlIG1vZHVsZXMgU0hPVUxEIGJlIHdyaXR0ZW4gdXNpbmcgdGhlIFlBTkcgc3ludGF4
IGRlZmluZWQgaW4NCiAgIFtSRkM3OTUwXS4gIFlBTkcgMS4wIFtSRkM2MDIwXSBNQVkgYmUgdXNl
ZCBpZiBubyBZQU5HIDEuMSBjb25zdHJ1Y3RzDQogICBvciBzZW1hbnRpY3MgYXJlIG5lZWRlZCBp
biB0aGUgbW9kdWxlLg0KDQogTkVXDQogICBUaGlzIHNlY3Rpb24gY29udGFpbnMgdGhlIG1vZHVs
ZShzKSBkZWZpbmVkIGJ5IHRoZSBZQU5HIHNwZWNpZmljYXRpb24uDQogICBUaGVzZSBtb2R1bGVz
IFNIT1VMRCBiZSB3cml0dGVuIHVzaW5nIHRoZSBZQU5HIDEuMSBbUkZDNzk1MF0gc3ludGF4Ow0K
ICAgWUFORyAxLjAgW1JGQzYwMjBdIHN5bnRheCBNQVkgYmUgdXNlZCBpZiBubyBZQU5HIDEuMSBj
b25zdHJ1Y3RzDQogICBvciBzZW1hbnRpY3MgYXJlIG5lZWRlZCBpbiB0aGUgbW9kdWxlLg0KDQog
Tm90ZTogdGhpcyByZWFkcyBiZXR0ZXIsIGJ1dCBJIHdvbmRlciwgc2luY2UgWUFORyAxLjAgc3lu
dGF4IGlzIGENCiBzdWJzZXQgb2YgWUFORyAxLjEgc3ludGF4LCB3aGF0IGlzIHJlYWxseSBiZWlu
ZyBzYWlkIGhlcmU/IC0gdGhhdA0KIHlhbmctdmVyc2lvbiBzdGF0ZW1lbnQgaXMgb3B0aW9uYWw/
ICBPciBtYXliZSwgaW5zdGVhZCBvZiBmb2N1c2luZw0KIG9uIHN5bnRheCwgdGhlIHN0YXRlbWVu
dCBzaG91bGQgcmVnYXJkIHRoZSB2ZXJzaW9uIG9mIFlBTkcgdXNlZD8NCg0KDQo0KSBMYXN0bHks
IHBpY2tpbmcgdXAgb24gdGhpcyBkaXNjdXNzaW9uOg0KDQogICAgIGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTcyNzcuaHRtbC4NCg0KICAg
Y2FuIGFkZCBhbiBJbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSB0byBSRkMgNDE1MSBpbiBTZWN0aW9u
IDUuOT8NCiAgIE1heWJlIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoNCiBPTEQNCg0KICAgVGhlIGZv
bGxvd2luZyBleGFtcGxlcyBhcmUgZm9yIG5vbi1TdGFuZGFyZHMtVHJhY2sgbW9kdWxlcy4gIFRo
ZQ0KICAgZG9tYWluICJleGFtcGxlLmNvbSIgU0hPVUxEIGJlIHVzZWQgaW4gYWxsIG5hbWVzcGFj
ZSBVUklzIGZvciBleGFtcGxlDQogICBtb2R1bGVzLg0KDQogICAgICAgaHR0cDovL2V4YW1wbGUu
Y29tL25zL2V4YW1wbGUtaW50ZXJmYWNlcw0KDQogICAgICAgaHR0cDovL2V4YW1wbGUuY29tL25z
L2V4YW1wbGUtc3lzdGVtDQoNCiBORVcNCg0KICAgVGhlIGZvbGxvd2luZyBVUklzIGV4ZW1wbGlm
eSB3aGF0IG1pZ2h0IGJlIHVzZWQgYnkgbm9uIFN0YW5kYXJkcw0KICAgVHJhY2sgbW9kdWxlcy4g
IE5vdGUgdGhhdCB0aGUgZG9tYWluICJleGFtcGxlLmNvbSIgU0hPVUxEIGJlIHVzZWQNCiAgIGJ5
IGV4YW1wbGUgbW9kdWxlcyBpbiBJRVRGIGRyYWZ0cy4NCg0KICAgRXhhbXBsZSBVUklzIHVzaW5n
IFVSTHMgcGVyIFJGQyAzOTg2IFtSRkMzOTg2XToNCg0KICAgICAgIGh0dHA6Ly9leGFtcGxlLmNv
bS9ucy9leGFtcGxlLWludGVyZmFjZXMNCiAgICAgICBodHRwOi8vZXhhbXBsZS5jb20vbnMvZXhh
bXBsZS1zeXN0ZW0NCg0KICAgRXhhbXBsZSBVUklzIHVzaW5nIHRhZ3MgcGVyIFJGQyA0MTUxIFtS
RkM0MTUxXToNCiANCiAgICAgICB0YWc6ZXhhbXBsZS5jb20sMjAxNzpleGFtcGxlLWludGVyZmFj
ZXMNCiAgICAgICB0YWc6ZXhhbXBsZS5jb20sMjAxNzpleGFtcGxlLXN5c3RlbQ0KDQoNCg0KVGhh
bmtzLA0KS2VudCAgICAvLyBhcyBzaGVwaGVyZA0KDQoNCg0K


From nobody Tue Jan 24 11:26:35 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 D9735129675 for ; Tue, 24 Jan 2017 11:26:33 -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 eSBlTfbx4yb9 for ; Tue, 24 Jan 2017 11:26:32 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 33DD9129671 for ; Tue, 24 Jan 2017 11:26:32 -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 67FF61AE0402; Tue, 24 Jan 2017 20:26:30 +0100 (CET)
Date: Tue, 24 Jan 2017 20:26:30 +0100 (CET)
Message-Id: <20170124.202630.843995888894291234.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: <093ED4A3-081D-418A-B233-E75148133635@juniper.net>
References:  <003354d9-841f-37b2-a594-6e9983110984@cisco.com> <093ED4A3-081D-418A-B233-E75148133635@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=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] example modules in 6087bis
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, 24 Jan 2017 19:26:34 -0000

Kent Watsen  wrote:
> Hi Andy,
> 
> I think this discussion has come to a head.  Please submit an updated 6087bis as soon as you can.  Some comments:
> 
> 
> 1) on the 3rd line below, should the text clarify that --ietf is only for IETF modules?  Also, how does the MUST here jive with the SHOULD in Section 4.10?
> 
>    - MUST use CODE BEGINS for a real module
>    - MUST NOT use CODE BEGINS for an example module
>    - MUST pass pyang --ietf for a real module
>    - MUST pass pyang for example module
> 
> 
> 2) related to #1, Section 5 says "In general, modules in IETF Standards Track specifications MUST comply with all syntactic and semantic requirements of YANG [RFC7950]."
> 
>    First, what does "In general...MUST" mean?  - maybe the 
>    sentence should start with "Modules in IETF..."?
> 
>    Second, can we add a statement for non-IETF SDOs that might
>    have other conventions/restrictions?  Would we recommend
>    --strict for starters, until they can add an SDO-specific
>    flag (e.g., --) to pyang?

We wouldn't talk about any specific tool; we'd just talk about
compliance with this document.  Other SDOs will have to decide on
their own rules, but we can suggest that they use all our rules except
the naming convention for modules and namespaces.


> 3) The first paragraph in Section 4.6 isn't clear, how about this?
> 
>  OLD
>    This section contains the module(s) defined by the specification.
>    These modules SHOULD be written using the YANG syntax defined in
>    [RFC7950].  YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 constructs
>    or semantics are needed in the module.
> 
>  NEW
>    This section contains the module(s) defined by the YANG specification.
>    These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax;
>    YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs
>    or semantics are needed in the module.
> 
>  Note: this reads better, but I wonder, since YANG 1.0 syntax is a
>  subset of YANG 1.1 syntax, what is really being said here? - that
>  yang-version statement is optional?  Or maybe, instead of focusing
>  on syntax, the statement should regard the version of YANG used?

The point is that yang-version 1.1 SHOULD be used, and yang-version 1
MAY be used.

> 4) Lastly, picking up on this discussion:
> 
>      https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html.
> 
>    can add an Informational reference to RFC 4151 in Section 5.9?
>    Maybe something like this:
> 
>  OLD
> 
>    The following examples are for non-Standards-Track modules.  The
>    domain "example.com" SHOULD be used in all namespace URIs for example
>    modules.
> 
>        http://example.com/ns/example-interfaces
> 
>        http://example.com/ns/example-system
> 
>  NEW
> 
>    The following URIs exemplify what might be used by non Standards
>    Track modules.  Note that the domain "example.com" SHOULD be used
>    by example modules in IETF drafts.
> 
>    Example URIs using URLs per RFC 3986 [RFC3986]:
> 
>        http://example.com/ns/example-interfaces
>        http://example.com/ns/example-system
> 
>    Example URIs using tags per RFC 4151 [RFC4151]:
>  
>        tag:example.com,2017:example-interfaces
>        tag:example.com,2017:example-system

I would like to see urn:example:, that's what I usually
use here.


/martin


From nobody Tue Jan 24 11: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 DAA3212968A for ; Tue, 24 Jan 2017 11:34:15 -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 JWKwcoBOJ55R for ; Tue, 24 Jan 2017 11:34:14 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 D3BE91295D0 for ; Tue, 24 Jan 2017 11:34:13 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id x49so199449798qtc.2 for ; Tue, 24 Jan 2017 11:34:13 -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=mZYw6KK6hNFTooWRDKhI2X60KRL5u7AtYtcpa23iK94=; b=f1AG9xvxX8tgQIGfmdxIvsrXpfyik22zeXikrUUMBNNfaznPQEIoabkc96M31OzYEw 2T0lCGLV61B8dor69hnLwvb0Mq4dLr7Q4P2NVph1b8PqWQRtqOrw61No/FoKdmbLcit1 Qt5mq87sjauYIBV6zzcJx87GJv6j0RsJoKC7tjWeGhFFIbA3+koBU9+69KIHMq5+tv47 7s+ILhF4Ql3rVc5sMubOly8IcsCNO2TesTSW7mt378y/Jjm+WcjqOXahkABrvZll/nvL D90FLUQpEaMRV4Pm7Ydq6QEHcPOYr6RRixGcMRshLkJ2zF/JDe5/RjNrGclEi89rgZEt 038g==
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=mZYw6KK6hNFTooWRDKhI2X60KRL5u7AtYtcpa23iK94=; b=fJ1xRTLk1MMebDSoKrYvwmidTAwyCF3pMP0GouPhZKvquz+ObFaiSHhRtC/3AbZcRk ZvVq+5MZj7gjaqXj08olh1Z8Y7aIMkblK/qMn2iSL+fro/4rmCeXsdoNZTNVNLJqQ/vg /LA1leyFUMH2B7+et8+kz/LGicvf1k05oDlhY4nRN/8BPFJQ1aA50MhYNwtOqDK6UVYp 5bZ0AfmIGvfNHDX3b2K+H/aPFfREuOR7PdQwnbiE4tpe0JVvm8ZEkbOyhKo/SYyRG/j3 65CWsck+/OtQy1ticy0LQrFYFG+2lTFfou7iWCi+4VvmFbnNretXRs0yxHgUesX238iP 8DoQ==
X-Gm-Message-State: AIkVDXKPm5RPXL0MmNodk25euAgRBhE6xyXoS6oGLEYRd6W8gtsMWddmBIzRnt8odnZlwxigCyt2zUw3jh14Ig==
X-Received: by 10.200.45.177 with SMTP id p46mr28906467qta.240.1485286452822;  Tue, 24 Jan 2017 11:34:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Tue, 24 Jan 2017 11:34:12 -0800 (PST)
In-Reply-To: <20170124.202630.843995888894291234.mbj@tail-f.com>
References:  <003354d9-841f-37b2-a594-6e9983110984@cisco.com> <093ED4A3-081D-418A-B233-E75148133635@juniper.net> <20170124.202630.843995888894291234.mbj@tail-f.com>
From: Andy Bierman 
Date: Tue, 24 Jan 2017 11:34:12 -0800
Message-ID: 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a114796e869184d0546dc3302
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] example modules in 6087bis
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, 24 Jan 2017 19:34:16 -0000

--001a114796e869184d0546dc3302
Content-Type: text/plain; charset=UTF-8

Hi,





On Tue, Jan 24, 2017 at 11:26 AM, Martin Bjorklund  wrote:

> Kent Watsen  wrote:
> > Hi Andy,
> >
> > I think this discussion has come to a head.  Please submit an updated
> 6087bis as soon as you can.  Some comments:
> >
> >
> > 1) on the 3rd line below, should the text clarify that --ietf is only
> for IETF modules?  Also, how does the MUST here jive with the SHOULD in
> Section 4.10?
> >
> >    - MUST use CODE BEGINS for a real module
> >    - MUST NOT use CODE BEGINS for an example module
> >    - MUST pass pyang --ietf for a real module
> >    - MUST pass pyang for example module
> >
> >
> > 2) related to #1, Section 5 says "In general, modules in IETF Standards
> Track specifications MUST comply with all syntactic and semantic
> requirements of YANG [RFC7950]."
> >
> >    First, what does "In general...MUST" mean?  - maybe the
> >    sentence should start with "Modules in IETF..."?
> >
> >    Second, can we add a statement for non-IETF SDOs that might
> >    have other conventions/restrictions?  Would we recommend
> >    --strict for starters, until they can add an SDO-specific
> >    flag (e.g., --) to pyang?
>
> We wouldn't talk about any specific tool; we'd just talk about
> compliance with this document.  Other SDOs will have to decide on
> their own rules, but we can suggest that they use all our rules except
> the naming convention for modules and namespaces.
>
>
>

I would like the --ietf parameter to be renamed --normative so it is not
IETF-specific
and it is clear IETF example modules should not use it.
Probably too late for that.


Agree wrt/ naming conventions.
e.g., openconfig uses ALL_CAPS for identityrefs and IETF does not.



Andy



> > 3) The first paragraph in Section 4.6 isn't clear, how about this?
> >
> >  OLD
> >    This section contains the module(s) defined by the specification.
> >    These modules SHOULD be written using the YANG syntax defined in
> >    [RFC7950].  YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 constructs
> >    or semantics are needed in the module.
> >
> >  NEW
> >    This section contains the module(s) defined by the YANG specification.
> >    These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax;
> >    YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs
> >    or semantics are needed in the module.
> >
> >  Note: this reads better, but I wonder, since YANG 1.0 syntax is a
> >  subset of YANG 1.1 syntax, what is really being said here? - that
> >  yang-version statement is optional?  Or maybe, instead of focusing
> >  on syntax, the statement should regard the version of YANG used?
>
> The point is that yang-version 1.1 SHOULD be used, and yang-version 1
> MAY be used.
>
> > 4) Lastly, picking up on this discussion:
> >
> >      https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html.
> >
> >    can add an Informational reference to RFC 4151 in Section 5.9?
> >    Maybe something like this:
> >
> >  OLD
> >
> >    The following examples are for non-Standards-Track modules.  The
> >    domain "example.com" SHOULD be used in all namespace URIs for example
> >    modules.
> >
> >        http://example.com/ns/example-interfaces
> >
> >        http://example.com/ns/example-system
> >
> >  NEW
> >
> >    The following URIs exemplify what might be used by non Standards
> >    Track modules.  Note that the domain "example.com" SHOULD be used
> >    by example modules in IETF drafts.
> >
> >    Example URIs using URLs per RFC 3986 [RFC3986]:
> >
> >        http://example.com/ns/example-interfaces
> >        http://example.com/ns/example-system
> >
> >    Example URIs using tags per RFC 4151 [RFC4151]:
> >
> >        tag:example.com,2017:example-interfaces
> >        tag:example.com,2017:example-system
>
> I would like to see urn:example:, that's what I usually
> use here.
>
>
> /martin
>

--001a114796e869184d0546dc3302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,




<=
/div>

On Tue, Jan =
24, 2017 at 11:26 AM, Martin Bjorklund <mbj@tail-f.com> wrote:<=
br>
Kent Watsen <=
kwatsen@juniper.net> wrote:

> Hi Andy,

>

> I think this discussion has come to a head.=C2=A0 Please submit an upd=
ated 6087bis as soon as you can.=C2=A0 Some comments:

>

>

> 1) on the 3rd line below, should the text clarify that --ietf is only =
for IETF modules?=C2=A0 Also, how does the MUST here jive with the SHOULD i=
n Section 4.10?

>

>=C2=A0 =C2=A0 - MUST use CODE BEGINS for a real module

>=C2=A0 =C2=A0 - MUST NOT use CODE BEGINS for an example module

>=C2=A0 =C2=A0 - MUST pass pyang --ietf for a real module

>=C2=A0 =C2=A0 - MUST pass pyang for example module

>

>

> 2) related to #1, Section 5 says "In general, modules in IETF Sta=
ndards Track specifications MUST comply with all syntactic and semantic req=
uirements of YANG [RFC7950]."

>

>=C2=A0 =C2=A0 First, what does "In general...MUST" mean?=C2=
=A0 - maybe the

>=C2=A0 =C2=A0 sentence should start with "Modules in IETF..."=
?

>

>=C2=A0 =C2=A0 Second, can we add a statement for non-IETF SDOs that mig=
ht

>=C2=A0 =C2=A0 have other conventions/restrictions?=C2=A0 Would we recom=
mend

>=C2=A0 =C2=A0 --strict for starters, until they can add an SDO-specific=


>=C2=A0 =C2=A0 flag (e.g., --<sdo>) to pyang?



We wouldn't talk about any specific tool; we'd just talk about

compliance with this document.=C2=A0 Other SDOs will have to decide on

their own rules, but we can suggest that they use all our rules except

the naming convention for modules and namespaces.






I would like the --ietf parameter to be renamed --normative so it i=
s not IETF-specific
and it is clear IETF example modules should n=
ot use it.
Probably too late for that.

<=
br>
Agree wrt/ naming conventions.
e.g., openconfig use=
s ALL_CAPS for identityrefs and IETF does not.


Andy

=C2=A0

> 3) The first paragraph in Section 4.6 isn't clear, how about this?=


>

>=C2=A0 OLD

>=C2=A0 =C2=A0 This section contains the module(s) defined by the specif=
ication.

>=C2=A0 =C2=A0 These modules SHOULD be written using the YANG syntax def=
ined in

>=C2=A0 =C2=A0 [RFC7950].=C2=A0 YANG 1.0 [RFC6020] MAY be used if no YAN=
G 1.1 constructs

>=C2=A0 =C2=A0 or semantics are needed in the module.

>

>=C2=A0 NEW

>=C2=A0 =C2=A0 This section contains the module(s) defined by the YANG s=
pecification.

>=C2=A0 =C2=A0 These modules SHOULD be written using the YANG 1.1 [RFC79=
50] syntax;

>=C2=A0 =C2=A0 YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 cons=
tructs

>=C2=A0 =C2=A0 or semantics are needed in the module.

>

>=C2=A0 Note: this reads better, but I wonder, since YANG 1.0 syntax is =
a

>=C2=A0 subset of YANG 1.1 syntax, what is really being said here? - tha=
t

>=C2=A0 yang-version statement is optional?=C2=A0 Or maybe, instead of f=
ocusing

>=C2=A0 on syntax, the statement should regard the version of YANG used?=




The point is that yang-version 1.1 SHOULD be used, and yang-version 1

MAY be used.



> 4) Lastly, picking up on this discussion:

>

>=C2=A0 =C2=A0 =C2=A0 https://w=
ww.ietf.org/mail-archive/web/netmod/current/msg17277.html.
>

>=C2=A0 =C2=A0 can add an Informational reference to RFC 4151 in Section=
 5.9?

>=C2=A0 =C2=A0 Maybe something like this:

>

>=C2=A0 OLD

>

>=C2=A0 =C2=A0 The following examples are for non-Standards-Track module=
s.=C2=A0 The

>=C2=A0 =C2=A0 domain "example.com" SHOULD be used in all namespa=
ce URIs for example

>=C2=A0 =C2=A0 modules.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://example.com/ns/exampl=
e-interfaces

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://example.com/ns/example-system

>

>=C2=A0 NEW

>

>=C2=A0 =C2=A0 The following URIs exemplify what might be used by non St=
andards

>=C2=A0 =C2=A0 Track modules.=C2=A0 Note that the domain "example.com" SHOULD be used

>=C2=A0 =C2=A0 by example modules in IETF drafts.

>

>=C2=A0 =C2=A0 Example URIs using URLs per RFC 3986 [RFC3986]:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://example.com/ns/exampl=
e-interfaces

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://example.com/ns/example-system

>

>=C2=A0 =C2=A0 Example URIs using tags per RFC 4151 [RFC4151]:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tag:example.com,2017:example-interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tag:example.com,2017:example-system



I would like to see urn:example:<module-name>, that's what I usua=
lly

use here.





/martin





--001a114796e869184d0546dc3302--


From nobody Tue Jan 24 12:56:16 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 3C7A3129762 for ; Tue, 24 Jan 2017 12:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 dnOr_NmXBHHo for ; Tue, 24 Jan 2017 12:56:13 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0106.outbound.protection.outlook.com [104.47.34.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39F61297B8 for ; Tue, 24 Jan 2017 12:56:13 -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=AfDP9dj0Cp+8apr5XD5zWe4YtUrtK0gGFzhxyucWq+E=; b=abgDf8yBXAreZBChjifenFHO5UPiLXr59fmBYEc92R3fv+kjB3B0eP9fCj1FZN+3LEnYRhMW2vjmWwGFyPbnDWSTPtx1/AJunY8CcPlhG7R85HDHeNMSsYEM7MTeCR9M7tOuNwxjrJWoT0gW9Gu7luFsVALnwtb3fbsRebi0k94=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 24 Jan 2017 20:56:12 +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.0874.012; Tue, 24 Jan 2017 20:56:12 +0000
From: Kent Watsen 
To: Martin Bjorklund 
Thread-Topic: [netmod] example modules in 6087bis
Thread-Index: AQHScA/x1/KtZni970SPgZ3dihSO36E+fAMAgAANVYCAB9faAIABVGyAgABZyQD//8U9gA==
Date: Tue, 24 Jan 2017 20:56:12 +0000
Message-ID: 
References:  <003354d9-841f-37b2-a594-6e9983110984@cisco.com> <093ED4A3-081D-418A-B233-E75148133635@juniper.net> <20170124.202630.843995888894291234.mbj@tail-f.com>
In-Reply-To: <20170124.202630.843995888894291234.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1e.0.170107
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: e5fa5420-6298-4bb3-76f1-08d4449b6e65
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1444; 
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:+f7Yuk7d53uOQECw6qVkp1x+dTHPC1boiZ0la/tSLLbrAxV0T6JsdWco3s9vk++Xx/RNGKE2C68AeAz4zIOG1FbOHEVSlAmAKJ30COwH0hMs8I1EK8akwZL4Qp/LMc2ksoSfOFsPEyEKjykBuyuB0ZKof2dQEBjEHjDVXTtT0wFQfJbL7OIx/ZJ2ZBvH7BKYghLRKs1uPziTeciCZ3TgnsyTvBrAlLIrl8rJBYwH3XQVWYPu+inFi6QGr76wyhYbk2x36nYF3Y6cEetmylFzbbtXEsfmw8+N1akBvXfUOsnXZgzoTr5dri5VlUHXqiCNCfFXPuXXLqkOS8IUUvzISHsxV2WfyhrxjJco2PDhprrjas6MP0eZXUQVV+1HiHi9DPc/8gLHdnm33oTzaJ1XJtQoWFT0S4w0wdP0DYBb/r+sqQ301bbkf2et6Suyry7OrNDvdjFZSL16oM8M3NIVrg==
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)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; 
x-forefront-prvs: 0197AFBD92
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39450400003)(39850400002)(39860400002)(189002)(199003)(36756003)(38730400001)(8936002)(81166006)(66066001)(3660700001)(81156014)(229853002)(82746002)(83716003)(8676002)(6916009)(83506001)(2950100002)(97736004)(106356001)(105586002)(106116001)(122556002)(92566002)(33656002)(189998001)(86362001)(110136003)(4001350100001)(3280700002)(50986999)(54356999)(76176999)(25786008)(2900100001)(5660300001)(2906002)(6512007)(6116002)(54906002)(99286003)(93886004)(4326007)(101416001)(3846002)(102836003)(305945005)(7736002)(77096006)(6486002)(53936002)(6436002)(68736007)(6506006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: <8E2703536B0EBB47B4506B1F93BD0D16@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2017 20:56:12.6904 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] example modules in 6087bis
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, 24 Jan 2017 20:56:15 -0000

SGkgTWFydGluLA0KDQo+IEkgd291bGQgbGlrZSB0byBzZWUgdXJuOmV4YW1wbGU6PG1vZHVsZS1u
YW1lPiwgdGhhdCdzIHdoYXQNCj4gSSB1c3VhbGx5IHVzZSBoZXJlLg0KDQpZb3UgbWVhbiB0aGUg
TklEIGZyb20gUkZDIDY5NjM/ICBTdXJlLCB0aGF0IGNhbiBiZSBtZW50aW9uZWQNCmFzIHdlbGwg
YnV0LCB1bmxpa2UgdGhlIG90aGVyIHR3byBleGFtcGxlcywgaXQncyAqb25seSogdXNlZnVsDQpm
b3IgZXhhbXBsZXMuLi5pdCBkb2VzIG5vdCByZXByZXNlbnQgYSB0ZW1wbGF0ZSB0aGF0IGNvdWxk
IGJlDQp1c2VkIGluIHByb2R1Y3Rpb24uDQoNCktlbnQgLy8gYXMgYSBjb250cmlidXRvcg0KDQoN
Cg0K


From nobody Wed Jan 25 00:51:50 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 5E7B612988D for ; Wed, 25 Jan 2017 00:51:46 -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 13lM5bvRS7o2 for ; Wed, 25 Jan 2017 00:51:44 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD82F129864 for ; Wed, 25 Jan 2017 00:51:43 -0800 (PST)
X-AuditID: c1b4fb30-d53ff70000007085-80-5888671c2aaf
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by  (Symantec Mail Security) with SMTP id 7C.98.28805.C1768885; Wed, 25 Jan 2017 09:51:42 +0100 (CET)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 25 Jan 2017 09:51:10 +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=kS4m9tBb0cTKpxyDnQlHttcT5IjKRPU9EXeRQbAslLY=; b=OZ4As9KHMcxnx0VKSwPrzezsT7bLAhh4EgBfzpZOfE5PsjuOBoaDr1ODbKWX2YakgGj/CN7h6/TVn6AEnnNBXNV7hxsoVWueayB6XbRM/D6EUMnmMPKkWJPHLgmAyHfTt8Y8dPPMTLAn4ZSkjDbg37nR7aEwTiqSP9eTj+N0nCE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.197.152] (91.82.100.59) by AM2PR07MB0946.eurprd07.prod.outlook.com (10.162.37.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Wed, 25 Jan 2017 08:51:08 +0000
To: "netmod@ietf.org" 
From: Balazs Lengyel 
Message-ID: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com>
Date: Wed, 25 Jan 2017 09:51:01 +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: HE1PR10CA0039.EURPRD10.PROD.OUTLOOK.COM (10.167.243.177) To AM2PR07MB0946.eurprd07.prod.outlook.com (10.162.37.141)
X-MS-Office365-Filtering-Correlation-Id: 73d0b6a1-5411-4450-4d8d-08d444ff4e2e
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0946;
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 3:lt3SVJF937DTMJJRmE13J2FLQNrsyZ4G3FSFnAxuZa1/8pzrL2gTv+mPgT87UDlLXtTr6CF+48QC6AMaDJwHCdi14Nw77Q7pbjeTWOC1ji/2d2hAg1NspT3igTJ+QMLzUoBT29Gbuwf/mekMuBm9GDqj/o/7mC2u7g2u5CFaGl2sgYYC6Z+YwejE8F4dcwHW8JrUhLY0hTYBqdsrPqM8qkuVke3HT99onTYCk6F/ntUu36a0gbuNlpaUpYBzCLqWdDk9+5K8FKhVdTNEMABb7w==; 25:jrOcf6GFH31w8gObijYVjE1TELEwTWro363bPzVXKmHOE8wLXPlNxMjIxCDPbQsObk4Js9AgTfHU3+yBVkknEnI4B7qImsz6Um+0r1UnQ9jSDXnBciUvWbrGSBJbC/0JBq1ld55GVNok8nudAH9To+T7oj4l8MQTdMmz8AxSKvBVVqn6a5uSJ7+/0jeE3WXDOw8Yxv9QbSGcyJWnDhdiA41HBt8yUD05stATUkGTQ+NRtiDw5ZF/dXVzefVkLduEMI+pZRXyn40HmgoDIpReSZkJCGVZKTEeCPbVmEYNC1obV1ElOLea8zFOvOuYnHM8Yfy9llrmSA6OBQsiirOJ+28YF0kivq/T5LmaTmalF0xHYkMTn4LMbwu+oOkAua2Oyt0+vLUdpAFy0o6puBdfWTEwQQrpXASW9jzh6VgL+uQFpPyW5GOdoNzfYjDwX9oJnHFHT527lFyIPmzeytrXyQ==
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 31:btud4cCjKWb5AdCIQ503OdGBrAbkuifU2+gAmHbk9i3bwpOCziYNtf5rcy1Ng9TmwncGv+2qCV4Q0DZUO3y5tRd/WlO+4eQ8C0uX+H12WrEz9dHk5OyC5xnfAUkPALVKheuo7Rm2Cm46JqEWHZaRR9gryAd+RfiWtWs5TODXBguMzS1O4nHQognGH9c+uvU3UpdAuX9ngZY6ynWhBJ/n+3MMVCnuL7MP6NTwbllGMFiIPg5DkNgXv1aFz6L3f+zt8wqmeUCygghRYKXrkQay2/M+6bE9nyUzZHCX+PYnk6w=; 20:8lIWkS24HiJIC/rE13cKRgwtvXa48qa/KRIaidkWmvx16Qiy42fWMqX5SgXF62K4I0oyB1wLIpAYBfIWuPNs0v8glFQvmOFqQS7XHbmZ230SIGrSnVNc7XaOluXmWg2vx4J7L/gx0IsD2slGxXikFAJMdHypnx7ncOH5qSwboA7ABKAsSMKS3U87BgPbyPHZP5o3elfxYiYoNGvzxyt9uOq/Jv16rxwzhhKv1KHfD4/r0otDNjUuKDPKD3znsLxWhrDOVHTkrJ17kZuaDGuQy1ugM97kItEz/foznhgpSwQ6DX6M4hPVF3IKnjsabgAA/vipYXu+E8g4NXLK+gu+6SB1s8nfermhLawatDDeABmO6fskPDJzEmsiVFUbZol+hdVg30tJ9hNiJuI76jHB71OrUrGBSSFMWEXmtctoW3zhxBkp+BSKtZvFfIrHYBYoxNCVsd5kFO7/wyaufLqTYgylQo3a2U1UEQ5oxUnXURHQlSCVcfG6rxG6B9Ow0C9G
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)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:AM2PR07MB0946; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0946; 
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 4:KphtZfqttHSCvXHumTSLe05rESA2mm9Gt/3VyFHQDP8F8aSMrpDqtKzPUeHEhd8knG3OTrOR6YPlf7Dcpk1g3ZhDFfXaKbK4Nu9ylBuL2knOF45cPZ8Fm+JyqY59eTrAgWJKK7r0Af0pNBcWdT+E8Xqboo0HlajxiHHzHdfdXXzlS5xUIpge3uoaDHdptAAZgWooFT7+D/b2xZSS1iQ3tHAUKIoZSjksxtF9bLpCq+ADS+vm/SHX8PuBCZ0RDKIEKPM1WCELQLGU6d8wI0cTInSe0h9mF/NHPJ5fm3veT3TSD14NWd1u6YuJ+SaRrCodu7HW7RjRvrzEeIjHaoXY27LJFj82oUJaFIgm/xvwqRu14ogjwjKJr6T2nYcyUu3GkluJGMOOB6tYAHx2fBzUM4oa/9jMp6jJA7h6lbD+DkyYfkm91aSeUSOKHpaC4d48ni1MHdjZtqgWNdxt2lCwBFHu/cxRBRqob2CErOXWw2Hw0NA0+jrGdmziYAjU6EPg7ev/BMoHvTuiIvjeAowFa3J+ocl91auzE6d4+b4CDuD/swPUJLoIJAfeEhN0KTsFuhZbMrZs4ey6RUrg+Eh9gIS6JIfkFDbrRlg/l0lFQYehIggYZQKBY74dmw7lRvid
X-Forefront-PRVS: 01986AE76B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(979002)(6049001)(6009001)(7916002)(39450400003)(189002)(252514010)(199003)(50986999)(65806001)(68736007)(54906002)(2906002)(4326007)(42186005)(47776003)(92566002)(6306002)(6486002)(65956001)(101416001)(2501003)(25786008)(38730400001)(90366009)(66066001)(5640700003)(54356999)(230700001)(83506001)(81166006)(8676002)(81156014)(7736002)(1730700003)(64126003)(97736004)(2351001)(189998001)(4001350100001)(6116002)(105586002)(53936002)(305945005)(33646002)(86362001)(31686004)(110136003)(23676002)(6916009)(50466002)(5660300001)(65826007)(6666003)(3846002)(31696002)(36756003)(106356001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0946; H:[159.107.197.152]; 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?MTtBTTJQUjA3TUIwOTQ2OzIzOmNIZ3BUaXNDL3JIU2c2ZjlkVnhmZWtyL3dl?= =?utf-8?B?MW9PWE5JdmVWU2l6Z3h3Sjd6dlJMWmlTdkQzV283L0NjMDZRb0daeW96N2xM?= =?utf-8?B?YnJxVmE0YUlQWEd0QmxKNmlZMTFQMkYzOTZmMHI3Y2ZUSXBQNkdwRUIySDgv?= =?utf-8?B?aHpiM0p1bTRqclBRcHh1WFFJdHdNMjJLVWJ1TGRxL0IrekV6b3FrbURYTDQz?= =?utf-8?B?aDRXeDkyUVpZQXZRYlo2Y1gyVTZ2L2FGY0VKTktUajA5YjlqUHpXQmxiU051?= =?utf-8?B?K3BjNzBLbTc4OFkvSjVRUXU2SGp3N3F6YlVuZWoxbGlCK1M2YTduRXVMYk9L?= =?utf-8?B?c3ZzVE5aYy9qMTdLbzF1MWdzdlVVb2F6a2xlelNaSkszT1VPeTROaFU4N1hR?= =?utf-8?B?SUE3TUR5SVJtM1BlUG5KRkJLR1BORFl1TW51bm1RZGJSeG5BWXhhL25rTVli?= =?utf-8?B?NXN5YmI0ZTlTOURUNnFGZnIyRDUwMytYeFZPV3owbENOcm5jazFocnZJMHVD?= =?utf-8?B?Z0MvR1M4aUtkQXhjeHFZMDk2UmtNakVqUy9HSDZEZW91YXJ6Tzc0cTBwbnJF?= =?utf-8?B?RXdPdHFUbDBMS0lLTVVWNEs2T0pyb1pyZGZMc09nSDZXWm03RWJieFBEVFpC?= =?utf-8?B?ZVJYVmpVUU9hc3M4WlhPU1V0aEdRaUJNNEdTYWpta2tEejdudDcwSDd5eVZw?= =?utf-8?B?ZUI5VndjV0hlcytoNDZYS0JJUTVGL2pJajdxdzJtalV0NkxhckF3TmZqNjR4?= =?utf-8?B?Q1JGaituQ3lmWEg0S2YxUU5wVUNKZjIrd1B1TnRGVzVhK0ZTQndNRkFuNGlR?= =?utf-8?B?YWZ6aEQrcnBLb0VWSUxadXNHTFVLYjJJTjVqUmpvUG1xOWd0NU1wOE1iQjM0?= =?utf-8?B?R1daclc4MmlKODBrM01ZNzA4TFBXQ1dZZjJOR3ZETXgrODJvZVdSZjlrYnV3?= =?utf-8?B?RFpWc2F3QjRBM0cyZDhDaW9rVkVsN0N4UXlkR0M0NzNpbStMV1R3SHc2NWJD?= =?utf-8?B?dW1wdWpxYy9PNnBBcTY4eEZnOGVxbHZGSUFIU29aTTdiMDdsTU1RVyt3NFp6?= =?utf-8?B?V0FDR0NjcXlMQ0pOTzM2eU4xZS9kUEoxUzZEY1kyL3NLMHFyQmdkblpvL2hL?= =?utf-8?B?NkRxZHFSTGwzMi81LzVUb2ZleXZLdytIUFp1bHNhaWl1VDZCdVBidk8xSkJq?= =?utf-8?B?SGdud28wODJXNmI5cmpudXZtRlVVUFFLMG9NOUl4ZXM4dWpRcVNaUWcyVGpR?= =?utf-8?B?V1g0eWN5ZytNc1duRWRRR2hKM3ZEaFByaW5jbUJaQ2hYS2xSTE4wa01ZMXVX?= =?utf-8?B?b09lQSsrQm1OTDJFMlNrVjF3TldMUmVGR0RHRVhNQUZ1Nk52c2d1ZlFMUXov?= =?utf-8?B?c09nTVJiV1lBUDZlRVd2UWloaHRkN28xa0dPTGRsWUNmRVY0L2wxdXNLMG5I?= =?utf-8?B?dWppWC9pampQMytwVXNBQWlNazhUaUtvVHF2SkVhNWdPYmpnWXE4NHFFSGJR?= =?utf-8?B?WXVvK05neTExRU5FNGc4LzBOcnBSTEpBTkZUZzR1V0xxRG1KVHpUMVl2Nkp6?= =?utf-8?B?L3hVZUNQeFlIMmNkOXNCSkJrVTY4U2drSUgxWWRaazNwSkxGL0pMNWFmbFhK?= =?utf-8?B?Q0t1ajJCUERpNUVva2orMDZwYVNUTGU5Z2VvZFdxTlVCR3F4TmFsZG1nN2wz?= =?utf-8?B?M1lkdWlodi92OFprZTYvRFZ1ZkZBeWdsbUNva09Kby9aSlQ0NUY1RW4wSmxO?= =?utf-8?B?amdIWUs2UFRJNkltUFNJcTJiV1BnbTc1cS9MN0duSW95amRHd2FtRnljQThY?= =?utf-8?B?NXJNaWF1UmJVTHNQWktiUGpCM3lpWWhNYThTdjNBWVdnaitCRFl3ZkZjdUww?= =?utf-8?B?NFF1UUo0ZkZQQm9iU3laWjl0dlpLR1BWQjVkUmVFMHhEK1Jsbm8wV3J0V3Zl?= =?utf-8?B?MTJDTW5rZGZtT3R6WXFGVjRpUmIzUjdnZUtaNFVYZXBDaHRqOENGVWs2cEJh?= =?utf-8?B?QS8yZzFmWHNycS94N2VSczlhQldEelUxUEZtZz09?=
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 6:JxascFSH+q4U6MuGRRWgIrzuWuPO3X01GcGkSldgmboUhDPHck4hDQiQ1Ifco7w6tlo8gZg/2hrMK2hcqvyPGqASWtk2Kg0q1vdqoLTpWZwYQ8MmYFuPEYLwx7h+4zvmuP67Uj3JHuTDjfBLykpOP9jPmlJ+cUC0Q7cQJhURoUCGtYnyCK+wYwP2SjYlfspL2xWwpA8RjOOttOp7muf0mr6qzSfhAm6u7Den7n7MyaNGTeWhX/0UvgRMtDsx+uCdECykhR7HLxNrFXqPJqhWSduH8r3Rhq21Wl1Yb1OqfVF/+pM0Ch8J9B5UhNvJsezAOwvM/JdZ3szacGz7em/UXxsVq7NICauj86eUOQ1IRSXxVgc+LkI4wxPWvbdO3aMFqwYJ5qn3rVuM13u/Egc4b22499XBeySL9vGfoiYoZNw=; 5:E3uJXwU5OhQsHMVm8LXurD1hIdGyOdKCXA1ayr8pCfFeOUUGeoP0Isn8NJxm/qa9XctRRy5cGLCmZPx2+VIYo5qASi4Jdt02XQaGkJDgqRUfS2jRD8Xks+8FM49Xl7WdnWgPmnLmzi1W6ufzf0np9g==; 24:B4G0aSDW4snq8E7HYHHPxz+4m4DEs/MmeyYglZSQWcphOZGi6lY1Kp1opjU03F8JqOg/YeBgsHjbAXyjL0C1roOVaSLc4p6fahuzst7h0JM=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 7:JVpHeWEsWAolCVBDU4u+AZJPXojSai19uyUwVpNzCEMqEGPco2zEzI1idtVp7irfFn10FPWxOzIZn7XdntrI7CC1jcuj7DfFnqCrEl8kNU4NQbfPDD4dvjBeOt3tlXgw3tnGVJJk759uHp2sv738bcwrUonN7++x8cvsf7ZLjZLyYpSOyYogtE2O4q6mBn7tfVfejsg2BbmLlPMuaEPzgASdheiRu151Oy4pSy1HJJvYlSecYAEL2UNohZa4AViTn9ccuEXCVwhaMBSFy/iQzBkBXSVNJxo1lHDILAaWcWuL3BkUep584QpFPytRwDK+Cv140gKDMpRLSkQQEB54E29k3dHPZDEUNLHMP9jqoajcFDKwRS+9ZGh2D7an+9NmLem16nNMlE6LakDn3I2t1vdczJc09gr43k4LIpZrVuV6C82vu+Y03egf2cjF/uu54jP1WMQgV6jeU7xdFyEGeA==
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2017 08:51:08.0245 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0946
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbHdTFcuvSPCYPZdRou3q04zWbxYvZrJ Yv7FRlYHZo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2Ph9NlMBa9YKvbtu8bUwHiPuYuR k0NCwERi9YYPLF2MXBxCAusYJTbc3c4K4ZxglFgy7RsTiMMi0MsssXnBFrAWRoE4iZ1rFkJV /WOUeLPyD1hCREBdYubO9WwgNpuAkcTU/vMsILawgK7EyUdfweLMAokSz5+cA4vzCthLHJ26 iBXEZhFQlfg4bw0jiC0qECPxdv1ydogaQYmTM5+wQPRaSMycf54RwpaX2P52DtQPChLXN18H +0FCoINRYsbEW2BDhQQ0JB5e+MsKUeQrMfHAI3YY+3rrY3aIhhVsEn87TzBDOE/ZJI5O3ATV kS3xrecE1Aoride/vjNC2F1MEl9WaUM0bGGVOPTnPBNEQkZi140rTBCJRWwSq7+sZ4G4I1Vi y40WNohEo4jE/aUXofa9ZpU48mo2ywRG9VlIvp2F5NtZSL5dwMi8ilG0OLU4KTfdyEgvtSgz ubg4P08vL7VkEyMwaRzc8ttgB+PL546HGAU4GJV4eD9kt0cIsSaWFVfmHmKU4GBWEuHdlNQR IcSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVAPjbPk5rPGq FmxTNGd3n7L97N5xXX7V8SnaiU+2ucTY3fjLbnc+Y/8B8/aI/0HbcvZI2CvFrmH+++HK0v2J P2NcPtTM+vGlpGjWu4JNu1yOdz8rP/68QPDRmm/Rclr8Ao0ujPsi6uU1y0+mJR6cE1UmtnG6 z//nHD+4FkzTEHuwj1f52IedPj+ylViKMxINtZiLihMBRr/UhRYDAAA=
Archived-At: 
Subject: [netmod] New proposal: Yang Schema annotation
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, 25 Jan 2017 08:51:46 -0000

Hello,

As a result of work coming from the Yangpush effort I just posted a draft
https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00

This proposes a way to extend YANG modules with extra properties for 
specific schema nodes without modifying the text of the original YANG 
module. We have a strong need for this in Yangpush, but it would be 
useful/needed outside Yangpush as well.

Please review, comment!

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Wed Jan 25 04:41:33 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 5AC9D1298AC for ; Wed, 25 Jan 2017 04:41:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 E6MzqbKJLom2 for ; Wed, 25 Jan 2017 04:41:29 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 408991295A9 for ; Wed, 25 Jan 2017 04:41:29 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 796441821FD5; Wed, 25 Jan 2017 12:40:20 +0000 (UTC)
From: Ladislav Lhotka 
To: Balazs Lengyel , "netmod\@ietf.org" 
In-Reply-To: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com>
References: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com>
Date: Wed, 25 Jan 2017 13:41:27 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] New proposal: Yang Schema annotation
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, 25 Jan 2017 12:41:31 -0000

Hi Balazs,

I agree that such a mechanism would be pretty useful.

I think though that the deviation-based approach can be used without
further ado. Why do you think that the "deviate" statement cannot handle
extension statements? AFAICT, the following module satisfies all rules
of RFC 7950, and it is then up to an implementation to handle the
extension, so it can also add it as an annotation to the target node.

module devext {
  namespace "http://example.com/devext";
  prefix de;
  import ietf-interfaces {
    prefix if;
  }
  extension foo;
  deviation "/if:interfaces" {
    deviate "add" {
      de:foo;
    }
  }
}

Lada

Balazs Lengyel  writes:

> Hello,
>
> As a result of work coming from the Yangpush effort I just posted a draft
> https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00
>
> This proposes a way to extend YANG modules with extra properties for 
> specific schema nodes without modifying the text of the original YANG 
> module. We have a strong need for this in Yangpush, but it would be 
> useful/needed outside Yangpush as well.
>
> Please review, comment!
>
> regards Balazs
>
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> 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 25 05:05: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 A8ADB1298AB; Wed, 25 Jan 2017 05:05:40 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 oSzymgUrskUX; Wed, 25 Jan 2017 05:05:39 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D007312989C; Wed, 25 Jan 2017 05:05:38 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0PD5Uhq031053; Wed, 25 Jan 2017 13:05:30 GMT
Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0PD5P0D031024 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2017 13:05:28 GMT
From: "Adrian Farrel" 
To: "'Tianran Zhou'" , 
Date: Wed, 25 Jan 2017 13:05:24 -0000
Message-ID: <02d501d2770b$b3cce160$1b66a420$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJ3C6XMP9fSsm4ISz6dPWABble+gA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22844.006
X-TM-AS-Result: No--17.567-10.0-31-10
X-imss-scan-details: No--17.567-10.0-31-10
X-TMASE-MatchedRID: 0+daXaNUWRWnn0ikgrV5F5VIEKhlTKpsCt59Uh3p/NWvQKL4Zyk7vD+w kmu9F8TUADB//LqfcBG2Dz3PHv7H5yhlmALF5LHIwVaayvK71l/2X2nyY2WSCfWAXs8IQX1uSzl I2vTw45voQ07jTT9lSldxg8E/dolzmsV/pxO5my+zwJcJKPFV6/ZbiRNt1Wiod71AOvz4tNyAEa pd1DGem+lrSILBkMIfW9AQiO8HcMDh134jKGaMGfOHbIp2eXtYQPCWRE0Lo8KdI/DikZ1UPLliD 6D5Idq7Pky3qUIYnds46aCOYadUWApP5EcuEKQc+3dCDI49dsshotH7bEpEMrrfxlRjqBJ3JRw8 rCLGUM8xcSfgz4Zxa/FPDHhQkgxywPFufF78O4iVUcz8XpiS9DGZtPrBBPZrs1y4JvwIDG6V/4b 3Z4NiM32iNUjkdD3238jePisGrfpdFN0T1voiz6+dYEguu4aVnvBHr/aFnM60Vg+MnSE2GIThNu sNaFrye2D25CVmFvp4ruJXWjLASRqX6iR5jg9rKWuiyZLRI4CRPtwwl97om7l+jVyLzmC70DM+v /G/NaM0KfHO8RTD8sn+WbzE3UhvAM0/G7XUdeMYBkxPlIuYCQ2AVSpm3nkDXDDHfowm/bfzPvRc NNSOxo9Zm8Ov7SprPDF4aOlLYwdKl5uDD6k69p4CIKY/Hg3AtOt1ofVlaoKm8jxRk5/juNRnEQC UU+jzjoczmuoPCq2UTGVAhB5EbQ==
Archived-At: 
Cc: opsawg@ietf.org, draft-ietf-netmod-yang-model-classification@ietf.org
Subject: Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2017 13:05:40 -0000

Hi Tianran,

I agree, it is very confusing.
It doesn't help (me) that folk are using the term "device model" when I can't
find a definition of that term. Maybe this is intended to be a synonym for
"Network Element YANG Modules" that is used in
draft-wu-opsawg-service-model-explained and
draft-ietf-netmod-yang-model-classification. In
draft-wu-opsawg-service-model-explained we tried to bring the terminology into
alignment by also using "Device Configuration Model" for this.

draft-ietf-netmod-yang-model-classification is pretty clear.

   Network Element YANG Modules describe the characteristics of a
   network device as defined by the vendor of that device.  The modules
   are commonly structured around features of the device, e.g. interface
   configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and
   firewall rules definitions [I-D.ietf-netmod-acl-model].

   The module provides a coherent data model representation of the
   software environment consisting of the operating system and
   applications running on the device.  The decomposition, ordering, and
   execution of changes to the operating system and application
   configuration is the task of the agent that implements the module.

Note: "a network device".

So, if a module contains information about multiple devices (because coordinated
behavior is needed to enable a service) or about the network itself when
facilitating the service, then the module is something bigger than the Network
Element YANG Module as defined in draft-ietf-netmod-yang-model-classification.

That's OK. It doesn't make the module wrong or evil. It doesn't mean the module
has no value. It just means that the module needs a different name. 

In draft-wu-opsawg-service-model-explained we chose to call this type of module
a "Network Configuration Model".

I don't believe that these authors of draft-wu-opsawg-service-model-explained
can be clearer on our definitions and motivations for listing the particular
modules that are work-in-progress in particular categories. We could, however,
stop mentioning such modules if that make everyone less uncomfortable. This
would not substantially change the value of our document (which is about service
models).

Thanks,
Adrian

> -----Original Message-----
> From: Tianran Zhou [mailto:zhoutianran@huawei.com]
> Sent: 23 January 2017 09:33
> To: adrian@olddog.co.uk; netmod@ietf.org
> Cc: opsawg@ietf.org; draft-ietf-netmod-yang-model-classification@ietf.org
> Subject: RE: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
> 
> To add more comments:
> 
> On the L2SM meeting, several people (4 or more) believed the 3 service
delivery
> model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], [I-D.ietf-bess-l2vpn-yang]
> and [I-D.ietf-bess-evpn-yang]) are actually device models.
> 
> I think both of the two I-Ds ([draft-ietf-netmod-yang-model-classification]
and
> [draft-wu-opsawg-service-model-explained]) can check if those YANG models
> are device models or service models.
> 
> Regards,
> Tianran
> 
> > -----Original Message-----
> > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian Farrel
> > Sent: Friday, January 20, 2017 12:25 AM
> > To: netmod@ietf.org
> > Cc: opsawg@ietf.org;
> > draft-ietf-netmod-yang-model-classification@ietf.org
> > Subject: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
> >
> > Hi,
> >
> > We've been trying to ensure that draft-wu-opsawg-service-model-explained
> > is consistent with the latest version of
> > draft-ietf-netmod-yang-model-classification. In discussions with Tianran
> > a question has come up.
> >
> > In section 2 you have a nice definition of Network Service YANG Modules
> > and this definition maps nicely to our definition of "service delivery
> > models".
> > Furthermore, your figure 1 shows Network Service YANG Modules on the
> > interface between OSS/BSS and the various network services.
> >
> > We have further defined "customer service models" at a higher layer still.
> > That is, on the interface to the customer. This (of course?) assumes that
> > the OSS/BSS is not customer code :-)
> >
> > However, your discussion of Network Service YANG Modules in section 2.1
> > seems slightly at odds, although this may be just ambiguity.
> >
> > For example, when you say, "Network Service YANG Modules describe the
> > characteristics of a service, as agreed upon with consumers of that
service,"
> > this is not the same as, "This model is used in the discussion between a
> > customer and a service provide to describe the characteristics of a
service."
> > That is, the former case could be arrived at after processing based on the
> > latter case - processing that we have called "service orchestration" but
> > might (of course) be what leads to the operator poking the OSS/BSS.
> >
> > This might all be fine and good, but later in the same section you say
"Network
> > Service YANG Modules define service models to be consumed by external
> > systems.
> > These modules are commonly designed, developed and deployed by network
> > infrastructure teams." And there you introduce two terms that are previously
> > undefined and only server to add ambiguity. Specifically "external to what?"
> > I could make and argument that the OSS is developed and deployed by
> network
> > infrastructure teams, ad also that the OSS is external to the network
itself.
> >
> > And, in between these two quoted pieces of text, you have...
> >
> >    As an example, the Network Service YANG Module defined in
> >    [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
> >    model for Layer 3 IP VPN service configuration.
> >
> > Per my other email, this reference needs to be fixed. But I struggle to
> > see the L3SM module as consistent with your figure. It may or may not be
> > consistent with your text dependent on the interpretation.
> >
> > In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show
> > how we (the authors) think L3SM fits into your classification. Here we place
> > L3SM further up the layering stack.
> >
> > [Apologies for not spotting this sooner. The citation
> > "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
> > delivery" which I took to imply a different module.]
> >
> > Thanks,
> > Adrian
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg


From nobody Wed Jan 25 06:09:47 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 1827A12995F for ; Wed, 25 Jan 2017 06:09:46 -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 3ZcP9HSthzk0 for ; Wed, 25 Jan 2017 06:09:44 -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 1189712995C for ; Wed, 25 Jan 2017 06:09:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1978; q=dns/txt; s=iport; t=1485353384; x=1486562984; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LnQ8zYU18KREQsrcEMLw7Sc7LsCYJIcmp1sIYWtIYqU=; b=P0E7AWeUFtKnKOW2bqeoXQ+61IiphTq3ODT+IP073BYyoheHrOaRGRVi emDWHtlHEk3X9hTDKb2HLnhjIrmOMbatmMtcMi/1gN3gU1LvF9CGBfzKw yGJ/NsKxvz7q6e4FWI028y4PA/kw8MUxjR5hdKDvCNbanwS8yaHOmjzGS o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQBnsIhY/xbLJq1EGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1AQEBAQF/Kl+NXHKmRoINKoV4AoJRGAECAQEBAQEBAWIohGo?= =?us-ascii?q?GOEEQC0ZXBwwGAgEBiRgOLbAmimIBAQEBAQEBAQEBAQEBAQEBASGGS4IFgmqBP?= =?us-ascii?q?IFQhyIBBIkCEYdhilqRc4F3hRCDKoY+inyDaYQVHzgRgQcTCBUVGCOEPA0PgWI?= =?us-ascii?q?9NQETiBgBAQE?=
X-IronPort-AV: E=Sophos;i="5.33,284,1477958400"; d="scan'208";a="691688658"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2017 14:09:41 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0PE9flw011706; Wed, 25 Jan 2017 14:09:41 GMT
To: mbj@tail-f.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net
References: <20170124124716.6A187B8011E@rfc-editor.org>
From: Benoit Claise 
Message-ID: <6c3b104f-ff86-77f5-9b73-49f7cca28f0e@cisco.com>
Date: Wed, 25 Jan 2017 15:09:40 +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: <20170124124716.6A187B8011E@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (4916)
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, 25 Jan 2017 14:09:46 -0000

Dear all,

This looks correct to me according to section 7.17.1
Need one more pair of eyes to double-check before approving.

Regards, Benoit
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7950&eid=4916
>
> --------------------------------------
> Type: Technical
> Reported by: Michal Vasko 
>
> Section: 7.17.
>
> Original Text
> -------------
> If the target node is a container, list, case, input, output, or
> notification node, the "container", "leaf", "list", "leaf-list",
> "uses", and "choice" statements can be used within the "augment"
> statement.
>
> Corrected Text
> --------------
> If the target node is a container, list, case, input, output, or
> notification node, the "anydata", "anyxml", "container", "leaf",
> "list", "leaf-list", "uses", and "choice" statements can be used
> within the "augment" statement.
>
> Notes
> -----
> It was forgotten to mention "anydata" and "anyxml" as valid substatements in this case.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --------------------------------------
> Title               : The YANG 1.1 Data Modeling Language
> Publication Date    : August 2016
> Author(s)           : M. Bjorklund, Ed.
> Category            : PROPOSED STANDARD
> Source              : NETCONF Data Modeling Language
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> .
>


From nobody Wed Jan 25 06:14: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 92523129965 for ; Wed, 25 Jan 2017 06:14:00 -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 o1JMjZG9h-0y for ; Wed, 25 Jan 2017 06:13:58 -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 B653512995C for ; Wed, 25 Jan 2017 06:13:58 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:4ddc:23a1:fb6b:398c] (unknown [IPv6:2001:718:1a02:1:4ddc:23a1:fb6b:398c]) by mail.nic.cz (Postfix) with ESMTPSA id 466336094A; Wed, 25 Jan 2017 15:13:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485353637; bh=6OuvutgXCWsIB/P6Cdxgcj9vHc8Bw8Gzu6QTU2Vx2dE=; h=From:Date:To; b=ZGglNUo8JTE7kpxHTFbFpKE33dn9jUUy4BEHgRG1Q3Z6Ch79FN8do7JJuTicDaGxD biZ/CoLlHYybyZ96afx9H11stUcNkbKzbvOVhlu2YKVR2Ua/fLW7V7Vj8RnodoRXsT JDe4DmRpthzJCq6AlppGSDq+Pq10GcnzN3bgCrI8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <6c3b104f-ff86-77f5-9b73-49f7cca28f0e@cisco.com>
Date: Wed, 25 Jan 2017 15:13:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20170124124716.6A187B8011E@rfc-editor.org> <6c3b104f-ff86-77f5-9b73-49f7cca28f0e@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.3259)
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: joel jaeggli , netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (4916)
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, 25 Jan 2017 14:14:00 -0000

> On 25 Jan 2017, at 15:09, Benoit Claise  wrote:
>=20
> Dear all,
>=20
> This looks correct to me according to section 7.17.1
> Need one more pair of eyes to double-check before approving.

Yes, it is correct, and also in agreement with the ABNF.

Lada

>=20
> Regards, Benoit
>> The following errata report has been submitted for RFC7950,
>> "The YANG 1.1 Data Modeling Language".
>>=20
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3D7950&eid=3D4916
>>=20
>> --------------------------------------
>> Type: Technical
>> Reported by: Michal Vasko 
>>=20
>> Section: 7.17.
>>=20
>> Original Text
>> -------------
>> If the target node is a container, list, case, input, output, or
>> notification node, the "container", "leaf", "list", "leaf-list",
>> "uses", and "choice" statements can be used within the "augment"
>> statement.
>>=20
>> Corrected Text
>> --------------
>> If the target node is a container, list, case, input, output, or
>> notification node, the "anydata", "anyxml", "container", "leaf",
>> "list", "leaf-list", "uses", and "choice" statements can be used
>> within the "augment" statement.
>>=20
>> Notes
>> -----
>> It was forgotten to mention "anydata" and "anyxml" as valid =
substatements in this case.
>>=20
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>=20
>> --------------------------------------
>> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>> --------------------------------------
>> Title               : The YANG 1.1 Data Modeling Language
>> Publication Date    : August 2016
>> Author(s)           : M. Bjorklund, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : NETCONF Data Modeling Language
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
>> .
>>=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 25 06:19: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 B04BE129961 for ; Wed, 25 Jan 2017 06:19:01 -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 09VLLV6iDrvE for ; Wed, 25 Jan 2017 06:18:59 -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 2290E12995D for ; Wed, 25 Jan 2017 06:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10648; q=dns/txt; s=iport; t=1485353939; x=1486563539; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=LmixydKDjbtFyji0EI9YE1y58RjipxpNID1P8NHNW4E=; b=CgQlipRPX8ivWRAFcTk+xXWdtoKNYZxuGdtm5Ui0wyH+qZ/XdJSB5e97 HIbbwKzD2F3Bx6zSN3XFGj0hHhPVd3YrY4zj+47oK9l+vaxa4R3uQRkSO 0TiG9FAAjBwNAuOPLkGKAKozHqIRlO+YnsizkSpiVCZYAC0qZqLbOhJUK E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/BQCBsohY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAX8qX45OkHkfkAOFK4INKoUuSgKCVRYBAgEBAQEBAQF?= =?us-ascii?q?iKIRqAQV5EAsOCi5XBgEMBgIBAYkYDrBXK4o3AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHYZLggUIgmKCPYFvAQGGAAWPLowghmWLDoF3U4Q9gyqGPop8h34mCCmBGBM?= =?us-ascii?q?IFRWEdxyBYj01AYV9gi4BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,284,1477958400";  d="scan'208,217";a="649126280"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2017 14:18:56 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0PEIuK0013955; Wed, 25 Jan 2017 14:18:56 GMT
To: Martin Bjorklund , kwatsen@juniper.net
References:  <003354d9-841f-37b2-a594-6e9983110984@cisco.com> <093ED4A3-081D-418A-B233-E75148133635@juniper.net> <20170124.202630.843995888894291234.mbj@tail-f.com>
From: Benoit Claise 
Message-ID: 
Date: Wed, 25 Jan 2017 15:18: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
In-Reply-To: <20170124.202630.843995888894291234.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------33490600001C2B85C2AB92B0"
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] example modules in 6087bis
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, 25 Jan 2017 14:19:02 -0000

This is a multi-part message in MIME format.
--------------33490600001C2B85C2AB92B0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 1/24/2017 8:26 PM, Martin Bjorklund wrote:
> Kent Watsen  wrote:
>> Hi Andy,
>>
>> I think this discussion has come to a head.  Please submit an updated 6087bis as soon as you can.  Some comments:
>>
>>
>> 1) on the 3rd line below, should the text clarify that --ietf is only for IETF modules?  Also, how does the MUST here jive with the SHOULD in Section 4.10?
>>
>>     - MUST use CODE BEGINS for a real module
>>     - MUST NOT use CODE BEGINS for an example module
>>     - MUST pass pyang --ietf for a real module
>>     - MUST pass pyang for example module
>>
>>
>> 2) related to #1, Section 5 says "In general, modules in IETF Standards Track specifications MUST comply with all syntactic and semantic requirements of YANG [RFC7950]."
>>
>>     First, what does "In general...MUST" mean?  - maybe the
>>     sentence should start with "Modules in IETF..."?
>>
>>     Second, can we add a statement for non-IETF SDOs that might
>>     have other conventions/restrictions?  Would we recommend
>>     --strict for starters, until they can add an SDO-specific
>>     flag (e.g., --) to pyang?
> We wouldn't talk about any specific tool;
Note that the document does already.
See section 4.4:

    The 'pyang' compiler can be used to produce the tree diagram, using
        the '-f tree' command line parameter.

        If the YANG module is comprised of groupings only, then the tree
        diagram SHOULD contain the groupings.  The 'pyang' compiler can be
        used to produce a tree diagram with groupings using the '-f tree
        --tree-print-groupings" command line parameters.

Reviewing this yesterday, I was wondering: why not speak of yanglint?
In discussion with Radek about this, he mentioned:

    yes, libyang supports the tree format. However, in some details it differs from pyang:

    - instead of the module prefixes, we use module names to avoid prefix collisions.
    - additionally, the default values (of the the leaf/leaf-lists/choice) are printed

regards, Benoit
> we'd just talk about
> compliance with this document.  Other SDOs will have to decide on
> their own rules, but we can suggest that they use all our rules except
> the naming convention for modules and namespaces.
>
>
>> 3) The first paragraph in Section 4.6 isn't clear, how about this?
>>
>>   OLD
>>     This section contains the module(s) defined by the specification.
>>     These modules SHOULD be written using the YANG syntax defined in
>>     [RFC7950].  YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 constructs
>>     or semantics are needed in the module.
>>
>>   NEW
>>     This section contains the module(s) defined by the YANG specification.
>>     These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax;
>>     YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs
>>     or semantics are needed in the module.
>>
>>   Note: this reads better, but I wonder, since YANG 1.0 syntax is a
>>   subset of YANG 1.1 syntax, what is really being said here? - that
>>   yang-version statement is optional?  Or maybe, instead of focusing
>>   on syntax, the statement should regard the version of YANG used?
> The point is that yang-version 1.1 SHOULD be used, and yang-version 1
> MAY be used.
>
>> 4) Lastly, picking up on this discussion:
>>
>>       https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html.
>>
>>     can add an Informational reference to RFC 4151 in Section 5.9?
>>     Maybe something like this:
>>
>>   OLD
>>
>>     The following examples are for non-Standards-Track modules.  The
>>     domain "example.com" SHOULD be used in all namespace URIs for example
>>     modules.
>>
>>         http://example.com/ns/example-interfaces
>>
>>         http://example.com/ns/example-system
>>
>>   NEW
>>
>>     The following URIs exemplify what might be used by non Standards
>>     Track modules.  Note that the domain "example.com" SHOULD be used
>>     by example modules in IETF drafts.
>>
>>     Example URIs using URLs per RFC 3986 [RFC3986]:
>>
>>         http://example.com/ns/example-interfaces
>>         http://example.com/ns/example-system
>>
>>     Example URIs using tags per RFC 4151 [RFC4151]:
>>   
>>         tag:example.com,2017:example-interfaces
>>         tag:example.com,2017:example-system
> I would like to see urn:example:, that's what I usually
> use here.
>
>
> /martin
> .
>


--------------33490600001C2B85C2AB92B0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 1/24/2017 8:26 PM, Martin Bjorklund
      wrote:

    

    

      
Kent Watsen <kwatsen@juniper.net> wrote:


      

        
Hi Andy,

I think this discussion has come to a head.  Please submit an updated 6087bis as soon as you can.  Some comments:


1) on the 3rd line below, should the text clarify that --ietf is only for IETF modules?  Also, how does the MUST here jive with the SHOULD in Section 4.10?

   - MUST use CODE BEGINS for a real module
   - MUST NOT use CODE BEGINS for an example module
   - MUST pass pyang --ietf for a real module
   - MUST pass pyang for example module


2) related to #1, Section 5 says "In general, modules in IETF Standards Track specifications MUST comply with all syntactic and semantic requirements of YANG [RFC7950]."

   First, what does "In general...MUST" mean?  - maybe the 
   sentence should start with "Modules in IETF..."?

   Second, can we add a statement for non-IETF SDOs that might
   have other conventions/restrictions?  Would we recommend
   --strict for starters, until they can add an SDO-specific
   flag (e.g., --<sdo>) to pyang?


      

      
We wouldn't talk about any specific tool; 

    

    Note that the document does already.

    See section 4.4:

    

      
The 'pyang' compiler can be used to produce the tree diagram, using
   the '-f tree' command line parameter.

   If the YANG module is comprised of groupings only, then the tree
   diagram SHOULD contain the groupings.  The 'pyang' compiler can be
   used to produce a tree diagram with groupings using the '-f tree
   --tree-print-groupings" command line parameters.

    

    Reviewing this yesterday, I was wondering: why not speak of
    yanglint?

    In discussion with Radek about this, he mentioned:

    

      
yes, libyang supports the tree format. However, in some details it differs from pyang:

- instead of the module prefixes, we use module names to avoid prefix collisions.
- additionally, the default values (of the the leaf/leaf-lists/choice) are printed

    

    regards, Benoit

    

      
we'd just talk about
compliance with this document.  Other SDOs will have to decide on
their own rules, but we can suggest that they use all our rules except
the naming convention for modules and namespaces.




      

        
3) The first paragraph in Section 4.6 isn't clear, how about this?

 OLD
   This section contains the module(s) defined by the specification.
   These modules SHOULD be written using the YANG syntax defined in
   [RFC7950].  YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 constructs
   or semantics are needed in the module.

 NEW
   This section contains the module(s) defined by the YANG specification.
   These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax;
   YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs
   or semantics are needed in the module.

 Note: this reads better, but I wonder, since YANG 1.0 syntax is a
 subset of YANG 1.1 syntax, what is really being said here? - that
 yang-version statement is optional?  Or maybe, instead of focusing
 on syntax, the statement should regard the version of YANG used?


      

      
The point is that yang-version 1.1 SHOULD be used, and yang-version 1
MAY be used.



      

        
4) Lastly, picking up on this discussion:

     https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html.

   can add an Informational reference to RFC 4151 in Section 5.9?
   Maybe something like this:

 OLD

   The following examples are for non-Standards-Track modules.  The
   domain "example.com" SHOULD be used in all namespace URIs for example
   modules.

       http://example.com/ns/example-interfaces

       http://example.com/ns/example-system

 NEW

   The following URIs exemplify what might be used by non Standards
   Track modules.  Note that the domain "example.com" SHOULD be used
   by example modules in IETF drafts.

   Example URIs using URLs per RFC 3986 [RFC3986]:

       http://example.com/ns/example-interfaces
       http://example.com/ns/example-system

   Example URIs using tags per RFC 4151 [RFC4151]:
 
       tag:example.com,2017:example-interfaces
       tag:example.com,2017:example-system


      

      
I would like to see urn:example:<module-name>, that's what I usually
use here.


/martin
.



    

    

  


--------------33490600001C2B85C2AB92B0--


From nobody Wed Jan 25 06:25: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 8601212996D for ; Wed, 25 Jan 2017 06:25:41 -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 8xIFqFRztHyo for ; Wed, 25 Jan 2017 06:25:38 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 76FFB12995C for ; Wed, 25 Jan 2017 06:25:38 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 07E071AE043A; Wed, 25 Jan 2017 15:25:36 +0100 (CET)
Date: Wed, 25 Jan 2017 15:25:35 +0100 (CET)
Message-Id: <20170125.152535.1898418340937171624.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: 
References: <093ED4A3-081D-418A-B233-E75148133635@juniper.net> <20170124.202630.843995888894291234.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: netmod@ietf.org
Subject: Re: [netmod] example modules in 6087bis
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, 25 Jan 2017 14:25:41 -0000

Benoit Claise  wrote:
> On 1/24/2017 8:26 PM, Martin Bjorklund wrote:
> > Kent Watsen  wrote:
> >> Hi Andy,
> >>
> >> I think this discussion has come to a head.  Please submit an updated
> >> 6087bis as soon as you can.  Some comments:
> >>
> >>
> >> 1) on the 3rd line below, should the text clarify that --ietf is only
> >> for IETF modules?  Also, how does the MUST here jive with the SHOULD
> >> in Section 4.10?
> >>
> >>     - MUST use CODE BEGINS for a real module
> >>     - MUST NOT use CODE BEGINS for an example module
> >>     - MUST pass pyang --ietf for a real module
> >>     - MUST pass pyang for example module
> >>
> >>
> >> 2) related to #1, Section 5 says "In general, modules in IETF
> >> Standards Track specifications MUST comply with all syntactic and
> >> semantic requirements of YANG [RFC7950]."
> >>
> >>     First, what does "In general...MUST" mean?  - maybe the
> >>     sentence should start with "Modules in IETF..."?
> >>
> >>     Second, can we add a statement for non-IETF SDOs that might
> >>     have other conventions/restrictions?  Would we recommend
> >>     --strict for starters, until they can add an SDO-specific
> >>     flag (e.g., --) to pyang?
> > We wouldn't talk about any specific tool;
> Note that the document does already.

Ok.

> See section 4.4:
> 
>    The 'pyang' compiler can be used to produce the tree diagram, using
>        the '-f tree' command line parameter.
> 
>        If the YANG module is comprised of groupings only, then the tree
>        diagram SHOULD contain the groupings.  The 'pyang' compiler can be
>        used to produce a tree diagram with groupings using the '-f tree
>        --tree-print-groupings" command line parameters.
> 
> Reviewing this yesterday, I was wondering: why not speak of yanglint?

Ok, well I just didn't want to push any specific tool.  It is fine if
the doc mentions some tools that gets the job done.


/martin


> In discussion with Radek about this, he mentioned:
> 
>    yes, libyang supports the tree format. However, in some details it
>    differs from pyang:
> 
>    - instead of the module prefixes, we use module names to avoid prefix
>      collisions.
>    - additionally, the default values (of the the leaf/leaf-lists/choice)
>      are printed
> 
> regards, Benoit
> > we'd just talk about
> > compliance with this document.  Other SDOs will have to decide on
> > their own rules, but we can suggest that they use all our rules except
> > the naming convention for modules and namespaces.
> >
> >
> >> 3) The first paragraph in Section 4.6 isn't clear, how about this?
> >>
> >>   OLD
> >>     This section contains the module(s) defined by the specification.
> >>     These modules SHOULD be written using the YANG syntax defined in
> >>     [RFC7950].  YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 constructs
> >>     or semantics are needed in the module.
> >>
> >>   NEW
> >>     This section contains the module(s) defined by the YANG specification.
> >>     These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax;
> >>     YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs
> >>     or semantics are needed in the module.
> >>
> >>   Note: this reads better, but I wonder, since YANG 1.0 syntax is a
> >>   subset of YANG 1.1 syntax, what is really being said here? - that
> >>   yang-version statement is optional?  Or maybe, instead of focusing
> >>   on syntax, the statement should regard the version of YANG used?
> > The point is that yang-version 1.1 SHOULD be used, and yang-version 1
> > MAY be used.
> >
> >> 4) Lastly, picking up on this discussion:
> >>
> >>       https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html.
> >>
> >>     can add an Informational reference to RFC 4151 in Section 5.9?
> >>     Maybe something like this:
> >>
> >>   OLD
> >>
> >>     The following examples are for non-Standards-Track modules.  The
> >>     domain "example.com" SHOULD be used in all namespace URIs for example
> >>     modules.
> >>
> >>         http://example.com/ns/example-interfaces
> >>
> >>         http://example.com/ns/example-system
> >>
> >>   NEW
> >>
> >>     The following URIs exemplify what might be used by non Standards
> >>     Track modules.  Note that the domain "example.com" SHOULD be used
> >>     by example modules in IETF drafts.
> >>
> >>     Example URIs using URLs per RFC 3986 [RFC3986]:
> >>
> >>         http://example.com/ns/example-interfaces
> >>         http://example.com/ns/example-system
> >>
> >>     Example URIs using tags per RFC 4151 [RFC4151]:
> >>           tag:example.com,2017:example-interfaces
> >>         tag:example.com,2017:example-system
> > I would like to see urn:example:, that's what I usually
> > use here.
> >
> >
> > /martin
> > .
> >
> 


From nobody Wed Jan 25 06:26: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 ED98212996F; Wed, 25 Jan 2017 06:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level: 
X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQiqgrO2LLJP; Wed, 25 Jan 2017 06:26:56 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8AA12995C; Wed, 25 Jan 2017 06:26:56 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 258D3B81257; Wed, 25 Jan 2017 06:26:56 -0800 (PST)
To: mvasko@cesnet.cz, mbj@tail-f.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170125142656.258D3B81257@rfc-editor.org>
Date: Wed, 25 Jan 2017 06:26:56 -0800 (PST)
Archived-At: 
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Verified] RFC7950 (4916)
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, 25 Jan 2017 14:26:58 -0000

The following errata report has been verified for RFC7950,
"The YANG 1.1 Data Modeling Language". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7950&eid=4916

--------------------------------------
Status: Verified
Type: Technical

Reported by: Michal Vasko 
Date Reported: 2017-01-24
Verified by: Benoit Claise (IESG)

Section: 7.17.

Original Text
-------------
If the target node is a container, list, case, input, output, or
notification node, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used within the "augment"
statement.

Corrected Text
--------------
If the target node is a container, list, case, input, output, or
notification node, the "anydata", "anyxml", "container", "leaf",
"list", "leaf-list", "uses", and "choice" statements can be used
within the "augment" statement.

Notes
-----
It was forgotten to mention "anydata" and "anyxml" as valid substatements in this case.

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Wed Jan 25 07:03: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 D6B7C129978 for ; Wed, 25 Jan 2017 07:02:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0Jm_XYinYIuk for ; Wed, 25 Jan 2017 07:02:57 -0800 (PST)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 28E34129985 for ; Wed, 25 Jan 2017 07:02:57 -0800 (PST)
Received: by mail-yb0-x236.google.com with SMTP id f67so8854447ybc.2 for ; Wed, 25 Jan 2017 07:02:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=haE3mMNGPTZWWI1amlezUwRMLcPAtes6102ZYkQrczk=; b=FDCzP7a6QpRfueX16z3nOpGlXoq8Rq16uZokClynV/wky4kVHQGL34OVGQS9091c99 vFD8mqnfm+85IeMtC+JqvO3GIFKnlmeMKsOoTRft/v4ndAZjF3D4IMhVF81JjSKj4kQy +zc+Sk0IcvIyPwFXmiGhm70lAgX4OA1WL21hWJtDjX94AJj0aAzA+A2RN9UBPSiw2y5T eJ05JzUjpjdu1fyKYI7YOUzWsVMdwadYP7edpqqI6PELqPzFNQNn+cQKnhsPGfScRagg GuMt5LemviWursQnyYjZ1gqjl3HikGLDLXeGTTfpN/dnfTZ2ebnqKUQQ8m/3ScYN0EZn Z+rA==
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=haE3mMNGPTZWWI1amlezUwRMLcPAtes6102ZYkQrczk=; b=KQ4duLvdSXVGbppxPQRi/2JiLc1UPCm2mkvhgcsbbHtN5JwCXW694xWXR0poLFfTJi 2JYg90AQEA9Qxch+7tq5+YqxYp4zJztZIAeaApqM2ksJmmEgn6/ODED/wKyqjXzNGaeW 0/P0kudlVw0KXxvA4mKoSxG+JdM4WdytMWme6twTKEebKAnSqA73Ttwh6enKhkQ5LdQx EHCvCogUNPrjLRrgYx5WN140SHLnb64+Oi2w9SKGYpQn3bQEoRNRC9vQI25RiMqzrubd N191LYfuZhNO4OoVpS9DOeeo0cJoaAFhMNBOqEwDmGlEWg5lZV/22PNjCk7u1gAc35cu MeAA==
X-Gm-Message-State: AIkVDXI3gxOQFvmVUolroVnalstDBZvDJ7WImIfXZlj6mJ+TbRkDb5lpqxX/3PK3foR7SVvgB7K0/sLHccMpFQ==
X-Received: by 10.129.178.197 with SMTP id q188mr30544775ywh.34.1485356576271;  Wed, 25 Jan 2017 07:02:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.50.67 with HTTP; Wed, 25 Jan 2017 07:02:55 -0800 (PST)
In-Reply-To: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com>
References: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com>
From: Vinod Kumar 
Date: Wed, 25 Jan 2017 20:32:55 +0530
Message-ID: 
To: Balazs Lengyel 
Content-Type: multipart/alternative; boundary=94eb2c13d50a17fcf30546ec87f4
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] New proposal: Yang Schema annotation
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, 25 Jan 2017 15:02:59 -0000

--94eb2c13d50a17fcf30546ec87f4
Content-Type: text/plain; charset=UTF-8

Hi Balazs,
    Yes we do agree, that there is a need to associate additional
information with the data modeled objects, based on the use cases the kind
of information required and interpretation would vary.
     So we had defined a generic extension for annotations, as per the
below draft (which will be refreshed shortly) .
https://tools.ietf.org/html/draft-agv-netmod-yang-compiler-metadata-01
     We feel that we could have a unified generic extension, which can be
used to annotate the schema objects.
      Kindly let us know your opinion in this regard.

Thanks and Regards,
Vinod Kumar S.

On Wed, Jan 25, 2017 at 2:21 PM, Balazs Lengyel  wrote:

> Hello,
>
> As a result of work coming from the Yangpush effort I just posted a draft
> https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00
>
> This proposes a way to extend YANG modules with extra properties for
> specific schema nodes without modifying the text of the original YANG
> module. We have a strong need for this in Yangpush, but it would be
> useful/needed outside Yangpush as well.
>
> Please review, comment!
>
> regards Balazs
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--94eb2c13d50a17fcf30546ec87f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Balazs=
,
=C2=A0 =C2=A0 Yes w=
e do agree, that there is a need to associate additional information with t=
he data modeled objects, based on the use cases the kind of information req=
uired and interpretation would vary.
=C2=A0 =C2=A0 =C2=A0So we had defined a generic extension f=
or annotations, as per the below draft (which will be refreshed shortly) .<=
/div>
=C2=A0=
 =C2=A0 =C2=A0We feel that we could have a unified generic extension, which=
 can be used to annotate the schema objects.
=C2=A0 =C2=A0 =C2=A0 Kindly let us know your opinio=
n in this regard.
Thanks and Regards,=

Vinod Kumar S.
=


On Wed, Jan=
 25, 2017 at 2:21 PM, Balazs Lengyel <balazs.lengyel@ericsson.co=
m> wrote:
Hello,



As a result of work coming from the Yangpush effort I just posted a draft
https://tools.ietf.org/html/dr<=
wbr>aft-lengyel-netmod-schema-annotation-00



This proposes a way to extend YANG modules with extra properties for specif=
ic schema nodes without modifying the text of the original YANG module. We =
have a strong need for this in Yangpush, but it would be useful/needed outs=
ide Yangpush as well.



Please review, comment!



regards Balazs



-- 

Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

Senior Specialist

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



_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




--94eb2c13d50a17fcf30546ec87f4--


From nobody Wed Jan 25 07:14: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 9D707129995 for ; Wed, 25 Jan 2017 07:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.387
X-Spam-Level: 
X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 7MdZHjBMBYz0 for ; Wed, 25 Jan 2017 07:14:06 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4103F12999B for ; Wed, 25 Jan 2017 07:14:06 -0800 (PST)
X-AuditID: c1b4fb25-5ba3c980000036c9-f7-5888c0bc04d6
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by  (Symantec Mail Security) with SMTP id 80.EF.14025.CB0C8885; Wed, 25 Jan 2017 16:14:04 +0100 (CET)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 25 Jan 2017 16:14:02 +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=f25Qe/GnD3LE2qiriEopHyBBCaaYd9BMBMY7yVTSUtc=; b=lhMXWz5emi+pS1DRF/JBjzm7/pdN91mWVrND1N4de2DE8+rW6n38crKAqT4VCX0LzfpOjGFF31EEfiDSn2gBUJVO/f1X2p8ro25VrUEeTj7HECnW8Q55ToA2ezQhfgW1w7IrSTXa1UNYFXXrvx8FElE4OdQ6yYNCWYyOcBhywSk=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.197.152] (91.82.100.59) by AM2PR07MB0945.eurprd07.prod.outlook.com (10.162.37.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Wed, 25 Jan 2017 15:14:00 +0000
To: Ladislav Lhotka , "netmod@ietf.org" 
References: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com> 
From: Balazs Lengyel 
Message-ID: <2ffc61fe-e54c-ec09-38be-58ed82a218ce@ericsson.com>
Date: Wed, 25 Jan 2017 16:13: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
In-Reply-To: 
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [91.82.100.59]
X-ClientProxiedBy: DB6P195CA0002.EURP195.PROD.OUTLOOK.COM (10.171.120.140) To AM2PR07MB0945.eurprd07.prod.outlook.com (10.162.37.140)
X-MS-Office365-Filtering-Correlation-Id: 7b826492-0bde-4863-74d1-08d44534cacc
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0945;
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0945; 3:M6qxQFq/T5Xy7tMycoolZtkEYL7kgRVhfBCo1j5CmkWP+kfOLST6ulqDjcZ9oUx3j0QoLftI9zgr6TFIJqJqmWiFwPAtSu2Mp2yfHJYhAjbC9TFHB9Ald4ZuITZsQAZE21tsAehl3dN9RWaWp/XKzgTzmWt3/L2qUOPfDLezrR19C/hFp0SGdoctrCoglwexKPVzmC9lEsXIVJ8Ngs/7FaI/azgv9wsr+CXS/7bUvCe3856dGBtd1txw0EIz4TvnmNQcOYKXFy9mUyTemRzKyA==; 25:aJfprmK23K9OsLNQWSB5rdk1aGCdlzZlMHytUv5w2fh7femsIhkmzoX8RGGOqEL+a1jMH9MPMorEbluSaxEAHGfQNbF5HUp2550lJDemvh0+B7kV+r0lKNQLepisyNWVSf96yx3N/RcNAC5tC2BD8RPqAwvJcKTczFGFO4czQwiaDMm29Lokx4Kl8tHl/kzXddGu9Ws5nvANFjfirGpfV/3jhBGfFXYHgI2IuluYJIqyQonmM/iF859sYGAVbd4JLRZfAjOG/Xpz5ZACkf8LadRpRIg+KcARrcjsirWIxpHxiHnIms+ZMqXJQHiuactI1EI7zfUK75jFYB1UXL6vHG9N/cPKFUMoeSX5iMfI+KsUC6EXrMvgTI6CezQf8nliio7GabNoj+Dka3KtP7m2wikENBnLY/STeoGq1oOnynzWU1Jd5t88RYDfGiSsAGnpeybdq9pjkExdNJC3bFmz5g==
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0945; 31:ppLpUKWDH3iEz4WYraMDKbDrw8J9ko69amwHi3Z7lJ0QHUHiLq3KwOCUOxRPXDBMwYqw49RxT9FNi0XR9ANtlBC0Ze1WSS1TS3MNGM2poez7zEpc7clRjJveWEwvQKFGQohUnYmNQZVl690C0qMwiLw7sJm8N7l3nZS7lvUUZ7U59mblbWYZk9sI5juNlK9LcN/AHcBnmG2RQrD/iGbvLtWDpMiI9uVm3hOw7vkW2GLatGZaLTbp8Gs3A8DomP5mTsYrN3DH4CLMIuw5eCKAJQ==; 20:YY2Kj2yh7n0zorG3tbDG5ltjOX2C7zzOgrh/xw1oBqINPVjngySVytJiFmN3E1FRiFQtY0gqzrHsGOdjDMUms8ZgNMLrRFRYsg7A1tu8l11fjTiqCIoBWea3QcGhREM8pZfaeZnyAaHAtk32gG9aERgTfrYsv1yzmBzQuRY3jd2ARpCZb2cDMospTsmP3OSCUyLKdyYrZ1+bYe0YOYHM+ooB9e/1M0SI6EalkxG6BX2mlG7YsCBZy+oZmWMpYDTxdpf81Y1ZWmT8ZROyjg/G4phQ+YNc+fg3MSXOsIXu1Dr0RX2PXjn15QjztTZ14W7mM1YjsUvWrSm1zzXjsvFBwN4jB/N+thG98j6/vK8KasvDAdEFIsrXWteBwnzQ4VYuDJuI5nw8h1fporHKSoqBeC2X7WH9HJpQFP+BE3ZOzVCrmD2PELhVeqBEBT5KCOxNRizyAtxVyaes8iQOoXg9EHfHMLZx1+TDxlSQHblTB9/kgqPkyiEsBfqMta/a2B5z
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)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:AM2PR07MB0945; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0945; 
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0945; 4:ZF5NLLl0QxoFZZsYh9xdTTAPwRHf1tCpscMID8m1560yoKN3YyczM+ZcxP8j3wRONS4N89t/0lMbCqBwNena54IrpRhxHhoTdEwxzg48887Gx1abfN+iBISfEdGwwVZbxJhNdrOhdhwuXsNILit2Ld6PiKJg+T4747zXOR4TuM7k+ssHlAvkgniz07W4dROsZKCyAj1IIAv1UZLB5ob4mgvYgur/L1+6EY3FA3gmouCKrrIcyN4XC5fReK3n2OPiEHGQ4m1jNqIHH0xmkO92MWMj45FR2IFbqx427iblVEODak3eOy0ac8AoPUil4WHrMhS04a4PYHLcNwW+umGdLfgB29T55tkYo9CSWUfmiU9Y716Wj/eUeVFl7YGpZ/WUILbCRWfncVX/bO3oyvNE1Ne4nMrFjJMDk14qAnJfpYQoHzOdVnUmgtKMTDItlMWw7tiOAHLiWSbC3oBCoI3j48lL63IrvSstZ/LohS6mdiaOQE49WIlcLKQoIN+XSPhtVHToUivERlRgmki5GG0SWjTjGjOvjtN2t8Q8dAWM2YppN1hThooNhn+uFq6UtCUYiFo8A50jjB7yU3oS9FxdG7+kuiet4ONwyXl1ATmWC0I=
X-Forefront-PRVS: 01986AE76B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(7916002)(39450400003)(24454002)(377424004)(252514010)(189002)(51914003)(199003)(606005)(64126003)(7906003)(5001770100001)(83506001)(8676002)(42186005)(31686004)(236005)(107886002)(101416001)(6486002)(23846002)(90366009)(15395725005)(38730400001)(25786008)(53936002)(31696002)(6306002)(92566002)(50466002)(97736004)(86362001)(2501003)(4001350100001)(229853002)(36756003)(6666003)(2950100002)(65826007)(2906002)(3846002)(68736007)(5660300001)(105586002)(65806001)(7736002)(106356001)(65956001)(81156014)(2870700001)(54356999)(66066001)(76176999)(50986999)(81166006)(189998001)(23746002)(33646002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0945; H:[159.107.197.152]; 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: =?Windows-1252?Q?1; AM2PR07MB0945; 23:lxuc7y2CmLQBLiu8FfZpM9y3yLw5/pS/xgAPs?= =?Windows-1252?Q?INfJjmKAfU/1PKhinGL5rh814uWWy7RIt0Meb19Pvb+3qtRQsNEKARFg?= =?Windows-1252?Q?UE2k5zM4JBjSHxq7f1ITLo8QN+SaMM5pvMMfk2tULAlDkpazXqBplJPX?= =?Windows-1252?Q?kE8hBBA3wrNZcSHo7Xdl/grk1B3OEgSI11B+0a7vRjOTUhuZltrgsrEK?= =?Windows-1252?Q?wONrFnOnxYnBpUx/mDmhRjuwaSV2KzRAXLUSw2XidtOQtIwbxpaNno21?= =?Windows-1252?Q?mBir3rHPVZNdSypo7mt96FmKAY3dR6xnL1H71s0s6dRA13TrSZ4eUiEc?= =?Windows-1252?Q?LYHv5oT21AtwEbV8/Yu5jz2RyHdOkibmcLAdE6HBg0dD6gatGQUG+SNF?= =?Windows-1252?Q?hhj+r5uanhAXEiqt4hteSkRKnjBGcWxlJJSmshHzFsl0KWNDk9xVleps?= =?Windows-1252?Q?LoFihpv3mtuhI5bK3clIfAFGWfrqyTs+QjnSkDfMhVWtaMEpeZ1usCk9?= =?Windows-1252?Q?/fmni0tuBaexNuUnMCrxyK0OI4y0uI6PbKQ8CktGeu8HA4OH4MXbDkC2?= =?Windows-1252?Q?dOuk8RHIYdYalC9xSd9IeW7MuA4ztKyGK8G9VqpVL7u9rGW1YKa7A8Kc?= =?Windows-1252?Q?yIsPtCPBZSqTYjdacq/l33a2PBvFTJMSlodO6EpYaMEBZYyrzHmjUoTL?= =?Windows-1252?Q?OIuJOwmayGHEj7W3N4Jr8IqYVlRo0dEGVgDPOWCUH8tiHHqbAX7v2yrZ?= =?Windows-1252?Q?qBXM3ABwQ7zZfXltYQqQeqSv+/qYfwL67GG+xRZorN91CF1XOLBiXM+w?= =?Windows-1252?Q?X9Sd5iwcvtxWzUhhhy3zb6YM92WLlFjlMpNI+y/LOsd4c0V7nev18M9n?= =?Windows-1252?Q?tUVWJFJeothjiSA7O1MZA1/wKymVhV06tHfKZLkUwU7+ZPP/icfj/98P?= =?Windows-1252?Q?aOwr5zSLvpbcJY60CSYVzXf5img/5jB4GUb4k7FE2NVF7wP3UcaEInkR?= =?Windows-1252?Q?27wJ2JOuhUURV0GDbr2ELpVygr0rBro7oUz2fEmBqSkDOQo0vuoME0lx?= =?Windows-1252?Q?MNLPpqaDTqAlzADoqNmKMP64zrbSP7uLDYnDDbJgyPWdSN6ZSwKDA5xt?= =?Windows-1252?Q?6nZMl9jJn8uqHIKBzJyN/50tTcc6LMrxp7+8hz/RzeoYwQj/xn3FAV09?= =?Windows-1252?Q?iVqgoDdcrtbmkWENCqc2NttnVZDFC8AQt4KdN6nMwSHjNqCD8eqcBkS7?= =?Windows-1252?Q?REvldbfpcGlBvIQxKTiJ3+/lEfUpt6r2Nf0gHqHET6FIhkWO5XsYjMnO?= =?Windows-1252?Q?7r+MH4Gyi9hDhfKOdgtjEQSteORUZgQlB6qrXirRAPWq8KjPxs0xhC6n?= =?Windows-1252?Q?Z0iF3hKfuNuYjOejssXYQe/7RqEXc9ytx6TcjF2hEzZAcatisntJ/JBy?= =?Windows-1252?Q?GZ8JrbuN2IRqw+swCdIRW3CDRa1/G79860vSiYrnuoblZcdw1WZ8y4Ol?= =?Windows-1252?Q?Ni8knIRB4TKjJeHedwQNOBu6/3QkoVyBOM+SSxki7z1nAB72QWke7Kcc?= =?Windows-1252?Q?S5eiO8jaYQenjQYzAox/KC/7SCeg/X1iX51?=
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0945; 6:Yhxu1eFPSaFp1Ht3z8rLt5fn2ZJGcXxho3BdzBV4Nh2WbjowTGrXmvNjRzd1V2oabP8jF0sVsp6YCz/8L7ALjym8bdnEiUkJVgpEoAoI3waMqBvtW49hl//OlodYPRpNGT4IWl1ET//C28pMJhbxML7IlXKtkbIjo67N0aiTo4Yu/gsnpPtL0rRp3J2pn+pkV3uv8U49+tp2XzVmVD0tmeL0clyJh/rOub9UioVCwJCUE+l8wCcyolq9oYykbIS9U/uBxqUmRPBqA8x+t9uITHtAKwoXOHqu13GDET/kOAXo4Z3fNAOuXxysM97qlMkbupKb4FShc5+nx3Ih27HOdAR6dy1FoisX5Vq7SdevdE8hjXD67kYFnyhudvE0He89TLHWo+5bHBn9/+zTCyy61cJwnKohMkY5+dhiPH17ypc=; 5:/0NP35eyk5mt6Vr++5R/TNIkojTijVDEX/Q1/zH7CW2Mfc6OIrnCrNKgfuhq8vOqfaYBeBmFGzBdJ5p5NBsEkrsQx0jTuV82/v5SFzKSQBtAUARH9A5eYWnBBV2tMOTxMM3THmx4XADReZAokhTBSg==; 24:WRAy4KHK39IexT5zzz4xkeN/z9bH8TjrHn7g/2q9ANHlvybn2SU0ZSIL4aooFXS2zeeoLih2zQD5W1GWdLUaxoG2PN78U253ijRC3xCOW5I=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0945; 7:C/uOYWDrmGSApzz429hwr4OLrQY4fu8skgpEiTGZ7tarFC9FlqbXgYfVKfhaJ1jx4tXBRTZpuNaowPlOG90fMhsu/FDcNVF1NrlpVAfY1PcllKqN7s6N96pmvkTH/IkpVVO0rX2TycTti4zOM5y+T+3sDJgHb/JwNGtBojm7eN3HK3DzRqjyMleEHM3yZUSBUtmu8ostC0o9kNCXTvEoN5sxdcYMpHFo8gplNlRLASdz13ShdL+BQ0Ghov8mhnkqLnPzb7hmQ37EtX9+uuYFBVIcc903j/zPRLJZalyMoZPTW3tX0M0ylcA2cT8Q5Q7yDJ2LPYwGvr4qX6D7Xec0Wm/4vThavPOXE5lMDHqpaWzeXwih5zgVwVbZqLSykrmuIx+bYrMKlvzdPYdR4a2AUzlAHDyrR1RnicXkEHNQVvV0xf0B0W2xj3RpRahf0Apj0yT7SoqWWQHvVQ8Mhga5Jw==
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2017 15:14:00.5962 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0945
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUyM2K7me6eAx0RBjOXi1tcWDWXzWL+xUZW ByaPJUt+MnlsunyHMYApissmJTUnsyy1SN8ugSvj0MKfzAVXlSpur73P2MB4UbKLkZNDQsBE ovvZQ6YuRi4OIYF1jBKr5vyBck4wSrz6t40RxGER6GWWeNm/ihmkhVEgTmLnmoWsILaQwD9G iRVvvUBsYQEridZbKxhBbBEBD4nr/RcZIWpSJS729IHVswkYSUztP88CYvMK2EscONcINpNF QFXixqvN7CC2qECMxNv1y9khagQlTs58AlTPwcEpYCBxZ5sjSJhZQF/i+p37rBC2vETz1tnM EN8oSFzffJ0F5GYJgXZGid3zr7ND3KAh8fDCX1aIIl+JlfP2soLMBLGXXzaEqF/BJnH/4yFm COcim8TBx+/ZIBqyJd4v3wS1wUri9a/vjBBFXUwSC7/8hnIWsErM/3iSBaJKRmLXjStMEImp bBKHLnbBw2LLjRY2iMQRAYlrb96wTGDUmIXk11lIHpyF5MEFjMyrGEWLU4uTctONjPVSizKT i4vz8/TyUks2MQKTxMEtv1V3MF5+43iIUYCDUYmHt2BvR4QQa2JZcWXuIUYJDmYlEd6WTUAh 3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGLNmJkdIc87f +ebZnD8TX4f0/Huyu2rOjGsK1zruye/eYxagEHgwNM3yyCszj327VGYs3DLtKecf382ZrUet FrMsPfcybMbeffzTTyi8ts5PZdpY9kkjWylU/uIK36kB81rkm6NeHs+eMGvasdtuqyp+XBB+ 9l771nxtg+9X9YTr1r/zehc5b1qSEktxRqKhFnNRcSIAYN3uCw4DAAA=
Archived-At: 
Subject: Re: [netmod] New proposal: Yang Schema annotation
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, 25 Jan 2017 15:14:09 -0000


  
    
  
  
    
Hello Lada,

    
Thanks for the support, I would like to get this in as a
      workgroup document soon.

    
Deviations are conceptually used to define ugly limitations. The
      yang-push group agreed it would be a misuse of deviations to use
      them for something constructive, like adding new schema
      information.

    
Also chapter https://tools.ietf.org/html/rfc7950#section-14
      explicitly lists the statements allowed in deviations e.g. 

    

    
   deviate-add-stmt    = deviate-keyword sep add-keyword-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [units-stmt]
                              *must-stmt
                              *unique-stmt
                              *default-stmt
                              [config-stmt]
                              [mandatory-stmt]
                              [min-elements-stmt]
                              [max-elements-stmt]
                          "}") stmtsep


    
This excludes the extension statement. :-( So adding extensions
      by deviations would modify RFC7950.

    
My pyang did not accept devext.yang.

    

    
(Side-note: there are other statements that should be but are not
      allowed by deviations like description, status, identity, enum
      etc. )

    

    
regards Balazs

    

    

    
On 2017-01-25 13:41, Ladislav Lhotka
      wrote:

    

    

      
Hi Balazs,

I agree that such a mechanism would be pretty useful.

I think though that the deviation-based approach can be used without
further ado. Why do you think that the "deviate" statement cannot handle
extension statements? AFAICT, the following module satisfies all rules
of RFC 7950, and it is then up to an implementation to handle the
extension, so it can also add it as an annotation to the target node.

module devext {
  namespace "http://example.com/devext";
  prefix de;
  import ietf-interfaces {
    prefix if;
  }
  extension foo;
  deviation "/if:interfaces" {
    deviate "add" {
      de:foo;
    }
  }
}

Lada

Balazs Lengyel <balazs.lengyel@ericsson.com> writes:



      

        
Hello,

As a result of work coming from the Yangpush effort I just posted a draft
https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00

This proposes a way to extend YANG modules with extra properties for 
specific schema nodes without modifying the text of the original YANG 
module. We have a strong need for this in Yangpush, but it would be 
useful/needed outside Yangpush as well.

Please review, comment!

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com

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


      

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Wed Jan 25 07:29:36 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 1329B129984 for ; Wed, 25 Jan 2017 07:29:35 -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 g4fwohqBuzwx for ; Wed, 25 Jan 2017 07:29:33 -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 1274612997D for ; Wed, 25 Jan 2017 07:29:33 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:4ddc:23a1:fb6b:398c] (unknown [IPv6:2001:718:1a02:1:4ddc:23a1:fb6b:398c]) by mail.nic.cz (Postfix) with ESMTPSA id 955DB607DD; Wed, 25 Jan 2017 16:29:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485358171; bh=D5IksBZ8vsKG6j043vvz5JZG3FYhZFZsr0FGMr08koE=; h=From:Date:To; b=lGaQx1Scon+UfU4vxd+AzBtYDSV29wi1DlUFuvgbfHQ0eazr5yHBWlHlELqx/P+3c hG1IxTLC2/5o3fQo4WXfRZQ2nFAEQ5VDDfaYh8JrRvmEowv30qxaX5vHxmVZXHFMKQ B1byvsUmrvuEKPsRbvdIkFJqTu+ece5xNgTxxdAo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <2ffc61fe-e54c-ec09-38be-58ed82a218ce@ericsson.com>
Date: Wed, 25 Jan 2017 16:29:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com>  <2ffc61fe-e54c-ec09-38be-58ed82a218ce@ericsson.com>
To: Balazs Lengyel 
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] New proposal: Yang Schema annotation
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, 25 Jan 2017 15:29:35 -0000

> On 25 Jan 2017, at 16:13, Balazs Lengyel  =
wrote:
>=20
> Hello Lada,
>=20
> Thanks for the support, I would like to get this in as a workgroup =
document soon.
>=20
> Deviations are conceptually used to define ugly limitations. The =
yang-push group agreed it would be a misuse of deviations to use them =
for something constructive, like adding new schema information.

I don't think this is a big problem. Another similar and simple solution =
might be to permit "augment" with no substatements - it cannot IMO cause =
any harm. And then extensions could be piggybacked in it.

>=20
> Also chapter https://tools.ietf.org/html/rfc7950#section-14 explicitly =
lists the statements allowed in deviations e.g.=20
>    deviate-add-stmt    =3D deviate-keyword sep add-keyword-str optsep
>                          (";" /
>                           "{" stmtsep
>                               ;; these stmts can appear in any order
>                               [units-stmt]
>                               *must-stmt
>                               *unique-stmt
>                               *default-stmt
>                               [config-stmt]
>                               [mandatory-stmt]
>                               [min-elements-stmt]
>                               [max-elements-stmt]
>                           "}") stmtsep
>=20
> This excludes the extension statement. :-(  So adding extensions by =
deviations would modify RFC7950.

Actually, no, extension statement can be derived form the "stmtsep" =
non-terminal:

   stmtsep             =3D *(WSP / line-break / unknown-statement)

   ;; represents the usage of an extension
   unknown-statement   =3D prefix ":" identifier [sep string] optsep
                         (";" /
                          "{" optsep
                              *((yang-stmt / unknown-statement) optsep)
                           "}") stmtsep


>=20
> My pyang did not accept devext.yang.

Yes, I know, it probably even crashed:

https://github.com/mbj4668/pyang/issues/300

> (Side-note: there are other statements that should be but are not =
allowed by deviations like description, status, identity, enum etc. )

Yes, this was already discussed.

Lada

> regards Balazs
>=20
> On 2017-01-25 13:41, Ladislav Lhotka wrote:
>> Hi Balazs,
>>=20
>> I agree that such a mechanism would be pretty useful.
>>=20
>> I think though that the deviation-based approach can be used without
>> further ado. Why do you think that the "deviate" statement cannot =
handle
>> extension statements? AFAICT, the following module satisfies all =
rules
>> of RFC 7950, and it is then up to an implementation to handle the
>> extension, so it can also add it as an annotation to the target node.
>>=20
>> module devext {
>>   namespace=20
>> "http://example.com/devext"
>> ;
>>   prefix de;
>>   import ietf-interfaces {
>>     prefix if;
>>   }
>>   extension foo;
>>   deviation "/if:interfaces" {
>>     deviate "add" {
>>       de:foo;
>>     }
>>   }
>> }
>>=20
>> Lada
>>=20
>> Balazs Lengyel=20
>> 
>>  writes:
>>=20
>>=20
>>> Hello,
>>>=20
>>> As a result of work coming from the Yangpush effort I just posted a =
draft
>>>=20
>>> =
https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00
>>>=20
>>>=20
>>> This proposes a way to extend YANG modules with extra properties for=20=

>>> specific schema nodes without modifying the text of the original =
YANG=20
>>> module. We have a strong need for this in Yangpush, but it would be=20=

>>> useful/needed outside Yangpush as well.
>>>=20
>>> Please review, comment!
>>>=20
>>> regards Balazs
>>>=20
>>> --=20
>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>> Senior Specialist
>>> Mobile: +36-70-330-7909              email:=20
>>> Balazs.Lengyel@ericsson.com
>>>=20
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>>=20
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email:=20
> Balazs.Lengyel@ericsson.com
> =20
>=20

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






From nobody Wed Jan 25 07:40:46 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 5428B129984 for ; Wed, 25 Jan 2017 07:40:45 -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 4Ck0z9UiryhK for ; Wed, 25 Jan 2017 07:40:44 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 022C812984C for ; Wed, 25 Jan 2017 07:40:44 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id A73AE1AE043A; Wed, 25 Jan 2017 16:40:42 +0100 (CET)
Date: Wed, 25 Jan 2017 16:40:40 +0100 (CET)
Message-Id: <20170125.164040.388971263136159631.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <2ffc61fe-e54c-ec09-38be-58ed82a218ce@ericsson.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: netmod@ietf.org
Subject: Re: [netmod] New proposal: Yang Schema annotation
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, 25 Jan 2017 15:40:45 -0000

Ladislav Lhotka  wrote:
> 
> > On 25 Jan 2017, at 16:13, Balazs Lengyel 
> > wrote:
> > 
> > Hello Lada,
> > 
> > Thanks for the support, I would like to get this in as a workgroup
> > document soon.
> > 
> > Deviations are conceptually used to define ugly limitations. The
> > yang-push group agreed it would be a misuse of deviations to use them
> > for something constructive, like adding new schema information.
> 
> I don't think this is a big problem. Another similar and simple
> solution might be to permit "augment" with no substatements - it
> cannot IMO cause any harm. And then extensions could be piggybacked in
> it.
> 
> > 
> > Also chapter https://tools.ietf.org/html/rfc7950#section-14 explicitly
> > lists the statements allowed in deviations e.g.
> >    deviate-add-stmt    = deviate-keyword sep add-keyword-str optsep
> >                          (";" /
> >                           "{" stmtsep
> >                               ;; these stmts can appear in any order
> >                               [units-stmt]
> >                               *must-stmt
> >                               *unique-stmt
> >                               *default-stmt
> >                               [config-stmt]
> >                               [mandatory-stmt]
> >                               [min-elements-stmt]
> >                               [max-elements-stmt]
> >                           "}") stmtsep
> > 
> > This excludes the extension statement. :-( So adding extensions by
> > deviations would modify RFC7950.
> 
> Actually, no, extension statement can be derived form the "stmtsep"
> non-terminal:
> 
>    stmtsep             = *(WSP / line-break / unknown-statement)
> 
>    ;; represents the usage of an extension
>    unknown-statement   = prefix ":" identifier [sep string] optsep
>                          (";" /
>                           "{" optsep
>                               *((yang-stmt / unknown-statement) optsep)
>                            "}") stmtsep

Furthermore, RFC 7950, section 7.20.3.2 says:

   If the target node has a property defined by an extension, this
   property can be deviated if the extension allows deviations.  See
   Section 7.19 for details.

and 7.19 says:

   An extension can allow refinement (see Section 7.13.2) and deviations
   (Section 7.20.3.2), but the mechanism for how this is defined is
   outside the scope of this specification.



/martin


From nobody Wed Jan 25 07:42: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 50F2112984C for ; Wed, 25 Jan 2017 07:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 UbYoqRhA6Edt for ; Wed, 25 Jan 2017 07:42:42 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3445112999D for ; Wed, 25 Jan 2017 07:42:42 -0800 (PST)
X-AuditID: c1b4fb3a-d4bff70000004068-cc-5888c76fc8b6
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by  (Symantec Mail Security) with SMTP id C2.4C.16488.F67C8885; Wed, 25 Jan 2017 16:42:40 +0100 (CET)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 25 Jan 2017 16:42:39 +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=zdnMhY4VBSGs/ZOoCoCKpneiQib1ErRqifKE9dlIiyk=; b=THNbS+U9FhzLmoj8kUY/Nf4VWLnaGjJasHw0KMfs/Bh4Wwzz3E5DLqHTHij4nyeoVekhhk4pZjwUhj0VAo+Hw9grBA7HNcM3XdRANuZ6xsMOxIzWDPVUywRtH2WRkK6PDPHyZMkfXP4NzvhsxnM/5tyhXv5fydJjzOaIK672qyo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.197.152] (91.82.100.59) by AM2PR07MB0948.eurprd07.prod.outlook.com (10.162.37.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Wed, 25 Jan 2017 15:42:37 +0000
To: Ladislav Lhotka 
References: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com>  <2ffc61fe-e54c-ec09-38be-58ed82a218ce@ericsson.com> 
From: Balazs Lengyel 
Message-ID: <04fae532-6024-db57-4d3d-cc6298cc2fca@ericsson.com>
Date: Wed, 25 Jan 2017 16:42:32 +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: 
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [91.82.100.59]
X-ClientProxiedBy: DB5PR0301CA0026.eurprd03.prod.outlook.com (10.167.222.164) To AM2PR07MB0948.eurprd07.prod.outlook.com (10.162.37.143)
X-MS-Office365-Filtering-Correlation-Id: 653ff69e-3dee-4058-a7c4-08d44538ca56
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0948;
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0948; 3:rDglEvd4Sb2c2+djbvFI5SHw12tbPHDa9SB5u+TpMDaEX0nJYoppzOkURea+kxnByunOtWBiE00fvmNFl1r0UU/Q/gtKPw+LZr9Uc5r+fNdxlQFBqaoN6ywWhx66O7YaelwxMeOZR0ip05sCrKTGT5E1UaZim6foIvjf6RI2PKxpYmnPwMDDBS1++J7O/yKZS1WRnMIMr+inoJU3zAE0P9JybUK0+dQni4VdqwhQ9wf2wgFcMWxptR2sSfRhDvhiohDy6x7VRXPyVApu0EQpLw==
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM2PR07MB0948; 25:SiKVBrX3YaKNgFYFzGDu9svIM1C3hVrLwzgcT?= =?Windows-1252?Q?jv+JMHm12wTS19nr/OSkpFql+3yvMGCeb2dglZXYE8MsVgsZC80Y1N3s?= =?Windows-1252?Q?44+oj9azXJ1SWa+HPfTGOzYrk35INfqSUo1h6R6dyTVOMlrB7IN0JqCc?= =?Windows-1252?Q?0EP2H10+Z76X8+Ba9HCaNOBgro3nt/rR/0Cfwv9zd3v+zitoxksOlXTR?= =?Windows-1252?Q?+HDN4xQhaUx/tbh1kVlbCx+2VYIiJrCGBS8qYEmqApfF/6AVcqZXseSF?= =?Windows-1252?Q?njj3fBbUq8A86Y6Jl763E99nhURMP9Q1CF2+8NsUUHHCEA37TxDE3X/p?= =?Windows-1252?Q?/kxR6HPI6U7EljXAC1Oj1J9sDndnQHidc6uDcnKuncmSehN5EPGze/kK?= =?Windows-1252?Q?saLe96AdYT1RuBmpguS+bqXC0tp0ft74lCoNh+80W1SExNBP45pnoSsr?= =?Windows-1252?Q?wJLm9QXM/HdXiAb034c3aVK0j6684kHtMwYiG5vCRVlCLyu0YlsBqOq8?= =?Windows-1252?Q?53/VEPnI9oCYUNvuRBcaFb/OZF5AFbPUkGu4LIOZoe5u/YiK9Wm2/L6Q?= =?Windows-1252?Q?VMfuCa29ulKPWd4w7pRP+j5MRe8QDS0U9TgkAv50TtciJkbIXlAWQhic?= =?Windows-1252?Q?BcwvRrl3IzxnJlWdrozt/kFn3SACJPZujcAcdxnodwlzCkAkIoPWd570?= =?Windows-1252?Q?9j9ISffeGMA5D4RTsypGogEkHVsZWgwx1FX2WTQBDVCGEtdGu6aES6p1?= =?Windows-1252?Q?dLsEOjQmGs9jiCxNwsz7nytUSgezIA/oJurI+Iz4E9LcXFbcq5h5z0RI?= =?Windows-1252?Q?XiEuSJmI1HaTqiSZorPnMmuOAKa/p/k05UeDK316sXRciBz2H1NlvwX0?= =?Windows-1252?Q?nG1bYJWkQRPLjCgBF6HMqiMza/tljcjeKKmK/8TGvLYq/I+MoNqlsdfR?= =?Windows-1252?Q?kq4Aq4iOooyX5bfSvjIbQTeQDDJc2UJQ33kDhubn00lYZZN3e17FrK/+?= =?Windows-1252?Q?J0z/CcwBzSCdsiTxOHW5IqheO8ML7tWqVEc2qA4SmL545tdGatNGW4uP?= =?Windows-1252?Q?w67hXPsQpwK46E=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0948; 31:JdeMGThnakPhDHsn9yVrchUuoU0v8Ju38Me/ay3W4gIs/Sx8rvsR+NzT3Uuyh/3DYrzTABafoe9y/vl6Vc9Xz7z/6EM0V6u0saAL8vF0YOIzQ96D4jP7cObJRdJNN0fCDQKiliaotz3Rc+PwN1NrB584O/MMDozP+ymeBIAGmIajqaQD9G95om1ToUDEpc57n+GLbIO2AYQRbgYO/nTaE5TIWncbRqtSDMC98Bhzoljgm3oUrjLQqnJjgxtxU380YfhKKxcFgA/o7OhztL53Jg==; 20:iewPxBHt5lEvWi3gTOKvGz5vlF8bQR4KhLi0Y7bzhZ3z4Arm6gUyJ+j75lJKRtDH8oZ9X2nW5l4X26izzD3n64YIixE3vHUAxh/3y+FqexmDKHHQKMGuFF6Ph0mlswy3d8te2RrPBTLId2B6CK8409ZxDXaBueCg3n5eVFrALaN14DLw3YCFrkdaI4yqSWtCkwF3VkbgGlrvK9UjzwVtDbN+9QKeHm8hDpU3Y1XjvcaeJ09IVxLjwE760A6nre51r58NQLdRNwIEI4SPuAja9pBkBHKjAmNS1FyAShWjKv7cRayxUEQnXcjHLV8f6VEOKhu0OAIQ+mbYFfdJYGAQjhKagfqID5Qe9tDD7gr0a6StwsxX+je8KSREMIWFz7ADvbS1s7tsIIXkiYAC+lLiyykpeZ5cRJV8iamsAKaakrWXuOT296t6XS674NlhxHSsb1CjSDjIvCBxxRT0C6DXRZp4gzEbxCquPIYT+5JQjSaGl+1+alVB6Gpkodv12t6u
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(166708455590820);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:AM2PR07MB0948; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0948; 
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0948; 4:Tlbz11bDg3SPCO3M/O7p6GY6rWWdt25/yVnbSOVwzmh11fHuNlokf5JF2Cxqc2y7y7/gUiupyqgLBKXXIZCaDPIClUMR13YE0VhVbLJzq+Ytr5YmfTAXovU/lWniIVVr7drcwEybshtidSN5hqHKbr4iaKHk0pUhs8sQXcb5NL+VJclGFAKzchqXCTnwxOU2rfIWYqbC046478+ZppX55EJ+Hc60IzlvWJ7Tahg/AH/sMALolLXzeXqXtx/Ed2IV4KyFzWAMw8g5G1ClNV/iFarD4EvNoIt8zqcgT293tNLigee6PKmFFH+DHxA2Yqqz4mdvyuXc19WQwEHTlqiTHxg9OF+q9WSDVSDWtGsEBH4NXXdm940wZXTJmwg7gQMQ1at5ssD6d1HJRh9EQypNOlH0SkG/8gxbsW33jcrdxu+VzXS/nqm0UZhWTRwUtXdUhXqQOdQ8iAYETP+aZqd0u/0piAUZMi8fY4OBaBHkHRh5SpOb5nT8Lhsi2s91WfYNDTg9y+T//bxnX0ndqKAmfMYTkPNk3hNpKuDxQH2SrZJ5vt4tV9V920GSF7vyJK7JxSPMe+WmZKQTvOfzisrJ6gZWw5mojuG4xJI4icEGjZQF++0QsJEpi7CVL9WZoIZmzY/5ULNHxPzpqMAq7pSnKg==
X-Forefront-PRVS: 01986AE76B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(7916002)(39450400003)(252514010)(51914003)(189002)(24454002)(377424004)(199003)(6306002)(38730400001)(81166006)(90366009)(236005)(53936002)(230700001)(606005)(25786008)(86362001)(66066001)(36756003)(50986999)(65956001)(6486002)(15395725005)(65806001)(54356999)(33646002)(76176999)(23746002)(42186005)(101416001)(31686004)(4001350100001)(105586002)(106356001)(93886004)(229853002)(83506001)(8676002)(31696002)(6916009)(2906002)(65826007)(4326007)(64126003)(110136003)(5660300001)(189998001)(81156014)(68736007)(7906003)(6116002)(97736004)(92566002)(7736002)(23846002)(2950100002)(3846002)(50466002)(6666003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0948; H:[159.107.197.152]; 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: =?Windows-1252?Q?1; AM2PR07MB0948; 23:ksnFRpyW3vUUA6whECQ1BHo+zInRHUIYkDL8S?= =?Windows-1252?Q?kX0VqK4LUOhEPKjf5QoKAmHZ5j+w4RJWXxsNLNKcreIZfYPJwDwuHr0S?= =?Windows-1252?Q?KQnv1twEDRIj3VJQYDV+v72x0vs+OfFQYOoRvg98vl6Vk2Y24aGPg53U?= =?Windows-1252?Q?QEz2troLVH6u2hK0ma5p4/0mA7I4yEJi+jIif6nP+0FJhvHvtZVqLvfe?= =?Windows-1252?Q?pe2hrkDamQniCDduYwgpqKcEwWAoFEwDJKwazPWPQ6wcFNx1GzWfMNR7?= =?Windows-1252?Q?cQrRZjgtIBzUbN9VG0t9r6JkL/riIZUABgY9Ieaf8XnqJJzekYylikms?= =?Windows-1252?Q?PLK5E4hcR6P7vhtvgiNdx2ubRhIpD2QTZ2ZfsqEVwe6riV2G+8xx70VQ?= =?Windows-1252?Q?j/EtlCkjl1VIrFshtIpUYTFlhu9rIfMFNBQq6dhB6+tvjPpzLhmvdaH1?= =?Windows-1252?Q?i7olL6qCeanLtKPO3J4awrOpb6ad77HeEdzri+gjCZmEfv3Yz2qp4Oaa?= =?Windows-1252?Q?DTHDM0TyTv04cZS2D16CDXe+hXAZH/aEL0qwBReh01GwPPLMZmIMfMm0?= =?Windows-1252?Q?fsCkV4ZeHoKe0zSBygXSuMJKY85FyhbItsF8UjG83rUQnIqBqjjTtkcR?= =?Windows-1252?Q?5aUHRvWuIi4Td2UVDTGk2pSHTDoblB0q6NHb4QTUBxunH+eHBHoC5jF3?= =?Windows-1252?Q?4o+9coUVtZOUsOwr/hgHV9c90ve6ypJfgf2NSFhB/8c3+rfXhHc+Wd4P?= =?Windows-1252?Q?F3bp3gfuQcsq0tqzDRTH64/xI0msYItcFg58Ae3YO+NvIfglnJULJx4y?= =?Windows-1252?Q?E5YQo3OjBGXn9D+kBalAHuSbGZqFp2eNVrslOuat/n58Nvtvz8Wsc3VL?= =?Windows-1252?Q?ZLWoOUnPPr1u+VqVzBv0/bL4J+u9evi3WR8W2rnJC3XOT0G15/cwGGIX?= =?Windows-1252?Q?/kElTNQlgEPDKi9iSn6BuOUUh8WCcs0x7tyXzfOwm9Jv0rBUy9E5jXv7?= =?Windows-1252?Q?jrd2PjIk6phsh1eC6uYo0rz9Eeb2sDsddNYiA+DdN+G+vGqhKvEBjHbW?= =?Windows-1252?Q?+KRD5rxqQtoLOWqmDbJq9ZGHwWVFBowzudH3Sn2Nv6/f5FLcAO/Ut00a?= =?Windows-1252?Q?nLdjWJqMgK1j0z6e1E0+RqzWl37hOTMoSCezAiaYLZsOqiy1iVyVyVn8?= =?Windows-1252?Q?uvkmpuXPnsTotHvzss4t8AixbhZ8dtBBDJIbafrGX6928z12f3YRp9JH?= =?Windows-1252?Q?bdD+1EsffVKZpqbWnuNdiBDMp6tn09NyNRiRcZ0zrzVEq8OYvj7NLVEB?= =?Windows-1252?Q?IawT40LMclmHGr+5AiGs2q5b3N/WfaOTil5OdBzcl4QvpTgJsNABan4+?= =?Windows-1252?Q?NZYJ+1wx6fTBiLv/fZX0J9Mgv1zo1HjHl4w9wSGTuWqkgZyqdQ6rUOsS?= =?Windows-1252?Q?Ok3GdqU05Ok8dCwf/gW4HVLvmSNmTrmLhnaUaYYiZj4Fhb3K0zT8qZL3?= =?Windows-1252?Q?YN80ulEYGJUp4V6Q87WF9cXbe710sdmARkyZwUm36vmXBlmd7pcJspsr?= =?Windows-1252?Q?8oaRuyharZ/BSGxalcM7kMn2Cj7Hn1PSdCK?=
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0948; 6:DU214SiKeulv2CC2XXSZeR4LF2BwAnCdlHbzg+qwSEzhjbjDUfl6go518WeC5ymJi67B2at8L0cZ4e4roeNUYCd0oMfoHrjHqsqHNCsVmaDpEG+jO2suZrrSx7sgo15nF7eK576uMidvVHTRG8qGldI6cu1VFUW+bOGYAZc/1/BdyGsps3jPuZN2laJyODXs2g4i7tEGQVOb+3Jnth3Mu+eyMYgVQbE2ztxt1NkNngJe9YDhXLT2uMH0G1jZOaqrr55+7G+wwdp+gx8iBtbRiPrZLztLEkr/dmBETp83pS76uN8DsLlB6dhXVjCLBCB/b/PwljiyAoazT9ePkzC/nuLmW1EVztts7v9BvLLDbDwC6n/t6Q3U0uMvkOInp4WPiyNTkg+HFnm4f65OVIraE/v/hUFz841xl9VTws1edS0=; 5:tPfRf7DaQmTbJq7C5XQ0BZgasjvhhixq/Vl7HgNOJvWQXl0/9PdgLc12IE3PES4Slz/zvCMK9oCjN8yp40/CTSdELqo/hHGLYBdAMmfJM0rIVrYRCTJRv1JhqVmT2Pny6Dm7QNrelZUoIAI7R8YCbA==; 24:ihAJJNAsrV62QXcnrJ3/LK4paaUk53B/JQXD+UquA7Y6aAXqyHavWHLENZuz8+5hr3OFzG0c+CPmCsovyJUSHL44so6kDN4eFqcZ6AAtchE=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0948; 7:bgcqeddgBpb08MK6zZQhH3iDiJmOVXe48m7eK2CNY/FhlmqAkGtY0Zo6ar7mJ+8bgFyAcrNRyrkeaL4QpKylvxiMfWniaXyVN44trmoShWWZIbboMuBFVmrGpihwytW1hOQvLm1emJl2ufYYpoyfqs4Q/8SIol8DHG8YM/e5NdNKE3FclMSe7DAMS+U+RMD+FfgaCZUa5ExYHeMv+7cFY/AkvUcH/wh4EXH1Espl/SjN/kc0Dl8yCF0oDL2T30LEmV2EHgs0eLDJJK+D6Iw1auPSGMjKjLGYwxK3HHeN1iGMYL9817uB/vqx3QW6Qd1q4UKEL4ZtLA8uY2t95XfoIXEaPbrfM/b9J4BY0nzAJoWZtCJ9CSvuZqLwBCRfb/+CwWZf+QETmi9uMs3l83va3jrn0dnoEHY4WNS4VJLZA671T7ObWcrDjHu3KN+1uDoM/7xoNWzpb/VdYUm1Y7f9gA==
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2017 15:42:37.8161 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0948
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUyM2K7pW7B8Y4Ig9mf5S0urJrLZjH/YiOr A5PHkiU/mTw2Xb7DGMAUxWWTkpqTWZZapG+XwJXxovMPW8FPk4r2L5oNjKvUuhg5OCQETCSW /a7tYuTiEBJYxyix5tUhpi5GTiDnBKPEmenmIAkWgV5miQ17TzGCJBgF4iR2rlnIClH0j1Hi 3AcJEFtYwEqi9dYKsBoRAWWJixN+skBMPc0o8eXscbAGZgF1iTunHrOB2GwCRhJT+8+zgNi8 AvYSR4+8ALNZBFQlLq09AlYjKhAj8Xb9cnaIGkGJkzOfgNVwAi2b9mAFC8RMfYnrd+5DzZeX 2P52DjOILSGgIHF983WwIyQEuhgl7nXtYIS4WkPi4YW/rBBFvhIPb99hhrEbnk9lg2g4wyTx 6/sPJojEIW6JK985IBIX2SRedDWwQSSyJVad/csIYXtLvJ64ghVqHZPE1k+rmaFGsUr8e9UL 1SEjsevGFSaIxAw2if0zFrFPYNSaheTBWUiemoXkqQWMzKsYRYtTi4tz042M9FKLMpOLi/Pz 9PJSSzYxAlPEwS2/rXYwHnzueIhRgINRiYe3YG9HhBBrYllxZe4hRgkOZiURXv+jQCHelMTK qtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4pRoY9VObdBplhSSEGQ89 27BhpaVffb+/hpKcSrliz8WFLuLzX959mcYWvnfqpCXbZi63nqiw4Zl3yvcrvI/K5y9Zre33 k729M/XwM6FePVu3PvPdEzL55KW27o+Nn/Hs/m2bf6f8OIslF/g0rrqwanFyn9kVvSS+M4Kr m/7uuPP3xePG/5cz8jujlViKMxINtZiLihMBKr5GLg0DAAA=
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] New proposal: Yang Schema annotation
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, 25 Jan 2017 15:42:44 -0000


  
    
  
  
    
I see a problem. 

    

    
   unknown-statement   = prefix ":" identifier [sep string] optsep
                         (";" /
                          "{" optsep
                              *((yang-stmt / unknown-statement) optsep)
                           "}") stmtsep

This, as I read it, does not allow for an argument. Am I misreading it or is this an error ???
Balazs


    

    
On 2017-01-25 16:29, Ladislav Lhotka
      wrote:

    

    

      

      

        
On 25 Jan 2017, at 16:13, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello Lada,

Thanks for the support, I would like to get this in as a workgroup document soon.

Deviations are conceptually used to define ugly limitations. The yang-push group agreed it would be a misuse of deviations to use them for something constructive, like adding new schema information.


      

      
I don't think this is a big problem. Another similar and simple solution might be to permit "augment" with no substatements - it cannot IMO cause any harm. And then extensions could be piggybacked in it.



      

        
Also chapter https://tools.ietf.org/html/rfc7950#section-14 explicitly lists the statements allowed in deviations e.g. 
   deviate-add-stmt    = deviate-keyword sep add-keyword-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [units-stmt]
                              *must-stmt
                              *unique-stmt
                              *default-stmt
                              [config-stmt]
                              [mandatory-stmt]
                              [min-elements-stmt]
                              [max-elements-stmt]
                          "}") stmtsep

This excludes the extension statement. :-(  So adding extensions by deviations would modify RFC7950.


      

      
Actually, no, extension statement can be derived form the "stmtsep" non-terminal:

   stmtsep             = *(WSP / line-break / unknown-statement)

   ;; represents the usage of an extension
   unknown-statement   = prefix ":" identifier [sep string] optsep
                         (";" /
                          "{" optsep
                              *((yang-stmt / unknown-statement) optsep)
                           "}") stmtsep




      

        
My pyang did not accept devext.yang.


      

      
Yes, I know, it probably even crashed:

https://github.com/mbj4668/pyang/issues/300



      

        
(Side-note: there are other statements that should be but are not allowed by deviations like description, status, identity, enum etc. )


      

      
Yes, this was already discussed.

Lada



      

        
regards Balazs

On 2017-01-25 13:41, Ladislav Lhotka wrote:


        

          
Hi Balazs,

I agree that such a mechanism would be pretty useful.

I think though that the deviation-based approach can be used without
further ado. Why do you think that the "deviate" statement cannot handle
extension statements? AFAICT, the following module satisfies all rules
of RFC 7950, and it is then up to an implementation to handle the
extension, so it can also add it as an annotation to the target node.

module devext {
  namespace 
"http://example.com/devext"
;
  prefix de;
  import ietf-interfaces {
    prefix if;
  }
  extension foo;
  deviation "/if:interfaces" {
    deviate "add" {
      de:foo;
    }
  }
}

Lada

Balazs Lengyel 
<balazs.lengyel@ericsson.com>
 writes:




          

            
Hello,

As a result of work coming from the Yangpush effort I just posted a draft

https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00


This proposes a way to extend YANG modules with extra properties for 
specific schema nodes without modifying the text of the original YANG 
module. We have a strong need for this in Yangpush, but it would be 
useful/needed outside Yangpush as well.

Please review, comment!

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: 
Balazs.Lengyel@ericsson.com


_______________________________________________
netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


          

        

        
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: 
Balazs.Lengyel@ericsson.com
 



      

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








    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Wed Jan 25 07:50:35 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 9AD391299B9 for ; Wed, 25 Jan 2017 07:50:32 -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 NLb6NEhqyof3 for ; Wed, 25 Jan 2017 07:50:31 -0800 (PST)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED12412984C for ; Wed, 25 Jan 2017 07:50:30 -0800 (PST)
Received: by mail-qk0-x22f.google.com with SMTP id 11so76071138qkl.3 for ; Wed, 25 Jan 2017 07:50:30 -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=gvuFvKWGodoCJttn27/b1fpCav6aeBjjDZpdRT3/w9o=; b=EsoFMKhbFABTnWxJsenCqzUxap/odFdBX/GYdp8wqMgfAPJLS0ulqnELKLWB03TkNX +2281rbSIPGb0FpFUug+sdFNC8hmTD54a4JTgKiU/Bbzz3Vj0JeCQw0HOYQ3hz8ziqad soB2Zrz4RGqNSWtGclo5bM4wdtiggVVn+AvpShn9FNGOfqEvTNdirpBbM20JH6okeKWr aAN14xp4nA2au+1Mxf3hB7xQGRxB8M3/IVTxxEDFPPcyfbef269YNdf+94SqAZwqiP3D CxWRZEQo/tNJDvMc+6iAncqxNiwhc4yAkFuGV3qGwCcXzLt7ngqeAGSZwEwbqFclYEL9 FNGg==
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=gvuFvKWGodoCJttn27/b1fpCav6aeBjjDZpdRT3/w9o=; b=b1ZB0USxsTVqr+Pa6fcCAScNg8l3UCJGzrB5C0HOIjf9UA4ZuZP4fNhBABKl7Ou9pB ZaGXBgXet64jg4nhW/X5xkHFRR0QBGI2so1Qqi2xHYkik4hVQm6wIPF38dysY4AyHq5j ZBQrMBAY5LrKUnNQHI+TEgYv65L2BN47xQc6XaSbcnkJ6QPfl74uhJeYoAnCDrcctOL5 HfhKFvYqu4z5atmYU+VWoUEO4puSidr6vtvDC0JYcCpKnljPciqUZZ2c2f1dMAXUSw4D D0G+YGOuPcBd8AtL5ml5VFwHXb1IDPgtRxwnsEJQmv//1i7nPlu2lSWQjDo+o5G1JMxE 47WA==
X-Gm-Message-State: AIkVDXII0ERVNWrSLD6vSCH6Nq86nlONsEEX+2SiyVzLNw4HK/9ldJqiy+iL+Nwu2LtyUtiioAflxKDDrER9WQ==
X-Received: by 10.55.135.197 with SMTP id j188mr34383099qkd.71.1485359430121;  Wed, 25 Jan 2017 07:50:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Wed, 25 Jan 2017 07:50:29 -0800 (PST)
In-Reply-To: 
References: <0df38f7a-7127-7a6f-3974-15ffbdc9b542@ericsson.com> 
From: Andy Bierman 
Date: Wed, 25 Jan 2017 07:50:29 -0800
Message-ID: 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=94eb2c0777e63256cf0546ed3155
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] New proposal: Yang Schema annotation
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, 25 Jan 2017 15:50:33 -0000

--94eb2c0777e63256cf0546ed3155
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 25, 2017 at 4:41 AM, Ladislav Lhotka  wrote:

> Hi Balazs,
>
> I agree that such a mechanism would be pretty useful.
>
> I think though that the deviation-based approach can be used without
> further ado. Why do you think that the "deviate" statement cannot handle
> extension statements? AFAICT, the following module satisfies all rules
> of RFC 7950, and it is then up to an implementation to handle the
> extension, so it can also add it as an annotation to the target node.
>
>

We fully implement the use of deviations in this manner.
We even call a deviation module that is not supposed to be advertised
as an annotation.

I agree that YANG 1.1 supports this use of deviations.


Andy


> module devext {
>   namespace "http://example.com/devext";
>   prefix de;
>   import ietf-interfaces {
>     prefix if;
>   }
>   extension foo;
>   deviation "/if:interfaces" {
>     deviate "add" {
>       de:foo;
>     }
>   }
> }
>
> Lada
>
> Balazs Lengyel  writes:
>
> > Hello,
> >
> > As a result of work coming from the Yangpush effort I just posted a draft
> > https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00
> >
> > This proposes a way to extend YANG modules with extra properties for
> > specific schema nodes without modifying the text of the original YANG
> > module. We have a strong need for this in Yangpush, but it would be
> > useful/needed outside Yangpush as well.
> >
> > Please review, comment!
> >
> > regards Balazs
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--94eb2c0777e63256cf0546ed3155
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 25, 2017 at 4:41 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:
Hi Balazs,



I agree that such a mechanism would be pretty useful.



I think though that the deviation-based approach can be used without

further ado. Why do you think that the "deviate" statement cannot=
 handle

extension statements? AFAICT, the following module satisfies all rules

of RFC 7950, and it is then up to an implementation to handle the

extension, so it can also add it as an annotation to the target node.




We fully implement the =
use of deviations in this manner.
We even call a deviation module=
 that is not supposed to be advertised
as an annotation.

I agree that YANG 1.1 supports this use of deviations.


Andy
=C2=A0

module devext {

=C2=A0 namespace "http://example.com/devext";

=C2=A0 prefix de;

=C2=A0 import ietf-interfaces {

=C2=A0 =C2=A0 prefix if;

=C2=A0 }

=C2=A0 extension foo;

=C2=A0 deviation "/if:interfaces" {

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

=C2=A0 =C2=A0 =C2=A0 de:foo;

=C2=A0 =C2=A0 }

=C2=A0 }

}



Lada



Balazs Lengyel <balazs.le=
ngyel@ericsson.com> writes:



> Hello,

>

> As a result of work coming from the Yangpush effort I just posted a dr=
aft

> https://tools.ietf.org/htm=
l/draft-lengyel-netmod-schema-annotation-00

>

> This proposes a way to extend YANG modules with extra properties for
> specific schema nodes without modifying the text of the original YANG<=
br>
> module. We have a strong need for this in Yangpush, but it would be
> useful/needed outside Yangpush as well.

>

> Please review, comment!

>

> regards Balazs

>

> --

> Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

> Senior Specialist

> Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 email: Balazs.Lengyel@er=
icsson.com

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--94eb2c0777e63256cf0546ed3155--


From nobody Wed Jan 25 17:52: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 8FB6E129410 for ; Wed, 25 Jan 2017 17:52:39 -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 pWlwBKsfT1eP for ; Wed, 25 Jan 2017 17:52:37 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0107.outbound.protection.outlook.com [104.47.36.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E63129440 for ; Wed, 25 Jan 2017 17:52:37 -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=ZL6haCHXU0C4UC6W4k8cl8hW1fbimRjDtTi1lRKvFeM=; b=W6ra8jcrmsqHvR4ZG8GB29TiXgi0AxfB2jKZTUDifYTyUjo5zJvuReg1oHTtft3zD13dunBRgL9I1ldvAvoY4YuCr4i6VwiryXdHH4uHb4AMIPuNr8NlPUSJe6+nYL/hvFkuipZFKB7JXr8UQp6FuG6r+OprcBtY4AxOJUklJfw=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Thu, 26 Jan 2017 01:52:35 +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.0874.015; Thu, 26 Jan 2017 01:52:35 +0000
From: Kent Watsen 
To: Ladislav Lhotka , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= 
Thread-Topic: [netmod] notifications...and yang-next
Thread-Index: AQHSd3bc7ZotfHwWMkCKRm0P31YCAQ==
Date: Thu, 26 Jan 2017 01:52:34 +0000
Message-ID: <7F5166BE-B7F5-4A6E-AB5C-2E4087E7FD4C@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1e.0.170107
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 18f1897f-80af-4133-2359-08d4458dffda
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1444; 
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:1eXgDNLbFi6YA8g8jNIA0qwfwecXzPwcvmWZU5n3z1vluYO5kXcPSymbkxzweUautu9OSST1+NU6TYnEhAqXHbuFfo+FygSGodab0kQ+T7pkDfnDOcZlYNgQnG0Y1Ww3ZZx9z0y9E6/iH8YHYE343g0MyQ8px+IT/bYsJ355Nl3XTzI/rL24oi/Do3OMUdq7n82oUBgkMwusTOKxK+K4kOlHDaCZqtONe02Wn+zJNdKoNKI2AkcQIzUJsnsgz0RuqGf/3kK57KthYbu/luSRdpZRBHfOc64An00MAhgW/gYC7OG6Pl4G+ipCL7+5tmKXB6Nj5k9Oiwn6YRVPkt5mpD0mjDNHuutghIZUP2YZboKHTw/S1x4+ZpSyBN+avDt/7tRR6nkTkK6HAMzNiEXbl0O8+SAcNAv2imt03xnGw0hNILeoX5sI+w7Ru2OvaUJNZB1uk6eQEFSxtdSzIGhubA==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; 
x-forefront-prvs: 019919A9E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39450400003)(39860400002)(39850400002)(51444003)(189002)(199003)(189998001)(81166006)(3660700001)(8936002)(229853002)(36756003)(99286003)(83716003)(38730400001)(81156014)(8676002)(83506001)(106116001)(106356001)(97736004)(105586002)(86362001)(92566002)(66066001)(33656002)(82746002)(5001770100001)(4001350100001)(15650500001)(2900100001)(3280700002)(54356999)(50986999)(6512007)(25786008)(68736007)(5660300001)(122556002)(6506006)(6306002)(2906002)(101416001)(305945005)(3846002)(6116002)(102836003)(77096006)(7736002)(4326007)(6486002)(53936002)(6436002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: <4AC08288E761D8408DE2EE4F2C4F2230@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2017 01:52:34.8730 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] notifications...and yang-next
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, 26 Jan 2017 01:52:39 -0000

DQpUaGUgTkVUQ09ORiBhbmQgTkVUTU9EIGNoYWlycyBhcmUgYWN0aXZlbHkgZGlzY3Vzc2luZyBo
b3cgd2UgbWlnaHQgbW92ZSBjb250ZW50IGFyb3VuZCBiZXR3ZWVuIGRyYWZ0cyBtYWludGFpbmVk
IGJ5IHRoZSB0d28gZ3JvdXBzLiAgUmVzb2x2aW5nIHRoaXMgbm90aWZpY2F0aW9uIHN0YXRlbWVu
dCBpc3N1ZSBpcyBwYXJ0IG9mIHRoYXQuICBIZXJlIGFyZSBzb21lIG9mIG15IHRob3VnaHRzIGFi
b3V0IHRoaXM6DQoNCjEpIEkgdGhpbmsgdGhhdCBZQU5HIGlzIHByaW1hcmlseSB1c2VkIHRvIGRl
ZmluZSB0aGUgbm90aWZpY2F0aW9uJ3MgZGF0YSB0cmVlLCB0aGUgcGF5bG9hZCwgd2hpY2ggbWF5
IGJlIHdyYXBwZWQgYnkgYSBwcm90b2NvbC1zcGVjaWZpYyBlbnZlbG9wIHRoYXQgaW5jbHVkZXMs
IGZvciBpbnN0YW5jZSwgYSB0aW1lc3RhbXAuICBUaGlzIGJlaW5nIHRoZSBjYXNlLCBJJ20gaG9w
aW5nIHRoYXQgdGhlcmUgaXNuJ3QgbXVjaCB0byBkbyBoZXJlLiANCg0KMikgWWVzLCBSRkMgNzk1
MCByZWZlcmVuY2VzIFJGQyA1Mjc3LCBidXQgbm90ZSB0aGF0IGl0IGRvZXMgc28gb25seSBpbiBh
IHNlY3Rpb24gY2FsbGVkICJORVRDT05GIFhNTCBFbmNvZGluZyBSdWxlcyIuICBJdCBpcyBteSBo
b3BlIHRoYXQgd2Ugd2lsbCBtb3ZlIGFsbCBzdWNoIHNlY3Rpb25zIG91dCBpbiB0aGUgbmV4dCBy
ZXZpc2lvbiBSRkMgNzk1MCAoc2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1u
ZXh0L2lzc3Vlcy8xMSkNCg0KMykgQWJvdmUgYW5kIGJleW9uZCB0aGUgbm90aWZpY2F0aW9uIHN0
YXRlbWVudCBpc3N1ZSwgTGFkYSBhbHNvIG5vdGVzIHRoYXQgUkZDIDc5NTAgU2VjdGlvbiAzIHJl
ZmVyZW5jZXMgUkZDIDYyNDEgZm9yIHNvbWUgdGVybXMuICBJIGJlbGlldmUgdGhhdCwgaW4gb3Jk
ZXIgdG8gcmVtb3ZlIHRoZXNlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIDYyNDEsIHRoZXNlIHRl
cm1zIHNob3VsZCBiZSBtb3ZlZCB0byB0aGUgcmV2aXNlZC1kYXRhc3RvcmUgZHJhZnQgKHNlZSBo
dHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXMvMTIpLg0KDQpUaG91
Z2h0cz8NCg0KDQpLZW50IC8vIG1vc3RseSBhcyBhIGNvbnRyaWJ1dG9yDQoNCg0KDQo=


From nobody Wed Jan 25 17:59:08 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 759F2129430 for ; Wed, 25 Jan 2017 17:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 70uEgKmqoWj7 for ; Wed, 25 Jan 2017 17:59:05 -0800 (PST)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC95D129410 for ; Wed, 25 Jan 2017 17:59:05 -0800 (PST)
Received: by mail-pf0-x241.google.com with SMTP id 19so15449106pfo.3 for ; Wed, 25 Jan 2017 17:59:05 -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:message-id:references :to; bh=QtL7GuzIqsbb7XGc2rWlCZMkdzLM7sZdG5NzLDR/o5A=; b=bswzri1khjTD7++0v8bADX0XijS4m8l3FgJlmg+M0Bzyw9q+38NzqXYp1XcE6Vg/Sm Qn6f1QyC03J0rgGBfi7UimFOhDQCNup2UUGX1xCijPi/RoSSM+8Jjv0+r+2YOeu9IqEg 2qmWsFAO0F677Jb9w6uL0XprAAqR+XIXpgIHbafqjxaZF/bH667hST5XxAGlzc62cyai j4BUPFc+Ba5Y32D3A0Y8lEIw4EC27NUchKzSoLcTfaPu3a6+Nypuaa4nzc1YJPScEPYy yToBGmOHpj7OzS6ol+6UgkKIL062pStb6TyAbu3N0BB4xhDRHZmeeY2Rbt4LjjRLO5MY X7XA==
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 :message-id:references:to; bh=QtL7GuzIqsbb7XGc2rWlCZMkdzLM7sZdG5NzLDR/o5A=; b=nY/I1kQdt5/YFGrvMh8CLkzB9ycSqS/BK4RAoksaQC5JPgVUs2So2uDhjdDYTxdymq eyb2GEG+7/B8SPuAAcHvkDuOnG9O3GQRpFFBdhMBJo6sYtG31+yMXsBv3H5wWEcQ4lnv CJ9PZlg8pNLL8To2Cct5gS1zSu/UIl3PspWGVCO+NE3mSrf6dGHjk/L00WfdROT3RGMG Z1XAYkglA8DnCNBA5/zpDOnHuAoFC0/eoqIJHJt6bba/ewbC687pZLhU5Dy8XUyQ7vI4 I2JV17Si62PtiXJtX0qQLlFM7Ax93+KCGAacii4nZu9trmw3hjDGlFkRi8sSEg6UEFeX NF+A==
X-Gm-Message-State: AIkVDXL0/SEpCpZySjHWiEY0f81mqg5el7OlbtpSIKdYPA0HSIjnCTwIyjdxnafxexPS0g==
X-Received: by 10.99.0.196 with SMTP id 187mr242568pga.139.1485395945088; Wed, 25 Jan 2017 17:59:05 -0800 (PST)
Received: from [10.24.52.82] ([128.107.241.184]) by smtp.gmail.com with ESMTPSA id 199sm23604pfu.91.2017.01.25.17.59.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Jan 2017 17:59:03 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_146C265C-F880-4A47-BD72-ECA2B441FC05"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Wed, 25 Jan 2017 17:59:01 -0800
Message-Id: <9DCB66AF-FB14-4AA8-A899-67E09853B9B6@gmail.com>
References:  <003354d9-841f-37b2-a594-6e9983110984@cisco.com> <093ED4A3-081D-418A-B233-E75148133635@juniper.net> <20170124.202630.843995888894291234.mbj@tail-f.com> 
To: Benoit Claise 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] example modules in 6087bis
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, 26 Jan 2017 01:59:07 -0000

--Apple-Mail=_146C265C-F880-4A47-BD72-ECA2B441FC05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On Jan 25, 2017, at 6:18 AM, Benoit Claise  wrote:
>=20
> On 1/24/2017 8:26 PM, Martin Bjorklund wrote:
>> Kent Watsen   wrote:
>>> Hi Andy,
>>>=20
>>> I think this discussion has come to a head.  Please submit an =
updated 6087bis as soon as you can.  Some comments:
>>>=20
>>>=20
>>> 1) on the 3rd line below, should the text clarify that --ietf is =
only for IETF modules?=20
Yes, and in addition yangvalidator.com  =
should stop complaining about module names and namespaces for modules =
that belong to other SDOs.

mef-cfm.yang:1: warning: RFC 6087: 4.1: the module name should start =
with one of the strings "ietf-" or "iana-"
mef-cfm.yang:3: warning: RFC 6087: 4.8: namespace value should be =
"urn:ietf:params:xml:ns:yang:mef-cfm"

>>>  Also, how does the MUST here jive with the SHOULD in Section 4.10?
>>>=20
>>>    - MUST use CODE BEGINS for a real module
>>>    - MUST NOT use CODE BEGINS for an example module
>>>    - MUST pass pyang --ietf for a real module
>>>    - MUST pass pyang for example module
>>>=20
>>>=20
>>> 2) related to #1, Section 5 says "In general, modules in IETF =
Standards Track specifications MUST comply with all syntactic and =
semantic requirements of YANG [RFC7950]."
>>>=20
>>>    First, what does "In general...MUST" mean?  - maybe the=20
>>>    sentence should start with "Modules in IETF..."?
>>>=20
>>>    Second, can we add a statement for non-IETF SDOs that might
>>>    have other conventions/restrictions?  Would we recommend
>>>    --strict for starters, until they can add an SDO-specific
>>>    flag (e.g., --) to pyang?
>> We wouldn't talk about any specific tool;=20
> Note that the document does already.
> See section 4.4:
> The 'pyang' compiler can be used to produce the tree diagram, using
>    the '-f tree' command line parameter.
>=20
>    If the YANG module is comprised of groupings only, then the tree
>    diagram SHOULD contain the groupings.  The 'pyang' compiler can be
>    used to produce a tree diagram with groupings using the '-f tree
>    --tree-print-groupings" command line parameters.
> Reviewing this yesterday, I was wondering: why not speak of yanglint?
> In discussion with Radek about this, he mentioned:
> yes, libyang supports the tree format. However, in some details it =
differs from pyang:
>=20
> - instead of the module prefixes, we use module names to avoid prefix =
collisions.
> - additionally, the default values (of the the leaf/leaf-lists/choice) =
are printed
> regards, Benoit
>> we'd just talk about
>> compliance with this document.  Other SDOs will have to decide on
>> their own rules, but we can suggest that they use all our rules =
except
>> the naming convention for modules and namespaces.
>>=20
>>=20
>>> 3) The first paragraph in Section 4.6 isn't clear, how about this?
>>>=20
>>>  OLD
>>>    This section contains the module(s) defined by the specification.
>>>    These modules SHOULD be written using the YANG syntax defined in
>>>    [RFC7950].  YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 =
constructs
>>>    or semantics are needed in the module.
>>>=20
>>>  NEW
>>>    This section contains the module(s) defined by the YANG =
specification.
>>>    These modules SHOULD be written using the YANG 1.1 [RFC7950] =
syntax;
>>>    YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs
>>>    or semantics are needed in the module.
>>>=20
>>>  Note: this reads better, but I wonder, since YANG 1.0 syntax is a
>>>  subset of YANG 1.1 syntax, what is really being said here? - that
>>>  yang-version statement is optional?  Or maybe, instead of focusing
>>>  on syntax, the statement should regard the version of YANG used?
>> The point is that yang-version 1.1 SHOULD be used, and yang-version 1
>> MAY be used.
>>=20
>>> 4) Lastly, picking up on this discussion:
>>>=20
>>>      =
https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html =
.
>>>=20
>>>    can add an Informational reference to RFC 4151 in Section 5.9?
>>>    Maybe something like this:
>>>=20
>>>  OLD
>>>=20
>>>    The following examples are for non-Standards-Track modules.  The
>>>    domain "example.com" SHOULD be used in all namespace URIs for =
example
>>>    modules.
>>>=20
>>>        http://example.com/ns/example-interfaces =

>>>=20
>>>        http://example.com/ns/example-system =

>>>=20
>>>  NEW
>>>=20
>>>    The following URIs exemplify what might be used by non Standards
>>>    Track modules.  Note that the domain "example.com" SHOULD be used
>>>    by example modules in IETF drafts.
>>>=20
>>>    Example URIs using URLs per RFC 3986 [RFC3986]:
>>>=20
>>>        http://example.com/ns/example-interfaces =

>>>        http://example.com/ns/example-system =

>>>=20
>>>    Example URIs using tags per RFC 4151 [RFC4151]:
>>> =20
>>>        tag:example.com,2017:example-interfaces
>>>        tag:example.com,2017:example-system
>> I would like to see urn:example:, that's what I usually
>> use here.
>>=20
>>=20
>> /martin
>> .
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_146C265C-F880-4A47-BD72-ECA2B441FC05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Jan 25, 2017, at 6:18 AM, Benoit Claise <bclaise@cisco.com> =
wrote:


 =20
    
 =20
  

    
On 1/24/2017 8:26 PM, Martin =
Bjorklund
      wrote:

    

    

      
Kent Watsen <kwatsen@juniper.net> =
wrote:


      

        
Hi Andy,

I think this discussion has come to a head.  Please submit an updated =
6087bis as soon as you can.  Some comments:


1) on the 3rd line below, should the text clarify that --ietf is only =
for IETF modules? =

Yes, and in =
addition yangvalidator.com should stop complaining about =
module names and namespaces for modules that belong to other =
SDOs.

mef-cfm.yang:1: =
warning: RFC 6087: 4.1: the module name should start with one of the =
strings "ietf-" or "iana-"
mef-cfm.yang:3: warning: RFC 6087: 4.8: namespace value should be =
"urn:ietf:params:xml:ns:yang:mef-cfm"

 Also, how does the MUST here jive with the SHOULD =
in Section 4.10?

   - MUST use CODE BEGINS for a real module
   - MUST NOT use CODE BEGINS for an example module
   - MUST pass pyang --ietf for a real module
   - MUST pass pyang for example module


2) related to #1, Section 5 says "In general, modules in IETF Standards =
Track specifications MUST comply with all syntactic and semantic =
requirements of YANG [RFC7950]."

   First, what does "In general...MUST" mean?  - maybe the=20
   sentence should start with "Modules in IETF..."?

   Second, can we add a statement for non-IETF SDOs that might
   have other conventions/restrictions?  Would we recommend
   --strict for starters, until they can add an SDO-specific
   flag (e.g., --<sdo>) to pyang?


      

      
We wouldn't talk about any specific =
tool; 

    

    Note that the document does already.

    See section 4.4:

    

      
The 'pyang' compiler can be used to produce =
the tree diagram, using
   the '-f tree' command line parameter.

   If the YANG module is comprised of groupings only, then the tree
   diagram SHOULD contain the groupings.  The 'pyang' compiler can be
   used to produce a tree diagram with groupings using the '-f tree
   --tree-print-groupings" command line parameters.

    

    Reviewing this yesterday, I was wondering: why not speak of
    yanglint?

    In discussion with Radek about this, he mentioned:

    

      
yes, libyang supports the tree format. =
However, in some details it differs from pyang:

- instead of the module prefixes, we use module names to avoid prefix =
collisions.
- additionally, the default values (of the the leaf/leaf-lists/choice) =
are printed

    

    regards, Benoit

    

      
we'd just talk about
compliance with this document.  Other SDOs will have to decide on
their own rules, but we can suggest that they use all our rules except
the naming convention for modules and namespaces.




      

        
3) The first paragraph in Section 4.6 =
isn't clear, how about this?

 OLD
   This section contains the module(s) defined by the specification.
   These modules SHOULD be written using the YANG syntax defined in
   [RFC7950].  YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 constructs
   or semantics are needed in the module.

 NEW
   This section contains the module(s) defined by the YANG =
specification.
   These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax;
   YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs
   or semantics are needed in the module.

 Note: this reads better, but I wonder, since YANG 1.0 syntax is a
 subset of YANG 1.1 syntax, what is really being said here? - that
 yang-version statement is optional?  Or maybe, instead of focusing
 on syntax, the statement should regard the version of YANG used?


      

      
The point is that yang-version 1.1 =
SHOULD be used, and yang-version 1
MAY be used.



      

        
4) Lastly, picking up on this =
discussion:

     https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html.

   can add an Informational reference to RFC 4151 in Section 5.9?
   Maybe something like this:

 OLD

   The following examples are for non-Standards-Track modules.  The
   domain "example.com" =
SHOULD be used in all namespace URIs for example
   modules.

       http://example.com/ns/ex=
ample-interfaces

       http://example.com/ns/exampl=
e-system

 NEW

   The following URIs exemplify what might be used by non Standards
   Track modules.  Note that the domain "example.com" SHOULD be used
   by example modules in IETF drafts.

   Example URIs using URLs per RFC 3986 [RFC3986]:

       http://example.com/ns/ex=
ample-interfaces
       http://example.com/ns/exampl=
e-system

   Example URIs using tags per RFC 4151 [RFC4151]:
=20
       tag:example.com,2017:example-interfaces
       tag:example.com,2017:example-system


      

      
I would like to see =
urn:example:<module-name>, that's what I usually
use here.


/martin
.



    

    

  


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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_146C265C-F880-4A47-BD72-ECA2B441FC05--


From nobody Fri Jan 27 11:23: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 2A272129771 for ; Fri, 27 Jan 2017 11:23: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 YVusegszN4Et for ; Fri, 27 Jan 2017 11:23:11 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 DB40A12973E for ; Fri, 27 Jan 2017 11:23:10 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id u68so23729609ywg.0 for ; Fri, 27 Jan 2017 11:23:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Hre7hBV3e9K4Uvd2SLK5yamiXc0zVyRwBj39I+UJQcw=; b=uJp7ydaWWvldj6q3EsXAjNLkKvOYrYVcnGFWk/QiVpd7NZ1GvYPsGgRkUhUXq11niH 0w6yfkJ3+wI7Af7euT50EhaRvAlIzkufihaUgNpcNVI9tGj3RirWZiexMAoMFt4wey1Z N9QqTlCHxFBj+5A8RmitKxqoYEv+sHfIUdTDi5CHwiW/nb2kfDlo6fIe4KJtnGdbT25F Fe6tR8f79jcsFlc4Nr8qvoL6lKZGOPEP88we354CkMpltGukEyU2xhMVfxxdQG+fQFI2 CvLTaNgE6teI77TzLWA5kknrbamtzu3Vpio5mMKYUe9Fg9cqg3jX0InkXYI9yB4hDTF4 62YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hre7hBV3e9K4Uvd2SLK5yamiXc0zVyRwBj39I+UJQcw=; b=r+ZlUkf1P3pS1sLYpArvyd8lfjwYOYla/q14YZljHXpVIxfld5zTlCfGdNKdGYKhFR 9AaHjnJpm9B1ff1ZkHHC5RLdsMI+A7gYZ4v94Z6b6K7WH2jme5gMuFdsjQ0H/OCF9mzk BSBPIgIux2YHhE6jMrT5bRrJ7aUfeOxyQbVLXTS0w++ry1hE4xGMNBSTld7/poVpSS5q AXPT0+CpNVGCPkEMXsN2BggZoLAPYFsLfq2bs7b1/9pLDIw//JUwuTVAnJLY14b7mCX3 Gi7nwwRokyCa5Abq2wwx9gf5WcI4ZGZur6mXAjaOTAxUFHKA2s6cwspSUlSnx+9koHCF ArOQ==
X-Gm-Message-State: AIkVDXIIb8cmW7qJHBTYk6Z1EKQpxPqVIDBUfFWVpS2gnQyHz9e7VH/7zYNrzB+RJc2gUE6gdEkM56Ky1xEG0w==
X-Received: by 10.55.153.2 with SMTP id b2mr2852864qke.314.1485544990050; Fri, 27 Jan 2017 11:23:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Fri, 27 Jan 2017 11:23:09 -0800 (PST)
From: Andy Bierman 
Date: Fri, 27 Jan 2017 11:23:09 -0800
Message-ID: 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c06252e6e54c405471865c8
Archived-At: 
Subject: [netmod] proposal to add 2 new guidelines in 6087bis
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, 27 Jan 2017 19:23:12 -0000

--94eb2c06252e6e54c405471865c8
Content-Type: text/plain; charset=UTF-8

Hi,

The "pyang --ietf" validator checks the statement order used in
data-def-stmts.
There is no guideline that says this is required.
RFC 7950 says canonical order is RECOMMENDED.


1) data-def sub-statement order
Proposal: add new last sentence to sec. 4.6, para 3:

YANG data definition sub-statements SHOULD be specified in canonical order.


2) enum/bit statement ordering

Proposal: add new para 2 to  sec 5.11.3:

The 'enum' statements within an 'enumeration' data type SHOULD be
specified in ascending order, based on the implied and/or explicit values
of the 'value' sub-statement. The 'bit' statements within a 'bits' data type
SHOULD be specified in ascending order, based on the implied and/or
explicit values of the 'position' sub-statement.



Andy

--94eb2c06252e6e54c405471865c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

The "pyang --ietf" valida=
tor checks the statement order used in data-def-stmts.
There is n=
o guideline that says this is required.
RFC 7950 says canonical o=
rder is RECOMMENDED.

1) data-def sub-statement order
Proposal: add new last sentence to sec. 4.6, para 3:

<=
/div>
YANG data definition sub-statements SHOULD be specified in canoni=
cal order.


2) enum/bit statement or=
dering

Proposal: add new para 2 to =C2=A0sec 5.11.=
3:

The 'enum' statements within an 'en=
umeration' data type SHOULD be
specified in ascending order, =
based on the implied and/or explicit values
of the 'value'=
; sub-statement. The 'bit' statements within a 'bits' data =
type
SHOULD be specified in ascending order, based on the implied=
 and/or
explicit values of the 'position' sub-statement.<=
/div>



Andy

<=
/div>


--94eb2c06252e6e54c405471865c8--


From nobody Fri Jan 27 15:06:33 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 8795B129AA2 for ; Fri, 27 Jan 2017 15:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 TwAPxfkh5WWA for ; Fri, 27 Jan 2017 15:06:30 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 A02CA129A8A for ; Fri, 27 Jan 2017 15:06:30 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id j15so165841649oih.2 for ; Fri, 27 Jan 2017 15:06:30 -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:message-id:references :to; bh=3fyxw9SCisu5O8JSz2TDAK29dFb9uabROMtZaL53wXU=; b=Vk0q7OzPS75RzuxIn4LORq/dQMIsdlODOL/lrTHvsb+a+8LPsfqoBIjTar544NfcRR Hg9q9Efj84iIyb+mAgE5qjAbvz4SNs1/Fbg5jilULNcEsBRWVi4fEloz6yHUDvQxdPkj tTX3uzCnl3Z14/EJydZHopK0IAzeXKWo8PhttnixuhdwFd3+46OcizYAFD3MpL/pA3lG KAgcha3BoMf3API0Pxm5MD8uUW+0tJ0YPG58CWvnSwq+T2aOZ9zG4BAiHYmvFIcEY6eE gbtwJhfjgcb/SuY5pml9oF3bdfYe5jSKUPGjQZrfXKyZYGzlEwzAX0oqljjMeJ7qQiqe 8fbg==
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 :message-id:references:to; bh=3fyxw9SCisu5O8JSz2TDAK29dFb9uabROMtZaL53wXU=; b=BWEQD9cFKbp7qlNF9bS8PhKWjhp0JWKzD4KF0hH6+TdbLQ0pMUuk2AV/suKj8hoTwm AanQPxL1m0Psy+HUYaHZ0Kpp6RLfNMNRBHe1W7T+Hr07T05CCQNlfe5Outd9nUPuq39J tpYEirijkw/cVjtfAGdz7UlqfRbPDP9o9WrVAdAa0Ca5xciQPB1f2ePRfMOoZik2bicu dq8NV216YjPOP89x9DPRkc+wWvtHjioWkuYB4tBcv/r99ELEKM+xyg6shiErzj/dV8zQ Dk8f3SFaruqgeBYr0sFrlLMNSTC4btFxFipnGyoAlvifY+AQiKtIub/cB+YHlUrx3xDo iXRQ==
X-Gm-Message-State: AIkVDXItq+IkTIDJGMDlERDNEp+aPsnHr+e9s2u/IB3GcvUrdDc3gusknmnw/1W2K8ILyQ==
X-Received: by 10.202.175.68 with SMTP id y65mr6772620oie.187.1485558389841; Fri, 27 Jan 2017 15:06:29 -0800 (PST)
Received: from dhcp-128-107-151-81.cisco.com (dhcp-128-107-151-81.cisco.com. [128.107.151.81]) by smtp.gmail.com with ESMTPSA id 94sm3147651otw.2.2017.01.27.15.06.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 27 Jan 2017 15:06:28 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB9A67F7-CF62-4F3B-9E65-321F07C2F9E4"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Fri, 27 Jan 2017 15:06:29 -0800
Message-Id: <29D3031A-8BC1-42C2-8306-9A4AC9A38940@gmail.com>
References: 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 27 Jan 2017 23:06:32 -0000

--Apple-Mail=_AB9A67F7-CF62-4F3B-9E65-321F07C2F9E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jan 27, 2017, at 11:23 AM, Andy Bierman  wrote:
>=20
> Hi,
>=20
> The "pyang --ietf" validator checks the statement order used in =
data-def-stmts.
> There is no guideline that says this is required.
> RFC 7950 says canonical order is RECOMMENDED.
>=20
> 1) data-def sub-statement order
> Proposal: add new last sentence to sec. 4.6, para 3:
>=20
> YANG data definition sub-statements SHOULD be specified in canonical =
order.

Not 6087bis specific =E2=80=A6

But is this IETF module specific? If not, should this not be checked by =
pyang for all modules.

>=20
>=20
> 2) enum/bit statement ordering
>=20
> Proposal: add new para 2 to  sec 5.11.3:
>=20
> The 'enum' statements within an 'enumeration' data type SHOULD be
> specified in ascending order, based on the implied and/or explicit =
values
> of the 'value' sub-statement. The 'bit' statements within a 'bits' =
data type
> SHOULD be specified in ascending order, based on the implied and/or
> explicit values of the 'position' sub-statement.

Ditto.

>=20
>=20
>=20
> Andy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_AB9A67F7-CF62-4F3B-9E65-321F07C2F9E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jan 27, 2017, at 11:23 AM, Andy Bierman <andy@yumaworks.com> =
wrote:

Hi,

The "pyang --ietf" validator checks the statement order used =
in data-def-stmts.
There is no guideline that says =
this is required.
RFC 7950 says canonical order is =
RECOMMENDED.

1) data-def sub-statement =
order
Proposal: add new last sentence to sec. 4.6, =
para 3:

YANG =
data definition sub-statements SHOULD be specified in canonical =
order.

Not =
6087bis specific =E2=80=A6

But is =
this IETF module specific? If not, should this not be checked by pyang =
for all modules.


2) =
enum/bit statement ordering

Proposal: add new para 2 to  sec 5.11.3:

The 'enum' statements =
within an 'enumeration' data type SHOULD be
specified=
 in ascending order, based on the implied and/or explicit =
values
of the 'value' sub-statement. The 'bit' =
statements within a 'bits' data type
SHOULD be =
specified in ascending order, based on the implied and/or
explicit values of the 'position' =
sub-statement.

Ditto.




Andy


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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_AB9A67F7-CF62-4F3B-9E65-321F07C2F9E4--


From nobody Fri Jan 27 15:18:43 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 712AF129881 for ; Fri, 27 Jan 2017 15:18: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 eMs1rcsl4Mf0 for ; Fri, 27 Jan 2017 15:18:39 -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 C1E7A129865 for ; Fri, 27 Jan 2017 15:18:39 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id x49so159499259qtc.2 for ; Fri, 27 Jan 2017 15:18: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=Re+22VoUsioFKeLMK5DpZtpURl8yaBY2qXTGQggmCC4=; b=ZvdkJ1iXHu+qKtLlsugBNLs0TnLdeCacVVNYgcsZSc38xb3X7e1RR0YyYxU6mjzQak QCz600TzC4g6/5sZEAUk79lQEwsPPaXVtjDhlajaDtj+xahHs76sMNjBoBJSh4qshi/X Z+y2DCLOak6HQS33kkUeKIFZWSQmtNrQ/nM7J4NkFPPfabKmEIfrWetFPMUzWyHj5jJh twWwYGwJdMyimvrAa/o/8f2HwSg3sLK/yqFrKEnA2iMJ2tTaVlwajX6iOKNLZUwphNJN z4hyYcWhxAwTUzbWzYHOY+p1/Fo9T0Eh1ANewD15ssxgO3qI9A8QQr81CQwy1nyfZRog FbRQ==
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=Re+22VoUsioFKeLMK5DpZtpURl8yaBY2qXTGQggmCC4=; b=Mext8GaX5n8tU9CT06VCgY6kCgqB1+YOFG0E4rxBgFAQ+usZgndm72YKP8vovFZPBf NQA42Pn5a3duNV9jU0CAx6KVQv38+InFxG5yxuPYAByj7S9Z9T2Ni05ihI8795h4+S3j xE2gSpJANPQ84Cav9g2GEMShMMZtwYwQ8zsO6+RerATKAG+u6jMLF8l2RlGIIiQCu941 DohPqcg9pKBrBNcg9Cp6MyTXrL5HqS1WWtZRiHZHeW5+MewRtcyVyNPEUyBmIfjCNy2Y TE2WEmeHb/gAlkCu5JwmJ78rX/qCpzc+ovfb+eJqPxZHNTimfZnQvgQTstjEMTTPIvac Aa7Q==
X-Gm-Message-State: AIkVDXKXDhbZqAnTGMt03eDCzX5s+P5X4JUM8XGg3oXGn2TijMEvfmrlcLsTEMeY0U7ADuOhLMAys23MZic3yQ==
X-Received: by 10.200.34.77 with SMTP id p13mr10311758qtp.35.1485559118916; Fri, 27 Jan 2017 15:18:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Fri, 27 Jan 2017 15:18:38 -0800 (PST)
In-Reply-To: <29D3031A-8BC1-42C2-8306-9A4AC9A38940@gmail.com>
References:  <29D3031A-8BC1-42C2-8306-9A4AC9A38940@gmail.com>
From: Andy Bierman 
Date: Fri, 27 Jan 2017 15:18:38 -0800
Message-ID: 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=001a113ff8b29383d805471bafba
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 27 Jan 2017 23:18:41 -0000

--001a113ff8b29383d805471bafba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I think these guidelines should apply to other modules but using --ietf
with pyang is up
to the SDOs to decide.


Andy


On Fri, Jan 27, 2017 at 3:06 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

>
> On Jan 27, 2017, at 11:23 AM, Andy Bierman  wrote:
>
> Hi,
>
> The "pyang --ietf" validator checks the statement order used in
> data-def-stmts.
> There is no guideline that says this is required.
> RFC 7950 says canonical order is RECOMMENDED.
>
>
> 1) data-def sub-statement order
> Proposal: add new last sentence to sec. 4.6, para 3:
>
> YANG data definition sub-statements SHOULD be specified in canonical orde=
r.
>
>
> Not 6087bis specific =E2=80=A6
>
> But is this IETF module specific? If not, should this not be checked by
> pyang for all modules.
>
>
>
> 2) enum/bit statement ordering
>
> Proposal: add new para 2 to  sec 5.11.3:
>
> The 'enum' statements within an 'enumeration' data type SHOULD be
> specified in ascending order, based on the implied and/or explicit values
> of the 'value' sub-statement. The 'bit' statements within a 'bits' data
> type
> SHOULD be specified in ascending order, based on the implied and/or
> explicit values of the 'position' sub-statement.
>
>
> Ditto.
>
>
>
>
> Andy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>

--001a113ff8b29383d805471bafba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I think these guidelines should app=
ly to other modules but using --ietf with pyang is up
to the SDOs=
 to decide.


Andy


On Fri, Jan 27, 2017 =
at 3:06 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

On Jan 27, 2017, at 11:23 AM,=
 Andy Bierman <a=
ndy@yumaworks.com> wrote:

Hi,

The &q=
uot;pyang --ietf" validator checks the statement order used in data-de=
f-stmts.
There is no guideline that says this is required.
<=
div>RFC 7950 says canonical order is RECOMMENDED.

1=
) data-def sub-statement order
Proposal: add new last sentence to=
 sec. 4.6, para 3:

YANG data definition sub-statem=
ents SHOULD be specified in canonical order.
=


Not 6087bis specific =E2=80=A6

But =
is this IETF module specific? If not, should this not be checked by pyang f=
or all modules.



2) enum/bit statement ordering
<=
div>
Proposal: add new para 2 to =C2=A0sec 5.11.3:
=

The 'enum' statements within an 'enumeration'=
; data type SHOULD be
specified in ascending order, based on the =
implied and/or explicit values
of the 'value' sub-stateme=
nt. The 'bit' statements within a 'bits' data type
SHOULD be specified in ascending order, based on the implied and/or
=

explicit values of the 'position' sub-statement.

Ditto.




Andy


_______________________________________________
netmod mailing list=

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



Mahesh Jethanandani










--001a113ff8b29383d805471bafba--


From nobody Sat Jan 28 02:54: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 ADDA912947E for ; Sat, 28 Jan 2017 02:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.198
X-Spam-Level: 
X-Spam-Status: No, score=-10.198 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_dZwMURrQOK for ; Sat, 28 Jan 2017 02:54:28 -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 218BD129479 for ; Sat, 28 Jan 2017 02:54:27 -0800 (PST)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 0B5BA6087B; Sat, 28 Jan 2017 11:54:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485600866; bh=81OWGtCLEmbRJnNTlr2XJUZ/ian2CZgzzyInDuuZNLo=; h=From:Date:To; b=HprSsxAL1IBQashAKoJHQ82dKKywg9pCCU6j7xXSJ2L+aQdHIjyg97UMig0rC3cQl v22agoyJRfzJLupgjCUufi3nj03IaOjF+Jccl7y93LVwVywiMyFMonNwNhrVBpIUn4 c2b3F32+POllLIvSEUSxOVmSzhKiRNxkIHqRXHMU=
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: Sat, 28 Jan 2017 11:54:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
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@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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: Sat, 28 Jan 2017 10:54:30 -0000

> On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
>=20
> Hi,
>=20
> The "pyang --ietf" validator checks the statement order used in =
data-def-stmts.
> There is no guideline that says this is required.
> RFC 7950 says canonical order is RECOMMENDED.
>=20
> 1) data-def sub-statement order
> Proposal: add new last sentence to sec. 4.6, para 3:
>=20
> YANG data definition sub-statements SHOULD be specified in canonical =
order.

IMO, this adds nothing to what's already stated in 7950. According to =
RFC 2119, SHOULD and RECOMMENDED mean the same.

>=20
>=20
> 2) enum/bit statement ordering
>=20
> Proposal: add new para 2 to  sec 5.11.3:
>=20
> The 'enum' statements within an 'enumeration' data type SHOULD be
> specified in ascending order, based on the implied and/or explicit =
values
> of the 'value' sub-statement. The 'bit' statements within a 'bits' =
data type
> SHOULD be specified in ascending order, based on the implied and/or
> explicit values of the 'position' sub-statement.

I don't agree. For some enumerations, especially those with a large =
number of enums, it is much more useful for the reader to have the enums =
ordered differently, e.g. alphabetically or geographically. On the other =
hand, numeric enum values often need to be assigned in the order how =
enums are defined in subsequent revisions.

Lada

>=20
>=20
>=20
> Andy
>=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 Sat Jan 28 08:23: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 7A7561295D5 for ; Sat, 28 Jan 2017 08:23:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6WViY-caEbC for ; Sat, 28 Jan 2017 08:23:03 -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 3FA381295D1 for ; Sat, 28 Jan 2017 08:23:03 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id s140so91984152qke.0 for ; Sat, 28 Jan 2017 08:23:03 -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=yqgfDo4Pqfi3W4g7wfAdZsSF80Vu9aZpv/YHx506zOA=; b=KJA2ZHYvp05aoHYO0Mv/nfizb6Y2cSI0w+8tz0p8SfWRAgDdDa0kdHudJ2oPwszq6Z ycxFIyDbaprVNwBZBmLR2oBvwyOI+uW9mCvD16cIwJ+21jbee/HVXO2z9DosYBU0qVvj dDv4C76aV4Hs2d1RrtJP0rpKzUBmOogUxjKLlQGogjkXvfJXss8LD0Pf4V1kDWOIa7BZ P5MJGSND4vdGY/DxrhQL/ykGpfd1ELWuE7A3T5aHGVzw9uhaYMuijQkd3/eOFw0HCVzo A/C0sudB2+vAB/7S570IhGG0DZR9/NJOTYULhYrP+EmzlkSSfFXWtpRW+6zAwq+F/i3r YC1g==
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=yqgfDo4Pqfi3W4g7wfAdZsSF80Vu9aZpv/YHx506zOA=; b=S94z41LxAAvZo/d0jNtZAO9Zkndh2S3B0v823J+QA02ap9w2ewhpAf5Gvo3Z+GJ/d7 2MvZ/wHYRJ5uDtMwMmMmq+SoN4Td8cuJj5huSlQZNd1UzSwgbBA5xlVLl0iA/AUt+LPU cWHcZ6EArOHq3B2Ae0MpZSZukIdRP8yk3WygP8axa4OPJ0nTh9+WsIpUfcYniTAhEuPW Vyjble1h/6pdZrs/tJD3sPhpZp0yNqAW7KyZlGsm5kmoZaK8dQ1vot1eRVjhpQ4UOiW/ UFFqVYm847uFnbr/wjHCYIHnzwuSFx0Jy37UqWyVJxIcI9IN29TIl22QF5tKv7qjMC31 ojig==
X-Gm-Message-State: AIkVDXJ+6pXfmGvhATCBS0AnXhWLxFFXf0gH+J2n1UcC9+AB6u6y+U4lH+nLehve6BdO5ru05D6YXKTlSBc3gw==
X-Received: by 10.55.135.197 with SMTP id j188mr13420221qkd.71.1485620582331;  Sat, 28 Jan 2017 08:23:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Sat, 28 Jan 2017 08:23:01 -0800 (PST)
In-Reply-To: 
References:  
From: Andy Bierman 
Date: Sat, 28 Jan 2017 08:23:01 -0800
Message-ID: 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=94eb2c0777e614d07e054729ff33
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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: Sat, 28 Jan 2017 16:23:05 -0000

--94eb2c0777e614d07e054729ff33
Content-Type: text/plain; charset=UTF-8

On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  wrote:

>
> > On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
> >
> > Hi,
> >
> > The "pyang --ietf" validator checks the statement order used in
> data-def-stmts.
> > There is no guideline that says this is required.
> > RFC 7950 says canonical order is RECOMMENDED.
> >
> > 1) data-def sub-statement order
> > Proposal: add new last sentence to sec. 4.6, para 3:
> >
> > YANG data definition sub-statements SHOULD be specified in canonical
> order.
>
> IMO, this adds nothing to what's already stated in 7950. According to RFC
> 2119, SHOULD and RECOMMENDED mean the same.
>
>


OK



> >
> >
> > 2) enum/bit statement ordering
> >
> > Proposal: add new para 2 to  sec 5.11.3:
> >
> > The 'enum' statements within an 'enumeration' data type SHOULD be
> > specified in ascending order, based on the implied and/or explicit values
> > of the 'value' sub-statement. The 'bit' statements within a 'bits' data
> type
> > SHOULD be specified in ascending order, based on the implied and/or
> > explicit values of the 'position' sub-statement.
>
> I don't agree. For some enumerations, especially those with a large number
> of enums, it is much more useful for the reader to have the enums ordered
> differently, e.g. alphabetically or geographically. On the other hand,
> numeric enum values often need to be assigned in the order how enums are
> defined in subsequent revisions.
>
>

We have been using ascending order in MIB modules and YANG modules
all along.  I think there are about 5000 modules in ascending order and one
not
in ascending order.  The guideline is SHOULD anyway.

YANG prohibits the value or position numbers from changing in
a new revision, so preserving previous ordering is required.


> Lada
>

Andy


>
> >
> >
> >
> > Andy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
>

--94eb2c0777e614d07e054729ff33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 27 Jan 2017, at 20:23, Andy Bierman <andy@yumaworks.com> wrote:

>

> Hi,

>

> The "pyang --ietf" validator checks the statement order used=
 in data-def-stmts.

> There is no guideline that says this is required.

> RFC 7950 says canonical order is RECOMMENDED.

>

> 1) data-def sub-statement order

> Proposal: add new last sentence to sec. 4.6, para 3:

>

> YANG data definition sub-statements SHOULD be specified in canonical o=
rder.



IMO, this adds nothing to what's already stated in 7950. According to R=
FC 2119, SHOULD and RECOMMENDED mean the same.





OK
=


=C2=A0

>

>

> 2) enum/bit statement ordering

>

> Proposal: add new para 2 to=C2=A0 sec 5.11.3:

>

> The 'enum' statements within an 'enumeration' data typ=
e SHOULD be

> specified in ascending order, based on the implied and/or explicit val=
ues

> of the 'value' sub-statement. The 'bit' statements wit=
hin a 'bits' data type

> SHOULD be specified in ascending order, based on the implied and/or
> explicit values of the 'position' sub-statement.



I don't agree. For some enumerations, especially those with a large num=
ber of enums, it is much more useful for the reader to have the enums order=
ed differently, e.g. alphabetically or geographically. On the other hand, n=
umeric enum values often need to be assigned in the order how enums are def=
ined in subsequent revisions.




We have been using asce=
nding order in MIB modules and YANG modules
all along.=C2=A0 I th=
ink there are about 5000 modules in ascending order and one not
i=
n ascending order.=C2=A0 The guideline is SHOULD anyway.

YANG prohibits the value or position numbers from changing in
<=
div>a new revision, so preserving previous ordering is required.
=
=C2=A0

Lada

Andy
=C2=A0



>

>

>

> Andy

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67















--94eb2c0777e614d07e054729ff33--


From nobody Mon Jan 30 00:21:08 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 D84101298BA for ; Mon, 30 Jan 2017 00:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.198
X-Spam-Level: 
X-Spam-Status: No, score=-10.198 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNzkflXOVJHq for ; Mon, 30 Jan 2017 00:21:05 -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 322001204D9 for ; Mon, 30 Jan 2017 00:21:04 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:1541:6b1a:7f:2793] (unknown [IPv6:2001:718:1a02:1:1541:6b1a:7f:2793]) by mail.nic.cz (Postfix) with ESMTPSA id 7BBE161378; Mon, 30 Jan 2017 09:21:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485764462; bh=FJ/HXLBlqxRKRynepBFVtDCLWvwRaXyO3SdzfRmSuq0=; h=From:Date:To; b=VyGFDIfekr/oxx8xzyAwSEfPEcI/wf27QJheZ/jJz89YqKoGL/LLDPChS8zUM90tm v6BckLEIsh+BS6oSjC7t5TQ2lxe0JEuUwV2SsOLRpppGEFq4jMQoqDKGiCWke/SCrn B2Vdq8wPyLSkaxLAy/tnpcjF0QT8rnjF4UeqosO4=
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, 30 Jan 2017 09:21:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
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@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 30 Jan 2017 08:21:07 -0000

> On 28 Jan 2017, at 17:23, Andy Bierman  wrote:
>=20
>=20
>=20
> On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
> >
> > Hi,
> >
> > The "pyang --ietf" validator checks the statement order used in =
data-def-stmts.
> > There is no guideline that says this is required.
> > RFC 7950 says canonical order is RECOMMENDED.
> >
> > 1) data-def sub-statement order
> > Proposal: add new last sentence to sec. 4.6, para 3:
> >
> > YANG data definition sub-statements SHOULD be specified in canonical =
order.
>=20
> IMO, this adds nothing to what's already stated in 7950. According to =
RFC 2119, SHOULD and RECOMMENDED mean the same.
>=20
>=20
>=20
>=20
> OK
>=20
> =20
> >
> >
> > 2) enum/bit statement ordering
> >
> > Proposal: add new para 2 to  sec 5.11.3:
> >
> > The 'enum' statements within an 'enumeration' data type SHOULD be
> > specified in ascending order, based on the implied and/or explicit =
values
> > of the 'value' sub-statement. The 'bit' statements within a 'bits' =
data type
> > SHOULD be specified in ascending order, based on the implied and/or
> > explicit values of the 'position' sub-statement.
>=20
> I don't agree. For some enumerations, especially those with a large =
number of enums, it is much more useful for the reader to have the enums =
ordered differently, e.g. alphabetically or geographically. On the other =
hand, numeric enum values often need to be assigned in the order how =
enums are defined in subsequent revisions.
>=20
>=20
>=20
> We have been using ascending order in MIB modules and YANG modules
> all along.  I think there are about 5000 modules in ascending order =
and one not
> in ascending order.  The guideline is SHOULD anyway.

A guideline with little or no technical merit is just noise.

>=20
> YANG prohibits the value or position numbers from changing in
> a new revision, so preserving previous ordering is required.

This is of course only true for auto-numbering. I think 6087bis should =
instead include a guideline saying that explicit values should be =
specified for extensible enumerations so that new enums can be inserted =
where it makes most sense, also in the middle of the list.

Extensibility is probably less relevant for "bits" type because =
available bits are usually pre-allocated. But then again, some authors =
may prefer listing bits in the descending order of positions, as in the =
ietf-isis-sr module:

https://tools.ietf.org/html/draft-ietf-isis-sr-yang-00#section-4

Lada

> =20
> Lada
>=20
> Andy
> =20
>=20
> >
> >
> >
> > Andy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67

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






From nobody Mon Jan 30 03:13:06 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 15D7C12998A for ; Mon, 30 Jan 2017 03:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX4I9L2KpKrt for ; Mon, 30 Jan 2017 03:13:04 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986BE12998B for ; Mon, 30 Jan 2017 03:13:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E88DD1E565A; Mon, 30 Jan 2017 03:11:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oWoXPz6WJ6mZ; Mon, 30 Jan 2017 03:11:58 -0800 (PST)
Received: from [192.168.1.127] (host5-81-223-185.range5-81.btcentralplus.com [5.81.223.185]) by c8a.amsl.com (Postfix) with ESMTPSA id DBE351E5656; Mon, 30 Jan 2017 03:11:57 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_C395BEB8-F074-4776-92EF-F333255DE7F3"
From: William Lupton 
In-Reply-To: 
Date: Mon, 30 Jan 2017 11:13:01 +0000
Message-Id: 
References:  <29D3031A-8BC1-42C2-8306-9A4AC9A38940@gmail.com> 
To: "netmod@ietf.org" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 30 Jan 2017 11:13:06 -0000

--Apple-Mail=_C395BEB8-F074-4776-92EF-F333255DE7F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Note that pyang --ietf is just a thin wrapper around --lint, with =
IETF/IANA namespace and module prefixes.

At BBF we are happy to follow IETF recommendations, and require no =
warnings or errors when using:

--strict --max-line-length=3D70 --lint --lint-modulename-prefix=3Dbbf =
--lint-namespace-prefix=3Durn:bbf:yang:

William

> On 27 Jan 2017, at 23:18, Andy Bierman  wrote:
>=20
> Hi,
>=20
> I think these guidelines should apply to other modules but using =
--ietf with pyang is up
> to the SDOs to decide.
>=20
>=20
> Andy
>=20
>=20
> On Fri, Jan 27, 2017 at 3:06 PM, Mahesh Jethanandani =
> wrote:
>=20
>> On Jan 27, 2017, at 11:23 AM, Andy Bierman > wrote:
>>=20
>> Hi,
>>=20
>> The "pyang --ietf" validator checks the statement order used in =
data-def-stmts.
>> There is no guideline that says this is required.
>> RFC 7950 says canonical order is RECOMMENDED.
>>=20
>> 1) data-def sub-statement order
>> Proposal: add new last sentence to sec. 4.6, para 3:
>>=20
>> YANG data definition sub-statements SHOULD be specified in canonical =
order.
>=20
> Not 6087bis specific =E2=80=A6
>=20
> But is this IETF module specific? If not, should this not be checked =
by pyang for all modules.
>=20
>>=20
>>=20
>> 2) enum/bit statement ordering
>>=20
>> Proposal: add new para 2 to  sec 5.11.3:
>>=20
>> The 'enum' statements within an 'enumeration' data type SHOULD be
>> specified in ascending order, based on the implied and/or explicit =
values
>> of the 'value' sub-statement. The 'bit' statements within a 'bits' =
data type
>> SHOULD be specified in ascending order, based on the implied and/or
>> explicit values of the 'position' sub-statement.
>=20
> Ditto.
>=20
>>=20
>>=20
>>=20
>> Andy
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod =

>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com 
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_C395BEB8-F074-4776-92EF-F333255DE7F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Note that pyang --ietf is just a thin wrapper =
around --lint, with IETF/IANA namespace and module prefixes.

At BBF we are happy to =
follow IETF recommendations, and require no warnings or errors when =
using:

--strict =
--max-line-length=3D70 --lint --lint-modulename-prefix=3Dbbf =
--lint-namespace-prefix=3Durn:bbf:yang:

William

On =
27 Jan 2017, at 23:18, Andy Bierman <andy@yumaworks.com> =
wrote:

Hi,

I think these guidelines should apply to other modules but =
using --ietf with pyang is up
to the SDOs to =
decide.


Andy


On Fri, Jan 27, 2017 at 3:06 PM, Mahesh =
Jethanandani <mjethanandani@gmail.com> wrote:

On Jan =
27, 2017, at 11:23 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

The "pyang --ietf" validator checks the =
statement order used in data-def-stmts.
There is no =
guideline that says this is required.
RFC 7950 says =
canonical order is RECOMMENDED.

1) data-def =
sub-statement order
Proposal: add new last sentence =
to sec. 4.6, para 3:

YANG data definition sub-statements SHOULD be specified in =
canonical order.

Not 6087bis specific =E2=80=A6

But is this IETF module specific? If =
not, should this not be checked by pyang for all modules.



2) =
enum/bit statement ordering

Proposal: add new para 2 to  sec 5.11.3:

The 'enum' statements =
within an 'enumeration' data type SHOULD be
specified=
 in ascending order, based on the implied and/or explicit =
values
of the 'value' sub-statement. The 'bit' =
statements within a 'bits' data type
SHOULD be =
specified in ascending order, based on the implied and/or
explicit values of the 'position' =
sub-statement.

Ditto.




Andy


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



Mahesh Jethanandani
mjethanandani@gmail.com









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

=

--Apple-Mail=_C395BEB8-F074-4776-92EF-F333255DE7F3--


From nobody Mon Jan 30 03:26: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 7281E129454 for ; Mon, 30 Jan 2017 03:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hvsqObqyQTQk for ; Mon, 30 Jan 2017 03:26:05 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD0112944A for ; Mon, 30 Jan 2017 03:26:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 05D571E565A; Mon, 30 Jan 2017 03:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id x_IDVSuSGV-i; Mon, 30 Jan 2017 03:24:59 -0800 (PST)
Received: from [192.168.1.127] (host5-81-223-185.range5-81.btcentralplus.com [5.81.223.185]) by c8a.amsl.com (Postfix) with ESMTPSA id 517FD1E5656; Mon, 30 Jan 2017 03:24:59 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: William Lupton 
Date: Mon, 30 Jan 2017 11:26:02 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <87135535-2FBD-419E-BEDA-63084A991AF3@broadband-forum.org>
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] RFC 6087bis (draft 09) description-stmt
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, 30 Jan 2017 11:26:06 -0000

Andy, all,

RFC 6087bis nearly always says =E2=80=9Cdescription statement=E2=80=9D =
but on one occasion it says "description-stmt=E2=80=9D (when discussing =
its use within =E2=80=9Cfeature-stmt=E2=80=9D).

It also usually doesn=E2=80=99t quote =E2=80=9Cdescription=E2=80=9D, but =
on a few (clustered?) occasions it does quote it.

The above remarks may apply more generally (i.e to other statements).

Thanks,
William=


From nobody Mon Jan 30 03:38: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 8311F12945A for ; Mon, 30 Jan 2017 03:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.719
X-Spam-Level: 
X-Spam-Status: No, score=-17.719 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUZ9g5r6ES3R for ; Mon, 30 Jan 2017 03:38:28 -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 5E649129454 for ; Mon, 30 Jan 2017 03:38:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11005; q=dns/txt; s=iport; t=1485776307; x=1486985907; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ssMVLx4+9ZDdVM0S4V8IKAPIDBr2AFuDqcMW1WchQmk=; b=OHrtxea3cxRDpUKPTY0Cr8taJ6gSry2T8jXEnhGuxM+ztv37JSsow28W 8fo58JgiXd5holSC3pyw9m7rClja6n7vJOQaseGbRkWpeTkLxZY4pmWO3 jQ/6jKz7JVxR35pQenFIbQOioPzOe/wbnoP/IjoK6DBacDYFVik7i90qb o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQD9JI9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDQqX41ecpBwH5AHhSuCDB8BCoUuSgKCTxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEBAwEBAWwLBQsLGCcHJx8RBgEMBgIBAYlYCA6tNCuKRQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhkuCBQiCYoouBZtUigGHeoF5iD8jhhyLAId/HziBGxMIFRU?= =?us-ascii?q?7hASCNUA1hXgrgg8BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,311,1477958400";  d="scan'208,217";a="652083032"
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; 30 Jan 2017 11:38:25 +0000
Received: from [10.63.23.109] (dhcp-ensft1-uk-vla370-10-63-23-109.cisco.com [10.63.23.109]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0UBcOJb013146; Mon, 30 Jan 2017 11:38:25 GMT
To: Andy Bierman , Ladislav Lhotka 
References:   
From: Robert Wilton 
Message-ID: <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com>
Date: Mon, 30 Jan 2017 11:38:24 +0000
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: 
Content-Type: multipart/alternative; boundary="------------A95DB2EEE09F4A2B784070B2"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 30 Jan 2017 11:38:29 -0000

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

Hi Andy, Lada,


On 28/01/2017 16:23, Andy Bierman wrote:
>
>
> On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  > wrote:
>
>
>     > On 27 Jan 2017, at 20:23, Andy Bierman      > wrote:
>     >
>     > Hi,
>     >
>     > The "pyang --ietf" validator checks the statement order used in
>     data-def-stmts.
>     > There is no guideline that says this is required.
>     > RFC 7950 says canonical order is RECOMMENDED.
>     >
>     > 1) data-def sub-statement order
>     > Proposal: add new last sentence to sec. 4.6, para 3:
>     >
>     > YANG data definition sub-statements SHOULD be specified in
>     canonical order.
>
>     IMO, this adds nothing to what's already stated in 7950. According
>     to RFC 2119, SHOULD and RECOMMENDED mean the same.
>
I support Andy's recommendation here, although I think that it might 
also be useful to cross reference back to where the canonical order is 
actually defined in 7950.

Lada, you are right that 7950 recommends the correct ordering, but I 
think that it is buried with the ABNF, which won't necessarily be read 
by all users of YANG.  Pulling it out in 6087bis doesn't seem to do any 
harm.


>
>
>
> OK
>
>     >
>     >
>     > 2) enum/bit statement ordering
>     >
>     > Proposal: add new para 2 to  sec 5.11.3:
>     >
>     > The 'enum' statements within an 'enumeration' data type SHOULD be
>     > specified in ascending order, based on the implied and/or
>     explicit values
>     > of the 'value' sub-statement. The 'bit' statements within a
>     'bits' data type
>     > SHOULD be specified in ascending order, based on the implied and/or
>     > explicit values of the 'position' sub-statement.
>
>     I don't agree. For some enumerations, especially those with a
>     large number of enums, it is much more useful for the reader to
>     have the enums ordered differently, e.g. alphabetically or
>     geographically. On the other hand, numeric enum values often need
>     to be assigned in the order how enums are defined in subsequent
>     revisions.
>
>
>
> We have been using ascending order in MIB modules and YANG modules
> all along.  I think there are about 5000 modules in ascending order 
> and one not
> in ascending order.  The guideline is SHOULD anyway.
+1.  Isn't this exactly what a SHOULD statement means.  I.e. put in 
ascending order unless there is a good reason not to do so (e.g. as per 
Lada's examples), in which case that is fine.

Rob


>
> YANG prohibits the value or position numbers from changing in
> a new revision, so preserving previous ordering is required.
>
>     Lada
>
>
> Andy
>
>
>     >
>     >
>     >
>     > Andy
>     >
>     > _______________________________________________
>     > netmod mailing list
>     > netmod@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/netmod
>     
>
>     --
>     Ladislav Lhotka, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------A95DB2EEE09F4A2B784070B2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy, Lada,

    

    

    
On 28/01/2017 16:23, Andy Bierman
      wrote:

    

    

      
      


        


          
On Sat, Jan 28, 2017 at 2:54 AM,
            Ladislav Lhotka <lhotka@nic.cz> wrote:

            


              > On 27 Jan 2017, at 20:23, Andy Bierman <andy@yumaworks.com>
              wrote:

              >

              > Hi,

              >

              > The "pyang --ietf" validator checks the statement
              order used in data-def-stmts.

              > There is no guideline that says this is required.

              > RFC 7950 says canonical order is RECOMMENDED.

              >

              > 1) data-def sub-statement order

              > Proposal: add new last sentence to sec. 4.6, para 3:

              >

              > YANG data definition sub-statements SHOULD be
              specified in canonical order.

              

              IMO, this adds nothing to what's already stated in 7950.
              According to RFC 2119, SHOULD and RECOMMENDED mean the
              same.

              

            

          

        

      

    

    I support Andy's recommendation here, although I think that it might
    also be useful to cross reference back to where the canonical order
    is actually defined in 7950.

    

    Lada, you are right that 7950 recommends the correct ordering, but I
    think that it is buried with the ABNF, which won't necessarily be
    read by all users of YANG. Pulling it out in 6087bis doesn't seem
    to do any harm.

    

    

    

      

        

          

            


            

            


            

            


            

            
OK

            


            

            

            

              >

              >

              > 2) enum/bit statement ordering

              >

              > Proposal: add new para 2 to sec 5.11.3:

              >

              > The 'enum' statements within an 'enumeration' data
              type SHOULD be

              > specified in ascending order, based on the implied
              and/or explicit values

              > of the 'value' sub-statement. The 'bit' statements
              within a 'bits' data type

              > SHOULD be specified in ascending order, based on the
              implied and/or

              > explicit values of the 'position' sub-statement.

              

              I don't agree. For some enumerations, especially those
              with a large number of enums, it is much more useful for
              the reader to have the enums ordered differently, e.g.
              alphabetically or geographically. On the other hand,
              numeric enum values often need to be assigned in the order
              how enums are defined in subsequent revisions.

              

            

            


            

            


            

            
We have been using ascending order in MIB modules and
              YANG modules

            
all along. I think there are about 5000 modules in
              ascending order and one not

            
in ascending order. The guideline is SHOULD anyway.

          

        

      

    

    +1. Isn't this exactly what a SHOULD statement means. I.e. put in
    ascending order unless there is a good reason not to do so (e.g. as
    per Lada's examples), in which case that is fine.

    

    Rob

    

    

    

      

        

          

            


            

            
YANG prohibits the value or position numbers from
              changing in

            
a new revision, so preserving previous ordering is
              required.

            

            

              Lada

            

            


            

            
Andy

            

            

              

              >

              >

              >

              > Andy

              >

              > _______________________________________________

              > netmod mailing list

              > netmod@ietf.org

              > https://www.ietf.org/mailman/listinfo/netmod

              

              --

              Ladislav Lhotka, CZ.NIC Labs

              PGP Key ID: 0xB8F92B08A9F76C67

              

              

              

              

              

            

          

          

        

      

      

      

      

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


    

    

  


--------------A95DB2EEE09F4A2B784070B2--


From nobody Mon Jan 30 03:49:58 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 A567712945D for ; Mon, 30 Jan 2017 03:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=voltanet-io.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 euMrVZ7Lw45k for ; Mon, 30 Jan 2017 03:49:55 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 EEF9212945B for ; Mon, 30 Jan 2017 03:49:54 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id b65so29039074wmf.0 for ; Mon, 30 Jan 2017 03:49:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voltanet-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tq4TnJPSzvGz9oeQhLHoi+p5ukp2NbfZWOmakWlFbGk=; b=VP4FeKRkFoR0DthpRWQoF8BnOtH7s3Eiuj9BQaM4UEkga/VgNNVz63imWXVeHaDoEL nkqqcOf+sCkFgnIr3giXicYvFeA0XD+HRXZRsFFMPLdm1ZbLhCCTYmtTPYWz1sOxiA6l URdC4HlGc9xML+1yQZZGM9WJFGOg3dDBBNlhtf/7Jxg3/F1g+V0i5pMqbdCnaHjaoGoj LQxr8MgmDDwudZXDFEmwU0PMSuH1peQuc6DtcYzMNU2XDJOae46vhhUI7ufonLcxhlZP DNJz0vuQiuyvtZySEM1B4pVHwJeRkXtvJI14hXYfNScyD1BsR3pyr0mNccMtP07lIux/ UMZA==
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=tq4TnJPSzvGz9oeQhLHoi+p5ukp2NbfZWOmakWlFbGk=; b=JUdYab1YjinJZUDLItsn7L+p1vCe4ixXHVaJPR7SXpE1gW4RoUqoNj3/LSHF2fVf4G nCT1e6Z2OAydajOGbUUHsWAuy40+kmdZ2xCdxLJAAznaC+xaCyDSedxOZgWr6UrXIFs4 L7tN68GMWlYh5NJ+lzvw+ImPRPs6q54FXVnEL3IMX5ySwX93wybA8scsEw7feeWeiR2M 0y/ljwn0i95fabCntNMOD3Ih9xqCyFe0Xrpdwej5IoM8clU8t09qX+7vB9QMwaTSdUWD 0eeD7zR2Ie1IDlxM8FqTusa2HXYJV6TNaNGTCSNwRM2vBjkNOBfDT3USoas02fZuAkHu ccbQ==
X-Gm-Message-State: AIkVDXJQ1lNDzRNjRYvJ1FcEaC8d8QzpKNUceUNLw8b2ih/xE6ynrQKrARnLY2shRqJoGg==
X-Received: by 10.28.131.72 with SMTP id f69mr14912870wmd.140.1485776993176; Mon, 30 Jan 2017 03:49:53 -0800 (PST)
Received: from [10.12.12.35] ([37.205.61.206]) by smtp.gmail.com with ESMTPSA id b8sm22341744wrb.17.2017.01.30.03.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 03:49:52 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Dean Bogdanovic 
In-Reply-To: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk>
Date: Mon, 30 Jan 2017 11:49:50 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <4248688C-E0AC-4302-A281-0622D824FA4D@voltanet.io>
References: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk>
To: adrian@olddog.co.uk
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: opsawg@ietf.org, draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
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, 30 Jan 2017 11:49:56 -0000

> On Jan 19, 2017, at 4:25 PM, Adrian Farrel  =
wrote:
>=20
> Hi,
>=20
> We've been trying to ensure that =
draft-wu-opsawg-service-model-explained is
> consistent with the latest version of
> draft-ietf-netmod-yang-model-classification. In discussions with =
Tianran a
> question has come up.
>=20
> In section 2 you have a nice definition of Network Service YANG =
Modules and this
> definition maps nicely to our definition of "service delivery models".
> Furthermore, your figure 1 shows Network Service YANG Modules on the =
interface
> between OSS/BSS and the various network services.
>=20
> We have further defined "customer service models" at a higher layer =
still. That
> is, on the interface to the customer. This (of course?) assumes that =
the OSS/BSS
> is not customer code :-)
>=20
> However, your discussion of Network Service YANG Modules in section =
2.1 seems
> slightly at odds, although this may be just ambiguity.
>=20
> For example, when you say, "Network Service YANG Modules describe the
> characteristics of a service, as agreed upon with consumers of that =
service,"
> this is not the same as, "This model is used in the discussion between =
a
> customer and a service provide to describe the characteristics of a =
service."
> That is, the former case could be arrived at after processing based on =
the
> latter case - processing that we have called "service orchestration" =
but might
> (of course) be what leads to the operator poking the OSS/BSS.

Adrian, I can see the ambiguity. The point of service module is to be =
consumed by the customer and there can be some modifications of the =
service module to adapt to the customer specifics.
>=20
> This might all be fine and good, but later in the same section you say =
"Network
> Service YANG Modules define service models to be consumed by external =
systems.
> These modules are commonly designed, developed and deployed by network
> infrastructure teams." And there you introduce two terms that are =
previously
> undefined and only server to add ambiguity. Specifically "external to =
what?" I
> could make and argument that the OSS is developed and deployed by =
network
> infrastructure teams, ad also that the OSS is external to the network =
itself.

Agree that external systems are not defined and this text has to be =
clarified. The external systems can be OSS and BSS.
>=20
> And, in between these two quoted pieces of text, you have...
>=20
>   As an example, the Network Service YANG Module defined in
>   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
>   model for Layer 3 IP VPN service configuration.

My question is where do you see the L3SM model=20

above or below OSS?

Because there are some nuances in the service module, but at the end we =
decided not to do sub classification

one is the business and one technical service.

When i read the YANG-Data-Model-for-L3VPN-service-delivery, it looked to =
me much more like a technical model, then the business model, as =
didn=E2=80=99t see SLA definitions to track the business parameters of =
the service use.

>=20
> Per my other email, this reference needs to be fixed. But I struggle =
to see the
> L3SM module as consistent with your figure. It may or may not be =
consistent with
> your text dependent on the interpretation.

Sure, we can fix that reference, but the authors of L3SM module should =
do their own module classification, as they are the only ones that know =
the intent of the module.

>=20
> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to =
show how we
> (the authors) think L3SM fits into your classification. Here we place =
L3SM
> further up the layering stack.
>=20
> [Apologies for not spotting this sooner. The citation
> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term =
"service
> delivery" which I took to imply a different module.]
>=20

No worries and sorry for late reply

Dean

> Thanks,
> Adrian
>=20


From nobody Mon Jan 30 03:50: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 1026F129458 for ; Mon, 30 Jan 2017 03:50:28 -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 w5GpK70dLA8l for ; Mon, 30 Jan 2017 03:50:26 -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 5D93412945A for ; Mon, 30 Jan 2017 03:50:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=736; q=dns/txt; s=iport; t=1485777022; x=1486986622; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=LG+QFXYWofUaKkannKBO8N6ah2aB1L8jpgDMZsuMz70=; b=FDVy255POAA4tTJxLblOl/W1yVTkxX8IWUXhv8hPGaLCzliGZVjbWMBw WW5wkCiTjz5gTd9p72QuyEOHkWTMs/kHINRmc8dUu5z8RUlocPZJHaE+l i/i0xOE8kQf4wX6pWaUcfGXXS6+Vgm/FyAshWSaynKOwrb8ACW+g/abX2 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAgALKI9Y/xbLJq1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBhF6ENIoJcqZBggyIcxgBAgEBAQEBAQFiHQuFExV2AiYCXw0IAQGJYJsVkAG?= =?us-ascii?q?CJYpwAQEIAiaBC4VAggWKOYJfBZtUgU2QLoFhiFeGP4sAh38fOIEbEwgVFYZ0Q?= =?us-ascii?q?IhnAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,311,1477958400"; d="scan'208";a="649240835"
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; 30 Jan 2017 11:50:20 +0000
Received: from [10.63.23.109] (dhcp-ensft1-uk-vla370-10-63-23-109.cisco.com [10.63.23.109]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0UBoK9L015017 for ; Mon, 30 Jan 2017 11:50:20 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: <7b87a0ee-0c10-5f40-418e-4c125901e336@cisco.com>
Date: Mon, 30 Jan 2017 11:50:20 +0000
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
Archived-At: 
Subject: [netmod] Are multiple revisions with the same date allowed?
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, 30 Jan 2017 11:50:28 -0000

RFC 7950 doesn't state that the date associated with revision statements 
in a YANG module must be unique.

Hence, I presume that it is intentionally allowed to have multiple 
revision statements with the same date.  E.g. the following module is 
allowed (and passes pyang --lint):

module rev-example {
   namespace
     "urn:example";

   prefix ex;

   organization "";

   contact "";

   description "'";
   reference "IEEE 802.3-2015, unless dated explicitly";

   revision 2017-01-30 {
     description
       "A revision description";
     reference "";
   }

   revision 2017-01-30 {
     description
       "A different revision with the same date";
     reference "";
   }

}

Thanks,
Rob



From nobody Mon Jan 30 03:52:36 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 5011D12945B; Mon, 30 Jan 2017 03:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVbAMWqMuj6U; Mon, 30 Jan 2017 03:52:33 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 5B0CD12945A; Mon, 30 Jan 2017 03:52:33 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id b65so29138647wmf.0; Mon, 30 Jan 2017 03:52:33 -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=5l6lPYx7EBol5g+pcU4YmvjbEOB9itPz8vi6SCTGX8o=; b=c/rl20bTdlHpwuEmFz9F8p8GK61b2Lj698xbiVBFmrAcJNIvliIusj4NW2m/Nr3LDQ pHYFbsoaDkpwwzrYYbf0VRX2BWZ/IzBHvfI6KY+jaOlMwiYJTqlXELK/FTPvyQoNb//q NU+oUE81vhbqPoCtz87vxeVsXiTV1at1/Ti7Lp6aIniNudgbL8VyfMh5CoMwAxSV5hxb 3k7mYZjl7kmlGmxZmZI+YUgNdKIzjdcAp4Am/Ei31RscYjEyojtg8W4ToEotFUVqoBW1 VPJ9pHACOe28WEiADL3WyQ89x+kgonRV4u5KRO/G10Sv4L5KLSjXz6XEfm+eRdZImUpu /6uA==
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=5l6lPYx7EBol5g+pcU4YmvjbEOB9itPz8vi6SCTGX8o=; b=W/wCuvbLZ0T6TgreJvpPHCpeEX57e8w3lYhST6jSBcBT1FedXPEVKBg8Q3LLekiXTJ CQnpyXk/CjYwoVQoOZyY0m7R97s4722oOonzmqdWALNvEC0yhD7tixB1OWN1Xiye5FBC qavO3VmhjkWqXfrUMdZBuLuGDKB/ENJRq0JChGdackowmFxC38GMKWHh+mfGVoozUVtB tGjoVO3z1aSd5fTf1uSafP3QX3jR5giXwxWz5GfCNti4RlylLMpCx8jtIB0O7U9qc21/ 4UzZTC0zjlfDAlKHl7pOCmr4LPItQRlIoQA+Xi7KwAyC/p2x0yVnHehajQLUjnRkDiyU zV2Q==
X-Gm-Message-State: AIkVDXLMs321p/XMsDgxVGXGvY7H67NNSdhstKljCdUjB6YH1s6QxUPmsWgV538D1IXDHQ==
X-Received: by 10.28.206.199 with SMTP id e190mr14179254wmg.98.1485777151797;  Mon, 30 Jan 2017 03:52:31 -0800 (PST)
Received: from [10.12.12.35] ([37.205.61.206]) by smtp.gmail.com with ESMTPSA id l9sm18382907wmf.18.2017.01.30.03.52.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 03:52:31 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Mon, 30 Jan 2017 11:52:30 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk> 
To: Tianran Zhou 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: "opsawg@ietf.org" , "draft-ietf-netmod-yang-model-classification@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
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, 30 Jan 2017 11:52:35 -0000

> On Jan 23, 2017, at 9:32 AM, Tianran Zhou  =
wrote:
>=20
> To add more comments:=20
>=20
> On the L2SM meeting, several people (4 or more) believed the 3 service =
delivery model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], =
[I-D.ietf-bess-l2vpn-yang] and [I-D.ietf-bess-evpn-yang]) are actually =
device models.
>=20
> I think both of the two I-Ds =
([draft-ietf-netmod-yang-model-classification] and =
[draft-wu-opsawg-service-model-explained]) can check if those YANG =
models are device models or service models.

The idea is that the classification drafts will provide guidelines for =
the authors to do their own classification. As mentioned in my previous =
email, the only people who will be able to do the right classification, =
are the module authors.

Please see I=E2=80=99m using distinction between module and model. Model =
can consist of multiple modules and in models you can get classification =
ambiguity. Modules are much more clear to classify.

Dean

>=20
> Regards,
> Tianran
>=20
>> -----Original Message-----
>> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian =
Farrel
>> Sent: Friday, January 20, 2017 12:25 AM
>> To: netmod@ietf.org
>> Cc: opsawg@ietf.org;
>> draft-ietf-netmod-yang-model-classification@ietf.org
>> Subject: [OPSAWG] Question on =
draft-ietf-netmod-yang-model-classification
>>=20
>> Hi,
>>=20
>> We've been trying to ensure that =
draft-wu-opsawg-service-model-explained
>> is consistent with the latest version of
>> draft-ietf-netmod-yang-model-classification. In discussions with =
Tianran
>> a question has come up.
>>=20
>> In section 2 you have a nice definition of Network Service YANG =
Modules
>> and this definition maps nicely to our definition of "service =
delivery
>> models".
>> Furthermore, your figure 1 shows Network Service YANG Modules on the
>> interface between OSS/BSS and the various network services.
>>=20
>> We have further defined "customer service models" at a higher layer =
still.
>> That is, on the interface to the customer. This (of course?) assumes =
that
>> the OSS/BSS is not customer code :-)
>>=20
>> However, your discussion of Network Service YANG Modules in section =
2.1
>> seems slightly at odds, although this may be just ambiguity.
>>=20
>> For example, when you say, "Network Service YANG Modules describe the
>> characteristics of a service, as agreed upon with consumers of that =
service,"
>> this is not the same as, "This model is used in the discussion =
between a
>> customer and a service provide to describe the characteristics of a =
service."
>> That is, the former case could be arrived at after processing based =
on the
>> latter case - processing that we have called "service orchestration" =
but
>> might (of course) be what leads to the operator poking the OSS/BSS.
>>=20
>> This might all be fine and good, but later in the same section you =
say "Network
>> Service YANG Modules define service models to be consumed by external
>> systems.
>> These modules are commonly designed, developed and deployed by =
network
>> infrastructure teams." And there you introduce two terms that are =
previously
>> undefined and only server to add ambiguity. Specifically "external to =
what?"
>> I could make and argument that the OSS is developed and deployed by =
network
>> infrastructure teams, ad also that the OSS is external to the network =
itself.
>>=20
>> And, in between these two quoted pieces of text, you have...
>>=20
>>   As an example, the Network Service YANG Module defined in
>>   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
>>   model for Layer 3 IP VPN service configuration.
>>=20
>> Per my other email, this reference needs to be fixed. But I struggle =
to
>> see the L3SM module as consistent with your figure. It may or may not =
be
>> consistent with your text dependent on the interpretation.
>>=20
>> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to =
show
>> how we (the authors) think L3SM fits into your classification. Here =
we place
>> L3SM further up the layering stack.
>>=20
>> [Apologies for not spotting this sooner. The citation
>> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term =
"service
>> delivery" which I took to imply a different module.]
>>=20
>> Thanks,
>> Adrian
>>=20
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Jan 30 04:05: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 241261293D8 for ; Mon, 30 Jan 2017 04:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.398
X-Spam-Level: 
X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22zsKzF-xYuq for ; Mon, 30 Jan 2017 04:05:16 -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 9FA2C12944C for ; Mon, 30 Jan 2017 04:05:15 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D2F29772; Mon, 30 Jan 2017 13:05:13 +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 mAguMYc7NABj; Mon, 30 Jan 2017 13:05: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; Mon, 30 Jan 2017 13:05:13 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86361200AC; Mon, 30 Jan 2017 13:05:13 +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 ZohENkTf6R7P; Mon, 30 Jan 2017 13:05: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 36BA5200AB; Mon, 30 Jan 2017 13:05:13 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id ADE903E51DC9; Mon, 30 Jan 2017 13:05:08 +0100 (CET)
Date: Mon, 30 Jan 2017 13:05:06 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20170130120503.GC56875@elstar.local>
Mail-Followup-To: Robert Wilton , "netmod@ietf.org" 
References: <7b87a0ee-0c10-5f40-418e-4c125901e336@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7b87a0ee-0c10-5f40-418e-4c125901e336@cisco.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Are multiple revisions with the same date allowed?
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, 30 Jan 2017 12:05:18 -0000

Rob,

since we are talking about _published_ modules, this is going to be
rare. Perhaps we could have allowed an optional time specification
here to handle this case (since multiple revisions with the same date
cause ambiguity) but then in most organizations this is unlikely to
happen (at least this is what we assumed).

/js

On Mon, Jan 30, 2017 at 11:50:20AM +0000, Robert Wilton wrote:
> RFC 7950 doesn't state that the date associated with revision statements in
> a YANG module must be unique.
> 
> Hence, I presume that it is intentionally allowed to have multiple revision
> statements with the same date.  E.g. the following module is allowed (and
> passes pyang --lint):
> 
> module rev-example {
>   namespace
>     "urn:example";
> 
>   prefix ex;
> 
>   organization "";
> 
>   contact "";
> 
>   description "'";
>   reference "IEEE 802.3-2015, unless dated explicitly";
> 
>   revision 2017-01-30 {
>     description
>       "A revision description";
>     reference "";
>   }
> 
>   revision 2017-01-30 {
>     description
>       "A different revision with the same date";
>     reference "";
>   }
> 
> }
> 
> Thanks,
> Rob
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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 30 04:20: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 4D4E212998C for ; Mon, 30 Jan 2017 04:20:53 -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, 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03NwxMjAhGcy for ; Mon, 30 Jan 2017 04:20:51 -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 03FFB129465 for ; Mon, 30 Jan 2017 04:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2070; q=dns/txt; s=iport; t=1485778851; x=1486988451; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Jgenb8c9XvVevJIJIVFKDrFoMJI5v/FRpLGngPTZl80=; b=PyVcUo4oQi5x0E2FCaS2a63h/ON0OC4MGW6vCryeYv49/HTmFu9Vj0xX +VxtEpyZ6jtjiLqZhyCXZ1+ljmChUeMFR5L9G1kLrh07KMz+6bk0n/ZCI ntDwe9j69oIESBVWkya5A7LJZ9y8fP0kDRXFm6+EV9GdNgZmAhKMVIZI6 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAgAKL49Y/xbLJq1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ0Kl+NXnKQcR+VMoIMHwuFLkoCgk8YAQIBAQEBAQEBYiiEagE?= =?us-ascii?q?BBAEBNjYbCxguJzAGAQwGAgEBiWAOrSKKcAEBAQEBAQEBAQEBAQEBAQEBAQEaB?= =?us-ascii?q?YZLggUIgmKEIYYNAQSPMYwjkXuKOIY/iwCHfx84gRsTCBUVO4Y5QDWIMgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,311,1477958400"; d="scan'208";a="649241572"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2017 12:20:48 +0000
Received: from [10.63.23.109] (dhcp-ensft1-uk-vla370-10-63-23-109.cisco.com [10.63.23.109]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0UCKmZA025833; Mon, 30 Jan 2017 12:20:48 GMT
To: "netmod@ietf.org" , Andy Bierman 
References: <7b87a0ee-0c10-5f40-418e-4c125901e336@cisco.com> <20170130120503.GC56875@elstar.local>
From: Robert Wilton 
Message-ID: <89c0ce34-055e-5122-7296-39ebf067b808@cisco.com>
Date: Mon, 30 Jan 2017 12:20:48 +0000
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: <20170130120503.GC56875@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Are multiple revisions with the same date allowed?
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, 30 Jan 2017 12:20:53 -0000

Juergen,

Thanks.  This isn't something that we need - just something that I 
noticed when reading 7950.

I was more questioning whether it should be allowed, given that a 
(module name, revision date) pair should effectively uniquely identify a 
published module.  Conversely, having multiple revisions with the same 
date doesn't seem to cause any harm either - other than the ambiguity 
that you mention that module authors would be wise to avoid anyway.

Perhaps a statement could be added to 6087bis that revision dates for a 
module SHOULD be unique to avoid any potential ambiguity?

Rob


On 30/01/2017 12:05, Juergen Schoenwaelder wrote:
> Rob,
>
> since we are talking about _published_ modules, this is going to be
> rare. Perhaps we could have allowed an optional time specification
> here to handle this case (since multiple revisions with the same date
> cause ambiguity) but then in most organizations this is unlikely to
> happen (at least this is what we assumed).
>
> /js
>
> On Mon, Jan 30, 2017 at 11:50:20AM +0000, Robert Wilton wrote:
>> RFC 7950 doesn't state that the date associated with revision statements in
>> a YANG module must be unique.
>>
>> Hence, I presume that it is intentionally allowed to have multiple revision
>> statements with the same date.  E.g. the following module is allowed (and
>> passes pyang --lint):
>>
>> module rev-example {
>>    namespace
>>      "urn:example";
>>
>>    prefix ex;
>>
>>    organization "";
>>
>>    contact "";
>>
>>    description "'";
>>    reference "IEEE 802.3-2015, unless dated explicitly";
>>
>>    revision 2017-01-30 {
>>      description
>>        "A revision description";
>>      reference "";
>>    }
>>
>>    revision 2017-01-30 {
>>      description
>>        "A different revision with the same date";
>>      reference "";
>>    }
>>
>> }
>>
>> Thanks,
>> Rob
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Jan 30 04:50: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 047A012959D for ; Mon, 30 Jan 2017 04:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiFK5wOTr3mq for ; Mon, 30 Jan 2017 04:50:39 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BEF129477 for ; Mon, 30 Jan 2017 04:50:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D47231E5656; Mon, 30 Jan 2017 04:49:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pWEnExsR0YYS; Mon, 30 Jan 2017 04:49:33 -0800 (PST)
Received: from [192.168.1.127] (host5-81-223-185.range5-81.btcentralplus.com [5.81.223.185]) by c8a.amsl.com (Postfix) with ESMTPSA id 03C5D1E55CC; Mon, 30 Jan 2017 04:49:32 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: William Lupton 
In-Reply-To: <89c0ce34-055e-5122-7296-39ebf067b808@cisco.com>
Date: Mon, 30 Jan 2017 12:50:36 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7b87a0ee-0c10-5f40-418e-4c125901e336@cisco.com> <20170130120503.GC56875@elstar.local> <89c0ce34-055e-5122-7296-39ebf067b808@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Are multiple revisions with the same date allowed?
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, 30 Jan 2017 12:50:44 -0000

RFC 7950 Section 7.1.9 says that =E2=80=9CFor every published editorial =
change, a new one SHOULD be added in front of the revisions sequence so =
that all revisions are in reverse chronological order.=E2=80=9D So I =
think it probably SHOULD be an error if the revision dates aren=E2=80=99t =
monotonically decreasing (from top to bottom) but having two revisions =
with the same date doesn't seem to be ambiguous.

The practical issue, of course, is that per RFC 7950 Section 5.2, "The =
name of the file SHOULD be of the form: module-or-submodule-name ['@' =
revision-date] ( '.yang' / '.yin=E2=80=99 )=E2=80=9D, so if two =
revisions have the same revision date how are the files to be named?

Note that RFC 6087bis Section 5.8 says "However, whenever a new (i.e. =
changed) version is made available (e.g., via a new version of an =
Internet-Draft), the revision date of that new version MUST be updated =
to a date later than that of the previous version.=E2=80=9D This is a =
requirement that revision dates in =E2=80=9Cavailable=E2=80=9D versions =
are strictly increasing.

William

> On 30 Jan 2017, at 12:20, Robert Wilton  wrote:
>=20
> Juergen,
>=20
> Thanks.  This isn't something that we need - just something that I =
noticed when reading 7950.
>=20
> I was more questioning whether it should be allowed, given that a =
(module name, revision date) pair should effectively uniquely identify a =
published module.  Conversely, having multiple revisions with the same =
date doesn't seem to cause any harm either - other than the ambiguity =
that you mention that module authors would be wise to avoid anyway.
>=20
> Perhaps a statement could be added to 6087bis that revision dates for =
a module SHOULD be unique to avoid any potential ambiguity?
>=20
> Rob
>=20
>=20
> On 30/01/2017 12:05, Juergen Schoenwaelder wrote:
>> Rob,
>>=20
>> since we are talking about _published_ modules, this is going to be
>> rare. Perhaps we could have allowed an optional time specification
>> here to handle this case (since multiple revisions with the same date
>> cause ambiguity) but then in most organizations this is unlikely to
>> happen (at least this is what we assumed).
>>=20
>> /js
>>=20
>> On Mon, Jan 30, 2017 at 11:50:20AM +0000, Robert Wilton wrote:
>>> RFC 7950 doesn't state that the date associated with revision =
statements in
>>> a YANG module must be unique.
>>>=20
>>> Hence, I presume that it is intentionally allowed to have multiple =
revision
>>> statements with the same date.  E.g. the following module is allowed =
(and
>>> passes pyang --lint):
>>>=20
>>> module rev-example {
>>>   namespace
>>>     "urn:example";
>>>=20
>>>   prefix ex;
>>>=20
>>>   organization "";
>>>=20
>>>   contact "";
>>>=20
>>>   description "'";
>>>   reference "IEEE 802.3-2015, unless dated explicitly";
>>>=20
>>>   revision 2017-01-30 {
>>>     description
>>>       "A revision description";
>>>     reference "";
>>>   }
>>>=20
>>>   revision 2017-01-30 {
>>>     description
>>>       "A different revision with the same date";
>>>     reference "";
>>>   }
>>>=20
>>> }
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=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
>=20


From nobody Mon Jan 30 09:52: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 32E45129A3B for ; Mon, 30 Jan 2017 09:52:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_zIt6mIsH2o for ; Mon, 30 Jan 2017 09:52:34 -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 784EE129A2C for ; Mon, 30 Jan 2017 09:52:34 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id 11so137272558qkl.3 for ; Mon, 30 Jan 2017 09:52:34 -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=OVqKIYJHMW5qNg/mtJ4U3A1j95wnmVzKpbCJC730LHA=; b=sH7PpXFa/ttlO9BVy7KTWj5Nzd5QAZouvAlVwbbqMHmhvD2R7mGxgoTSp2aFY2drMC qpzNEAWw/uikgTDDTjOlZLtejDL1bbUYszqPZJEJ5t/fjFkCN+4R/ppgiARxZfjIinss Q6Cm9giV3MhAUAIaWPfh7NjYfZv5YoY/7s7vscjpYlfI6QRiDmiOZXGrXHQ+4o+jq717 462SFOrfYhEA66e5IRjRbCgTEDVIm9F28oO/jYZZNCUb7/FUWy4+wN/qkLfOqt2e332/ /QCTIga43UiLi2rlRBujrY5VhYKz+Fppp8C62aadfi4eFhCipL4/R6lAl2aj4A/u3uq4 yNsA==
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=OVqKIYJHMW5qNg/mtJ4U3A1j95wnmVzKpbCJC730LHA=; b=Ps4ENNkf3fC6w7DXChSrN6n9S88DbonRyJYNcwkge7V9I+l11dFlPwYnS6NDzKAxp9 wjNF9gw51j8YItQlLwO04QlB6Z3NxWgVNpKpZ84IJ4TTkzXDHFkTHiq8WfBERrISYsGe iNAKowsSjI+vdzqJ4EwlGUZ3QGwizzZyAwz7BCI8MYe1aA24B7vordnS9TKejUL1qWXT WrILb2ERaQGXtbktYs1Cwxgrm3eBZcSTl5iPzhKoEcrNpOjCZPOU5z9DM8Uyud5yn0yB NjIvIsnulghsLHhDne4eqGf4vU0P0Xa0ZoGE0NEqfqIVekjRUuFt0jmwCd8bQRxA0tUC hsOQ==
X-Gm-Message-State: AIkVDXIvYnBjkNWxPLnwExG8mVFEos/dr3oGjwOohWtlCikWL8xjqLCzHm97x8HimmhTX/NUWOK6+UQLgFWCrg==
X-Received: by 10.55.20.137 with SMTP id 9mr21863808qku.237.1485798753569; Mon, 30 Jan 2017 09:52:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Mon, 30 Jan 2017 09:52:33 -0800 (PST)
In-Reply-To: <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com>
References:    <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com>
From: Andy Bierman 
Date: Mon, 30 Jan 2017 09:52:33 -0800
Message-ID: 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a1144d226ea3f1b0547537a22
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 30 Jan 2017 17:52:38 -0000

--001a1144d226ea3f1b0547537a22
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton  wrote:

> Hi Andy, Lada,
>
> On 28/01/2017 16:23, Andy Bierman wrote:
>
>
>
> On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  wrote:
>
>>
>> > On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
>> >
>> > Hi,
>> >
>> > The "pyang --ietf" validator checks the statement order used in
>> data-def-stmts.
>> > There is no guideline that says this is required.
>> > RFC 7950 says canonical order is RECOMMENDED.
>> >
>> > 1) data-def sub-statement order
>> > Proposal: add new last sentence to sec. 4.6, para 3:
>> >
>> > YANG data definition sub-statements SHOULD be specified in canonical
>> order.
>>
>> IMO, this adds nothing to what's already stated in 7950. According to RFC
>> 2119, SHOULD and RECOMMENDED mean the same.
>>
>> I support Andy's recommendation here, although I think that it might also
> be useful to cross reference back to where the canonical order is actually
> defined in 7950.
>
> Lada, you are right that 7950 recommends the correct ordering, but I think
> that it is buried with the ABNF, which won't necessarily be read by all
> users of YANG.  Pulling it out in 6087bis doesn't seem to do any harm.
>
>
>
Actually, the RFC 7950 text is not really correct.
The canonical order does not apply to the relative order of
container, list, leaf-list, leaf, choice, case, anyxml, or anydata.

We list these nodes in the relative order we want in the data structure,
not all containers first, then all leafs, etc.  That is why my text says
'data definition sub-statements'.


Andy


>
>
> OK
>
>
>
>> >
>> >
>> > 2) enum/bit statement ordering
>> >
>> > Proposal: add new para 2 to  sec 5.11.3:
>> >
>> > The 'enum' statements within an 'enumeration' data type SHOULD be
>> > specified in ascending order, based on the implied and/or explicit
>> values
>> > of the 'value' sub-statement. The 'bit' statements within a 'bits' data
>> type
>> > SHOULD be specified in ascending order, based on the implied and/or
>> > explicit values of the 'position' sub-statement.
>>
>> I don't agree. For some enumerations, especially those with a large
>> number of enums, it is much more useful for the reader to have the enums
>> ordered differently, e.g. alphabetically or geographically. On the other
>> hand, numeric enum values often need to be assigned in the order how enums
>> are defined in subsequent revisions.
>>
>>
>
> We have been using ascending order in MIB modules and YANG modules
> all along.  I think there are about 5000 modules in ascending order and
> one not
> in ascending order.  The guideline is SHOULD anyway.
>
> +1.  Isn't this exactly what a SHOULD statement means.  I.e. put in
> ascending order unless there is a good reason not to do so (e.g. as per
> Lada's examples), in which case that is fine.
>
> Rob
>
>
>
> YANG prohibits the value or position numbers from changing in
> a new revision, so preserving previous ordering is required.
>
>
>> Lada
>>
>
> Andy
>
>
>>
>> >
>> >
>> >
>> > Andy
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>

--001a1144d226ea3f1b0547537a22
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Andy, Lada,

    

    

    
On 28/01/2017 16:2=
3, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Sat, Jan 28, 2017 at 2:54 AM,
            Ladislav Lhotka <lhotka@nic.cz> wrote:

            


              > On 27 Jan 2017, at 20:23, Andy Bierman <andy@yumaworks.com>
              wrote:

              >

              > Hi,

              >

              > The "pyang --ietf" validator checks the statem=
ent
              order used in data-def-stmts.

              > There is no guideline that says this is required.

              > RFC 7950 says canonical order is RECOMMENDED.

              >

              > 1) data-def sub-statement order

              > Proposal: add new last sentence to sec. 4.6, para 3:

              >

              > YANG data definition sub-statements SHOULD be
              specified in canonical order.

              

              IMO, this adds nothing to what's already stated in 7950.
              According to RFC 2119, SHOULD and RECOMMENDED mean the
              same.

              

            

          

        

      

    

    I support Andy's recommendation here, although I think that it migh=
t
    also be useful to cross reference back to where the canonical order
    is actually defined in 7950.

    

    Lada, you are right that 7950 recommends the correct ordering, but I
    think that it is buried with the ABNF, which won't necessarily be
    read by all users of YANG.=C2=A0 Pulling it out in 6087bis doesn't =
seem
    to do any harm.

    

    

Actually, the RFC 7950 text =
is not really correct.
The canonical order does not apply to the =
relative order of
container, list, leaf-list, leaf, choice, case,=
 anyxml, or anydata.

We list these nodes in the re=
lative order we want in the data structure,
not all containers fi=
rst, then all leafs, etc.=C2=A0 That is why my text says
'dat=
a definition sub-statements'.


A=
ndy


    

      

        

          

            


            

            


            

            


            

            
OK

            


            

            
=C2=A0

            

              >

              >

              > 2) enum/bit statement ordering

              >

              > Proposal: add new para 2 to=C2=A0 sec 5.11.3:

              >

              > The 'enum' statements within an 'enumeration=
' data
              type SHOULD be

              > specified in ascending order, based on the implied
              and/or explicit values

              > of the 'value' sub-statement. The 'bit' =
statements
              within a 'bits' data type

              > SHOULD be specified in ascending order, based on the
              implied and/or

              > explicit values of the 'position' sub-statement.=


              

              I don't agree. For some enumerations, especially those
              with a large number of enums, it is much more useful for
              the reader to have the enums ordered differently, e.g.
              alphabetically or geographically. On the other hand,
              numeric enum values often need to be assigned in the order
              how enums are defined in subsequent revisions.

              

            

            


            

            


            

            
We have been using ascending order in MIB modules and
              YANG modules

            
all along.=C2=A0 I think there are about 5000 modules in
              ascending order and one not

            
in ascending order.=C2=A0 The guideline is SHOULD anyway.<=
/div>
          

        

      

    

    +1.=C2=A0 Isn't this exactly what a SHOULD statement means.=C2=A0 I=
.e. put in
    ascending order unless there is a good reason not to do so (e.g. as
    per Lada's examples), in which case that is fine.

    

    Rob

    

    

    

      

        

          

            


            

            
YANG prohibits the value or position numbers from
              changing in

            
a new revision, so preserving previous ordering is
              required.

            
=C2=A0

            

              Lada

            

            


            

            
Andy

            
=C2=A0

            

              

              >

              >

              >

              > Andy

              >

              > _______________________________________________

              > netmod mailing list

              > net=
mod@ietf.org

              > https://www.ietf.org/mailman/lis=
tinfo/netmod

              

              --

              Ladislav Lhotka, CZ.NIC Labs

              PGP Key ID: 0xB8F92B08A9F76C67

              

              

              

              

              

            

          

          

        

      

      

      

      

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


    

    

  






--001a1144d226ea3f1b0547537a22--


From nobody Mon Jan 30 10:09: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 F1828129A80 for ; Mon, 30 Jan 2017 10:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.719
X-Spam-Level: 
X-Spam-Status: No, score=-17.719 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHaQeQu0QjB7 for ; Mon, 30 Jan 2017 10:09:53 -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 A8933129A75 for ; Mon, 30 Jan 2017 10:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18836; q=dns/txt; s=iport; t=1485799792; x=1487009392; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ylP3O/EzVADzKb6X0/kH3X4WyQpvBLjHb6mvsEGk/w4=; b=gYMUeU8gt+tUXaADfUCCz7Sm5aBjqBU39FBU+5JcFf3qoRiTbym9oZlu uejnWnFppYP0RkhhLr8Ka/6gT+bA1PtZe/6GCosuZKDMGt3/rfpxCS1dB +Ga/2c0ysPoj/zJ5mDgTTTxJQIStC5wl31rhpsk4MZ2d5NGlB06RQnm8d o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAQDXgI9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+BRQMnX4NViglykRKVMoIMHwEKhS5KAoJgGAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEDAQEBIUsLBQsLFQMnAwICJx8RBg0GAgEBiVUIDqsMgiUrimgBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYZLggWCaodPgl8Fm1SKAYd6gXmIPyOGHIsAh38?= =?us-ascii?q?fOIEbEwgVFTuEBII1QDWFeCuCDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,312,1477958400";  d="scan'208,217";a="652092264"
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; 30 Jan 2017 18:09:50 +0000
Received: from [10.63.23.109] (dhcp-ensft1-uk-vla370-10-63-23-109.cisco.com [10.63.23.109]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0UI9oVR007219; Mon, 30 Jan 2017 18:09:50 GMT
To: Andy Bierman 
References:    <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com> 
From: Robert Wilton 
Message-ID: <9999f224-c136-93cd-35c2-54c59e211a38@cisco.com>
Date: Mon, 30 Jan 2017 18:09:48 +0000
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: 
Content-Type: multipart/alternative; boundary="------------94C8904C6AF5128AA159F7D0"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 30 Jan 2017 18:09:55 -0000

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



On 30/01/2017 17:52, Andy Bierman wrote:
>
>
> On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton  > wrote:
>
>     Hi Andy, Lada,
>
>
>     On 28/01/2017 16:23, Andy Bierman wrote:
>>
>>
>>     On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka >     > wrote:
>>
>>
>>         > On 27 Jan 2017, at 20:23, Andy Bierman >         > wrote:
>>         >
>>         > Hi,
>>         >
>>         > The "pyang --ietf" validator checks the statement order
>>         used in data-def-stmts.
>>         > There is no guideline that says this is required.
>>         > RFC 7950 says canonical order is RECOMMENDED.
>>         >
>>         > 1) data-def sub-statement order
>>         > Proposal: add new last sentence to sec. 4.6, para 3:
>>         >
>>         > YANG data definition sub-statements SHOULD be specified in
>>         canonical order.
>>
>>         IMO, this adds nothing to what's already stated in 7950.
>>         According to RFC 2119, SHOULD and RECOMMENDED mean the same.
>>
>     I support Andy's recommendation here, although I think that it
>     might also be useful to cross reference back to where the
>     canonical order is actually defined in 7950.
>
>     Lada, you are right that 7950 recommends the correct ordering, but
>     I think that it is buried with the ABNF, which won't necessarily
>     be read by all users of YANG. Pulling it out in 6087bis doesn't
>     seem to do any harm.
>
>
>
> Actually, the RFC 7950 text is not really correct.
> The canonical order does not apply to the relative order of
> container, list, leaf-list, leaf, choice, case, anyxml, or anydata.
>
> We list these nodes in the relative order we want in the data structure,
> not all containers first, then all leafs, etc.  That is why my text says
> 'data definition sub-statements'.

Is this worth adding as an errata to 7950 then?

From:

    data-def-stmt       = container-stmt /
                          leaf-stmt /
                          leaf-list-stmt /
                          list-stmt /
                          choice-stmt /
                          anydata-stmt /
                          anyxml-stmt /
                          uses-stmt

To:
    data-def-stmt       = ;; these stmts can appear in any order
                          container-stmt /
                          leaf-stmt /
                          leaf-list-stmt /
                          list-stmt /
                          choice-stmt /
                          anydata-stmt /
                          anyxml-stmt /
                          uses-stmt


Otherwise, if I am reading it correctly, it seems to imply that the top 
level data-defn stmts in a module/sub-module must be in the order above?

Rob


>
>
> Andy
>
>>
>>
>>
>>     OK
>>
>>         >
>>         >
>>         > 2) enum/bit statement ordering
>>         >
>>         > Proposal: add new para 2 to  sec 5.11.3:
>>         >
>>         > The 'enum' statements within an 'enumeration' data type
>>         SHOULD be
>>         > specified in ascending order, based on the implied and/or
>>         explicit values
>>         > of the 'value' sub-statement. The 'bit' statements within a
>>         'bits' data type
>>         > SHOULD be specified in ascending order, based on the
>>         implied and/or
>>         > explicit values of the 'position' sub-statement.
>>
>>         I don't agree. For some enumerations, especially those with a
>>         large number of enums, it is much more useful for the reader
>>         to have the enums ordered differently, e.g. alphabetically or
>>         geographically. On the other hand, numeric enum values often
>>         need to be assigned in the order how enums are defined in
>>         subsequent revisions.
>>
>>
>>
>>     We have been using ascending order in MIB modules and YANG modules
>>     all along.  I think there are about 5000 modules in ascending
>>     order and one not
>>     in ascending order.  The guideline is SHOULD anyway.
>     +1.  Isn't this exactly what a SHOULD statement means. I.e. put in
>     ascending order unless there is a good reason not to do so (e.g.
>     as per Lada's examples), in which case that is fine.
>
>     Rob
>
>
>>
>>     YANG prohibits the value or position numbers from changing in
>>     a new revision, so preserving previous ordering is required.
>>
>>         Lada
>>
>>
>>     Andy
>>
>>
>>         >
>>         >
>>         >
>>         > Andy
>>         >
>>         > _______________________________________________
>>         > netmod mailing list
>>         > netmod@ietf.org 
>>         > https://www.ietf.org/mailman/listinfo/netmod
>>         
>>
>>         --
>>         Ladislav Lhotka, CZ.NIC Labs
>>         PGP Key ID: 0xB8F92B08A9F76C67
>>
>>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     netmod@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/netmod
>>     
>

--------------94C8904C6AF5128AA159F7D0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 30/01/2017 17:52, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Jan 30, 2017 at 3:38 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
Hi Andy, Lada,

                

                

                
On
                  28/01/2017 16:23, Andy Bierman wrote:

                

                

                  


                    


                      
On Sat, Jan 28, 2017 at
                        2:54 AM, Ladislav Lhotka <lhotka@nic.cz>
                        wrote:

                        


                          > On 27 Jan 2017, at 20:23, Andy Bierman
                          <andy@yumaworks.com>
                          wrote:

                          >

                          > Hi,

                          >

                          > The "pyang --ietf" validator checks the
                          statement order used in data-def-stmts.

                          > There is no guideline that says this is
                          required.

                          > RFC 7950 says canonical order is
                          RECOMMENDED.

                          >

                          > 1) data-def sub-statement order

                          > Proposal: add new last sentence to sec.
                          4.6, para 3:

                          >

                          > YANG data definition sub-statements
                          SHOULD be specified in canonical order.

                          

                          IMO, this adds nothing to what's already
                          stated in 7950. According to RFC 2119, SHOULD
                          and RECOMMENDED mean the same.

                          

                        

                      

                    

                  

                

                I support Andy's recommendation here, although I think
                that it might also be useful to cross reference back to
                where the canonical order is actually defined in 7950.

                

                Lada, you are right that 7950 recommends the correct
                ordering, but I think that it is buried with the ABNF,
                which won't necessarily be read by all users of YANG. 
                Pulling it out in 6087bis doesn't seem to do any harm.

                

                

              

            

            


            

            
Actually, the RFC 7950 text is not really correct.

            
The canonical order does not apply to the relative
              order of

            
container, list, leaf-list, leaf, choice, case, anyxml,
              or anydata.

            


            

            
We list these nodes in the relative order we want in
              the data structure,

            
not all containers first, then all leafs, etc.  That is
              why my text says

            
'data definition sub-statements'.

          

        

      

    

    

    Is this worth adding as an errata to 7950 then?

    

    From:

    
   data-def-stmt       = container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         choice-stmt /
                         anydata-stmt /
                         anyxml-stmt /
                         uses-stmt

To:
   data-def-stmt       = ;; these stmts can appear in any order
                         container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         choice-stmt /
                         anydata-stmt /
                         anyxml-stmt /
                         uses-stmt


    

    Otherwise, if I am reading it correctly, it seems to imply that the
    top level data-defn stmts in a module/sub-module must be in the
    order above?

    

    Rob

    

    

    

      

        

          

            


            

            


            

            
Andy

            


            

            

              

                

                  

                    

                      

                        


                        

                        


                        

                        


                        

                        
OK

                        


                        

                        
 

                        
 >

                          >

                          > 2) enum/bit statement ordering

                          >

                          > Proposal: add new para 2 to  sec 5.11.3:

                          >

                          > The 'enum' statements within an
                          'enumeration' data type SHOULD be

                          > specified in ascending order, based on
                          the implied and/or explicit values

                          > of the 'value' sub-statement. The 'bit'
                          statements within a 'bits' data type

                          > SHOULD be specified in ascending order,
                          based on the implied and/or

                          > explicit values of the 'position'
                          sub-statement.

                          

                          I don't agree. For some enumerations,
                          especially those with a large number of enums,
                          it is much more useful for the reader to have
                          the enums ordered differently, e.g.
                          alphabetically or geographically. On the other
                          hand, numeric enum values often need to be
                          assigned in the order how enums are defined in
                          subsequent revisions.

                          

                        

                        


                        

                        


                        

                        
We have been using ascending order in MIB
                          modules and YANG modules

                        
all along.  I think there are about 5000
                          modules in ascending order and one not

                        
in ascending order.  The guideline is
                          SHOULD anyway.

                      

                    

                  

                

                +1.  Isn't this exactly what a SHOULD statement means. 
                I.e. put in ascending order unless there is a good
                reason not to do so (e.g. as per Lada's examples), in
                which case that is fine.

                

                Rob

                

                

                

                  

                    

                      

                        


                        

                        
YANG prohibits the value or position
                          numbers from changing in

                        
a new revision, so preserving previous
                          ordering is required.

                        
 

                        
 Lada

                        

                        


                        

                        
Andy

                        
 

                        
 

                          >

                          >

                          >

                          > Andy

                          >

                          > _______________________________________________

                          > netmod mailing list

                          > netmod@ietf.org

                          > https://www.ietf.org/mailman/listinfo/netmod

                          

                          --

                          Ladislav Lhotka, CZ.NIC Labs

                          PGP Key ID: 0xB8F92B08A9F76C67

                          

                          

                          

                          

                          

                        

                      

                      

                    

                  

                  

                  

                  

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


    

    

  












--------------94C8904C6AF5128AA159F7D0--


From nobody Mon Jan 30 12:07: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 62F6F129B39 for ; Mon, 30 Jan 2017 12:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.198
X-Spam-Level: 
X-Spam-Status: No, score=-10.198 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AGr9OzH-2Cx for ; Mon, 30 Jan 2017 12:07:50 -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 30725129B13 for ; Mon, 30 Jan 2017 12:07:47 -0800 (PST)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id EE6A560CAE; Mon, 30 Jan 2017 21:07:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485806865; bh=+zqHLmSN1sN7fZggu3nbgBNGp7gf2kkfu5WgiqJKEFg=; h=From:Date:To; b=Y8+1OumHxq+kHLLDno/8/2aydf9MEaryXjcnAI6xP93aaG1kiVdLtsGx/hedz0KFV fBKgV5HPNES/GlhbBLrhKaqxx/J39WsKKBLzP3AWfivtg+lVd+63fIcmrl1UVsoxpA jCZ7BsiTdYeq6HjCMujgmUGqS3MgRAVyYTYkFlmM=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <9999f224-c136-93cd-35c2-54c59e211a38@cisco.com>
Date: Mon, 30 Jan 2017 21:07:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EBB38BD-FE11-44B5-8CA8-FB9AB03E7906@nic.cz>
References:    <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com>  <9999f224-c136-93cd-35c2-54c59e211a38@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: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 30 Jan 2017 20:07:52 -0000

> On 30 Jan 2017, at 19:09, Robert Wilton  wrote:
>=20
>=20
>=20
> On 30/01/2017 17:52, Andy Bierman wrote:
>>=20
>>=20
>> On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton  =
wrote:
>> Hi Andy, Lada,
>>=20
>> On 28/01/2017 16:23, Andy Bierman wrote:
>>>=20
>>>=20
>>> On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  =
wrote:
>>>=20
>>> > On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
>>> >
>>> > Hi,
>>> >
>>> > The "pyang --ietf" validator checks the statement order used in =
data-def-stmts.
>>> > There is no guideline that says this is required.
>>> > RFC 7950 says canonical order is RECOMMENDED.
>>> >
>>> > 1) data-def sub-statement order
>>> > Proposal: add new last sentence to sec. 4.6, para 3:
>>> >
>>> > YANG data definition sub-statements SHOULD be specified in =
canonical order.
>>>=20
>>> IMO, this adds nothing to what's already stated in 7950. According =
to RFC 2119, SHOULD and RECOMMENDED mean the same.
>>>=20
>> I support Andy's recommendation here, although I think that it might =
also be useful to cross reference back to where the canonical order is =
actually defined in 7950.
>>=20
>> Lada, you are right that 7950 recommends the correct ordering, but I =
think that it is buried with the ABNF, which won't necessarily be read =
by all users of YANG.  Pulling it out in 6087bis doesn't seem to do any =
harm.
>>=20
>>=20
>>=20
>> Actually, the RFC 7950 text is not really correct.
>> The canonical order does not apply to the relative order of
>> container, list, leaf-list, leaf, choice, case, anyxml, or anydata.
>>=20
>> We list these nodes in the relative order we want in the data =
structure,
>> not all containers first, then all leafs, etc.  That is why my text =
says
>> 'data definition sub-statements'.
>=20
> Is this worth adding as an errata to 7950 then?
>=20
> From:
>    data-def-stmt       =3D container-stmt /
>                          leaf-stmt /
>                          leaf-list-stmt /
>                          list-stmt /
>                          choice-stmt /
>                          anydata-stmt /
>                          anyxml-stmt /
>                          uses-stmt
>=20
> To:
>    data-def-stmt       =3D ;; these stmts can appear in any order
>                          container-stmt /
>                          leaf-stmt /
>                          leaf-list-stmt /
>                          list-stmt /
>                          choice-stmt /
>                          anydata-stmt /
>                          anyxml-stmt /
>                          uses-stmt
>=20
>=20
> Otherwise, if I am reading it correctly, it seems to imply that the =
top level data-defn stmts in a module/sub-module must be in the order =
above?

No, as it is a list of alternatives. Each time "data-def-stmt" is =
applied you can choose any one of the alternatives.

Lada

>=20
> Rob
>=20
>=20
>>=20
>>=20
>> Andy
>>=20
>>>=20
>>>=20
>>>=20
>>> OK
>>>=20
>>> =20
>>> >
>>> >
>>> > 2) enum/bit statement ordering
>>> >
>>> > Proposal: add new para 2 to  sec 5.11.3:
>>> >
>>> > The 'enum' statements within an 'enumeration' data type SHOULD be
>>> > specified in ascending order, based on the implied and/or explicit =
values
>>> > of the 'value' sub-statement. The 'bit' statements within a 'bits' =
data type
>>> > SHOULD be specified in ascending order, based on the implied =
and/or
>>> > explicit values of the 'position' sub-statement.
>>>=20
>>> I don't agree. For some enumerations, especially those with a large =
number of enums, it is much more useful for the reader to have the enums =
ordered differently, e.g. alphabetically or geographically. On the other =
hand, numeric enum values often need to be assigned in the order how =
enums are defined in subsequent revisions.
>>>=20
>>>=20
>>>=20
>>> We have been using ascending order in MIB modules and YANG modules
>>> all along.  I think there are about 5000 modules in ascending order =
and one not
>>> in ascending order.  The guideline is SHOULD anyway.
>> +1.  Isn't this exactly what a SHOULD statement means.  I.e. put in =
ascending order unless there is a good reason not to do so (e.g. as per =
Lada's examples), in which case that is fine.
>>=20
>> Rob
>>=20
>>=20
>>>=20
>>> YANG prohibits the value or position numbers from changing in
>>> a new revision, so preserving previous ordering is required.
>>> =20
>>> Lada
>>>=20
>>> Andy
>>> =20
>>>=20
>>> >
>>> >
>>> >
>>> > Andy
>>> >
>>> > _______________________________________________
>>> > netmod mailing list
>>> > netmod@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> ______________________________
>>> _________________
>>> netmod mailing list
>>>=20
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod

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






From nobody Mon Jan 30 13:17: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 6E18A1295CB for ; Mon, 30 Jan 2017 13:16:59 -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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb-M0Q2anIKt for ; Mon, 30 Jan 2017 13:16:58 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 213C0129580 for ; Mon, 30 Jan 2017 13:16:58 -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 8D85D1AE01AA; Mon, 30 Jan 2017 22:16:56 +0100 (CET)
Date: Mon, 30 Jan 2017 22:16:56 +0100 (CET)
Message-Id: <20170130.221656.939625061655050331.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@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=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 30 Jan 2017 21:16:59 -0000

Andy Bierman  wrote:
> On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton  wrote:
> 
> > Hi Andy, Lada,
> >
> > On 28/01/2017 16:23, Andy Bierman wrote:
> >
> >
> >
> > On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  wrote:
> >
> >>
> >> > On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
> >> >
> >> > Hi,
> >> >
> >> > The "pyang --ietf" validator checks the statement order used in
> >> data-def-stmts.
> >> > There is no guideline that says this is required.
> >> > RFC 7950 says canonical order is RECOMMENDED.
> >> >
> >> > 1) data-def sub-statement order
> >> > Proposal: add new last sentence to sec. 4.6, para 3:
> >> >
> >> > YANG data definition sub-statements SHOULD be specified in canonical
> >> order.
> >>
> >> IMO, this adds nothing to what's already stated in 7950. According to RFC
> >> 2119, SHOULD and RECOMMENDED mean the same.
> >>
> >> I support Andy's recommendation here, although I think that it might also
> > be useful to cross reference back to where the canonical order is actually
> > defined in 7950.
> >
> > Lada, you are right that 7950 recommends the correct ordering, but I think
> > that it is buried with the ABNF, which won't necessarily be read by all
> > users of YANG.  Pulling it out in 6087bis doesn't seem to do any harm.
> >
> >
> >
> Actually, the RFC 7950 text is not really correct.
> The canonical order does not apply to the relative order of
> container, list, leaf-list, leaf, choice, case, anyxml, or anydata.

I think RFC 7950 is correct.  It says:

  The ABNF grammar defines the canonical order.

and the grammar allows mixing of container/list etc. (see also Lada's
email).


/martin


From nobody Tue Jan 31 00:48:37 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 F4178129444 for ; Tue, 31 Jan 2017 00:48:34 -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 JrBEq72FEzeL for ; Tue, 31 Jan 2017 00:48:33 -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 27479126D73 for ; Tue, 31 Jan 2017 00:48:33 -0800 (PST)
Received: from [172.29.2.201] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id C56C460ABD; Tue, 31 Jan 2017 09:48:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1485852511; bh=dkwvaT8EW7e4QfW51Hpsz+3pVi4aijs8XxiG3bCtA8Y=; h=From:Date:To; b=D4HMwln0jS4BoNFxcJp7UP07F3YedyH4GQfqGrwch6IjvWMa9ZtTtjE1HDjuiy5pB hjmpPD1XRl0UE+sx4OXv5d6jHiwKheBFefsJl3KVwY5yTnDUkRXzn3+ATy8T934IpJ BcwzVKCbwD9Ha2KvFwKeZq6B6wiWBtzGMaNZuT4I=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka 
In-Reply-To: <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com>
Date: Tue, 31 Jan 2017 09:48:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <661B2A61-9F22-4836-9F50-CDDB7878D069@nic.cz>
References:    <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@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: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 31 Jan 2017 08:48:35 -0000

> On 30 Jan 2017, at 12:38, Robert Wilton  wrote:
>=20
> Hi Andy, Lada,
>=20
> On 28/01/2017 16:23, Andy Bierman wrote:
>>=20
>>=20
>> On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  =
wrote:
>>=20
>> > On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
>> >
>> > Hi,
>> >
>> > The "pyang --ietf" validator checks the statement order used in =
data-def-stmts.
>> > There is no guideline that says this is required.
>> > RFC 7950 says canonical order is RECOMMENDED.
>> >
>> > 1) data-def sub-statement order
>> > Proposal: add new last sentence to sec. 4.6, para 3:
>> >
>> > YANG data definition sub-statements SHOULD be specified in =
canonical order.
>>=20
>> IMO, this adds nothing to what's already stated in 7950. According to =
RFC 2119, SHOULD and RECOMMENDED mean the same.
>>=20
> I support Andy's recommendation here, although I think that it might =
also be useful to cross reference back to where the canonical order is =
actually defined in 7950.
>=20
> Lada, you are right that 7950 recommends the correct ordering, but I =
think that it is buried with the ABNF, which won't necessarily be     =
read by all users of YANG.  Pulling it out in 6087bis doesn't seem to do =
any harm.

OK

>=20
>=20
>>=20
>>=20
>>=20
>> OK
>>=20
>> =20
>> >
>> >
>> > 2) enum/bit statement ordering
>> >
>> > Proposal: add new para 2 to  sec 5.11.3:
>> >
>> > The 'enum' statements within an 'enumeration' data type SHOULD be
>> > specified in ascending order, based on the implied and/or explicit =
values
>> > of the 'value' sub-statement. The 'bit' statements within a 'bits' =
data type
>> > SHOULD be specified in ascending order, based on the implied and/or
>> > explicit values of the 'position' sub-statement.
>>=20
>> I don't agree. For some enumerations, especially those with a large =
number of enums, it is much more useful for the reader to have the enums =
ordered differently, e.g. alphabetically or geographically. On the other =
hand, numeric enum values often need to be assigned in the order how =
enums are defined in subsequent revisions.
>>=20
>>=20
>>=20
>> We have been using ascending order in MIB modules and YANG modules
>> all along.  I think there are about 5000 modules in ascending order =
and one not
>> in ascending order.  The guideline is SHOULD anyway.
> +1.  Isn't this exactly what a SHOULD statement means.  I.e. put in =
ascending order unless there is a good reason not to do so (e.g. as per =
Lada's examples), in which case that is fine.

If tools are supposed to issue a warning, and drafts to be flagged in =
Benoit's list, then it becomes a significant annoyance. How about this =
formulation:

The "enum" and "bit" statements SHOULD be ordered in a way that is =
appropriate for a given parameter, e.g., alphabetically or by numeric =
values or positions.

Lada=20

>=20
> Rob
>=20
>=20
>>=20
>> YANG prohibits the value or position numbers from changing in
>> a new revision, so preserving previous ordering is required.
>> =20
>> Lada
>>=20
>> Andy
>> =20
>>=20
>> >
>> >
>> >
>> > Andy
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>>=20
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20

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






From nobody Tue Jan 31 01:48:35 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 EF1181293F0 for ; Tue, 31 Jan 2017 01:48:33 -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 jhWs9Dm-IkZJ for ; Tue, 31 Jan 2017 01:48:32 -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 7D3DE128AB0 for ; Tue, 31 Jan 2017 01:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3108; q=dns/txt; s=iport; t=1485856112; x=1487065712; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=T+8+YSMUTXgkfCsOkxX0T7K8oKXZ+5DrYoGu3kvB5g8=; b=T8M3clV+3ioyfwkJ/o4cEalrNzX0hwfVF9usDsOqF4AcNPYTPzhKuiik 9Kyzb6vuHoXr3xMAG0FWei2P95+NUavsibA2KpgtnT9QJzXbOqADiBmmC zpGGYmaqNv/2qHqBot0Ekid03oXLHoZAEKKN4z7w6/Uhpd0+HocSsijQt c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQD7XJBY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhF9fjV9ykRSVM4INhiICgloYAQIBAQEBAQEBYiiEaQEBAQQ4QRA?= =?us-ascii?q?LFQMuVwYNBgIBAYlqrViLHgEBAQEBAQEBAQEBAQEBAQEBIYZLggWCaooxAQSbV?= =?us-ascii?q?4oBh32BeYg/I4YdiwCHfx84gRsTCBUVO4Y5QDWGByuCDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,314,1477958400"; d="scan'208";a="691829831"
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; 31 Jan 2017 09:48:30 +0000
Received: from [10.63.23.109] (dhcp-ensft1-uk-vla370-10-63-23-109.cisco.com [10.63.23.109]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0V9mT1w020520; Tue, 31 Jan 2017 09:48:30 GMT
To: Ladislav Lhotka 
References:    <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com>  <9999f224-c136-93cd-35c2-54c59e211a38@cisco.com> <2EBB38BD-FE11-44B5-8CA8-FB9AB03E7906@nic.cz>
From: Robert Wilton 
Message-ID: <7f7dc692-fe93-8ac1-ac25-10187e3f1a23@cisco.com>
Date: Tue, 31 Jan 2017 09:48:29 +0000
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: <2EBB38BD-FE11-44B5-8CA8-FB9AB03E7906@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 31 Jan 2017 09:48:34 -0000

On 30/01/2017 20:07, Ladislav Lhotka wrote:
>> On 30 Jan 2017, at 19:09, Robert Wilton  wrote:
>>
>>
>>
>> On 30/01/2017 17:52, Andy Bierman wrote:
>>>
>>> On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton  wrote:
>>> Hi Andy, Lada,
>>>
>>> On 28/01/2017 16:23, Andy Bierman wrote:
>>>>
>>>> On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka  wrote:
>>>>
>>>>> On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> The "pyang --ietf" validator checks the statement order used in data-def-stmts.
>>>>> There is no guideline that says this is required.
>>>>> RFC 7950 says canonical order is RECOMMENDED.
>>>>>
>>>>> 1) data-def sub-statement order
>>>>> Proposal: add new last sentence to sec. 4.6, para 3:
>>>>>
>>>>> YANG data definition sub-statements SHOULD be specified in canonical order.
>>>> IMO, this adds nothing to what's already stated in 7950. According to RFC 2119, SHOULD and RECOMMENDED mean the same.
>>>>
>>> I support Andy's recommendation here, although I think that it might also be useful to cross reference back to where the canonical order is actually defined in 7950.
>>>
>>> Lada, you are right that 7950 recommends the correct ordering, but I think that it is buried with the ABNF, which won't necessarily be read by all users of YANG.  Pulling it out in 6087bis doesn't seem to do any harm.
>>>
>>>
>>>
>>> Actually, the RFC 7950 text is not really correct.
>>> The canonical order does not apply to the relative order of
>>> container, list, leaf-list, leaf, choice, case, anyxml, or anydata.
>>>
>>> We list these nodes in the relative order we want in the data structure,
>>> not all containers first, then all leafs, etc.  That is why my text says
>>> 'data definition sub-statements'.
>> Is this worth adding as an errata to 7950 then?
>>
>> From:
>>     data-def-stmt       = container-stmt /
>>                           leaf-stmt /
>>                           leaf-list-stmt /
>>                           list-stmt /
>>                           choice-stmt /
>>                           anydata-stmt /
>>                           anyxml-stmt /
>>                           uses-stmt
>>
>> To:
>>     data-def-stmt       = ;; these stmts can appear in any order
>>                           container-stmt /
>>                           leaf-stmt /
>>                           leaf-list-stmt /
>>                           list-stmt /
>>                           choice-stmt /
>>                           anydata-stmt /
>>                           anyxml-stmt /
>>                           uses-stmt
>>
>>
>> Otherwise, if I am reading it correctly, it seems to imply that the top level data-defn stmts in a module/sub-module must be in the order above?
> No, as it is a list of alternatives. Each time "data-def-stmt" is applied you can choose any one of the alternatives.
Ah, yes.  So given that the grammar is 7950 is correct, then presumably 
it is reasonable to reference it from 6087bis.

Rob


From nobody Tue Jan 31 20:19:35 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 BA245129C64; Tue, 31 Jan 2017 20:19:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.41.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148592277475.6031.17766422199447171451.idtracker@ietfa.amsl.com>
Date: Tue, 31 Jan 2017 20:19:34 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-10.txt
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, 01 Feb 2017 04:19:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

        Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
        Author          : Andy Bierman
	Filename        : draft-ietf-netmod-rfc6087bis-10.txt
	Pages           : 67
	Date            : 2017-01-31

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-10


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Jan 31 20:21: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 0BCD7129C69 for ; Tue, 31 Jan 2017 20:21:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZJRG6pYdZ4y for ; Tue, 31 Jan 2017 20:21:27 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 007F0129C68 for ; Tue, 31 Jan 2017 20:21:26 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id w20so184837271qtb.1 for ; Tue, 31 Jan 2017 20:21:26 -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=qkRsUmkNARv5aVn9VRjezj36Trjw8Q1ljba/Ppgu6+o=; b=QGPRp5M1kT1yzHAcyvgThRq+TVWLKQhD6Iptk+dejsHB5U1ErLzIjveIo5+MNIi09l PzBXzL/Mty5k9nKJkbFOqhyh7NVOkOf0AMCPc8aD8FAknQprDKTmDIRHP5yNWjDGdm91 A7vtdP1rnw4x0i23rgJEYwltQzx2Lsq5YoNjK1OQPV+hXYJGS+J/ABUV/5vlntHnES5Z eC+ngkEFAopHdo4ZYgGuYNc3EQLI95Le67BjcAZcBDTXn+UIRGqaUksDCo8afGo1fqC4 Epu0kI/EKGh27aXJ4lLMhbvs4TQ/qTGsFu73H0Uf0pBTjLfyteRzMgzD9giaoo7ZN6HD 7ukg==
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=qkRsUmkNARv5aVn9VRjezj36Trjw8Q1ljba/Ppgu6+o=; b=IciH1gYedj4gjXXGbZwJOygbMVBQiKgGlxsHl3XCI4kx5WWfEN8JRQr7Q33wjzvk9O xmShr98sceJZAn43Ljx0aS5szourWspclG5g/AjsHwCXKGa7xYc3RFXF+RcPLUwoONpW c2ZS2/NJonxXJWq2hooxyl7dgJj2HBzRpdTJNgv5UPjab95IwATuNAtrxWJ3lqjoF/a1 +UMd3RbMu7KTtQi4mZ9Ms8LLya4FG95NVdPz8SkLNnzAQ6g0JmR8i0gPRZ2iTxKmlx14 fIxsnWN3/AmijHhDohAXrkV3Ji8+oyu2TKqMQ966qNVUGx93gZT3orOQ9dWP3g+JVaWj TzPg==
X-Gm-Message-State: AIkVDXKb/Nex0RhXx/cxVviV+U9JIhh8DQeMEF4fCueg6g5I7Po5sp9G5nTvN6oem2Gs+PNoU/VGykh9XJZnbw==
X-Received: by 10.200.48.235 with SMTP id w40mr857165qta.72.1485922886098; Tue, 31 Jan 2017 20:21:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.66 with HTTP; Tue, 31 Jan 2017 20:21:25 -0800 (PST)
In-Reply-To: <7f7dc692-fe93-8ac1-ac25-10187e3f1a23@cisco.com>
References:    <449fb3a4-fbf5-bfa6-7530-fdfc7fe0488b@cisco.com>  <9999f224-c136-93cd-35c2-54c59e211a38@cisco.com> <2EBB38BD-FE11-44B5-8CA8-FB9AB03E7906@nic.cz> <7f7dc692-fe93-8ac1-ac25-10187e3f1a23@cisco.com>
From: Andy Bierman 
Date: Tue, 31 Jan 2017 20:21:25 -0800
Message-ID: 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11404a48ca4a1805477061b5
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] proposal to add 2 new guidelines in 6087bis
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, 01 Feb 2017 04:21:29 -0000

--001a11404a48ca4a1805477061b5
Content-Type: text/plain; charset=UTF-8

Hi,

I updated the rfc6087bis draft and did not either of these 2 guidelines.


Andy


On Tue, Jan 31, 2017 at 1:48 AM, Robert Wilton  wrote:

>
>
> On 30/01/2017 20:07, Ladislav Lhotka wrote:
>
>> On 30 Jan 2017, at 19:09, Robert Wilton  wrote:
>>>
>>>
>>>
>>> On 30/01/2017 17:52, Andy Bierman wrote:
>>>
>>>>
>>>> On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton 
>>>> wrote:
>>>> Hi Andy, Lada,
>>>>
>>>> On 28/01/2017 16:23, Andy Bierman wrote:
>>>>
>>>>>
>>>>> On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka 
>>>>> wrote:
>>>>>
>>>>> On 27 Jan 2017, at 20:23, Andy Bierman  wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The "pyang --ietf" validator checks the statement order used in
>>>>>> data-def-stmts.
>>>>>> There is no guideline that says this is required.
>>>>>> RFC 7950 says canonical order is RECOMMENDED.
>>>>>>
>>>>>> 1) data-def sub-statement order
>>>>>> Proposal: add new last sentence to sec. 4.6, para 3:
>>>>>>
>>>>>> YANG data definition sub-statements SHOULD be specified in canonical
>>>>>> order.
>>>>>>
>>>>> IMO, this adds nothing to what's already stated in 7950. According to
>>>>> RFC 2119, SHOULD and RECOMMENDED mean the same.
>>>>>
>>>>> I support Andy's recommendation here, although I think that it might
>>>> also be useful to cross reference back to where the canonical order is
>>>> actually defined in 7950.
>>>>
>>>> Lada, you are right that 7950 recommends the correct ordering, but I
>>>> think that it is buried with the ABNF, which won't necessarily be read by
>>>> all users of YANG.  Pulling it out in 6087bis doesn't seem to do any harm.
>>>>
>>>>
>>>>
>>>> Actually, the RFC 7950 text is not really correct.
>>>> The canonical order does not apply to the relative order of
>>>> container, list, leaf-list, leaf, choice, case, anyxml, or anydata.
>>>>
>>>> We list these nodes in the relative order we want in the data structure,
>>>> not all containers first, then all leafs, etc.  That is why my text says
>>>> 'data definition sub-statements'.
>>>>
>>> Is this worth adding as an errata to 7950 then?
>>>
>>> From:
>>>     data-def-stmt       = container-stmt /
>>>                           leaf-stmt /
>>>                           leaf-list-stmt /
>>>                           list-stmt /
>>>                           choice-stmt /
>>>                           anydata-stmt /
>>>                           anyxml-stmt /
>>>                           uses-stmt
>>>
>>> To:
>>>     data-def-stmt       = ;; these stmts can appear in any order
>>>                           container-stmt /
>>>                           leaf-stmt /
>>>                           leaf-list-stmt /
>>>                           list-stmt /
>>>                           choice-stmt /
>>>                           anydata-stmt /
>>>                           anyxml-stmt /
>>>                           uses-stmt
>>>
>>>
>>> Otherwise, if I am reading it correctly, it seems to imply that the top
>>> level data-defn stmts in a module/sub-module must be in the order above?
>>>
>> No, as it is a list of alternatives. Each time "data-def-stmt" is applied
>> you can choose any one of the alternatives.
>>
> Ah, yes.  So given that the grammar is 7950 is correct, then presumably it
> is reasonable to reference it from 6087bis.
>
> Rob
>
>

--001a11404a48ca4a1805477061b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I updated the rfc6087bis draft and =
did not either of these 2 guidelines.


Andy



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










On Tue, Jan 31, 2017 at 1:48 AM, Robert Wilton <rwilton=
@cisco.com> wrote:




On 30/01/2017 20:07, Ladislav Lhotka wrote:



On 30 Jan 2017, at 19:09, Robert Wilton <rwilton@cisco.com> wrote:







On 30/01/2017 17:52, Andy Bierman wrote:





On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy, Lada,



On 28/01/2017 16:23, Andy Bierman wrote:





On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:





On 27 Jan 2017, at 20:23, Andy Bierman <andy@yumaworks.com> wrote:



Hi,



The "pyang --ietf" validator checks the statement order used in d=
ata-def-stmts.

There is no guideline that says this is required.

RFC 7950 says canonical order is RECOMMENDED.



1) data-def sub-statement order

Proposal: add new last sentence to sec. 4.6, para 3:



YANG data definition sub-statements SHOULD be specified in canonical order.=




IMO, this adds nothing to what's already stated in 7950. According to R=
FC 2119, SHOULD and RECOMMENDED mean the same.





I support Andy's recommendation here, although I think that it might al=
so be useful to cross reference back to where the canonical order is actual=
ly defined in 7950.



Lada, you are right that 7950 recommends the correct ordering, but I think =
that it is buried with the ABNF, which won't necessarily be read by all=
 users of YANG.=C2=A0 Pulling it out in 6087bis doesn't seem to do any =
harm.







Actually, the RFC 7950 text is not really correct.

The canonical order does not apply to the relative order of

container, list, leaf-list, leaf, choice, case, anyxml, or anydata.



We list these nodes in the relative order we want in the data structure,
not all containers first, then all leafs, etc.=C2=A0 That is why my text sa=
ys

'data definition sub-statements'.



Is this worth adding as an errata to 7950 then?



From:

=C2=A0 =C2=A0 data-def-stmt=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D container-stmt /<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 leaf-stmt /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 leaf-list-stmt /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 list-stmt /

=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 choice-stmt /

=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 anydata-stmt /

=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 anyxml-stmt /

=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 uses-stmt



To:

=C2=A0 =C2=A0 data-def-stmt=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D ;; these stmts ca=
n appear in any order

=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 container-stmt /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 leaf-stmt /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 leaf-list-stmt /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 list-stmt /

=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 choice-stmt /

=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 anydata-stmt /

=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 anyxml-stmt /

=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 uses-stmt





Otherwise, if I am reading it correctly, it seems to imply that the top lev=
el data-defn stmts in a module/sub-module must be in the order above?



No, as it is a list of alternatives. Each time "data-def-stmt" is=
 applied you can choose any one of the alternatives.



Ah, yes.=C2=A0 So given that the grammar is 7950 is correct, then presumabl=
y it is reasonable to reference it from 6087bis.



Rob







--001a11404a48ca4a1805477061b5--