From david.partain@ericsson.com Tue Sep 1 00:59:49 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D53D28C1A2 for ; Tue, 1 Sep 2009 00:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOgKGG9tFKmP for ; Tue, 1 Sep 2009 00:59:48 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 61C2C3A6B32 for ; Tue, 1 Sep 2009 00:59:48 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-07-4a9cd47fc486 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id C0.9A.18827.F74DC9A4; Tue, 1 Sep 2009 09:59:59 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 09:59:59 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 09:59:59 +0200 From: David Partain Organization: Ericsson AB Date: Tue, 1 Sep 2009 09:59:58 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline To: NETMOD Working Group Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909010959.59070.david.partain@ericsson.com> X-OriginalArrivalTime: 01 Sep 2009 07:59:59.0597 (UTC) FILETIME=[33EE41D0:01CA2ADA] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 07:59:49 -0000 Hi, There has been significant debate about whether to reopen the question of having 'assigned-by system'. See this mail thread - http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html The discussion has been in the "agent-default -- new 3rd state" thread (and probably elsewhere). Martin wrote in the message referenced above: "The idea is that if a leaf is marked as assigned-by system, then the client MAY choose to not set a value for the leaf when its parent instance is created. In this case the system will assign a suitable value for the leaf." A number of people have said they think this should be reopened and that it would be valuable, particularly in dealing with misunderstandings around the meaning of default. Others have questioned doing so at this time. Clearly, if we think this is a serious enough problem that it MUST be fixed for good interoperability, then we should do so. I'd like to resolve this ASAP. Please voice your opinion by close of business tomorrow (Wednesday) about whether you in principle think we should add 'assigned-by system' (pending concrete text, of course). If the rough consensus appears to be to add it, I'll ask Martin to submit a proposal with text. We'll then discuss based on that text. Thanks. David From david.partain@ericsson.com Tue Sep 1 01:12:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA5D28C573 for ; Tue, 1 Sep 2009 01:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B0OaFayTg43 for ; Tue, 1 Sep 2009 01:12:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DD60428C328 for ; Tue, 1 Sep 2009 01:12:25 -0700 (PDT) X-AuditID: c1b4fb3c-b7bcbae000007452-d3-4a9cd559ae5a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 87.B3.29778.955DC9A4; Tue, 1 Sep 2009 10:03:37 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 10:03:13 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 10:03:12 +0200 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Tue, 1 Sep 2009 10:03:12 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909011003.12519.david.partain@ericsson.com> X-OriginalArrivalTime: 01 Sep 2009 08:03:12.0936 (UTC) FILETIME=[A72B7280:01CA2ADA] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Focus, focus, focus... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:12:27 -0000 Hi all, I'd like everyone involved in discussions here to try to remain focused on the text. If you see problems - please try to explain them succinctly so that everyone can "get it" - please use subject lines that reflect the problem you see - please remain focused on the text in the document you are discussing; include the text in question in your mail with suggested edits While I am going to try to pull out issues from the mail on the list, the volume guarantees that I will miss things. Doing the above will make it much much easier to drive consensus forward. Cheers, David From david.partain@ericsson.com Tue Sep 1 01:15:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8EC28C571 for ; Tue, 1 Sep 2009 01:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HOosbfdRxH6 for ; Tue, 1 Sep 2009 01:15:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 06A3528C52A for ; Tue, 1 Sep 2009 01:15:36 -0700 (PDT) X-AuditID: c1b4fb3c-b7bcbae000007452-bc-4a9cd6adf95f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B3.74.29778.DA6DC9A4; Tue, 1 Sep 2009 10:09:17 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 10:09:17 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 10:09:17 +0200 From: David Partain Organization: Ericsson AB Date: Tue, 1 Sep 2009 10:09:16 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline To: NETMOD Working Group Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909011009.16729.david.partain@ericsson.com> X-OriginalArrivalTime: 01 Sep 2009 08:09:17.0090 (UTC) FILETIME=[8038F020:01CA2ADB] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:15:38 -0000 Greetings, Another discussion that's been ... um... lively has been around the meaning of 'default'. Martin has written some text (a new section) that he has sent to the list, but it may have gotten lost in the middle of everything else. As such, here it is again: ------------------------------------------------------------------------------------------------------------------ 7.6.1. The leaf's default value The default value of a leaf is the value that the server uses if no value has been explicitly set. The usage of the default value depends on the type of the leaf's closest ancestor node in the schema tree which is not a non-presence container: o If no such ancestor exists in the schema tree, the default value MUST be used. o Otherwise, if this ancestor is a case node, the default value MUST be used if any node from the case exists in the data tree, or if the case node is the choice's default case, and no nodes from any other case exist in the data tree. o Otherwise, the default value MUST be used if the ancestor node exists in the data tree. In the cases where the default value MUST be used, the server MUST operationally behave as is if the leaf was present in the data tree with the default value as its value. If a leaf has a "default" statement, the leaf's default value is the value of the "default" statement. Otherwise, if the leaf's type has a default value, and the leaf is not mandatory, then the leaf's default value is the type's default value. In all other cases, the leaf does not have a default value. ------------------------------------------------------------------------------------------------------------------ If possible, I want to reach consensus on whether this text is what the WG wants this text or what changes we need to make to it. Please focus on this text... Cheers, David From mbj@tail-f.com Tue Sep 1 01:32:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065193A6F55 for ; Tue, 1 Sep 2009 01:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep3pt0z2c14V for ; Tue, 1 Sep 2009 01:32:22 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 15A4C3A6F4F for ; Tue, 1 Sep 2009 01:32:21 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 7880776C4A1; Tue, 1 Sep 2009 10:32:33 +0200 (CEST) Date: Tue, 01 Sep 2009 10:32:34 +0200 (CEST) Message-Id: <20090901.103234.72788342.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200909010959.59070.david.partain@ericsson.com> References: <200909010959.59070.david.partain@ericsson.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:32:23 -0000 Hi, David Partain wrote: > Clearly, if we think this is a serious enough problem that it MUST be fixed > for good interoperability, then we should do so. I'd like to resolve this > ASAP. Please voice your opinion by close of business tomorrow (Wednesday) > about whether you in principle think we should add 'assigned-by system' > (pending concrete text, of course). I have changed my mind. I think we should include this statement. The reason for this is that I believe that with this statement, the current confusion about when the server is allowed to create config instances can be sorted out. /martin From j.schoenwaelder@jacobs-university.de Tue Sep 1 02:37:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0317528C6B0 for ; Tue, 1 Sep 2009 02:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmkszp0gzVXk for ; Tue, 1 Sep 2009 02:37:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 33B0128C5D2 for ; Tue, 1 Sep 2009 02:36:39 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AA47C002A; Tue, 1 Sep 2009 11:36:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YqFg16gqqlSr; Tue, 1 Sep 2009 11:36:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88B0CC004A; Tue, 1 Sep 2009 11:36:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CCFAAC89FC0; Tue, 1 Sep 2009 11:36:47 +0200 (CEST) Date: Tue, 1 Sep 2009 11:36:47 +0200 From: Juergen Schoenwaelder To: David Partain Message-ID: <20090901093647.GB8876@elstar.local> Mail-Followup-To: David Partain , NETMOD Working Group References: <200909010959.59070.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909010959.59070.david.partain@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 09:37:31 -0000 On Tue, Sep 01, 2009 at 09:59:58AM +0200, David Partain wrote: > Hi, > > There has been significant debate about whether to reopen the question of > having 'assigned-by system'. See this mail thread - > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html > > The discussion has been in the "agent-default -- new 3rd state" thread (and > probably elsewhere). > > Martin wrote in the message referenced above: "The idea is that if a leaf is > marked as assigned-by system, then the client MAY choose to not set a value > for the leaf when its parent instance is created. In this case the system > will assign a suitable value for the leaf." > > A number of people have said they think this should be reopened and that it > would be valuable, particularly in dealing with misunderstandings around the > meaning of default. Others have questioned doing so at this time. > > Clearly, if we think this is a serious enough problem that it MUST be fixed > for good interoperability, then we should do so. I'd like to resolve this > ASAP. Please voice your opinion by close of business tomorrow (Wednesday) > about whether you in principle think we should add 'assigned-by system' > (pending concrete text, of course). > > If the rough consensus appears to be to add it, I'll ask Martin to submit a > proposal with text. We'll then discuss based on that text. I think a statement like assigned-by system help to achieve clarity and should be added. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.partain@ericsson.com Tue Sep 1 04:27:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67FC93A6F3A for ; Tue, 1 Sep 2009 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDLijlN6iE8k for ; Tue, 1 Sep 2009 04:27:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 040083A6B18 for ; Tue, 1 Sep 2009 04:27:07 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-f3-4a9d05181971 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 80.A3.01983.8150D9A4; Tue, 1 Sep 2009 13:27:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:27:19 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:27:19 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 1 Sep 2009 13:27:19 +0200 User-Agent: KMail/1.9.10 References: <4A9A2DA7.9020505@netconfcentral.com> <1251743687.12309.107.camel@missotis> <4A9C29F9.6060901@netconfcentral.com> In-Reply-To: <4A9C29F9.6060901@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909011327.19356.david.partain@ericsson.com> X-OriginalArrivalTime: 01 Sep 2009 11:27:19.0653 (UTC) FILETIME=[2AC82950:01CA2AF7] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] tconfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 11:27:09 -0000 Hi, I've just read through this thread. It's talked about "transient config" a= nd=20 is now morphing into a discussionabout deviations. =20 I haven't, though, seen any concrete suggestions about textual changes that= =20 people want. I'd like to close this thread, please, unless accompanied by= =20 suggestions for changes. Thanks. David On Monday 31 August 2009 21.52.25 Andy Bierman wrote: > Ladislav Lhotka wrote: > > Andy Bierman p=C3=AD=C5=A1e v Po 31. 08. 2009 v 09:45 -0700: > >>>> An alternative could be to work on a more generic solution, but I > >>>> think this requires protocol support ( or something= ), > >>>> and modelling support. But I don't think this is a must-have for YA= NG > >>>> 1.0. We don't even know what such a solution would look like, so if > >>>> anything, we could encourage people to work on the problem, using > >>>> NETCONF and YANG extensions. > >>> > >>> I agree, and from my point of view current YANG is OK as a > >>> domain-specific XML schema language - we can decide whether a given > >>> configuration is valid according to a data model, whether two > >>> configurations are equivalent given the set of declared defaults etc. > >> > >> I also agree, but only if the definition of a default is confined > >> to the YANG default-stmt value, for all YANG modules advertised > >> in the module capabilities. > > > > Absolutely, and with-defaults draft should include YANG-specific > > normative text. > > yes, but I am not sure how deviations work with this definition > of a default. > > I think there are only 2 implementations that include deviation-stmt > at this time, and we both implemented deviations as a patch. > Once the run-time schema tree is patched, does this count as the > new contract, including defaults? > > That's what I was afraid of when I objected to deviations > so strongly in the first place. > > standard says: > > leaf foo { > type string; > } > > If the deviations add/replace/delete a default, does > that count as the new default, or does that count as > a server-created instance with a non-default value? > The deviations were not supposed to allow the contract > to be altered, just identify the ways the server > is non-compliant. > > The schema language is the component that adds > semantics to the standard syntax. We are making a big > departure from SNMP robustness principles by requiring > a client to have a complete and accurate set of schema > definitions and deviations, just to obtain a complete set of > operational data values from a particular server. > > A human or a dumb 'MIB walker' could make use of the complete > output, especially in XML, because the object hierarchy is > clearly identified and (except for binary) the built-in content > is all readable. This definition of 'all' includes YANG defaults. > > I am also concerned that vendors will not advertise the > critical deviation modules for standard modules, because > that (by definition) means the vendor does not comply with > the standard. The deviations for the vendor's own YANG modules > will be quite rare in comparison, since they have total > ownership of that content. > > I am also concerned about the fact that revision statements > are purely optional to use (outside of standard modules). > Then, if the vendor changes a default over time, the client > has no clue which leaf-stmt to pick to decide if > a missing leaf has a default, and its true value. > > (Still want to stake your job on those default-stmt values. operators?) > > > Lada > > Andy > > >> As long as every leaf instance is retrievable by the client somehow, > >> then the current draft is fine. I can accept that the configuration > >> is just the leaf instances that do not have the YANG default-stmt > >> value. If the current value of every leaf instance is retrievable > >> on every NETCONF server, then it is OK if the description statements > >> are needed to correlate the leaf instances. > >> > >> Asking the server to deduce the value of any current leaf instance > >> value is the only non-starter still floating around at this time. > >> > >>> Lada > >>> > >>>> /martin > >> > >> Andy From david.partain@ericsson.com Tue Sep 1 04:36:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750A83A6880 for ; Tue, 1 Sep 2009 04:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.633 X-Spam-Level: X-Spam-Status: No, score=-5.633 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNYjG2lhFGbE for ; Tue, 1 Sep 2009 04:36:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 85DB63A6B59 for ; Tue, 1 Sep 2009 04:36:37 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-94-4a9d0733b1ea Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1E.64.01983.3370D9A4; Tue, 1 Sep 2009 13:36:19 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:36:11 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:36:11 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 1 Sep 2009 13:36:10 +0200 User-Agent: KMail/1.9.10 References: <200908241333.n7ODX6KL091523@idle.juniper.net> <200908311126.16613.david.partain@ericsson.com> In-Reply-To: <200908311126.16613.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909011336.10195.david.partain@ericsson.com> X-OriginalArrivalTime: 01 Sep 2009 11:36:11.0306 (UTC) FILETIME=[67ABF8A0:01CA2AF8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 11:36:38 -0000 On Monday 31 August 2009 11.26.16 David Partain wrote: > On Monday 24 August 2009 15.33.06 Phil Shafer wrote: > > Juergen Schoenwaelder writes: > > >we need to put this > > >discussion somehow to an end. > > > > +1 > > I completely agree. I'm trying to read through huge heaps of email to try > to figure out what the right question to ask is. Stay tuned. Hi folks, I'd like this thread closed, too. The focus of this discussion should now be on the mail with the subject "Issue: interpretation of 'default'" (http://www.ietf.org/mail-archive/web/netmod/current/msg03821.html). Cheers, David From andy@netconfcentral.com Tue Sep 1 04:51:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD473A6E6F for ; Tue, 1 Sep 2009 04:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ2-z--82pxW for ; Tue, 1 Sep 2009 04:51:27 -0700 (PDT) Received: from n12b.bullet.mail.mud.yahoo.com (n12b.bullet.mail.mud.yahoo.com [209.191.125.179]) by core3.amsl.com (Postfix) with SMTP id 829CB3A6B59 for ; Tue, 1 Sep 2009 04:51:27 -0700 (PDT) Received: from [68.142.194.243] by n12.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 11:51:38 -0000 Received: from [68.142.201.247] by t1.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 11:51:38 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 11:51:38 -0000 X-Yahoo-Newman-Id: 906089.68511.bm@omp408.mail.mud.yahoo.com Received: (qmail 29111 invoked from network); 1 Sep 2009 11:51:38 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 11:51:38 -0000 X-YMail-OSG: uy3L4.AVM1nGn.Yt3mcvy7ejaqxZ6Jyd_xGHynyc5JfWPI3yPa8hRwPPM0NVzbUQNZFa9lXfUsBJ4iXoDiTrT5jsvwqZqj8B4PWlpkZqpnlsII5MPOjb6E9wjKgqe78S_Qx2VI8zvHz2SjIjzhvnDtOJCuubojOsgXjRKrQ1APT_t85VFkNuy6FcXfGCt_aGD2pRmoIxCRmGQax5T.Itvz5DMhJz_pYQiAfbofv6PK.QanA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D0AD9.7020907@netconfcentral.com> Date: Tue, 01 Sep 2009 04:51:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <200909010959.59070.david.partain@ericsson.com> In-Reply-To: <200909010959.59070.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 11:51:28 -0000 David Partain wrote: > Hi, > > There has been significant debate about whether to reopen the question of > having 'assigned-by system'. See this mail thread - > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html > > The discussion has been in the "agent-default -- new 3rd state" thread (and > probably elsewhere). > > Martin wrote in the message referenced above: "The idea is that if a leaf is > marked as assigned-by system, then the client MAY choose to not set a value > for the leaf when its parent instance is created. In this case the system > will assign a suitable value for the leaf." > > A number of people have said they think this should be reopened and that it > would be valuable, particularly in dealing with misunderstandings around the > meaning of default. Others have questioned doing so at this time. > > Clearly, if we think this is a serious enough problem that it MUST be fixed > for good interoperability, then we should do so. I'd like to resolve this > ASAP. Please voice your opinion by close of business tomorrow (Wednesday) > about whether you in principle think we should add 'assigned-by system' > (pending concrete text, of course). > > If the rough consensus appears to be to add it, I'll ask Martin to submit a > proposal with text. We'll then discuss based on that text. > I have not yet seen a complete and convincing problem statement, let alone a complete and convincing solution proposal. I expect the NETCONF protocol to be deterministic for all protocol operations on a particular YANG data model. Any solution in which the descriptive annotations in YANG are used as a substitute for retrieval of definitive values (using protocol operations) is unacceptable. Not sure what assigned-by system really does for the data modeler. Can somebody explain that to me again? What MUST behavior is associated with usage of assigned-by system? What about the other enum (whatever it is called)? > Thanks. > > David > Andy From mbj@tail-f.com Tue Sep 1 05:40:51 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBC628CA08 for ; Tue, 1 Sep 2009 05:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl1CpOXrH6CJ for ; Tue, 1 Sep 2009 05:40:50 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1A95228CCEF for ; Tue, 1 Sep 2009 05:25:35 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 94C1476C4A1; Tue, 1 Sep 2009 14:25:47 +0200 (CEST) Date: Tue, 01 Sep 2009 14:25:47 +0200 (CEST) Message-Id: <20090901.142547.110033514.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A9D0AD9.7020907@netconfcentral.com> References: <200909010959.59070.david.partain@ericsson.com> <4A9D0AD9.7020907@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 12:40:51 -0000 Andy Bierman wrote: > I have not yet seen a complete and convincing problem statement, > let alone a complete and convincing solution proposal. I think there are two benefits: 1) it will be clear when the client can expect the server to create instances, (see the recent discussion about mandatory) 2) it gives the data modeler another formal tool so that his data model can be more precise (there are a couple of examples in the ipfix module where this could be used; the user's "uid" is the other example) > Not sure what assigned-by system really does for the data modeler. > Can somebody explain that to me again? What MUST behavior is > associated with usage of assigned-by system? What about > the other enum (whatever it is called)? If the WG believes that something like this is useful, then I will write down one proposal which we then can discuss. I welcome anyone who wants to help with this text to let me know! /martin From jmh@joelhalpern.com Tue Sep 1 06:20:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B68F3A68E6 for ; Tue, 1 Sep 2009 06:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRpdxmLXaqDg for ; Tue, 1 Sep 2009 06:20:36 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F020228C6EA for ; Tue, 1 Sep 2009 06:19:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 026EE43037E; Tue, 1 Sep 2009 06:19:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 92D9743037D; Tue, 1 Sep 2009 06:19:57 -0700 (PDT) Message-ID: <4A9D1F7C.4030605@joelhalpern.com> Date: Tue, 01 Sep 2009 09:19:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Partain References: <200909010959.59070.david.partain@ericsson.com> In-Reply-To: <200909010959.59070.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:20:37 -0000 I consider this one of several possible paths to an acceptable solution. I think it is helpful information to the management system to know whether the managed device may choose to unilaterally set the value. For this to solve the related issues about what is a default and when are such values returned, we need to be explicit both that a) such value setting is not a default b) that system shall not behave as if there is a well-defined value for the item without reporting it. We will also need to make sure that the text is clear as to what would happen in the equivalent of the default-by-reference case. So, I think this is a useful change, and can be part of a larger solution to the ongoing debate. As a minor matter, I would not call it "assign-by system". That tends to make the reader thing that the managing client can not assign to it, when they can (it is config data.) Some other terminology would be a good idea. Yours, Joel David Partain wrote: > Hi, > > There has been significant debate about whether to reopen the question of > having 'assigned-by system'. See this mail thread - > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html > > The discussion has been in the "agent-default -- new 3rd state" thread (and > probably elsewhere). > > Martin wrote in the message referenced above: "The idea is that if a leaf is > marked as assigned-by system, then the client MAY choose to not set a value > for the leaf when its parent instance is created. In this case the system > will assign a suitable value for the leaf." > > A number of people have said they think this should be reopened and that it > would be valuable, particularly in dealing with misunderstandings around the > meaning of default. Others have questioned doing so at this time. > > Clearly, if we think this is a serious enough problem that it MUST be fixed > for good interoperability, then we should do so. I'd like to resolve this > ASAP. Please voice your opinion by close of business tomorrow (Wednesday) > about whether you in principle think we should add 'assigned-by system' > (pending concrete text, of course). > > If the rough consensus appears to be to add it, I'll ask Martin to submit a > proposal with text. We'll then discuss based on that text. > > Thanks. > > David > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Tue Sep 1 06:29:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9093A6820 for ; Tue, 1 Sep 2009 06:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B+7RUZW1zVR for ; Tue, 1 Sep 2009 06:29:47 -0700 (PDT) Received: from n9a.bullet.mail.mud.yahoo.com (n9a.bullet.mail.mud.yahoo.com [209.191.87.108]) by core3.amsl.com (Postfix) with SMTP id 2B54C3A68AD for ; Tue, 1 Sep 2009 06:29:45 -0700 (PDT) Received: from [209.191.108.96] by n9.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 13:29:57 -0000 Received: from [68.142.201.245] by t3.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 13:29:57 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 13:29:57 -0000 X-Yahoo-Newman-Id: 396800.16007.bm@omp406.mail.mud.yahoo.com Received: (qmail 53801 invoked from network); 1 Sep 2009 13:29:57 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 13:29:56 -0000 X-YMail-OSG: xGqn0dkVM1nhwQjbRhYZrYE.NCjA5eB_qcrK3wX3O5rdArEb5jc8fcHB3CX_rBoRHfcs49aWiWhv9xTBucMn7Kjt2mWEGmt9G1mWaGeNQZhveBdjZu2_mYwgJSBXEFbuRNMyrbW7Q.G5FJgLkHQUIbTaT1lg1SfLP5MEWeDPhet9wEvSG_mihUtdzMhkH0pB0Nzabk6CIazezCgIcfEO8LhR4DtHfz_ly.NahEPnpCgA_hqu6Krd5j6YzHcLVjygnLTrMJxQCLQT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D21E4.9020100@netconfcentral.com> Date: Tue, 01 Sep 2009 06:30:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200909010959.59070.david.partain@ericsson.com> <4A9D0AD9.7020907@netconfcentral.com> <20090901.142547.110033514.mbj@tail-f.com> In-Reply-To: <20090901.142547.110033514.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:29:48 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I have not yet seen a complete and convincing problem statement, >> let alone a complete and convincing solution proposal. > > I think there are two benefits: > > 1) it will be clear when the client can expect the server to create > instances, (see the recent discussion about mandatory) > so there will be normative text saying a server MUST NOT create an instance if it is an 'assigned-by user' type of leaf? this would be useful to have. The assigned-by statement has no affect on retrieval operations whatsoever, correct? that is also important. A server-created leaf instance must be just a plain old leaf instance, and not special in any way. > 2) it gives the data modeler another formal tool so that his data > model can be more precise (there are a couple of examples in the > ipfix module where this could be used; the user's "uid" is the > other example) > >> Not sure what assigned-by system really does for the data modeler. >> Can somebody explain that to me again? What MUST behavior is >> associated with usage of assigned-by system? What about >> the other enum (whatever it is called)? > > If the WG believes that something like this is useful, then I will > write down one proposal which we then can discuss. I welcome anyone > who wants to help with this text to let me know! > > > /martin > > Andy From jmh@joelhalpern.com Tue Sep 1 06:31:10 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265373A685B for ; Tue, 1 Sep 2009 06:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY8OYAhr6nUa for ; Tue, 1 Sep 2009 06:31:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 81C5F3A697D for ; Tue, 1 Sep 2009 06:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3CD8143037E; Tue, 1 Sep 2009 06:31:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A83F2430379; Tue, 1 Sep 2009 06:31:20 -0700 (PDT) Message-ID: <4A9D2227.4060407@joelhalpern.com> Date: Tue, 01 Sep 2009 09:31:19 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Partain References: <200909011009.16729.david.partain@ericsson.com> In-Reply-To: <200909011009.16729.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:31:10 -0000 Unfortunately, while I like this case, it does not, as far as I can tell, solve the problem at hand. A number of folks have argued that either a) the managed device is free to set the node to some other value, even if it has a default definition, and to still treat that as a default valued node b) the managed device is free to set nodes without default to some value, and not report that value in response to get requests of any kind. Both of those are not directly addressed by the text, but are clearly within the topic of the text. We need to resolve those behaviors somehow. Personally, I find the reading that (a) is allowed to be a distortion of the plain meaning of the existing text, but at least one person has argued vocally that it is not only allowed but desirable. I do want to try to write text to address these. I am happy to assume the text below from Martin as a starting point, and to determine whether the additional text goes in 7.6 or 7.6.1. As a minor clarification, there apparently has been some confusion about the managed device treating leaf-lists as if they have values, and whether those need to be reported. Yours, Joel David Partain wrote: > Greetings, > > Another discussion that's been ... um... lively has been around the meaning > of 'default'. Martin has written some text (a new section) that he has sent > to the list, but it may have gotten lost in the middle of everything else. > As such, here it is again: > > ------------------------------------------------------------------------------------------------------------------ > 7.6.1. The leaf's default value > > The default value of a leaf is the value that the server uses if no > value has been explicitly set. The usage of the default value > depends on the type of the leaf's closest ancestor node in the schema > tree which is not a non-presence container: > > o If no such ancestor exists in the schema tree, the default value > MUST be used. > > o Otherwise, if this ancestor is a case node, the default value MUST > be used if any node from the case exists in the data tree, or if > the case node is the choice's default case, and no nodes from any > other case exist in the data tree. > > o Otherwise, the default value MUST be used if the ancestor node > exists in the data tree. > > In the cases where the default value MUST be used, the server MUST > operationally behave as is if the leaf was present in the data tree > with the default value as its value. > > If a leaf has a "default" statement, the leaf's default value is the > value of the "default" statement. Otherwise, if the leaf's type has > a default value, and the leaf is not mandatory, then the leaf's > default value is the type's default value. In all other cases, the > leaf does not have a default value. > ------------------------------------------------------------------------------------------------------------------ > > If possible, I want to reach consensus on whether this text is what the WG > wants this text or what changes we need to make to it. Please focus on this > text... > > Cheers, > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Tue Sep 1 06:38:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEEA73A6B14 for ; Tue, 1 Sep 2009 06:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-nGvJDfc-fV for ; Tue, 1 Sep 2009 06:38:45 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 326A23A69E3 for ; Tue, 1 Sep 2009 06:38:45 -0700 (PDT) Received: (qmail 32374 invoked from network); 1 Sep 2009 13:38:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 13:38:56 -0000 X-YMail-OSG: dYL9YOIVM1lhtcv_.697GDOAFHcp7x0PwMKAK_ORFPtxkgb5_EbviSAmCmsO.7XjWdl1Ok6ik_.rnHI.NkSLHQBPtjokS_ENDaDuBNTPS3LcK.j9hE7t.qUoHgHnxvUgeqvhqHLYo4p.kdbpO34J6xY.nGjj3xFfwvwfLcCKseHeyPN6xQMGc_19X3sITDRVHmDlLVTkay9mYfY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D2400.5020000@netconfcentral.com> Date: Tue, 01 Sep 2009 06:39:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200909010959.59070.david.partain@ericsson.com> <4A9D1F7C.4030605@joelhalpern.com> In-Reply-To: <4A9D1F7C.4030605@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:38:45 -0000 Joel M. Halpern wrote: > I consider this one of several possible paths to an acceptable solution. > I think it is helpful information to the management system to know > whether the managed device may choose to unilaterally set the value. > > For this to solve the related issues about what is a default and when > are such values returned, we need to be explicit both that > a) such value setting is not a default > b) that system shall not behave as if there is a well-defined value for > the item without reporting it. > > We will also need to make sure that the text is clear as to what would > happen in the equivalent of the default-by-reference case. > I think the WG is going in the wrong direction by trying to create more ways to replace simple data retrieval with algorithmic synthesis of that data. I will never trust server vendors to put nearly as much effort into their documentation as they put into their code. I know what goes on in the kitchen... > So, I think this is a useful change, and can be part of a larger > solution to the ongoing debate. > > As a minor matter, I would not call it "assign-by system". That tends > to make the reader thing that the managing client can not assign to it, > when they can (it is config data.) > Some other terminology would be a good idea. > > Yours, > Joel > Andy From mbj@tail-f.com Tue Sep 1 06:51:16 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0EDF3A6F87 for ; Tue, 1 Sep 2009 06:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVnhsRVoiYwD for ; Tue, 1 Sep 2009 06:51:16 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E316C3A6F4E for ; Tue, 1 Sep 2009 06:51:15 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 44E6C76C4A1; Tue, 1 Sep 2009 15:51:28 +0200 (CEST) Date: Tue, 01 Sep 2009 15:51:27 +0200 (CEST) Message-Id: <20090901.155127.188489339.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A9D2227.4060407@joelhalpern.com> References: <200909011009.16729.david.partain@ericsson.com> <4A9D2227.4060407@joelhalpern.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:51:16 -0000 "Joel M. Halpern" wrote: > Unfortunately, while I like this case, it does not, as far as I can tell, solve > the problem at hand. > > A number of folks have argued that either > a) the managed device is free to set the node to some other value, even if it > has a default definition, and to still treat that as a default valued node When you say "set the node" do you mean actually create the instance? If so, the assigned-by system statement supposedly covers this - if the node is assigned-by user, the server MUST NOT create it. Or do you mean "operationally use"? If so, you are saying that it would be ok to simply ignore the default statement and use any other value. My text does not allow this. It says that the value from the default statement MUST be used. > b) the managed device is free to set nodes without default to some value, and > not report that value in response to get requests of any kind. Here I assume you mean "operationally use". I think the proposed text is clear when it says: "In all other cases, the leaf does not have a default value." So from a YANG perspective, this would not be a default value. > Both of those are not directly addressed by the text, but are clearly within > the topic of the text. We need to resolve those behaviors somehow. > Personally, I find the reading that (a) is allowed to be a distortion of the > plain meaning of the existing text, but at least one person has argued vocally > that it is not only allowed but desirable. > > I do want to try to write text to address these. > I am happy to assume the text below from Martin as a starting point, and to > determine whether the additional text goes in 7.6 or 7.6.1. This would be very welcome! /martin From mbj@tail-f.com Tue Sep 1 06:59:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A8F3A6861 for ; Tue, 1 Sep 2009 06:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0ReRn7LNh0u for ; Tue, 1 Sep 2009 06:59:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B9903A6A34 for ; Tue, 1 Sep 2009 06:57:02 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E27D76C4E1; Tue, 1 Sep 2009 15:57:15 +0200 (CEST) Date: Tue, 01 Sep 2009 15:57:14 +0200 (CEST) Message-Id: <20090901.155714.58576538.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A9D21E4.9020100@netconfcentral.com> References: <4A9D0AD9.7020907@netconfcentral.com> <20090901.142547.110033514.mbj@tail-f.com> <4A9D21E4.9020100@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:59:27 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I have not yet seen a complete and convincing problem statement, > >> let alone a complete and convincing solution proposal. > > > > I think there are two benefits: > > > > 1) it will be clear when the client can expect the server to create > > instances, (see the recent discussion about mandatory) > > > > so there will be normative text saying > a server MUST NOT create an instance > if it is an 'assigned-by user' type of leaf? Yes, that is the idea. Where "create" means "create when the parent node is created" (sort of). I.e. it would still be ok for a device to start with a preloaded data store, or an "initial config". One way of viewing this is that the server is free to create such leafs even though the client has the lock on the data store. > The assigned-by statement has no affect on retrieval > operations whatsoever, correct? that is also > important. A server-created leaf instance must be > just a plain old leaf instance, and not special > in any way. Yes, that is my view as well. /martin From andy@netconfcentral.com Tue Sep 1 07:06:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6F13A6FC8 for ; Tue, 1 Sep 2009 07:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n18xFYGiH08 for ; Tue, 1 Sep 2009 07:06:07 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 26C4E3A6FA7 for ; Tue, 1 Sep 2009 07:06:07 -0700 (PDT) Received: (qmail 72861 invoked from network); 1 Sep 2009 14:06:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 14:06:18 -0000 X-YMail-OSG: LEK0Ez0VM1naQGkfTvkW1vN.DNj2jxbN.SGMUjz7k_DHZvxifAhwH7dmHydX0qX2lB0V5mkmlVnfV8T84ncKdrP6504ucwVerba0Kl_NH7HM.wLsfhqSQbrPpitgcHIXGfongVOR0OWrjZ87yYmjqe2qYoLc4gUfRDHaFhHu6Jc0UruX_1fKlJsWhRyU8IwrEbidWgqverCDiXMdDlKxWaVFdLFVXhHRf_S5LjURr4thhAK_Ex3pujc3OSyv.Tv8hW50jzAPUwBIJPXTmBhmW2HgM.8UfpErIeWkaLu5R9MzIuH3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D29F1.6010806@netconfcentral.com> Date: Tue, 01 Sep 2009 07:04:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <200908241333.n7ODX6KL091523@idle.juniper.net> <200908311126.16613.david.partain@ericsson.com> <200909011336.10195.david.partain@ericsson.com> In-Reply-To: <200909011336.10195.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 14:06:08 -0000 David Partain wrote: > On Monday 31 August 2009 11.26.16 David Partain wrote: >> On Monday 24 August 2009 15.33.06 Phil Shafer wrote: >>> Juergen Schoenwaelder writes: >>>> we need to put this >>>> discussion somehow to an end. >>> +1 >> I completely agree. I'm trying to read through huge heaps of email to try >> to figure out what the right question to ask is. Stay tuned. > > Hi folks, > > I'd like this thread closed, too. The focus of this discussion should now be > on the mail with the subject "Issue: interpretation of 'default'" > (http://www.ietf.org/mail-archive/web/netmod/current/msg03821.html). > I wish this was a linear process as well but engineering doesn't work that way. Sometimes it takes a few tries before you really understand why a design is broken. How does this YANG-default as a substitute for data retrieval works when there are deviation-stmts that change the default, or a YANG module with no revision-stmts adds a default over time? IMO, it doesn't. The entire premise that YANG default-stmts are equivalent to runtime data is incorrect. Note that section 10 clearly states that a default may be added after initial publication, but that is all. Once a leaf is published with a YANG default-stmt, it MUST never be changed or removed. This makes it even more unlikely that one will be able to trust the default-stmt value across all versions of all platforms, because this CLR will be ignored. So I prefer 'report-all', and don't care about the server wasting bandwidth while doing its job. > Cheers, > > David Andy From Washam.Fan@huaweisymantec.com Tue Sep 1 07:08:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EF228C291 for ; Tue, 1 Sep 2009 07:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i7FFiPOvO1z for ; Tue, 1 Sep 2009 07:08:10 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 2BF4B28C24C for ; Tue, 1 Sep 2009 07:08:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KPA002QKPXD5IA0@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Tue, 01 Sep 2009 22:08:01 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KPA00B7LPXDL220@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Tue, 01 Sep 2009 22:08:01 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 01 Sep 2009 22:08:01 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Tue, 01 Sep 2009 22:08:01 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090901.155127.188489339.mbj@tail-f.com> References: <200909011009.16729.david.partain@ericsson.com> <4A9D2227.4060407@joelhalpern.com> <20090901.155127.188489339.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 14:08:11 -0000 Hi, > > b) the managed device is free to set nodes without default to some > value, and > > not report that value in response to get requests of any kind. IMO, in this case, the value assigned by the server should be reported, since the client has no clue to deduce it. And to my knowledge, the server might not be free to set any nodes without default but those mandatory ones for the valid config. washam > Here I assume you mean "operationally use". I think the proposed text > is clear when it says: "In all other cases, the leaf does not have a > default value." So from a YANG perspective, this would not be a > default value. From andy@netconfcentral.com Tue Sep 1 08:44:39 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677C23A68F3 for ; Tue, 1 Sep 2009 08:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqP7DWdULdE9 for ; Tue, 1 Sep 2009 08:44:38 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 3A02628C78F for ; Tue, 1 Sep 2009 08:42:45 -0700 (PDT) Received: (qmail 18734 invoked from network); 1 Sep 2009 15:42:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 15:42:55 -0000 X-YMail-OSG: AS6lHFgVM1mGXWFP_OreBiMvq4wuUhUtPL8Pr1HrQo3YOmojBYrQqTEot0z7MAFRtrb5h46nD7bz7ei_hMDbT.nROyc2mh4fM5Ywx444yT5rBO1kdX0uI0UqwgkspHLIHJr1hPidluJo.ZciaeIY.CyrG5ZhzDIKc_BTx0u.zi4dKk1Dcpy0uwPpfW1KVW.gh50sZ0M3PfVtqRVs1Ec1sIO4GVf2BW8Whl3mcTa.6SPMN8HXuuoOPpimJMr.lejb.rvS1Omwn1hfiDkUAJecu6VNK3obGo_vG0VLHYtF3dmhwXIEzZkZVZ2Y3Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D410F.8020109@netconfcentral.com> Date: Tue, 01 Sep 2009 08:43:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] module capabilities section X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:44:39 -0000 Hi, I think sec. 5.6.4 should be more clear about the conformance for the module capability content. This is a critical component of the many complex features, and it MUST be complete and correct for NETCONF/YANG to have any real chance at interoperability. Sec 5.6.4.1: All revisions of all modules that are used within the server MUST be announced in the because import-by-revision and include-by-revision are optional to use, and therefore ambiguous. Even all 'typedef' modules like ietf-yang-types are not safe to use without a revision date. Assuming the client will guess the right file for 'import footypes' is broken. Without a namespace, there is no way to verify that the client and server both picked the same 'footypes'. The current text says: Modules that do not contribute any data definitions, rpcs, notifications, or deviations to the device MAY be advertised in the message. This is incomplete and non-deterministic data. Maybe humans don't care about that, but it is a big deal to automation-based applications. (Some humans have noticed that incomplete and non-deterministic data wastes time.) Sec 5.6.4.2: It should be clear that the server MUST announce all features it supports for a given module, if any. Sec 5.6.4.3: It should be clear that the server MUST announce all deviations it has loaded for a given module, if any. The deviation module MUST be advertised as a capability. It cannot just be identified as deviations=foo'. It should be obvious that these modules are subject to the same module name collisions as any other module. Not so obvious -- the server MUST support every mandatory-to-implement YANG construct in a deviations module, since it is just like any other. string-for-uri-nobody-can-remember:module=X&revision=2009-02-01&deviations=Y string-for-uri-nobody-can-remember:module=Y&revision=2009-02-01 ------------------------------ General: Using a complete and deterministic data-set is fundamental to automation of manual IT labor. If others want to use NETCONF as a human interface that's fine, but that should not be the limit of NETCONF's utility. Many classes of applications are not just simple front-ends for a human to read and type, and incomplete data is a killer for all those apps. IMO, the amount of bandwidth being saved is a million times cheaper than the labor hours for looking up all the missing data, or over-paying experts to know all the esoteric details without looking them up. Andy From andy@netconfcentral.com Tue Sep 1 09:04:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B5028C836 for ; Tue, 1 Sep 2009 09:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L04vWdsIllTO for ; Tue, 1 Sep 2009 09:04:10 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 3ABB028C87F for ; Tue, 1 Sep 2009 09:03:01 -0700 (PDT) Received: (qmail 71805 invoked from network); 1 Sep 2009 16:03:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 16:03:12 -0000 X-YMail-OSG: veSTnOUVM1lBP_LL5ms_tlJY0FqdfP38JwdXFKL9khgSiIOyO_GRqr2hpPh3kzjNbwJqGGObBZtPWPyYWNQIIJQxWmOMqkWV1.IutWNMXDG7u2N3W30Wi_Oo1MzmWVu41Gaa169UfiJcxMasFAHMV_ZrSPar1qYT4FXWGekYHFcBn2dHAGE5fgFJFZopMljTMuNFFRYUO.jLC.KkxWWWC7aV2GsrDd2zeh2WWQQ02H7JJuH6XX8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D45D0.4060905@netconfcentral.com> Date: Tue, 01 Sep 2009 09:03:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] database + defaults = broken X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 16:04:11 -0000 Hi, There are several places in the draft where special definitions of the database are given for XPath: o The accessible tree is made up of all nodes in the data tree, and all leafs with default values. ------------------------- module X { namespace "http://example.com/ns/X"; prefix X; leaf x { type int32; } } 1 year later ... module X { namespace "http://example.com/ns/X"; prefix X; leaf x { type int32; default 10; } } ------------------------- This is legal YANG. Revisions are optional, and a default can be added over time. The client needs to manage old servers and new servers. Client retrieves /x: The server responds with no data: So -- is the client talking to an old server that just doesn't have this leaf, or a new server that is using the YANG default? It could be either, and that is broken. Andy From lhotka@cesnet.cz Tue Sep 1 09:05:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E30028C82F for ; Tue, 1 Sep 2009 09:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc7V7szTZEkE for ; Tue, 1 Sep 2009 09:05:22 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3C44528C819 for ; Tue, 1 Sep 2009 09:05:22 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 247F0D800E8; Tue, 1 Sep 2009 18:05:35 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4A9D2227.4060407@joelhalpern.com> References: <200909011009.16729.david.partain@ericsson.com> <4A9D2227.4060407@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 01 Sep 2009 18:05:33 +0200 Message-Id: <1251821133.4542.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 16:05:23 -0000 Joel M. Halpern píše v Út 01. 09. 2009 v 09:31 -0400: > Unfortunately, while I like this case, it does not, as far as I can > tell, solve the problem at hand. > > A number of folks have argued that either > a) the managed device is free to set the node to some other value, even > if it has a default definition, and to still treat that as a default > valued node > b) the managed device is free to set nodes without default to some > value, and not report that value in response to get requests of any kind. The text now specifies that under certain conditions the configuration without the leaf is equivalent to one in which the leaf is present and set to the default value. However, formulations like "server MUST use the default" value may be understood as if the server is not allowed to assign a value unilaterally. So it might be actually better to talk about equivalence of configurations, also because it can be easily applied to datastores other than running. Lada > > Both of those are not directly addressed by the text, but are clearly > within the topic of the text. We need to resolve those behaviors somehow. > Personally, I find the reading that (a) is allowed to be a distortion of > the plain meaning of the existing text, but at least one person has > argued vocally that it is not only allowed but desirable. > > I do want to try to write text to address these. > I am happy to assume the text below from Martin as a starting point, and > to determine whether the additional text goes in 7.6 or 7.6.1. > > As a minor clarification, there apparently has been some confusion about > the managed device treating leaf-lists as if they have values, and > whether those need to be reported. > > Yours, > Joel > > David Partain wrote: > > Greetings, > > > > Another discussion that's been ... um... lively has been around the meaning > > of 'default'. Martin has written some text (a new section) that he has sent > > to the list, but it may have gotten lost in the middle of everything else. > > As such, here it is again: > > > > ------------------------------------------------------------------------------------------------------------------ > > 7.6.1. The leaf's default value > > > > The default value of a leaf is the value that the server uses if no > > value has been explicitly set. The usage of the default value > > depends on the type of the leaf's closest ancestor node in the schema > > tree which is not a non-presence container: > > > > o If no such ancestor exists in the schema tree, the default value > > MUST be used. > > > > o Otherwise, if this ancestor is a case node, the default value MUST > > be used if any node from the case exists in the data tree, or if > > the case node is the choice's default case, and no nodes from any > > other case exist in the data tree. > > > > o Otherwise, the default value MUST be used if the ancestor node > > exists in the data tree. > > > > In the cases where the default value MUST be used, the server MUST > > operationally behave as is if the leaf was present in the data tree > > with the default value as its value. > > > > If a leaf has a "default" statement, the leaf's default value is the > > value of the "default" statement. Otherwise, if the leaf's type has > > a default value, and the leaf is not mandatory, then the leaf's > > default value is the type's default value. In all other cases, the > > leaf does not have a default value. > > ------------------------------------------------------------------------------------------------------------------ > > > > If possible, I want to reach consensus on whether this text is what the WG > > wants this text or what changes we need to make to it. Please focus on this > > text... > > > > Cheers, > > > > David > > _______________________________________________ > > 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, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Sep 1 10:19:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B41D28C8BC for ; Tue, 1 Sep 2009 10:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.189 X-Spam-Level: X-Spam-Status: No, score=-1.189 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObFYV+bYKNen for ; Tue, 1 Sep 2009 10:19:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8978C28C8B7 for ; Tue, 1 Sep 2009 10:19:33 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D22C4D80095 for ; Tue, 1 Sep 2009 19:19:44 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4A9D49D5.6060806@joelhalpern.com> References: <200909011009.16729.david.partain@ericsson.com> <4A9D2227.4060407@joelhalpern.com> <1251821133.4542.13.camel@missotis> <4A9D49D5.6060806@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 01 Sep 2009 19:19:43 +0200 Message-Id: <1251825583.4542.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:19:34 -0000 Joel M. Halpern píše v Út 01. 09. 2009 v 12:20 -0400: > Sorry, I have no idea what you are getting at / asking for. > (I can provide two possible interpretations, one of which would be fine > and one of which I would completely disagree with. And what you meant > is probably neither one.) > Would you please clarify to the list? My point simply is that the "server MUST use" language misled me into thinking that the 'default' statement prevents the device from doing a), which is not the case, so I am suggesting another formulation expressed solely in terms of datastore content. Lada > > Thank you, > Joel > > > Ladislav Lhotka wrote: > > Joel M. Halpern píše v Út 01. 09. 2009 v 09:31 -0400: > >> Unfortunately, while I like this case, it does not, as far as I can > >> tell, solve the problem at hand. > >> > >> A number of folks have argued that either > >> a) the managed device is free to set the node to some other value, even > >> if it has a default definition, and to still treat that as a default > >> valued node > >> b) the managed device is free to set nodes without default to some > >> value, and not report that value in response to get requests of any kind. > > > > The text now specifies that under certain conditions the configuration > > without the leaf is equivalent to one in which the leaf is present and > > set to the default value. However, formulations like "server MUST use > > the default" value may be understood as if the server is not allowed to > > assign a value unilaterally. So it might be actually better to talk > > about equivalence of configurations, also because it can be easily > > applied to datastores other than running. > > > > Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From cfinss@dial.pipex.com Tue Sep 1 10:29:42 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB163A686D for ; Tue, 1 Sep 2009 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkG3SE49Dlda for ; Tue, 1 Sep 2009 10:29:41 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 9E63D3A68C2 for ; Tue, 1 Sep 2009 10:28:01 -0700 (PDT) X-Trace: 191690738/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.113/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.113 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEALv2nEo+vGlx/2dsb2JhbACDLY4Dy18JhBIF X-IronPort-AV: E=Sophos;i="4.44,313,1249254000"; d="scan'208";a="191690738" X-IP-Direction: IN Received: from 1cust113.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.113]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Sep 2009 18:27:13 +0100 Message-ID: <004201ca2b20$e0b9c7e0$0601a8c0@allison> From: "tom.petch" To: "David Partain" , "NETMOD Working Group" References: <200909010959.59070.david.partain@ericsson.com> Date: Tue, 1 Sep 2009 17:48:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:29:42 -0000 ----- Original Message ----- From: "David Partain" Sent: Tuesday, September 01, 2009 9:59 AM > > There has been significant debate about whether to reopen the question of > having 'assigned-by system'. See this mail thread - > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html > > The discussion has been in the "agent-default -- new 3rd state" thread (and > probably elsewhere). > > Martin wrote in the message referenced above: "The idea is that if a leaf is > marked as assigned-by system, then the client MAY choose to not set a value > for the leaf when its parent instance is created. In this case the system > will assign a suitable value for the leaf." I am unclear. I take it this is created in the data tree but is it as config or operational state (which affects how it can be retrieved) and is an instance being created or is this one of those thingies which seem neither dead nor alive? This harks back to Phil differentiating uid from mtu and Joel not seeing the difference. I am afraid I have yet to see the difference:-( Martin said 'So "if an instance exists because the server created it" then it *is* config. ' Um, leaves me none the wiser. And what's the parent instance got to do with it? It sounds like an assumption is built in there (and not the usual case or non-presence container issues) that I am missing. Tom Petch > A number of people have said they think this should be reopened and that it > would be valuable, particularly in dealing with misunderstandings around the > meaning of default. Others have questioned doing so at this time. > > Clearly, if we think this is a serious enough problem that it MUST be fixed > for good interoperability, then we should do so. I'd like to resolve this > ASAP. Please voice your opinion by close of business tomorrow (Wednesday) > about whether you in principle think we should add 'assigned-by system' > (pending concrete text, of course). > > If the rough consensus appears to be to add it, I'll ask Martin to submit a > proposal with text. We'll then discuss based on that text. > > Thanks. > > David > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From cfinss@dial.pipex.com Tue Sep 1 10:29:43 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326AB3A6A0C for ; Tue, 1 Sep 2009 10:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH0vQbPiWuMY for ; Tue, 1 Sep 2009 10:29:42 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 517333A6A7F for ; Tue, 1 Sep 2009 10:28:02 -0700 (PDT) X-Trace: 191690744/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.113/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.113 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEALv2nEo+vGlx/2dsb2JhbACDLY4Dy18JhBIF X-IronPort-AV: E=Sophos;i="4.44,313,1249254000"; d="scan'208";a="191690744" X-IP-Direction: IN Received: from 1cust113.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.113]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Sep 2009 18:27:14 +0100 Message-ID: <004301ca2b20$e193fb40$0601a8c0@allison> From: "tom.petch" To: "David Partain" , "NETMOD Working Group" References: <200909011009.16729.david.partain@ericsson.com> Date: Tue, 1 Sep 2009 18:21:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:29:43 -0000 David I find it less than clear; see inline. Tom Petch ----- Original Message ----- From: "David Partain" To: "NETMOD Working Group" Sent: Tuesday, September 01, 2009 10:09 AM Subject: [netmod] Issue: interpretation of 'default' > Greetings, > > Another discussion that's been ... um... lively has been around the meaning > of 'default'. Martin has written some text (a new section) that he has sent > to the list, but it may have gotten lost in the middle of everything else. > As such, here it is again: > > ------------------------------------------------------------------------------ ------------------------------------ > 7.6.1. The leaf's default value > > The default value of a leaf is the value that the server uses if no > value has been explicitly set. The usage of the default value When are we talking about? Note we have no terminology for what is in the data tree, presume instances with values, in which case are we talking about an instance being created? But then we have no definition of when an instance is created. With an SNMP background, this is academic, there is always a 1.3.6.1.2.1.1.1 with a 'value', it is just a question of being a valid value or not, but with YANG, we have not nailed this down, and so some posts have implied that a data node leaf does not exist in the data tree unless and until eg its ancestor node becomes part of the data tree, or perhaps when the server, if it has permission, just decides to create it and ancestor anyway. And is there a difference, as Lada asked, between doing an specifying as opposed to 42? All this needs nailing down otherwise discussions of default, assigned by all/user/system.... can end up with each person having a different view. And 'explicitly set'; to me, that MUST be set by anyone, CLI, SNMP, Netconf, .... It is no use having a Netconf/YANG that pretends that nothing else in the world exists as far as configuration management is concerned and so can be ignored. Again, an issue touched on but not resolved. We have the gory details but lack the big picture. > depends on the type of the leaf's closest ancestor node in the schema > tree which is not a non-presence container: > > o If no such ancestor exists in the schema tree, the default value > MUST be used. > > o Otherwise, if this ancestor is a case node, the default value MUST > be used if any node from the case exists in the data tree, or if > the case node is the choice's default case, and no nodes from any > other case exist in the data tree. > > o Otherwise, the default value MUST be used if the ancestor node > exists in the data tree. > > In the cases where the default value MUST be used, the server MUST > operationally behave as is if the leaf was present in the data tree > with the default value as its value. > > If a leaf has a "default" statement, the leaf's default value is the > value of the "default" statement. Otherwise, if the leaf's type has > a default value, and the leaf is not mandatory, then the leaf's > default value is the type's default value. In all other cases, the > leaf does not have a default value. > ------------------------------------------------------------------------------ ------------------------------------ > > If possible, I want to reach consensus on whether this text is what the WG > wants this text or what changes we need to make to it. Please focus on this > text... > > Cheers, > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From cfinss@dial.pipex.com Tue Sep 1 10:29:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5373A7058 for ; Tue, 1 Sep 2009 10:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMixE7WfQ-Qr for ; Tue, 1 Sep 2009 10:29:43 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id AE2EC3A6F88 for ; Tue, 1 Sep 2009 10:28:03 -0700 (PDT) X-Trace: 191690761/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.113/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.113 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEALv2nEo+vGlx/2dsb2JhbACDLY4Dy18JhBIF X-IronPort-AV: E=Sophos;i="4.44,313,1249254000"; d="scan'208";a="191690761" X-IP-Direction: IN Received: from 1cust113.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.113]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Sep 2009 18:27:17 +0100 Message-ID: <004501ca2b20$e3486200$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <200908282045.n7SKjRaU038511@idle.juniper.net> <00a401ca298f$fe348f40$0601a8c0@allison> <4A9AE5D9.7020902@netconfcentral.com> Date: Tue, 1 Sep 2009 18:24:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:29:44 -0000 ----- Original Message ----- From: "Andy Bierman" To: "tom.petch" Cc: "Phil Shafer" ; Sent: Sunday, August 30, 2009 10:49 PM > tom.petch wrote: > > ----- Original Message ----- > > From: "Phil Shafer" > > Sent: Friday, August 28, 2009 10:45 PM > > > >> Andy Bierman writes: > >>> if this is true, then why does the 'explicit' mode > >>> of with-defaults just look at whether the leaf was > >>> explicitly set and not the YANG default? > >> The explicit mode should have logic like: > >> > >> if (the user explicitly set it) > >> return it > > > > Phil > > > > I think that you are absolutely right that this mode should exist; I see it as > > a major, if not the major, requirement to emerge from RFC3535. But I > > disagree that it is the only requirement; I think that there is another one, an > > operational one, I share certainly with Andy. > > > > Enterprise systems could not exist without configuration management; they simply > > have too many thousands of devices to configure by any other means. > > > > One key part of this is a three part system, a central store of data for each > > device, probably several versions for each, a pull protocol to get data from > > a device and a push protocol, such that given a fresh from shrink-wrap, > > manufacturer-supplied box, the push will create a replacement operational box. > > > > Box A gets trashed, take a new one off the shelf, push the data to the new box > > and the service is restored. > > > > So the pull protocol must get everything that needs to be set to create the > > operational box, regardless of which 'user' set it - CLI, SNMP, Netconf,..... - > > or when. > > > > I don't think YANG can help much here; it could have a substatement, > > read-only, modified , but really this is a Netconf protocol > > requirement for the device manufacturer to support. > > > > I think it wrong to equate this mode with the one and only meaning of words > > such as config. > > > > I can agree with Phil that 'config' I did not set > is not really config -- if the YANG and with-defaults > draft specify the same thing correctly. > > But if it is not config when an instance exists > because the server created it, then it must be > operational state. So it MUST be retrievable, > in order to support applications (NETCONF was chartered > to get away from screen-scraping). Andy, I agree, it MUST be retrievable. For Configuration purposes, I would prefer to stay with 'everything writable is config' and what has been set (by anyone outside the server, not as part of operational state or by server) is perforce a subset of that, and Netconf has the option to retrieve all or the subset. For Operational purposes, most of the time, I need a combination of items. If I look at an OSPF interface, I want to know - OSPF configured (explicitly set by some user) - Active or Passive (probably default but I want to hear the server's view, not some assumption that everything is fine) - timers (almost always default, but I really want to know what the server is actually using) - Adjacency (operational state) and, magically, that is what I currently get. It would be a shame if YANG or Netconf required the whole LS database to be retrieved just to give me the equivalent:-) And of course, there will be times when this summary does not resolve my issue, and yes, I will need every one of the 100 or however many items there are in the server relating to the interface. Tom Petch > > I am not willing to accept that any leaf instance > (defined as a leaf with a value != YANG default-stmt) > can ever be inaccessible for retrieval. > > If the server has a value, and the client asks for it > correctly, it MUST be returned via , , > or . That's what the standard says now, and > I agree with it. > > > > Tom Petch > > Andy > > > > >> But really it works like: > >> > >> if (there is a value in the config database) > >> return it // since the user must have set it > >> > >> In neither approach are default values inspected. > >> > >> Thanks, > >> Phil > > > > > > From andy@netconfcentral.com Tue Sep 1 10:37:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2D83A704C for ; Tue, 1 Sep 2009 10:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy8sQVoSqFh6 for ; Tue, 1 Sep 2009 10:37:05 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id CCD5128C902 for ; Tue, 1 Sep 2009 10:36:58 -0700 (PDT) Received: from [209.191.108.96] by n10.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 17:37:10 -0000 Received: from [68.142.201.252] by t3.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 17:37:10 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 17:37:10 -0000 X-Yahoo-Newman-Id: 645558.14439.bm@omp413.mail.mud.yahoo.com Received: (qmail 30600 invoked from network); 1 Sep 2009 17:37:10 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 17:37:10 -0000 X-YMail-OSG: sKpQGmoVM1kMAFCA77IJqXRTmDL2j6JiFmBVA87hZwBQqMImaLORnRAmOJktTid_yc847Iq_c4NY7IY6.zRSgBeIkyYuhKzvcPD15r9BLMmWSPl2N6hAUc93Lkrkrp1.JIix_7d1mN.a4RG2nZd3RKt2s3iUg2_UM4_GGeiJZL6EroDJV3cB.BXrmUPRXYQTL.P2X2AMMvqTooU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D5B5D.5060409@netconfcentral.com> Date: Tue, 01 Sep 2009 10:35:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" References: <200908282045.n7SKjRaU038511@idle.juniper.net> <00a401ca298f$fe348f40$0601a8c0@allison> <4A9AE5D9.7020902@netconfcentral.com> <004501ca2b20$e3486200$0601a8c0@allison> In-Reply-To: <004501ca2b20$e3486200$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:37:05 -0000 tom.petch wrote: ..... > and, magically, that is what I currently get. It would be a > shame if YANG or Netconf required the whole LS database > to be retrieved just to give me the equivalent:-) > It doesn't. The parameter is mandatory to implement for subtree filters. > And of course, there will be times when this summary > does not resolve my issue, and yes, I will need every one > of the 100 or however many items there are in the server > relating to the interface. > Yep -- nobody ever said the server should be forced to send all the data all the time. But the client MUST be able to ask for all the data somehow, even if that is not the default operation -- it still must be the same operation on every server. > Tom Petch Andy From phil@juniper.net Tue Sep 1 11:13:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182613A703B for ; Tue, 1 Sep 2009 11:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72Liyrt1qCUG for ; Tue, 1 Sep 2009 11:13:47 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 3D8543A6B99 for ; Tue, 1 Sep 2009 11:13:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSp1kZ6WccrI0urhZAxt/ZCwFM1MlZ7l0@postini.com; Tue, 01 Sep 2009 11:14:01 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 11:10:13 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:10:13 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:10:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:10:12 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81IA9d52862; Tue, 1 Sep 2009 11:10:11 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81Hw5Va092176; Tue, 1 Sep 2009 17:58:05 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909011758.n81Hw5Va092176@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9D29F1.6010806@netconfcentral.com> Date: Tue, 1 Sep 2009 13:58:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 18:10:12.0794 (UTC) FILETIME=[7318C1A0:01CA2B2F] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 18:13:48 -0000 Andy Bierman writes: >So I prefer 'report-all', and don't care about the server >wasting bandwidth while doing its job. But others (including me) do not prefer this. The "with-defaults" capability gives you the means to make the world work the way you want it. Since that's your preference for your applications, you should simply use 'report-all' for all your config requests. I guess what I find troubling is your view is that the world MUST work your way or else it is broken. The world isn't that fragile. Giving the device sufficient flexibility to work in their normal, native way is a good thing. Let the marketplace decide which default scheme wins the most converts. The rest of the world should be forced to follow your preference. Thanks, Phil From phil@juniper.net Tue Sep 1 11:22:28 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED3628C937 for ; Tue, 1 Sep 2009 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNyL0ZI852A8 for ; Tue, 1 Sep 2009 11:22:27 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 8882F28C92E for ; Tue, 1 Sep 2009 11:21:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSp1mQ1RzV1b3x+i/kdv8j41fR0aPKkN3@postini.com; Tue, 01 Sep 2009 11:21:58 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 11:18:38 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:18:38 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:18:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:18:37 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81IIad57347; Tue, 1 Sep 2009 11:18:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81I6W6M092259; Tue, 1 Sep 2009 18:06:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909011806.n81I6W6M092259@idle.juniper.net> To: "tom.petch" In-Reply-To: <004501ca2b20$e3486200$0601a8c0@allison> Date: Tue, 1 Sep 2009 14:06:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 18:18:37.0416 (UTC) FILETIME=[9FDFF680:01CA2B30] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 18:22:28 -0000 "tom.petch" writes: >----- Original Message ----- >From: "Andy Bierman" >> I can agree with Phil that 'config' I did not set >> is not really config -- if the YANG and with-defaults >> draft specify the same thing correctly. >> >> But if it is not config when an instance exists >> because the server created it, then it must be >> operational state. So it MUST be retrievable, >> in order to support applications (NETCONF was chartered >> to get away from screen-scraping). > >Andy, > >I agree, it MUST be retrievable. > >For Configuration purposes, >I would prefer to stay with 'everything writable is config' >and what has been set (by anyone outside the server, not >as part of operational state or by server) is perforce a >subset of that, and Netconf has the option to >retrieve all or the subset. Here's a proposal: Let's make "default" an error for "config false" data. This means that operational data values cannot default to a YANG-specified value. If you want them, you must emit them. This should end the comments about having to read documentation to find default values. It should also clarify the role of default in a YANG module. And it should cost almost nothing. Thanks, Phil From phil@juniper.net Tue Sep 1 11:40:55 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F713A67CF for ; Tue, 1 Sep 2009 11:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onms0LuNo99i for ; Tue, 1 Sep 2009 11:40:48 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 6D8A73A6A6C for ; Tue, 1 Sep 2009 11:40:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSp1qs4k9tUDgScupnaYcH/M3cyelzvIC@postini.com; Tue, 01 Sep 2009 11:40:56 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 11:36:39 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:36:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:36:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:36:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81Iacd66558; Tue, 1 Sep 2009 11:36:38 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81IOXLk092470; Tue, 1 Sep 2009 18:24:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909011824.n81IOXLk092470@idle.juniper.net> To: "tom.petch" Date: Tue, 1 Sep 2009 14:24:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 18:36:38.0846 (UTC) FILETIME=[247515E0:01CA2B33] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: [netmod] proposal : X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 18:40:55 -0000 There are huge issues with the overlap between config data and operational data. Trying to model these both in a single YANG module will be difficult and will introduce some annoying bits of hackery (like "mtu-configured" .vs. "mtu-right-now"). Instead, I propose a new operation for YANG-based models. The RPC will return operational data associated with a YANG module. The module name is a mandatory argument to the RPC, with an optional "revision" argument. In addition, a filter argument will take a stock NETCONF filter hierarchy. In response, the server will return a set of XML elements that follow many of the constraints of the YANG module, but are freed from a few, in order to allow useful data to be returned. A union's "type" statement and the "enum" statement will accept a "config" statement indicating if this branch of the union will be accepted for configuration data or only for operational data. module foo { ... container foo-top { list interface { key name; leaf name { type string; } leaf mtu { type int; default 1024; } leaf duplex { type enumeration { enum full; enum half; enum auto { config true; } default auto; } } } } } Alternative: "config" here could be replaced with "operational" and the value inverted. foo so-0/0/0 1500 full Since defaults are ignored for operational data, any values MUST be returned as part of the normal data hierarchy. Thanks, Phil From jmh@joelhalpern.com Tue Sep 1 12:15:07 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CD928C470 for ; Tue, 1 Sep 2009 12:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOSS9hXOBU8U for ; Tue, 1 Sep 2009 12:15:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8913828CA1F for ; Tue, 1 Sep 2009 12:14:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A66174303AF; Tue, 1 Sep 2009 12:13:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4319A4303AC; Tue, 1 Sep 2009 12:13:53 -0700 (PDT) Message-ID: <4A9D7270.5020207@joelhalpern.com> Date: Tue, 01 Sep 2009 15:13:52 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ladislav Lhotka References: <200909011009.16729.david.partain@ericsson.com> <4A9D2227.4060407@joelhalpern.com> <1251821133.4542.13.camel@missotis> <4A9D49D5.6060806@joelhalpern.com> <1251825583.4542.24.camel@missotis> In-Reply-To: <1251825583.4542.24.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:15:07 -0000 Then I must restate my disagreement with you. The point of the wording is that if the model has a default value specified then the managed device is not free to arbitrarily treat the node as having some other value. And it is most especially not permitted to treat that node as if it were being validly defaulted. It is not. To change that meaning makes the agree MUST in teh default wording meaningless. I understand you want a different meaning. But please argue explicitly for that. Arguing for wording that allows multiple incompatible interpretations is actually counter-productive. Yours, Joel Ladislav Lhotka wrote: > Joel M. Halpern píše v Út 01. 09. 2009 v 12:20 -0400: >> Sorry, I have no idea what you are getting at / asking for. >> (I can provide two possible interpretations, one of which would be fine >> and one of which I would completely disagree with. And what you meant >> is probably neither one.) >> Would you please clarify to the list? > > My point simply is that the "server MUST use" language misled me into > thinking that the 'default' statement prevents the device from doing a), > which is not the case, so I am suggesting another formulation expressed > solely in terms of datastore content. > > Lada > >> Thank you, >> Joel >> >> >> Ladislav Lhotka wrote: >>> Joel M. Halpern píše v Út 01. 09. 2009 v 09:31 -0400: >>>> Unfortunately, while I like this case, it does not, as far as I can >>>> tell, solve the problem at hand. >>>> >>>> A number of folks have argued that either >>>> a) the managed device is free to set the node to some other value, even >>>> if it has a default definition, and to still treat that as a default >>>> valued node >>>> b) the managed device is free to set nodes without default to some >>>> value, and not report that value in response to get requests of any kind. >>> The text now specifies that under certain conditions the configuration >>> without the leaf is equivalent to one in which the leaf is present and >>> set to the default value. However, formulations like "server MUST use >>> the default" value may be understood as if the server is not allowed to >>> assign a value unilaterally. So it might be actually better to talk >>> about equivalence of configurations, also because it can be easily >>> applied to datastores other than running. >>> >>> Lada From andy@netconfcentral.com Tue Sep 1 12:28:27 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E523A6A59 for ; Tue, 1 Sep 2009 12:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMgrbR3+oMeY for ; Tue, 1 Sep 2009 12:28:26 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 96DE928C5B4 for ; Tue, 1 Sep 2009 12:28:26 -0700 (PDT) Received: (qmail 65532 invoked from network); 1 Sep 2009 19:21:28 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 19:21:28 -0000 X-YMail-OSG: DQE1zCoVM1nrd4scd1P0S5JnL_zRGPZugMnAE3swENQs38ZKbisE.E29DqvT_lPl_Nqi3HtfJoIgu1AWuVcj4zI3zlY_82mKKOCBqXX0U.jfIoQbd9Jp7YAfeNGiKn5zEuhZ1sTZNFtTcLnZiqE7zfTTu5BrE8lyWEeYuSXuwp6dzV_LmQd_boyh3kGReV5r8pz7dqhKhpXh0Khk.rgH_IGM_XjYn4KXL74qkJUOHa.sGKLSeONWPQ5hG0DG9Wwu5ynJTmjyoZLD5m7K X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D73CC.7050903@netconfcentral.com> Date: Tue, 01 Sep 2009 12:19:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909011758.n81Hw5Va092176@idle.juniper.net> In-Reply-To: <200909011758.n81Hw5Va092176@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:28:27 -0000 Phil Shafer wrote: > Andy Bierman writes: >> So I prefer 'report-all', and don't care about the server >> wasting bandwidth while doing its job. > > But others (including me) do not prefer this. The "with-defaults" > capability gives you the means to make the world work the way you > want it. Since that's your preference for your applications, you > should simply use 'report-all' for all your config requests. > > I guess what I find troubling is your view is that the world MUST > work your way or else it is broken. The world isn't that fragile. > Giving the device sufficient flexibility to work in their normal, > native way is a good thing. Let the marketplace decide which default > scheme wins the most converts. The rest of the world should be > forced to follow your preference. > I see the situation just the opposite. The :with-defaults capability is optional-to-implement. You want to force your way of thinking on everybody else by insisting that your server does not need to ever make the full data-set available to any client, or to even let the client know what sort of 'server-pruning' is being done. You already agreed it is not because there is some implementation burden, but because the client 'does not want the data'. This is not always true, and several people (including me) want a standard that forces server-created nodes to be retrievable on every implementation of a YANG module. > Thanks, > Phil > Andy From jmh@joelhalpern.com Tue Sep 1 12:28:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461BC28C94F for ; Tue, 1 Sep 2009 12:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoIBhmazt26W for ; Tue, 1 Sep 2009 12:28:28 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id 8195128C94E for ; Tue, 1 Sep 2009 12:28:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id D43F6A37B3 for ; Tue, 1 Sep 2009 12:22:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BE1D14303BE; Tue, 1 Sep 2009 12:22:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 410734303B2; Tue, 1 Sep 2009 12:22:18 -0700 (PDT) Message-ID: <4A9D7469.7030006@joelhalpern.com> Date: Tue, 01 Sep 2009 15:22:17 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200909011806.n81I6W6M092259@idle.juniper.net> In-Reply-To: <200909011806.n81I6W6M092259@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:28:29 -0000 I have a strong suspicion that we are talking past each other. The issue I believe Andy has, and I know I have, is with a "config true" which is given a value by the system, but where that value is not reported to a client application either in a regular get or in get with all defaults. If the system is using a value for a "config true" node, and that value is not reported, and that value is not the model defined default value, then we have an operability problem. If some systems report it one way, and some systems report it another way, then we probably have an interoperability problem. From the text below, I would have concluded that you were suggesting that the value the system is using should appear in a "config false" node, separate from the "config true" node used to set the value. As I said to Juergen, I can live with that. However, from your previous strident responses, I presume that is not what you intended to communicate. Yours, Joel Phil Shafer wrote: > "tom.petch" writes: >> ----- Original Message ----- >> From: "Andy Bierman" >>> I can agree with Phil that 'config' I did not set >>> is not really config -- if the YANG and with-defaults >>> draft specify the same thing correctly. >>> >>> But if it is not config when an instance exists >>> because the server created it, then it must be >>> operational state. So it MUST be retrievable, >>> in order to support applications (NETCONF was chartered >>> to get away from screen-scraping). >> Andy, >> >> I agree, it MUST be retrievable. >> >> For Configuration purposes, >> I would prefer to stay with 'everything writable is config' >> and what has been set (by anyone outside the server, not >> as part of operational state or by server) is perforce a >> subset of that, and Netconf has the option to >> retrieve all or the subset. > > Here's a proposal: > > Let's make "default" an error for "config false" data. > > This means that operational data values cannot default > to a YANG-specified value. If you want them, you must > emit them. > > This should end the comments about having to read documentation to > find default values. > > It should also clarify the role of default in a YANG module. > > And it should cost almost nothing. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Tue Sep 1 12:35:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A6B3A6CBD for ; Tue, 1 Sep 2009 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGSWK1k92qhr for ; Tue, 1 Sep 2009 12:35:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7787B3A68A5 for ; Tue, 1 Sep 2009 12:35:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C79F2C002A for ; Tue, 1 Sep 2009 21:35:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PsoVIX9pdnRU; Tue, 1 Sep 2009 21:35:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBB6EC000C; Tue, 1 Sep 2009 21:35:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 68B79C8B502; Tue, 1 Sep 2009 21:35:08 +0200 (CEST) Date: Tue, 1 Sep 2009 21:35:08 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090901193508.GA9782@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [netmod] Configuration Data versus Operational State Data versus Statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 19:35:30 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I propose to add a section to the architecture document defining and discussing the difference between configuration data, operational state data, and statistics. I attaching some draft writeup explaining the background, providing a definition and some examples we discussed here on the list. I am also including a section discussing potential approaches to deal with operational state data. This is more for discussion rather than inclusion in the architecture document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="NETCONF.txt" * Configuration Data versus Operational State Data versus Statistics The distinction between configuration data, operational state data, and statistics is important to understand for data model writers and people who plan to extend the NETCONF protocol. This section first discusses some background and then provides a definition and some examples. ** Background During the IAB Network Management Workshop documented in RFC 3535, operators did formulate the following two requirements: 2. It is necessary to make a clear distinction between configuration data, data that describes operational state and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols. 3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices. The NETCONF protocol defined in RFC 4741 distinguishes two types of data, namely configuration data and state data: Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. Obviously, the distinction formulated by the operators between configuration data, operational state data, and statistical data has not been maintained in the design of NETCONF. ** Definitions Below is a definition for configuration data, operational state data, and statistical data. The definition borrows from previous work. - Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. [RFC 4741] - Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behaviour similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols. - Statistical data is the set of read-only data created by a system itself. It reports the status and performance of the system and its components. To clarify the difference between configuration data, operational state data and statistics, we will discuss some examples. *** Example 1: IP Routing Table IP routing tables can contain entries that are statically configured (configuration data) as well as entries obtained from routing protocols such as OSPF (operational state data). In addition, a routing engine might collect statistics like how often a particular routing table entry has been used. *** Example 2: Interfaces Network interfaces usually comes with a large number of attributes that are specific to the interface type and in some cases specific to the cable plugged into an interface. Examples are the maximum transmission unit of an interface or the speed detected by an Ethernet interface. In many deployments, systems use the interface attributes detected when an interface is initialized. As such, these attributes constitute operational state. However, there are usually provisions to overwrite the discovered attributes with static configuration data, like for example configuring the interface MTU to use a specific value or forcing an Ethernet interface to run at a given speed. *** Example 3: Account Information Systems usually maintain static configuration information about the accounts on the system. In addition, systems can obtain information about accounts from other sources (e.g. LDAP, NIS) dynamically, leading to operational state data. Information about account usage are examples of statistic data. Note that configuration data supplied to a system in order to create a new account might be supplemented with additional configuration information determined by the system when the account is being created (such as a unique account id). Even though the system might create such information, it usually becomes part of the static configuration of the system since this data is not transient. ** Implications The primary focus of YANG 1.0 is configuration data. At the time of this writing, the WG has not yet a clear idea how to best deal with the separation of operational state data and statistics since NETCONF treats them both as state data. There are different options to tackle this problem: *** Data Models The first option is to have data models that provide explicitly differentiate between configuration data and operational state data. This leads to duplication of data structures and might not scale well from a modeling perspective. *** Additional Operations to Retrieve Operational State The NETCONF protocol can be extended with new protocol operations that specifically allow the retrieval of all operational state, e.g. by introducing a get-ops() operation (and perhaps also a get-stats() operation). *** Introduction of an Operational State Datastore Another option could be to introduce a new "configuration" data store that represents the operational state. A get-config() on the data store would then return the operational state determining the behaviour of the box instead of its static and explicit configuration state. *** New Options to Change Access to the Running Datastore New options can be introduced to change the behaviour of existing protocol operations so that they return not only the configuration data but in addition operational state data. The -with-defaults proposal is kind of going into that direction but it should be noted that this approach assumes that operational state is always a proper super-set of configuration state, which might not always be true. A typical example is an interface statically configured to automatically select the speed while the operational state includes the actually selected speed. --FCuugMFkClbJLl1L-- From phil@juniper.net Tue Sep 1 12:35:33 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46973A68A5 for ; Tue, 1 Sep 2009 12:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POr76XMFgw75 for ; Tue, 1 Sep 2009 12:35:33 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 265C03A6BC8 for ; Tue, 1 Sep 2009 12:35:32 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSp13calOGoHdjra2lbt5hFBs8kwqnRtX@postini.com; Tue, 01 Sep 2009 12:35:47 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 12:32:34 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:32:34 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:32:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:32:33 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81JWXd95127; Tue, 1 Sep 2009 12:32:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81JKT1I093197; Tue, 1 Sep 2009 19:20:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909011920.n81JKT1I093197@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9D45D0.4060905@netconfcentral.com> Date: Tue, 1 Sep 2009 15:20:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 19:32:33.0872 (UTC) FILETIME=[F4356D00:01CA2B3A] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: [netmod] issue: adding defaults in new revisions [was Re: database + defaults = broken] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:35:33 -0000 Andy Bierman writes: >Revisions are optional, and a default can >be added over time. The overriding rule is: ... However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification. Proposals: (a) Default statements cannot be added in new revisions of a module. (b) Default statements cannot be added in new revisions of a module unless that module contains a revision statement. (c) No changes can be made to a module unless it contains a revision statement. (b) and (c) could be done with by changing: For any published change, a new "revision" statement (^revision^) - SHOULD be included in front of the existing revision statements. + MUST be included in front of the existing revision statements. or making two classes of ways a module can be changed, and requiring revisions for any changes with a potential to cause interoperability problems. Thanks, Phil From andy@netconfcentral.com Tue Sep 1 12:49:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6335F3A6FA6 for ; Tue, 1 Sep 2009 12:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPR7k9Jue9C2 for ; Tue, 1 Sep 2009 12:49:53 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id D29B93A708F for ; Tue, 1 Sep 2009 12:48:54 -0700 (PDT) Received: from [68.142.200.224] by n19.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 19:44:56 -0000 Received: from [68.142.201.247] by t5.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 19:44:56 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 19:44:56 -0000 X-Yahoo-Newman-Id: 789494.94985.bm@omp408.mail.mud.yahoo.com Received: (qmail 72146 invoked from network); 1 Sep 2009 19:44:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 19:44:55 -0000 X-YMail-OSG: ENUwl6gVM1mTu8VMztSoxYqYHMj9iPUft_FtwGx7ooCkjohxjo2VevqbIZD3jvYaBbxt448JsiifUJUkZ7xqqvtA4Plk614Ze1mfA.QKpKUNu0roVzZAPhXQxtGZihMnkA.pZbTkuAo4ieJnkZBOaTP27qfEgmVGo4Q1UePOflYDD4sA7cYHpaGrDwsl2tWrTDmty5pV.BsZE7jFrcTXOQLoBfcvfk..X_fFj_RjIXOBQIA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D794C.3000808@netconfcentral.com> Date: Tue, 01 Sep 2009 12:43:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200909011806.n81I6W6M092259@idle.juniper.net> <4A9D7469.7030006@joelhalpern.com> In-Reply-To: <4A9D7469.7030006@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:49:54 -0000 Joel M. Halpern wrote: > I have a strong suspicion that we are talking past each other. > > The issue I believe Andy has, and I know I have, is with a "config true" > which is given a value by the system, but where that value is not > reported to a client application either in a regular get or in get with > all defaults. > > If the system is using a value for a "config true" node, > and that value is not reported, and that value is not the model defined > default value, then we have an operability problem. > If some systems report it one way, and some systems report it another > way, then we probably have an interoperability problem. > > From the text below, I would have concluded that you were suggesting > that the value the system is using should appear in a "config false" > node, separate from the "config true" node used to set the value. As I > said to Juergen, I can live with that. I do not understand why, if the data is tagged config=false, it is somehow less potentially useful to the operator. What is the correlation I am missing here? What about the deviations and no-revision-date corner-cases? I thought deterministic behavior across versions, platforms, and vendors was our goal here. I don't understand why the functional requirements for network-related data retrieval established through 2 decades of standards work should be ignored, and the bar should be lowered for NETCONF. In SNMP you can get an exact piece of data (get foo.1.2.3). Not in NETCONF. In SNMP, if foo.1.2.3 exists then you can get its value, otherwise it does not exist. Simple yet powerful. (modulo VACM, of course). However, from your previous > strident responses, I presume that is not what you intended to communicate. > > Yours, > Joel Andy > > Phil Shafer wrote: >> "tom.petch" writes: >>> ----- Original Message ----- >>> From: "Andy Bierman" >>>> I can agree with Phil that 'config' I did not set >>>> is not really config -- if the YANG and with-defaults >>>> draft specify the same thing correctly. >>>> >>>> But if it is not config when an instance exists >>>> because the server created it, then it must be >>>> operational state. So it MUST be retrievable, >>>> in order to support applications (NETCONF was chartered >>>> to get away from screen-scraping). >>> Andy, >>> >>> I agree, it MUST be retrievable. >>> >>> For Configuration purposes, >>> I would prefer to stay with 'everything writable is config' >>> and what has been set (by anyone outside the server, not >>> as part of operational state or by server) is perforce a >>> subset of that, and Netconf has the option to >>> retrieve all or the subset. >> >> Here's a proposal: >> >> Let's make "default" an error for "config false" data. >> >> This means that operational data values cannot default >> to a YANG-specified value. If you want them, you must >> emit them. >> >> This should end the comments about having to read documentation to >> find default values. >> >> It should also clarify the role of default in a YANG module. >> >> And it should cost almost nothing. >> >> Thanks, >> Phil >> _______________________________________________ >> 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 jmh@joelhalpern.com Tue Sep 1 12:49:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80713A6910 for ; Tue, 1 Sep 2009 12:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf5EePCC9n9b for ; Tue, 1 Sep 2009 12:49:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 672283A6C71 for ; Tue, 1 Sep 2009 12:49:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1DDB74303C6; Tue, 1 Sep 2009 12:49:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 794F44303C8; Tue, 1 Sep 2009 12:49:07 -0700 (PDT) Message-ID: <4A9D7AB2.90006@joelhalpern.com> Date: Tue, 01 Sep 2009 15:49:06 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <200909011806.n81I6W6M092259@idle.juniper.net> <4A9D7469.7030006@joelhalpern.com> <4A9D794C.3000808@netconfcentral.com> In-Reply-To: <4A9D794C.3000808@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:49:59 -0000 Andy, sorry, I have no idea what you are getting at. I was trying to suggest again that having a "config false" node with the data, which is reported, would be a way to have the data reported. I realize I am repeating myself, and apologize for that. I was repeating myself because although when I said it last Phill had strongly objected to that approach, it is what he seems to be suggesting in the note I was responding to. I think that this is somehow related to Phil's proposed new operation, which I also did not understand. sounds to me like a which happens to target only "config false" nodes. Yours, joel Andy Bierman wrote: > Joel M. Halpern wrote: >> I have a strong suspicion that we are talking past each other. >> >> The issue I believe Andy has, and I know I have, is with a "config true" >> which is given a value by the system, but where that value is not >> reported to a client application either in a regular get or in get with >> all defaults. >> >> If the system is using a value for a "config true" node, >> and that value is not reported, and that value is not the model defined >> default value, then we have an operability problem. >> If some systems report it one way, and some systems report it another >> way, then we probably have an interoperability problem. >> >> From the text below, I would have concluded that you were suggesting >> that the value the system is using should appear in a "config false" >> node, separate from the "config true" node used to set the value. As I >> said to Juergen, I can live with that. > > I do not understand why, if the > data is tagged config=false, it is somehow less > potentially useful to the operator. > What is the correlation I am missing here? > > What about the deviations and no-revision-date corner-cases? > I thought deterministic behavior across versions, platforms, > and vendors was our goal here. I don't understand why > the functional requirements for network-related data retrieval > established through 2 decades of standards work should be > ignored, and the bar should be lowered for NETCONF. > > In SNMP you can get an exact piece of data (get foo.1.2.3). > Not in NETCONF. In SNMP, if foo.1.2.3 exists then you > can get its value, otherwise it does not exist. Simple yet powerful. > (modulo VACM, of course). > > > However, from your previous >> strident responses, I presume that is not what you intended to communicate. >> >> Yours, >> Joel > > > Andy > > >> Phil Shafer wrote: >>> "tom.petch" writes: >>>> ----- Original Message ----- >>>> From: "Andy Bierman" >>>>> I can agree with Phil that 'config' I did not set >>>>> is not really config -- if the YANG and with-defaults >>>>> draft specify the same thing correctly. >>>>> >>>>> But if it is not config when an instance exists >>>>> because the server created it, then it must be >>>>> operational state. So it MUST be retrievable, >>>>> in order to support applications (NETCONF was chartered >>>>> to get away from screen-scraping). >>>> Andy, >>>> >>>> I agree, it MUST be retrievable. >>>> >>>> For Configuration purposes, >>>> I would prefer to stay with 'everything writable is config' >>>> and what has been set (by anyone outside the server, not >>>> as part of operational state or by server) is perforce a >>>> subset of that, and Netconf has the option to >>>> retrieve all or the subset. >>> Here's a proposal: >>> >>> Let's make "default" an error for "config false" data. >>> >>> This means that operational data values cannot default >>> to a YANG-specified value. If you want them, you must >>> emit them. >>> >>> This should end the comments about having to read documentation to >>> find default values. >>> >>> It should also clarify the role of default in a YANG module. >>> >>> And it should cost almost nothing. >>> >>> Thanks, >>> Phil >>> _______________________________________________ >>> 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 phil@juniper.net Tue Sep 1 12:53:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FD33A686D for ; Tue, 1 Sep 2009 12:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqZRP7T2vGby for ; Tue, 1 Sep 2009 12:53:04 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 3E5B728C9A2 for ; Tue, 1 Sep 2009 12:53:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSp17kvUdL2Tp1i7aWsXROT+jR27Ip3no@postini.com; Tue, 01 Sep 2009 12:53:18 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 12:42:12 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:42:12 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:42:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:42:12 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81JgBd99506; Tue, 1 Sep 2009 12:42:11 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81JU7WS093379; Tue, 1 Sep 2009 19:30:07 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909011930.n81JU7WS093379@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9D73CC.7050903@netconfcentral.com> Date: Tue, 1 Sep 2009 15:30:06 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 19:42:12.0040 (UTC) FILETIME=[4CD2DC80:01CA2B3C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:53:05 -0000 Andy Bierman writes: >You want to force your way of thinking on everybody >else by insisting that your server does not need >to ever make the full data-set available to any client, >or to even let the client know what sort of 'server-pruning' >is being done. The current scheme in YANG allows the server to behave in any of the three styles listed in the with-defaults draft. We have sufficient flexibility to allow you to work the way you want, and to allow others to work the way they work. This is good. Thanks, Phil From andy@netconfcentral.com Tue Sep 1 12:53:06 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510263A6A8E for ; Tue, 1 Sep 2009 12:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvoCFesqc81J for ; Tue, 1 Sep 2009 12:53:05 -0700 (PDT) Received: from n9.bullet.mail.mud.yahoo.com (n9.bullet.mail.mud.yahoo.com [209.191.86.157]) by core3.amsl.com (Postfix) with SMTP id 737C03A686D for ; Tue, 1 Sep 2009 12:53:05 -0700 (PDT) Received: from [68.142.200.227] by n9.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 19:52:50 -0000 Received: from [68.142.201.73] by t8.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 19:52:50 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 19:52:50 -0000 X-Yahoo-Newman-Id: 549754.14275.bm@omp425.mail.mud.yahoo.com Received: (qmail 78903 invoked from network); 1 Sep 2009 19:52:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 19:52:49 -0000 X-YMail-OSG: yjWY5.oVM1mJ59y_Pyx8IJMgLrLXpVCWp60vOQ2_djeH2wgIFjMuO347h7i2.wrC5hAKYKvbvk05SYDeD5WWe5uIDS1xeXOait0Pbyj4im0u9bWKCGkQwiWpKr3FreXAbHzcEXAI_SCp5f232Zs6tVkaK9MrSmQFb1l2_pJGnY5gEEbVmxsAGAJK1l0L8SH91rRe92wJ7JRMn7E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D7BA2.8020803@netconfcentral.com> Date: Tue, 01 Sep 2009 12:53:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909011930.n81JU7WS093379@idle.juniper.net> In-Reply-To: <200909011930.n81JU7WS093379@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:53:06 -0000 Phil Shafer wrote: > Andy Bierman writes: >> You want to force your way of thinking on everybody >> else by insisting that your server does not need >> to ever make the full data-set available to any client, >> or to even let the client know what sort of 'server-pruning' >> is being done. > > The current scheme in YANG allows the server to behave in any of > the three styles listed in the with-defaults draft. We have > sufficient flexibility to allow you to work the way you want, and > to allow others to work the way they work. This is good. > no it does not allow for the 3 current schemes. That is nonsense. The draft clearly says that database = leafs + YANG default-stmt leafs. There is no text then even suggests anything other than that. > Thanks, > Phil > Andy From mbj@tail-f.com Tue Sep 1 12:55:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BF13A69A2 for ; Tue, 1 Sep 2009 12:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29M354RQ8z7C for ; Tue, 1 Sep 2009 12:54:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 96B313A69D9 for ; Tue, 1 Sep 2009 12:54:59 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D40876C4A1; Tue, 1 Sep 2009 21:54:57 +0200 (CEST) Date: Tue, 01 Sep 2009 21:54:57 +0200 (CEST) Message-Id: <20090901.215457.12686984.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251825583.4542.24.camel@missotis> References: <1251821133.4542.13.camel@missotis> <4A9D49D5.6060806@joelhalpern.com> <1251825583.4542.24.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:55:00 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSm9lbCBNLiBIYWxw ZXJuIHDDrcWhZSB2IMOadCAwMS4gMDkuIDIwMDkgdiAxMjoyMCAtMDQwMDoNCj4gPiBTb3JyeSwg SSBoYXZlIG5vIGlkZWEgd2hhdCB5b3UgYXJlIGdldHRpbmcgYXQgLyBhc2tpbmcgZm9yLg0KPiA+ IChJIGNhbiBwcm92aWRlIHR3byBwb3NzaWJsZSBpbnRlcnByZXRhdGlvbnMsIG9uZSBvZiB3aGlj aCB3b3VsZCBiZSBmaW5lIA0KPiA+IGFuZCBvbmUgb2Ygd2hpY2ggSSB3b3VsZCBjb21wbGV0ZWx5 IGRpc2FncmVlIHdpdGguICBBbmQgd2hhdCB5b3UgbWVhbnQgDQo+ID4gaXMgcHJvYmFibHkgbmVp dGhlciBvbmUuKQ0KPiA+IFdvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB0byB0aGUgbGlzdD8NCj4g DQo+IE15IHBvaW50IHNpbXBseSBpcyB0aGF0IHRoZSAic2VydmVyIE1VU1QgdXNlIiBsYW5ndWFn ZSBtaXNsZWQgbWUgaW50bw0KPiB0aGlua2luZyB0aGF0IHRoZSAnZGVmYXVsdCcgc3RhdGVtZW50 IHByZXZlbnRzIHRoZSBkZXZpY2UgZnJvbSBkb2luZyBhKSwNCj4gd2hpY2ggaXMgbm90IHRoZSBj YXNlLA0KDQpXZWxsLCB0aGF0IHdhcyB0aGUgaW50ZW50aW9uLiAgSWYgdGhlcmUgaXMgYSAnZGVm YXVsdCcgc3RhdGVtZW50LCBpdA0KcHJldmVudHMgdGhlIHNlcnZlciBmcm9tIGlnbm9yaW5nIGl0 LiANCg0KV2h5IGRvIHNheSB0aGF0IHRoaXMgaXMgbm90IHRoZSBjYXNlPw0KDQoNCi9tYXJ0aW4N Cg0KPiA+IExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4gPiA+IEpvZWwgTS4gSGFscGVybiBww63F oWUgdiDDmnQgMDEuIDA5LiAyMDA5IHYgMDk6MzEgLTA0MDA6DQo+ID4gPj4gVW5mb3J0dW5hdGVs eSwgd2hpbGUgSSBsaWtlIHRoaXMgY2FzZSwgaXQgZG9lcyBub3QsIGFzIGZhciBhcyBJIGNhbiAN Cj4gPiA+PiB0ZWxsLCBzb2x2ZSB0aGUgcHJvYmxlbSBhdCBoYW5kLg0KPiA+ID4+DQo+ID4gPj4g QSBudW1iZXIgb2YgZm9sa3MgaGF2ZSBhcmd1ZWQgdGhhdCBlaXRoZXINCj4gPiA+PiBhKSB0aGUg bWFuYWdlZCBkZXZpY2UgaXMgZnJlZSB0byBzZXQgdGhlIG5vZGUgdG8gc29tZSBvdGhlciB2YWx1 ZSwgZXZlbiANCj4gPiA+PiBpZiBpdCBoYXMgYSBkZWZhdWx0IGRlZmluaXRpb24sIGFuZCB0byBz dGlsbCB0cmVhdCB0aGF0IGFzIGEgZGVmYXVsdCANCj4gPiA+PiB2YWx1ZWQgbm9kZQ0KPiA+ID4+ IGIpIHRoZSBtYW5hZ2VkIGRldmljZSBpcyBmcmVlIHRvIHNldCBub2RlcyB3aXRob3V0IGRlZmF1 bHQgdG8gc29tZSANCj4gPiA+PiB2YWx1ZSwgYW5kIG5vdCByZXBvcnQgdGhhdCB2YWx1ZSBpbiBy ZXNwb25zZSB0byBnZXQgcmVxdWVzdHMgb2YgYW55IGtpbmQuDQo+ID4gPiANCj4gPiA+IFRoZSB0 ZXh0IG5vdyBzcGVjaWZpZXMgdGhhdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMgdGhlIGNvbmZp Z3VyYXRpb24NCj4gPiA+IHdpdGhvdXQgdGhlIGxlYWYgaXMgZXF1aXZhbGVudCB0byBvbmUgaW4g d2hpY2ggdGhlIGxlYWYgaXMgcHJlc2VudCBhbmQNCj4gPiA+IHNldCB0byB0aGUgZGVmYXVsdCB2 YWx1ZS4gSG93ZXZlciwgZm9ybXVsYXRpb25zIGxpa2UgInNlcnZlciBNVVNUIHVzZQ0KPiA+ID4g dGhlIGRlZmF1bHQiIHZhbHVlIG1heSBiZSB1bmRlcnN0b29kIGFzIGlmIHRoZSBzZXJ2ZXIgaXMg bm90IGFsbG93ZWQgdG8NCj4gPiA+IGFzc2lnbiBhIHZhbHVlIHVuaWxhdGVyYWxseS4gU28gaXQg bWlnaHQgYmUgYWN0dWFsbHkgYmV0dGVyIHRvIHRhbGsNCj4gPiA+IGFib3V0IGVxdWl2YWxlbmNl IG9mIGNvbmZpZ3VyYXRpb25zLCBhbHNvIGJlY2F1c2UgaXQgY2FuIGJlIGVhc2lseQ0KPiA+ID4g YXBwbGllZCB0byBkYXRhc3RvcmVzIG90aGVyIHRoYW4gcnVubmluZy4NCj4gPiA+IA0KPiA+ID4g TGFkYQ0KPiAtLSANCj4gTGFkaXNsYXYgTGhvdGthLCBDRVNORVQNCj4gUEdQIEtleSBJRDogRTc0 RThDMEMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From andy@netconfcentral.com Tue Sep 1 12:57:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137A53A6BED for ; Tue, 1 Sep 2009 12:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LriXjTV3QyA5 for ; Tue, 1 Sep 2009 12:57:36 -0700 (PDT) Received: from n11.bullet.mail.mud.yahoo.com (n11.bullet.mail.mud.yahoo.com [209.191.125.210]) by core3.amsl.com (Postfix) with SMTP id 18CED3A6AAD for ; Tue, 1 Sep 2009 12:57:36 -0700 (PDT) Received: from [68.142.200.221] by n11.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 19:57:00 -0000 Received: from [68.142.201.244] by t9.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 19:57:00 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 19:57:00 -0000 X-Yahoo-Newman-Id: 837609.47172.bm@omp405.mail.mud.yahoo.com Received: (qmail 46426 invoked from network); 1 Sep 2009 19:57:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 19:56:59 -0000 X-YMail-OSG: 1JkTV2wVM1nHaXqRbUTqZBAqZGIMIXiostUtpkwmXaPX4k9xi_TPG37e5zBRWiKiUkMFqiW7QzKqL5bkFEqrvtzgrjJAxZ.ZbkvYHxcWKN9V8_oL.veVsbmq6QVDY0AwTJAWUYmcTQVi3QBZtY0fRtQwhGryLHAJA8nFzKGqHyTVoyFall1c_BZn4cEpNNPtohBKcEo8SdYbQGBOhOr5GVF2JT_2zZd1ttrgMzL5kXSOFeE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D7C9C.7040004@netconfcentral.com> Date: Tue, 01 Sep 2009 12:57:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200909011806.n81I6W6M092259@idle.juniper.net> <4A9D7469.7030006@joelhalpern.com> <4A9D794C.3000808@netconfcentral.com> <4A9D7AB2.90006@joelhalpern.com> In-Reply-To: <4A9D7AB2.90006@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:57:37 -0000 Joel M. Halpern wrote: > Andy, sorry, I have no idea what you are getting at. > I was trying to suggest again that having a "config false" node with the > data, which is reported, would be a way to have the data reported. > I realize I am repeating myself, and apologize for that. > I was repeating myself because although when I said it last Phill had > strongly objected to that approach, it is what he seems to be suggesting > in the note I was responding to. > sorry -- I misread what you meant by your comment. I cannot live with a solution where a YANG object that is config=true, but <*-config> operations do not work. Ditto for a solution where a YANG object that is config=false, but <*-config> operations do work. Maybe that is not what you are talking about either. > I think that this is somehow related to Phil's proposed new operation, > which I also did not understand. sounds to me > like a which happens to target only "config false" nodes. > > Yours, > joel Andy > > Andy Bierman wrote: >> Joel M. Halpern wrote: >>> I have a strong suspicion that we are talking past each other. >>> >>> The issue I believe Andy has, and I know I have, is with a "config true" >>> which is given a value by the system, but where that value is not >>> reported to a client application either in a regular get or in get with >>> all defaults. >>> >>> If the system is using a value for a "config true" node, >>> and that value is not reported, and that value is not the model defined >>> default value, then we have an operability problem. >>> If some systems report it one way, and some systems report it another >>> way, then we probably have an interoperability problem. >>> >>> From the text below, I would have concluded that you were suggesting >>> that the value the system is using should appear in a "config false" >>> node, separate from the "config true" node used to set the value. As I >>> said to Juergen, I can live with that. >> >> I do not understand why, if the >> data is tagged config=false, it is somehow less >> potentially useful to the operator. >> What is the correlation I am missing here? >> >> What about the deviations and no-revision-date corner-cases? >> I thought deterministic behavior across versions, platforms, >> and vendors was our goal here. I don't understand why >> the functional requirements for network-related data retrieval >> established through 2 decades of standards work should be >> ignored, and the bar should be lowered for NETCONF. >> >> In SNMP you can get an exact piece of data (get foo.1.2.3). >> Not in NETCONF. In SNMP, if foo.1.2.3 exists then you >> can get its value, otherwise it does not exist. Simple yet powerful. >> (modulo VACM, of course). >> >> >> However, from your previous >>> strident responses, I presume that is not what you intended to >>> communicate. >>> >>> Yours, >>> Joel >> >> >> Andy >> >> >>> Phil Shafer wrote: >>>> "tom.petch" writes: >>>>> ----- Original Message ----- >>>>> From: "Andy Bierman" >>>>>> I can agree with Phil that 'config' I did not set >>>>>> is not really config -- if the YANG and with-defaults >>>>>> draft specify the same thing correctly. >>>>>> >>>>>> But if it is not config when an instance exists >>>>>> because the server created it, then it must be >>>>>> operational state. So it MUST be retrievable, >>>>>> in order to support applications (NETCONF was chartered >>>>>> to get away from screen-scraping). >>>>> Andy, >>>>> >>>>> I agree, it MUST be retrievable. >>>>> >>>>> For Configuration purposes, >>>>> I would prefer to stay with 'everything writable is config' >>>>> and what has been set (by anyone outside the server, not >>>>> as part of operational state or by server) is perforce a >>>>> subset of that, and Netconf has the option to >>>>> retrieve all or the subset. >>>> Here's a proposal: >>>> >>>> Let's make "default" an error for "config false" data. >>>> >>>> This means that operational data values cannot default >>>> to a YANG-specified value. If you want them, you must >>>> emit them. >>>> >>>> This should end the comments about having to read documentation to >>>> find default values. >>>> >>>> It should also clarify the role of default in a YANG module. >>>> >>>> And it should cost almost nothing. >>>> >>>> Thanks, >>>> Phil >>>> _______________________________________________ >>>> 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 mbj@tail-f.com Tue Sep 1 12:58:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C0E3A6F9D for ; Tue, 1 Sep 2009 12:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKree8nuMNyz for ; Tue, 1 Sep 2009 12:58:21 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EC48C3A68A6 for ; Tue, 1 Sep 2009 12:58:20 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 015D961A2C3; Tue, 1 Sep 2009 21:58:00 +0200 (CEST) Date: Tue, 01 Sep 2009 21:58:00 +0200 (CEST) Message-Id: <20090901.215800.167985517.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A9D7BA2.8020803@netconfcentral.com> References: <200909011930.n81JU7WS093379@idle.juniper.net> <4A9D7BA2.8020803@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:58:24 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > The current scheme in YANG allows the server to behave in any of > > the three styles listed in the with-defaults draft. We have > > sufficient flexibility to allow you to work the way you want, and > > to allow others to work the way they work. This is good. > > > > no it does not allow for the 3 current schemes. > That is nonsense. The draft clearly says that > database = leafs + YANG default-stmt leafs. > There is no text then even suggests anything > other than that. I don't understand this. I agree with Phil that the current scheme allows the server to implement any of the 3 modes in the with-defaults ID. The reason it does is that it says: A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an for a or request, MUST be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value. /martin From jmh@joelhalpern.com Tue Sep 1 13:01:02 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997993A6CBE for ; Tue, 1 Sep 2009 13:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ4Zr2u3Xg4k for ; Tue, 1 Sep 2009 13:01:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B434E3A7029 for ; Tue, 1 Sep 2009 13:01:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6B2A74303CB; Tue, 1 Sep 2009 13:01:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id BC8274303AF; Tue, 1 Sep 2009 13:01:06 -0700 (PDT) Message-ID: <4A9D7D82.8030202@joelhalpern.com> Date: Tue, 01 Sep 2009 16:01:06 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <200909011806.n81I6W6M092259@idle.juniper.net> <4A9D7469.7030006@joelhalpern.com> <4A9D794C.3000808@netconfcentral.com> <4A9D7AB2.90006@joelhalpern.com> <4A9D7C9C.7040004@netconfcentral.com> In-Reply-To: <4A9D7C9C.7040004@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:01:02 -0000 We are in agreement. I was not suggesting either of those alternatives. I would agree with you that those alternatives making the spec internally contradictory, and at the very best, confuse the reader. More likely they confuse a lot more and cause non-interoperability. Joel Andy Bierman wrote: > Joel M. Halpern wrote: >> Andy, sorry, I have no idea what you are getting at. >> I was trying to suggest again that having a "config false" node with the >> data, which is reported, would be a way to have the data reported. >> I realize I am repeating myself, and apologize for that. >> I was repeating myself because although when I said it last Phill had >> strongly objected to that approach, it is what he seems to be suggesting >> in the note I was responding to. >> > > > sorry -- I misread what you meant by your comment. > > I cannot live with a solution where a > YANG object that is config=true, > but <*-config> operations do not work. > > Ditto for a solution where > a YANG object that is config=false, > but <*-config> operations do work. > > Maybe that is not what you are talking about either. > > > >> I think that this is somehow related to Phil's proposed new operation, >> which I also did not understand. sounds to me >> like a which happens to target only "config false" nodes. >> >> Yours, >> joel > > Andy > > >> Andy Bierman wrote: >>> Joel M. Halpern wrote: >>>> I have a strong suspicion that we are talking past each other. >>>> >>>> The issue I believe Andy has, and I know I have, is with a "config true" >>>> which is given a value by the system, but where that value is not >>>> reported to a client application either in a regular get or in get with >>>> all defaults. >>>> >>>> If the system is using a value for a "config true" node, >>>> and that value is not reported, and that value is not the model defined >>>> default value, then we have an operability problem. >>>> If some systems report it one way, and some systems report it another >>>> way, then we probably have an interoperability problem. >>>> >>>> From the text below, I would have concluded that you were suggesting >>>> that the value the system is using should appear in a "config false" >>>> node, separate from the "config true" node used to set the value. As I >>>> said to Juergen, I can live with that. >>> I do not understand why, if the >>> data is tagged config=false, it is somehow less >>> potentially useful to the operator. >>> What is the correlation I am missing here? >>> >>> What about the deviations and no-revision-date corner-cases? >>> I thought deterministic behavior across versions, platforms, >>> and vendors was our goal here. I don't understand why >>> the functional requirements for network-related data retrieval >>> established through 2 decades of standards work should be >>> ignored, and the bar should be lowered for NETCONF. >>> >>> In SNMP you can get an exact piece of data (get foo.1.2.3). >>> Not in NETCONF. In SNMP, if foo.1.2.3 exists then you >>> can get its value, otherwise it does not exist. Simple yet powerful. >>> (modulo VACM, of course). >>> >>> >>> However, from your previous >>>> strident responses, I presume that is not what you intended to >>>> communicate. >>>> >>>> Yours, >>>> Joel >>> >>> Andy >>> >>> >>>> Phil Shafer wrote: >>>>> "tom.petch" writes: >>>>>> ----- Original Message ----- >>>>>> From: "Andy Bierman" >>>>>>> I can agree with Phil that 'config' I did not set >>>>>>> is not really config -- if the YANG and with-defaults >>>>>>> draft specify the same thing correctly. >>>>>>> >>>>>>> But if it is not config when an instance exists >>>>>>> because the server created it, then it must be >>>>>>> operational state. So it MUST be retrievable, >>>>>>> in order to support applications (NETCONF was chartered >>>>>>> to get away from screen-scraping). >>>>>> Andy, >>>>>> >>>>>> I agree, it MUST be retrievable. >>>>>> >>>>>> For Configuration purposes, >>>>>> I would prefer to stay with 'everything writable is config' >>>>>> and what has been set (by anyone outside the server, not >>>>>> as part of operational state or by server) is perforce a >>>>>> subset of that, and Netconf has the option to >>>>>> retrieve all or the subset. >>>>> Here's a proposal: >>>>> >>>>> Let's make "default" an error for "config false" data. >>>>> >>>>> This means that operational data values cannot default >>>>> to a YANG-specified value. If you want them, you must >>>>> emit them. >>>>> >>>>> This should end the comments about having to read documentation to >>>>> find default values. >>>>> >>>>> It should also clarify the role of default in a YANG module. >>>>> >>>>> And it should cost almost nothing. >>>>> >>>>> Thanks, >>>>> Phil >>>>> _______________________________________________ >>>>> 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 mbj@tail-f.com Tue Sep 1 13:04:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEE23A68A6 for ; Tue, 1 Sep 2009 13:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0qp+pYrh37c for ; Tue, 1 Sep 2009 13:03:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DD33C3A6CC8 for ; Tue, 1 Sep 2009 13:03:58 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9EAD761A2C3; Tue, 1 Sep 2009 22:04:11 +0200 (CEST) Date: Tue, 01 Sep 2009 22:04:11 +0200 (CEST) Message-Id: <20090901.220411.219341767.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <004201ca2b20$e0b9c7e0$0601a8c0@allison> References: <200909010959.59070.david.partain@ericsson.com> <004201ca2b20$e0b9c7e0$0601a8c0@allison> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:04:00 -0000 "tom.petch" wrote: > ----- Original Message ----- > From: "David Partain" > Sent: Tuesday, September 01, 2009 9:59 AM > > > > There has been significant debate about whether to reopen the question of > > having 'assigned-by system'. See this mail thread - > > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html > > > > The discussion has been in the "agent-default -- new 3rd state" thread (and > > probably elsewhere). > > > > Martin wrote in the message referenced above: "The idea is that if a leaf is > > marked as assigned-by system, then the client MAY choose to not set a value > > for the leaf when its parent instance is created. In this case the system > > will assign a suitable value for the leaf." > > I am unclear. I take it this is created in the data tree but is it as > config or operational state (which affects how it can be retrieved) > and is an instance being created or is this one of those thingies > which seem neither dead nor alive? No magic is supposed to happen here. If the defintion is: leaf uid { type int32; config true; assigned-by system; } I hope it is obvious that we're talking about configuration data? 'assigned-by' and 'config false' cannot be used together -- a client can never create config false data (directly). > This harks back to Phil > differentiating uid from mtu and Joel not seeing the difference. > I am afraid I have yet to see the difference:-( Martin said > 'So "if an instance exists because the server created it" then it *is* > config. ' Um, leaves me none the wiser. > > And what's the parent instance got to do with it? It sounds like > an assumption is built in there (and not the usual case or > non-presence container issues) that I am missing. Extending the example a bit: list user { ... leaf uid { ... assigned-by system; } } We need to make it clear that the 'uid' is not spontanesoulsy created for non-existing users. The 'uid' leaf will be created by the system when a new user is created (its "parent" -- note this is not a term we have used, and we will have to find the right language to describe this). Another example: container foo { presence "..."; leaf bar { ... assigned-by system; } } /foo/bar is created by the system when the client creates /foo. /martin From andy@netconfcentral.com Tue Sep 1 13:13:12 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BACA28C653 for ; Tue, 1 Sep 2009 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyJRkJtPvWD8 for ; Tue, 1 Sep 2009 13:13:11 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 7E96928C857 for ; Tue, 1 Sep 2009 13:12:37 -0700 (PDT) Received: from [68.142.200.221] by n10.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 20:12:43 -0000 Received: from [68.142.201.70] by t9.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 20:12:43 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 20:12:43 -0000 X-Yahoo-Newman-Id: 657086.81861.bm@omp422.mail.mud.yahoo.com Received: (qmail 16249 invoked from network); 1 Sep 2009 20:12:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 20:12:42 -0000 X-YMail-OSG: huxrIzIVM1mmN.ZenmagHAZPjJ1axqsDbUIokYGLWTqhxCCNcwOkT3bfhpy.Oh0fmdZ8paIAPDdg.3NEHTDQmED4PIP17uVKzhZ5gOAKj.TGbqSYPjkX1LtMMJXJcGBeqvwrteN2THqWHH5sVZzwM9Vr9mSnlYLBxYoByaQYInZ5MdiFAOLaLiAHjH4CSKdY5R4NPMFY6PxvQ4hrvO5PNONTvMk36el0qJJfe0IqTOYSorf0E3l4bq2raloH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D804A.2030207@netconfcentral.com> Date: Tue, 01 Sep 2009 13:12:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200909011930.n81JU7WS093379@idle.juniper.net> <4A9D7BA2.8020803@netconfcentral.com> <20090901.215800.167985517.mbj@tail-f.com> In-Reply-To: <20090901.215800.167985517.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:13:12 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> The current scheme in YANG allows the server to behave in any of >>> the three styles listed in the with-defaults draft. We have >>> sufficient flexibility to allow you to work the way you want, and >>> to allow others to work the way they work. This is good. >>> >> no it does not allow for the 3 current schemes. >> That is nonsense. The draft clearly says that >> database = leafs + YANG default-stmt leafs. >> There is no text then even suggests anything >> other than that. > > I don't understand this. I agree with Phil that the current scheme > allows the server to implement any of the 3 modes in the with-defaults > ID. The reason it does is that it says: > > A NETCONF server that replies to a or request MAY > choose not to send the leaf element if its value is the default > value. Thus, a client that receives an for a or > request, MUST be prepared to handle the case that a > leaf node with a default value is not present in the XML. In this > case, the value used by the server is known to be the default value. > > We've been going in circles so much, we must be getting dizzy. 1) this is not even true for YANG-default-stmt values, because of deviations and no-revision-date modules. 2) a server-created leaf that does not contain the YANG-default-stmt value is not a default, so this text is irrelevant wrt/ omitting other server-created instances from operations. That is what is allowed in :explicit mode of the :with-defaults capability. So this assertion that :explicit is somehow covered, even if the server does not implement :with-defaults is false. It is only covered *if* the server implements and advertises the :with-defaults capability. > /martin > > Andy From mbj@tail-f.com Tue Sep 1 13:19:31 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74C128C434 for ; Tue, 1 Sep 2009 13:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Qa78NXktwmX for ; Tue, 1 Sep 2009 13:19:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CAEF028C857 for ; Tue, 1 Sep 2009 13:19:04 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C57B76C4A1; Tue, 1 Sep 2009 22:19:18 +0200 (CEST) Date: Tue, 01 Sep 2009 22:19:18 +0200 (CEST) Message-Id: <20090901.221918.226622597.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <004301ca2b20$e193fb40$0601a8c0@allison> References: <200909011009.16729.david.partain@ericsson.com> <004301ca2b20$e193fb40$0601a8c0@allison> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:19:31 -0000 "tom.petch" wrote: > > 7.6.1. The leaf's default value > > > > The default value of a leaf is the value that the server uses if no > > value has been explicitly set. The usage of the default value > > When are we talking about? In this case, one must read the entire section in order to understand the what, when, and how. If you have a suggestion for some text that explains this better, I am more than happy to include it. > Note we have no terminology for what > is in the data tree, presume instances with values, in which case are > we talking about an instance being created? But then we have no > definition of when an instance is created. With an SNMP background, > this is academic, there is always a 1.3.6.1.2.1.1.1 with a 'value', it is > just a question of being a valid value or not I don't understand this. In SNMP, ifStackStatus.1.4 may or may not exist. You might have to create it. In NETCONF, there are protocol operations that create instances. > but with YANG, we have > not nailed this down, and so some posts have implied that a data node > leaf does not exist in the data tree unless and until eg its ancestor > node becomes part of the data tree Right, the leaf /foo/bar can never exist in the data tree unless /foo exists. > or perhaps when the server, if > it has permission, just decides to create it and ancestor anyway. Sure this can happen; the server can even run a local NETCONF-client script if it wants to. Does that mean it is server created. > And is there a difference, as Lada asked, between doing an > specifying as opposed to 42? I haven't seen that question, but the first one tries to set the 'element' leaf (assuming it is a leaf) to the empty string, and the second to the value 42, so yes, there is a difference. > All this needs nailing down otherwise discussions of default, > assigned by all/user/system.... can end up with each person having > a different view. > > And 'explicitly set'; to me, that MUST be set by anyone, CLI, SNMP, > Netconf, .... It is no use having a Netconf/YANG that pretends that > nothing else in the world exists as far as configuration management > is concerned and so can be ignored. Absolutely. > Again, an issue touched on but not > resolved. I am not sure what sort of text you expect, if any. /martin From mbj@tail-f.com Tue Sep 1 13:28:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8877828C52F for ; Tue, 1 Sep 2009 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gARVwLI49ook for ; Tue, 1 Sep 2009 13:28:37 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7F1FC3A6992 for ; Tue, 1 Sep 2009 13:28:37 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 49B4076C4A1; Tue, 1 Sep 2009 22:28:51 +0200 (CEST) Date: Tue, 01 Sep 2009 22:28:50 +0200 (CEST) Message-Id: <20090901.222850.210872069.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A9D804A.2030207@netconfcentral.com> References: <4A9D7BA2.8020803@netconfcentral.com> <20090901.215800.167985517.mbj@tail-f.com> <4A9D804A.2030207@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:28:38 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Phil Shafer wrote: > >>> The current scheme in YANG allows the server to behave in any of > >>> the three styles listed in the with-defaults draft. We have > >>> sufficient flexibility to allow you to work the way you want, and > >>> to allow others to work the way they work. This is good. > >>> > >> no it does not allow for the 3 current schemes. > >> That is nonsense. The draft clearly says that > >> database = leafs + YANG default-stmt leafs. > >> There is no text then even suggests anything > >> other than that. > > > > I don't understand this. I agree with Phil that the current scheme > > allows the server to implement any of the 3 modes in the with-defaults > > ID. The reason it does is that it says: > > > > A NETCONF server that replies to a or request MAY > > choose not to send the leaf element if its value is the default > > value. Thus, a client that receives an for a or > > request, MUST be prepared to handle the case that a > > leaf node with a default value is not present in the XML. In this > > case, the value used by the server is known to be the default value. > > > > > > We've been going in circles so much, we must be getting dizzy. > > 1) this is not even true for YANG-default-stmt values, > because of deviations and no-revision-date modules. A deviation may change the leaf's default value, so the text still applies. (this may or may not be a good idea, but that's a sepatate issue). no-revision-date modules might be an issue, but I believe it can be solved (see Phil's email). > 2) a server-created leaf that does not contain the > YANG-default-stmt value is not a default Agreed. > so this text > is irrelevant wrt/ omitting other server-created instances > from operations. That is what is allowed in :explicit > mode of the :with-defaults capability. Is it? If so, the :with-defaults capability needs to be fixed. Wait - you and I at least already agreed that it should be fixed. > So this assertion > that :explicit is somehow covered, even if the server > does not implement :with-defaults is false. It is only > covered *if* the server implements and advertises the > :with-defaults capability. Here I disagree. If the server does not implement :with-defaults, the client knows what it means if a leaf with a default statement is not present in the reply. /martin From phil@juniper.net Tue Sep 1 13:34:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05E83A6A53 for ; Tue, 1 Sep 2009 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdPfizyAWyrS for ; Tue, 1 Sep 2009 13:34:10 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 3D8AA3A6804 for ; Tue, 1 Sep 2009 13:34:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSp2FS7omVRtmvCsAFy7mr65VV7E/gbtZ@postini.com; Tue, 01 Sep 2009 13:34:25 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 13:30:37 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:30:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:30:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:30:36 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81KUWd24103; Tue, 1 Sep 2009 13:30:32 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81KIRof094517; Tue, 1 Sep 2009 20:18:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909012018.n81KIRof094517@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4A9D7469.7030006@joelhalpern.com> Date: Tue, 1 Sep 2009 16:18:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 20:30:36.0178 (UTC) FILETIME=[0FD32720:01CA2B43] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:34:12 -0000 "Joel M. Halpern" writes: >The issue I believe Andy has, and I know I have, is with a "config true" >which is given a value by the system, but where that value is not >reported to a client application either in a regular get or in get with >all defaults. I believe this is a red herring. There are no such nodes. If you believe such nodes exist, then we are truly talking past each other. I will try in this email to describe why I believe this, and I hope at the end you will agree. >If the system is using a value for a "config true" node, >and that value is not reported, and that value is not the model defined >default value, then we have an operability problem. >If some systems report it one way, and some systems report it another >way, then we probably have an interoperability problem. The delicate terms is "the system is using a value". This is an ambiguous term that may be the source of the trouble. So let's start with some precise terminology: "assigned-by system" (ABS): a behavior where the system will, at validation time, assign values in the configuration database for leafs which are not given values. If values were given before validation time, the system will not assign new values, but will honor these existing values. "configuration default value" (CDV): the default value used for configuration data. If a list instance is created in the configuration database and the value for a leaf is not provided, then the CDV is the value which the system will use internally. This means that the behaviour of the running system using that CDV as the operational value is identical to the behaviour if that leaf had been explicitly configured with that value. The CDV value must be a fixed value. "operational default value" (ODV): the default value used for operational data. This is the value used by the running system if a value was not configured. It may not be fixed or easily described. The value may be dynamic or even unpublished. With these terms, we make the following rules: (a) the YANG default statement can be used to provide a CDV. (b) the YANG default statement cannot provide defaults for ODVs. (c) the YANG default statement cannot provide defaults for ABS leafs. (d) a server MAY choose to not send a leaf element if it is a configuration leaf ('config true') and the value of the leaf is the default value. (e) ODVs MUST be sent for operational data, since the default statement applies only to configuration data. In effect, operational data has no default values. (f) ABS data is _real_ configuration data, since it appears in the configuration database and can be manipulated with the operation NETCONF/YANG operations. So to address your concerns: >The issue I believe Andy has, and I know I have, is with a "config true" >which is given a value by the system, but where that value is not >reported to a client application either in a regular get or in get with >all defaults. If "given a value by the system" means ABS, then there are no such nodes. When the system assigns a value to an ABS leaf, that leaf and value are now part of the configuration database, and that value will be returned to any client application (with the proviso that (d) allows the server to not send the CDV). If by "given a value by the system" you really mean ODVs, where the system is used a value for a leaf that was not configured, then the ODV will be sent, since the server MUST sent ODVs. >If the system is using a value for a "config true" node, >and that value is not reported, and that value is not the model defined >default value, then we have an operability problem. >If some systems report it one way, and some systems report it another >way, then we probably have an interoperability problem. If we are talking configuration data, then any client can retrieve any configuration data that has been configured (with the proviso above). Consider an example: module users { container users-top { list user { key name; leaf name { type string; } leaf password { type string; default "*"; } leaf uid { type uint32; assigned-by system; } leaf full-name { type string; } leaf last-login { type data-time; } } } } If I make a user like: ... phil then at validate time, the system will assign an appropriate "uid" value. It will not assign a password leaf in the database, but when an entry is made for the user in /etc/master.passwd, the line will start with "phil:*:". If I get this user, I'll see: phil 2005 If I do a , I may see the element with an appropriate value. I will not see a element, since there is no appropriate value. So I'm hoping you can agree that there is no ghost configuration data. Thanks, Phil From phil@juniper.net Tue Sep 1 13:41:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0442A3A702C for ; Tue, 1 Sep 2009 13:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mmib0D+tci2t for ; Tue, 1 Sep 2009 13:41:09 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 964A63A6867 for ; Tue, 1 Sep 2009 13:41:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSp2G8rPeJEJNNMlz1nhKCvKWn4N+r5ou@postini.com; Tue, 01 Sep 2009 13:41:24 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 13:38:22 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:38:22 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:38:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:38:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81KcKd28111; Tue, 1 Sep 2009 13:38:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81KQGve094633; Tue, 1 Sep 2009 20:26:16 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909012026.n81KQGve094633@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4A9D7AB2.90006@joelhalpern.com> Date: Tue, 1 Sep 2009 16:26:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 20:38:21.0190 (UTC) FILETIME=[24FE5A60:01CA2B44] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:41:11 -0000 "Joel M. Halpern" writes: >I was repeating myself because although when I said it last Phill had >strongly objected to that approach, it is what he seems to be suggesting >in the note I was responding to. I strongly oppose mixing default values into the configuration database. If I get configuration data, I do not want default values. >I think that this is somehow related to Phil's proposed new operation, >which I also did not understand. sounds to me >like a which happens to target only "config false" nodes. No, it's a module-specific get operation, that returns config false nodes in addition to config true ones. The interesting bits are how such a scheme would describe the rules or constraints which are true for config data, but do not hold for operational data. For example, the duplex may be "full", "half", or "auto" for config, but for operational data, would be "full", "half", and "down". The strong constraint of config data, which we need to construct config data that plays by the model's rules, are less important for operational data. How do we model the interaction and overlap between operational and configuration data? So far, we've really only worried about config data, since that's the greenfield for NETCONF/YANG. Thanks, Phil From phil@juniper.net Tue Sep 1 13:43:46 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5803A67F9 for ; Tue, 1 Sep 2009 13:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9Ol5K7Dz9st for ; Tue, 1 Sep 2009 13:43:45 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id EFCB93A6912 for ; Tue, 1 Sep 2009 13:43:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSp2HjRrL9lIbd7zSmc/uRieSfoq+L0bB@postini.com; Tue, 01 Sep 2009 13:43:59 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 13:41:01 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:41:01 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:41:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:41:00 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81Kexd29873; Tue, 1 Sep 2009 13:40:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81KStRN094661; Tue, 1 Sep 2009 20:28:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909012028.n81KStRN094661@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9D7C9C.7040004@netconfcentral.com> Date: Tue, 1 Sep 2009 16:28:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 20:41:00.0549 (UTC) FILETIME=[83FA9B50:01CA2B44] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:43:46 -0000 Andy Bierman writes: >I cannot live with a solution where a >YANG object that is config=true, >but <*-config> operations do not work. > >Ditto for a solution where >a YANG object that is config=false, >but <*-config> operations do work. I don't believe anyone is suggesting either of these concepts. Thanks, Phil From jmh@joelhalpern.com Tue Sep 1 13:44:45 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CAA28C857 for ; Tue, 1 Sep 2009 13:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWg09IWsjYfy for ; Tue, 1 Sep 2009 13:44:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AF77F28C8B6 for ; Tue, 1 Sep 2009 13:44:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5218C4303D3; Tue, 1 Sep 2009 13:44:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9A1F54303C2; Tue, 1 Sep 2009 13:44:24 -0700 (PDT) Message-ID: <4A9D87A7.6050606@joelhalpern.com> Date: Tue, 01 Sep 2009 16:44:23 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200909012018.n81KIRof094517@idle.juniper.net> In-Reply-To: <200909012018.n81KIRof094517@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:44:46 -0000 Well, I may be missing something, and others may disagree, but this looks like progress to me. They key for me has always been how ODV (Operational Default Values as you describe them) show up. I apparently misunderstood you as not wanting them reported in any of any kind. As long as they show up somewhere that is reasonably describable, I am happy. To drive this down a level of detail, if we have a config variable ifMtu, and if in the absence of configuration it uses an ODV, how does the client (management system) get that ODV? (I can think of several possible answers, but I think we need to pick one.) Yours, Joel PS: To avoid the temptation to confuse them with defaults, would it make sense to render ODV as Operationally Determined Value, i.e. the device operation determined a value due to the absence of the configuration? Phil Shafer wrote: > "Joel M. Halpern" writes: >> The issue I believe Andy has, and I know I have, is with a "config true" >> which is given a value by the system, but where that value is not >> reported to a client application either in a regular get or in get with >> all defaults. > > I believe this is a red herring. There are no such nodes. If you > believe such nodes exist, then we are truly talking past each other. > I will try in this email to describe why I believe this, and I hope > at the end you will agree. > >> If the system is using a value for a "config true" node, >> and that value is not reported, and that value is not the model defined >> default value, then we have an operability problem. >> If some systems report it one way, and some systems report it another >> way, then we probably have an interoperability problem. > > The delicate terms is "the system is using a value". This is an > ambiguous term that may be the source of the trouble. So let's > start with some precise terminology: > > "assigned-by system" (ABS): a behavior where the system will, > at validation time, assign values in the configuration database > for leafs which are not given values. If values were given before > validation time, the system will not assign new values, but will > honor these existing values. > > "configuration default value" (CDV): the default value used for > configuration data. If a list instance is created in the > configuration database and the value for a leaf is not provided, > then the CDV is the value which the system will use internally. > This means that the behaviour of the running system using that > CDV as the operational value is identical to the behaviour if > that leaf had been explicitly configured with that value. The > CDV value must be a fixed value. > > "operational default value" (ODV): the default value used for > operational data. This is the value used by the running > system if a value was not configured. It may not be fixed or > easily described. The value may be dynamic or even unpublished. > > With these terms, we make the following rules: > > (a) the YANG default statement can be used to provide a CDV. > (b) the YANG default statement cannot provide defaults for ODVs. > (c) the YANG default statement cannot provide defaults for ABS leafs. > (d) a server MAY choose to not send a leaf element if > it is a configuration leaf ('config true') and the > value of the leaf is the default value. > (e) ODVs MUST be sent for operational data, since the default > statement applies only to configuration data. In effect, > operational data has no default values. > (f) ABS data is _real_ configuration data, since it appears > in the configuration database and can be manipulated with > the operation NETCONF/YANG operations. > > So to address your concerns: > >> The issue I believe Andy has, and I know I have, is with a "config true" >> which is given a value by the system, but where that value is not >> reported to a client application either in a regular get or in get with >> all defaults. > > If "given a value by the system" means ABS, then there are no such > nodes. When the system assigns a value to an ABS leaf, that leaf > and value are now part of the configuration database, and that value > will be returned to any client application (with the proviso that > (d) allows the server to not send the CDV). > > If by "given a value by the system" you really mean ODVs, where the > system is used a value for a leaf that was not configured, then the > ODV will be sent, since the server MUST sent ODVs. > >> If the system is using a value for a "config true" node, >> and that value is not reported, and that value is not the model defined >> default value, then we have an operability problem. >> If some systems report it one way, and some systems report it another >> way, then we probably have an interoperability problem. > > If we are talking configuration data, then any client can retrieve > any configuration data that has been configured (with the proviso > above). > > Consider an example: > > module users { > container users-top { > list user { > key name; > leaf name { type string; } > leaf password { > type string; > default "*"; > } > leaf uid { > type uint32; > assigned-by system; > } > leaf full-name { > type string; > } > leaf last-login { > type data-time; > } > } > } > } > > If I make a user like: > > > ... > > > > phil > > > > > > then at validate time, the system will assign an appropriate "uid" > value. It will not assign a password leaf in the database, but > when an entry is made for the user in /etc/master.passwd, the line > will start with "phil:*:". > > If I get this user, I'll see: > > > > phil > 2005 > > > > If I do a , I may see the element > with an appropriate value. I will not see a element, > since there is no appropriate value. > > So I'm hoping you can agree that there is no ghost configuration > data. > > Thanks, > Phil > From jmh@joelhalpern.com Tue Sep 1 13:54:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D38E28CA13 for ; Tue, 1 Sep 2009 13:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgAMtTo25qj8 for ; Tue, 1 Sep 2009 13:54:24 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 29E9528CA26 for ; Tue, 1 Sep 2009 13:51:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 58FE74303D4; Tue, 1 Sep 2009 13:51:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B2D864303CB; Tue, 1 Sep 2009 13:51:02 -0700 (PDT) Message-ID: <4A9D8936.5060707@joelhalpern.com> Date: Tue, 01 Sep 2009 16:51:02 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200909012026.n81KQGve094633@idle.juniper.net> In-Reply-To: <200909012026.n81KQGve094633@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:54:35 -0000 Based on the other note I responded to, I misunderstood you. I apologize, and lets try to sort out this idea. I must have missed some subtlety in the netconf spec. I am not sure why there is a need for a module specific operation, or how this operation differs from which is defined to return all running configuration and device state information. (I tend to presume that ODVs, and other operational information, appear only in the running config?) I am confused by your question about different data constraints. presumably, the config variable and the operational state variable are different. Operation state variables are "config false", will tend to have few or no constraints (MUST statements), and will have value sets that cover the operationally availble values. Yours, Joel Phil Shafer wrote: > "Joel M. Halpern" writes: >> I was repeating myself because although when I said it last Phill had >> strongly objected to that approach, it is what he seems to be suggesting >> in the note I was responding to. > > I strongly oppose mixing default values into the configuration > database. If I get configuration data, I do not want default values. > >> I think that this is somehow related to Phil's proposed new operation, >> which I also did not understand. sounds to me >> like a which happens to target only "config false" nodes. > > No, it's a module-specific get operation, that returns config false > nodes in addition to config true ones. > > The interesting bits are how such a scheme would describe the rules > or constraints which are true for config data, but do not hold for > operational data. For example, the duplex may be "full", "half", > or "auto" for config, but for operational data, would be "full", > "half", and "down". > > The strong constraint of config data, which we need to construct > config data that plays by the model's rules, are less important for > operational data. How do we model the interaction and overlap > between operational and configuration data? So far, we've really > only worried about config data, since that's the greenfield for > NETCONF/YANG. > > Thanks, > Phil > From phil@juniper.net Tue Sep 1 13:55:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DAA3A6B9C for ; Tue, 1 Sep 2009 13:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIefiKKALgjo for ; Tue, 1 Sep 2009 13:55:47 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 120C628C9DF for ; Tue, 1 Sep 2009 13:55:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSp2KVvHYBkx/6jHhQw2kIpSevM3XLMGm@postini.com; Tue, 01 Sep 2009 13:55:53 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 13:52:47 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:52:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:52:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 13:52:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81Kqjd34995; Tue, 1 Sep 2009 13:52:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81KefeE094806; Tue, 1 Sep 2009 20:40:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909012040.n81KefeE094806@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9D804A.2030207@netconfcentral.com> Date: Tue, 1 Sep 2009 16:40:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 20:52:46.0310 (UTC) FILETIME=[28A53060:01CA2B46] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:55:48 -0000 Andy Bierman writes: >We've been going in circles so much, we must be getting dizzy. We're going in circles, because you keep repeating the same false statements. Please read the text Martin and I keep posting. >1) this is not even true for YANG-default-stmt values, > because of deviations and no-revision-date modules. A deviation is a claim from the device that it is behaving in a non-standard way. It is making an attempt to tell you how broken it is, but you cannot claim that because we have a mechanism for a device to announce this broken-ness, we lack a standard way to behave. >2) a server-created leaf that does not contain the > YANG-default-stmt value is not a default, so this text > is irrelevant wrt/ omitting other server-created instances > from operations. An ABS leaf is not a default, and such a leaf cannot have a default statement. Once the leaf is created, it is normal config data, but since there's no default value, the server MUST emit the value for that leaf. >That is what is allowed in :explicit > mode of the :with-defaults capability. So this assertion > that :explicit is somehow covered, even if the server > does not implement :with-defaults is false. It is only > covered *if* the server implements and advertises the > :with-defaults capability. This is simply not true. YANG allows the explicit behavour in a way that it unlinked to with-defaults. In addition, this issue is unrelated to "assigned-by system". The YANG spec says that if the value is the default value, the server may choose to not emit it. The "trim" behavior avoids emitting leafs when the value is the default value. The explcit behavior emits values if the value was set by the user. Both are allowed under the text that Martin and I continue to point you to. Please read it and let's stop circling this particular rat hole. Thanks, Phil From andy@netconfcentral.com Tue Sep 1 14:00:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DE63A6AC6 for ; Tue, 1 Sep 2009 14:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8y+Nkzv8YFV for ; Tue, 1 Sep 2009 14:00:39 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 305943A68A1 for ; Tue, 1 Sep 2009 14:00:39 -0700 (PDT) Received: (qmail 40778 invoked from network); 1 Sep 2009 21:00:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 21:00:50 -0000 X-YMail-OSG: 8E1dAy4VM1mYrUcSjyf3eQpAsAN80n7lehDlonQ2GqSK8YU8DEfqZUYrLjNKW3uMaZwkQacTwfJtr78xFmQzmHuGmHd1iQ0PPPrHEUikUUiGhwkQQ8yR3GPb3DUA7wyiBNQkEG0ZnooDNJe7.eAIzODMdcZn4SIzfZTV9K.lCSFr_C0GsyZWxBu7uNcojyN2NVWjkTCaa7zBIysXnHI_XhidKirWKTjSU5C_X8R5VtZs8ZJNUT.tsdxnJbD2hZBrt.jiNS0ekqH4auDS X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D8B92.5060407@netconfcentral.com> Date: Tue, 01 Sep 2009 14:01:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909012018.n81KIRof094517@idle.juniper.net> In-Reply-To: <200909012018.n81KIRof094517@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:00:40 -0000 Phil Shafer wrote: > "Joel M. Halpern" writes: >> The issue I believe Andy has, and I know I have, is with a "config true" >> which is given a value by the system, but where that value is not >> reported to a client application either in a regular get or in get with >> all defaults. > > I believe this is a red herring. There are no such nodes. If you > believe such nodes exist, then we are truly talking past each other. > I will try in this email to describe why I believe this, and I hope > at the end you will agree. > >> If the system is using a value for a "config true" node, >> and that value is not reported, and that value is not the model defined >> default value, then we have an operability problem. >> If some systems report it one way, and some systems report it another >> way, then we probably have an interoperability problem. > > The delicate terms is "the system is using a value". This is an > ambiguous term that may be the source of the trouble. So let's > start with some precise terminology: > > "assigned-by system" (ABS): a behavior where the system will, > at validation time, assign values in the configuration database > for leafs which are not given values. If values were given before > validation time, the system will not assign new values, but will > honor these existing values. > > "configuration default value" (CDV): the default value used for > configuration data. If a list instance is created in the > configuration database and the value for a leaf is not provided, > then the CDV is the value which the system will use internally. > This means that the behaviour of the running system using that > CDV as the operational value is identical to the behaviour if > that leaf had been explicitly configured with that value. The > CDV value must be a fixed value. > > "operational default value" (ODV): the default value used for > operational data. This is the value used by the running > system if a value was not configured. It may not be fixed or > easily described. The value may be dynamic or even unpublished. > > With these terms, we make the following rules: > > (a) the YANG default statement can be used to provide a CDV. > (b) the YANG default statement cannot provide defaults for ODVs. why is there any correlation between the YANG config-stmt and the YANG default-stmt? This is the first I've heard that. > (c) the YANG default statement cannot provide defaults for ABS leafs. > (d) a server MAY choose to not send a leaf element if > it is a configuration leaf ('config true') and the > value of the leaf is the default value. what does config=true have to do with it? does (c) + (d) somehow == "the server can omit any leaf it set instead of the client"? If not, no problem. If yes, big problem. If the server set it, then it isn't 'explicitly set'. That seems obvious. But that is precisely what the 'explicit' mode allows to be filtered out. So please explain how you reach the conclusion, that filtering out everything except the explicitly set leafs somehow is covered by the YANG draft text. > (e) ODVs MUST be sent for operational data, since the default > statement applies only to configuration data. In effect, > operational data has no default values. this is not what YANG defines for a default+config=false. I prefer what is already in the spec. > Thanks, > Phil Andy From andy@netconfcentral.com Tue Sep 1 14:02:04 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAB33A6A60 for ; Tue, 1 Sep 2009 14:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWYwMW-cfMwx for ; Tue, 1 Sep 2009 14:02:03 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 3862B3A6C17 for ; Tue, 1 Sep 2009 14:01:54 -0700 (PDT) Received: (qmail 89654 invoked from network); 1 Sep 2009 21:02:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 21:02:06 -0000 X-YMail-OSG: cqLbi5wVM1m6GSoPbnZFr74Id077pnpMnt9LWcFH0D2VrAxhaGIjYrylvFCJ3IEMyuAD0jkrTvQNzIOAdEkCWjuqqh6rsFZ1ryeSzzz6j3puMsklPXxWMYwsf5.1bBwKj7IdVktEPXtWW4j.2AHY1uD3PUPeEaqETO_wyI7cV3DqDxWGdzlaSexU40oAHLeE19K8AaXGTiwklUVfUfsOVmzFe96H5WHCVULSjpvWgnmOnC_mMCzD.mC71KS_m8bw5V0JI8_mYdR7.o9L_KKMQik39UnSF_ICEa7bPy4P9tw3NOmphBgaKFXi7mNlcJ5XIosM7_HAyF86ag-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D8BDE.1030505@netconfcentral.com> Date: Tue, 01 Sep 2009 14:02:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A9D7BA2.8020803@netconfcentral.com> <20090901.215800.167985517.mbj@tail-f.com> <4A9D804A.2030207@netconfcentral.com> <20090901.222850.210872069.mbj@tail-f.com> In-Reply-To: <20090901.222850.210872069.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of default X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:02:04 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Phil Shafer wrote: >>>>> The current scheme in YANG allows the server to behave in any of >>>>> the three styles listed in the with-defaults draft. We have >>>>> sufficient flexibility to allow you to work the way you want, and >>>>> to allow others to work the way they work. This is good. >>>>> >>>> no it does not allow for the 3 current schemes. >>>> That is nonsense. The draft clearly says that >>>> database = leafs + YANG default-stmt leafs. >>>> There is no text then even suggests anything >>>> other than that. >>> I don't understand this. I agree with Phil that the current scheme >>> allows the server to implement any of the 3 modes in the with-defaults >>> ID. The reason it does is that it says: >>> >>> A NETCONF server that replies to a or request MAY >>> choose not to send the leaf element if its value is the default >>> value. Thus, a client that receives an for a or >>> request, MUST be prepared to handle the case that a >>> leaf node with a default value is not present in the XML. In this >>> case, the value used by the server is known to be the default value. >>> >>> >> We've been going in circles so much, we must be getting dizzy. >> >> 1) this is not even true for YANG-default-stmt values, >> because of deviations and no-revision-date modules. > > A deviation may change the leaf's default value, so the text still > applies. (this may or may not be a good idea, but that's a sepatate > issue). > > no-revision-date modules might be an issue, but I believe it can be > solved (see Phil's email). > > >> 2) a server-created leaf that does not contain the >> YANG-default-stmt value is not a default > > Agreed. > >> so this text >> is irrelevant wrt/ omitting other server-created instances >> from operations. That is what is allowed in :explicit >> mode of the :with-defaults capability. > > Is it? If so, the :with-defaults capability needs to be fixed. Wait > - you and I at least already agreed that it should be fixed. > >> So this assertion >> that :explicit is somehow covered, even if the server >> does not implement :with-defaults is false. It is only >> covered *if* the server implements and advertises the >> :with-defaults capability. > > Here I disagree. If the server does not implement :with-defaults, the > client knows what it means if a leaf with a default statement is not > present in the reply. > > There is no disagreement about leafs that contain the YANG default statement value. Move on. As long as the server does not omit any leaf instance that is not the YANG default statement value, there is no problem. Right? > /martin > Andy From jmh@joelhalpern.com Tue Sep 1 14:05:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6103A6A08 for ; Tue, 1 Sep 2009 14:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia3WaRU25Pbh for ; Tue, 1 Sep 2009 14:04:59 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D16BE3A69AE for ; Tue, 1 Sep 2009 14:04:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4C3724303D0; Tue, 1 Sep 2009 14:05:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AD2F64303C4; Tue, 1 Sep 2009 14:05:13 -0700 (PDT) Message-ID: <4A9D8C87.7060707@joelhalpern.com> Date: Tue, 01 Sep 2009 17:05:11 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <200909012018.n81KIRof094517@idle.juniper.net> <4A9D8B92.5060407@netconfcentral.com> In-Reply-To: <4A9D8B92.5060407@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:05:00 -0000 ? You seem to be asking for "default value" statements to be allowed on "config false" nodes. Why? That is either a meaningless use of default, or it describes a constant node. I suppose that there are some corner cases where a constant node might be useful, but it is quite a stretch. I hope I have once again misunderstood. Yours, Joel Andy Bierman wrote: ... > this is not what YANG defines for a default+config=false. > I prefer what is already in the spec. > > >> Thanks, >> Phil > > Andy > From andy@netconfcentral.com Tue Sep 1 14:09:00 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6603A6C53 for ; Tue, 1 Sep 2009 14:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9cnVgCjYYq6 for ; Tue, 1 Sep 2009 14:09:00 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 1A7103A6BDE for ; Tue, 1 Sep 2009 14:09:00 -0700 (PDT) Received: (qmail 62155 invoked from network); 1 Sep 2009 21:09:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 21:09:11 -0000 X-YMail-OSG: pwAeSU0VM1mJalDS4pEaiAyOUbiMr7_uU0eEkeVPv6fR6BhWy34zoy8K.xNS21kOcy.pNYmWTJwIRfXfch4Z1h8JzDMWVtIPlCiQKAsYRC7MTULKd_0mKY4Pi0HndFspl5rsaPGjut7XD8WRKd5yf9nIVMl7CPXpyBkP.YUmwhgkND8Ia.wmphjtx62gxpy71QWILqpq07Qwjy5FfD5w_avf7jENIk1cLCzfI6qprrPINyYIjX2_I7jgOrm3B7vidlCEfovGUQib_S1t X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D8D86.7090106@netconfcentral.com> Date: Tue, 01 Sep 2009 14:09:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200909012018.n81KIRof094517@idle.juniper.net> <4A9D8B92.5060407@netconfcentral.com> <4A9D8C87.7060707@joelhalpern.com> In-Reply-To: <4A9D8C87.7060707@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:09:01 -0000 Joel M. Halpern wrote: > ? You seem to be asking for "default value" statements to be allowed on > "config false" nodes. Why? That is either a meaningless use of > default, or it describes a constant node. I suppose that there are some > corner cases where a constant node might be useful, but it is quite a > stretch. > you are right. I sometimes confuse old SNMP days where DEFVAL was not binding, and for some read-only state objects, was relevant. never mind... > I hope I have once again misunderstood. > Yours, > Joel > Andy From andy@netconfcentral.com Tue Sep 1 14:29:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC7D28C406 for ; Tue, 1 Sep 2009 14:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICyWgGxcpJ7z for ; Tue, 1 Sep 2009 14:29:36 -0700 (PDT) Received: from n9a.bullet.mail.mud.yahoo.com (n9a.bullet.mail.mud.yahoo.com [209.191.87.108]) by core3.amsl.com (Postfix) with SMTP id 69DCF28C73A for ; Tue, 1 Sep 2009 14:28:24 -0700 (PDT) Received: from [68.142.200.227] by n9.bullet.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 21:28:28 -0000 Received: from [68.142.201.243] by t8.bullet.mud.yahoo.com with NNFMP; 01 Sep 2009 21:28:28 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 01 Sep 2009 21:28:28 -0000 X-Yahoo-Newman-Id: 42583.3855.bm@omp404.mail.mud.yahoo.com Received: (qmail 32739 invoked from network); 1 Sep 2009 21:28:27 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 1 Sep 2009 21:28:27 -0000 X-YMail-OSG: MBtB984VM1mTGQ1V77g2boIqYbUleRpXKa3vPOafm3cAD8KgnGM1515Rv5GYEfYS7X88JHrhkg0AUDUNL.emNjpnxjl_q8aci1CBRCmMPu5pvn.BrQZq3gbpnlGeqnGkD6B8BvZGJ__D69CcFGbsj.Iz81HfIQMLGoTwdRBE.LQj2XUzl2iABn36fqdroXyU9k_CamdnaZ3vENc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D920B.30604@netconfcentral.com> Date: Tue, 01 Sep 2009 14:28:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200909012018.n81KIRof094517@idle.juniper.net> <4A9D8B92.5060407@netconfcentral.com> <4A9D8C87.7060707@joelhalpern.com> <4A9D8D86.7090106@netconfcentral.com> In-Reply-To: <4A9D8D86.7090106@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:29:37 -0000 Andy Bierman wrote: > Joel M. Halpern wrote: >> ? You seem to be asking for "default value" statements to be allowed on >> "config false" nodes. Why? That is either a meaningless use of >> default, or it describes a constant node. I suppose that there are some >> corner cases where a constant node might be useful, but it is quite a >> stretch. >> > > you are right. > > I sometimes confuse old SNMP days > where DEFVAL was not binding, and for > some read-only state objects, was relevant. > > never mind... > > wait a minute... I was thinking that default was the value that applied if the server does not return it, but if the server returned a value, it could be different than the default. leaf operStatus { config false; type enumeration { enum normal; // followed by lots of abnormal status enums } default normal; } In this case, it is really useful to omit all the status leafs that have a value of 'normal'. But default is not defined that way now. However, the same justification for omitting config leafs applies to state leafs. >> I hope I have once again misunderstood. >> Yours, >> Joel >> > > Andy Andy From phil@juniper.net Tue Sep 1 14:30:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24303A70AA for ; Tue, 1 Sep 2009 14:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiWDTQWvRH2n for ; Tue, 1 Sep 2009 14:30:47 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id CE0063A6F94 for ; Tue, 1 Sep 2009 14:30:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSp2SevXxSxzAVJURZJtAxgLxYeyp7SSd@postini.com; Tue, 01 Sep 2009 14:31:01 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 14:28:16 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 14:28:16 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 14:28:16 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 14:28:15 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n81LSFd53284; Tue, 1 Sep 2009 14:28:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n81LGAKh095413; Tue, 1 Sep 2009 21:16:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909012116.n81LGAKh095413@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9D8B92.5060407@netconfcentral.com> Date: Tue, 1 Sep 2009 17:16:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 Sep 2009 21:28:15.0876 (UTC) FILETIME=[1DF72C40:01CA2B4B] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:30:48 -0000 Andy Bierman writes: >If the server set it, then it isn't 'explicitly set'. >That seems obvious. Nope, if the server set the value for an ABS leaf, then that value is real config data and must be treated as such. YANG does not allow the server to not emit configuration data, unless the value is the default value. Since ABS leafs should not have default values, there is no overlap. ABS leafs are config data, and config data should be emitted. If the term "explicit" is confusing to you, please suggest a new name to use in the with-defaults draft. >But that is precisely what the 'explicit' mode allows to be filtered out. >So please explain how you reach the conclusion, that >filtering out everything except the explicitly set leafs >somehow is covered by the YANG draft text. If a leaf is created in the configuration database, the server can always emit it. Either the leaf will have the CDV (which YANG allows the server to emit), or the leaf will have a non-CDV (which the server MUST emit). If the leaf was not created in the database, then it has no value. YANG allows the server to emit the default value, but does not require it. So if the leaf "foo" has a default of "3", and a client sets foo to 3, then a server can still emit the value "3". This is the "explicit" behavior, where the server emits values that the user has set, without caring whether those values are the CDV. HTH.... Thanks, Phil From andy@netconfcentral.com Tue Sep 1 14:54:54 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488D63A70A4 for ; Tue, 1 Sep 2009 14:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0MdqzC1OxGZ for ; Tue, 1 Sep 2009 14:54:53 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 05C073A6A09 for ; Tue, 1 Sep 2009 14:54:52 -0700 (PDT) Received: (qmail 11045 invoked from network); 1 Sep 2009 21:55:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 21:55:04 -0000 X-YMail-OSG: u63yn48VM1mQgP5xd63iAaZjmOYcg5UF0kGi0FB8QwDygP2H5IqYiqlen4B4h3oAGk5o5v4gvPOPfyl9WSWIkRjuG7p4lo5td8dVqmjBxOxdyfZEnSKliuGZu2pwSdIeaDbuQhfWZ53qP3U_wLiOAyEP4060yXy3jCYjsCZGIe2CqGxcP8t_7oZNomxZB.mdSr9yrPyMl5asJ4aW1iAwn7Gz9.ffJoI2iP6dbhU_bsgXTsQ6yJ3bMubHJ6TmzQsJ0ggOlH60TBt8k_bq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D9848.3030703@netconfcentral.com> Date: Tue, 01 Sep 2009 14:55:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909012116.n81LGAKh095413@idle.juniper.net> In-Reply-To: <200909012116.n81LGAKh095413@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:54:54 -0000 Phil Shafer wrote: > Andy Bierman writes: >> If the server set it, then it isn't 'explicitly set'. >> That seems obvious. > > Nope, if the server set the value for an ABS leaf, then that value > is real config data and must be treated as such. YANG does not > allow the server to not emit configuration data, unless the value > is the default value. Since ABS leafs should not have default > values, there is no overlap. ABS leafs are config data, and > config data should be emitted. So an ABS leaf will always be retrievable on every server because it does not have the YANG default value. > > If the term "explicit" is confusing to you, please suggest a new > name to use in the with-defaults draft. Then with-defaults needs a lot of fine-tuning, because it just says: o report-all: All default data is always reported. o trim: Values are not reported if they match the default. o explicit: Report values if they are explicitly set. For state data this has the same effect as report-all The 3rd bullet is clearly wrong, because 'explicitly set' is never defined, and you 'set by client or startup' is not what it means anyway. It really means o explicit: Report all leaf values, including those which are explicitly set, even if they are equal to the default value. For state data this has the same effect as report-all. Seems like for all data it has the same effect as 'report-all'. What is filtered-out? Leafs that have no instances? We know that. > >> But that is precisely what the 'explicit' mode allows to be filtered out. >> So please explain how you reach the conclusion, that >> filtering out everything except the explicitly set leafs >> somehow is covered by the YANG draft text. > > If a leaf is created in the configuration database, the server can > always emit it. Either the leaf will have the CDV (which YANG > allows the server to emit), or the leaf will have a non-CDV (which > the server MUST emit). I prefer to stick with the 'YANG default-stmt == default' definition we have now. > > If the leaf was not created in the database, then it has no value. > YANG allows the server to emit the default value, but does not > require it. > > So if the leaf "foo" has a default of "3", and a client sets foo > to 3, then a server can still emit the value "3". This is the > "explicit" behavior, where the server emits values that the user > has set, without caring whether those values are the CDV. > > HTH.... yes -- the server MAY choose to emit a leaf with its YANG default value. Agreed. > > Thanks, > Phil > Andy From andy@netconfcentral.com Tue Sep 1 15:04:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567D43A70B7 for ; Tue, 1 Sep 2009 15:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GkbwCcexC1W for ; Tue, 1 Sep 2009 15:04:28 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 36FC928C7B0 for ; Tue, 1 Sep 2009 15:02:09 -0700 (PDT) Received: (qmail 24738 invoked from network); 1 Sep 2009 22:02:23 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 1 Sep 2009 22:02:23 -0000 X-YMail-OSG: t23len4VM1nVmxZdkcMHxb8Yd18WLDWDYdKdUiG1FCFOWjbbBmUczsJ2xuLS_GCvZvTrCJYdmBaN6K5DlIPcQ4j3FHGrkoEH9JvRxib.132zpqgsE3ioPDPNDZu4mkeBCPvx0sfZmiTCMqR8zNbCT3XasH17jtbWPh.3ca1DS7TsM0SAGOvNb5IAWzWxg0GD6cvSkr_CHV7u_auUDb.eWUVopTq59vsHBc369ufFeJsUErDtb973EcSpMs_9QqxN_JzEYfwKxmFEP_Tg X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9D9986.1050602@netconfcentral.com> Date: Tue, 01 Sep 2009 15:00:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909012116.n81LGAKh095413@idle.juniper.net> <4A9D9848.3030703@netconfcentral.com> In-Reply-To: <4A9D9848.3030703@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 22:04:29 -0000 Hi Phil, > The 3rd bullet is clearly wrong, because 'explicitly set' is never defined, > and you 'set by client or startup' is not what it means anyway. > It really means > > o explicit: Report all leaf values, including those which are explicitly set, > even if they are equal to the default value. For state > data this has the same effect as report-all. > I still got this wrong. Can you write some normative text so the capability makes sense? A capability where the server MAY do all the things the protocol says it can do is pointless. Let's get the normative text to say there are actual differences between the 3 modes, or remove redundant modes. Andy From randy_presuhn@mindspring.com Tue Sep 1 17:50:26 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673B33A7057 for ; Tue, 1 Sep 2009 17:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JegFX8GcKY8S for ; Tue, 1 Sep 2009 17:50:25 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id A6DA93A6840 for ; Tue, 1 Sep 2009 17:50:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Qa20e7p52+hPgdpUd9Eet69Ihy9VKJksJUMhrnMMOBCjrQwaAznpkdMBczJ7pI2W; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.94.65] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mie3Z-0001rO-TI for netmod@ietf.org; Tue, 01 Sep 2009 20:50:38 -0400 Message-ID: <005001ca2a9e$ad027820$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <200909011009.16729.david.partain@ericsson.com> <4A9D2227.4060407@joelhalpern.com> Date: Mon, 31 Aug 2009 17:53:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f906e7955804b3999330b1f5f1cfd8c87a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.94.65 Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 00:50:26 -0000 Hi - > From: "Joel M. Halpern" > To: "David Partain" > Cc: "NETMOD Working Group" > Sent: Tuesday, September 01, 2009 6:31 AM > Subject: Re: [netmod] Issue: interpretation of 'default' ... > A number of folks have argued that either > a) the managed device is free to set the node to some other value, even > if it has a default definition, undesirable - it means that if a client wants to be sure something has the "default" value, the client must explicitly assign that value to it > and to still treat that as a default > valued node intolerable - this would mean that the client would not readily see that the server was not adhering to the interface contract established by the use of "default" > b) the managed device is free to set nodes without default to some > value, this is ok > and not report that value in response to get requests of any kind. intolerable - this would prevent configuration backup / restore Randy From phil@juniper.net Tue Sep 1 18:47:11 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB623A6A13 for ; Tue, 1 Sep 2009 18:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOyg5dQbkWkF for ; Tue, 1 Sep 2009 18:47:11 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id ED86F3A690D for ; Tue, 1 Sep 2009 18:47:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSp3OcewmDhXiYocMJ1YAUNX1kVPE5+bK@postini.com; Tue, 01 Sep 2009 18:47:26 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 1 Sep 2009 18:38:24 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 18:38:24 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 18:38:24 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 18:38:23 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n821cMd24845; Tue, 1 Sep 2009 18:38:22 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n821QFVn097471; Wed, 2 Sep 2009 01:26:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909020126.n821QFVn097471@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9D9848.3030703@netconfcentral.com> Date: Tue, 1 Sep 2009 21:26:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Sep 2009 01:38:23.0571 (UTC) FILETIME=[0F3FB230:01CA2B6E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 01:47:11 -0000 Andy Bierman writes: >So an ABS leaf will always be retrievable on every server >because it does not have the YANG default value. Yes. >I prefer to stick with the 'YANG default-stmt == default' >definition we have now. This lack of common meaning has drawn out a lot of wasted email. I don't think we can use the definitions we have now without some additional clarification. >yes -- the server MAY choose to emit a leaf with its >YANG default value. Agreed. Rah. We're back to agreeing on what we agreed to when we wrote the dang thing. Thanks, Phil From andy@netconfcentral.com Tue Sep 1 19:15:41 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D52E3A6873 for ; Tue, 1 Sep 2009 19:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S8yQc5H257W for ; Tue, 1 Sep 2009 19:15:39 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 6B94E3A6A13 for ; Tue, 1 Sep 2009 19:15:39 -0700 (PDT) Received: (qmail 44514 invoked from network); 2 Sep 2009 02:02:27 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 2 Sep 2009 02:02:27 -0000 X-YMail-OSG: .SnNPhkVM1m56knMtdXTuWBfYqAUBZRRVVEXSZ3uY9wNj7NwzbrP5co_GYllC0EZJv4.aukaXokUvJVsq4OWBQLQK6gWzRRjadj6t.utRlIGAZjSQ0wq37IRgP1bFOHxhy1QBcA3Y36yr.RGviTbRJmWlM1WbNQf9WQ_bf_ARoNTe6Es3Rgb0GJ6CmEHyz9doHETVnEQNX.lRWl8CTMpOaVz.nMT.ZErGFjdkq09rmvl6JBTwuDMLvN9kHdlwqZIVlCZgV.D1cSkf.2W X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9DD1CA.8010702@netconfcentral.com> Date: Tue, 01 Sep 2009 19:00:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909020126.n821QFVn097471@idle.juniper.net> In-Reply-To: <200909020126.n821QFVn097471@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 02:15:41 -0000 Phil Shafer wrote: > Andy Bierman writes: >> So an ABS leaf will always be retrievable on every server >> because it does not have the YANG default value. > > Yes. > >> I prefer to stick with the 'YANG default-stmt == default' >> definition we have now. > > This lack of common meaning has drawn out a lot of wasted > email. I don't think we can use the definitions we have > now without some additional clarification. > I like the current meaning because it is a single value that MUST be valid for the data type. It is a trivial implementation detail to exchange 'fred' for fred, (assuming you consider having a perfect view of the schema definitions used by the current server session to be trivial). >> yes -- the server MAY choose to emit a leaf with its >> YANG default value. Agreed. > > Rah. We're back to agreeing on what we agreed to when > we wrote the dang thing. no, because if the definition of explicit in with-defaults was never right, so we were using different definitions of 'explicitly set'. Try these definitions A default is defined as YANG default-stmt value for YANG modules, and the 'default' attribute value for XSD: o report-all: All default data MUST be reported. o trim: Default data SHOULD NOT be reported. o explicit: Default data MAY be reported. > > Thanks, > Phil > Andy From mbj@tail-f.com Tue Sep 1 23:54:52 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C3A3A68DC for ; Tue, 1 Sep 2009 23:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv4S-tE+ixZx for ; Tue, 1 Sep 2009 23:54:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D046D3A6C48 for ; Tue, 1 Sep 2009 23:53:40 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DB1F476C4E1; Wed, 2 Sep 2009 08:52:25 +0200 (CEST) Date: Wed, 02 Sep 2009 08:52:25 +0200 (CEST) Message-Id: <20090902.085225.250234213.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251872580.12476.35.camel@missotis> References: <1251825583.4542.24.camel@missotis> <20090901.215457.12686984.mbj@tail-f.com> <1251872580.12476.35.camel@missotis> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 06:54:52 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMDEuIDA5LiAyMDA5IHYgMjE6NTQgKzAyMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IEpvZWwgTS4gSGFscGVy biBww63FoWUgdiDDmnQgMDEuIDA5LiAyMDA5IHYgMTI6MjAgLTA0MDA6DQo+ID4gPiA+IFNvcnJ5 LCBJIGhhdmUgbm8gaWRlYSB3aGF0IHlvdSBhcmUgZ2V0dGluZyBhdCAvIGFza2luZyBmb3IuDQo+ ID4gPiA+IChJIGNhbiBwcm92aWRlIHR3byBwb3NzaWJsZSBpbnRlcnByZXRhdGlvbnMsIG9uZSBv ZiB3aGljaCB3b3VsZCBiZSBmaW5lIA0KPiA+ID4gPiBhbmQgb25lIG9mIHdoaWNoIEkgd291bGQg Y29tcGxldGVseSBkaXNhZ3JlZSB3aXRoLiAgQW5kIHdoYXQgeW91IG1lYW50IA0KPiA+ID4gPiBp cyBwcm9iYWJseSBuZWl0aGVyIG9uZS4pDQo+ID4gPiA+IFdvdWxkIHlvdSBwbGVhc2UgY2xhcmlm eSB0byB0aGUgbGlzdD8NCj4gPiA+IA0KPiA+ID4gTXkgcG9pbnQgc2ltcGx5IGlzIHRoYXQgdGhl ICJzZXJ2ZXIgTVVTVCB1c2UiIGxhbmd1YWdlIG1pc2xlZCBtZSBpbnRvDQo+ID4gPiB0aGlua2lu ZyB0aGF0IHRoZSAnZGVmYXVsdCcgc3RhdGVtZW50IHByZXZlbnRzIHRoZSBkZXZpY2UgZnJvbSBk b2luZyBhKSwNCj4gPiA+IHdoaWNoIGlzIG5vdCB0aGUgY2FzZSwNCj4gPiANCj4gPiBXZWxsLCB0 aGF0IHdhcyB0aGUgaW50ZW50aW9uLiAgSWYgdGhlcmUgaXMgYSAnZGVmYXVsdCcgc3RhdGVtZW50 LCBpdA0KPiA+IHByZXZlbnRzIHRoZSBzZXJ2ZXIgZnJvbSBpZ25vcmluZyBpdC4gDQo+ID4gDQo+ ID4gV2h5IGRvIHNheSB0aGF0IHRoaXMgaXMgbm90IHRoZSBjYXNlPw0KPiANCj4gSG1tLCB0aGlz IGlzIGdldHRpbmcgcmVhbGx5IGNvbmZ1c2luZywgc28gbGV0IG1lIHN0YXRlIGNsZWFybHkgbXkN Cj4gcG9zaXRpb246DQo+IA0KPiAxLiBUaGUgJ2RlZmF1bHQnIHN0YXRlbWVudCBzYXlzIHRoYXQg Y2VydGFpbiBwcmVjaXNlbHkgc3BlY2lmaWVkIA0KPiAgICBjaGFuZ2VzIHRvIHRoZSBkYXRhc3Rv cmUgaW5mb3NldCBkbyBub3QgY2hhbmdlIHRoZSBtZWFuaW5nIG9mIHRoZSANCj4gICAgY29uZmln dXJhdGlvbi4NCj4gDQo+IDIuIEluIHByaW5jaXBsZSwgdGhpcyBkb2VzIG5vdCBwcmV2ZW50IHRo ZSBzZXJ2ZXIgZnJvbSBzZXR0aW5nIHN1Y2ggYSANCj4gICAgY29uZmlndXJhdGlvbiBwYXJhbWV0 ZXIgdG8gYW55IHZhbGlkIHZhbHVlLCBlLmcuIGluIGFuIGluaXRpYWwgDQo+ICAgIGNvbmZpZ3Vy YXRpb24uIEhvd2V2ZXIsIGlmIHRoaXMgdmFsdWUgaXMgZGlmZmVyZW50IGZyb20gdGhlIGRlZmF1 bHQgDQo+ICAgIHNwZWNpZmllZCBieSB0aGUgZGF0YSBtb2RlbCwgaXQgbXVzdCBhbHdheXMgYmUg c2hvd24gaW4gdGhlIA0KPiAgICBjb25maWd1cmF0aW9uLg0KPiANCj4gSSB1bmRlcnN0b29kIEpv ZWwncyBpdGVtIGEpIG1lYW5zIHRoZSBzYW1lIGFzIDIuDQoNCkJ1dCBoZSB3cm90ZSAiYW5kIHN0 aWxsIHRyZWF0IHRoYXQgYXMgYSBkZWZhdWx0IHZhbHVlZCBub2RlIiwgd2hpY2ggaXMNCm5vdCB3 aGF0IHlvdSAoYW5kIG1lKSBhcmUgc2F5aW5nLiAgSnVzdCBhcyB5b3Ugc2F5LCBpZiBpdCBoYXMg YSB2YWx1ZQ0KaXQgbXVzdCBiZSByZXR1cm5lZC4NCg0KDQovbWFydGluDQoNCg0KDQoNCg0KDQo+ IA0KPiBMYWRhDQo+IA0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4gPiA+ID4gTGFk aXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+ID4gPiA+IEpvZWwgTS4gSGFscGVybiBww63FoWUgdiDD mnQgMDEuIDA5LiAyMDA5IHYgMDk6MzEgLTA0MDA6DQo+ID4gPiA+ID4+IFVuZm9ydHVuYXRlbHks IHdoaWxlIEkgbGlrZSB0aGlzIGNhc2UsIGl0IGRvZXMgbm90LCBhcyBmYXIgYXMgSSBjYW4gDQo+ ID4gPiA+ID4+IHRlbGwsIHNvbHZlIHRoZSBwcm9ibGVtIGF0IGhhbmQuDQo+ID4gPiA+ID4+DQo+ ID4gPiA+ID4+IEEgbnVtYmVyIG9mIGZvbGtzIGhhdmUgYXJndWVkIHRoYXQgZWl0aGVyDQo+ID4g PiA+ID4+IGEpIHRoZSBtYW5hZ2VkIGRldmljZSBpcyBmcmVlIHRvIHNldCB0aGUgbm9kZSB0byBz b21lIG90aGVyIHZhbHVlLA0KPiA+ID4gPiA+PiBldmVuDQo+ID4gPiA+ID4+IGlmIGl0IGhhcyBh IGRlZmF1bHQgZGVmaW5pdGlvbiwgYW5kIHRvIHN0aWxsIHRyZWF0IHRoYXQgYXMgYSBkZWZhdWx0 IA0KPiA+ID4gPiA+PiB2YWx1ZWQgbm9kZQ0KPiA+ID4gPiA+PiBiKSB0aGUgbWFuYWdlZCBkZXZp Y2UgaXMgZnJlZSB0byBzZXQgbm9kZXMgd2l0aG91dCBkZWZhdWx0IHRvIHNvbWUgDQo+ID4gPiA+ ID4+IHZhbHVlLCBhbmQgbm90IHJlcG9ydCB0aGF0IHZhbHVlIGluIHJlc3BvbnNlIHRvIGdldCBy ZXF1ZXN0cyBvZiBhbnkNCj4gPiA+ID4gPj4ga2luZC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBU aGUgdGV4dCBub3cgc3BlY2lmaWVzIHRoYXQgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zIHRoZSBj b25maWd1cmF0aW9uDQo+ID4gPiA+ID4gd2l0aG91dCB0aGUgbGVhZiBpcyBlcXVpdmFsZW50IHRv IG9uZSBpbiB3aGljaCB0aGUgbGVhZiBpcyBwcmVzZW50IGFuZA0KPiA+ID4gPiA+IHNldCB0byB0 aGUgZGVmYXVsdCB2YWx1ZS4gSG93ZXZlciwgZm9ybXVsYXRpb25zIGxpa2UgInNlcnZlciBNVVNU IHVzZQ0KPiA+ID4gPiA+IHRoZSBkZWZhdWx0IiB2YWx1ZSBtYXkgYmUgdW5kZXJzdG9vZCBhcyBp ZiB0aGUgc2VydmVyIGlzIG5vdCBhbGxvd2VkIHRvDQo+ID4gPiA+ID4gYXNzaWduIGEgdmFsdWUg dW5pbGF0ZXJhbGx5LiBTbyBpdCBtaWdodCBiZSBhY3R1YWxseSBiZXR0ZXIgdG8gdGFsaw0KPiA+ ID4gPiA+IGFib3V0IGVxdWl2YWxlbmNlIG9mIGNvbmZpZ3VyYXRpb25zLCBhbHNvIGJlY2F1c2Ug aXQgY2FuIGJlIGVhc2lseQ0KPiA+ID4gPiA+IGFwcGxpZWQgdG8gZGF0YXN0b3JlcyBvdGhlciB0 aGFuIHJ1bm5pbmcuDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gTGFkYQ0KPiA+ID4gLS0gDQo+ID4g PiBMYWRpc2xhdiBMaG90a2EsIENFU05FVA0KPiA+ID4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4g PiA+IA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gLS0gDQo+ IExhZGlzbGF2IExob3RrYSwgQ0VTTkVUDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0K From lhotka@cesnet.cz Wed Sep 2 00:07:37 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCEA13A68DC for ; Wed, 2 Sep 2009 00:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL8c6PDEvdwK for ; Wed, 2 Sep 2009 00:07:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B9F773A686A for ; Wed, 2 Sep 2009 00:07:36 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2D5A8D800E8; Wed, 2 Sep 2009 09:07:13 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090902.085225.250234213.mbj@tail-f.com> References: <1251825583.4542.24.camel@missotis> <20090901.215457.12686984.mbj@tail-f.com> <1251872580.12476.35.camel@missotis> <20090902.085225.250234213.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Sep 2009 09:07:11 +0200 Message-Id: <1251875231.12476.51.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 07:07:37 -0000 Martin Bjorklund píše v St 02. 09. 2009 v 08:52 +0200: > > > > 1. The 'default' statement says that certain precisely specified > > changes to the datastore infoset do not change the meaning of the > > configuration. > > > > 2. In principle, this does not prevent the server from setting such a > > configuration parameter to any valid value, e.g. in an initial > > configuration. However, if this value is different from the default > > specified by the data model, it must always be shown in the > > configuration. > > > > I understood Joel's item a) means the same as 2. > > But he wrote "and still treat that as a default valued node", which is > not what you (and me) are saying. Just as you say, if it has a value > it must be returned. These are the perils of shortcut formulations. My interpretation of "and still treat that as a default valued node" was that the 'default' statement for that node still applies, i.e. the 'default' statement that the data model specifies for this node is not suddenly nullified by the action. Lada > > > /martin > > > > > > > > > > Lada > > > > > > > > > > > /martin > > > > > > > > Ladislav Lhotka wrote: > > > > > > Joel M. Halpern píše v Út 01. 09. 2009 v 09:31 -0400: > > > > > >> Unfortunately, while I like this case, it does not, as far as I can > > > > > >> tell, solve the problem at hand. > > > > > >> > > > > > >> A number of folks have argued that either > > > > > >> a) the managed device is free to set the node to some other value, > > > > > >> even > > > > > >> if it has a default definition, and to still treat that as a default > > > > > >> valued node > > > > > >> b) the managed device is free to set nodes without default to some > > > > > >> value, and not report that value in response to get requests of any > > > > > >> kind. > > > > > > > > > > > > The text now specifies that under certain conditions the configuration > > > > > > without the leaf is equivalent to one in which the leaf is present and > > > > > > set to the default value. However, formulations like "server MUST use > > > > > > the default" value may be understood as if the server is not allowed to > > > > > > assign a value unilaterally. So it might be actually better to talk > > > > > > about equivalence of configurations, also because it can be easily > > > > > > applied to datastores other than running. > > > > > > > > > > > > Lada > > > > -- > > > > Ladislav Lhotka, CESNET > > > > PGP Key ID: E74E8C0C > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Wed Sep 2 00:08:47 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9113A686A for ; Wed, 2 Sep 2009 00:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+5K4H54EA4L for ; Wed, 2 Sep 2009 00:08:47 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 12F2A3A6A1B for ; Wed, 2 Sep 2009 00:07:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSp4ZnC6Qioc7/ZNDZg1W9Q7KkHYEAEan@postini.com; Wed, 02 Sep 2009 00:09:02 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 2 Sep 2009 00:00:16 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 00:00:16 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 00:00:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 00:00:15 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n82706d47939; Wed, 2 Sep 2009 00:00:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n826m1Ru099344; Wed, 2 Sep 2009 06:48:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909020648.n826m1Ru099344@idle.juniper.net> To: WashamFan In-Reply-To: Date: Wed, 2 Sep 2009 02:48:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Sep 2009 07:00:15.0130 (UTC) FILETIME=[05D5BFA0:01CA2B9B] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 07:08:48 -0000 WashamFan writes: >Below is my interpretation: Here's my take: report-all: The server MUST send the leaf element if the leaf has a configured value or a default value. If no value has been configured, the default value is used as the leaf value. trim: The server MUST send the leaf element if the leaf has a configured value and that value is different than the default value. explicit: The server MUST send the leaf element if the leaf has a configured value. Would "configured" be more meaningful than "explicit"? Thanks, Phil From Washam.Fan@huaweisymantec.com Wed Sep 2 00:29:48 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484623A6A80 for ; Wed, 2 Sep 2009 00:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtNKRTrOglsh for ; Wed, 2 Sep 2009 00:29:47 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 890643A6F97 for ; Wed, 2 Sep 2009 00:27:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KPB00AR2Z1UKB00@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 02 Sep 2009 14:22:43 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KPB009L2Z1U8R10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 02 Sep 2009 14:22:42 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 02 Sep 2009 14:22:42 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 02 Sep 2009 14:22:42 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A9DD1CA.8010702@netconfcentral.com> References: <200909020126.n821QFVn097471@idle.juniper.net> <4A9DD1CA.8010702@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 07:29:48 -0000 > no, because if the definition of explicit in with-defaults > was never right, so we were using different definitions > of 'explicitly set'. Try these definitions > > A default is defined as YANG default-stmt value for > YANG modules, and the 'default' attribute value for XSD: > > o report-all: All default data MUST be reported. > o trim: Default data SHOULD NOT be reported. > o explicit: Default data MAY be reported. Below is my interpretation: o report-all: All default data MUST be reported. o trim: Default data MUST NOT be reported. o explicit: Default data MAY be reported. I.e., default data explicitly set by the client MUST be reported. It is what I've been understood :with-defaults. And it is unambiguous. Any comments? washam From david.partain@ericsson.com Wed Sep 2 00:59:09 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C133A6FD2 for ; Wed, 2 Sep 2009 00:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfFxyyRWzOL2 for ; Wed, 2 Sep 2009 00:59:08 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0248D3A6FB0 for ; Wed, 2 Sep 2009 00:56:42 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-54-4a9e18103ccd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id C9.49.18827.0181E9A4; Wed, 2 Sep 2009 09:00:32 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 09:00:31 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 09:00:31 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 2 Sep 2009 09:00:30 +0200 User-Agent: KMail/1.9.10 References: <4A9D7BA2.8020803@netconfcentral.com> <20090901.222850.210872069.mbj@tail-f.com> <4A9D8BDE.1030505@netconfcentral.com> In-Reply-To: <4A9D8BDE.1030505@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909020900.31039.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 07:00:31.0398 (UTC) FILETIME=[0F880C60:01CA2B9B] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Supporting three styles of default handling in with-defaults (was meaning of default) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 07:59:09 -0000 Hi all, We're treading in and out of NETCONF territory... So, :with-defaults supports three ways of handling defaults (quoting...) - report-all: All default data is always reported. - trim: Values are not reported if they match the default. - explicit: Report values if they are explicitly set. For state data this has the same effect as report-all Andy argues that YANG cannot support these three different modes. Martin has agreed that there are issues that need to be addressed, but not that it's broken in the way Andy claims. I see two things that need to happen: 1. If there are problems in the :with-defaults document, they should be fixed in NETCONF. Proposals are, I'm sure, welcome. 2. If there are problems in the YANG spec that make it impossible (I'm unconvinced) to support all three, please provide textual proposals of what needs to change. Thanks. David From dromasca@avaya.com Wed Sep 2 01:04:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66CBC3A67B6 for ; Wed, 2 Sep 2009 01:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf+jBLGApUtE for ; Wed, 2 Sep 2009 01:04:35 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 4B3143A6AB3 for ; Wed, 2 Sep 2009 01:03:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,317,1249272000"; d="scan'208";a="172094991" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 02 Sep 2009 03:53:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Sep 2009 03:53:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Sep 2009 09:53:37 +0200 Message-ID: In-Reply-To: <20090901193508.GA9782@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Configuration Data versus Operational State Data versusStatistics Thread-Index: AcorO2f1FsmfB5+VR3emQe1o9HG5PQAZekFQ References: <20090901193508.GA9782@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Subject: Re: [netmod] Configuration Data versus Operational State Data versusStatistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 08:04:36 -0000 (speaking as a contributor) I believe that this is an important subject, and it's good to deal with it in the architecture document.=20 The scope seems to exceed NETCONF architecture. It's good to have the distinction made and the concepts well defined. My question is however - what is the role of NETCONF (and YANG) in retrieving or reporting statistics information? I rather see a future network management architecture using NETCONF for configuration data. I am not so sure about operational state data - would it be NETCONF, or rather SNMP doe operational status retrieval and notifications, or SYSLOG - if we deal with alarms? Is there a good case to use anything else than SNMP to retrieve statistics information?=20 Dan > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, September 01, 2009 10:35 PM > To: netmod@ietf.org > Subject: [netmod] Configuration Data versus Operational State=20 > Data versusStatistics >=20 > Hi, >=20 > I propose to add a section to the architecture document=20 > defining and discussing the difference between configuration=20 > data, operational state data, and statistics. I attaching=20 > some draft writeup explaining the background, providing a=20 > definition and some examples we discussed here on the list. I=20 > am also including a section discussing potential approaches=20 > to deal with operational state data. This is more for=20 > discussion rather than inclusion in the architecture document. >=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 From david.partain@ericsson.com Wed Sep 2 01:15:29 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729903A7073 for ; Wed, 2 Sep 2009 01:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGmrZd0pWAZd for ; Wed, 2 Sep 2009 01:15:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4B2C23A6FEF for ; Wed, 2 Sep 2009 01:15:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-ea-4a9e25d72433 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 5C.29.01983.7D52E9A4; Wed, 2 Sep 2009 09:59:19 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 09:59:19 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 09:59:19 +0200 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Wed, 2 Sep 2009 09:59:18 +0200 User-Agent: KMail/1.9.10 References: <200909010959.59070.david.partain@ericsson.com> <4A9D0AD9.7020907@netconfcentral.com> In-Reply-To: <4A9D0AD9.7020907@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909020959.19045.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 07:59:19.0598 (UTC) FILETIME=[4680A4E0:01CA2BA3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 08:15:29 -0000 Hi, On Tuesday 01 September 2009 13.51.53 Andy Bierman wrote: > > David Partain wrote: > > If the rough consensus appears to be to add it, I'll ask Martin to submit > > a proposal with text. We'll then discuss based on that text. > > I have not yet seen a complete and convincing problem statement, > let alone a complete and convincing solution proposal. The idea was (1) to find out if we should re-open the question and (2) _thereafter_ ask Martin to propose a solution to decide on. I think that's what I wrote above. Cheers, David From david.partain@ericsson.com Wed Sep 2 01:18:23 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8BE3A6C51 for ; Wed, 2 Sep 2009 01:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XxUeo7u7TpK for ; Wed, 2 Sep 2009 01:18:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8A5473A689B for ; Wed, 2 Sep 2009 01:18:22 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-ab-4a9e2685e191 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0F.89.01983.5862E9A4; Wed, 2 Sep 2009 10:02:13 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 10:02:13 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 10:02:13 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 2 Sep 2009 10:02:12 +0200 User-Agent: KMail/1.9.10 References: <200909010959.59070.david.partain@ericsson.com> <004201ca2b20$e0b9c7e0$0601a8c0@allison> <20090901.220411.219341767.mbj@tail-f.com> In-Reply-To: <20090901.220411.219341767.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021002.12971.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 08:02:13.0398 (UTC) FILETIME=[AE186B60:01CA2BA3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 08:18:23 -0000 Hi, I think there's been enough mail stating that a proposal would be good. Martin, could you please put together some text detailing "assigned-by system" (or some other name that is better -- suggestions welcome)? Once the text is on the table, y'all can all have at it. Cheers, David From lhotka@cesnet.cz Wed Sep 2 01:19:34 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865923A69FD for ; Wed, 2 Sep 2009 01:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47ORAcPF4eYg for ; Wed, 2 Sep 2009 01:19:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A90C128C260 for ; Wed, 2 Sep 2009 01:19:33 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0A762D800E8 for ; Wed, 2 Sep 2009 10:18:53 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Sep 2009 10:18:52 +0200 Message-Id: <1251879533.12476.100.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: [netmod] [Fwd: Re: Configuration Data versus Operational State Data versus Statistics] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 08:19:34 -0000 Hi, as if the chaos wasn't big enough yet, the mailing list had eaten up two of my recent messages. So I am resending this one, and the important part of the other one is in the subsequent discussion with Martin with subject "Issue: interpretation of 'default'". I am sorry for that, Lada -------- Přeposlaná zpráva -------- Od: Ladislav Lhotka Komu: Juergen Schoenwaelder Kopie: netmod@ietf.org Předmět: Re: [netmod] Configuration Data versus Operational State Data versus Statistics Datum: Wed, 02 Sep 2009 09:53:43 +0200 Juergen Schoenwaelder píše v Út 01. 09. 2009 v 21:35 +0200: > Hi, > > I propose to add a section to the architecture document defining and > discussing the difference between configuration data, operational > state data, and statistics. I attaching some draft writeup explaining I support inclusion of this text in the architecture document. The distinction between operational state data and statistics is crucial. > the background, providing a definition and some examples we discussed > here on the list. I am also including a section discussing potential > approaches to deal with operational state data. This is more for > discussion rather than inclusion in the architecture document. In the second paragraph of Example 2 you write: "However, there are usually provisions to overwrite the discovered attributes with static configuration data, ..." Depending on implementation, operational state and configuration parameters may be so tightly coupled that they are effectively indistinguishable. For example, I can directly write certain values in the /proc filesystem, so they are by definition configuration data, but the write immediately changes operational data in the kernel. Conversely, any change of such a parameter in the kernel is immediately reflected in the /proc filesystem. Lada > > /js > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Wed Sep 2 01:22:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E7E28C416 for ; Wed, 2 Sep 2009 01:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.672 X-Spam-Level: X-Spam-Status: No, score=-3.672 tagged_above=-999 required=5 tests=[AWL=-1.423, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuSco1cIqFSW for ; Wed, 2 Sep 2009 01:22:58 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A7CBF3A68DB for ; Wed, 2 Sep 2009 01:21:53 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-77-4a9e27402586 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 77.1F.18827.0472E9A4; Wed, 2 Sep 2009 10:05:20 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 10:05:19 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 10:05:19 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 2 Sep 2009 10:05:19 +0200 User-Agent: KMail/1.9.10 References: <200909012018.n81KIRof094517@idle.juniper.net> In-Reply-To: <200909012018.n81KIRof094517@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021005.19240.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 08:05:19.0677 (UTC) FILETIME=[1D2056D0:01CA2BA4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 08:22:58 -0000 Hi all, On Tuesday 01 September 2009 22.18.27 Phil Shafer wrote: > >If the system is using a value for a "config true" node, > >and that value is not reported, and that value is not the model defined > >default value, then we have an operability problem. > >If some systems report it one way, and some systems report it another > >way, then we probably have an interoperability problem. > > The delicate terms is "the system is using a value". This is an > ambiguous term that may be the source of the trouble. So let's > start with some precise terminology: > > "assigned-by system" (ABS): a behavior where the system will, > at validation time, assign values in the configuration database > for leafs which are not given values. If values were given before > validation time, the system will not assign new values, but will > honor these existing values. > > "configuration default value" (CDV): the default value used for > configuration data. If a list instance is created in the > configuration database and the value for a leaf is not provided, > then the CDV is the value which the system will use internally. > This means that the behaviour of the running system using that > CDV as the operational value is identical to the behaviour if > that leaf had been explicitly configured with that value. The > CDV value must be a fixed value. > > "operational default value" (ODV): the default value used for > operational data. This is the value used by the running > system if a value was not configured. It may not be fixed or > easily described. The value may be dynamic or even unpublished. > > With these terms, we make the following rules: > > (a) the YANG default statement can be used to provide a CDV. > (b) the YANG default statement cannot provide defaults for ODVs. > (c) the YANG default statement cannot provide defaults for ABS leafs. > (d) a server MAY choose to not send a leaf element if > it is a configuration leaf ('config true') and the > value of the leaf is the default value. > (e) ODVs MUST be sent for operational data, since the default > statement applies only to configuration data. In effect, > operational data has no default values. > (f) ABS data is _real_ configuration data, since it appears > in the configuration database and can be manipulated with > the operation NETCONF/YANG operations. Phil, are you proposing that this text be added to the YANG draft to then be used to help define 'default' behavior? David From andy@netconfcentral.com Wed Sep 2 03:20:15 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1423A67A4 for ; Wed, 2 Sep 2009 03:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKAxLGajxHad for ; Wed, 2 Sep 2009 03:20:13 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 576423A6A02 for ; Wed, 2 Sep 2009 03:18:53 -0700 (PDT) Received: (qmail 80460 invoked from network); 2 Sep 2009 10:16:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 2 Sep 2009 10:16:56 -0000 X-YMail-OSG: xnXuXKoVM1kc4nMP8Xxkr8ahA0FSjDdH8gd82OZlpuRy5PjDfceG0OP7AHpm8fy.xkaO5v_rPFeQQXm2E0pqHMLE4fuP5CGrcBEfDqi5j_b0HLm4n9ctLdOlCMdrtPz99fN5hY3O7hkHtO3_ZNZssU4ErNor_the5nxUNJZXGy.lAhyNHTHgIHjg9WGtqsk8h1VAuRr7B7FAU4Dcse1gl_TZUprPZpDWb_pImJlnSV28EKl7Y.J0hpMTrDyjVmUWZ_bTRQjOQ4MfLhOk X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9E45AF.6060007@netconfcentral.com> Date: Wed, 02 Sep 2009 03:15:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200909020648.n826m1Ru099344@idle.juniper.net> In-Reply-To: <200909020648.n826m1Ru099344@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] proposal: no defaults for non-config data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:20:15 -0000 Phil Shafer wrote: > WashamFan writes: >> Below is my interpretation: > > Here's my take: > > report-all: The server MUST send the leaf element if the leaf has > a configured value or a default value. If no value has been > configured, the default value is used as the leaf value. > > trim: The server MUST send the leaf element if the leaf has a > configured value and that value is different than the default value. > > explicit: The server MUST send the leaf element if the leaf has a > configured value. > > Would "configured" be more meaningful than "explicit"? > provide a definition for 'configured', and we shall find out. > Thanks, > Phil > Andy From lhotka@cesnet.cz Wed Sep 2 03:40:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098FF3A69E8 for ; Wed, 2 Sep 2009 03:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80-17u-vfYjM for ; Wed, 2 Sep 2009 03:40:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D748928C2F2 for ; Wed, 2 Sep 2009 03:40:36 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 93976D800EF; Wed, 2 Sep 2009 09:53:43 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090901193508.GA9782@elstar.local> References: <20090901193508.GA9782@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Sep 2009 09:53:42 +0200 Message-Id: <1251878022.12476.77.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Configuration Data versus Operational State Data versus Statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:40:38 -0000 Juergen Schoenwaelder píše v Út 01. 09. 2009 v 21:35 +0200: > Hi, > > I propose to add a section to the architecture document defining and > discussing the difference between configuration data, operational > state data, and statistics. I attaching some draft writeup explaining I support inclusion of this text in the architecture document. The distinction between operational state data and statistics is crucial. > the background, providing a definition and some examples we discussed > here on the list. I am also including a section discussing potential > approaches to deal with operational state data. This is more for > discussion rather than inclusion in the architecture document. In the second paragraph of Example 2 you write: "However, there are usually provisions to overwrite the discovered attributes with static configuration data, ..." Depending on implementation, operational state and configuration parameters may be so tightly coupled that they are effectively indistinguishable. For example, I can directly write certain values in the /proc filesystem, so they are by definition configuration data, but the write immediately changes operational data in the kernel. Conversely, any change of such a parameter in the kernel is immediately reflected in the /proc filesystem. Lada > > /js > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Wed Sep 2 03:50:38 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EA63A69A1 for ; Wed, 2 Sep 2009 03:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.562 X-Spam-Level: X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsFy8s6s2B0c for ; Wed, 2 Sep 2009 03:50:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 393C93A676A for ; Wed, 2 Sep 2009 03:50:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-50-4a9e4dc8b96e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C8.E5.06532.8CD4E9A4; Wed, 2 Sep 2009 12:49:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 12:49:44 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 12:49:44 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 2 Sep 2009 12:49:43 +0200 User-Agent: KMail/1.9.10 References: <4A95EB78.7000009@netconfcentral.com> <20090827.163003.130650426.mbj@tail-f.com> <4A96ACF7.6010204@netconfcentral.com> In-Reply-To: <4A96ACF7.6010204@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021249.43871.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 10:49:44.0528 (UTC) FILETIME=[15092500:01CA2BBB] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:50:38 -0000 On Thursday 27 August 2009 17.57.43 Andy Bierman wrote: > If this filtering was just limited to YANG default-stmts, > then it would be fine, but it is not. I just be really thick, but I thought that's _exactly_ what it was limited to. We need to work on the interaction between this and :with-defaults (which should be done in NETCONF...), but I've never seen anyone suggesting the server should just magically decide what it will or will not send. David From cfinss@dial.pipex.com Wed Sep 2 03:54:56 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D233A6E94 for ; Wed, 2 Sep 2009 03:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKyhdYz8LYCE for ; Wed, 2 Sep 2009 03:54:55 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 3A92E3A6AF2 for ; Wed, 2 Sep 2009 03:54:55 -0700 (PDT) X-Trace: 135628355/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.166/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.166 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAIvpnUo+vGmm/2dsb2JhbACDLUCNT8kiCYQSBQ X-IronPort-AV: E=Sophos;i="4.44,317,1249254000"; d="scan'208";a="135628355" X-IP-Direction: IN Received: from 1cust166.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.166]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2009 11:46:33 +0100 Message-ID: <000b01ca2bb2$11b925c0$0601a8c0@allison> From: "tom.petch" To: "Randy Presuhn" , "NETMOD Working Group" References: <200909011009.16729.david.partain@ericsson.com><4A9D2227.4060407@joelhalpern.com> <005001ca2a9e$ad027820$6801a8c0@oemcomputer> Date: Wed, 2 Sep 2009 11:30:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:54:56 -0000 Randy Good to hear from you; see inline Tom Petch ----- Original Message ----- From: "Randy Presuhn" Sent: Tuesday, September 01, 2009 2:53 AM > > From: "Joel M. Halpern" > > Sent: Tuesday, September 01, 2009 6:31 AM > ... > > A number of folks have argued that either > > a) the managed device is free to set the node to some other value, even > > if it has a default definition, > > undesirable - it means that if a client wants to be sure something has > the "default" value, the client must explicitly assign that value to it > > > and to still treat that as a default > > valued node > > intolerable - this would mean that the client would not readily see that > the server was not adhering to the interface contract established by > the use of "default" > > > b) the managed device is free to set nodes without default to some > > value, > > this is ok > > > and not report that value in response to get requests of any kind. > > intolerable - this would prevent configuration backup / restore Crunch; yes, there MUST be an option (preferrably a mandatory one) to get back such data. Tom Petch > > Randy From cfinss@dial.pipex.com Wed Sep 2 03:54:57 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEE73A6E94 for ; Wed, 2 Sep 2009 03:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3N6-cXimI48 for ; Wed, 2 Sep 2009 03:54:56 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id E24DC3A6E5C for ; Wed, 2 Sep 2009 03:54:55 -0700 (PDT) X-Trace: 135628364/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.166/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.166 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAIvpnUo+vGmm/2dsb2JhbACDLUCNT8kiCYQSBQ X-IronPort-AV: E=Sophos;i="4.44,317,1249254000"; d="scan'208";a="135628364" X-IP-Direction: IN Received: from 1cust166.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.166]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2009 11:46:34 +0100 Message-ID: <000c01ca2bb2$127040c0$0601a8c0@allison> From: "tom.petch" To: "David Partain" , References: <4A9D7BA2.8020803@netconfcentral.com><20090901.222850.210872069.mbj@tail-f.com><4A9D8BDE.1030505@netconfcentral.com> <200909020900.31039.david.partain@ericsson.com> Date: Wed, 2 Sep 2009 11:30:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] Supporting three styles of default handling inwith-defaults (was meaning of default) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:54:57 -0000 ----- Original Message ----- From: "David Partain" Sent: Wednesday, September 02, 2009 9:00 AM > Hi all, > > We're treading in and out of NETCONF territory... > > So, :with-defaults supports three ways of handling defaults (quoting...) > > - report-all: All default data is always reported. > - trim: Values are not reported if they match the default. > - explicit: Report values if they are explicitly set. For state data this has > the same effect as report-all Depends what you mean by 'explicitly set'. If it is only by Netconf, (which is what the with-defaults I-D suggests to me) then I think this too narrow to be useful. I want it to include CLI, SNMP etc since this is the data that needs to be available for configuration backup/restore, as Randy referred to. But if it includes data set by operations - IP FIB, Bridge forwarding table, BGP RIB, OSPF adjacencies and LS database - then I find that too wide to be useful. I see this last case as yang independent; there is nothing in yang that records whether or not something has been explicitly set. It is currently just a matter for Netconf. Tom Petch > Andy argues that YANG cannot support these three different modes. Martin has > agreed that there are issues that need to be addressed, but not that it's > broken in the way Andy claims. I see two things that need to happen: > > 1. If there are problems in the :with-defaults document, they should be fixed > in NETCONF. Proposals are, I'm sure, welcome. > > 2. If there are problems in the YANG spec that make it impossible (I'm > unconvinced) to support all three, please provide textual proposals of what > needs to change. > > Thanks. > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From cfinss@dial.pipex.com Wed Sep 2 03:54:57 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21A93A6E5C for ; Wed, 2 Sep 2009 03:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIVXpUmf25cs for ; Wed, 2 Sep 2009 03:54:56 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 976DF3A6AF2 for ; Wed, 2 Sep 2009 03:54:56 -0700 (PDT) X-Trace: 135628377/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.166/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.166 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAIvpnUo+vGmm/2dsb2JhbACDLUCNT7hwCZApAgeCQ4FPBQ X-IronPort-AV: E=Sophos;i="4.44,317,1249254000"; d="scan'208";a="135628377" X-IP-Direction: IN Received: from 1cust166.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.166]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2009 11:46:36 +0100 Message-ID: <000d01ca2bb2$1385f680$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090901193508.GA9782@elstar.local> Date: Wed, 2 Sep 2009 11:31:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] Configuration Data versus Operational State Data versusStatistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:54:57 -0000 Juergen Promising. The problem I have is that the primary focus of YANG is the schema tree and I find the data tree, which I assume is the focus here, ill-defined. When people give definitions in terms of a configuration database, I cannot relate it to the data tree. Here the reference is to datastores which, in YANG, only really figure in the text we have tidied up as part of XPath. How simple this is in SMI; I need something more tangible here. What is the data tree made of ? Is it a pre-requisite that there is a data node in the schema tree? Is there a distinction between its constituent and the value thereof? When do its constituents come into being? Um Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, September 01, 2009 9:35 PM Subject: [netmod] Configuration Data versus Operational State Data versusStatistics > Hi, > > I propose to add a section to the architecture document defining and > discussing the difference between configuration data, operational > state data, and statistics. I attaching some draft writeup explaining > the background, providing a definition and some examples we discussed > here on the list. I am also including a section discussing potential > approaches to deal with operational state data. This is more for > discussion rather than inclusion in the architecture document. > > /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 > From cfinss@dial.pipex.com Wed Sep 2 03:54:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EEC28C773 for ; Wed, 2 Sep 2009 03:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge3aWEcblfMu for ; Wed, 2 Sep 2009 03:54:54 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 862443A6A92 for ; Wed, 2 Sep 2009 03:54:54 -0700 (PDT) X-Trace: 135628341/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.166/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.166 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAIvpnUo+vGmm/2dsb2JhbACDLUCNT8kiCYQSBYFX X-IronPort-AV: E=Sophos;i="4.44,317,1249254000"; d="scan'208";a="135628341" X-IP-Direction: IN Received: from 1cust166.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.166]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2009 11:46:31 +0100 Message-ID: <000a01ca2bb2$10ce2980$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <200909010959.59070.david.partain@ericsson.com><004201ca2b20$e0b9c7e0$0601a8c0@allison> <20090901.220411.219341767.mbj@tail-f.com> Date: Wed, 2 Sep 2009 11:30:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 10:54:58 -0000 ---- Original Message ----- From: "Martin Bjorklund" Sent: Tuesday, September 01, 2009 10:04 PM > "tom.petch" wrote: > > ----- Original Message ----- > > From: "David Partain" > > Sent: Tuesday, September 01, 2009 9:59 AM > > > > > > There has been significant debate about whether to reopen the question of > > > having 'assigned-by system'. See this mail thread - > > > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html > > > > > > The discussion has been in the "agent-default -- new 3rd state" thread (and > > > probably elsewhere). > > > > > > Martin wrote in the message referenced above: "The idea is that if a leaf is > > > marked as assigned-by system, then the client MAY choose to not set a value > > > for the leaf when its parent instance is created. In this case the system > > > will assign a suitable value for the leaf." > > > > I am unclear. I take it this is created in the data tree but is it as > > config or operational state (which affects how it can be retrieved) > > and is an instance being created or is this one of those thingies > > which seem neither dead nor alive? > > No magic is supposed to happen here. If the defintion is: > > leaf uid { > type int32; > config true; > assigned-by system; > } > > I hope it is obvious that we're talking about configuration data? Yes:-) > 'assigned-by' and 'config false' cannot be used together -- a client > can never create config false data (directly). > > > This harks back to Phil > > differentiating uid from mtu and Joel not seeing the difference. > > I am afraid I have yet to see the difference:-( Martin said > > 'So "if an instance exists because the server created it" then it *is* > > config. ' Um, leaves me none the wiser. > > > > And what's the parent instance got to do with it? It sounds like > > an assumption is built in there (and not the usual case or > > non-presence container issues) that I am missing. > > Extending the example a bit: > > list user { > ... > leaf uid { > ... > assigned-by system; > } > } > We need to make it clear that the 'uid' is not spontanesoulsy created > for non-existing users. The 'uid' leaf will be created by the system > when a new user is created (its "parent" -- note this is not a term we > have used, and we will have to find the right language to describe > this). Right (why do I often need a second lesson from you to understand:-( So is this 'system will assign' a MAY, MUST, SHOULD? And is it immediate ancestor only? I am thinking of the complex nested stack one gets with physical and logical interfaces, with the server allocating VCs at the bottom of the stack. Last time around, we spent time discussing the interaction with default and mandatory, but I see these two as incompatible with assigned-by-system if default means a value that the server MUST use and mandatory means the client MUST supply (disagree with these two, but suspect that these are the current view). Tom Petch > Another example: > > container foo { > presence "..."; > leaf bar { > ... > assigned-by system; > } > } > > /foo/bar is created by the system when the client creates /foo. > > /martin From lhotka@cesnet.cz Wed Sep 2 04:11:13 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC193A6B2C for ; Wed, 2 Sep 2009 04:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76iQA+kNnRaq for ; Wed, 2 Sep 2009 04:11:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C3F913A6B2B for ; Wed, 2 Sep 2009 04:11:11 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5A781D800CE; Wed, 2 Sep 2009 08:23:01 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090901.215457.12686984.mbj@tail-f.com> References: <1251821133.4542.13.camel@missotis> <4A9D49D5.6060806@joelhalpern.com> <1251825583.4542.24.camel@missotis> <20090901.215457.12686984.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Sep 2009 08:23:00 +0200 Message-Id: <1251872580.12476.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: interpretation of 'default' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 11:11:13 -0000 Martin Bjorklund píše v Út 01. 09. 2009 v 21:54 +0200: > Ladislav Lhotka wrote: > > Joel M. Halpern píše v Út 01. 09. 2009 v 12:20 -0400: > > > Sorry, I have no idea what you are getting at / asking for. > > > (I can provide two possible interpretations, one of which would be fine > > > and one of which I would completely disagree with. And what you meant > > > is probably neither one.) > > > Would you please clarify to the list? > > > > My point simply is that the "server MUST use" language misled me into > > thinking that the 'default' statement prevents the device from doing a), > > which is not the case, > > Well, that was the intention. If there is a 'default' statement, it > prevents the server from ignoring it. > > Why do say that this is not the case? Hmm, this is getting really confusing, so let me state clearly my position: 1. The 'default' statement says that certain precisely specified changes to the datastore infoset do not change the meaning of the configuration. 2. In principle, this does not prevent the server from setting such a configuration parameter to any valid value, e.g. in an initial configuration. However, if this value is different from the default specified by the data model, it must always be shown in the configuration. I understood Joel's item a) means the same as 2. Lada > > > /martin > > > > Ladislav Lhotka wrote: > > > > Joel M. Halpern píše v Út 01. 09. 2009 v 09:31 -0400: > > > >> Unfortunately, while I like this case, it does not, as far as I can > > > >> tell, solve the problem at hand. > > > >> > > > >> A number of folks have argued that either > > > >> a) the managed device is free to set the node to some other value, even > > > >> if it has a default definition, and to still treat that as a default > > > >> valued node > > > >> b) the managed device is free to set nodes without default to some > > > >> value, and not report that value in response to get requests of any kind. > > > > > > > > The text now specifies that under certain conditions the configuration > > > > without the leaf is equivalent to one in which the leaf is present and > > > > set to the default value. However, formulations like "server MUST use > > > > the default" value may be understood as if the server is not allowed to > > > > assign a value unilaterally. So it might be actually better to talk > > > > about equivalence of configurations, also because it can be easily > > > > applied to datastores other than running. > > > > > > > > Lada > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Wed Sep 2 04:29:24 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D5C28C2F2 for ; Wed, 2 Sep 2009 04:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HR6Z0uTdMUd for ; Wed, 2 Sep 2009 04:29:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EF5A43A70A9 for ; Wed, 2 Sep 2009 04:26:26 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-f4-4a9e52b4e4d2 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id DB.3C.01983.4B25E9A4; Wed, 2 Sep 2009 13:10:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:10:41 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:10:41 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 2 Sep 2009 13:10:40 +0200 User-Agent: KMail/1.9.10 References: <200908280510.n7S5ApVq031830@idle.juniper.net> <4A978928.3070802@netconfcentral.com> In-Reply-To: <4A978928.3070802@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021310.40777.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 11:10:41.0186 (UTC) FILETIME=[020FF020:01CA2BBE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 11:29:24 -0000 Hi, On Friday 28 August 2009 09.37.12 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> If the server can synthesize the value of a leaf for the purposes > >> of validation and XPath, that it can do the same for the > >> purposes of retrieval. > > > > We've traveled this road before. The issue isn't that the server > > cannot supply default values, it's that it should not supply them. > > Again -- it is up to the client to decide what > the client wants to retrieve, not the server. My take is that we really need :with-defaults... > Again -- documentation for what the server should contain > is not the same as retrieval of the data that the server actually contains. > Documentation is purely optional in YANG anyway. Andy, you keep talking about "offline documentation" or "vendor documentation". I'm clearly missing something. I don't see that we're talking about "vendor documentation" but rather the YANG data model. You can't do anything rational with SNMP without the MIB, either. If the client doesn't have the YANG data model, we're trashed anyway, aren't we? Why is it so onerous to look at what 'default' statements are in the data model? Thanks. David From mbj@tail-f.com Wed Sep 2 04:29:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4666628C6E4 for ; Wed, 2 Sep 2009 04:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgS8WW2v+hNO for ; Wed, 2 Sep 2009 04:29:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 469D33A70C9 for ; Wed, 2 Sep 2009 04:26:39 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 85E5076C4E1; Wed, 2 Sep 2009 13:16:11 +0200 (CEST) Date: Wed, 02 Sep 2009 13:16:12 +0200 (CEST) Message-Id: <20090902.131612.177280550.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <000a01ca2bb2$10ce2980$0601a8c0@allison> References: <004201ca2b20$e0b9c7e0$0601a8c0@allison> <20090901.220411.219341767.mbj@tail-f.com> <000a01ca2bb2$10ce2980$0601a8c0@allison> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 11:29:30 -0000 "tom.petch" wrote: > So is this 'system will assign' a MAY, MUST, SHOULD? Open question. See below. > And is it immediate ancestor only? I am thinking of the complex > nested stack one gets with physical and logical interfaces, with the > server allocating VCs at the bottom of the stack. Yes, ancestor only (modulo NP-containers). > Last time around, we spent time discussing the interaction with > default and mandatory, but I see these two as incompatible > with assigned-by-system > if default means a value that the server MUST use and mandatory > means the client MUST supply (disagree with these two, but suspect > that these are the current view). (See also http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html) Here are some alternatives: A. Keep the current text about mandatory, and allow the combination assigned-by system and mandatory true. The combination then means that the server MUST assign a value if the client doesn't. If assigned-by system mandatory is false, the server MAY assign a value. In this case, default would be ok if mandatory is false. If the server did not assign a value the default applies. B. Change mandatory to mean that the client MUST set it. This rules out the combination assigned-by system and mandatory true. B.1 B + assigned-by system means MUST assign This rules out the combination assigned-by system and default B.2 B + assigned-by system means MAY assign The combination assigned-by system and default would be ok. A gives most flexibility, but is also more error-prone. B.1 seems to be the most straight forward solution if we don't want to do A. /martin From andy@netconfcentral.com Wed Sep 2 04:34:36 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A073A6864 for ; Wed, 2 Sep 2009 04:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFv07EB-edwK for ; Wed, 2 Sep 2009 04:34:36 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id A8A2F28C0DD for ; Wed, 2 Sep 2009 04:32:11 -0700 (PDT) Received: (qmail 71685 invoked from network); 2 Sep 2009 11:19:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 2 Sep 2009 11:19:40 -0000 X-YMail-OSG: uqGTbEgVM1nC4Ez4JdjeqmZThe5NM6VBVACLnyaIEmEkbIobPdvABypU0i3UUYNL6DsKiPr03MiR_TEftyVqiyUDlj8qPJRvuFgOt8urOuRU79M81ygTxHFZbqbxAdB1awShlqsJrAQB7kxfEYhTKlYOMeyGVak2xF4D2n9ce3Xj.pcKGhJwDKbV_ldLshR7DxYjKUoZAuubd6g- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9E54DD.1010002@netconfcentral.com> Date: Wed, 02 Sep 2009 04:19:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <4A95EB78.7000009@netconfcentral.com> <20090827.163003.130650426.mbj@tail-f.com> <4A96ACF7.6010204@netconfcentral.com> <200909021249.43871.david.partain@ericsson.com> In-Reply-To: <200909021249.43871.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 11:34:37 -0000 David Partain wrote: > On Thursday 27 August 2009 17.57.43 Andy Bierman wrote: >> If this filtering was just limited to YANG default-stmts, >> then it would be fine, but it is not. > > I just be really thick, but I thought that's _exactly_ what it was limited to. > maybe you should catch up on the mail threads. We are trying to resolve terminology errors in the with-defaults spec. We were combining poorly written text in with-defaults with the inherently complex YANG document definitions and they did not align correctly. I am not convinced the complexity we continue to pile onto YANG is directly proportional to its usefulness, but one could have said that at 50 pages, 80 pages, 120 pages... > We need to work on the interaction between this and :with-defaults (which > should be done in NETCONF...), but I've never seen anyone suggesting the > server should just magically decide what it will or will not send. > > David Andy From j.schoenwaelder@jacobs-university.de Wed Sep 2 04:55:25 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270673A68DA for ; Wed, 2 Sep 2009 04:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAoxXaCXWthW for ; Wed, 2 Sep 2009 04:55:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0061E3A67AC for ; Wed, 2 Sep 2009 04:55:23 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88A1BC0063; Wed, 2 Sep 2009 13:53:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DSwB4UnFNeZ1; Wed, 2 Sep 2009 13:53:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03D26C0065; Wed, 2 Sep 2009 13:53:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 821A4C8CE51; Wed, 2 Sep 2009 13:53:22 +0200 (CEST) Date: Wed, 2 Sep 2009 13:53:22 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090902115322.GD10753@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "netmod@ietf.org" References: <20090901193508.GA9782@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Configuration Data versus Operational State Data versusStatistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2009 11:55:25 -0000 On Wed, Sep 02, 2009 at 09:53:37AM +0200, Romascanu, Dan (Dan) wrote: > (speaking as a contributor) > > I believe that this is an important subject, and it's good to deal with > it in the architecture document. > > The scope seems to exceed NETCONF architecture. It's good to have the > distinction made and the concepts well defined. My question is however - > what is the role of NETCONF (and YANG) in retrieving or reporting > statistics information? I rather see a future network management > architecture using NETCONF for configuration data. I am not so sure > about operational state data - would it be NETCONF, or rather SNMP doe > operational status retrieval and notifications, or SYSLOG - if we deal > with alarms? Is there a good case to use anything else than SNMP to > retrieve statistics information? There is no explicit NETCONF architecture I am aware of. Second, RFC 4741 explicitely spells out support for configuration data and state data retrieval - this is why we have get and get-config. I think the IETF is ill advised if it wants to mandate which protocol to use for certain data since this will remain a deployment issue taking into account tools available to an operator, the familiarity with protocols and supporting tools, authentication and security 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 david.partain@ericsson.com Wed Sep 2 04:57:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5007528C49B for ; Wed, 2 Sep 2009 04:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0UGq328OlH0 for ; Wed, 2 Sep 2009 04:57:49 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EDA9128C6E4 for ; Wed, 2 Sep 2009 04:56:46 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-21-4a9e597653ef Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 6C.AE.01983.6795E9A4; Wed, 2 Sep 2009 13:39:34 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:39:34 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:39:34 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 2 Sep 2009 13:39:33 +0200 User-Agent: KMail/1.9.10 References: <4A9815FA.9060306@netconfcentral.com> <4A983E80.5090508@netconfcentral.com> <20090828.224008.212827189.mbj@tail-f.com> In-Reply-To: <20090828.224008.212827189.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021339.33850.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 11:39:34.0391 (UTC) FILETIME=[0B220870:01CA2BC2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 11:57:50 -0000 On Friday 28 August 2009 22.40.08 Martin Bjorklund wrote: > Andy Bierman wrote: > > Martin Bjorklund wrote: > > > Andy Bierman wrote: > > >> We all agree that only actual instances of a leaf object > > >> matter here. The whole premise behind filter='explicit' > > >> is that the client does not need to know the server > > >> selected values of these instances because the exact > > >> value the server has selected is described somehow in > > >> the optional-to-use user documentation. > > > > > > You keep saying this, and we keep saying that this is not the way it > > > works. The premise is that the client knows the (static) default > > > value from the "default" statement (if it needs to know it at all). > > > > if this is true, then why does the 'explicit' mode > > of with-defaults just look at whether the leaf was > > explicitly set and not the YANG default? > > I didn't write that draft - you did ;) But I assume that it is > supposed to be DML-agnostic? For me it would be fine to make it > YANG-specific, or at least be very specific that *if* the data model > is written in YANG, it means that it applies to leafs with the > "default" statement that are not explicitly set. Hi all, I agree with Martin here. If we need to add YANGish clarifications to :with-defaults, let's do so (but please talk about it in NETCONF...) Cheers, David From j.schoenwaelder@jacobs-university.de Wed Sep 2 05:04:08 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A93B3A6AC4 for ; Wed, 2 Sep 2009 05:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VNtOjtTlyiV for ; Wed, 2 Sep 2009 05:04:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 920FD28C79A for ; Wed, 2 Sep 2009 05:03:14 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 433F2C005A; Wed, 2 Sep 2009 14:00:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NGZ6KNT6n4Lc; Wed, 2 Sep 2009 14:00:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B10D0C007C; Wed, 2 Sep 2009 14:00:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7741EC8CF22; Wed, 2 Sep 2009 14:00:36 +0200 (CEST) Date: Wed, 2 Sep 2009 14:00:36 +0200 From: Juergen Schoenwaelder To: David Partain Message-ID: <20090902120036.GE10753@elstar.local> Mail-Followup-To: David Partain , "netmod@ietf.org" References: <4A9D7BA2.8020803@netconfcentral.com> <20090901.222850.210872069.mbj@tail-f.com> <4A9D8BDE.1030505@netconfcentral.com> <200909020900.31039.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909020900.31039.david.partain@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Supporting three styles of default handling in with-defaults (was meaning of default) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2009 12:04:08 -0000 On Wed, Sep 02, 2009 at 09:00:30AM +0200, David Partain wrote: > Hi all, > > We're treading in and out of NETCONF territory... > > So, :with-defaults supports three ways of handling defaults (quoting...) > > - report-all: All default data is always reported. > - trim: Values are not reported if they match the default. > - explicit: Report values if they are explicitly set. For state data this has > the same effect as report-all > > Andy argues that YANG cannot support these three different modes. Martin has > agreed that there are issues that need to be addressed, but not that it's > broken in the way Andy claims. I see two things that need to happen: > > 1. If there are problems in the :with-defaults document, they should be fixed > in NETCONF. Proposals are, I'm sure, welcome. > > 2. If there are problems in the YANG spec that make it impossible (I'm > unconvinced) to support all three, please provide textual proposals of what > needs to change. I like to find agreement that NETCONF/YANG lacks proper mechanisms to deal with the distinction of configuration data and operational state data called out for by the operators in RFC 3535. If we can agree on this, we can discuss what needs to be done to solve this problem. For YANG, this might imply that "config true/false" is too simplistic. For NETCONF, it might mean that three different ways to deal with-defaults are not needed - instead we create a proper and clean way to retrieve operational state separately from config state. But the first step is to agree that the problem is of a much more fundamental nature and requires fixes affecting both NETCONF and NETMOD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Sep 2 05:09:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9D03A69D2 for ; Wed, 2 Sep 2009 05:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QLkqh+a-TjT for ; Wed, 2 Sep 2009 05:09:34 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id E72AC3A6B16 for ; Wed, 2 Sep 2009 05:07:16 -0700 (PDT) Received: (qmail 79075 invoked from network); 2 Sep 2009 12:05:02 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 2 Sep 2009 12:05:02 -0000 X-YMail-OSG: BGSJdIQVM1nmHjUtdglG7Fi6PbHZAFDA8dkaaf7UGALf4JGw3eCxMvj6z9aDCiSoTEcH0G7vhZsp12iZ82t6QPgd_RbB8RZT9lg1GaQAHA5a5WW5toWV0Wqo7QRMp7160TMElar2gUAdiHaOmBkVP69wAs3Lm7sA9IR5BtojXAipuOgCMcZW8xBN6HUlb4orNu95XET.Rxs4avCfcgSiF.wucuqFvuF7MUbt5ntqmySlAAgwdesDRv5FNgCAd7Uz7a2OqtVtQtrKf92b93K1V24O85zcYwsCRKso82nrNs6M0y_o X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9E5F7F.1090002@netconfcentral.com> Date: Wed, 02 Sep 2009 05:05:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" References: <20090901193508.GA9782@elstar.local> <000d01ca2bb2$1385f680$0601a8c0@allison> In-Reply-To: <000d01ca2bb2$1385f680$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Configuration Data versus Operational State Data versusStatistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 12:09:35 -0000 tom.petch wrote: > Juergen > > Promising. > > The problem I have is that the primary focus of YANG is the schema tree and > I find the data tree, which I assume is the focus here, ill-defined. When > people > give definitions in terms of a configuration database, I cannot relate it to > the data tree. Here the reference is to datastores which, in YANG, only really > figure in the text we have tidied up as part of XPath. > > How simple this is in SMI; I need something more tangible here. > amen to that! I am not convinced at all that the database management model we have created, laden and dependent on so much meta-cruft, is going to provide any interoperability improvement beyond where we are now with SNMP/SMIv2. It may get much worse instead. I do not agree that SMIv2/SNMP experience and BCPs are irrelevant to NETCONF/YANG. I do not consider a default value to be so special that it warrants all the complexity it is adding to the protocol. There are going to be so many kinds of default data, mandatory data, and optional data, it may be too hard for newbies to learn. > What is the data tree made of ? Is it a pre-requisite that there is a data node > in the schema tree? > > Is there a distinction between its constituent and the value thereof? > > When do its constituents come into being? > > Um > > Tom Petch Andy > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, September 01, 2009 9:35 PM > Subject: [netmod] Configuration Data versus Operational State Data > versusStatistics > > >> Hi, >> >> I propose to add a section to the architecture document defining and >> discussing the difference between configuration data, operational >> state data, and statistics. I attaching some draft writeup explaining >> the background, providing a definition and some examples we discussed >> here on the list. I am also including a section discussing potential >> approaches to deal with operational state data. This is more for >> discussion rather than inclusion in the architecture document. >> >> /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 >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Wed Sep 2 05:09:50 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341F928C0E9 for ; Wed, 2 Sep 2009 05:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AGwraLHUei6 for ; Wed, 2 Sep 2009 05:09:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EFB163A6A0A for ; Wed, 2 Sep 2009 05:09:48 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5318FC0068; Wed, 2 Sep 2009 14:08:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kCj+HyU2Na0u; Wed, 2 Sep 2009 14:08:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08F1AC005A; Wed, 2 Sep 2009 14:08:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8E6C3C8CFAA; Wed, 2 Sep 2009 14:08:44 +0200 (CEST) Date: Wed, 2 Sep 2009 14:08:44 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090902120844.GF10753@elstar.local> Mail-Followup-To: Phil Shafer , "tom.petch" , "netmod@ietf.org" References: <200909011824.n81IOXLk092470@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909011824.n81IOXLk092470@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] proposal : X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2009 12:09:50 -0000 On Tue, Sep 01, 2009 at 08:24:33PM +0200, Phil Shafer wrote: > > There are huge issues with the overlap between config data and > operational data. Trying to model these both in a single YANG > module will be difficult and will introduce some annoying bits of > hackery (like "mtu-configured" .vs. "mtu-right-now"). > > Instead, I propose a new operation for YANG-based models. The > RPC will return operational data associated > with a YANG module. The module name is a mandatory argument to the > RPC, with an optional "revision" argument. In addition, a filter > argument will take a stock NETCONF filter hierarchy. A constructive proposal - thanks! I am not sure why you want to pass the module name; we do not scope get-config by module name either and you can use a filter on the module's namespace. Seems duplicated and also limiting - why can I not retrieve operational state from two related modules in one call? > In response, the server will return a set of XML elements that > follow many of the constraints of the YANG module, but are > freed from a few, in order to allow useful data to be returned. > > A union's "type" statement and the "enum" statement will accept a > "config" statement indicating if this branch of the union will be > accepted for configuration data or only for operational data. > > module foo { > ... > container foo-top { > list interface { > key name; > leaf name { type string; } > leaf mtu { > type int; > default 1024; > } > leaf duplex { > type enumeration { > enum full; > enum half; > enum auto { config true; } > default auto; > } > } > } > } > } > > Alternative: "config" here could be replaced with "operational" and > the value inverted. Is list interface config true or false here? We have to be careful about the usage of keywords since enum auto { config true; } likely is very different from leaf duplex { config true; ... } - I assume this needs more thought to get right. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.com Wed Sep 2 05:18:44 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464B128C553 for ; Wed, 2 Sep 2009 05:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YzPuC-YYATM for ; Wed, 2 Sep 2009 05:18:43 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 75C8D28C6E4 for ; Wed, 2 Sep 2009 05:18:43 -0700 (PDT) Received: (qmail 97002 invoked from network); 2 Sep 2009 12:10:20 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 2 Sep 2009 12:10:19 -0000 X-YMail-OSG: 5RP9T1wVM1l9bFW2UhIIqeUh1L3Ryr4KkrNk.iLHOXvHV6I_vI.HOc75rXyJk4eEOuQWAii89hw.yFLHoKzEYCtVzoa7LCCkxrM1SOI4TurQMN.kI1H7N2WXupwxsvtgCQt4a8..BfwSUiZVeevyaq7uDyqs5pFc032jFdhxM4DiXzPH_XLk63S3UqNltxhCDTnR9UvOfNpgeufTUDf9wY0Mi_mEGr.ncyenbCnmT7obYD4arbMLW8HZ0hu0AnTRWcbwp.tha7GG__uKduQyES2b1Tsl0SEeldHi005uon1d5fqQWvR7j41XfKyFTww9QvDqRTqU.6wJQw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9E60BC.9030900@netconfcentral.com> Date: Wed, 02 Sep 2009 05:10:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <4A9815FA.9060306@netconfcentral.com> <4A983E80.5090508@netconfcentral.com> <20090828.224008.212827189.mbj@tail-f.com> <200909021339.33850.david.partain@ericsson.com> In-Reply-To: <200909021339.33850.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 12:18:44 -0000 David Partain wrote: > On Friday 28 August 2009 22.40.08 Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Martin Bjorklund wrote: >>>> Andy Bierman wrote: >>>>> We all agree that only actual instances of a leaf object >>>>> matter here. The whole premise behind filter='explicit' >>>>> is that the client does not need to know the server >>>>> selected values of these instances because the exact >>>>> value the server has selected is described somehow in >>>>> the optional-to-use user documentation. >>>> You keep saying this, and we keep saying that this is not the way it >>>> works. The premise is that the client knows the (static) default >>>> value from the "default" statement (if it needs to know it at all). >>> if this is true, then why does the 'explicit' mode >>> of with-defaults just look at whether the leaf was >>> explicitly set and not the YANG default? >> I didn't write that draft - you did ;) Actually, the draft I submitted was much simpler and much more clear than what the WG has now. It was a simple boolean for a simple concept (do you want the defaults or not?) But I assume that it is >> supposed to be DML-agnostic? For me it would be fine to make it >> YANG-specific, or at least be very specific that *if* the data model >> is written in YANG, it means that it applies to leafs with the >> "default" statement that are not explicitly set. > > Hi all, > > I agree with Martin here. If we need to add YANGish clarifications > to :with-defaults, let's do so (but please talk about it in NETCONF...) > sure -- but IMO what mailing list we use is irrelevant. The with-defaults draft needs to align with YANG definitions, so do we send an email to NETCONF if we just refer to the parameter, but send the email to NETMOD if we ask about the meaning of a default? > Cheers, > > David Andy From lhotka@cesnet.cz Wed Sep 2 05:34:35 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0CC3A68EE for ; Wed, 2 Sep 2009 05:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPjyrbnASPB8 for ; Wed, 2 Sep 2009 05:34:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 438133A68BE for ; Wed, 2 Sep 2009 05:34:34 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 05E1FD800CE; Wed, 2 Sep 2009 14:03:20 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090902114347.GC10753@elstar.local> References: <20090901193508.GA9782@elstar.local> <1251878022.12476.77.camel@missotis> <20090902114347.GC10753@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Sep 2009 14:03:18 +0200 Message-Id: <1251892998.12476.119.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Configuration Data versus Operational State Data versus Statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 12:34:35 -0000 Juergen Schoenwaelder píše v St 02. 09. 2009 v 13:43 +0200: > On Wed, Sep 02, 2009 at 09:53:42AM +0200, Ladislav Lhotka wrote: > > > > > In the second paragraph of Example 2 you write: > > > > "However, there are usually provisions to overwrite the discovered > > attributes with static configuration data, ..." > > > > Depending on implementation, operational state and configuration > > parameters may be so tightly coupled that they are effectively > > indistinguishable. For example, I can directly write certain values in > > the /proc filesystem, so they are by definition configuration data, but > > the write immediately changes operational data in the kernel. > > Conversely, any change of such a parameter in the kernel is immediately > > reflected in the /proc filesystem. > > Writing to /proc changes operational state - the act of writing to > /proc does not consitute creation of configuration. Writing to /proc > becomes configuration if you create a persistent config file that > writes to /proc again when the box reloads its configuration. If an in-memory database is allowed as the configuration datastore, it could be coupled with the internal parameters in a similar way as in the /proc filesystem, and persistence can be also guaranteed. Perhaps we should really treat configuration as a "config file", or XML document in the NETCONF context. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.partain@ericsson.com Wed Sep 2 05:44:30 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3EC3A67AC for ; Wed, 2 Sep 2009 05:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.691 X-Spam-Level: X-Spam-Status: No, score=-3.691 tagged_above=-999 required=5 tests=[AWL=-1.442, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRr6J8XKFEyC for ; Wed, 2 Sep 2009 05:44:29 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 901943A6AB2 for ; Wed, 2 Sep 2009 05:42:26 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-ff-4a9e5b0640bc Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 9A.81.18827.60B5E9A4; Wed, 2 Sep 2009 13:46:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:46:13 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:46:13 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 2 Sep 2009 13:46:13 +0200 User-Agent: KMail/1.9.10 References: <4A95EB78.7000009@netconfcentral.com> <200909021249.43871.david.partain@ericsson.com> <4A9E54DD.1010002@netconfcentral.com> In-Reply-To: <4A9E54DD.1010002@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021346.13387.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2009 11:46:13.0905 (UTC) FILETIME=[F9430810:01CA2BC2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 12:44:30 -0000 On Wednesday 02 September 2009 13.19.57 Andy Bierman wrote: > David Partain wrote: > > On Thursday 27 August 2009 17.57.43 Andy Bierman wrote: > >> If this filtering was just limited to YANG default-stmts, > >> then it would be fine, but it is not. > > > > I just be really thick, but I thought that's _exactly_ what it was > > limited to. > > maybe you should catch up on the mail threads. > We are trying to resolve terminology errors in > the with-defaults spec. We were combining > poorly written text in with-defaults > with the inherently complex YANG document definitions > and they did not align correctly. Thanks, Andy. I'm perfectly aware of what the discussion is about. David From lhotka@cesnet.cz Wed Sep 2 05:51:58 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636273A6AB7 for ; Wed, 2 Sep 2009 05:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6SFNz18y3hn for ; Wed, 2 Sep 2009 05:51:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C1CE63A68EE for ; Wed, 2 Sep 2009 05:51:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D0FCCD800EF; Wed, 2 Sep 2009 14:16:37 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090902.134448.165255613.mbj@tail-f.com> References: <000a01ca2bb2$10ce2980$0601a8c0@allison> <20090902.131612.177280550.mbj@tail-f.com> <1251891606.12476.104.camel@missotis> <20090902.134448.165255613.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Sep 2009 14:16:36 +0200 Message-Id: <1251893796.12476.129.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Issue: add 'assigned-by system' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 12:51:58 -0000 Martin Bjorklund píše v St 02. 09. 2009 v 13:44 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v St 02. 09. 2009 v 13:16 +0200: > > > "tom.petch" wrote: > > > > So is this 'system will assign' a MAY, MUST, SHOULD? > > > > > > Open question. See below. > > > > > > > And is it immediate ancestor only? I am thinking of the complex > > > > nested stack one gets with physical and logical interfaces, with the > > > > server allocating VCs at the bottom of the stack. > > > > > > Yes, ancestor only (modulo NP-containers). > > > > > > > Last time around, we spent time discussing the interaction with > > > > default and mandatory, but I see these two as incompatible > > > > with assigned-by-system > > > > if default means a value that the server MUST use and mandatory > > > > means the client MUST supply (disagree with these two, but suspect > > > > that these are the current view). > > > > > > (See also > > > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html) > > > > > > Here are some alternatives: > > > > > > A. Keep the current text about mandatory, and allow the combination > > > assigned-by system and mandatory true. The combination then > > > means that the server MUST assign a value if the client doesn't. > > > If assigned-by system mandatory is false, the server MAY assign a > > > value. > > > > > > In this case, default would be ok if mandatory is false. If the > > > server did not assign a value the default applies. > > > > > > B. Change mandatory to mean that the client MUST set it. This > > > rules out the combination assigned-by system and mandatory true. > > > > > > B.1 B + assigned-by system means MUST assign > > > This rules out the combination assigned-by system and default > > > > > > B.2 B + assigned-by system means MAY assign > > > The combination assigned-by system and default would be ok. > > > > > > > > > A gives most flexibility, but is also more error-prone. B.1 seems to > > > be the most straight forward solution if we don't want to do A. > > > > I want to do A. Why is it error-prone? > > It adds complexity, and the interactions may be subtle. IMO, it is exactly the case A where interactions are minimal or none - 'mandatory' and 'default' address static configurations whereas 'assigned-by' addresses workflow. In particular, 'assigned-by' is irrelevant for the validation of a configuration. Lada > > This said, I prefer A as well. > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Sep 2 05:54:40 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7473A6AF6 for ; Wed, 2 Sep 2009 05:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEUsAkyTSKc5 for ; Wed, 2 Sep 2009 05:54:39 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id A2B843A68DA for ; Wed, 2 Sep 2009 05:54:39 -0700 (PDT) Received: (qmail 1319 invoked from network); 2 Sep 2009 12:47:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 2 Sep 2009 12:47:11 -0000 X-YMail-OSG: a4wtnoEVM1kB6LCRkQj_EdZ7rv2R5SA4JoAUpshrAb9oYbH2zAu4xZLj3UXIayUM.o7ZMJow1EMM2e0Sh0sYcXKM93ivFja_AY6ivV_Hp.1lDpvJtm.xOmej4.CAd588YGzQpOJoUH96egKQZESj8gTlKy9YVET6HMHg5h5PmOsX_6XoRBxrQrIaQjdMnqIj.jrn6nTB.6bs9sk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9E68E7.3030801@netconfcentral.com> Date: Wed, 02 Sep 2009 05:45:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <200908280510.n7S5ApVq031830@idle.juniper.net> <4A978928.3070802@netconfcentral.com> <200909021310.40777.david.partain@ericsson.com> In-Reply-To: <200909021310.40777.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 12:54:40 -0000 David Partain wrote: > Hi, > > On Friday 28 August 2009 09.37.12 Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> If the server can synthesize the value of a leaf for the purposes >>>> of validation and XPath, that it can do the same for the >>>> purposes of retrieval. >>> We've traveled this road before. The issue isn't that the server >>> cannot supply default values, it's that it should not supply them. >> Again -- it is up to the client to decide what >> the client wants to retrieve, not the server. > > My take is that we really need :with-defaults... > I think it was much cleaner as a boolean. Retrieve YANG defaults? (yes/no) [d:no] >> Again -- documentation for what the server should contain >> is not the same as retrieval of the data that the server actually contains. >> Documentation is purely optional in YANG anyway. > > Andy, you keep talking about "offline documentation" or "vendor > documentation". I'm clearly missing something. I don't see that we're > talking about "vendor documentation" but rather the YANG data model. You > can't do anything rational with SNMP without the MIB, either. If the client > doesn't have the YANG data model, we're trashed anyway, aren't we? Why is it > so onerous to look at what 'default' statements are in the data model? > IMO, this is more complicated to use, and not nearly as robust as SNMP. As Tom alluded to, you have to save the server capabilities and extracted defaults out of the YANG modules+deviations, along with the 'real' data, just to backup a configuration. You need very complicated software and a deterministic set of meta-data just to extract the current configuration/state/whatever from a device. The only way to be sure a device is using the default is to set every server-assigned leaf to its default, just so you can read back the value you set. This is extra work on both ends for no reason. The deviations and no-revision-is-OK problems make the meta-data set almost deterministic and almost complete, at best. That's not good enough for backup purposes. I have not met anybody (so far) that believes for a second that vendors will publish their deviation files, so relying on deviations (especially in the critical path) seems problematic to me. > Thanks. > > David Andy From andy@netconfcentral.com Wed Sep 2 06:03:05 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C62C28C6DD for ; Wed, 2 Sep 2009 06:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuEx8-1YwvDT for ; Wed, 2 Sep 2009 06:03:04 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id C092128C0FA for ; Wed, 2 Sep 2009 06:02:37 -0700 (PDT) Received: (qmail 77221 invoked from network); 2 Sep 2009 13:01:42 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 2 Sep 2009 13:01:42 -0000 X-YMail-OSG: oleJj3AVM1k7LWLJSKzxvrx5yntYWB6GIaG1NZ7JVzfHpWBcO6QtrrrmnJIo3X5x7DCdV7ovUd4IyjT606iZ7AFPzrPf4syIVpK2eO9tZ8POkGXDN83eVBELohvA6p_X8xrrGwsOhpbILKN6NION7vKjfIsnpMerrgunsYhzsMt8ZQYS9dsLwv4wVQuEBS.v9DmSwaoQJPwWgMZ1swx3Zyc.00hRWZFP7AAphh6U3B9PwU9S2QGw1CiAU6GeK_xn6awEY2g8WomsT.0_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9E6C4F.6090108@netconfcentral.com> Date: Wed, 02 Sep 2009 05:59:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Partain References: <4A95EB78.7000009@netconfcentral.com> <200909021249.43871.david.partain@ericsson.com> <4A9E54DD.1010002@netconfcentral.com> <200909021346.13387.david.partain@ericsson.com> In-Reply-To: <200909021346.13387.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Configuration nodes was Re: meaning of defau X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 13:03:05 -0000 David Partain wrote: > On Wednesday 02 September 2009 13.19.57 Andy Bierman wrote: >> David Partain wrote: >>> On Thursday 27 August 2009 17.57.43 Andy Bierman wrote: >>>> If this filtering was just limited to YANG default-stmts, >>>> then it would be fine, but it is not. >>> I just be really thick, but I thought that's _exactly_ what it was >>> limited to. >> maybe you should catch up on the mail threads. >> We are trying to resolve terminology errors in >> the with-defaults spec. We were combining >> poorly written text in with-defaults >> with the inherently complex YANG document definitions >> and they did not align correctly. > > Thanks, Andy. I'm perfectly aware of what the discussion is about. > great then -- glad you can join us. The threads are way too long and repetitive. It would be great if they were resolved sooner. I am having a hard time believing that Joel and I misinterpreted the meaning of 'explicit' with-defaults retrieval so incorrectly. We repeatedly asked if this referred just to nodes set by the client, and were told yes. We asked, will server-created leaf instances that do not contain the YANG default-stmt value be returned? We were told no. Now we are told the opposite, that 'explicit' means set by the client AND the server (who's left?) and all server-created leaf instances are returned in a . Explicit just means: "if the client set it, return it, even if the value is the YANG default". This was not made clear until recently. > David Andy From j.schoenwaelder@jacobs-university.de Wed Sep 2 06:31:18 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BBA3A6B4F for ; Wed, 2 Sep 2009 06:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUXlAMQ9Yqzk for ; Wed, 2 Sep 2009 06:31:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2C413A6C0F for ; Wed, 2 Sep 2009 06:31:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F3D9C0059; Wed, 2 Sep 2009 13:43:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id stvwFlVJiA9y; Wed, 2 Sep 2009 13:43:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B357BC0019; Wed, 2 Sep 2009 13:43:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 45E59C8CE09; Wed, 2 Sep 2009 13:43:47 +0200 (CEST) Date: Wed, 2 Sep 2009 13:43:47 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090902114347.GC10753@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20090901193508.GA9782@elstar.local> <1251878022.12476.77.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1251878022.12476.77.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Configuration Data versus Operational State Data versus Statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2009 13:31:18 -0000 On Wed, Sep 02, 2009 at 09:53:42AM +0200, Ladislav Lhotka wrote: > > In the second paragraph of Example 2 you write: > > "However, there are usually provisions to overwrite the discovered > attributes with static configuration data, ..." > > Depending on implementation, operational state and configuration > parameters may be so tightly coupled that they are effectively > indistinguishable. For example, I can directly write certain values in > the /proc filesystem, so they are by definition configuration data, but > the write immediately changes operational data in the kernel. > Conversely, any change of such a parameter in the kernel is immediately > reflected in the /proc filesystem. Writing to /proc changes operational state - the act of writing to /proc does not consitute creation of configuration. Writing to /proc becomes configuration if you create a persistent config file that writes to /proc again when the box reloads its configuration. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Sep 2 07:09:53 2009 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252A13A6C8A for ; Wed, 2 Sep 2009 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd9FboiRSs9F for ; Wed, 2 Sep 2009 07:09:52 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id EE7623A6824 for ; Wed, 2 Sep 2009 07:09:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSp58kG3KpvgiIBraWX4SDhywd3x6t59i@postini.com; Wed, 02 Sep 2009 07:10:08 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 2 Sep 2009 06:59:24 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 06:59:24 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 06:59:24 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 06:59:23 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n82DxMd44311; Wed, 2 Sep 2009 06:59:23 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n82DlHsa004215; Wed, 2 Sep 2009 13:47:17 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200909021347.n82DlHsa004215@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251878022.12476.77.camel@missotis> Date: Wed, 2 Sep 2009 09:47:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Sep 2009 13:59:23.0561 (UTC) FILETIME=[9377C990:01CA2BD5] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Configuration Data versus Operational State Data versus Statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 14:09:53 -0000 Ladislav Lhotka writes: >Depending on implementation, operational state and configuration >parameters may be so tightly coupled that they are effectively >indistinguishable. For example, I can directly write certain values in >the /proc filesystem, so they are by definition configuration data, but >the write immediately changes operational data in the kernel. >Conversely, any change of such a parameter in the kernel is immediately >reflected in the /proc filesystem. There is writable data that is not configuration data. Examples: - file system contents - software images - EPROM contents - the time in "shutdown at