From mbj@tail-f.com Sat Aug 1 01:26: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 59CBF3A6925 for ; Sat, 1 Aug 2009 01:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.214, 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 We9joLnEBS8A for ; Sat, 1 Aug 2009 01:26:48 -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 862573A6A5A for ; Sat, 1 Aug 2009 01:26:48 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 33BCD76C54A; Sat, 1 Aug 2009 10:26:49 +0200 (CEST) Date: Sat, 01 Aug 2009 10:07:05 +0200 (CEST) Message-Id: <20090801.100705.211039634.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A7345E4.9000508@netconfcentral.com> References: <4A7316BA.5090308@netconfcentral.com> <20090731.211656.192693069.mbj@tail-f.com> <4A7345E4.9000508@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] prefixes in groupings example 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: Sat, 01 Aug 2009 08:26:49 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> This text does not fully address the example I posted (footest2.yang). > >> > >> The problem is more complicated than just must/when expressions. > >> > >> If the local prefix is not used (the normal use-case), then > >> the module with the uses-stmt will be used to find > >> identities and types, and resolve the default-stmt. > >> This is broken. > > > > I agree that this would be broken. But that is not how it works. I > > was a bit unclear in my quote of the proposed text -- the text was > > from section 6.4.1, the XPath context, which applies to must/when/path > > only. Below I have attached the complete text for this section. The > > rules for non-xpath statements are the same as before. > > > > how does this apply to types and identityrefs, and defaults? It does not change. [...] > Before, all of these statements that use QNames will use the > module that defined the statement as the local module, > to resolve the missing prefix . Yes. > Now these are all changing too, right? No. > Are you saying that some prefixes (or missing prefixes) > inside a grouping will mean one thing, and mean another > thing just inside must/when statements? They already do. In YANG statements, the prefix refers to a module (or even a particular version of a module). In XPath, the prefix refers to an XML namespaces. For a module designer, the simple rule of thumb is "do not use prefixes for local references" (which also saves typing and makes the module easier to read). /martin From lhotka@cesnet.cz Sat Aug 1 04:14: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 088063A681A for ; Sat, 1 Aug 2009 04:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=0.113, 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 rQgT61ZS-vrD for ; Sat, 1 Aug 2009 04:14:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B19C13A6946 for ; Sat, 1 Aug 2009 04:14:05 -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 BF765D80096; Sat, 1 Aug 2009 13:13:56 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200907302333.n6UNXiI7047938@idle.juniper.net> References: <200907302333.n6UNXiI7047938@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 01 Aug 2009 13:13:55 +0200 Message-Id: <1249125235.8328.15.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] mandatory mess 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: Sat, 01 Aug 2009 11:14:36 -0000 Phil Shafer píše v Čt 30. 07. 2009 v 19:33 -0400: > Ladislav Lhotka writes: > >So one has to come to the conclusion in this case that a mandatory node > >has to be set by the client in order to get into the datastore and thus > >cannot be supplied by the server in an "initial factory setting". > > I don't grok the hangup here, but perhaps if you view it > this way it will help. On some boxes, when the startup > mechanism notices that the configuration database is empty, > a "local client application" is triggered that loads some > factory default configuration into the configuration database. > And this "local client" need not be a NETCONF client, it > can be something as mundane as: > > [ -s $config ] || cp $factory_defaults $config So if I unwrap my device and switch it on, mandatory (and perhaps some other) nodes are filled in. Now: 1. Is this factory default configuration (part of) the 'initial default state' that RFC 4741 talks about? 2. Will the values set this way be returned in get-config having with-defaults=false? 3. Is it possible that this factory default configuration sets some optional leafs to values that differ from the defaults specified in the data model? Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Sat Aug 1 04:37: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 4240F3A68AD for ; Sat, 1 Aug 2009 04:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.100, 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 uRntCiEactLu for ; Sat, 1 Aug 2009 04:37:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7B7D83A68A4 for ; Sat, 1 Aug 2009 04:37:12 -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 5193FD80096; Sat, 1 Aug 2009 13:37:14 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090801.100705.211039634.mbj@tail-f.com> References: <4A7316BA.5090308@netconfcentral.com> <20090731.211656.192693069.mbj@tail-f.com> <4A7345E4.9000508@netconfcentral.com> <20090801.100705.211039634.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 01 Aug 2009 13:37:12 +0200 Message-Id: <1249126632.8328.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sat, 01 Aug 2009 11:37:13 -0000 Martin Bjorklund píše v So 01. 08. 2009 v 10:07 +0200: > > Are you saying that some prefixes (or missing prefixes) > > inside a grouping will mean one thing, and mean another > > thing just inside must/when statements? > > They already do. In YANG statements, the prefix refers to a module > (or even a particular version of a module). In XPath, the prefix > refers to an XML namespaces. Or putting it differently: names in XPath expressions refer to nodes in the instance data tree, other names refer to "schema objects" (nodes, typedefs, groupings, identities, ...). Lada > > For a module designer, the simple rule of thumb is "do not use > prefixes for local references" (which also saves typing and makes the > module easier to read). > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sat Aug 1 08:10: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 79F113A67B6 for ; Sat, 1 Aug 2009 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 j+5A2MuqyRIF for ; Sat, 1 Aug 2009 08:10:44 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 9CCA93A682D for ; Sat, 1 Aug 2009 08:10:44 -0700 (PDT) Received: from [68.142.200.225] by n18.bullet.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 15:10:43 -0000 Received: from [68.142.201.241] by t6.bullet.mud.yahoo.com with NNFMP; 01 Aug 2009 15:10:43 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 15:10:43 -0000 X-Yahoo-Newman-Id: 232787.70532.bm@omp402.mail.mud.yahoo.com Received: (qmail 72220 invoked from network); 1 Aug 2009 15:10:42 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 1 Aug 2009 15:10:42 -0000 X-YMail-OSG: aZmErN0VM1nawXfQa.9lu.wcTWnGJcah6S4bABv1M4OplFgoJH6iCLGcwZRyngn5cw9z53rtU7_uUki.SlCPaPsZmBsKW99fjWu0RiAo3hsjSmtNjbC93fTTsDinudgS2R3dR_1QFNxcHtpV7MNJBRzN664tv59ZiKrQe2wfl8MthVwIjKwe7kdF6uH_nzoYkiih2fUeVaiZpP9zOoQC4QjgGaoIkGZzye8rUtK8KXe5AfLr5ncnjPSyzYAY18lBM3eziKX0h4jZon7hQQVyalaVZBJNMXuX0KyMqNiJJt1JIwuB.8trISFuuuBbkfzbdzO7N6hn64M- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A745B05.6000001@netconfcentral.com> Date: Sat, 01 Aug 2009 08:11:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7316BA.5090308@netconfcentral.com> <20090731.211656.192693069.mbj@tail-f.com> <4A7345E4.9000508@netconfcentral.com> <20090801.100705.211039634.mbj@tail-f.com> In-Reply-To: <20090801.100705.211039634.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sat, 01 Aug 2009 15:10:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> This text does not fully address the example I posted (footest2.yang). >>>> >>>> The problem is more complicated than just must/when expressions. >>>> >>>> If the local prefix is not used (the normal use-case), then >>>> the module with the uses-stmt will be used to find >>>> identities and types, and resolve the default-stmt. >>>> This is broken. >>> I agree that this would be broken. But that is not how it works. I >>> was a bit unclear in my quote of the proposed text -- the text was >>> from section 6.4.1, the XPath context, which applies to must/when/path >>> only. Below I have attached the complete text for this section. The >>> rules for non-xpath statements are the same as before. >>> >> how does this apply to types and identityrefs, and defaults? > > It does not change. > > [...] > >> Before, all of these statements that use QNames will use the >> module that defined the statement as the local module, >> to resolve the missing prefix . > > Yes. > >> Now these are all changing too, right? > > No. > Well -- this is broken. Why is it OK for a prefix in a default-stmt to do the wrong thing, but not a must-stmt? IMO, your proposal is extremely fragile and impossible for off-the-shelf tools to implement. It is also broken, since the exact same QName used in a default-stmt (my-identity in the example) will be treated differently in a must or when statement. Can you explain why you think only the prefixes in an XPath expression are a problem, but not other uses of the local prefix? Andy >> Are you saying that some prefixes (or missing prefixes) >> inside a grouping will mean one thing, and mean another >> thing just inside must/when statements? > > They already do. In YANG statements, the prefix refers to a module > (or even a particular version of a module). In XPath, the prefix > refers to an XML namespaces. > > For a module designer, the simple rule of thumb is "do not use > prefixes for local references" (which also saves typing and makes the > module easier to read). > > > /martin > From lhotka@cesnet.cz Sat Aug 1 09:16: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 56F573A6971 for ; Sat, 1 Aug 2009 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.082, 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 ssxU6RpqA8DD for ; Sat, 1 Aug 2009 09:16:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 83D0F3A6403 for ; Sat, 1 Aug 2009 09:16:48 -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 53590D800BD; Sat, 1 Aug 2009 18:16:50 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A745B05.6000001@netconfcentral.com> References: <4A7316BA.5090308@netconfcentral.com> <20090731.211656.192693069.mbj@tail-f.com> <4A7345E4.9000508@netconfcentral.com> <20090801.100705.211039634.mbj@tail-f.com> <4A745B05.6000001@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 01 Aug 2009 18:16:48 +0200 Message-Id: <1249143408.14644.55.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sat, 01 Aug 2009 16:16:49 -0000 Andy Bierman píše v So 01. 08. 2009 v 08:11 -0700: > > Well -- this is broken. > Why is it OK for a prefix in a default-stmt to do > the wrong thing, but not a must-stmt? > IMO, your proposal is extremely fragile > and impossible for off-the-shelf tools to implement. Why? The implementation just has to be careful about the context in which QNames (actually only those without any prefix) are used. > > It is also broken, since the exact same QName used > in a default-stmt (my-identity in the example) > will be treated differently in a must or when statement. This is because the use of prefixes is overloaded. QNames inside XPath expressions point to qualitatively different things than those outside. > > Can you explain why you think only the prefixes in > an XPath expression are a problem, but not other > uses of the local prefix? All prefixes (be they in XPath or not, in a grouping or not) are resolved in the module where they appear. Only the handling of names without prefixes differs because we want the late binding for names of data nodes in groupings. This late binding of course must not happen for names schema objects. However, these two cases are easily separable on the basis of the statement in which they appear. Lada > > > Andy > > > >> Are you saying that some prefixes (or missing prefixes) > >> inside a grouping will mean one thing, and mean another > >> thing just inside must/when statements? > > > > They already do. In YANG statements, the prefix refers to a module > > (or even a particular version of a module). In XPath, the prefix > > refers to an XML namespaces. > > > > For a module designer, the simple rule of thumb is "do not use > > prefixes for local references" (which also saves typing and makes the > > module easier to read). > > > > > > /martin > > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sat Aug 1 09:37: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 EF66B3A696F for ; Sat, 1 Aug 2009 09:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 98wge7CjSenS for ; Sat, 1 Aug 2009 09:37:49 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id 10C713A692B for ; Sat, 1 Aug 2009 09:37:49 -0700 (PDT) Received: from [68.142.200.225] by n14.bullet.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 16:37:49 -0000 Received: from [68.142.201.66] by t6.bullet.mud.yahoo.com with NNFMP; 01 Aug 2009 16:37:49 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 01 Aug 2009 16:37:48 -0000 X-Yahoo-Newman-Id: 986189.35596.bm@omp418.mail.mud.yahoo.com Received: (qmail 78798 invoked from network); 1 Aug 2009 16:37:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 1 Aug 2009 16:37:48 -0000 X-YMail-OSG: 4DJ1dUwVM1lXTI1F.8IOnBfFPZ6nkZObJDc8SvtDGbkRHXloDIkDfXeya_5Hw.E.zjyz0bnWxg8GhG5Q9z.TcdPBTFqGhGOwEO4z0a1.0OLHOFVO1hu8QnKdDwx4VEsJYdc6w4mRERfPgxLqyt2a_vOfRsMMJJj9d_50oB0a8SsVmjdQhSkSNbtkvaqml_u5B1dtQ_Ppj4ZookW_84ejHYD9_uFO2HQXmWpeGTJW95MRDOAt7JWEaEBiohno2nTnb1HPZ7N5AmYmsA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A746F6F.7040707@netconfcentral.com> Date: Sat, 01 Aug 2009 09:38:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A7316BA.5090308@netconfcentral.com> <20090731.211656.192693069.mbj@tail-f.com> <4A7345E4.9000508@netconfcentral.com> <20090801.100705.211039634.mbj@tail-f.com> <4A745B05.6000001@netconfcentral.com> <1249143408.14644.55.camel@missotis> In-Reply-To: <1249143408.14644.55.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sat, 01 Aug 2009 16:37:50 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v So 01. 08. 2009 v 08:11 -0700: > >> Well -- this is broken. >> Why is it OK for a prefix in a default-stmt to do >> the wrong thing, but not a must-stmt? >> IMO, your proposal is extremely fragile >> and impossible for off-the-shelf tools to implement. > > Why? The implementation just has to be careful about the context in > which QNames (actually only those without any prefix) are used. > >> It is also broken, since the exact same QName used >> in a default-stmt (my-identity in the example) >> will be treated differently in a must or when statement. > > This is because the use of prefixes is overloaded. QNames inside XPath > expressions point to qualitatively different things than those outside. > >> Can you explain why you think only the prefixes in >> an XPath expression are a problem, but not other >> uses of the local prefix? > > All prefixes (be they in XPath or not, in a grouping or not) are > resolved in the module where they appear. Only the handling of names > without prefixes differs because we want the late binding for names of > data nodes in groupings. This late binding of course must not happen for > names schema objects. However, these two cases are easily separable on > the basis of the statement in which they appear. > Look at the example I posted. The ambiguity for no-prefix resolution exists everywhere. Your proposal will only make things worse by creating special rules for some statements, while leaving other statements in the same grouping broken. The prefixes are not special because they are in must/when expressions. These are NOT XML prefixes at all. They are within a YANG module, and they are using YANG prefixes, not XML prefixes. The mapping from YANG module namespace to XML namespace is an implementation detail that applies to every part of YANG, not just must/when statements. > Lada > Andy >> >> Andy >> >> >>>> Are you saying that some prefixes (or missing prefixes) >>>> inside a grouping will mean one thing, and mean another >>>> thing just inside must/when statements? >>> They already do. In YANG statements, the prefix refers to a module >>> (or even a particular version of a module). In XPath, the prefix >>> refers to an XML namespaces. >>> >>> For a module designer, the simple rule of thumb is "do not use >>> prefixes for local references" (which also saves typing and makes the >>> module easier to read). >>> >>> >>> /martin >>> >> From mbj@tail-f.com Sat Aug 1 12:49: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 458283A681E for ; Sat, 1 Aug 2009 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.204, 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 yoYYxOQSYOWf for ; Sat, 1 Aug 2009 12:49:35 -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 39C153A6B80 for ; Sat, 1 Aug 2009 12:49:01 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id AA73276C54A; Sat, 1 Aug 2009 21:49:01 +0200 (CEST) Date: Sat, 01 Aug 2009 21:49:01 +0200 (CEST) Message-Id: <20090801.214901.199335718.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A746F6F.7040707@netconfcentral.com> References: <4A745B05.6000001@netconfcentral.com> <1249143408.14644.55.camel@missotis> <4A746F6F.7040707@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] prefixes in groupings example 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: Sat, 01 Aug 2009 19:49:36 -0000 Andy Bierman wrote: > The prefixes are not special because they are in must/when > expressions. These are NOT XML prefixes at all. They > are within a YANG module, and they are using YANG prefixes, > not XML prefixes. No they *are* different in XPath than in ordinary YANG statements. In XPath they are used to map to an XML namespace, in YANG statements they are used to map to a (specific version of a) YANG module. At this point I am not sure I understand your objection. Do you think that there are technical problems with the solution? If so, what are they? /martin From j.schoenwaelder@jacobs-university.de Sat Aug 1 14:56: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 074B63A67B5 for ; Sat, 1 Aug 2009 14:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 NZbjPmkilL8G for ; Sat, 1 Aug 2009 14:56:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2C0623A6BBF for ; Sat, 1 Aug 2009 14:54:29 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C70DC0013; Sat, 1 Aug 2009 23:54:31 +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 I4yGGubDOyeu; Sat, 1 Aug 2009 23:54:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E4DCC000C; Sat, 1 Aug 2009 23:54:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 74091B7420B; Sat, 1 Aug 2009 23:54:30 +0200 (CEST) Date: Sat, 1 Aug 2009 23:54:30 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090801215430.GA18163@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A721FFB.9090500@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Sat, 01 Aug 2009 21:56:42 -0000 On Fri, Jul 31, 2009 at 12:34:35AM +0200, Andy Bierman wrote: > Uh-oh, another detail: Should 'yang' really be 'netmod'? IMO, yes. > The naming authority is the NETMOD WG, not the YANG language. Its called yang because the module is yang. The naming authority is the IETF. > namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-03 > namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-04 > namespace urn:ietf:params:xml:ns:netmod:DRAFT:bar-00 > > So what is a real YANG module URN supposed to look like? > > namespace urn:ietf:params:xml:ns:netmod:RFC5991:foo > namespace urn:ietf:params:xml:ns:netmod:RFC6210:foo > namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar No. > Where is this registry and template defined? In the YANG language definition. /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 Sat Aug 1 15:20: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 7D1013A6B38 for ; Sat, 1 Aug 2009 15:20:12 -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 7SaHSlp05ngH for ; Sat, 1 Aug 2009 15:20:11 -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 5D94E3A6BC3 for ; Sat, 1 Aug 2009 15:19:54 -0700 (PDT) Received: (qmail 5749 invoked from network); 1 Aug 2009 22:19:55 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 1 Aug 2009 22:19:54 -0000 X-YMail-OSG: 2Jc0cAsVM1npNq1he086uEhXsE8XiLQfRwQxIgkx1L.bW0mtHowvapdcjbmcstjBzMWSzIn6hNmk3BSUuhEIAmpW4UMV4lFulkEC6rDpvqwkL_HlemgXd4LuD3N30gmlfsAJHvDfnDHLLEm.UD01_XjZpFHFxvX.Uk_MuHLEn3ewirF8oPIYG6S8XlkKCpz_ENx.FBW04N21SmczZJOAkbrbM34sb9wVDvrBI08xZLMCZWfqoBJBNcaYxRShCGrJ9HECBR4HV.719Zb7vXi7SDb1oC3j_23shjg2MfEqy7Z5MtEPmL7lf7HrhbPdxp_j4athLAWq2IE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A74BF9F.4060203@netconfcentral.com> Date: Sat, 01 Aug 2009 15:20:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A745B05.6000001@netconfcentral.com> <1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com> <20090801.214901.199335718.mbj@tail-f.com> In-Reply-To: <20090801.214901.199335718.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sat, 01 Aug 2009 22:20:12 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> The prefixes are not special because they are in must/when >> expressions. These are NOT XML prefixes at all. They >> are within a YANG module, and they are using YANG prefixes, >> not XML prefixes. > > No they *are* different in XPath than in ordinary YANG statements. In > XPath they are used to map to an XML namespace, in YANG statements > they are used to map to a (specific version of a) YANG module. > That seems irrelevant to me. > At this point I am not sure I understand your objection. Do you think > that there are technical problems with the solution? If so, what are > they? > must and when statements are not the only YANG constructs that can be defined within a grouping that can have an implied prefix. mod 1: prefix foo1; grouping ggg { container test-top { leaf bar { type uint8; } leaf baz { must "../goo = 'my-identity' and . > 42"; type MyType; } leaf goo { type identityref { base MyBase; } default my-identity; } } } mod 2: prefix foo; container one { uses foo1:ggg; } } In this example, the must expression will reference the foo:my-identity definition, but the default references the foo1:my-identity. This is not obvious at all. The type-stmt references the foo1:MyType typedef for leaf 'goo', but in XPath the leaf 'goo' will use the other definition of MyType, which is a boolean, not an int32. This seems broken to me. > > /martin > Andy From andy@netconfcentral.com Sat Aug 1 18:34: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 7973A3A68CC for ; Sat, 1 Aug 2009 18:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_36=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 fqp8NFIwcLIz for ; Sat, 1 Aug 2009 18:34:44 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id C9F203A67E6 for ; Sat, 1 Aug 2009 18:34:44 -0700 (PDT) Received: (qmail 39136 invoked from network); 2 Aug 2009 01:34:44 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 2 Aug 2009 01:34:44 -0000 X-YMail-OSG: CtztEDwVM1nA.F2YDj7nEJqbSix3QAqKECiCF7NvNd0PcDzAPQiWUSkXod7EqpXb07uyaYo5mOnZgW6Ki062Oo1qz0g4bIvNK0vJK7m_.hn6sH77wbASrMYgaUhT6JFHlMqeNAJGjoaciMYRUz7XzylIDXiy4PPQiv.XpgJT07g1zcVqBsN7ezGVxnFG5qrSirN0d0l1oUkpk3h.x2Ip9Ux163_IfCk_Z9bSSEAqIw6XIlCeYwXN9RjCsLSxXdF3UQcqFFF7eHbR_LsiKthdirhJYUkxr2aqipcGHD4vwBOgAXhgUzs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A74ED49.6030508@netconfcentral.com> Date: Sat, 01 Aug 2009 18:35:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] external deviations files 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: Sun, 02 Aug 2009 01:34:45 -0000 Hi, Sec. 5.6.4 clearly says that the deviation parameter indicates the name of the module defining device deviations. So even though deviation-stmt is defined in body-stmt, the deviation(s) advertised in a module capability cannot be sub-modules. If the deviations are located in a submodule, then the main module is advertised instead. You cannot go backwards from a sub-module to the exact main module because the belongs-to statement does not have a revision-date field. How come deviations are stored in YANG modules, but their revision dates are ignored, unlike a real YANG module. An agent has no way to advertise to revision of the deviations module used. Deviations which are external (the target is in a different module) are too complicated to fully process when the deviations file contains local typedefs and identities. It is also unnatural because the deviations module needs to import the target module, but (of course) the target module cannot import the deviations module, or an imports loop would form. So with deviations, the patched file can end up referencing definitions which are not imported at all. This will result in errors. I think the draft needs to be clear that the patched object (deviations applied) MUST be valid using just the imports and includes in the patched file. e.g.: module-capability&module=foo&revision=2009-08-01&deviation=dev module dev { namespace "dev-NS"; prefix dev; import foo { prefix foo; revision-date 2009-08-01; } typedef mytype { type string; } deviation /foo:bar/foo:baz { deviate replace { type { dev:mytype; } } } } This will cause an error in the patched foo module, because dev:mytype cannot be found. Andy From lhotka@cesnet.cz Sun Aug 2 04:10: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 D940B3A6953 for ; Sun, 2 Aug 2009 04:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.075, 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 KarDtbDpQrpH for ; Sun, 2 Aug 2009 04:10:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B73043A684A for ; Sun, 2 Aug 2009 04:10:17 -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 C9D7BD80096; Sun, 2 Aug 2009 13:10:16 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A74BF9F.4060203@netconfcentral.com> References: <4A745B05.6000001@netconfcentral.com> <1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com> <20090801.214901.199335718.mbj@tail-f.com> <4A74BF9F.4060203@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sun, 02 Aug 2009 13:10:13 +0200 Message-Id: <1249211413.3182.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sun, 02 Aug 2009 11:10:18 -0000 Hi, we should strictly distinguish between data node identifiers that live in a "target XML namespace" and become names of XML elements in instance documents, and names of "schema things" that essentialy belong to a YANG module - schema nodes, types, groupings, identities. Only the former - if they appear in a grouping and have no prefix - may be subject to the late namespace binding. It is IMO a bit unfortunate that these two namespaces are handled as one. At least we now don't use XPath for addressing schema nodes (in 'augment' and 'refine'). The identityrefs are really very tricky and in XPath expressions they seem to be almost unusable since they appear as string literals. It is a technical problem although it wasn't introduced by the new text. IMO the only sensible way out may be a custom XPath function identityref() performing the type casting. I guess we are stretching poor XPath too far here. Lada Andy Bierman píše v So 01. 08. 2009 v 15:20 -0700: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> The prefixes are not special because they are in must/when > >> expressions. These are NOT XML prefixes at all. They > >> are within a YANG module, and they are using YANG prefixes, > >> not XML prefixes. > > > > No they *are* different in XPath than in ordinary YANG statements. In > > XPath they are used to map to an XML namespace, in YANG statements > > they are used to map to a (specific version of a) YANG module. > > > > That seems irrelevant to me. > > > At this point I am not sure I understand your objection. Do you think > > that there are technical problems with the solution? If so, what are > > they? > > > > > must and when statements are not the only YANG constructs > that can be defined within a grouping that can have an implied prefix. > > > mod 1: prefix foo1; > > grouping ggg { > container test-top { > leaf bar { type uint8; } > leaf baz { > must "../goo = 'my-identity' and . > 42"; > type MyType; > } > leaf goo { > type identityref { > base MyBase; > } > default my-identity; > } > } > } > > > mod 2: prefix foo; > container one { > uses foo1:ggg; > } > } > > > > > In this example, the must expression will reference > the foo:my-identity definition, but the default > references the foo1:my-identity. This is not obvious at all. > > The type-stmt references the foo1:MyType typedef for leaf 'goo', > but in XPath the leaf 'goo' will use the other definition of MyType, > which is a boolean, not an int32. This seems broken to me. > > > > > > /martin > > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sun Aug 2 07:16: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 C86FA3A6818 for ; Sun, 2 Aug 2009 07:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 sffj2D-4pH5x for ; Sun, 2 Aug 2009 07:16:10 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 163663A694F for ; Sun, 2 Aug 2009 07:14:13 -0700 (PDT) Received: from [68.142.200.226] by n18.bullet.mail.mud.yahoo.com with NNFMP; 02 Aug 2009 14:14:12 -0000 Received: from [68.142.201.66] by t7.bullet.mud.yahoo.com with NNFMP; 02 Aug 2009 14:14:12 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 02 Aug 2009 14:14:12 -0000 X-Yahoo-Newman-Id: 58714.90980.bm@omp418.mail.mud.yahoo.com Received: (qmail 65658 invoked from network); 2 Aug 2009 14:14:11 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 2 Aug 2009 14:14:11 -0000 X-YMail-OSG: mnWzTgYVM1kOxL0HNO4XDaUXTpGWFLZPP_68hiN0STNlDDENPK4_pR4TeYP9D9o83laRADxTj7RF_arXAwBcTa1dZtOGu8zhWKN0xWFqzueQtppczc2xKbu8_A4l9aAs6M35HPSSpqleT.dIpihfz3UZoIe9ZXf189L8gU9SsI.8EzkruoSyW4RaUlLsxqw4BGNLdH1_bWsQhGyEnFdGoPlHpDYFFT2zqpzbEfhobtFpTtW3sIydUQLiEQ.uZtFIeNCHUvhJ5kORMszAoMIaaDLwE6mhzCT5OflPoJuuUwxEfnQn5ZXrSkdm1wDMfuLA8nESRou1fhAl X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A759ED4.3090703@netconfcentral.com> Date: Sun, 02 Aug 2009 07:12:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A745B05.6000001@netconfcentral.com> <1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com> <20090801.214901.199335718.mbj@tail-f.com> <4A74BF9F.4060203@netconfcentral.com> <1249211413.3182.43.camel@missotis> In-Reply-To: <1249211413.3182.43.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sun, 02 Aug 2009 14:16:10 -0000 Ladislav Lhotka wrote: > Hi, > > we should strictly distinguish between data node identifiers that live > in a "target XML namespace" and become names of XML elements in instance > documents, and names of "schema things" that essentialy belong to a YANG > module - schema nodes, types, groupings, identities. > > Only the former - if they appear in a grouping and have no prefix - may > be subject to the late namespace binding. > why is that, exactly? > It is IMO a bit unfortunate that these two namespaces are handled as > one. At least we now don't use XPath for addressing schema nodes (in > 'augment' and 'refine'). > > The identityrefs are really very tricky and in XPath expressions they > seem to be almost unusable since they appear as string literals. It is a > technical problem although it wasn't introduced by the new text. IMO the > only sensible way out may be a custom XPath function identityref() > performing the type casting. I guess we are stretching poor XPath too > far here. > > Lada > Andy > Andy Bierman píše v So 01. 08. 2009 v 15:20 -0700: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> The prefixes are not special because they are in must/when >>>> expressions. These are NOT XML prefixes at all. They >>>> are within a YANG module, and they are using YANG prefixes, >>>> not XML prefixes. >>> No they *are* different in XPath than in ordinary YANG statements. In >>> XPath they are used to map to an XML namespace, in YANG statements >>> they are used to map to a (specific version of a) YANG module. >>> >> That seems irrelevant to me. >> >>> At this point I am not sure I understand your objection. Do you think >>> that there are technical problems with the solution? If so, what are >>> they? >>> >> >> must and when statements are not the only YANG constructs >> that can be defined within a grouping that can have an implied prefix. >> >> >> mod 1: prefix foo1; >> >> grouping ggg { >> container test-top { >> leaf bar { type uint8; } >> leaf baz { >> must "../goo = 'my-identity' and . > 42"; >> type MyType; >> } >> leaf goo { >> type identityref { >> base MyBase; >> } >> default my-identity; >> } >> } >> } >> >> >> mod 2: prefix foo; >> container one { >> uses foo1:ggg; >> } >> } >> >> >> >> >> In this example, the must expression will reference >> the foo:my-identity definition, but the default >> references the foo1:my-identity. This is not obvious at all. >> >> The type-stmt references the foo1:MyType typedef for leaf 'goo', >> but in XPath the leaf 'goo' will use the other definition of MyType, >> which is a boolean, not an int32. This seems broken to me. >> >> >>> /martin >>> >> Andy From lhotka@cesnet.cz Sun Aug 2 08:49: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 E8CEA3A6C3F for ; Sun, 2 Aug 2009 08:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.069, 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 OPwrFiCPNQdy for ; Sun, 2 Aug 2009 08:49:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 943C33A6C2B for ; Sun, 2 Aug 2009 08:48: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 8709AD80096; Sun, 2 Aug 2009 17:48:33 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A759ED4.3090703@netconfcentral.com> References: <4A745B05.6000001@netconfcentral.com> <1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com> <20090801.214901.199335718.mbj@tail-f.com> <4A74BF9F.4060203@netconfcentral.com> <1249211413.3182.43.camel@missotis> <4A759ED4.3090703@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sun, 02 Aug 2009 17:48:30 +0200 Message-Id: <1249228110.3182.45.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sun, 02 Aug 2009 15:49:38 -0000 Andy Bierman píše v Ne 02. 08. 2009 v 07:12 -0700: > Ladislav Lhotka wrote: > > Hi, > > > > we should strictly distinguish between data node identifiers that live > > in a "target XML namespace" and become names of XML elements in instance > > documents, and names of "schema things" that essentialy belong to a YANG > > module - schema nodes, types, groupings, identities. > > > > Only the former - if they appear in a grouping and have no prefix - may > > be subject to the late namespace binding. > > > > why is that, exactly? That's my understanding of how groupings are supposed to work. Is it insufficient? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Sun Aug 2 09:59: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 2B6353A6C4C for ; Sun, 2 Aug 2009 09:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 942kDwEB6+uA for ; Sun, 2 Aug 2009 09:59:35 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id C58A63A6C3D for ; Sun, 2 Aug 2009 09:59:31 -0700 (PDT) Received: (qmail 39982 invoked from network); 2 Aug 2009 16:59:32 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2009 16:59:32 -0000 X-YMail-OSG: 1Zo38o0VM1lob1MJ.hjN_tN8JXeQy_dVJnoBQ3OaFKtw9T7uhHNxS_WyP4SdoJ49QULAc4y3S5f1WMpo8GMeKcrxBBPYrZS3V8z1KtsHUEAXjB_MGlUCxgXFO5Rbbf41vPt7eMM2jXCLhNWranHw0_HbcnR3bTz9W6GmojnBcijsvC7EkdtewoGF9O6ctgYMqn4bx4sxSiPDJBVQnVcdikqDkaNfb.bLhDUzgrkcSoTSUFudU8pRasVPSn3klNb4litCcCJ_gGGMS5o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A75C594.8040409@netconfcentral.com> Date: Sun, 02 Aug 2009 09:57:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A745B05.6000001@netconfcentral.com> <1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com> <20090801.214901.199335718.mbj@tail-f.com> <4A74BF9F.4060203@netconfcentral.com> <1249211413.3182.43.camel@missotis> <4A759ED4.3090703@netconfcentral.com> <1249228110.3182.45.camel@missotis> In-Reply-To: <1249228110.3182.45.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Sun, 02 Aug 2009 16:59:36 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Ne 02. 08. 2009 v 07:12 -0700: >> Ladislav Lhotka wrote: >>> Hi, >>> >>> we should strictly distinguish between data node identifiers that live >>> in a "target XML namespace" and become names of XML elements in instance >>> documents, and names of "schema things" that essentialy belong to a YANG >>> module - schema nodes, types, groupings, identities. >>> >>> Only the former - if they appear in a grouping and have no prefix - may >>> be subject to the late namespace binding. >>> >> why is that, exactly? > > That's my understanding of how groupings are supposed to work. Is it > insufficient? yes. It is not my understanding of how the default prefix works. IMO, it is extremely non-obvious that, within a YANG file, the same QNames will mean different things in various contexts. IMO, one of the best tests of a good modeling language is how easy or difficult it is for an author to mess up and inadvertently do the wrong thing. The 'astonishment factor' in YANG is fairly high, and about to get worse. > > Lada > Andy From andy@netconfcentral.com Sun Aug 2 10:24:22 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 46A8D3A6A74 for ; Sun, 2 Aug 2009 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 WuqHdSJvVFga for ; Sun, 2 Aug 2009 10:24:21 -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 476433A6B58 for ; Sun, 2 Aug 2009 10:23:36 -0700 (PDT) Received: (qmail 42139 invoked from network); 2 Aug 2009 17:23:35 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 2 Aug 2009 17:23:35 -0000 X-YMail-OSG: QVSa0rMVM1nJz0Kl6aAVmNYKemkdOOWoU3N3mvv3CTgL9eC5xevdWKzbx9wzmyFdbvlBm8f3fYW9BuHhnGGZXpY4eXCML__raD6WVaA.Ms3by0RntV3nG1gtOK1PXdt4GnscfUyF3H89U_rfsDD4T6bBd0Ydb6ooR6gmn7Ptb394XEKy.uz4BD_5MaoB2UdDhH6ydL36HI830vhXU3fhDHs8NfPjhtPfycREJYcvzUejZeEw1M6ifY9jUwlPKsBT6ryE6CP5wIWJauTxjJZ67NwDHLZYVA0CuCKeimcv8ZegTkoAvpM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A75CBB1.2040300@netconfcentral.com> Date: Sun, 02 Aug 2009 10:24:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> In-Reply-To: <20090801215430.GA18163@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 02 Aug 2009 17:24:22 -0000 Juergen Schoenwaelder wrote: > On Fri, Jul 31, 2009 at 12:34:35AM +0200, Andy Bierman wrote: > >> Uh-oh, another detail: Should 'yang' really be 'netmod'? IMO, yes. >> The naming authority is the NETMOD WG, not the YANG language. > > Its called yang because the module is yang. The naming authority is > the IETF. > OK -- but it is confusing that this is set to the WG name in every other usage. Here are the data model namespaces we have in RFCs already: urn:ietf:params:xml:ns:netconf:base:1.0 urn:ietf:params:xml:ns:netconf:notification:1.0 urn:ietf:params:xml:ns:netmod:notification Here are the temporary namespaces that have been used so far in I-Ds: urn:ietf:params:xml:ns:netconf:partial-lock:1.0 urn:ietf:params:xml:ns:netconf:state urn:ietf:params:xml:ns:netconf:with-defaults:1.0 Now you can see why I raised this issue. So, what is the temporary URI format that should be used in these drafts? What about version numbers in the namespace? We should not do that! We should use revision-date (or version in XSD) to distinguish versions. Both temporary and permanent namespace URIs should use the revision date instead of the namespace. Otherwise it is inconsistent, and we will be asking every YANG author from now on to bother IANA every time they update their I-D. The module 'yang' seems wrong to me. The namespace becomes the targetNamespace in XSD. It is not YANG specific at all. I think it is NETCONF-specific, since all our YANG modules are currently written for use with NETCONF. Here is another attempt: temporary URIs: urn:ietf:params:xml:ns:netconf:partial-lock:DRAFT urn:ietf:params:xml:ns:netconf:state:DRAFT urn:ietf:params:xml:ns:netconf:with-defaults:DRAFT real URIs: urn:ietf:params:xml:ns:netconf:partial-lock urn:ietf:params:xml:ns:netconf:state urn:ietf:params:xml:ns:netconf:with-defaults IANA just needs to drop the :DRAFT at RFC publication time. Simple. It works. Can we move on? >> namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-03 >> namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-04 >> namespace urn:ietf:params:xml:ns:netmod:DRAFT:bar-00 >> >> So what is a real YANG module URN supposed to look like? >> >> namespace urn:ietf:params:xml:ns:netmod:RFC5991:foo >> namespace urn:ietf:params:xml:ns:netmod:RFC6210:foo >> namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar > > No. > >> Where is this registry and template defined? > > In the YANG language definition. > > /js > Andy From j.schoenwaelder@jacobs-university.de Sun Aug 2 10:47: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 4C4733A688B for ; Sun, 2 Aug 2009 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.041, 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 m5YP61eBcDeA for ; Sun, 2 Aug 2009 10:46:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 306533A6803 for ; Sun, 2 Aug 2009 10:46:59 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECBAEC0013; Sun, 2 Aug 2009 19:47:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RmRiDCOUed5B; Sun, 2 Aug 2009 19:46:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D580C000B; Sun, 2 Aug 2009 19:46:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29DE1B74931; Sun, 2 Aug 2009 19:47:00 +0200 (CEST) Date: Sun, 2 Aug 2009 19:46:59 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090802174659.GA18545@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A75CBB1.2040300@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 02 Aug 2009 17:47:00 -0000 On Sun, Aug 02, 2009 at 07:24:01PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Jul 31, 2009 at 12:34:35AM +0200, Andy Bierman wrote: > > > >> Uh-oh, another detail: Should 'yang' really be 'netmod'? IMO, yes. > >> The naming authority is the NETMOD WG, not the YANG language. > > > > Its called yang because the module is yang. The naming authority is > > the IETF. > > > > OK -- but it is confusing that this is set to the WG name > in every other usage. > > Here are the data model namespaces we have in RFCs already: > > urn:ietf:params:xml:ns:netconf:base:1.0 > urn:ietf:params:xml:ns:netconf:notification:1.0 > urn:ietf:params:xml:ns:netmod:notification You confuse protocol capability URNs with data model namespaces. And I agree that the 3rd one was a rather poor choice. > Here are the temporary namespaces that have been used so far in I-Ds: > > urn:ietf:params:xml:ns:netconf:partial-lock:1.0 > urn:ietf:params:xml:ns:netconf:state > urn:ietf:params:xml:ns:netconf:with-defaults:1.0 > > Now you can see why I raised this issue. > > So, what is the temporary URI format that should be used in > these drafts? urn:ietf:params:xml:ns:yang:netconf-partial-lock:DRAFT-09 urn:ietf:params:xml:ns:yang:netconf-state:DRAFT-07 The with-defaults is again a capability URI, so it should follow the other capability URIs in format: urn:ietf:params:xml:ns:netconf:with-defaults:1.0 > What about version numbers in the namespace? > We should not do that! We should use revision-date (or > version in XSD) to distinguish versions. The Version Number is the version of the Internet-Draft and will go away once an RFC the official IANA assignment is being made. > Both temporary and permanent namespace URIs should > use the revision date instead of the namespace. > Otherwise it is inconsistent, and we will be asking > every YANG author from now on to bother IANA every > time they update their I-D. The string in an ID is a placeholder until IANA does the final assignment. > The module 'yang' seems wrong to me. It is a namespace assigned for use with the YANG data modeling language. For me, WG names are pointless since they come and go. > The namespace becomes the targetNamespace in XSD. Yes. > It is not YANG specific at all. I think > it is NETCONF-specific, since all our YANG > modules are currently written for use with NETCONF. The data model are written in YANG and conform to the YANG restrictions of NETCONF content and so I believe yang is correct. /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 Sun Aug 2 11:09: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 277C03A6BC4 for ; Sun, 2 Aug 2009 11:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 pe6x-iM2z7q9 for ; Sun, 2 Aug 2009 11:09: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 7DA903A6B23 for ; Sun, 2 Aug 2009 11:09:22 -0700 (PDT) Received: (qmail 12716 invoked from network); 2 Aug 2009 18:09:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2009 18:09:24 -0000 X-YMail-OSG: bt3POmoVM1lOCegMkoAYQBiBBMs1gNo8UNnYRmuVJutJ5ymf8PxslrV0C4kk3UUbSVimS4KT33KTEBxHuZkpf3mj9f3WvdwybNQSpWZr_IZzrxAIR2SXlpXilxhuiygb0Sc6nep7PYztKg78FsSb_BQ2evH4aSH2asT7xxFwKqsAH8Njbw96sbJYefbE6ytC8DDruD44EFEjLVFXS4D4rEbXwd.YyX.w.Cm39cqJVrnkbAta9d6rklG0FJYBYnd6Pz8GHSjJMLFta9o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A75D66E.6010207@netconfcentral.com> Date: Sun, 02 Aug 2009 11:09:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> In-Reply-To: <20090802174659.GA18545@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 02 Aug 2009 18:09:40 -0000 Juergen Schoenwaelder wrote: > On Sun, Aug 02, 2009 at 07:24:01PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Jul 31, 2009 at 12:34:35AM +0200, Andy Bierman wrote: >>> >>>> Uh-oh, another detail: Should 'yang' really be 'netmod'? IMO, yes. >>>> The naming authority is the NETMOD WG, not the YANG language. >>> Its called yang because the module is yang. The naming authority is >>> the IETF. >>> >> OK -- but it is confusing that this is set to the WG name >> in every other usage. >> >> Here are the data model namespaces we have in RFCs already: >> >> urn:ietf:params:xml:ns:netconf:base:1.0 >> urn:ietf:params:xml:ns:netconf:notification:1.0 >> urn:ietf:params:xml:ns:netmod:notification > > You confuse protocol capability URNs with data model namespaces. And I > agree that the 3rd one was a rather poor choice. > >> Here are the temporary namespaces that have been used so far in I-Ds: >> >> urn:ietf:params:xml:ns:netconf:partial-lock:1.0 >> urn:ietf:params:xml:ns:netconf:state >> urn:ietf:params:xml:ns:netconf:with-defaults:1.0 >> >> Now you can see why I raised this issue. >> >> So, what is the temporary URI format that should be used in >> these drafts? > > urn:ietf:params:xml:ns:yang:netconf-partial-lock:DRAFT-09 > urn:ietf:params:xml:ns:yang:netconf-state:DRAFT-07 > So you want every YANG I-D author to be forced to update the IANA registry every time the I-D is updated? Because if the version number is in the string, that is what will be required. The registry might get really big after only a few years. IMO, it is better to get the IANA assignment at the time of the -00 draft only. There is no point in letting authors make up their own namespace strings that look like IANA assignments. (But that's what we've been doing.) These are supposed to be globally unique strings that never get reused, so a real registry entry is needed. Either that, or leave the field broken (like in SMIv2) in I-Ds. Why is the revision-date good enough between RFC versions, but not between draft versions? > The with-defaults is again a capability URI, so it should follow the > other capability URIs in format: > > urn:ietf:params:xml:ns:netconf:with-defaults:1.0 > >> What about version numbers in the namespace? >> We should not do that! We should use revision-date (or >> version in XSD) to distinguish versions. > > The Version Number is the version of the Internet-Draft and will go > away once an RFC the official IANA assignment is being made. > >> Both temporary and permanent namespace URIs should >> use the revision date instead of the namespace. >> Otherwise it is inconsistent, and we will be asking >> every YANG author from now on to bother IANA every >> time they update their I-D. > > The string in an ID is a placeholder until IANA does the final > assignment. > >> The module 'yang' seems wrong to me. > > It is a namespace assigned for use with the YANG data modeling > language. For me, WG names are pointless since they come and go. > >> The namespace becomes the targetNamespace in XSD. > > Yes. > >> It is not YANG specific at all. I think >> it is NETCONF-specific, since all our YANG >> modules are currently written for use with NETCONF. > > The data model are written in YANG and conform to the YANG > restrictions of NETCONF content and so I believe yang is correct. > > /js > Andy From andy@netconfcentral.com Sun Aug 2 11:34: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 76EA13A6A9D for ; Sun, 2 Aug 2009 11:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 J-Uvfb0BgRUg for ; Sun, 2 Aug 2009 11:34:49 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id C6C5E3A68EF for ; Sun, 2 Aug 2009 11:34:49 -0700 (PDT) Received: (qmail 24187 invoked from network); 2 Aug 2009 18:34:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 2 Aug 2009 18:34:49 -0000 X-YMail-OSG: xswRNmoVM1k8u1oi3vzr_kZSbhC_gRLtoBr8es1xCEX80gPvaEx8WGSNcb7hzo9aoEVkY1JZviRLC0SNBmTac5mLs5scJ.5f0hf2gME102R6juGafCaq3AwcsH8aDlRGyDFrbIN0ld_nX3sJtX9V4gQAWhNCJS9pBRchy5BYBSrlrojHJQm9RY7Jm64YLUps3wZVeF9O9JdItDg3uDnAAJz380jGloxUkRe9AkWuqgaLRZm8D7MXwHyWrn.UQnpOzbXmTXkH_.u2Mbg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A75DC63.2070005@netconfcentral.com> Date: Sun, 02 Aug 2009 11:35:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> In-Reply-To: <20090802174659.GA18545@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 02 Aug 2009 18:34:50 -0000 Juergen Schoenwaelder wrote: .... > The with-defaults is again a capability URI, so it should follow the > other capability URIs in format: > > urn:ietf:params:xml:ns:netconf:with-defaults:1.0 > The element is defined in a targetNamespace with the same value as the capability URI. It is also incorrectly specified in the XSD in section 4. The parameter is a leaf, not an XML attribute. IMO, the ":1.0" should be left out of the XML namespace. > .... > The data model are written in YANG and conform to the YANG > restrictions of NETCONF content and so I believe yang is correct. > OK So, when the -00 I-D is published, the main part of the URI is requested from IANA. The :DRAFT-XX is added by the author without any IANA involvement. The 3 I-D namespace URIs should be: urn:ietf:params:xml:ns:yang:ietf-partial-lock:DRAFT-09 urn:ietf:params:xml:ns:yang:ietf-netconf-state:DRAFT-07 urn:ietf:params:xml:ns:yang:ietf-with-defaults:DRAFT-02 Not only are the versions wrong, the names are wrong too. So the process almost works: 1) publish draft -00; get IANA assignment 2) publish DRAFT-nn versions 3) publish the 1st RFC version 4) publish RFC-bis draft -00 version oops: the DRAFT-00 URI was used already way back in step 1 Another issue: people who reference the IANA registry do not know if an entry is published at RFC or DRAFT status, or which RFC number or I-D name. > /js > Andy From j.schoenwaelder@jacobs-university.de Sun Aug 2 11:51: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 524023A6C41 for ; Sun, 2 Aug 2009 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 D6394DshyJwu for ; Sun, 2 Aug 2009 11:50:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 826E13A6C0E for ; Sun, 2 Aug 2009 11:50:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A26F8C000F; Sun, 2 Aug 2009 20:51:01 +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 OG4CWUjZMZAB; Sun, 2 Aug 2009 20:51:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 564CBC000B; Sun, 2 Aug 2009 20:51:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D03C0B74B27; Sun, 2 Aug 2009 20:51:00 +0200 (CEST) Date: Sun, 2 Aug 2009 20:51:00 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090802185100.GB18545@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75D66E.6010207@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A75D66E.6010207@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 02 Aug 2009 18:51:00 -0000 On Sun, Aug 02, 2009 at 08:09:50PM +0200, Andy Bierman wrote: > So you want every YANG I-D author > to be forced to update the IANA registry > every time the I-D is updated? > Because if the version number is in the string, > that is what will be required. > > The registry might get really big after only a few years. > IMO, it is better to get the IANA assignment at > the time of the -00 draft only. Except you, I have not heard anyone suggesting this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Aug 2 12:00: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 072A53A681D for ; Sun, 2 Aug 2009 12:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.039, 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 WqapOODOm+Sl for ; Sun, 2 Aug 2009 12:00:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 72F9928C0F9 for ; Sun, 2 Aug 2009 12:00:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 913F2C000F; Sun, 2 Aug 2009 21:00:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GfH-vCxwIv9X; Sun, 2 Aug 2009 21:00:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA118C000B; Sun, 2 Aug 2009 21:00:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 504F1B74B79; Sun, 2 Aug 2009 21:00:21 +0200 (CEST) Date: Sun, 2 Aug 2009 21:00:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090802190021.GC18545@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75DC63.2070005@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A75DC63.2070005@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 02 Aug 2009 19:00:26 -0000 On Sun, Aug 02, 2009 at 08:35:15PM +0200, Andy Bierman wrote: > So, when the -00 I-D is published, the main part > of the URI is requested from IANA. The :DRAFT-XX > is added by the author without any IANA involvement. No. The IANA assignment is made after IESG approval with a recommendation already in the ID with an added :DRAFT-xx to mark it clearly as a non-official URI. > The 3 I-D namespace URIs should be: > > urn:ietf:params:xml:ns:yang:ietf-partial-lock:DRAFT-09 > urn:ietf:params:xml:ns:yang:ietf-netconf-state:DRAFT-07 > urn:ietf:params:xml:ns:yang:ietf-with-defaults:DRAFT-02 > > Not only are the versions wrong, the names are wrong too. I still can't find the YANG data model in draft-ietf-netconf-with-defaults-02.txt. and the module name in draft-ietf-netconf-partial-lock-09.txt is ietf-netconf-partial-lock; so yes, your names are wrong. > So the process almost works: > > 1) publish draft -00; get IANA assignment > 2) publish DRAFT-nn versions > 3) publish the 1st RFC version > 4) publish RFC-bis draft -00 version > oops: the DRAFT-00 URI was used already way back in step 1 I think this is not what was discussed in Stockholm. /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 Sun Aug 2 14:33: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 075C93A6C44 for ; Sun, 2 Aug 2009 14:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 njL29Kw+fC75 for ; Sun, 2 Aug 2009 14:33:46 -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 3DBB83A69D0 for ; Sun, 2 Aug 2009 14:33:46 -0700 (PDT) Received: (qmail 98771 invoked from network); 2 Aug 2009 21:33:47 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2009 21:33:46 -0000 X-YMail-OSG: LJpiPMUVM1mGwphzr5h5M3gMrmaCQ6xQ7qwrvp1YTS5AOmZVY27gPYk_M9eIosjvFo4Hy5vNGrnCiYVInkDBDabt83Jo5VrEIz0xDNdhIDO5VE9SiLVoRJ8p.aJDOpKXSqpG7SN4mYazFza1y9gu4t.uTNpAGvdIShxjUvMEXYGEWJv47hwF7zRnHflTfw60ZatOUK33lXotgQhdRly64WaSJN5toi7Tdg5v5StK4qiiz5OTj2WMfeHhNVEiHF2ezsnWZ6K82dogwH4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7605DB.7010002@netconfcentral.com> Date: Sun, 02 Aug 2009 14:32:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <4A70DCA9.6060109@netconfcentral.com> <200907300012.n6U0CvH2039381@idle.juniper.net> <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75DC63.2070005@netconfcentral.com> <20090802190021.GC18545@elstar.local> In-Reply-To: <20090802190021.GC18545@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 02 Aug 2009 21:33:47 -0000 Juergen Schoenwaelder wrote: > On Sun, Aug 02, 2009 at 08:35:15PM +0200, Andy Bierman wrote: > >> So, when the -00 I-D is published, the main part >> of the URI is requested from IANA. The :DRAFT-XX >> is added by the author without any IANA involvement. > > No. The IANA assignment is made after IESG approval with a > recommendation already in the ID with an added :DRAFT-xx to mark it > clearly as a non-official URI. > Then I'm not clear on the value of the registry. I would think it was important to choose unique URIs from Day One. I would think that any early implementations using these URIs expect them to be unique. So it is the author's responsibility to make sure nobody ever starts working on module with the same name, during the several years it may take to reach RFC publication? >> The 3 I-D namespace URIs should be: >> >> urn:ietf:params:xml:ns:yang:ietf-partial-lock:DRAFT-09 >> urn:ietf:params:xml:ns:yang:ietf-netconf-state:DRAFT-07 >> urn:ietf:params:xml:ns:yang:ietf-with-defaults:DRAFT-02 >> >> Not only are the versions wrong, the names are wrong too. > > I still can't find the YANG data model in > draft-ietf-netconf-with-defaults-02.txt. and the module name in > draft-ietf-netconf-partial-lock-09.txt is ietf-netconf-partial-lock; > so yes, your names are wrong. > The module names for IETF modules are supposed to start with "ietf-". The NETCONF WG already agreed to this. If the URI is supposed to contain the module name, then it needs to match. >> So the process almost works: >> >> 1) publish draft -00; get IANA assignment >> 2) publish DRAFT-nn versions >> 3) publish the 1st RFC version >> 4) publish RFC-bis draft -00 version >> oops: the DRAFT-00 URI was used already way back in step 1 > > I think this is not what was discussed in Stockholm. > How does one distinguish foo:DRAFT-00 done in one year from another foo:DRAFT-00 several years later when the WG is rechartered to update the original RFC? I must have missed that part of the meeting. > /js > Andy From balazs.lengyel@ericsson.com Mon Aug 3 04:36: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 BAB9D3A6A32 for ; Mon, 3 Aug 2009 04:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.711 X-Spam-Level: X-Spam-Status: No, score=-4.711 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_05=-1.11, 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 S8Pja0YW3YsO for ; Mon, 3 Aug 2009 04:36:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AAC203A68FD for ; Mon, 3 Aug 2009 04:36:05 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-21-4a76cba66dbf Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2F.2F.15141.6ABC67A4; Mon, 3 Aug 2009 13:36:06 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 13:35:58 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 13:35:58 +0200 Message-ID: <4A76CB9E.5010906@ericsson.com> Date: Mon, 03 Aug 2009 13:35:58 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2009 11:35:58.0878 (UTC) FILETIME=[9248DBE0:01CA142E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] type in type 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: Mon, 03 Aug 2009 11:36:06 -0000 Hello, In chapter 7.4.1 in the yang-07 draft, it is stated that type can be a sub-statement of type. What does type in type mean? Could you give me an example? Or is this a mistake? Balazs From j.schoenwaelder@jacobs-university.de Mon Aug 3 04:58:01 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 3ADD13A6D84 for ; Mon, 3 Aug 2009 04:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.038, 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 HiLV5byD9IyV for ; Mon, 3 Aug 2009 04:58:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 475E53A6D3E for ; Mon, 3 Aug 2009 04:58:00 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 865B1C0019; Mon, 3 Aug 2009 13:58:02 +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 7zVA4dRahIwm; Mon, 3 Aug 2009 13:58:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00FE9C003A; Mon, 3 Aug 2009 13:58:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 727C1B76292; Mon, 3 Aug 2009 13:58:02 +0200 (CEST) Date: Mon, 3 Aug 2009 13:58:02 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090803115802.GC19630@elstar.local> Mail-Followup-To: Balazs Lengyel , NETMOD Working Group References: <4A76CB9E.5010906@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A76CB9E.5010906@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] type in type 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: Mon, 03 Aug 2009 11:58:01 -0000 On Mon, Aug 03, 2009 at 01:35:58PM +0200, Balazs Lengyel wrote: > In chapter 7.4.1 in the yang-07 draft, it is stated that type can be > a sub-statement of type. What does type in type mean? Could you > give me an example? Or is this a mistake? I think this is a mistake in the table. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Tue Aug 4 10:22: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 532283A7076 for ; Tue, 4 Aug 2009 10:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=-1.608, BAYES_40=-0.185, DATE_IN_PAST_24_48=1.219] 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 yI3Lfqj1Eqbs for ; Tue, 4 Aug 2009 10:22:46 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 2F19C3A6D9A for ; Tue, 4 Aug 2009 10:22:46 -0700 (PDT) X-Trace: 273555309/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.13/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.13 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: Au4EAI8LeEo+vGQN/2dsb2JhbABHgmY/HoxRxFcJhA8F X-IronPort-AV: E=Sophos;i="4.43,322,1246834800"; d="scan'208";a="273555309" X-IP-Direction: IN Received: from 1cust13.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.13]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Aug 2009 18:22:43 +0100 Message-ID: <000701ca151f$b3238760$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A65EC7A.1060008@ericsson.com><20090722.000948.206458951.mbj@tail-f.com><006d01ca0ba1$bc1344a0$0601a8c0@allison> <20090730.214800.216128611.mbj@tail-f.com> Date: Mon, 3 Aug 2009 18:02:59 +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] Comments on draft-ietf-netmod-yang-07.txt 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, 04 Aug 2009 17:22:47 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, July 30, 2009 9:48 PM > > "tom.petch" wrote: > > Martin > > > > Some wordings that have bugged me for a while. > > > > 5.1 ..."by using the enterprise or organization name as a prefix." > > Do you really mean prefix? only I think of prefix as shorthand and while IBM, > > Cisco or HP might qualify, other organization names would not. > > The text you quoted is preceeded by an "e.g." -- this is just a > friendly suggestion. If it is better, I can remove the quoted text. I still wonder what you had in mind. I would expect the enterprise or organization name to be in the namespace URI, not in the prefix, and the rest of the paragraph does seem to be about namespace names not prefix names. On the other hand, unique and consistent prefix names would make a big difference to the ease of use of yang, as I perceive it having done, totally informally, for SMI. So, at the risk of opening another XPath-like can of worms, I wonder what support there would be for that eg require all non-RFC prefix start with a character that flags them as enterprise defined. > > 5.5 .."searches up the levels of hierarchy in the schema tree" > > levels of hierarchy has a suggestion of all the nodes at a level whereas I > > think > > that this means search the path to the root. > > Me, Phil and Lada came up with this replacement text: > > OLD: > > When a YANG implementation resolves a reference to an unprefixed type > or grouping, or one which uses the prefix of the local module, it > searches up the levels of hierarchy in the schema tree, starting at > the current level, for the definition of the type or grouping. > > NEW: > > A reference to an unprefixed type or grouping, or one which uses the > prefix of the current module, is resolved by locating the closest > matching "typedef" or "grouping" statement among the immediate > substatments of each ancestor statement. Ok (/statments/statements/) > > 6 " YANG modules are written in the UTF-8 [RFC3629] character set." > > > > UTF-8 is not a character set in the lexicons I use; character encoding, > > transfer format, character syntax but not character set. > > NEW: > > YANG modules use the UTF-8 [RFC3629] character encoding. Yes > > 6.1.3 "up to at most the column of the double quote character." > > seems imprecise, leaving the option of everything up to or some way short of or > > whatever an implementation chooses > > How about this: > > If the double quoted string contains a line break followed by space > or tab characters which is used to indent the text according to the > layout in the YANG file, this leading whitespace is stripped from > the string, up to the column of the double quote character, or to > the first non-whitespace character, whichever occurs first. Yes ( /which is/which are/ ) > > 6.2.1 "All groupings defined within a parent node " > > well no, grouping names, otherwise it sounds like the identifiers defined > > within > > the grouping. > > Fixed. > > > 7.1.3 "with the exception of data node identifiers defined inside a grouping " > > well, only when they are 'uses'd in another module; needs adding IMO > > It says See section 7.12 for details. We have rewritten this section > to: > > > 7.12. The uses Statement > > The "uses" statement is used to reference a "grouping" definition. > It takes one argument, which is the name of the grouping. > > The effect of a "uses" reference to a grouping is that the nodes > defined by the grouping are copied into the current schema tree, and > then updated according to the refinement and augment statements. > > The identifiers defined in the grouping are not bound to a namespace > until the contents of the grouping are added to the schema tree via a > "uses" statement that does not appear inside a "grouping" statement, > a which point they are bound to the namespace of the current module. Ok > > 9.9.2 "Predicates are used only for constraining the values for the > > key nodes for list entries" > > or leaflists? > > Fixed. > > > /martin From lhotka@cesnet.cz Tue Aug 4 13:13: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 B4AC73A6D2B for ; Tue, 4 Aug 2009 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 AVBrxu8jJSYS for ; Tue, 4 Aug 2009 13:13:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D34273A6822 for ; Tue, 4 Aug 2009 13:13:33 -0700 (PDT) Received: from [192.168.1.66] (213-84-249-21.adsl.xs4all.nl [82.95.100.87]) by office2.cesnet.cz (Postfix) with ESMTP id F3F64D800F0 for ; Tue, 4 Aug 2009 22:13:35 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4A76CB9E.5010906@ericsson.com> References: <4A76CB9E.5010906@ericsson.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 04 Aug 2009 22:13:34 +0200 Message-Id: <1249416814.8954.1.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] type in type 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, 04 Aug 2009 20:13:34 -0000 Balazs Lengyel píše v Po 03. 08. 2009 v 13:35 +0200: > Hello, > In chapter 7.4.1 in the yang-07 draft, it is stated that type can be a sub-statement of type. > What does type in type mean? Could you give me an example? Or is this a mistake? It's used for the "union" type. Lada > Balazs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Aug 4 13:29: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 120A53A70B7 for ; Tue, 4 Aug 2009 13:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 vgrjokyErnKy for ; Tue, 4 Aug 2009 13:29: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 7A8123A70AC for ; Tue, 4 Aug 2009 13:29:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E99DDC0056; Tue, 4 Aug 2009 22:29:48 +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 sTUz4sqjo6YP; Tue, 4 Aug 2009 22:29: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 614DAC0055; Tue, 4 Aug 2009 22:29:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 36388B78D72; Tue, 4 Aug 2009 22:29:47 +0200 (CEST) Date: Tue, 4 Aug 2009 22:29:47 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090804202947.GA1204@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <4A76CB9E.5010906@ericsson.com> <1249416814.8954.1.camel@nomad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1249416814.8954.1.camel@nomad> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] type in type 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, 04 Aug 2009 20:29:50 -0000 On Tue, Aug 04, 2009 at 10:13:34PM +0200, Ladislav Lhotka wrote: > Balazs Lengyel p????e v Po 03. 08. 2009 v 13:35 +0200: > > Hello, > > In chapter 7.4.1 in the yang-07 draft, it is stated that type can be a sub-statement of type. > > What does type in type mean? Could you give me an example? Or is this a mistake? > > It's used for the "union" type. Correct - I missed that one. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed Aug 5 09:33: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 D43AA28C499 for ; Wed, 5 Aug 2009 09:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.387, 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 LuEFUIT43PF1 for ; Wed, 5 Aug 2009 09:33:32 -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 54DF13A7182 for ; Wed, 5 Aug 2009 09:33:32 -0700 (PDT) X-Trace: 185290675/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.17/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.17 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: Ap0EAK5QeUo+vGQR/2dsb2JhbACDL40zxUYJgigBgWYFgUyIXw X-IronPort-AV: E=Sophos;i="4.43,329,1246834800"; d="scan'208";a="185290675" X-IP-Direction: IN Received: from 1cust17.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.17]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Aug 2009 17:33:32 +0100 Message-ID: <001201ca15e1$fe22d140$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" References: <4A745B05.6000001@netconfcentral.com><1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com><20090801.214901.199335718.mbj@tail-f.com><4A74BF9F.4060203@netconfcentral.com> <1249211413.3182.43.camel@missotis> Date: Wed, 5 Aug 2009 17:31:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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] prefixes in groupings example 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, 05 Aug 2009 16:33:33 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Andy Bierman" Cc: Sent: Sunday, August 02, 2009 1:10 PM > we should strictly distinguish between data node identifiers that live > in a "target XML namespace" and become names of XML elements in instance > documents, and names of "schema things" that essentialy belong to a YANG > module - schema nodes, types, groupings, identities. Disagree: there is something going on here, but I have yet to get my mind around what it is. Schema nodes include list, leaf-list, list etc and I think that their identifier structure strictly parallels that of the data tree, the obvious qualification being the use of keys to identify items in a list (OID fragment, if you know SMI). I think that 'XML namespace', although used in the I-D, is the wrong term. Rather an identifier has local and global parts, and the global part is a URI and must be unique, not just within YANG but within URI used as XML namespaces etc. But calling it an XML namespace, as the I-D does, seems to add nothing of value; it isn't a namespace. As the I-D says, there are multiple identifier namespaces, one per parent node, and we have no separate identifier for each of those identifier namespaces; they all come under the namespace URI, which is bound to the module with the namespace statement, without differentiation. And that is equally true for schema tree and data tree. So the issue, which may now be resolved, is of what happens to identifiers without the prefix which implies a global part, and when is that default or explicit prefix turned into a global part. I think the characterisation that a prefix sometimes refers to a module, and sometimes to an XML namespace, is wrong; for me, it always refers to a URI, a global part. Early and late provision of the default prefix (not binding, to me that is of prefix to URI), I am comfortable with. Tom Petch > Only the former - if they appear in a grouping and have no prefix - may > be subject to the late namespace binding. > > It is IMO a bit unfortunate that these two namespaces are handled as > one. At least we now don't use XPath for addressing schema nodes (in > 'augment' and 'refine'). > > The identityrefs are really very tricky and in XPath expressions they > seem to be almost unusable since they appear as string literals. It is a > technical problem although it wasn't introduced by the new text. IMO the > only sensible way out may be a custom XPath function identityref() > performing the type casting. I guess we are stretching poor XPath too > far here. > > Lada > > Andy Bierman píše v So 01. 08. 2009 v 15:20 -0700: > > Martin Bjorklund wrote: > > > Andy Bierman wrote: > > >> The prefixes are not special because they are in must/when > > >> expressions. These are NOT XML prefixes at all. They > > >> are within a YANG module, and they are using YANG prefixes, > > >> not XML prefixes. > > > > > > No they *are* different in XPath than in ordinary YANG statements. In > > > XPath they are used to map to an XML namespace, in YANG statements > > > they are used to map to a (specific version of a) YANG module. > > > > > > > That seems irrelevant to me. > > > > > At this point I am not sure I understand your objection. Do you think > > > that there are technical problems with the solution? If so, what are > > > they? > > > > > > > > > must and when statements are not the only YANG constructs > > that can be defined within a grouping that can have an implied prefix. > > > > > > mod 1: prefix foo1; > > > > grouping ggg { > > container test-top { > > leaf bar { type uint8; } > > leaf baz { > > must "../goo = 'my-identity' and . > 42"; > > type MyType; > > } > > leaf goo { > > type identityref { > > base MyBase; > > } > > default my-identity; > > } > > } > > } > > > > > > mod 2: prefix foo; > > container one { > > uses foo1:ggg; > > } > > } > > > > > > > > > > In this example, the must expression will reference > > the foo:my-identity definition, but the default > > references the foo1:my-identity. This is not obvious at all. > > > > The type-stmt references the foo1:MyType typedef for leaf 'goo', > > but in XPath the leaf 'goo' will use the other definition of MyType, > > which is a boolean, not an int32. This seems broken to me. > > > > > > > > > > /martin > > > > > > > Andy > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@netconfcentral.com Wed Aug 5 09:50: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 9F4413A696A for ; Wed, 5 Aug 2009 09:50:54 -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 WVTXHRu3ZqiW for ; Wed, 5 Aug 2009 09:50:53 -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 9F95D3A71D8 for ; Wed, 5 Aug 2009 09:50:53 -0700 (PDT) Received: (qmail 67407 invoked from network); 5 Aug 2009 16:50:55 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2009 16:50:54 -0000 X-YMail-OSG: GzhJaVMVM1mrspaNNeIeQ_nWc6Bwf7_ZNVcC56ra8BfuV_gUpY8D9MJ14dXXNaq4TI1LQiHcLPhEpNrQ3jQiFwiYJ77SR6l9xZIzTkrlzBKtbgpCc_W41h0ImnpvEE5QB.CZw3VYKUSzXMlTgvYnBKw5xLPkJDaFd1WJL_Wkcg42kx._qWMiXp1DmkXAy4WsUqewB1Y91mTxHS33epTyD7bhx8AkHoXbnB_zU6E4WJIKsJdKna8rAlz5s3hvifniCNYqxOWEni4v3848coxd7ITZ1a65yBXLEs7DP3iniciDNoe0PFZlv4SkpW7fFp.z4XQ2uZSJYDvnp0UidJY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A79B89B.9090708@netconfcentral.com> Date: Wed, 05 Aug 2009 09:51:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "tom.petch" References: <4A745B05.6000001@netconfcentral.com><1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com><20090801.214901.199335718.mbj@tail-f.com><4A74BF9F.4060203@netconfcentral.com> <1249211413.3182.43.camel@missotis> <001201ca15e1$fe22d140$0601a8c0@allison> In-Reply-To: <001201ca15e1$fe22d140$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 05 Aug 2009 16:50:54 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Andy Bierman" > Cc: > Sent: Sunday, August 02, 2009 1:10 PM > >> we should strictly distinguish between data node identifiers that live >> in a "target XML namespace" and become names of XML elements in instance >> documents, and names of "schema things" that essentialy belong to a YANG >> module - schema nodes, types, groupings, identities. > > Disagree: there is something going on here, but I have yet to get my mind around > what it is. > > Schema nodes include list, leaf-list, list etc and I think that their identifier > structure strictly parallels that of the data tree, the obvious qualification > being the use of keys to identify items in a list (OID fragment, if you know > SMI). > > I think that 'XML namespace', although used in the I-D, is the wrong term. > Rather an identifier has local and global parts, and the global part is a URI > and must be unique, not just within YANG but within URI used as XML namespaces > etc. But calling it an XML namespace, as the I-D does, seems > to add nothing of value; it isn't a namespace. > > As the I-D says, there are multiple identifier namespaces, one per parent node, > and we have no separate identifier for each of those identifier namespaces; they > all come under the namespace URI, which is bound to the module with the > namespace statement, without differentiation. > > And that is equally true for schema tree and data tree. > > So the issue, which may now be resolved, is of what happens to identifiers > without the prefix which implies a global part, and when is that default or > explicit prefix turned into a global part. I think the characterisation that a > prefix sometimes refers to a module, and sometimes to an XML namespace, is > wrong; for me, it always refers to a URI, a global part. > nice summary > Early and late provision of the default prefix (not binding, to me that is of > prefix to URI), I am comfortable with. I can live with it -- I just want it clear to users. We have seen plenty of evidence that the 'distributed' nature and sheer size of the NETCONF RFC has led to lots of interoperability problems. Nobody is going to guess that no-local-prefix means different things for different statements, but only in groupings. Astonishment:fragility is 1:1. We should know better by now. > > Tom Petch > Andy From andy@netconfcentral.com Wed Aug 5 13:53: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 8B1983A71EA for ; Wed, 5 Aug 2009 13:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 7cA9Tv47qcAl for ; Wed, 5 Aug 2009 13:53:25 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 9CDD73A6908 for ; Wed, 5 Aug 2009 13:53:25 -0700 (PDT) Received: (qmail 22509 invoked from network); 5 Aug 2009 20:53:27 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2009 20:53:26 -0000 X-YMail-OSG: r0VV_0EVM1mdOZJZvawn35dEivhHu68RBpQTM7XP2bz7UWFhWCLMEbIEzUtrIKDLwV0Eqg5De7FV.azboyHoR8L3PZBhbnut77g552tVKhbOKf.BbBFzp2y87acOOpxw_wi9fvnTEXW1eWeUB8mcwmn7plfimMSSlxyUxZzrXqY5v4pYyXTa4ZCXkoCGcp8jw3lRP27z5U07aZZZb5JrQ5OcNjLcSi8myG9feceT8DeZlTLL_NZp.gdA7TuWoPRDzR4qAfXoR.8_18WusavvKJsrH1z97w9B3bvu2R7SzGSWuKaxQIfub_afew.O4N0TDcuypJ1F326t1Ux1eI0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A79F174.5090406@netconfcentral.com> Date: Wed, 05 Aug 2009 13:54:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "tom.petch" References: <4A745B05.6000001@netconfcentral.com><1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com><20090801.214901.199335718.mbj@tail-f.com><4A74BF9F.4060203@netconfcentral.com> <1249211413.3182.43.camel@missotis> <001201ca15e1$fe22d140$0601a8c0@allison> In-Reply-To: <001201ca15e1$fe22d140$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 05 Aug 2009 20:53:26 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Andy Bierman" > Cc: > Sent: Sunday, August 02, 2009 1:10 PM > >> we should strictly distinguish between data node identifiers that live >> in a "target XML namespace" and become names of XML elements in instance >> documents, and names of "schema things" that essentialy belong to a YANG >> module - schema nodes, types, groupings, identities. > > Disagree: there is something going on here, but I have yet to get my mind around > what it is. > the following YANG shows that this problem is not related to the XML namespace in an XPath expression, but also (at least) type names. grouping hhh { container test-top { typedef MyType { type int8; } leaf baz { type MyType; } } } Andy From andy@netconfcentral.com Fri Aug 7 17:56: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 2CDE03A6AA7 for ; Fri, 7 Aug 2009 17:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 CIwMrJZY4edS for ; Fri, 7 Aug 2009 17:56:41 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 5BF8A3A685D for ; Fri, 7 Aug 2009 17:56:41 -0700 (PDT) Received: (qmail 51335 invoked from network); 8 Aug 2009 00:56:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 8 Aug 2009 00:56:42 -0000 X-YMail-OSG: 5P4iRJMVM1mH9ZJDrBDLArCEY9kRdTntOeNts51HS0RjzoEzFJ4C4cOTD35xTBcmlCSh18HcO_b7R.L7h19329eS82nklBkjaL3m1hBkxOIHKuqD3xLpifR255leL.TlwSmJ51Jpl_6Mdu4M1DxFT3gyDMM6TTB8fAhqUWG0kuyPJ9UARA6oX2EqjtlrSVLSWupU1_M8WVS4ATX9IqwX5Ov8xCmBCJ6YzILT2q4a6icJfD.WfDrxxKL3e6F97ariLw_xvYVBPGNfJ5edKh_ESj_aaY0MttsWigW5VLxl27wWu70- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7CCD86.5090204@netconfcentral.com> Date: Fri, 07 Aug 2009 17:57:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: netmod@ietf.org References: <4A745B05.6000001@netconfcentral.com><1249143408.14644.55.camel@missotis> <4A746F6F.7040707@netconfcentral.com><20090801.214901.199335718.mbj@tail-f.com><4A74BF9F.4060203@netconfcentral.com> <1249211413.3182.43.camel@missotis> <001201ca15e1$fe22d140$0601a8c0@allison> <4A79F174.5090406@netconfcentral.com> In-Reply-To: <4A79F174.5090406@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] prefixes in groupings example 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: Sat, 08 Aug 2009 00:56:42 -0000 Andy Bierman wrote: > tom.petch wrote: >> ----- Original Message ----- >> From: "Ladislav Lhotka" >> To: "Andy Bierman" >> Cc: >> Sent: Sunday, August 02, 2009 1:10 PM >> >>> we should strictly distinguish between data node identifiers that live >>> in a "target XML namespace" and become names of XML elements in instance >>> documents, and names of "schema things" that essentialy belong to a YANG >>> module - schema nodes, types, groupings, identities. >> Disagree: there is something going on here, but I have yet to get my mind around >> what it is. >> > > the following YANG shows that this problem > is not related to the XML namespace in an XPath expression, > but also (at least) type names. > > grouping hhh { > container test-top { > > typedef MyType { type int8; } > > leaf baz { > type MyType; > } > } > } > Here is the complete example to show that the proposed solution does not work: grouping hhh { container test-top { typedef MyType { type identityref { base MyBase; } default my-identity; } leaf baz { type MyType; } leaf copy { type leafref { path ../baz; } } } } Does the missing prefix refer to the local module or to the grouping? Sure looks like both to me. It would be nice to resolve this important detail. > > Andy Andy From phil@juniper.net Sat Aug 8 07:50:14 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 4B8DA28C127 for ; Sat, 8 Aug 2009 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Y2sSfkv3hSRT for ; Sat, 8 Aug 2009 07:50:13 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 685FB3A6974 for ; Sat, 8 Aug 2009 07:50:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSn2QpI6nt3hiowTuuUbjGRTheeaP0Zgj@postini.com; Sat, 08 Aug 2009 07:50:17 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; Sat, 8 Aug 2009 07:47:29 -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); Sat, 8 Aug 2009 07:47:29 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:47:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 07:47:28 -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 n78ElRd80639; Sat, 8 Aug 2009 07:47:27 -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 n78EZlY6046698; Sat, 8 Aug 2009 14:35:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908081435.n78EZlY6046698@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1249125235.8328.15.camel@missotis> Date: Sat, 8 Aug 2009 10:35:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2009 14:47:28.0044 (UTC) FILETIME=[266D36C0:01CA1837] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] mandatory mess 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: Sat, 08 Aug 2009 14:50:14 -0000 Ladislav Lhotka writes: >1. Is this factory default configuration (part of) the 'initial default >state' that RFC 4741 talks about? No, I don't think so. This is just a default config content that the device will supply if you don't give one. >2. Will the values set this way be returned in get-config having >with-defaults=false? No. You are free to delete such "factory default" config. >3. Is it possible that this factory default configuration sets some >optional leafs to values that differ from the defaults specified in the >data model? Sure, I could have a default syslog file called "messages" that has a large value for "size" and "count" that are not the normal defaults. Thanks, Phil From muenz@net.in.tum.de Sat Aug 8 15:44: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 56F793A69A5 for ; Sat, 8 Aug 2009 15:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 c4HaFFfLGBfJ for ; Sat, 8 Aug 2009 15:44:49 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 402BF3A69CC for ; Sat, 8 Aug 2009 15:44:48 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 997AE47BFC for ; Sun, 9 Aug 2009 00:44:49 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 0162816EE for ; Sun, 9 Aug 2009 00:44:48 +0200 (CEST) Message-ID: <4A7DFFE0.8010700@net.in.tum.de> Date: Sun, 09 Aug 2009 00:44:48 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704050108030808070104" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] mandatory mess 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: Sat, 08 Aug 2009 22:44:50 -0000 This is a cryptographically signed message in MIME format. --------------ms010704050108030808070104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Reading this e-mail thread, I see a similarity to various cases in the IPFIX configuration data model where parameters (= leaf values) are given by the device if the user does not configure them. The idea is the following: - These leaves always exist if the ancestor node exists. (opposed to leaves whose non-existence has a specific meaning) - The user does not have to configure them. - There is not default value specified in the module. - The value given by the device does not always have to be the same for all occurrences of the leaves. It is assigned dynamically when the ancestor node is created. In IPFIX, these parameters have been modeled as non-mandatory leaves (i.e., without "mandatory true;"). The behavior cannot be formalized. Therefore, the behavior is only specified in the description. I think that the initial device configuration this discussion is about is very similar: Parameters, which always exist (even if not yet configured by the user), are set by the device at startup. However, these parameters are not mandatory, because mandatory means that the user has to provide them when he sends a complete configuration (e.g., with copy-config). I'm not sure if such parameters should be returned as response to get-config having with-defaults=false. It would be logic not to return them because the user has not set them. On the other hand, the parameters are definitively part of the configuration datastore because their values may be dynamically assigned when the ancestor node is created or at startup (not using the same value all the time). Coming back to the YANG guidelines, I think it makes sense to discourage mandatory/min-element!=1 objects at the toplevel. What has been discussed in this thread are parameters that always exist and that are designed by the device unless the user changes them. However, they are not mandatory in the common sense. We had this discussion in Dublin. Having "mandatory true/false" is not sufficient to cover this "third" type of parameter. There was a proposal of "assigned-by system;" or the like, but it did not make it into YANG 1.0. Maybe, this problem can be solved in the next YANG version. Regards, Gerhard Phil Shafer wrote: > Ladislav Lhotka writes: >> 1. Is this factory default configuration (part of) the 'initial default >> state' that RFC 4741 talks about? > > No, I don't think so. This is just a default config content that the > device will supply if you don't give one. > >> 2. Will the values set this way be returned in get-config having >> with-defaults=false? > > No. You are free to delete such "factory default" config. > >> 3. Is it possible that this factory default configuration sets some >> optional leafs to values that differ from the defaults specified in the >> data model? > > Sure, I could have a default syslog file called "messages" that has > a large value for "size" and "count" that are not the normal defaults. > > Thanks, > Phil --------------ms010704050108030808070104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODA4MjI0NDQ4WjAjBgkqhkiG9w0BCQQxFgQU FyhV6qVbpFv4YJzTYagyP078d4UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJ7i/UCvcUuh6btlfeWViPIptHfh93fwRCyJEq6sOx96r/JH ub6IdEuIIf5TegiJ4GtPZFNor4r6U/FJeWuKytbRvIS18vKelyk0K81Us8SMcZbjeqQJAguh nddYCeQH6Tgtsv86SFGVD5IQ8r1XiJgPApBwa33mr/bHzo7X4Z6KvsnjXqN9ZT0DExdtmESK BNhSu6ba6Pg1szWCw60GqnlEOa5HPA+QmD2+nguPZmWe+M3OJmCjGYcEG9VPFUog1/mS0apM 87jxWCGhkk9ykPoiA0yt+Pyi9FaVvtRIpV1jeKk8+OGHyxaw9DepHIIavDoikgAT9pViAJF/ czmdDOkAAAAAAAA= --------------ms010704050108030808070104-- From phil@juniper.net Sat Aug 8 21:24: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 DCE743A69FC for ; Sat, 8 Aug 2009 21:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 xOZcf+vblsMJ for ; Sat, 8 Aug 2009 21:24:11 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 94ED23A6C48 for ; Sat, 8 Aug 2009 21:23:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSn5PXiaI8A+DsQf5t0EBfjwsXRAXJUme@postini.com; Sat, 08 Aug 2009 21:24:06 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; Sat, 8 Aug 2009 21:21:49 -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); Sat, 8 Aug 2009 21:21:49 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 21:21:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 21:21:48 -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 n794Lmd25027; Sat, 8 Aug 2009 21:21:48 -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 n794A767049820; Sun, 9 Aug 2009 04:10:08 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908090410.n794A767049820@idle.juniper.net> To: Gerhard Muenz In-Reply-To: <4A7DFFE0.8010700@net.in.tum.de> Date: Sun, 9 Aug 2009 00:10:07 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2009 04:21:48.0585 (UTC) FILETIME=[E9941990:01CA18A8] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] mandatory mess 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: Sun, 09 Aug 2009 04:24:11 -0000 Gerhard Muenz writes: >In IPFIX, these parameters have been modeled as non-mandatory leaves >(i.e., without "mandatory true;"). The behavior cannot be formalized. >Therefore, the behavior is only specified in the description. We have a proposal for "assigned-by system", but I'm not sure what happened to it. The statement was meant to indicate exactly the scenario you are in, where the value is assigned by the system (device) if no value is given. We have one such scenario in JUNOS (where a "uid" is automatically assigned if none is given). But I don't see this as being involve with the default values discussion, since defaults are meant to be invisible, where these "assigned-by system" leafs are automatically created and always appear there after. Thanks, Phil From andy@netconfcentral.com Sun Aug 9 08:59: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 A01E53A6C34 for ; Sun, 9 Aug 2009 08:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_43=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 ZdBAOUO8pdgh for ; Sun, 9 Aug 2009 08:59:07 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 607FF3A6C99 for ; Sun, 9 Aug 2009 08:59:03 -0700 (PDT) Received: (qmail 50864 invoked from network); 9 Aug 2009 15:59:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 9 Aug 2009 15:59:04 -0000 X-YMail-OSG: 7fTN.3cVM1k8lT1WVD1mGfwfWVXeV_SRvFQUGVcV7YB8lKshsTG_xqxdfYSDDtiVRJpGI8gHI.fcxtw.FdcYwc2yJssyMWjyjbLJ8nS4g8fDzxwyMpQO9U20l3ykwT1azupLQPHgrfq_OCOuXh2EtfDEt_iRaT8poR6ZcVuU8X2N07pbOt217LCm6AWeffqu.Uu2j6P6tGDAo35cHgcOQAvrUV7v8KQSzDmXCHfEpY5qreljywm5moZQpd2IM9IxTvn7ISkgCV5OH6o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7EF28E.2040502@netconfcentral.com> Date: Sun, 09 Aug 2009 09:00:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] staying in synch on data model discovery 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: Sun, 09 Aug 2009 15:59:08 -0000 Hi, I would like to see the NETCONF and NETMOD WGs act more like they play for the same team regarding YANG and all the YANG data models under development. I mostly care about the ietf-netconf-state data model to use the get-schema() operation with YANG. If others want XSD and RNG instead, then that's extra credit, but full support for YANG is a must-have. YANG modules, submodules, and deviation modules all need to be listed in the and retrievable with . However, deviations have no revision that is advertised, yet they clearly have a revision-date just like any other YANG module. This is somewhere between confusing and broken. The field in the operation is mandatory. It should be optional, and if missing, then the agent will pick whatever revision it wants (usually there will just be 1 to pick from). The field in the operation is mandatory. It should be optional, and the default should be 'YANG'. IMO, the use of capabilities instead of YANG features needs to stop. Even more, ALL the data models under way in the NETCONF WG should wait for YANG, and use YANG features, not protocol capabilities to achieve. That will eliminate the possibility that there can be 16 valid variants of the same leaf,and will help start out with a coherent set of YANG modules using the same data types (e.g., ip-address issue). I think the node should have another leaf: leaf moduleType { description "The type of data model file for this schema entry."; type enumeration { enum module { description "Indicates this entry is for a main module."; } enum submodule { description "Indicates this entry is for a sub-module."; } enum deviation { description "Indicates this entry is for a deviation module."; } enum other { description "Indicates this entry is for some other type of module."; } } } This will help operators understand what all the 'extra' entries are for, and allow better filtering of the subtree. Andy From j.schoenwaelder@jacobs-university.de Sun Aug 9 14:03: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 487273A69D7 for ; Sun, 9 Aug 2009 14:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_40=-0.185, 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 Yb8jNSWBE8vM for ; Sun, 9 Aug 2009 14:03:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 55E763A6A2D for ; Sun, 9 Aug 2009 14:03:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B16AFC0016; Sun, 9 Aug 2009 23:03:08 +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 Exr503NIOR+7; Sun, 9 Aug 2009 23:03:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C506EC0014; Sun, 9 Aug 2009 23:03:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CE1F9B80129; Sun, 9 Aug 2009 23:03:06 +0200 (CEST) Date: Sun, 9 Aug 2009 23:03:06 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090809210306.GB4430@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75DC63.2070005@netconfcentral.com> <20090802190021.GC18545@elstar.local> <4A7605DB.7010002@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7605DB.7010002@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 09 Aug 2009 21:03:06 -0000 On Sun, Aug 02, 2009 at 11:32:11PM +0200, Andy Bierman wrote: > So it is the author's responsibility to make sure nobody > ever starts working on module with the same name, during > the several years it may take to reach RFC publication? While name clashes are in principle possible, they are also pretty unlikely to happen in practice. > How does one distinguish foo:DRAFT-00 done in one year > from another foo:DRAFT-00 several years later > when the WG is rechartered to update the original RFC? > > I must have missed that part of the meeting. Good catch - we can use DRAFT-XXXXBIS-00 in that case, where XXXX is the RFC number of the most recent published version of the module. /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 Sun Aug 9 14:23: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 AE7A53A6903 for ; Sun, 9 Aug 2009 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_34=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 gjy4ADTFxluG for ; Sun, 9 Aug 2009 14:23:05 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id E05643A68CC for ; Sun, 9 Aug 2009 14:23:04 -0700 (PDT) Received: (qmail 32282 invoked from network); 9 Aug 2009 21:23:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 9 Aug 2009 21:23:05 -0000 X-YMail-OSG: wBWBKWQVM1lX0IW1O24jlLffeRzjnh8Cf3Dko_mnrgehsno8fqcf9Bdji3xYk2upBSHKiZvR9fUv57WmEYhUSQL2GR9CPz.E9aL4w.oi_njo5P_5UL5OnU7xhXBz7F2OR2t3bcyrzcew4vRfdo3xD8PNTNyisthv4aCRU_GFDup6beBKn.TLk178194DxM3gmfHdCgMRhofu4Gd6cwuKu8AqcYNAyaVYktAjiHpO69VSnnkSJqb3hgH4jNP64DjqoZrXjM3fz6NPUjGfbSW.qLyP6I20GSeTjhPG59lCBQWQVfp6GJ6rpKa2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7F3E81.2000401@netconfcentral.com> Date: Sun, 09 Aug 2009 14:24:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <20090730053929.GA15264@elstar.local> <4A71691C.5000808@netconfcentral.com> <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75DC63.2070005@netconfcentral.com> <20090802190021.GC18545@elstar.local> <4A7605DB.7010002@netconfcentral.com> <20090809210306.GB4430@elstar.local> In-Reply-To: <20090809210306.GB4430@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 09 Aug 2009 21:23:05 -0000 Juergen Schoenwaelder wrote: > On Sun, Aug 02, 2009 at 11:32:11PM +0200, Andy Bierman wrote: > >> So it is the author's responsibility to make sure nobody >> ever starts working on module with the same name, during >> the several years it may take to reach RFC publication? > > While name clashes are in principle possible, they are also pretty > unlikely to happen in practice. > >> How does one distinguish foo:DRAFT-00 done in one year >> from another foo:DRAFT-00 several years later >> when the WG is rechartered to update the original RFC? >> >> I must have missed that part of the meeting. > > Good catch - we can use DRAFT-XXXXBIS-00 in that case, where XXXX is > the RFC number of the most recent published version of the module. > OK just 1 more issue on this section, which is when the IANA request is made. It needs to be at the time of the -00 draft. The foo.yang author has no way of knowing who else might want to use foo.yang. The only way to find out is to search the published I-Ds, but by that time it is too late. It is not the RFC Editor's responsibility to check for any uniqueness except the draft name itself. The 'thing' we use to let the authors check on their own is an IANA registry. Perhaps an on-line script will automate this function and a simple database can be maintained somewhere in ietf.org so the names and prefixes already in use can be viewed or searched. > /js > Andy From j.schoenwaelder@jacobs-university.de Sun Aug 9 14:48:21 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 75BFD3A6959 for ; Sun, 9 Aug 2009 14:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_34=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 t06lVdqYkH5D for ; Sun, 9 Aug 2009 14:48:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4C07D3A680B for ; Sun, 9 Aug 2009 14:48:20 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A97DBC0016; Sun, 9 Aug 2009 23:48:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RkI+E2+M-Ugn; Sun, 9 Aug 2009 23:48:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87B2AC0014; Sun, 9 Aug 2009 23:48:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9928EB801D1; Sun, 9 Aug 2009 23:48:21 +0200 (CEST) Date: Sun, 9 Aug 2009 23:48:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090809214821.GC4430@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75DC63.2070005@netconfcentral.com> <20090802190021.GC18545@elstar.local> <4A7605DB.7010002@netconfcentral.com> <20090809210306.GB4430@elstar.local> <4A7F3E81.2000401@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7F3E81.2000401@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 09 Aug 2009 21:48:21 -0000 On Sun, Aug 09, 2009 at 11:24:17PM +0200, Andy Bierman wrote: > just 1 more issue on this section, which is when the IANA > request is made. It needs to be at the time of the -00 draft. > The foo.yang author has no way of knowing who else might > want to use foo.yang. The only way to find out is to > search the published I-Ds, but by that time it is too late. > > It is not the RFC Editor's responsibility to check for any > uniqueness except the draft name itself. The 'thing' we use to > let the authors check on their own is an IANA registry. I doubt that IANA assignments for -00 IDs is going to be practical nor to I believe the likelyhood of name clashes is high enough to waste lots of bandwidth on this. And even if a clash happens, then all this only becomes an issue when someone implements and ships the clashing IDs implemented on the same server and I assume this someone will detect the problem and take proper action. Perhaps the YANG usage draft needs a sentence that iterates "You should not ship YANG models that have not been formerly published. If you want to implement early (which is encouraged), rename the model so that it falls under your enterprises namespace." /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Aug 9 15:03: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 251F63A68FA for ; Sun, 9 Aug 2009 15:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_50=0.001, 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 WG6w9ycOn-44 for ; Sun, 9 Aug 2009 15:03:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7E5BA3A694E for ; Sun, 9 Aug 2009 15:03:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE680C0019 for ; Mon, 10 Aug 2009 00:03:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xN5DLpSJ-J6W; Mon, 10 Aug 2009 00:03:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01CD8C0016; Mon, 10 Aug 2009 00:03:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0635EB8027A; Mon, 10 Aug 2009 00:03:25 +0200 (CEST) Date: Mon, 10 Aug 2009 00:03:25 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20090809220325.GD4430@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20090727120535.GA10672@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090727120535.GA10672@elstar.local> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] date-and-time canonicalization (option #3) 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: Sun, 09 Aug 2009 22:03:26 -0000 During the Stockholm IETF meeting, the canonicalization of data-and-time was discussed. The current text says that NETCONF server must return date-and-time values in UTC format. That is, I can configure 2009-08-09T23:08:00+02:00 and the server will return the configured time in UTC using the "Z" format: 2009-08-09T21:08:00Z We discussed to what extend this behaviour is desirable and there was rough consensus in the meeting room to stick to the current rules. I can easily see that certain NETCONF users will be pretty surprised by this behaviour (especially enterprises operating local networks in just one time zone) while others will find it cool (operators of networks spanning the globe). So I am wondering whether we can find a solution that makes both "camps" happy. So far, we considered the "always UTC" option and the "server remembers configured time offset" options. Here is the "everything is relative to the servers notion of its time zone offset" proposal: The canonical format for date-and-time values is the format with a numeric time zone offset that is calculated using the device's configured known offset to UTC time. A change of the device's offset to UTC time will cause date-and-time values to change accordingly. Such changes might happen periodically in case a server follows automatically daylight saving time (DST) time zone offset changes. This is a departure from the XSD dateTime rules (XSD requires the "Z" format) but this approach has the advantage that operators deploying NETCONF servers can configure the time zone and thus decide themselves whether they like all dates to be returned in UTC or in a local time zone. As a side effect, a server returning 2009-08-09T23:08:00+02:00 indicates that the server's time offset is +02:00 at the time when the response was generated. Comments? /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 Sun Aug 9 15:48:21 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 7546B3A6997 for ; Sun, 9 Aug 2009 15:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=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 QXlKMHtgY6QZ for ; Sun, 9 Aug 2009 15:48:20 -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 B759F3A68ED for ; Sun, 9 Aug 2009 15:48:20 -0700 (PDT) Received: (qmail 405 invoked from network); 9 Aug 2009 22:48:22 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2009 22:48:22 -0000 X-YMail-OSG: QvSQURkVM1mafyAHWFbC0mrm4ueBjuG9iIp.sPOeiRA3IyLFzROQMxGdaq806lPlifkg.x4OBiqUtAyrV_2FwwZJIE.qhzxLpZGaY0M7O8cbsU1TVbccgI9F___DPEZlS7cA1_JmQ58C2R6nLAB.l9kjFuvY.7mE7WjnxRzQ3txeP.szy88PGxUX1MccjdWmO6oHFJr9fJIf8aZKAdGEkgAKCIIlOVa4zJGABWqYjLPTncpTK7UaBuwVj74tXyEes5rG9WCEDAkFgYOTTMRXxfFE86HjYOMsbp2A0Kh2USCQ3EtR1xk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7F527F.9080705@netconfcentral.com> Date: Sun, 09 Aug 2009 15:49:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75DC63.2070005@netconfcentral.com> <20090802190021.GC18545@elstar.local> <4A7605DB.7010002@netconfcentral.com> <20090809210306.GB4430@elstar.local> <4A7F3E81.2000401@netconfcentral.com> <20090809214821.GC4430@elstar.local> In-Reply-To: <20090809214821.GC4430@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 09 Aug 2009 22:48:21 -0000 Juergen Schoenwaelder wrote: > On Sun, Aug 09, 2009 at 11:24:17PM +0200, Andy Bierman wrote: > >> just 1 more issue on this section, which is when the IANA >> request is made. It needs to be at the time of the -00 draft. >> The foo.yang author has no way of knowing who else might >> want to use foo.yang. The only way to find out is to >> search the published I-Ds, but by that time it is too late. >> >> It is not the RFC Editor's responsibility to check for any >> uniqueness except the draft name itself. The 'thing' we use to >> let the authors check on their own is an IANA registry. > > I doubt that IANA assignments for -00 IDs is going to be practical nor > to I believe the likelyhood of name clashes is high enough to waste > lots of bandwidth on this. And even if a clash happens, then all this > only becomes an issue when someone implements and ships the clashing > IDs implemented on the same server and I assume this someone will > detect the problem and take proper action. > Sometimes I-Ds in progress last for several years. Sometimes the RFC never gets published. The purpose of the registry is to help early implementors maintain unique names. If unique names in I-Ds is not a concern, then we should just tell WGs to put whatever they want, but IANA may change it in the end. If another WG wants a module with the same name, the first WG better hurry up and publish their RFC before the other WG. We don't need a lot of CLRs for something that does not matter. There is no point in a registry for reserving unique identifiers that have been in use for several years already. The 'DRAFT' string in the URI SHOULD be used, to indicate the assignment is not from IANA. > Perhaps the YANG usage draft needs a sentence that iterates "You > should not ship YANG models that have not been formerly published. If > you want to implement early (which is encouraged), rename the model so > that it falls under your enterprises namespace." no -- this does not help early implementors at all, especially if an I-D reaches a 'stable-snapshot' state. (We haven't had one of those around here for awhile ;-) We should leave the namespace empty if we want vendors to change it. Otherwise they won't. > > /js > Andy From andy@netconfcentral.com Sun Aug 9 15:59: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 BA9AC3A6A55 for ; Sun, 9 Aug 2009 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_34=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 ZtPytQ9OQKki for ; Sun, 9 Aug 2009 15:59:55 -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 0FADD3A6A9A for ; Sun, 9 Aug 2009 15:59:55 -0700 (PDT) Received: (qmail 22421 invoked from network); 9 Aug 2009 22:59:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 9 Aug 2009 22:59:55 -0000 X-YMail-OSG: dedePSIVM1mDahBOBrVXXrNhUO1BAlO4zQT5.pBbz7da6YajAlA0Gr2JL_WfY2bj61UyjQf1Mi8_Z119P7BZUPsoHgXBRja_Yg8hkULUW_FXoQR8BZseUuVmbsIlabSpCGaz74E6vdSe1jCwIDxukEDeU6NvyWNULIf6VtEFOxWT.XhsuCXR2_3mjM0fpH8mrTFwGoPm6x5Fb0KPEJQRtKwnpbFdSOKOJMM8MfuU8ovdgk0y3SFCCnP7Em6LAayH_betoqsJcde4UkQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7F5534.4020105@netconfcentral.com> Date: Sun, 09 Aug 2009 16:01:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <20090730103516.GB16076@elstar.local> <4A721FFB.9090500@netconfcentral.com> <20090801215430.GA18163@elstar.local> <4A75CBB1.2040300@netconfcentral.com> <20090802174659.GA18545@elstar.local> <4A75DC63.2070005@netconfcentral.com> <20090802190021.GC18545@elstar.local> <4A7605DB.7010002@netconfcentral.com> <20090809210306.GB4430@elstar.local> <4A7F3E81.2000401@netconfcentral.com> <20090809214821.GC4430@elstar.local> In-Reply-To: <20090809214821.GC4430@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] yang usage: temporary URI issue 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: Sun, 09 Aug 2009 22:59:55 -0000 Juergen Schoenwaelder wrote: > On Sun, Aug 09, 2009 at 11:24:17PM +0200, Andy Bierman wrote: > >> just 1 more issue on this section, which is when the IANA >> request is made. It needs to be at the time of the -00 draft. >> The foo.yang author has no way of knowing who else might >> want to use foo.yang. The only way to find out is to >> search the published I-Ds, but by that time it is too late. >> >> It is not the RFC Editor's responsibility to check for any >> uniqueness except the draft name itself. The 'thing' we use to >> let the authors check on their own is an IANA registry. > > I doubt that IANA assignments for -00 IDs is going to be practical nor > to I believe the likelyhood of name clashes is high enough to waste > lots of bandwidth on this. And even if a clash happens, then all this > only becomes an issue when someone implements and ships the clashing > IDs implemented on the same server and I assume this someone will > detect the problem and take proper action. > actually -- the module names are just as important wrt/ uniqueness as the namespace URI -- maybe more because humans will start remembering the module names. The import-stmt expects the module name to be unique. But that is good -- if somebody sees a new I-D with ietf-foo.yang in it, they will hopefully say something. Otherwise, the module name will get changed before RFC publication. > Perhaps the YANG usage draft needs a sentence that iterates "You > should not ship YANG models that have not been formerly published. If > you want to implement early (which is encouraged), rename the model so > that it falls under your enterprises namespace." > > /js > Andy From mbj@tail-f.com Mon Aug 10 03:34: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 BC18F3A6A3B for ; Mon, 10 Aug 2009 03:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 zTsD7yDDLMpg for ; Mon, 10 Aug 2009 03:34:54 -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 E5B543A6A5A for ; Mon, 10 Aug 2009 03:34:53 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4BF9661600E; Mon, 10 Aug 2009 12:34:57 +0200 (CEST) Date: Mon, 10 Aug 2009 12:34:56 +0200 (CEST) Message-Id: <20090810.123456.138462525.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A7CCD86.5090204@netconfcentral.com> References: <001201ca15e1$fe22d140$0601a8c0@allison> <4A79F174.5090406@netconfcentral.com> <4A7CCD86.5090204@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] prefixes in groupings example 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: Mon, 10 Aug 2009 10:34:54 -0000 Andy Bierman wrote: > Here is the complete example to show that the proposed > solution does not work: > > > grouping hhh { > container test-top { > > typedef MyType { > type identityref { > base MyBase; > } > default my-identity; > } > > leaf baz { > type MyType; > } > leaf copy { > type leafref { > path ../baz; > } > } > } > } > > > Does the missing prefix refer to the local module or > to the grouping? Sure looks like both to me. I think you are mixing two issues here. The first is when unprefixed identifiers are resolved. The current proposal addresses this. The second issue is how default values can be specified when the lexicographical representation of the value contains XML prefixes (and thus depends on the XML context). This applies to instance-identifier and identityref. This issue is not handled in the draft. We have three options: 1. do not allow default values for these types 2. allow default values but require prefixes 3. allow default values and make the prefixes optional Suggested text for option 3 to go into 9.10.3: When an identityref is given a default value using the "default" statement, the default value MAY have a prefix. If a prefix is present on the identity name, it refers to an identity defined in the module which was imported with that prefix. Otherwise an identity with the matching name MUST be defined in the current module or an included submodule. /martin From mbj@tail-f.com Mon Aug 10 03:40:20 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 0C1473A6BBF for ; Mon, 10 Aug 2009 03:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 fSyKrf3ht0T9 for ; Mon, 10 Aug 2009 03:40:19 -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 AA52D28C102 for ; Mon, 10 Aug 2009 03:40:18 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 15DC7616010; Mon, 10 Aug 2009 12:40:21 +0200 (CEST) Date: Mon, 10 Aug 2009 12:40:21 +0200 (CEST) Message-Id: <20090810.124021.111892628.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <000701ca151f$b3238760$0601a8c0@allison> References: <006d01ca0ba1$bc1344a0$0601a8c0@allison> <20090730.214800.216128611.mbj@tail-f.com> <000701ca151f$b3238760$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] Comments on draft-ietf-netmod-yang-07.txt 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: Mon, 10 Aug 2009 10:40:20 -0000 "tom.petch" wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, July 30, 2009 9:48 PM > > > > "tom.petch" wrote: > > > Martin > > > > > > Some wordings that have bugged me for a while. > > > > > > 5.1 ..."by using the enterprise or organization name as a prefix." > > > Do you really mean prefix? only I think of prefix as shorthand and while > IBM, > > > Cisco or HP might qualify, other organization names would not. > > > > The text you quoted is preceeded by an "e.g." -- this is just a > > friendly suggestion. If it is better, I can remove the quoted text. > > I still wonder what you had in mind. Actually, this text was written by Juergen for SMIng (see section 2 of rfc 3780). > I would expect the enterprise or > organization name to be in the namespace URI, not in the prefix, and the rest > of > the paragraph does seem to be about namespace names not prefix > names. Hmm. Is it the term "prefix" that is unfortunate? The idea was that if the acme company writes a bgp module, it could be called ACME-BGP. I.e. the company name is used as a prefix in the module name. I have fixed the rest of your comments. /martin > On the other hand, unique and consistent prefix names would make a big > difference to the ease of use of yang, as I perceive it having done, totally > informally, for SMI. So, at the risk of opening another XPath-like can of > worms, I wonder what support there would be for that eg require all non-RFC > prefix start with a character that flags them as enterprise defined. > > > > 5.5 .."searches up the levels of hierarchy in the schema tree" > > > levels of hierarchy has a suggestion of all the nodes at a level whereas I > > > think > > > that this means search the path to the root. > > > > Me, Phil and Lada came up with this replacement text: > > > > OLD: > > > > When a YANG implementation resolves a reference to an unprefixed type > > or grouping, or one which uses the prefix of the local module, it > > searches up the levels of hierarchy in the schema tree, starting at > > the current level, for the definition of the type or grouping. > > > > NEW: > > > > A reference to an unprefixed type or grouping, or one which uses the > > prefix of the current module, is resolved by locating the closest > > matching "typedef" or "grouping" statement among the immediate > > substatments of each ancestor statement. > > Ok (/statments/statements/) > > > > 6 " YANG modules are written in the UTF-8 [RFC3629] character set." > > > > > > UTF-8 is not a character set in the lexicons I use; character encoding, > > > transfer format, character syntax but not character set. > > > > NEW: > > > > YANG modules use the UTF-8 [RFC3629] character encoding. > > Yes > > > > 6.1.3 "up to at most the column of the double quote character." > > > seems imprecise, leaving the option of everything up to or some way short > > > of > or > > > whatever an implementation chooses > > > > How about this: > > > > If the double quoted string contains a line break followed by space > > or tab characters which is used to indent the text according to the > > layout in the YANG file, this leading whitespace is stripped from > > the string, up to the column of the double quote character, or to > > the first non-whitespace character, whichever occurs first. > > Yes ( /which is/which are/ ) > > > > 6.2.1 "All groupings defined within a parent node " > > > well no, grouping names, otherwise it sounds like the identifiers defined > > > within > > > the grouping. > > > > Fixed. > > > > > 7.1.3 "with the exception of data node identifiers defined inside a > > > grouping > " > > > well, only when they are 'uses'd in another module; needs adding IMO > > > > It says See section 7.12 for details. We have rewritten this section > > to: > > > > > > 7.12. The uses Statement > > > > The "uses" statement is used to reference a "grouping" definition. > > It takes one argument, which is the name of the grouping. > > > > The effect of a "uses" reference to a grouping is that the nodes > > defined by the grouping are copied into the current schema tree, and > > then updated according to the refinement and augment statements. > > > > The identifiers defined in the grouping are not bound to a namespace > > until the contents of the grouping are added to the schema tree via a > > "uses" statement that does not appear inside a "grouping" statement, > > a which point they are bound to the namespace of the current module. > > Ok > > > > 9.9.2 "Predicates are used only for constraining the values for the > > > key nodes for list entries" > > > or leaflists? > > > > Fixed. > > > > > > /martin > From phil@juniper.net Mon Aug 10 06:36: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 5AA593A6E41 for ; Mon, 10 Aug 2009 06:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 Rbz-X3Kd4p-D for ; Mon, 10 Aug 2009 06:36:46 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 666CA3A6CF2 for ; Mon, 10 Aug 2009 06:36:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAibjJNHDWJaPoQYI4sWw9nD+moTJis@postini.com; Mon, 10 Aug 2009 06:36:50 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; Mon, 10 Aug 2009 06:35: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); Mon, 10 Aug 2009 06:35:38 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:35:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:35: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 n7ADZad42982; Mon, 10 Aug 2009 06:35: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 n7ADNsfq058820; Mon, 10 Aug 2009 13:23:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101323.n7ADNsfq058820@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090809210306.GB4430@elstar.local> Date: Mon, 10 Aug 2009 09:23:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 13:35:36.0959 (UTC) FILETIME=[71A558F0:01CA19BF] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Mon, 10 Aug 2009 13:36:47 -0000 Juergen Schoenwaelder writes: >Good catch - we can use DRAFT-XXXXBIS-00 in that case, where XXXX is >the RFC number of the most recent published version of the module. I thought (but may be wrong) that URN space was hierarchically managed. So putting "DRAFT" in the middle allows that whole subhierarchy to be labeled as swamp water. Putting it at the end means the drafts are polluting someone else's domain. Thanks, Phil From phil@juniper.net Mon Aug 10 06:41: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 86CCC3A6AA4 for ; Mon, 10 Aug 2009 06:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 P1NYgyujsXjD for ; Mon, 10 Aug 2009 06:41:43 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 6A4B73A6834 for ; Mon, 10 Aug 2009 06:41:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAjmYkaOT7MZAMDSzcE3pS0/p58v/wD@postini.com; Mon, 10 Aug 2009 06:41:47 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; Mon, 10 Aug 2009 06:40:26 -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); Mon, 10 Aug 2009 06:40:26 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:40:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:40:25 -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 n7ADeNd44945; Mon, 10 Aug 2009 06:40:24 -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 n7ADSgiM058861; Mon, 10 Aug 2009 13:28:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101328.n7ADSgiM058861@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090809220325.GD4430@elstar.local> Date: Mon, 10 Aug 2009 09:28:42 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 13:40:25.0208 (UTC) FILETIME=[1D74A780:01CA19C0] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] date-and-time canonicalization (option #3) 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: Mon, 10 Aug 2009 13:41:45 -0000 Juergen Schoenwaelder writes: >I can easily see that certain NETCONF users will be pretty surprised >by this behaviour (especially enterprises operating local networks in >just one time zone) while others will find it cool (operators of >networks spanning the globe). So I am wondering whether we can find a >solution that makes both "camps" happy. Global operators (and many national multi-time-zone ones) don't configure a time zone on the box, defaulting it to UTC. So this proposal (follow the configured time zone) should make everyone happy. Thanks, Phil From phil@juniper.net Mon Aug 10 06:45: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 A259D3A6AA4 for ; Mon, 10 Aug 2009 06:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 fQiRt01bpQxi for ; Mon, 10 Aug 2009 06:45:42 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id A31BD3A67B3 for ; Mon, 10 Aug 2009 06:45:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAkiTnIl+cJfYI5P070XSbnieJV/eCE@postini.com; Mon, 10 Aug 2009 06:45:46 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; Mon, 10 Aug 2009 06:44:02 -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); Mon, 10 Aug 2009 06:44:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:44:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 06:44:01 -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 n7ADi1d46298; Mon, 10 Aug 2009 06:44:01 -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 n7ADWJar058890; Mon, 10 Aug 2009 13:32:20 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101332.n7ADWJar058890@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A7F5534.4020105@netconfcentral.com> Date: Mon, 10 Aug 2009 09:32:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 13:44:01.0706 (UTC) FILETIME=[9E7FA0A0:01CA19C0] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Mon, 10 Aug 2009 13:45:42 -0000 Andy Bierman writes: >actually -- the module names are just as important wrt/ uniqueness >as the namespace URI -- maybe more because humans will start >remembering the module names. The import-stmt expects the >module name to be unique. I don't think yang requires unique module names, since independent parties may each decide to name their module "fred" or "cool" or "cooler-still". Yang suggests (SHOULD) but without a responsible naming scheme, you can't depend on it. Thanks, Phil From andy@netconfcentral.com Mon Aug 10 08: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 DC7593A6D5F for ; Mon, 10 Aug 2009 08:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 WtPBa4tSxxfv for ; Mon, 10 Aug 2009 08:35:33 -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 395383A67EF for ; Mon, 10 Aug 2009 08:35:33 -0700 (PDT) Received: (qmail 59283 invoked from network); 10 Aug 2009 15:35:34 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2009 15:35:34 -0000 X-YMail-OSG: tzHmbtkVM1l8RPPcxFWUlIyCVFq_R._pWB.MnbJq0eYH2w4mlJdA3D1VegPJoSO1YM2kxl04ggilgl41LXlRcKdPMJltbwlYCV6PXej8JaJ7SnaYJmBXk4SLMyO5agmKvtNyo0PHQSurJ.5z.hAJVhpMMJCK4tXejUZXm_8FMeky7LjCaphXgdMiOx.CFy0lLQ4TqZ5H3v2qi0DIyw.mpcsScOYBV67Fmax5tWsF5M689O5RBsFaTxnbYKy4LuhgV6SmR.mIgRIIb3JYRjnWbXnUHTJmDBMmrhH5xfwIazefshUjgv4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A803E1A.9000807@netconfcentral.com> Date: Mon, 10 Aug 2009 08:34:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908101332.n7ADWJar058890@idle.juniper.net> In-Reply-To: <200908101332.n7ADWJar058890@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Mon, 10 Aug 2009 15:35:34 -0000 Phil Shafer wrote: > Andy Bierman writes: >> actually -- the module names are just as important wrt/ uniqueness >> as the namespace URI -- maybe more because humans will start >> remembering the module names. The import-stmt expects the >> module name to be unique. > > I don't think yang requires unique module names, since independent > parties may each decide to name their module "fred" or "cool" or > "cooler-still". Yang suggests (SHOULD) but without a responsible > naming scheme, you can't depend on it. > I disagree. This needs to be clarified in the YANG spec. module A { ... import X { prefix x; revision 2009-01-01; } ... } module B { ... import X { prefix x; revision 2009-01-01; } ... } The same module X MUST be used, at least on the same agent. The import-stmt and include-stmt do not have any way of differentiating modules with the same name. > Thanks, > Phil > Andy From phil@juniper.net Mon Aug 10 09:57: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 57CC33A6A99 for ; Mon, 10 Aug 2009 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 xGXknOGq6DFX for ; Mon, 10 Aug 2009 09:57:56 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id A100E3A6BCF for ; Mon, 10 Aug 2009 09:57:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSoBRl3RIbTD1oONxS89Pt8LvRwGPk3cC@postini.com; Mon, 10 Aug 2009 09:58:00 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; Mon, 10 Aug 2009 09:53:45 -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); Mon, 10 Aug 2009 09:53:45 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 09:53:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 09:53:44 -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 n7AGrid34143; Mon, 10 Aug 2009 09:53:44 -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 n7AGg2IF060554; Mon, 10 Aug 2009 16:42:02 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908101642.n7AGg2IF060554@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A803E1A.9000807@netconfcentral.com> Date: Mon, 10 Aug 2009 12:42:02 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2009 16:53:44.0758 (UTC) FILETIME=[1F538560:01CA19DB] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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: Mon, 10 Aug 2009 16:57:57 -0000 Andy Bierman writes: >This needs to be clarified in the YANG spec. 7.1. The module Statement ... Private module names are assigned by the organization owning the module without a central registry. It is RECOMMENDED to choose module names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix. The namespace is the unique key, not the module name. Module names are like file names: try to be unique, use directories to keep them separate. Thanks, Phil From cfinss@dial.pipex.com Mon Aug 10 10:24: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 6AC8D28C14D for ; Mon, 10 Aug 2009 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_39=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 zchSfyOyUZ4T for ; Mon, 10 Aug 2009 10:24:42 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 767DE3A6F09 for ; Mon, 10 Aug 2009 10:24:13 -0700 (PDT) X-Trace: 240559387/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.6/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.6 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: ApYFAMv0f0o+vGQG/2dsb2JhbABEgmyNPsAxCYQPBYIn X-IronPort-AV: E=Sophos;i="4.43,354,1246834800"; d="scan'208";a="240559387" X-IP-Direction: IN Received: from 1cust6.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.6]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Aug 2009 18:24:15 +0100 Message-ID: <001401ca19d6$e2d228c0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <006d01ca0ba1$bc1344a0$0601a8c0@allison><20090730.214800.216128611.mbj@tail-f.com><000701ca151f$b3238760$0601a8c0@allison> <20090810.124021.111892628.mbj@tail-f.com> Date: Mon, 10 Aug 2009 13:58:39 +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] Comments on draft-ietf-netmod-yang-07.txt 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: Mon, 10 Aug 2009 17:24:43 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Monday, August 10, 2009 12:40 PM > "tom.petch" wrote: > > ----- Original Message ----- > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Thursday, July 30, 2009 9:48 PM > > > > > > "tom.petch" wrote: > > > > Martin > > > > > > > > Some wordings that have bugged me for a while. > > > > > > > > 5.1 ..."by using the enterprise or organization name as a prefix." > > > > Do you really mean prefix? only I think of prefix as shorthand and while > > IBM, > > > > Cisco or HP might qualify, other organization names would not. > > > > > > The text you quoted is preceeded by an "e.g." -- this is just a > > > friendly suggestion. If it is better, I can remove the quoted text. > > > > I still wonder what you had in mind. > > Actually, this text was written by Juergen for SMIng (see section 2 of > rfc 3780). > > > I would expect the enterprise or > > organization name to be in the namespace URI, not in the prefix, and the rest > > of > > the paragraph does seem to be about namespace names not prefix > > names. > > Hmm. Is it the term "prefix" that is unfortunate? The idea was that > if the acme company writes a bgp module, it could be called ACME-BGP. > I.e. the company name is used as a prefix in the module name. Ah, now I am with you. I was reading prefix as in bgp:ipAddress not in the more generic sense. Perhaps expand the sentence to "e.g., by using the enterprise or organization name as a prefix for the module name." lest anyone else make the same mistake as I. Tom Petch > > I have fixed the rest of your comments. > > > /martin > > From mbj@tail-f.com Mon Aug 10 13:05: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 B548E28C271 for ; Mon, 10 Aug 2009 13:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_39=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 xJbjt5h2DHMa for ; Mon, 10 Aug 2009 13:05:08 -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 C69AF3A6F23 for ; Mon, 10 Aug 2009 13:05:08 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5AD6D616005; Mon, 10 Aug 2009 22:05:11 +0200 (CEST) Date: Mon, 10 Aug 2009 22:05:10 +0200 (CEST) Message-Id: <20090810.220510.171994873.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <001401ca19d6$e2d228c0$0601a8c0@allison> References: <000701ca151f$b3238760$0601a8c0@allison> <20090810.124021.111892628.mbj@tail-f.com> <001401ca19d6$e2d228c0$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] Comments on draft-ietf-netmod-yang-07.txt 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: Mon, 10 Aug 2009 20:05:09 -0000 "tom.petch" wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, August 10, 2009 12:40 PM > > > "tom.petch" wrote: > > > ----- Original Message ----- > > > From: "Martin Bjorklund" > > > To: > > > Cc: > > > Sent: Thursday, July 30, 2009 9:48 PM > > > > > > > > "tom.petch" wrote: > > > > > Martin > > > > > > > > > > Some wordings that have bugged me for a while. > > > > > > > > > > 5.1 ..."by using the enterprise or organization name as a prefix." > > > > > Do you really mean prefix? only I think of prefix as shorthand and > > > > > while > > > IBM, > > > > > Cisco or HP might qualify, other organization names would not. > > > > > > > > The text you quoted is preceeded by an "e.g." -- this is just a > > > > friendly suggestion. If it is better, I can remove the quoted text. > > > > > > I still wonder what you had in mind. > > > > Actually, this text was written by Juergen for SMIng (see section 2 of > > rfc 3780). > > > > > I would expect the enterprise or > > > organization name to be in the namespace URI, not in the prefix, and the > rest > > > of > > > the paragraph does seem to be about namespace names not prefix > > > names. > > > > Hmm. Is it the term "prefix" that is unfortunate? The idea was that > > if the acme company writes a bgp module, it could be called ACME-BGP. > > I.e. the company name is used as a prefix in the module name. > > Ah, now I am with you. I was reading prefix as in bgp:ipAddress not in the > more > generic sense. > > Perhaps expand the sentence to > "e.g., by using the enterprise or organization name as a prefix for the module > name." > lest anyone else make the same mistake as I. Fixed. /martin From randy_presuhn@mindspring.com Mon Aug 10 13:09: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 F28F028C143 for ; Mon, 10 Aug 2009 13:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001] 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 Hh22SxZVEPMd for ; Mon, 10 Aug 2009 13:09:44 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id B9E4C28C248 for ; Mon, 10 Aug 2009 13:09:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=p0BqgxhVfhIgstzzZvYPnFXvh4KuRsOy/jPjSanwTwEJYR+X+BVQ9oIyZ3G8eT9V; 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.93.93] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MabBR-0000xT-FS for netmod@ietf.org; Mon, 10 Aug 2009 16:09:29 -0400 Message-ID: <00b401ca19f6$cb50cd80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20090727120535.GA10672@elstar.local> <20090809220325.GD4430@elstar.local> Date: Mon, 10 Aug 2009 13:11:47 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69681aa1a528366878937473cd4376d67b08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.93 Subject: Re: [netmod] date-and-time canonicalization (option #3) 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: Mon, 10 Aug 2009 20:09:45 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Sunday, August 09, 2009 3:03 PM > Subject: [netmod] date-and-time canonicalization (option #3) ... > The canonical format for date-and-time values is the format with a > numeric time zone offset that is calculated using the device's > configured known offset to UTC time. A change of the device's offset > to UTC time will cause date-and-time values to change accordingly. > Such changes might happen periodically in case a server follows > automatically daylight saving time (DST) time zone offset changes. > > This is a departure from the XSD dateTime rules (XSD requires the "Z" > format) but this approach has the advantage that operators deploying > NETCONF servers can configure the time zone and thus decide themselves > whether they like all dates to be returned in UTC or in a local time > zone. As a side effect, a server returning > > 2009-08-09T23:08:00+02:00 > > indicates that the server's time offset is +02:00 at the time when the > response was generated. > > Comments? ... For some use cases this would be desirable, for others not. Sometimes a time or schedule really needs to be in terms of local clock time. On the one side, consider intrusion detection sensors that need to be in harmony with an office's local hours of operation. On the other side, consider backup runs scheduled to avoid overtaxing an enterprise's global network. The former absolutely needs to take local daylight savings time changes into account. The latter probably should not. There really is a semantic difference between "schedule according to local clock time" and "schedule for purposes of global coordination". A model that loses that semantic will shortchange one or the other. I *do* think this issue can be separated from that of canonicalization. After all, it's really a matter of the semantics of the bit of configuration data. If the goal is to handle both semantics in a single data type, then this bit needs to show up in the representation. If we decide that the difference in semantics merits having two distinct types (which happen to look very much alike), then there's no need for in in the representation. Randy From andy@netconfcentral.com Mon Aug 10 15:32: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 C8F5F3A6B4E for ; Mon, 10 Aug 2009 15:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 bGQEccFTBk5k for ; Mon, 10 Aug 2009 15:32:43 -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 0A7D63A6E2D for ; Mon, 10 Aug 2009 15:32:43 -0700 (PDT) Received: (qmail 34628 invoked from network); 10 Aug 2009 22:32:45 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2009 22:32:44 -0000 X-YMail-OSG: WJ0VrzcVM1lQEfI7ojqObrUxDMphlxbrMn1wsutIGhR9NURBn2nxsSuAb0XO9xqjw8Es6ijQhIe1qx8qbGY9GBgkNQdQ.D61EI5zJ9F7PHMwsABwdbE2joB_Xf1dfbr2lfxbbOk8xCu9CnL4d2ztLM3y2l0_.RwDR..wkJgJpPnPJNqw6MaG4V2DWg_x9FzLv64ooyfU0v._eDCR7DGti1cEaQIA8uK19cvHFWyuwwFInxZI4dWaonJlhGAWRjJ79rldjs764KF7AW62JdRIi2W67F7ArMHmeSC1Npm83vPM4igj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A80A05B.3050200@netconfcentral.com> Date: Mon, 10 Aug 2009 15:34:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <001201ca15e1$fe22d140$0601a8c0@allison> <4A79F174.5090406@netconfcentral.com> <4A7CCD86.5090204@netconfcentral.com> <20090810.123456.138462525.mbj@tail-f.com> In-Reply-To: <20090810.123456.138462525.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Mon, 10 Aug 2009 22:32:43 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Here is the complete example to show that the proposed >> solution does not work: >> >> >> grouping hhh { >> container test-top { >> >> typedef MyType { >> type identityref { >> base MyBase; >> } >> default my-identity; >> } >> >> leaf baz { >> type MyType; >> } >> leaf copy { >> type leafref { >> path ../baz; >> } >> } >> } >> } >> >> >> Does the missing prefix refer to the local module or >> to the grouping? Sure looks like both to me. > > I think you are mixing two issues here. > > The first is when unprefixed identifiers are resolved. The current > proposal addresses this. > IMO, not very well. It is also really confusing for YANG language users, which is kind of important. > The second issue is how default values can be specified when the > lexicographical representation of the value contains XML prefixes (and > thus depends on the XML context). This applies to instance-identifier > and identityref. This issue is not handled in the draft. We have three > options: > We seem to disagree on this seemingly unimportant point. YANG module definition files (i.e., written in YANG) do not contain any XML prefixes -- only YANG prefixes, as identified by a [module-name] key or [module-name, revision-date] key. Within a NETCONF PDU, XML prefixes are bound to module namespace URI strings. There does not have to be a 1:1 correspondence between the module selected in XML and that selected in YANG. As Phil pointed out, unique module names are optional. The use of a revision in each module is even optional. Maybe YANG is too complicated. Are we building something like an experimental jet to break the sound barrier or a standard commuter plane any pilot can fly easily and safely? Neither? Both? I've seen the X-1, and it had so many unlabeled and strange knobs, I doubt anybody but Chuck Yeager could operate it. I hope YANG doesn't turn out the same way. I suspect it is already too late for that. > 1. do not allow default values for these types > 2. allow default values but require prefixes > 3. allow default values and make the prefixes optional > > Suggested text for option 3 to go into 9.10.3: > > When an identityref is given a default value using the "default" > statement, the default value MAY have a prefix. If a prefix is > present on the identity name, it refers to an identity defined in > the module which was imported with that prefix. Otherwise an > identity with the matching name MUST be defined in the current > module or an included submodule. > > > > /martin > Andy From mbj@tail-f.com Tue Aug 11 00:55: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 158283A694A for ; Tue, 11 Aug 2009 00:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.074, 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 gx0q+Y3na+kH for ; Tue, 11 Aug 2009 00:55:42 -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 3BA5C3A6A0D for ; Tue, 11 Aug 2009 00:55:42 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 958F976C59C; Tue, 11 Aug 2009 09:55:44 +0200 (CEST) Date: Tue, 11 Aug 2009 09:55:44 +0200 (CEST) Message-Id: <20090811.095544.105030598.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A80A05B.3050200@netconfcentral.com> References: <4A7CCD86.5090204@netconfcentral.com> <20090810.123456.138462525.mbj@tail-f.com> <4A80A05B.3050200@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] prefixes in groupings example 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, 11 Aug 2009 07:55:43 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > The second issue is how default values can be specified when the > > lexicographical representation of the value contains XML prefixes (and > > thus depends on the XML context). This applies to instance-identifier > > and identityref. This issue is not handled in the draft. We have three > > options: > > > > We seem to disagree on this seemingly unimportant point. Hmm. I have not seen a proposal from you for how to handle identityref default values. I apologize if I missed it; if I did could you point me to it? In either case, could you comment on my proposed text? > Maybe YANG is too complicated. > Are we building something like an experimental jet to break the > sound barrier or a standard commuter plane any pilot can > fly easily and safely? Neither? Both? FWIW, regarding the first issue, "late binding" in xpath expressions, one of our customers who is modelling their entire product in YANG ran into this problem - they need to be able to reference things where the grouping is used. It is just one data point of course, but it indicates that some early users are in fact using also the features we believe are "advanced". /martin From andy@netconfcentral.com Tue Aug 11 02:46: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 D71953A6F9B for ; Tue, 11 Aug 2009 02:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_36=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 cmz9e9sxL6k1 for ; Tue, 11 Aug 2009 02:46:27 -0700 (PDT) Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by core3.amsl.com (Postfix) with SMTP id F1F913A7000 for ; Tue, 11 Aug 2009 02:46:26 -0700 (PDT) Received: from [68.142.200.226] by n16.bullet.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 09:46:28 -0000 Received: from [68.142.201.250] by t7.bullet.mud.yahoo.com with NNFMP; 11 Aug 2009 09:46:28 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 09:46:28 -0000 X-Yahoo-Newman-Id: 814827.79301.bm@omp411.mail.mud.yahoo.com Received: (qmail 92375 invoked from network); 11 Aug 2009 09:46:28 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2009 09:46:28 -0000 X-YMail-OSG: vkMJ1zoVM1nTar7fAj8wSPrreymDoWKAfm6D28gOcOHHay3rmG3aj7KiXZqZe.N1yor6rljItp_N7zL.bTPwrlaPwsB8EM6YKg3sx81bIMaTGXwkHy2pPamLxRzh60lhrJn_c.SbPwQn.fjwjhqJVY3WA_BRXC6pP2jmm3hwegZhjQbby9oOnZBjQfTVLzli0PbH387LwXLotlYpTq497mTU9Ilk.htKilThOdB9z7tym6D9Vl4WFm_5oaJliqHTLMQmGev.IxLIsBM3dqp5Sa.AlEJNAK5pYbvJQdjFJdSXQwXskXjr_wa_XXknK19W.xtKgVvx4Bgq2lrzQNCjGGlwcrz5EOTr9cP8ZVQcD9Z.xFd5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A813E46.9000601@netconfcentral.com> Date: Tue, 11 Aug 2009 02:47:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7CCD86.5090204@netconfcentral.com> <20090810.123456.138462525.mbj@tail-f.com> <4A80A05B.3050200@netconfcentral.com> <20090811.095544.105030598.mbj@tail-f.com> In-Reply-To: <20090811.095544.105030598.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 11 Aug 2009 09:46:27 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> The second issue is how default values can be specified when the >>> lexicographical representation of the value contains XML prefixes (and >>> thus depends on the XML context). This applies to instance-identifier >>> and identityref. This issue is not handled in the draft. We have three >>> options: >>> >> We seem to disagree on this seemingly unimportant point. > > Hmm. I have not seen a proposal from you for how to handle > identityref default values. I apologize if I missed it; if I did > could you point me to it? In either case, could you comment on my > proposed text? > I'm still trying to figure out how the type-name prefix thing works. If I have a local type like in my example: module foo { grouping ggg { container top-level { typedef MyType { ... } leaf X { type MyType; } } } } According to your rule, leaf X will have type foo:MyType. It is bound to the 'foo' namespace because it is a type, not an XPath expression. module goo { import foo { prefix foo; } uses foo:ggg; } Now, even though there is a typedef called MyType in module goo, it is goo:MyType, and not a match. The YANG compiler is forced to call this an error, even though the intent was to use the MyType in the grouping, not the one tied to the foo namespace. >> Maybe YANG is too complicated. >> Are we building something like an experimental jet to break the >> sound barrier or a standard commuter plane any pilot can >> fly easily and safely? Neither? Both? > > FWIW, regarding the first issue, "late binding" in xpath expressions, > one of our customers who is modelling their entire product in YANG ran > into this problem - they need to be able to reference things where the > grouping is used. It is just one data point of course, but it > indicates that some early users are in fact using also the features we > believe are "advanced". > The issue is localized cost -- how to support advanced features without making everything too complicated. Maybe it is not possible in this case. The more we think about groupings, the more we find there is to know. > > /martin > Andy From mbj@tail-f.com Tue Aug 11 03:13: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 DB8163A700D for ; Tue, 11 Aug 2009 03:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=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 usaVNX6NTEtP for ; Tue, 11 Aug 2009 03:13:36 -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 1CBA53A6E22 for ; Tue, 11 Aug 2009 03:13:36 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C57A576C59C; Tue, 11 Aug 2009 12:13:31 +0200 (CEST) Date: Tue, 11 Aug 2009 12:13:31 +0200 (CEST) Message-Id: <20090811.121331.71537449.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A813E46.9000601@netconfcentral.com> References: <4A80A05B.3050200@netconfcentral.com> <20090811.095544.105030598.mbj@tail-f.com> <4A813E46.9000601@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] prefixes in groupings example 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, 11 Aug 2009 10:13:37 -0000 Andy Bierman wrote: > I'm still trying to figure out how the type-name prefix > thing works. > > If I have a local type like in my example: > > module foo { > grouping ggg { > container top-level { > typedef MyType { ... } > leaf X { type MyType; } > } > } > } > > > According to your rule, leaf X will have type foo:MyType. > It is bound to the 'foo' namespace because it is a type, > not an XPath expression. Yes. > module goo { > > import foo { prefix foo; } > uses foo:ggg; > } > > Now, even though there is a typedef called MyType in > module goo, it is goo:MyType, and not a match. > The YANG compiler is forced to call this an error, > even though the intent was to use the MyType in the > grouping, not the one tied to the foo namespace. No, with the module foo above, this is not an error. Why would it be an error? leaf X in the grouping has a type, and it is the same type in all modules where 'ggg' is used. This works as before. /martin From andy@netconfcentral.com Tue Aug 11 05:05: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 00C243A70BA for ; Tue, 11 Aug 2009 05:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_36=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 i9urIneHqwzp for ; Tue, 11 Aug 2009 05:05:01 -0700 (PDT) Received: from n22b.bullet.mail.mud.yahoo.com (n22b.bullet.mail.mud.yahoo.com [68.142.206.159]) by core3.amsl.com (Postfix) with SMTP id D55343A7098 for ; Tue, 11 Aug 2009 05:04:59 -0700 (PDT) Received: from [68.142.200.226] by n22.bullet.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 12:04:26 -0000 Received: from [68.142.201.241] by t7.bullet.mud.yahoo.com with NNFMP; 11 Aug 2009 12:04:26 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 12:04:26 -0000 X-Yahoo-Newman-Id: 110586.94880.bm@omp402.mail.mud.yahoo.com Received: (qmail 93640 invoked from network); 11 Aug 2009 12:04:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2009 12:04:25 -0000 X-YMail-OSG: p_vPY5YVM1niwrvXCgHI7KUzSqHZcURbmzzDXosf0YWgwkMvjIrYWkZ.XzLa7dPoFIdMX79sjD.osHyYI__jkhcwVQ7YJtT9v0Uj_g.KfQqZwA5lk7ILyGw0x0C6o2g7FXC2cmTBhg1nU0wzxb2OUDjJ83plnbSPauU19JYCoC3f8TYE6OSgQxSnb16A3WoH0FirbKSMjQrCiYYCb4yGUkpLswQaQ59T4059iTR_qnD9J6q83SP6hmM57eI_Coa_aeSvQArc6VBNZSa5RTtLB7mmQJ2IetR3gEG8P4CGAceIsOSh_mPZysGGEOBHdvkEUq.g42Go18OUCTCzqnv8xQvf8ACW77COGjjHZL7hWHAsuJfu X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A815E22.8060801@netconfcentral.com> Date: Tue, 11 Aug 2009 05:03:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A80A05B.3050200@netconfcentral.com> <20090811.095544.105030598.mbj@tail-f.com> <4A813E46.9000601@netconfcentral.com> <20090811.121331.71537449.mbj@tail-f.com> In-Reply-To: <20090811.121331.71537449.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 11 Aug 2009 12:05:02 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I'm still trying to figure out how the type-name prefix >> thing works. >> >> If I have a local type like in my example: >> >> module foo { >> grouping ggg { >> container top-level { >> typedef MyType { ... } >> leaf X { type MyType; } >> } >> } >> } >> >> >> According to your rule, leaf X will have type foo:MyType. >> It is bound to the 'foo' namespace because it is a type, >> not an XPath expression. > > Yes. > >> module goo { >> >> import foo { prefix foo; } >> uses foo:ggg; >> } >> >> Now, even though there is a typedef called MyType in >> module goo, it is goo:MyType, and not a match. >> The YANG compiler is forced to call this an error, >> even though the intent was to use the MyType in the >> grouping, not the one tied to the foo namespace. > > No, with the module foo above, this is not an error. Why would it be > an error? leaf X in the grouping has a type, and it is the same type > in all modules where 'ggg' is used. This works as before. > > it works because we do a late binding on the type name prefix, not an early binding as your rule specifies. There is no foo:MyType. If the prefix 'foo' was present, then foo:MyType should not resolve in module goo. Local typedefs are special, because they cannot mask a global type (a global foo:MyType would be OK, except that the grouping ggg could be used anywhere but module foo). I think the rule you are proposing is in the right direction, but I do not agree that this problem is specific to XPath or XML prefixes. It seems to me that all explicit prefixes are early binding and all missing prefixes are late-binding. This works whether the definition is in a grouping or not (same module: early vs. late produces the same result). If this is the case, then why can't the rule be stated that way? > /martin > Andy From mbj@tail-f.com Tue Aug 11 05:44: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 A7E033A70BC for ; Tue, 11 Aug 2009 05:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, J_CHICKENPOX_36=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 g7zzCP4QpGNN for ; Tue, 11 Aug 2009 05:44:39 -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 E83EA3A67E7 for ; Tue, 11 Aug 2009 05:44:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CD6A676C59C; Tue, 11 Aug 2009 14:33:01 +0200 (CEST) Date: Tue, 11 Aug 2009 14:33:01 +0200 (CEST) Message-Id: <20090811.143301.217566638.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A815E22.8060801@netconfcentral.com> References: <4A813E46.9000601@netconfcentral.com> <20090811.121331.71537449.mbj@tail-f.com> <4A815E22.8060801@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] prefixes in groupings example 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, 11 Aug 2009 12:44:40 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I'm still trying to figure out how the type-name prefix > >> thing works. > >> > >> If I have a local type like in my example: > >> > >> module foo { > >> grouping ggg { > >> container top-level { > >> typedef MyType { ... } > >> leaf X { type MyType; } > >> } > >> } > >> } > >> > >> > >> According to your rule, leaf X will have type foo:MyType. > >> It is bound to the 'foo' namespace because it is a type, > >> not an XPath expression. > > > > Yes. > > > >> module goo { > >> > >> import foo { prefix foo; } > >> uses foo:ggg; > >> } > >> > >> Now, even though there is a typedef called MyType in > >> module goo, it is goo:MyType, and not a match. > >> The YANG compiler is forced to call this an error, > >> even though the intent was to use the MyType in the > >> grouping, not the one tied to the foo namespace. > > > > No, with the module foo above, this is not an error. Why would it be > > an error? leaf X in the grouping has a type, and it is the same type > > in all modules where 'ggg' is used. This works as before. > > > > > > it works because we do a late binding on the type name prefix, > not an early binding as your rule specifies. This is getting confusing. Can we agree that there is no late binding for types in the current draft 07? From section 5.4: Grouping, type, and identity names are resolved in the context in which they are defined, rather than the context in which they are used. Users of groupings, typedefs, and identities are not required to import modules or include submodules to satisfy all references made by the original definition. This behaves like static scoping in a conventional programming language. Our proposal is to introduce "late binding" for references in XPath expressions. The current rule for type identifiers are the same as before. > I think the rule you are proposing is in the right direction, > but I do not agree that this problem is specific to XPath or > XML prefixes. Ok, so it seems we agree so far, but in addition to what we propose, you also want to change the current rule for type/grouping/... to also use late binding. > It seems to me that all explicit prefixes are > early binding and all missing prefixes are late-binding. > This works whether the definition is in a grouping or not > (same module: early vs. late produces the same result). I prefer to keep the type/grouping rule the way it is, and not do late binding in this case. Consider this case: module foo { typedef my-type { type int32; } grouping foo { leaf x { type my-type; } } } module goo { import foo { prefix foo; } typedef my-type { type string; } uses foo:foo; } Now, with your rule, goo:x is of type string. I think this is confusing. /martin From andy@netconfcentral.com Tue Aug 11 05:49: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 F0BD43A70C3 for ; Tue, 11 Aug 2009 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=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 IpJZ8Tw1c61u for ; Tue, 11 Aug 2009 05:49:44 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id B99B73A684A for ; Tue, 11 Aug 2009 05:49:32 -0700 (PDT) Received: (qmail 86741 invoked from network); 11 Aug 2009 12:48:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 11 Aug 2009 12:48:59 -0000 X-YMail-OSG: ZBZ5OOMVM1kYNZaE7ztYpTWLbnR.CA5u0ZsRYbbCY9JXfSYbqlyw6C2Q9C3.zVj9A5mkij6hoVdjTACegeKF.8SMEHoPYTP4UDLH6WTGp_lnHt4YjqeTq2H.zY06V4RImE_eS8Gtiz7GuCfOnMi2Qv8cT2Wa4e3JNcNw2bHZnZ0vDXx8DMVmzW8gTDCHfnSCM1uHSsaWhPya0xARKdEi1fslMx9nKi4afi7jT_Nn8Cj6B6wVJCMUI.WWUHlPiH7sOMnQgT14_nSgaiJPD.F2Xq_btW6f2CznMfvi9o57UUnPTtVbwkHSAVvTRPQxl.Oi6HMlk5BAGLi1vsyb.hLlJaZzU4U.xyrxYlV9AvJ.5y4i4ZP7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A81690D.7000906@netconfcentral.com> Date: Tue, 11 Aug 2009 05:50:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A813E46.9000601@netconfcentral.com> <20090811.121331.71537449.mbj@tail-f.com> <4A815E22.8060801@netconfcentral.com> <20090811.143301.217566638.mbj@tail-f.com> In-Reply-To: <20090811.143301.217566638.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 11 Aug 2009 12:49:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> I'm still trying to figure out how the type-name prefix >>>> thing works. >>>> >>>> If I have a local type like in my example: >>>> >>>> module foo { >>>> grouping ggg { >>>> container top-level { >>>> typedef MyType { ... } >>>> leaf X { type MyType; } >>>> } >>>> } >>>> } >>>> >>>> >>>> According to your rule, leaf X will have type foo:MyType. >>>> It is bound to the 'foo' namespace because it is a type, >>>> not an XPath expression. >>> Yes. >>> >>>> module goo { >>>> >>>> import foo { prefix foo; } >>>> uses foo:ggg; >>>> } >>>> >>>> Now, even though there is a typedef called MyType in >>>> module goo, it is goo:MyType, and not a match. >>>> The YANG compiler is forced to call this an error, >>>> even though the intent was to use the MyType in the >>>> grouping, not the one tied to the foo namespace. >>> No, with the module foo above, this is not an error. Why would it be >>> an error? leaf X in the grouping has a type, and it is the same type >>> in all modules where 'ggg' is used. This works as before. >>> >>> >> it works because we do a late binding on the type name prefix, >> not an early binding as your rule specifies. > > This is getting confusing. Can we agree that there is no late binding > for types in the current draft 07? From section 5.4: > > Grouping, type, and identity names are resolved in the context in > which they are defined, rather than the context in which they are > used. Users of groupings, typedefs, and identities are not required > to import modules or include submodules to satisfy all references > made by the original definition. This behaves like static scoping in > a conventional programming language. > > Our proposal is to introduce "late binding" for references in XPath > expressions. The current rule for type identifiers are the same as > before. > >> I think the rule you are proposing is in the right direction, >> but I do not agree that this problem is specific to XPath or >> XML prefixes. > > Ok, so it seems we agree so far, but in addition to what we propose, > you also want to change the current rule for type/grouping/... to also > use late binding. > >> It seems to me that all explicit prefixes are >> early binding and all missing prefixes are late-binding. >> This works whether the definition is in a grouping or not >> (same module: early vs. late produces the same result). > > I prefer to keep the type/grouping rule the way it is, and not do late > binding in this case. Consider this case: > > module foo { > > typedef my-type { type int32; } > > grouping foo { > leaf x { type my-type; } > } > } > Add this grouping: grouping foobar { container fubar { typedef my-type { type boolean; } leaf y { type my-type; } } } So you are saying this is the same as: grouping foobar { } This is not illegal (yet) since there needs to be a uses-stmt to determine if my-type is a conflict. > module goo { > > import foo { prefix foo; } > > typedef my-type { type string; } > > uses foo:foo; > } > > Now, with your rule, goo:x is of type string. I think this is > confusing. Either way it is confusing. Your rule does not work for local typedefs: module foo { grouping foo { container fubar { typedef my-type { type boolean; } leaf y { type my-type; } } } } module goo { import foo { prefix foo; } uses foo:foo; } This is the normal use-case for local typedefs, not an obscure corner-case. By your rule, leaf goo:y has type foo:my-type. There is no foo:my-type. There is only a local typedef for my-type within container goo:fubar. But you say this works by your early-binding rule. I still don't get it. Sorry. > > > /martin > Andy From mbj@tail-f.com Tue Aug 11 06:07: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 DEE993A716E for ; Tue, 11 Aug 2009 06:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, J_CHICKENPOX_36=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 CdiKIOCtL8iB for ; Tue, 11 Aug 2009 06:07:41 -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 B39233A7032 for ; Tue, 11 Aug 2009 06:07:40 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 69A2376C59C; Tue, 11 Aug 2009 14:59:54 +0200 (CEST) Date: Tue, 11 Aug 2009 14:59:54 +0200 (CEST) Message-Id: <20090811.145954.34232467.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A81690D.7000906@netconfcentral.com> References: <4A815E22.8060801@netconfcentral.com> <20090811.143301.217566638.mbj@tail-f.com> <4A81690D.7000906@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] prefixes in groupings example 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, 11 Aug 2009 13:07:41 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> I'm still trying to figure out how the type-name prefix > >>>> thing works. > >>>> > >>>> If I have a local type like in my example: > >>>> > >>>> module foo { > >>>> grouping ggg { > >>>> container top-level { > >>>> typedef MyType { ... } > >>>> leaf X { type MyType; } > >>>> } > >>>> } > >>>> } > >>>> > >>>> > >>>> According to your rule, leaf X will have type foo:MyType. > >>>> It is bound to the 'foo' namespace because it is a type, > >>>> not an XPath expression. > >>> Yes. > >>> > >>>> module goo { > >>>> > >>>> import foo { prefix foo; } > >>>> uses foo:ggg; > >>>> } > >>>> > >>>> Now, even though there is a typedef called MyType in > >>>> module goo, it is goo:MyType, and not a match. > >>>> The YANG compiler is forced to call this an error, > >>>> even though the intent was to use the MyType in the > >>>> grouping, not the one tied to the foo namespace. > >>> No, with the module foo above, this is not an error. Why would it be > >>> an error? leaf X in the grouping has a type, and it is the same type > >>> in all modules where 'ggg' is used. This works as before. > >>> > >>> > >> it works because we do a late binding on the type name prefix, > >> not an early binding as your rule specifies. > > > > This is getting confusing. Can we agree that there is no late binding > > for types in the current draft 07? From section 5.4: > > > > Grouping, type, and identity names are resolved in the context in > > which they are defined, rather than the context in which they are > > used. Users of groupings, typedefs, and identities are not required > > to import modules or include submodules to satisfy all references > > made by the original definition. This behaves like static scoping in > > a conventional programming language. > > > > Our proposal is to introduce "late binding" for references in XPath > > expressions. The current rule for type identifiers are the same as > > before. > > > >> I think the rule you are proposing is in the right direction, > >> but I do not agree that this problem is specific to XPath or > >> XML prefixes. > > > > Ok, so it seems we agree so far, but in addition to what we propose, > > you also want to change the current rule for type/grouping/... to also > > use late binding. > > > >> It seems to me that all explicit prefixes are > >> early binding and all missing prefixes are late-binding. > >> This works whether the definition is in a grouping or not > >> (same module: early vs. late produces the same result). > > > > I prefer to keep the type/grouping rule the way it is, and not do late > > binding in this case. Consider this case: > > > > module foo { > > > > typedef my-type { type int32; } > > > > grouping foo { > > leaf x { type my-type; } > > } > > } > > > > > Add this grouping: > > grouping foobar { > container fubar { > typedef my-type { type boolean; } > leaf y { type my-type; } > } > } This defines a grouping foobar with one container fubar with one leaf y which is a boolean. > So you are saying this is the same as: > > grouping foobar { > > } This defines an empty grouping. They are not the same. > This is not illegal (yet) since there needs to be a uses-stmt > to determine if my-type is a conflict. > > > > > module goo { > > > > import foo { prefix foo; } > > > > typedef my-type { type string; } > > > > uses foo:foo; > > } > > > > Now, with your rule, goo:x is of type string. I think this is > > confusing. > > > Either way it is confusing. > Your rule does not work for local typedefs: > > module foo { > > grouping foo { > container fubar { > typedef my-type { type boolean; } > leaf y { type my-type; } > } > } > } > > module goo { > > import foo { prefix foo; } > > uses foo:foo; > } > > This is the normal use-case for local typedefs, > not an obscure corner-case. Agreed. > By your rule, leaf goo:y has type foo:my-type. No, by the rules of draft 07 (which I do not want to change), 'y' gets its type when it is defined; it is a boolean. No 'uses' can ever change that. /martin From andy@netconfcentral.com Tue Aug 11 06:49: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 D37BC3A684A for ; Tue, 11 Aug 2009 06:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_31=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 K4Raf7ny8gm8 for ; Tue, 11 Aug 2009 06:49:40 -0700 (PDT) Received: from n24.bullet.mail.mud.yahoo.com (n24.bullet.mail.mud.yahoo.com [68.142.206.163]) by core3.amsl.com (Postfix) with SMTP id F22D73A6ACF for ; Tue, 11 Aug 2009 06:48:44 -0700 (PDT) Received: from [209.191.108.96] by n24.bullet.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 13:47:44 -0000 Received: from [68.142.201.66] by t3.bullet.mud.yahoo.com with NNFMP; 11 Aug 2009 13:47:44 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 11 Aug 2009 13:47:44 -0000 X-Yahoo-Newman-Id: 352491.67742.bm@omp418.mail.mud.yahoo.com Received: (qmail 60965 invoked from network); 11 Aug 2009 13:47:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2009 13:47:43 -0000 X-YMail-OSG: EGjMRlQVM1kk9zFadegpYpU1J9XNZiKQHl1ciavbAnRSGp7VzklmlmP0IbwfgK3T_hdCfK6J.suRFCKsJ8MQq7ABJ8WhR4xXY3hjfSibCoQ7Fv341b0pGJqOuuXat9l79qima_1i08R8FDzJEBcMMjCCpSHbDiXiKxwEWxW5nG1VjJMunmyXpxMbmcDSkTTmGBIsFl1dEbbmFzCzRzAnhDJ5NMFx0AK2GIzfuUPRNKeC._qNiZvrav0qfelcZnD56ypjosKKyJYdrjfTSL84jIpf1A4mmMlWcSStoc99IPrn6aW_9AM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8176D2.3010305@netconfcentral.com> Date: Tue, 11 Aug 2009 06:49:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A815E22.8060801@netconfcentral.com> <20090811.143301.217566638.mbj@tail-f.com> <4A81690D.7000906@netconfcentral.com> <20090811.145954.34232467.mbj@tail-f.com> In-Reply-To: <20090811.145954.34232467.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 11 Aug 2009 13:49:40 -0000 .... > >> So you are saying this is the same as: >> >> grouping foobar { >> >> } > > This defines an empty grouping. They are not the same. > this was a cut instead of a copy. sorry. >> Either way it is confusing. >> Your rule does not work for local typedefs: >> >> module foo { >> >> grouping foo { >> container fubar { >> typedef my-type { type boolean; } >> leaf y { type my-type; } >> } >> } >> } >> >> module goo { >> >> import foo { prefix foo; } >> >> uses foo:foo; >> } >> >> This is the normal use-case for local typedefs, >> not an obscure corner-case. > > Agreed. > >> By your rule, leaf goo:y has type foo:my-type. > > No, by the rules of draft 07 (which I do not want to change), 'y' gets > its type when it is defined; it is a boolean. No 'uses' can ever > change that. > draft-07 is a large document. Can you point out the exact test that says leaf y is bound to the local typedef, even in a grouping? I agree this is the case, because I don't want to change my code any more than you do. The internal pointer to the correct typedef finds the one inside the grouping. That never changes, no matter how many times the group is refined-and-cloned into a uses-stmt. module foo { prefix foo; typedef my-type { type int8; } grouping XXX { container xxx { typedef my-type { type int16; } leaf a { type my-type; } leaf b { type foo:my-type; } } } } yangdump will flag the local 'my-type' typedef as a 'shadow global type' error, even without any uses-stmt. But normally (without the global my-type) the xxx grouping would work fine in another module, so my-type == foo:my-type in another module. So I guess you are right. The local typedef gets bound to module foo right away, even if it is in a grouping. It seems weird that the namespace for the element changes but not the data type of the element, for an external uses-stmt, especially since local typedefs are not really exported like real typedefs. I am still confused whether or not the text in the draft matches the behavior we supposedly agree is correct, but I do not have any replacement text, so I will drop any objection. > > /martin > Andy From mbj@tail-f.com Tue Aug 11 07:04: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 3F4F13A70FA for ; Tue, 11 Aug 2009 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.140, 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 1fcnO4BJHDZE for ; Tue, 11 Aug 2009 07:04:39 -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 4E0A23A691D for ; Tue, 11 Aug 2009 07:03:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F2FE76C59C; Tue, 11 Aug 2009 16:01:35 +0200 (CEST) Date: Tue, 11 Aug 2009 16:01:34 +0200 (CEST) Message-Id: <20090811.160134.106266928.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8176D2.3010305@netconfcentral.com> References: <4A81690D.7000906@netconfcentral.com> <20090811.145954.34232467.mbj@tail-f.com> <4A8176D2.3010305@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] prefixes in groupings example 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, 11 Aug 2009 14:04:40 -0000 Andy Bierman wrote: > draft-07 is a large document. > Can you point out the exact test that says > leaf y is bound to the local typedef, > even in a grouping? I agree this is the case, > because I don't want to change my code any more than you do. >From section 5.4: Grouping, type, and identity names are resolved in the context in which they are defined, rather than the context in which they are used. Users of groupings, typedefs, and identities are not required to import modules or include submodules to satisfy all references made by the original definition. This behaves like static scoping in a conventional programming language. /martin From j.schoenwaelder@jacobs-university.de Tue Aug 11 08:09: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 71AA63A6D9A for ; Tue, 11 Aug 2009 08:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 3RLWiE9-O859 for ; Tue, 11 Aug 2009 08:09:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C9EC63A6BC8 for ; Tue, 11 Aug 2009 08:08:41 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E14CC0029; Tue, 11 Aug 2009 17:07:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gyL30iCtweD2; Tue, 11 Aug 2009 17:07:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67757C002F; Tue, 11 Aug 2009 17:07:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 44F78C3BA4D; Tue, 11 Aug 2009 17:07:36 +0200 (CEST) Date: Tue, 11 Aug 2009 17:07:36 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090811150736.GD1042@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , NETMOD Working Group References: <4A803E1A.9000807@netconfcentral.com> <200908101642.n7AGg2IF060554@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908101642.n7AGg2IF060554@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yang usage: temporary URI issue 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, 11 Aug 2009 15:09:39 -0000 On Mon, Aug 10, 2009 at 06:42:02PM +0200, Phil Shafer wrote: > Andy Bierman writes: > >This needs to be clarified in the YANG spec. > > 7.1. The module Statement > ... > Private module names are assigned by the organization owning the > module without a central registry. It is RECOMMENDED to choose > module names that will have a low probability of colliding with > standard or other enterprise modules and submodules, e.g., by using > the enterprise or organization name as a prefix. > > The namespace is the unique key, not the module name. Module names > are like file names: try to be unique, use directories to keep them > separate. Then the language is broken. For me, the XML namespace is used on the wire to identify elements in instance documents while the module name is used to refer to YANG modules. We now use prefixed module names like ietf-yang-types and we RECOMMEND that other organizations also properly prefix module names. Of course, there is no guarantee of clashes but the probability should be small and in cases there is a clash, you need to resolve it somehow at module compile time by some renaming exercise. Since on the wire XML namespaces are used that we designed to be name clash free (nobody stops a poor implementor of course to screw things up), I think we are fine. /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 Tue Aug 11 08:11: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 AC20C3A6DC8 for ; Tue, 11 Aug 2009 08:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 xMblRpgMGsS2 for ; Tue, 11 Aug 2009 08:11:09 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id D44553A6D9A for ; Tue, 11 Aug 2009 08:11:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSoGJRdfkDBKgfjyhBllKDa4Ql5b2EXBh@postini.com; Tue, 11 Aug 2009 08:11:13 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, 11 Aug 2009 07: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, 11 Aug 2009 07: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, 11 Aug 2009 07:52:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 07: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 n7BEqjd77483; Tue, 11 Aug 2009 07: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 n7BEf397067774; Tue, 11 Aug 2009 14:41:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908111441.n7BEf397067774@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090811.143301.217566638.mbj@tail-f.com> Date: Tue, 11 Aug 2009 10:41:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2009 14:52:46.0436 (UTC) FILETIME=[63713A40:01CA1A93] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 11 Aug 2009 15:11:09 -0000 Martin Bjorklund writes: >Our proposal is to introduce "late binding" for references in XPath >expressions. The current rule for type identifiers are the same as >before. To be clear, this is not late binding for prefixes, only for element names. Thanks, Phil From Washam.Fan@huaweisymantec.com Tue Aug 11 20:26:22 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 18F6A3A6A41 for ; Tue, 11 Aug 2009 20:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_50=0.001, J_CHICKENPOX_36=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 5yh3eOGXOGel for ; Tue, 11 Aug 2009 20:26:21 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 375753A6A38 for ; Tue, 11 Aug 2009 20:26:21 -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 <0KO800HGSS0ORB20@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 12 Aug 2009 10:24:25 +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 <0KO800GZTS0O0Y00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 12 Aug 2009 10:24:24 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 12 Aug 2009 10:24:24 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 12 Aug 2009 10:24:24 +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: <4A813E46.9000601@netconfcentral.com> References: <4A7CCD86.5090204@netconfcentral.com> <20090810.123456.138462525.mbj@tail-f.com> <4A80A05B.3050200@netconfcentral.com> <20090811.095544.105030598.mbj@tail-f.com> <4A813E46.9000601@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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, 12 Aug 2009 03:26:22 -0000 Hi, > I'm still trying to figure out how the type-name prefix > thing works. > > If I have a local type like in my example: > > module foo { > grouping ggg { > container top-level { > typedef MyType { ... } > leaf X { type MyType; } > } > } > } > > > According to your rule, leaf X will have type foo:MyType. > It is bound to the 'foo' namespace because it is a type, > not an XPath expression. > > module goo { > > import foo { prefix foo; } > uses foo:ggg; > } > > Now, even though there is a typedef called MyType in > module goo, it is goo:MyType, and not a match. > The YANG compiler is forced to call this an error, > even though the intent was to use the MyType in the > grouping, not the one tied to the foo namespace. > To my understanding, type identifier/XPath exprs/anything else with prefixes in groupings should be resolved in where it is defined not it is used. Once resolved, the references should be kept unchanged regardless of "early binding" or "late binding". In other words, That the references can not be determined until the grouping is used makes no sense to me. washam From mbj@tail-f.com Wed Aug 12 00:03: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 D437A3A6A38 for ; Wed, 12 Aug 2009 00:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.132, 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 CJPtOaXoIKUL for ; Wed, 12 Aug 2009 00:03:04 -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 BFA8C3A695D for ; Wed, 12 Aug 2009 00:03:03 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F031276C4D1; Wed, 12 Aug 2009 09:00:57 +0200 (CEST) Date: Wed, 12 Aug 2009 09:00:57 +0200 (CEST) Message-Id: <20090812.090057.122296722.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A7EF28E.2040502@netconfcentral.com> References: <4A7EF28E.2040502@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] staying in synch on data model discovery 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, 12 Aug 2009 07:03:04 -0000 Hi Andy, Andy Bierman wrote: > I mostly care about the ietf-netconf-state data model to > use the get-schema() operation with YANG. If others want > XSD and RNG instead, then that's extra credit, but full > support for YANG is a must-have. I agree. > YANG modules, submodules, and deviation modules all need > to be listed in the and retrievable with . Yes. That is the intention of the current design. > However, deviations have no revision that is advertised, > yet they clearly have a revision-date just like any other > YANG module. This is somewhere between confusing and broken. What makes you think that modules with deviation statements are not advertised with their revision? > The field in the operation is mandatory. > It should be optional, and if missing, then the > agent will pick whatever revision it wants (usually > there will just be 1 to pick from). > > The field in the operation is mandatory. > It should be optional, and the default should be 'YANG'. I agree that these two parameters should be made optional, but I think that an error should be returned if there are multiple revisions and/or formats. In most cases there will be just one revision and one format so that's the one that will be returned. > IMO, the use of capabilities instead of YANG features needs > to stop. Agreed. For the current drafts, I think this applies to partial-lock which we don't want to change at this point, and with-defaults which I believe Juergen commented on in some other thread. I think the monitoring draft is fine. > I think the node should have another leaf: > > leaf moduleType { > description > "The type of data model file for this schema entry."; > type enumeration { > enum module { > description > "Indicates this entry is for a main module."; > } > enum submodule { > description > "Indicates this entry is for a sub-module."; > } > enum deviation { > description > "Indicates this entry is for a deviation module."; > } > enum other { > description > "Indicates this entry is for some other type of module."; > } > } > } I don't think this is necessary, and in any case, there is no such thing as a 'deviation' module. In theory, any module / submodule can have deviation statements. /martin From andy@netconfcentral.com Wed Aug 12 01:49: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 B2F623A698B for ; Wed, 12 Aug 2009 01:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 nEQjTXTPpnKe for ; Wed, 12 Aug 2009 01:49:24 -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 2E0613A6B08 for ; Wed, 12 Aug 2009 01:49:04 -0700 (PDT) Received: (qmail 83006 invoked from network); 12 Aug 2009 08:34:37 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 12 Aug 2009 08:34:37 -0000 X-YMail-OSG: srrIbcsVM1mUFoFdWnG4XdCh_uu.UA1JAoNci4Pu2TwEIu4E9UC7KOTcDJOCaRclu4ga3yl9ITVx6hsIH_q0wBOmlEtxVEMW99ciIz9xWdPmCzRkuOU3lwXcwsTpkp_gE9jQZoo98XZwmDtywMAuLGfZhPd7DKx5LBw2j94UeOIPBtrz0tpkS_Du9S6rpEwSv5UCC.B4.4pvH4rpifDtsJWUxKRP1D.U31PEsm3xKSQU0EbGjAnCIoKLR5tPivgrxiWXSRdzfFqfnZnGrBSd6q0F1qjR0gcaWOLy0uDi4N_bK7dHvuS381e.gq3UeELfbdisZAR5lQJrs7LocdxhcJ2ZhCk3mfJqumAxbjtLNOc7tlOT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A827E79.7040306@netconfcentral.com> Date: Wed, 12 Aug 2009 01:34:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7EF28E.2040502@netconfcentral.com> <20090812.090057.122296722.mbj@tail-f.com> In-Reply-To: <20090812.090057.122296722.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] staying in synch on data model discovery 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, 12 Aug 2009 08:49:25 -0000 Martin Bjorklund wrote: > Hi Andy, > > Andy Bierman wrote: >> I mostly care about the ietf-netconf-state data model to >> use the get-schema() operation with YANG. If others want >> XSD and RNG instead, then that's extra credit, but full >> support for YANG is a must-have. > > I agree. > >> YANG modules, submodules, and deviation modules all need >> to be listed in the and retrievable with . > > Yes. That is the intention of the current design. > >> However, deviations have no revision that is advertised, >> yet they clearly have a revision-date just like any other >> YANG module. This is somewhere between confusing and broken. > > What makes you think that modules with deviation statements are not > advertised with their revision? The module capability does not include a revision date for the deviations that are attached to a particular module. So if there is more than 1 version of a module advertised as a deviation, it is not known by the manager which version is being used as the deviation for 'foo' module=foo&revision=2009-01-01?deviations=bar,baz,baz2 So when I retrieve bar, baz, or baz2, I have no idea what to put in the mandatory version field. IMO -- kind of broken. > >> The field in the operation is mandatory. >> It should be optional, and if missing, then the >> agent will pick whatever revision it wants (usually >> there will just be 1 to pick from). >> >> The field in the operation is mandatory. >> It should be optional, and the default should be 'YANG'. > > I agree that these two parameters should be made optional, but I think > that an error should be returned if there are multiple revisions > and/or formats. In most cases there will be just one revision and one > format so that's the one that will be returned. > >> IMO, the use of capabilities instead of YANG features needs >> to stop. > > Agreed. For the current drafts, I think this applies to partial-lock > which we don't want to change at this point, and with-defaults which I > believe Juergen commented on in some other thread. I think the > monitoring draft is fine. > >> I think the node should have another leaf: >> >> leaf moduleType { >> description >> "The type of data model file for this schema entry."; >> type enumeration { >> enum module { >> description >> "Indicates this entry is for a main module."; >> } >> enum submodule { >> description >> "Indicates this entry is for a sub-module."; >> } >> enum deviation { >> description >> "Indicates this entry is for a deviation module."; >> } >> enum other { >> description >> "Indicates this entry is for some other type of module."; >> } >> } >> } Got to love that augment-stmt. Who cares about standards when you got namespaces! ;-) > > I don't think this is necessary, and in any case, there is no such > thing as a 'deviation' module. In theory, any module / submodule can > have deviation statements. > > > /martin > Andy From mbj@tail-f.com Wed Aug 12 02:23: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 CD0113A6A11 for ; Wed, 12 Aug 2009 02:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=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 Kwg8JIUR3KPw for ; Wed, 12 Aug 2009 02:23:12 -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 F07A83A635F for ; Wed, 12 Aug 2009 02:23:11 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B2F276C4D1; Wed, 12 Aug 2009 10:52:42 +0200 (CEST) Date: Wed, 12 Aug 2009 10:52:41 +0200 (CEST) Message-Id: <20090812.105241.134338006.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A827E79.7040306@netconfcentral.com> References: <4A7EF28E.2040502@netconfcentral.com> <20090812.090057.122296722.mbj@tail-f.com> <4A827E79.7040306@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] staying in synch on data model discovery 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, 12 Aug 2009 09:23:12 -0000 Andy Bierman wrote: > >> However, deviations have no revision that is advertised, > >> yet they clearly have a revision-date just like any other > >> YANG module. This is somewhere between confusing and broken. > > > > What makes you think that modules with deviation statements are not > > advertised with their revision? > > The module capability does not include a revision date > for the deviations that are attached to a particular module. But you advertise your deviations module, and include the revision there: urn:foo?module=foo&revision=2009-01-01?deviations=bar urn:bar?module=bar&revision=2009-04-01 So even if the bar module exists in multiple revisions (this would happen if bar contains deviations AND reusable typedefs / groupings, and some other modules import bar by different revision...), only one is implemented by the device. We do not support that you advertise multiple versions of a module with data nodes and / or deviations. /martin From mehmet.ersue@nsn.com Wed Aug 12 04:14: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 35A0B3A6A43; Wed, 12 Aug 2009 04:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=1.368, 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 lflUm2BIty+6; Wed, 12 Aug 2009 04:14:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 883933A6A5E; Wed, 12 Aug 2009 04:14:05 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7CAH98a017903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 12:17:09 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7CAH7tO023496; Wed, 12 Aug 2009 12:17:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 12:17:09 +0200 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, 12 Aug 2009 12:17:07 +0200 Message-ID: In-Reply-To: <20090812.090057.122296722.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] staying in synch on data model discovery Thread-Index: AcobGvUPRKKv4Q3BSv6jEChpd7T0IAAF/sKg References: <4A7EF28E.2040502@netconfcentral.com> <20090812.090057.122296722.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , X-OriginalArrivalTime: 12 Aug 2009 10:17:09.0169 (UTC) FILETIME=[0CE04A10:01CA1B36] Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] staying in synch on data model discovery 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, 12 Aug 2009 11:14:54 -0000 Hi Andy, Martin, I think we should bring the discussion related to NETCONF Monitoring draft to the NETCONF maillist. Since we believed the monitoring draft was nearly final I would appreciate if you guys post clear requests possibly with a text proposal.=20 I think this will help the authors of the monitoring draft and the NETCONF WG a lot. One other question though as a contributor: NETCONF WG developed "capabilities" and introduced several of them. Is it your proposal they shouldn't be used? I am wondering whether we need a WG decision or BCP-like statement saying it shouldn't be used. It would be interesting if you elaborate a bit why YANG features should be used instead of NETCONF capabilities. (I know some of the reasons but might be missing others. At the end we need a record on the maillist if we want to push such a decision.) Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Martin Bjorklund > Sent: Wednesday, August 12, 2009 9:01 AM > To: andy@netconfcentral.com > Cc: netmod@ietf.org > Subject: Re: [netmod] staying in synch on data model discovery >=20 > Hi Andy, >=20 > Andy Bierman wrote: > > I mostly care about the ietf-netconf-state data model to > > use the get-schema() operation with YANG. If others want > > XSD and RNG instead, then that's extra credit, but full > > support for YANG is a must-have. >=20 > I agree. >=20 > > YANG modules, submodules, and deviation modules all need > > to be listed in the and retrievable with . >=20 > Yes. That is the intention of the current design. >=20 > > However, deviations have no revision that is advertised, > > yet they clearly have a revision-date just like any other > > YANG module. This is somewhere between confusing and broken. >=20 > What makes you think that modules with deviation statements are not > advertised with their revision? >=20 > > The field in the operation is mandatory. > > It should be optional, and if missing, then the > > agent will pick whatever revision it wants (usually > > there will just be 1 to pick from). > >=20 > > The field in the operation is mandatory. > > It should be optional, and the default should be 'YANG'. >=20 > I agree that these two parameters should be made optional, but I think > that an error should be returned if there are multiple revisions > and/or formats. In most cases there will be just one revision and one > format so that's the one that will be returned. >=20 > > IMO, the use of capabilities instead of YANG features needs > > to stop. >=20 > Agreed. For the current drafts, I think this applies to partial-lock > which we don't want to change at this point, and with-defaults which I > believe Juergen commented on in some other thread. I think the > monitoring draft is fine. >=20 > > I think the node should have another leaf: > >=20 > > leaf moduleType { > > description > > "The type of data model file for this schema entry."; > > type enumeration { > > enum module { > > description > > "Indicates this entry is for a main module."; > > } > > enum submodule { > > description > > "Indicates this entry is for a sub-module."; > > } > > enum deviation { > > description > > "Indicates this entry is for a deviation module."; > > } > > enum other { > > description > > "Indicates this entry is for some other type of=20 > module."; > > } > > } > > } >=20 > I don't think this is necessary, and in any case, there is no such > thing as a 'deviation' module. In theory, any module / submodule can > have deviation statements. >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From j.schoenwaelder@jacobs-university.de Wed Aug 12 04:35: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 CC41B3A69FF; Wed, 12 Aug 2009 04:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Hy6KV2--q7gi; Wed, 12 Aug 2009 04:35: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 9B1A63A69E4; Wed, 12 Aug 2009 04:35:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 403C4C0053; Wed, 12 Aug 2009 13:32:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7TlCQ8iD9lml; Wed, 12 Aug 2009 13:32:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9291CC0051; Wed, 12 Aug 2009 13:32:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7D7A5C64BA5; Wed, 12 Aug 2009 13:32:52 +0200 (CEST) Date: Wed, 12 Aug 2009 13:32:52 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20090812113252.GA12121@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , "andy@netconfcentral.com" , "netconf@ietf.org" , "netmod@ietf.org" References: <4A7EF28E.2040502@netconfcentral.com> <20090812.090057.122296722.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] staying in synch on data model discovery 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, 12 Aug 2009 11:35:31 -0000 On Wed, Aug 12, 2009 at 12:17:07PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > NETCONF WG developed "capabilities" and introduced several of them. > Is it your proposal they shouldn't be used? I am wondering whether > we need a WG decision or BCP-like statement saying it shouldn't be > used. It would be interesting if you elaborate a bit why YANG > features should be used instead of NETCONF capabilities. (I know > some of the reasons but might be missing others. At the end we need > a record on the maillist if we want to push such a decision.) I believe we did not communicate this well... NETCONF provides a capability exchange mechanism which uses URIs to identify capabilities. The NETCONF protocol defines some core capability URIs but otherwise leaves the format of capability URIs pretty much open. YANG uses the NETCONF capability exchange and imposes a format on the URIs to communicate among other things data model defined features. The common format of the URIs allows to write generic code to analyse these URIs. So everything is actually pretty fine in the sense that NETCONF provides a mechanism and YANG uses and further restricts the mechanism in order to enhance interoperability. All we want to achieve is to do away with handcrafted URI formats (often miscommunicated as "avoid capabilities") and instead use the YANG feature mechanisms. The existing NETCONF URIs of course won't be changed - but for new URIs, we like to use the YANG format. Does this help? /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 Aug 12 06:19: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 AF2DE3A6B7F for ; Wed, 12 Aug 2009 06:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_33=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 yY3R4+QuS7Q7 for ; Wed, 12 Aug 2009 06:19:47 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id EC7C73A6909 for ; Wed, 12 Aug 2009 06:19:37 -0700 (PDT) Received: (qmail 73703 invoked from network); 12 Aug 2009 13:17:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 12 Aug 2009 13:17:18 -0000 X-YMail-OSG: LSOFF7EVM1nKZ.eSaSGNRxDo91V.mtvVqNq_I_byAjOqG3JOzNtCvgM7ZELM9_CGsvCCCA2zPkY4XfOkkuRNAD7eEG77q0pL0tIhWrKvUzMHTMG5QEr2mMu_o0244K6l3DkxYkVzi37qqBrLcMRPKt83EoeqikUtJXkgEJwy6h3ipR12M193ui0g5esAPLRVhKAjTDQXtLOVNZ7VCiBkE4e.W4OONsfahvxF3gAJUi1vgDPd5HFkPLNxMvWWdjc58M75TbzyX.1ZRfr7qzOXNfkL9CE9KhFS9pWkL3TXIZrDz3MdAxEOQKVouI3T2XyEpemz4YBXe9CP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A82C0B9.2070100@netconfcentral.com> Date: Wed, 12 Aug 2009 06:16:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A7EF28E.2040502@netconfcentral.com> <20090812.090057.122296722.mbj@tail-f.com> <4A827E79.7040306@netconfcentral.com> <20090812.105241.134338006.mbj@tail-f.com> In-Reply-To: <20090812.105241.134338006.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] staying in synch on data model discovery 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, 12 Aug 2009 13:19:47 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>>> However, deviations have no revision that is advertised, >>>> yet they clearly have a revision-date just like any other >>>> YANG module. This is somewhere between confusing and broken. >>> What makes you think that modules with deviation statements are not >>> advertised with their revision? >> The module capability does not include a revision date >> for the deviations that are attached to a particular module. > > But you advertise your deviations module, and include the revision > there: > > urn:foo?module=foo&revision=2009-01-01?deviations=bar > urn:bar?module=bar&revision=2009-04-01 > but remember the thread on all this little fields? You and Phil claimed we need them all so you do not have to look at more than the "capability I care about". Now when there is a real need to have the info at once (so can be called), it is OK to fish through all the module capabilities to find out. > So even if the bar module exists in multiple revisions (this would > happen if bar contains deviations AND reusable typedefs / groupings, > and some other modules import bar by different revision...), only one > is implemented by the device. We do not support that you advertise > multiple versions of a module with data nodes and / or deviations. > There is no requirement in the YANG spec that 2 different versions of the same module cannot be present. Import-by-revision requires the opposite -- the agent must be able to support multiple versions of the same module (A imports B and C1, B imports C2). To make matters even worse, revisions are a completely optional concept in YANG, and a vendor may decide to never use them. Then the mandatory 'version' parameter is really strange in this case. > > /martin > Andy From mbj@tail-f.com Wed Aug 12 06:43:22 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 71A783A69CA for ; Wed, 12 Aug 2009 06:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=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 qmumbqGMtdKr for ; Wed, 12 Aug 2009 06:43: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 787243A6A4E for ; Wed, 12 Aug 2009 06:43:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2140876C4D1; Wed, 12 Aug 2009 15:42:31 +0200 (CEST) Date: Wed, 12 Aug 2009 15:42:30 +0200 (CEST) Message-Id: <20090812.154230.214340685.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A82C0B9.2070100@netconfcentral.com> References: <4A827E79.7040306@netconfcentral.com> <20090812.105241.134338006.mbj@tail-f.com> <4A82C0B9.2070100@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] staying in synch on data model discovery 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, 12 Aug 2009 13:43:22 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >>>> However, deviations have no revision that is advertised, > >>>> yet they clearly have a revision-date just like any other > >>>> YANG module. This is somewhere between confusing and broken. > >>> What makes you think that modules with deviation statements are not > >>> advertised with their revision? > >> The module capability does not include a revision date > >> for the deviations that are attached to a particular module. > > > > But you advertise your deviations module, and include the revision > > there: > > > > urn:foo?module=foo&revision=2009-01-01?deviations=bar > > urn:bar?module=bar&revision=2009-04-01 > > > > but remember the thread on all this little fields? > You and Phil claimed we need them all so you do > not have to look at more than the "capability I care about". > > Now when there is a real need to have the info at > once (so can be called), it is OK to fish through > all the module capabilities to find out. I assume you refer to this: http://www.ietf.org/mail-archive/web/netmod/current/msg01764.html and your mail before it. The point was that the client can look at the capability list only - it does not have to download and parse all modules in order to find how a device deviates (or not). > To make matters even worse, revisions are a completely optional > concept in YANG, and a vendor may decide to never use them. > Then the mandatory 'version' parameter is really strange in this case. Well, I already agreed to your idea that 'version' and 'format' should be optional. /martin From andy@netconfcentral.com Wed Aug 12 07:08: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 4ABAE3A6A19 for ; Wed, 12 Aug 2009 07:08:00 -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.341, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=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 z8OHQK+qNRTv for ; Wed, 12 Aug 2009 07:07:59 -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 636DA3A683F for ; Wed, 12 Aug 2009 07:07:59 -0700 (PDT) Received: (qmail 9011 invoked from network); 12 Aug 2009 14:06:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2009 14:06:18 -0000 X-YMail-OSG: L_f626cVM1lhj8y3PRwqLRc3LSNVRJFPJ2OIzgso5DUTh.qnP5eX.K1u73YXsG7tNHO4eCsO_FUY_tD3W0rKsVEx4UhVRKUvp1Vc0cWxxtUsZlQfeLYbTEau2PffRNO6GQcGgdztcORfIc23YlnE9p3FqDm3QYZOYKEfuudyQBwUhkedOyqLxSD7eHg3YaJyq8G4iSeDiiTsK70Tu8_vbgBFOIyW654mKU0hedgudvkYCQ6nQxwyVYEcKpAL7AWVI3HbNaphDt0cCK9WbnQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A82CC3B.4060809@netconfcentral.com> Date: Wed, 12 Aug 2009 07:05:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A827E79.7040306@netconfcentral.com> <20090812.105241.134338006.mbj@tail-f.com> <4A82C0B9.2070100@netconfcentral.com> <20090812.154230.214340685.mbj@tail-f.com> In-Reply-To: <20090812.154230.214340685.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] staying in synch on data model discovery 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, 12 Aug 2009 14:08:00 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>>>> However, deviations have no revision that is advertised, >>>>>> yet they clearly have a revision-date just like any other >>>>>> YANG module. This is somewhere between confusing and broken. >>>>> What makes you think that modules with deviation statements are not >>>>> advertised with their revision? >>>> The module capability does not include a revision date >>>> for the deviations that are attached to a particular module. >>> But you advertise your deviations module, and include the revision >>> there: >>> >>> urn:foo?module=foo&revision=2009-01-01?deviations=bar >>> urn:bar?module=bar&revision=2009-04-01 >>> >> but remember the thread on all this little fields? >> You and Phil claimed we need them all so you do >> not have to look at more than the "capability I care about". >> >> Now when there is a real need to have the info at >> once (so can be called), it is OK to fish through >> all the module capabilities to find out. > > I assume you refer to this: > http://www.ietf.org/mail-archive/web/netmod/current/msg01764.html > and your mail before it. > > The point was that the client can look at the capability list only - > it does not have to download and parse all modules in order to find > how a device deviates (or not). > OK -- I don't want to re-open the module capability URI. The normal use-cases are covered very well. >> To make matters even worse, revisions are a completely optional >> concept in YANG, and a vendor may decide to never use them. >> Then the mandatory 'version' parameter is really strange in this case. > > Well, I already agreed to your idea that 'version' and 'format' should > be optional. > I think this will make get-schema easier to use. I implemented all of draft-07, and I allow an empty string for version to mean "agent picks the version, if there is one. If not, then I'm already asking for the correct version -- none". In YANG terms, just leaving out the parameter would be cleaner. > > /martin > > Andy From andy@netconfcentral.com Wed Aug 12 08:23: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 DA3593A6B56 for ; Wed, 12 Aug 2009 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 3cH4zkoCtsiu for ; Wed, 12 Aug 2009 08:23:13 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 17CF93A6A6C for ; Wed, 12 Aug 2009 08:23:12 -0700 (PDT) Received: (qmail 94414 invoked from network); 12 Aug 2009 15:13:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 12 Aug 2009 15:13:49 -0000 X-YMail-OSG: 3UwtlD0VM1kV5gv2XIofcJ1rqaM8cQugvlSwyvxH7iWr3oko2i_rsvB4dySQG6XCC8xn18_jkKeOYTW6NTeJpikVmLsKdqpKLTWFHnIod3USsT1odCMww.W8CzWM7FlZykSs6uGFTo3wOcUCfjgTX1Fpxt8w8AmG6kbbw5Ce_dy6kwlhnSgKer4CzdmOqJcSSz.3ehtaxamfQp8HEwC1MHth8pRmB.mjYrLg.umx9aI9UnYtc4S5.WhODT3jP6wG1eWJ1Gbmip8Q6Rc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A82DC87.6000302@netconfcentral.com> Date: Wed, 12 Aug 2009 08:15:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] CLR request 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, 12 Aug 2009 15:23:13 -0000 Hi, I have some early implementation experience that suggests that 2 specific corner-cases are very hard to implement correctly in the agent protocol stack: 1) leafref chains (leafref points to leafref points to ...) 2) leafrefs that point to instance-identifiers I suspect that nobody will want to remove these features, even though there are no use cases that matter to our problem space to back them up. This is kind of like retrieving the main module while parsing a submodule, just to get the prefix. This was eventually fixed in the belongs-to-stmt. I hope I don't hear any whining a year from now how difficult this bit is to code, as if the issue was never raised before. If we are going to end up with these CLRs to get people to implement YANG, then let's add them now, or decide now that this is not a concern to the WG, or any unreasonable implementation burden. Andy From andy@netconfcentral.com Wed Aug 12 08:51:21 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 B778A3A6B28 for ; Wed, 12 Aug 2009 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 Evi3ery0AWKV for ; Wed, 12 Aug 2009 08:51:21 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id E6A463A6803 for ; Wed, 12 Aug 2009 08:51:20 -0700 (PDT) Received: (qmail 33121 invoked from network); 12 Aug 2009 15:49:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 12 Aug 2009 15:49:40 -0000 X-YMail-OSG: zvtJorEVM1kgO6eVhr1TRTRGXKG.E1v.E1C.Nj5QOh94Z0_Oeu.ZZzyGIWbedwURmkC9mVma0Sh9l8EF3y9dkUF82z_L.AvANc0806aWee4Z7Nlg7PMMt2.GPJNxwi3cV67PHOCdn1MAp0K3T_votNnuLtR4CbJ0WNok3ixVv4rU9khFDs6_XJ4vve6SL0KKmLJd3uG0bEueu6G7mdIIVpzNYHxNfcXcR1y1LhDxfRmOvThDMZuHmIc_CFTe92vIHzTy34JfTi7Kj_8T6NkNtVnd682o.QuhqUqbkupCum44.10wOjk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A82E4EE.9050700@netconfcentral.com> Date: Wed, 12 Aug 2009 08:51:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] leafref corner case 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, 12 Aug 2009 15:51:21 -0000 Hi, I'm sure glad we think it is so important to have leafrefs in the database, because they are really a pain to implement as database objects. Here are 2 more corner-cases: list top { key a; leaf a { type int8; } leaf foo { type string; } } container copy { presence "Cannot use a top-level mandatory container"; leaf fooref { type leafref { path /top/foo; } mandatory true; } } ... deviation /top/foo { deviate not-supported; } 1) mandatory pointing at optional this is legal YANG, but it doesn't really work 2) defunct leafref due to deviations Deviations are patches. In this agent, there is no leaf /top/foo. So what happens to leaf /copy/fooref? Andy From mehmet.ersue@nsn.com Wed Aug 12 10:34: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 35F0D3A6B56; Wed, 12 Aug 2009 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=-0.689, 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 rbYSLY9n2vs2; Wed, 12 Aug 2009 10:34:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 183853A6826; Wed, 12 Aug 2009 10:33:55 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7CH0o0W015356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 19:00:50 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7CH0oXF007945; Wed, 12 Aug 2009 19:00:50 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 19:00:50 +0200 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, 12 Aug 2009 19:00:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] staying in synch on data model discovery Thread-Index: AcobQKfrCo99F2pmQ+iCKvMBauxS3AACyEEAAAidEDA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 12 Aug 2009 17:00:50.0628 (UTC) FILETIME=[71FDA040:01CA1B6E] Cc: netconf@ietf.org, netmod@ietf.org Subject: [netmod] FW: staying in synch on data model discovery 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, 12 Aug 2009 17:34:24 -0000 From: ext Juergen Schoenwaelder Wednesday, August 12, 2009 1:33 PM >=20 > On Wed, Aug 12, 2009 at 12:17:07PM +0200, Ersue, Mehmet (NSN=20 > - DE/Munich) wrote: > =20 > > NETCONF WG developed "capabilities" and introduced several of them. > > Is it your proposal they shouldn't be used? I am wondering whether > > we need a WG decision or BCP-like statement saying it shouldn't be > > used. It would be interesting if you elaborate a bit why YANG > > features should be used instead of NETCONF capabilities. (I know > > some of the reasons but might be missing others. At the end we need > > a record on the maillist if we want to push such a decision.) >=20 > I believe we did not communicate this well... >=20 > NETCONF provides a capability exchange mechanism which uses URIs to > identify capabilities. The NETCONF protocol defines some core > capability URIs but otherwise leaves the format of capability URIs > pretty much open. YANG uses the NETCONF capability exchange and > imposes a format on the URIs to communicate among other things data > model defined features. The common format of the URIs allows to write > generic code to analyse these URIs. So everything is actually pretty > fine in the sense that NETCONF provides a mechanism and YANG uses and > further restricts the mechanism in order to enhance interoperability. >=20 > All we want to achieve is to do away with handcrafted URI formats > (often miscommunicated as "avoid capabilities") and instead use the > YANG feature mechanisms. The existing NETCONF URIs of course won't be > changed - but for new URIs, we like to use the YANG format. Using NETCONF URIs in a specific way is fine from NETCONF POV. I support what has been proposed in Ch. 4.4. Conditional Statements=20 of the "YANG Usage guidelines" document. Mehmet =20 From randy_presuhn@mindspring.com Wed Aug 12 11:05:21 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 C153B3A6B62 for ; Wed, 12 Aug 2009 11:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] 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 wEyXmCUNPTsz for ; Wed, 12 Aug 2009 11:05:20 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id DFF483A6BD7 for ; Wed, 12 Aug 2009 11:05:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LlTpZhWAlMUOQrdCX2E2s0h8VMlx25FMDkMGonmvUbtq8j2oIEenfypNGGF360jy; 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.41.49.220] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MbHp2-0000me-3A for netmod@ietf.org; Wed, 12 Aug 2009 13:41:12 -0400 Message-ID: <002b01ca1b74$6e5b1660$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4A7EF28E.2040502@netconfcentral.com><20090812.090057.122296722.mbj@tail-f.com><4A827E79.7040306@netconfcentral.com> <20090812.105241.134338006.mbj@tail-f.com> Date: Wed, 12 Aug 2009 10:43:39 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9465cc8860015db7fdc8e0ae6be31778a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.220 Subject: Re: [netmod] staying in synch on data model discovery 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, 12 Aug 2009 18:05:21 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Wednesday, August 12, 2009 1:52 AM > Subject: Re: [netmod] staying in synch on data model discovery ... > So even if the bar module exists in multiple revisions (this would > happen if bar contains deviations AND reusable typedefs / groupings, > and some other modules import bar by different revision...), only one > is implemented by the device. We do not support that you advertise > multiple versions of a module with data nodes and / or deviations. ... Is this really realistic in a world of FRUs? I can see how one might shoehorn the models for different versions of a FRU into one, but the deviations (which might be different for, e.g., different line cards) seem less likely to work this way. Randy From cfinss@dial.pipex.com Wed Aug 12 14:02: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 DF4C03A67B2 for ; Wed, 12 Aug 2009 14:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_36=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 9qjjYLFvVYNz for ; Wed, 12 Aug 2009 14:02:14 -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 720413A690D for ; Wed, 12 Aug 2009 14:02:14 -0700 (PDT) X-Trace: 187054554/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.85/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.85 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: AsgEALHKgko+vGRV/2dsb2JhbACDMEEgjGrDBgmCKoFmBYFMWw X-IronPort-AV: E=Sophos;i="4.43,370,1246834800"; d="scan'208";a="187054554" X-IP-Direction: IN Received: from 1cust85.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.85]) by smtp.pipex.tiscali.co.uk with SMTP; 12 Aug 2009 22:01:42 +0100 Message-ID: <000901ca1b87$96d421a0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A813E46.9000601@netconfcentral.com><20090811.121331.71537449.mbj@tail-f.com><4A815E22.8060801@netconfcentral.com> <20090811.143301.217566638.mbj@tail-f.com> Date: Wed, 12 Aug 2009 21:59:10 +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] prefixes in groupings example 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, 12 Aug 2009 21:02:15 -0000 Martin Top posting as this is a related tangent. When I struggle to understand yang, I think it is sometimes the choice of words I struggle with. Perhaps this I-D fails my boring test. Technical writing should bore me; the same concepts should be bound one-to-one to identifiers and so the same identifiers should recur over and over again. Boring:-( but clear:-) eg, look at the passage you have quoted to Andy: > Grouping, type, and identity names are resolved in the context in > which they are defined, rather than the context in which they are > used. Users of groupings, typedefs, and identities are not required > to import modules or include submodules to satisfy all references > made by the original definition. coupled with o All derived type names defined within a parent node or at the top- level of the module or its submodules share the same type identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that typedef, and it MUST NOT define a typedef with the same name. I think that one concept, the typedef name ie the identifier which is the "typedef" statement's argument, gets referred to as, successively, type ..names typedefs derived type names type identifier typedef Life would be more boring, and so for me simpler, if all references were to typedef names (or derived type names, although I would find that prolix). When I see four identifiers for what seems to be the same concept, I get this nagging doubt - what am I missing? (please spare me the excitement:-) Tom Petch ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, August 11, 2009 2:33 PM Subject: Re: [netmod] prefixes in groupings example > Andy Bierman wrote: > > Martin Bjorklund wrote: > > > Andy Bierman wrote: > > >> I'm still trying to figure out how the type-name prefix > > >> thing works. > > >> > > >> If I have a local type like in my example: > > >> > > >> module foo { > > >> grouping ggg { > > >> container top-level { > > >> typedef MyType { ... } > > >> leaf X { type MyType; } > > >> } > > >> } > > >> } > > >> > > >> > > >> According to your rule, leaf X will have type foo:MyType. > > >> It is bound to the 'foo' namespace because it is a type, > > >> not an XPath expression. > > > > > > Yes. > > > > > >> module goo { > > >> > > >> import foo { prefix foo; } > > >> uses foo:ggg; > > >> } > > >> > > >> Now, even though there is a typedef called MyType in > > >> module goo, it is goo:MyType, and not a match. > > >> The YANG compiler is forced to call this an error, > > >> even though the intent was to use the MyType in the > > >> grouping, not the one tied to the foo namespace. > > > > > > No, with the module foo above, this is not an error. Why would it be > > > an error? leaf X in the grouping has a type, and it is the same type > > > in all modules where 'ggg' is used. This works as before. > > > > > > > > > > it works because we do a late binding on the type name prefix, > > not an early binding as your rule specifies. > > This is getting confusing. Can we agree that there is no late binding > for types in the current draft 07? From section 5.4: > > Grouping, type, and identity names are resolved in the context in > which they are defined, rather than the context in which they are > used. Users of groupings, typedefs, and identities are not required > to import modules or include submodules to satisfy all references > made by the original definition. This behaves like static scoping in > a conventional programming language. > > Our proposal is to introduce "late binding" for references in XPath > expressions. The current rule for type identifiers are the same as > before. > > > I think the rule you are proposing is in the right direction, > > but I do not agree that this problem is specific to XPath or > > XML prefixes. > > Ok, so it seems we agree so far, but in addition to what we propose, > you also want to change the current rule for type/grouping/... to also > use late binding. > > > It seems to me that all explicit prefixes are > > early binding and all missing prefixes are late-binding. > > This works whether the definition is in a grouping or not > > (same module: early vs. late produces the same result). > > I prefer to keep the type/grouping rule the way it is, and not do late > binding in this case. Consider this case: > > module foo { > > typedef my-type { type int32; } > > grouping foo { > leaf x { type my-type; } > } > } > > module goo { > > import foo { prefix foo; } > > typedef my-type { type string; } > > uses foo:foo; > } > > Now, with your rule, goo:x is of type string. I think this is > confusing. > > > /martin From root@core3.amsl.com Wed Aug 12 14:30:01 2009 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ED6A028C153; Wed, 12 Aug 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090812213001.ED6A028C153@core3.amsl.com> Date: Wed, 12 Aug 2009 14:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-01.txt 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, 12 Aug 2009 21:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-01.txt Pages : 28 Date : 2009-08-12 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-12142440.I-D@ietf.org> --NextPart-- From andy@netconfcentral.com Wed Aug 12 20:29: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 C37CB3A67DF for ; Wed, 12 Aug 2009 20:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 L-x-N66aRKMb for ; Wed, 12 Aug 2009 20:29:57 -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 E0AD83A6B2E for ; Wed, 12 Aug 2009 20:29:56 -0700 (PDT) Received: (qmail 362 invoked from network); 13 Aug 2009 03:29:36 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 13 Aug 2009 03:29:36 -0000 X-YMail-OSG: OxHn40YVM1nSatXEssBJCB4ykaeoWeLcrP1LQOuYr15z_4TL2IDe0SrO82eTs054pBLLUBNJHR8_7skdgJwVoLz9GuTSd2_TUV6dkla8mTSWHjQtIl0L06JP27c_bB79R0xneWETlDY1sGX8yu0A_.ypMvYYojNwyFhdLUANPNh9d5yk4OHrS5VVhOi.CPu1NXdP5BzqH0zxcm.GUMIiiz3HavsWLG4Pf9kBXSVe0ukjicA9lVrd_HnomvyZ9JPDGt1fNQd3Elhfs1SLtrjqBDE6u9mmWrya7psQayiYERBLE_.XtA0_9vKCbfzD6z_IdkuMSQqxoDyz90.ZQ.Y- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8388FD.7000802@netconfcentral.com> Date: Wed, 12 Aug 2009 20:31:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/mixed; boundary="------------090400060501040203030909" Subject: [netmod] [Fwd: I-D Action:draft-ietf-netmod-yang-usage-01.txt] 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: Thu, 13 Aug 2009 03:29:57 -0000 This is a multi-part message in MIME format. --------------090400060501040203030909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, FYI: new YANG guidelines draft There are still some [TBD] details scattered about that need to be resolved. I will try to do that in the next month. All the mailing list issues are settled. I added ietf-template.yang, which is just a shell that YANG authors can fill in with a data model. I figured that this is not a YANG tutorial, so the expresso-machine.yang module can wait for another draft. Please review ASAP and let me know if there are any problems, bugs, missing guidelines, etc. thanks, Andy --------------090400060501040203030909 Content-Type: message/rfc822; name="[netmod] I-D Action:draft-ietf-netmod-yang-usage-01.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[netmod] I-D Action:draft-ietf-netmod-yang-usage-01.txt.eml" X-Account-Key: account8 X-Mozilla-Keys: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.netconfcentral.com X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=RCVD_IN_DNSWL_MED autolearn=failed version=3.2.5 Delivered-To: andy@netconfcentral.com Return-Path: Received: from mail.ietf.org (mail.ietf.org [::ffff:64.170.98.32]) by www.netconfcentral.org with esmtp; Wed, 12 Aug 2009 14:35:00 -0700 id 0017058E.4A833584.00007470 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4972428C153; Wed, 12 Aug 2009 14:30:03 -0700 (PDT) X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ED6A028C153; Wed, 12 Aug 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_www.netconfcentral.com-29808-1250112900-0001-2" Message-Id: <20090812213001.ED6A028C153@core3.amsl.com> Date: Wed, 12 Aug 2009 14:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-01.txt 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: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_www.netconfcentral.com-29808-1250112900-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-01.txt Pages : 28 Date : 2009-08-12 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=_www.netconfcentral.com-29808-1250112900-0001-2 Content-Type: message/external-body; name="draft-ietf-netmod-yang-usage-01.txt"; site="ftp.ietf.org"; access-type=anon-ftp; directory=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2009-08-12142440.I-D@ietf.org> --=_www.netconfcentral.com-29808-1250112900-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --=_www.netconfcentral.com-29808-1250112900-0001-2-- --------------090400060501040203030909-- From j.schoenwaelder@jacobs-university.de Wed Aug 12 23: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 2CA7E3A69C0 for ; Wed, 12 Aug 2009 23:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 LJJ8nrIClj8z for ; Wed, 12 Aug 2009 23:34:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B60053A685E for ; Wed, 12 Aug 2009 23:34:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17AA6C0072; Thu, 13 Aug 2009 08:12:22 +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 hy9giMd5xS+Y; Thu, 13 Aug 2009 08:12:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33196C000F; Thu, 13 Aug 2009 08:12:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9CD0AC65AF8; Thu, 13 Aug 2009 08:12:19 +0200 (CEST) Date: Thu, 13 Aug 2009 08:12:19 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090813061219.GA13155@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4A8388FD.7000802@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8388FD.7000802@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] [Fwd: I-D Action:draft-ietf-netmod-yang-usage-01.txt] 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: Thu, 13 Aug 2009 06:34:36 -0000 On Thu, Aug 13, 2009 at 05:31:09AM +0200, Andy Bierman wrote: > Please review ASAP and let me know if there are any problems, > bugs, missing guidelines, etc. If we use a reference statement to identify the RFC, should this statement then not be part of the revision statement, that is: revision 2009-08-12 { description "Initial revision"; reference "RFC XXXX"; } Right now, you have the reference statement where all the meta data is and it seems YANG does not even allow to place the reference statement like I propose here. But common usage has been to refer to the RFC in the revision statement equivalent in the SMIv2 world. I am not sure I really see the value of requiring the file name for unpublished documents in the comments. The more places an author has to maintain with each revision, the more errors can be made. We already have the DRAFT-XX in the URN and in the SMIv2 world, we managed to survive without such a comment. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Aug 12 23:54: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 7F1F53A693B for ; Wed, 12 Aug 2009 23:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 YyQ9HVQAvyCA for ; Wed, 12 Aug 2009 23:54:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9C6963A68C6 for ; Wed, 12 Aug 2009 23:54:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CA49C007E for ; Thu, 13 Aug 2009 08:53:00 +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 KVEjPMLUxEaK; Thu, 13 Aug 2009 08:52:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 810E3C0072; Thu, 13 Aug 2009 08:52:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 25CBFC65CD5; Thu, 13 Aug 2009 08:52:58 +0200 (CEST) Date: Thu, 13 Aug 2009 08:52:58 +0200 From: Juergen Schoenwaelder To: NETMOD Working Group Message-ID: <20090813065258.GA13523@elstar.local> Mail-Followup-To: NETMOD Working Group References: <4A8388FD.7000802@netconfcentral.com> <20090813061219.GA13155@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090813061219.GA13155@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [netmod] [Fwd: I-D Action:draft-ietf-netmod-yang-usage-01.txt] 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: Thu, 13 Aug 2009 06:54:51 -0000 On Thu, Aug 13, 2009 at 08:12:19AM +0200, Juergen Schoenwaelder wrote: > On Thu, Aug 13, 2009 at 05:31:09AM +0200, Andy Bierman wrote: > > > Please review ASAP and let me know if there are any problems, > > bugs, missing guidelines, etc. > > If we use a reference statement to identify the RFC, should this > statement then not be part of the revision statement, that is: > > revision 2009-08-12 { > description "Initial revision"; > reference "RFC XXXX"; > } > > Right now, you have the reference statement where all the meta data is > and it seems YANG does not even allow to place the reference statement > like I propose here. But common usage has been to refer to the RFC in > the revision statement equivalent in the SMIv2 world. The example should actually be: revision 2009-08-13 { description "Initial revision."; reference "RFC XXXX: Common YANG Data Types"; } // RFC Ed.: replace XXXX with actual RFC number and remove this note I added the title of the RFC (as I normally do) since not everybody memorizes all the RFC numbers. Martin, can we change YANG to allow this? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 13 00:01: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 A4F313A68FD for ; Thu, 13 Aug 2009 00:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.142, 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 JkZf7Wnmo-rz for ; Thu, 13 Aug 2009 00:01: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 4325E3A6811 for ; Thu, 13 Aug 2009 00:01:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5225676C540; Thu, 13 Aug 2009 08:59:07 +0200 (CEST) Date: Thu, 13 Aug 2009 08:59:07 +0200 (CEST) Message-Id: <20090813.085907.46272376.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090813065258.GA13523@elstar.local> References: <4A8388FD.7000802@netconfcentral.com> <20090813061219.GA13155@elstar.local> <20090813065258.GA13523@elstar.local> 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] [Fwd: I-D Action:draft-ietf-netmod-yang-usage-01.txt] 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: Thu, 13 Aug 2009 07:01:28 -0000 Juergen Schoenwaelder wrote: > > Right now, you have the reference statement where all the meta data is > > and it seems YANG does not even allow to place the reference statement > > like I propose here. But common usage has been to refer to the RFC in > > the revision statement equivalent in the SMIv2 world. > > The example should actually be: > > revision 2009-08-13 { > description > "Initial revision."; > reference > "RFC XXXX: Common YANG Data Types"; > } > // RFC Ed.: replace XXXX with actual RFC number and remove this note > > I added the title of the RFC (as I normally do) since not everybody > memorizes all the RFC numbers. Martin, can we change YANG to allow > this? Yes I think we should. In fact, we can view this as a bug - in all other places where a 'description' statement is allowed, 'reference' is also allowed. /martin From andy@netconfcentral.com Thu Aug 13 02:56: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 502DA3A6912 for ; Thu, 13 Aug 2009 02:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 2IIUIvZ+ns0W for ; Thu, 13 Aug 2009 02:56:04 -0700 (PDT) Received: from n24.bullet.mail.mud.yahoo.com (n24.bullet.mail.mud.yahoo.com [68.142.206.163]) by core3.amsl.com (Postfix) with SMTP id 6FE5F3A67AC for ; Thu, 13 Aug 2009 02:56:04 -0700 (PDT) Received: from [209.191.108.96] by n24.bullet.mail.mud.yahoo.com with NNFMP; 13 Aug 2009 09:46:13 -0000 Received: from [68.142.201.254] by t3.bullet.mud.yahoo.com with NNFMP; 13 Aug 2009 09:46:13 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 13 Aug 2009 09:46:13 -0000 X-Yahoo-Newman-Id: 662066.66704.bm@omp415.mail.mud.yahoo.com Received: (qmail 1485 invoked from network); 13 Aug 2009 09:46:13 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2009 09:46:12 -0000 X-YMail-OSG: .l2tfUgVM1n1WApC6VruAOSDYl0gLItfKd59tYRCOLCzY16hRqC3mXkbLVhRUVHpYfjCqBMII7G002XZAn1datvCwId1zXyzlenk7L1FuaFiuWHTfDQHQ7OqcltG2Urv1nhno7v0u108aspkTuniosfOsdPEysdokfqrmjEkKyqvwxCGYBrzxx5Cvt6PPgJuy9s1CUr4E.c4zcMRLvxj.6Rn5zXIRmB6S5dxLhUEgpiebORTW9V3HLbGXJy0GJvAjWuTkevhN4fa5ESqRI4kfpoC1eT8uvBaVuVoZmpckjpbxcuqm4LAytGIpoTEnfk5NO1SqWM6YWebKHnruuaTtqjdSAIxxA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A83E143.4000209@netconfcentral.com> Date: Thu, 13 Aug 2009 02:47:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8388FD.7000802@netconfcentral.com> <20090813061219.GA13155@elstar.local> <20090813065258.GA13523@elstar.local> <20090813.085907.46272376.mbj@tail-f.com> In-Reply-To: <20090813.085907.46272376.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] [Fwd: I-D Action:draft-ietf-netmod-yang-usage-01.txt] 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: Thu, 13 Aug 2009 09:56:05 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >>> Right now, you have the reference statement where all the meta data is >>> and it seems YANG does not even allow to place the reference statement >>> like I propose here. But common usage has been to refer to the RFC in >>> the revision statement equivalent in the SMIv2 world. >> The example should actually be: >> >> revision 2009-08-13 { >> description >> "Initial revision."; >> reference >> "RFC XXXX: Common YANG Data Types"; >> } >> // RFC Ed.: replace XXXX with actual RFC number and remove this note >> >> I added the title of the RFC (as I normally do) since not everybody >> memorizes all the RFC numbers. Martin, can we change YANG to allow >> this? > > Yes I think we should. In fact, we can view this as a bug - in all > other places where a 'description' statement is allowed, 'reference' > is also allowed. > I disagree. It is not a bug -- it is feature-creep. We can use a comment for this purpose. > > /martin Andy From j.schoenwaelder@jacobs-university.de Thu Aug 13 03:06:14 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 B221E3A6912 for ; Thu, 13 Aug 2009 03:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 XmRs0lboY0jV for ; Thu, 13 Aug 2009 03:06:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 68A473A68EC for ; Thu, 13 Aug 2009 03:06:13 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C288C007C; Thu, 13 Aug 2009 12:03:37 +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 fNzWo-N1p5jM; Thu, 13 Aug 2009 12:03:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 401FDC007A; Thu, 13 Aug 2009 12:03:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5FFAAC66511; Thu, 13 Aug 2009 12:03:35 +0200 (CEST) Date: Thu, 13 Aug 2009 12:03:35 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090813100335.GD14045@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4A8388FD.7000802@netconfcentral.com> <20090813061219.GA13155@elstar.local> <20090813065258.GA13523@elstar.local> <20090813.085907.46272376.mbj@tail-f.com> <4A83E143.4000209@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A83E143.4000209@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] [Fwd: I-D Action:draft-ietf-netmod-yang-usage-01.txt] 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: Thu, 13 Aug 2009 10:06:14 -0000 On Thu, Aug 13, 2009 at 11:47:47AM +0200, Andy Bierman wrote: > Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >>> Right now, you have the reference statement where all the meta data is > >>> and it seems YANG does not even allow to place the reference statement > >>> like I propose here. But common usage has been to refer to the RFC in > >>> the revision statement equivalent in the SMIv2 world. > >> The example should actually be: > >> > >> revision 2009-08-13 { > >> description > >> "Initial revision."; > >> reference > >> "RFC XXXX: Common YANG Data Types"; > >> } > >> // RFC Ed.: replace XXXX with actual RFC number and remove this note > >> > >> I added the title of the RFC (as I normally do) since not everybody > >> memorizes all the RFC numbers. Martin, can we change YANG to allow > >> this? > > > > Yes I think we should. In fact, we can view this as a bug - in all > > other places where a 'description' statement is allowed, 'reference' > > is also allowed. > > > > I disagree. > It is not a bug -- it is feature-creep. > We can use a comment for this purpose. I like the bug fix. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 13 05:56: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 955763A6ACD for ; Thu, 13 Aug 2009 05:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Wslo9Xtb9rt3 for ; Thu, 13 Aug 2009 05:56:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 717723A6877 for ; Thu, 13 Aug 2009 05:56:52 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 752B5C0084; Thu, 13 Aug 2009 14:54:11 +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 G59gg6Ck0sAM; Thu, 13 Aug 2009 14:54:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E25AAC0083; Thu, 13 Aug 2009 14:54:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 19F74C66A8E; Thu, 13 Aug 2009 14:54:09 +0200 (CEST) Date: Thu, 13 Aug 2009 14:54:08 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090813125408.GC15042@elstar.local> Mail-Followup-To: Randy Presuhn , "netmod@ietf.org" References: <20090727120535.GA10672@elstar.local> <20090809220325.GD4430@elstar.local> <00b401ca19f6$cb50cd80$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b401ca19f6$cb50cd80$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] date-and-time canonicalization (option #3) 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: Thu, 13 Aug 2009 12:56:53 -0000 On Mon, Aug 10, 2009 at 10:11:47PM +0200, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: > > Sent: Sunday, August 09, 2009 3:03 PM > > Subject: [netmod] date-and-time canonicalization (option #3) > ... > > The canonical format for date-and-time values is the format with a > > numeric time zone offset that is calculated using the device's > > configured known offset to UTC time. A change of the device's offset > > to UTC time will cause date-and-time values to change accordingly. > > Such changes might happen periodically in case a server follows > > automatically daylight saving time (DST) time zone offset changes. > > > > This is a departure from the XSD dateTime rules (XSD requires the "Z" > > format) but this approach has the advantage that operators deploying > > NETCONF servers can configure the time zone and thus decide themselves > > whether they like all dates to be returned in UTC or in a local time > > zone. As a side effect, a server returning > > > > 2009-08-09T23:08:00+02:00 > > > > indicates that the server's time offset is +02:00 at the time when the > > response was generated. > > > > Comments? > ... > > For some use cases this would be desirable, for others not. > Sometimes a time or schedule really needs to be in terms of local > clock time. On the one side, consider intrusion detection sensors > that need to be in harmony with an office's local hours of > operation. On the other side, consider backup runs scheduled to > avoid overtaxing an enterprise's global network. The former > absolutely needs to take local daylight savings time changes into > account. The latter probably should not. > > There really is a semantic difference between "schedule according to local > clock time" and "schedule for purposes of global coordination". A model > that loses that semantic will shortchange one or the other. > > I *do* think this issue can be separated from that of > canonicalization. After all, it's really a matter of the semantics > of the bit of configuration data. If the goal is to handle both > semantics in a single data type, then this bit needs to show up in > the representation. If we decide that the difference in semantics > merits having two distinct types (which happen to look very much > alike), then there's no need for in in the representation. Following RFC 3339, you can specify unknown timezone by using: 2009-08-09T23:08:00-00:00 The only sensible interpretation of this I can come up with on the device is local time. So it is possible to make a distinction. I am tempted to actually allow the short-hand notation 2009-08-09T23:08:00 for this and to make this the canonical format (that is something configured as 2009-08-09T23:08:00-00:00 will be returned as 2009-08-09T23:08:00) since it seems to be easier to read. Further comments? /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 Thu Aug 13 11:04: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 A092A3A6A99 for ; Thu, 13 Aug 2009 11:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.179, 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 xAwFSeF+jSQv for ; Thu, 13 Aug 2009 11:04:24 -0700 (PDT) Received: from n25.bullet.mail.mud.yahoo.com (n25.bullet.mail.mud.yahoo.com [68.142.206.220]) by core3.amsl.com (Postfix) with SMTP id 1B54C28C13D for ; Thu, 13 Aug 2009 11:04:05 -0700 (PDT) Received: from [68.142.200.225] by n25.bullet.mail.mud.yahoo.com with NNFMP; 13 Aug 2009 18:04:07 -0000 Received: from [68.142.201.67] by t6.bullet.mud.yahoo.com with NNFMP; 13 Aug 2009 18:04:07 -0000 Received: from [127.0.0.1] by omp419.mail.mud.yahoo.com with NNFMP; 13 Aug 2009 18:04:07 -0000 X-Yahoo-Newman-Id: 786682.65593.bm@omp419.mail.mud.yahoo.com Received: (qmail 38512 invoked from network); 13 Aug 2009 18:04:07 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2009 18:04:07 -0000 X-YMail-OSG: ThA7AKcVM1nGw0mymXwGElYdVv8OgmArL2qc7Mkkd7ovvGVmRGmlfD.CJcpnRMTMoq._2FPz2awrLcUaBipIuVy_JP4yJ8VjUTCXpJHr1C5GXvVhr1gFowBxwOy0RF9HY_xBx2eWhDHOTDiGJjB3Cc_SlHSFUprVRCQws0cKPowElBc7bYadY1SmS6efseky4CoPjR93uFPpqBSj5M7GE9KsdorSAWra5j5KPnugdRgxkQbN9xN4ctHQRgK3ah0mC_yS8AFFopKOSUnmZnT_ksVPSsRWLPqxRGNGxNs6puvRXxBhFx0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8455F8.3070509@netconfcentral.com> Date: Thu, 13 Aug 2009 11:05:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] leafref problems 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: Thu, 13 Aug 2009 18:04:25 -0000 Hi, >From yang-07, sec. 9.9.2 The "path" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: o The context node is the node in the data tree for which the "path" statement is defined. The accessible tree depends on the context node: o If the leaf with the instance-identifier type represents configuration data, the tree is the data in one of the NETCONF datastores. The XPath root node has all top-level configuration data nodes in all modules as children. o Otherwise the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. 1) this must be a bug, because it discusses the i-i type in the section about the leafref builtin type. 2) This behavior is really complicated, especially when the leafref is nested within a union typedef. When checking a value against its typedef, you need to know the protocol operation and which target database (if any) is being referenced. Maybe the agent just picks a database at random if the target is not provided in some operation? 3) There are no compelling use-cases for including leafref objects in the database. Their use in notifications and RPC operations is different. That allows custom RPCs and any event-type to point at database objects for their transient messages 4) The issues I raised wrt mandatory/optional or just dealing with objects that point at nonexistent nodes (not-supported or if-feature=false, or when-stmt=false) make leafref almost unusable in the database. The implementation complexity issues can be dismissed as subjective, but not the rest of them. I think the leafref should not be allowed in config=true objects at all. They are not properly supported, and they are not really needed either. Leafref is way more trouble than it is worth. It hardly ever shows up in MIBs. I know of 1 MIB -- the RMON usrHistoryTable, which uses a leafref as part of its self-contained config to monitor read-only data. It isn't even very good for RPC/notification. A 'varbind' approach would be much better and much easier to use. Andy From randy_presuhn@mindspring.com Thu Aug 13 12:38:14 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 7B74D28C108 for ; Thu, 13 Aug 2009 12:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_05=-1.11, 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 w17yWiF8ZQT0 for ; Thu, 13 Aug 2009 12:38:13 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id BD1DF3A6CC0 for ; Thu, 13 Aug 2009 12:38:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Rfs+CuWwoJzXrplGgZFeoCVRD5dZ184Dq8wHEwLZd13sj4TiSVqR4RZ5KJX8D84r; 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.95.116] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mbg7o-0004WB-8S for netmod@ietf.org; Thu, 13 Aug 2009 15:38:12 -0400 Message-ID: <000801ca1c4d$f1d1d2c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <4A8455F8.3070509@netconfcentral.com> Date: Thu, 13 Aug 2009 12:40:40 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f972990d147de016fa294643d29fd60702350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.95.116 Subject: Re: [netmod] leafref problems 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: Thu, 13 Aug 2009 19:38:14 -0000 Hi - > From: "Andy Bierman" > To: "NETMOD Working Group" > Sent: Thursday, August 13, 2009 11:05 AM > Subject: [netmod] leafref problems ... > I think the leafref should not be allowed in config=true objects > at all. They are not properly supported, and they are not really > needed either. Leafref is way more trouble than it is worth. > It hardly ever shows up in MIBs. I know of 1 MIB -- the > RMON usrHistoryTable, which uses a leafref as part of its > self-contained config to monitor read-only data. Similar things abound in the disman MIB modules' configuration data. The patterns used in VACM are also *conceptually* similar, though they're really built on syntactic punning. There really are cases where it's necessary for configuration data to refer to other elements of configuration data. If leafref in its current form is problematic, a counter-proposal is in order. > It isn't even very good for RPC/notification. A 'varbind' approach > would be much better and much easier to use. I'm inclined to agree. Randy From andy@netconfcentral.com Thu Aug 13 13:02: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 7F40928C20A for ; Thu, 13 Aug 2009 13:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 I-m6xvFacxvE for ; Thu, 13 Aug 2009 13:02:30 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 8EF6A28C208 for ; Thu, 13 Aug 2009 13:02:30 -0700 (PDT) Received: (qmail 34819 invoked from network); 13 Aug 2009 20:02:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 13 Aug 2009 20:02:05 -0000 X-YMail-OSG: dRgipQcVM1kvpFCaZUS1nhOdAhpLT4K7PiyHko1lmO1Dj8k3TvyyGmMKyeITIwDMH7GVagkeFKpec3RVk.Rj_8UPRhd8V4rT2v3TsnzD7R.mXr6tqhOLQwGSdJRdttIxdCv93ne1XpOCezzsySNpcUezTkC_h63B28BqzvdUHee3r_HgtJSDkHWhWlJY4lP24skUD0hsBxDBYILETxxKfUevSx11pK.ok649sNl7KAoRmjYQUWTJcrIgfuZryDjr3PBU4W6HQ0FEC_ZnOcl8w9bqp8gpg8rg77MTrwH5D33Jnew- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A847126.50409@netconfcentral.com> Date: Thu, 13 Aug 2009 13:01:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Randy Presuhn References: <4A8455F8.3070509@netconfcentral.com> <000801ca1c4d$f1d1d2c0$6801a8c0@oemcomputer> In-Reply-To: <000801ca1c4d$f1d1d2c0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] leafref problems 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: Thu, 13 Aug 2009 20:02:31 -0000 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "NETMOD Working Group" >> Sent: Thursday, August 13, 2009 11:05 AM >> Subject: [netmod] leafref problems > ... >> I think the leafref should not be allowed in config=true objects >> at all. They are not properly supported, and they are not really >> needed either. Leafref is way more trouble than it is worth. >> It hardly ever shows up in MIBs. I know of 1 MIB -- the >> RMON usrHistoryTable, which uses a leafref as part of its >> self-contained config to monitor read-only data. > > Similar things abound in the disman MIB modules' configuration > data. The patterns used in VACM are also *conceptually* similar, > though they're really built on syntactic punning. There really are > cases where it's necessary for configuration data to refer to > other elements of configuration data. If leafref in its current form > is problematic, a counter-proposal is in order. > these MIB modules are not widely used. IMO, the leafref database object introduces a lot of complexity for a very minor feature. I don't have a counter-proposal to fix leafref, other than to disallow the parts that don't work. I think the normal process is for the WG to first agree or disagree that any problem exists. Somebody can go through all the points I raised and explain why there are no concerns for users of the YANG standard in any of them. If somebody has a better solution then great. I don't think the outcome of "nobody has a good solution, so we will just ignore the problem" works that well during the later review stages of the IETF standards process. >> It isn't even very good for RPC/notification. A 'varbind' approach >> would be much better and much easier to use. > > I'm inclined to agree. > > Randy Andy From mbj@tail-f.com Thu Aug 13 13:14: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 F293928C210 for ; Thu, 13 Aug 2009 13:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.069, 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 U5XxEzQtdueC for ; Thu, 13 Aug 2009 13:14:25 -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 3C40228C159 for ; Thu, 13 Aug 2009 13:14:08 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D80276C540; Thu, 13 Aug 2009 22:13:19 +0200 (CEST) Date: Thu, 13 Aug 2009 22:13:18 +0200 (CEST) Message-Id: <20090813.221318.55822339.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8455F8.3070509@netconfcentral.com> References: <4A8455F8.3070509@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] leafref problems 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: Thu, 13 Aug 2009 20:14:26 -0000 Andy Bierman wrote: > Hi, > > From yang-07, sec. 9.9.2 > > The "path" XPath expression is conceptually evaluated in the > following context, in addition to the definition in Section 6.4.1: > > o The context node is the node in the data tree for which the "path" > statement is defined. > > > The accessible tree depends on the context node: > > o If the leaf with the instance-identifier type represents > configuration data, the tree is the data in one of the NETCONF > datastores. The XPath root node has all top-level configuration > data nodes in all modules as children. > > o Otherwise the tree is all state data on the device, and the > datastore. The XPath root node has all top-level data > nodes in all modules as children. > > 1) this must be a bug, because it discusses the i-i type > in the section about the leafref builtin type. Yes, fixed in the upcoming -08. > 3) There are no compelling use-cases for including leafref objects > in the database. Haven't we had this discussion several times before? Are you now suggesting that no leafref type whatsoever is needed, or are you (still) concerned with leafref to non-key leafs? /martin From andy@netconfcentral.com Thu Aug 13 13:18:01 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 ADE6C3A6C53 for ; Thu, 13 Aug 2009 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 Ijb-XvuBOpbM for ; Thu, 13 Aug 2009 13:18:00 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id C8F9D3A6863 for ; Thu, 13 Aug 2009 13:18:00 -0700 (PDT) Received: from [68.142.200.221] by n17.bullet.mail.mud.yahoo.com with NNFMP; 13 Aug 2009 20:17:30 -0000 Received: from [68.142.201.253] by t9.bullet.mud.yahoo.com with NNFMP; 13 Aug 2009 20:17:30 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 13 Aug 2009 20:17:30 -0000 X-Yahoo-Newman-Id: 163641.83087.bm@omp414.mail.mud.yahoo.com Received: (qmail 49233 invoked from network); 13 Aug 2009 20:17:29 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2009 20:17:29 -0000 X-YMail-OSG: Vuf1hE4VM1kJgqGPPSgxEW0tON08afse0N.9tHVJGSG5txR9BVFu92D1A072bZrBJ52LUb2QWGuahV3dGU.TK1EI.GyZgbjvSgqEvvJrGsqNKJ6mSfSpRTe1gyIq5r48X7zCfHBprhQ.Hg15qWjxV8h7qtf9xjhOuzYCiqId7Q2TyzO_Tht94cKJkuW8UgcNAeR13ClX.544nSjkfXOiqG_boXC3zS15ce0ExeOrZEqpNfIQKpBdYPUCgdP7pvb6tnND.XBeTBVOq1FiuDq1L1.7zZ8w6wi4yk7b1exLKUAnT_k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8474C2.3090407@netconfcentral.com> Date: Thu, 13 Aug 2009 13:17:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Randy Presuhn References: <4A8455F8.3070509@netconfcentral.com> <000801ca1c4d$f1d1d2c0$6801a8c0@oemcomputer> In-Reply-To: <000801ca1c4d$f1d1d2c0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] leafref problems 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: Thu, 13 Aug 2009 20:18:01 -0000 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "NETMOD Working Group" >> Sent: Thursday, August 13, 2009 11:05 AM >> Subject: [netmod] leafref problems > ... >> I think the leafref should not be allowed in config=true objects >> at all. They are not properly supported, and they are not really >> needed either. Leafref is way more trouble than it is worth. >> It hardly ever shows up in MIBs. I know of 1 MIB -- the >> RMON usrHistoryTable, which uses a leafref as part of its >> self-contained config to monitor read-only data. > > Similar things abound in the disman MIB modules' configuration > data. The patterns used in VACM are also *conceptually* similar, > though they're really built on syntactic punning. There really are > cases where it's necessary for configuration data to refer to > other elements of configuration data. If leafref in its current form > is problematic, a counter-proposal is in order. > this isn't really leafref we are talking about. leafref has a hard-wired target object in the YANG file that can never be changed. The RMON use (and the varbind use) is really a pair of objects -- an instance-identifier leaf to identify the pointed-at-object, and an anyxml node to represent the pointed-at-contents. leafref does not provide anything like that. >> It isn't even very good for RPC/notification. A 'varbind' approach >> would be much better and much easier to use. > > I'm inclined to agree. > > Randy > Andy From andy@netconfcentral.com Thu Aug 13 13:32: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 0FA4F28C204 for ; Thu, 13 Aug 2009 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 K2FsQq4QB3GZ for ; Thu, 13 Aug 2009 13:32:03 -0700 (PDT) Received: from n75.bullet.mail.sp1.yahoo.com (n75.bullet.mail.sp1.yahoo.com [98.136.44.51]) by core3.amsl.com (Postfix) with SMTP id 43C0128C203 for ; Thu, 13 Aug 2009 13:32:03 -0700 (PDT) Received: from [216.252.122.216] by n75.bullet.mail.sp1.yahoo.com with NNFMP; 13 Aug 2009 20:31:27 -0000 Received: from [68.142.194.243] by t1.bullet.sp1.yahoo.com with NNFMP; 13 Aug 2009 20:31:27 -0000 Received: from [68.142.201.72] by t1.bullet.mud.yahoo.com with NNFMP; 13 Aug 2009 20:31:27 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 13 Aug 2009 20:31:27 -0000 X-Yahoo-Newman-Id: 54185.33618.bm@omp424.mail.mud.yahoo.com Received: (qmail 76863 invoked from network); 13 Aug 2009 20:31:26 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2009 20:31:26 -0000 X-YMail-OSG: 3_T4ZwUVM1l8w1QBv7SrY.IPbgHaL3f0VDzP7iNjuDsX9ZhKpGkPSLop1FnD3ml5PANxitP8cERUUa_lDpNIsoojyrfkSTcXpnkxQkzxqJhIj4xaAmsXu_TtCFwJmjI4qlKYI0gKoyyL1rmqki7ntm9joeFdYHKOzRL4NCDJgIHNdwOejMrkTJegDFNOdSlidXbdMm11vtZvAj2Xvm.m_W87Gx2BFDOET2WL6J5Z.aTAe4ha1ZIgESLWDDHeRV0DfYNyT5Nv9UKIdLzlVB7OxwE3kYhx5Fi5kyl4KZMTOyU0OTuOpt2M7XtgzBKudzz05t7GNRjQ_s1h7YR1yr_7sK6gAij_hYSeQq1CkaiNTFCrjXpI X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A847880.2030808@netconfcentral.com> Date: Thu, 13 Aug 2009 13:33:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8455F8.3070509@netconfcentral.com> <20090813.221318.55822339.mbj@tail-f.com> In-Reply-To: <20090813.221318.55822339.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Thu, 13 Aug 2009 20:32:04 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> From yang-07, sec. 9.9.2 >> >> The "path" XPath expression is conceptually evaluated in the >> following context, in addition to the definition in Section 6.4.1: >> >> o The context node is the node in the data tree for which the "path" >> statement is defined. >> >> >> The accessible tree depends on the context node: >> >> o If the leaf with the instance-identifier type represents >> configuration data, the tree is the data in one of the NETCONF >> datastores. The XPath root node has all top-level configuration >> data nodes in all modules as children. >> >> o Otherwise the tree is all state data on the device, and the >> datastore. The XPath root node has all top-level data >> nodes in all modules as children. >> >> 1) this must be a bug, because it discusses the i-i type >> in the section about the leafref builtin type. > > Yes, fixed in the upcoming -08. > this needs to be changed for for i-i too, because that is just as bad, and confusing. Sometimes an i-i points to the , sometimes to the , sometimes to candidate, sometimes to running, sometimes who knows where because the target is specified in a description clause. pg 132: o If the leaf with the instance-identifier type represents configuration data, the tree is the data in one of the NETCONF datastores. The XPath root node has all top-level configuration data nodes in all modules as children. Does the operation check the leafrefs against the candidate, and checks them against the running config? Or does the agent do whatever it wants? Which "one of the NETCONF datastores" does an i-i represent? This is very confusing. IMO, i-i should have a static format: /nc:rpc/... --> in the PDU /nc:rpc-reply/... --> in the PDU /ncn:notification/... --> in the PDU Everything else --> top-level node in the database or conceptual state data available with The i-i data type is an absolute path expression, so the parent context is irrelevant. >> 3) There are no compelling use-cases for including leafref objects >> in the database. > > Haven't we had this discussion several times before? Are you now > suggesting that no leafref type whatsoever is needed, or are you > (still) concerned with leafref to non-key leafs? > > The recent issues I raised were discussed before and resolved? I do not remember that. What was the resolution to each issue? > > /martin > Andy From mbj@tail-f.com Thu Aug 13 23:17: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 1425128C0F0 for ; Thu, 13 Aug 2009 23:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ukwkiDzSMK8e for ; Thu, 13 Aug 2009 23:17:41 -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 2F9413A67DD for ; Thu, 13 Aug 2009 23:17:41 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D2FD076C4D1; Fri, 14 Aug 2009 08:17:13 +0200 (CEST) Date: Fri, 14 Aug 2009 08:17:13 +0200 (CEST) Message-Id: <20090814.081713.43129145.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8455F8.3070509@netconfcentral.com> References: <4A8455F8.3070509@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] leafref problems 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: Fri, 14 Aug 2009 06:17:42 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Haven't we had this discussion several times before? Are you now > > suggesting that no leafref type whatsoever is needed, or are you > > (still) concerned with leafref to non-key leafs? You didn't reply to my clarifying question above, so I will assume that you mean that you want to remove leafref completely. > The recent issues I raised were discussed before and > resolved? I do not remember that. What was the resolution > to each issue? > 1) this must be a bug, because it discusses the i-i type > in the section about the leafref builtin type. Fixed bug, as already mentioned. > 2) This behavior is really complicated, especially when the leafref > is nested within a union typedef. That's why leafref is not allowed in union. > 3) There are no compelling use-cases for including leafref objects > in the database. I strongly disagree. Cross references are common in configuration data. For example, see the ipfix module. For an SNMP example, see how many MIBs have references to ifIndex. Search the ML archives for more examples. Our customers use it (or rather the somewhat older 'keyref') all the time. > 4) The issues I raised wrt mandatory/optional or just dealing > with objects that point at nonexistent nodes (not-supported > or if-feature=false, or when-stmt=false) make leafref almost > unusable in the database. IMO this falls under garbage in / garbage out. You can get the same problems with must expressions. You can even get the same problem with description clauses: leaf a { if-feature foo; type int32; } leaf b { type int32; mandatory true; description "This leaf MUST be a divisor of the leaf 'a'"; } > It isn't even very good for RPC/notification. A 'varbind' approach > would be much better and much easier to use. You agreed in http://www.ietf.org/mail-archive/web/netmod/current/msg03104.html that this should wait. /martin From andy@netconfcentral.com Fri Aug 14 03:19: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 EEE553A6867 for ; Fri, 14 Aug 2009 03:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.174, 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 lVs3weywaikc for ; Fri, 14 Aug 2009 03:19:44 -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 0621A3A67B5 for ; Fri, 14 Aug 2009 03:19:43 -0700 (PDT) Received: (qmail 82657 invoked from network); 14 Aug 2009 10:18:35 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 10:18:34 -0000 X-YMail-OSG: KW9tznEVM1nNn2ZbZZfWvtZ6TC5pkvHPbw2QpO.NltG299hVdCDwfSNgApl3mWSwrP3Z4f1H3NRKzCjyeHz.3CEkjb25QTQyJ4PDXqICbA47Yg6fErDP6YLmmoQCihBdYfIg9PPTuSso1zHOTAPKo06hUMkCo3e9dvGRBL7MTkq4awTwU9MINElIJwDXdSRoUQGe3VYdA1.bUVBw995nYcbPjr6Mz0iBOGxpVM6JtZPmvBAkhqSHSj73ElOLVheY5UNZpOP6fRW_UIU9DT87CBRhjwOvvtCEswPHFMPmdQZMWB3o65R1DEKO1vpW9HQaN3ekVvXeNSck4b75YoI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A853A60.1040809@netconfcentral.com> Date: Fri, 14 Aug 2009 03:20:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8455F8.3070509@netconfcentral.com> <20090814.081713.43129145.mbj@tail-f.com> In-Reply-To: <20090814.081713.43129145.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Fri, 14 Aug 2009 10:19:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Haven't we had this discussion several times before? Are you now >>> suggesting that no leafref type whatsoever is needed, or are you >>> (still) concerned with leafref to non-key leafs? > > You didn't reply to my clarifying question above, so I will assume > that you mean that you want to remove leafref completely. > no; just leafref pointing at leafref and config=true leafref >> The recent issues I raised were discussed before and >> resolved? I do not remember that. What was the resolution >> to each issue? > >> 1) this must be a bug, because it discusses the i-i type >> in the section about the leafref builtin type. > > Fixed bug, as already mentioned. > i-i needs to be fixed as well. The database MUST always be , not up to the agent to decide. >> 2) This behavior is really complicated, especially when the leafref >> is nested within a union typedef. > > That's why leafref is not allowed in union. > good -- not easy to remember what types are allowed where though. >> 3) There are no compelling use-cases for including leafref objects >> in the database. > > I strongly disagree. Cross references are common in configuration > data. For example, see the ipfix module. For an SNMP example, see > how many MIBs have references to ifIndex. Search the ML archives for > more examples. Our customers use it (or rather the somewhat older > 'keyref') all the time. 1) I am not convinced that the ipfix model is implementable by mere mortals. When somebody actually has it working in running code, then I will be proved wrong. 2) INDEX by reference is trivial to support in SMIv2, and could be as well in YANG. YANG allows nested tabled instead of flattened out tables like SMIv2, so table linkage can be done multiple ways. What is the use-case for leafref pointing at leafref? > >> 4) The issues I raised wrt mandatory/optional or just dealing >> with objects that point at nonexistent nodes (not-supported >> or if-feature=false, or when-stmt=false) make leafref almost >> unusable in the database. > > IMO this falls under garbage in / garbage out. You can get the same > problems with must expressions. You can even get the same problem > with description clauses: > > leaf a { > if-feature foo; > type int32; > } > leaf b { > type int32; > mandatory true; > description "This leaf MUST be a divisor of the leaf 'a'"; > } > IMO, YANG has way too much GIGO! YANG just ignores the broken protocol behavior, and that is unacceptable. You can define mandatory top-level objects that cannot possibly be supported by any NETCONF agent. You can have objects pointing at non-existent objects, which also cannot possibly be implemented by any NETCONF agent. YANG tools needs to check leafref: - mandatory pointing at optional - conditional pointing at different conditional - not conditional pointing at conditional A YANG compiler MUST detect these fatal errors. A YANG module is invalid and will not be usable if any leafref object has these conditions. If the agent contains any leafref objects whatsoever which are no longer valid because the pointed-at object is not available (e.g. due to deviations not-supported) then what is supposed to happen to the leafref object(s)? Is the agent supposed to remove all the leafrefs that point at the not-supported leaf? Just crash and burn? How does YANG modify the NETCONF protocol (again) so NETCONF works with YANG in this case? >> It isn't even very good for RPC/notification. A 'varbind' approach >> would be much better and much easier to use. > > You agreed in > http://www.ietf.org/mail-archive/web/netmod/current/msg03104.html that > this should wait. > Yes -- eventually I want a varbind-based solution. I don't care if it is added now or later. > > /martin > Andy From mbj@tail-f.com Fri Aug 14 04:58: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 BB53B3A6828 for ; Fri, 14 Aug 2009 04:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.195, 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 6-Csx-0CPV7c for ; Fri, 14 Aug 2009 04:58:53 -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 9519F3A6819 for ; Fri, 14 Aug 2009 04:58:52 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2559D616008; Fri, 14 Aug 2009 13:55:29 +0200 (CEST) Date: Fri, 14 Aug 2009 13:55:28 +0200 (CEST) Message-Id: <20090814.135528.01350591.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A853A60.1040809@netconfcentral.com> References: <4A8455F8.3070509@netconfcentral.com> <20090814.081713.43129145.mbj@tail-f.com> <4A853A60.1040809@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] leafref problems 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: Fri, 14 Aug 2009 11:58:53 -0000 [resend] Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> 1) this must be a bug, because it discusses the i-i type > >> in the section about the leafref builtin type. > > > > Fixed bug, as already mentioned. > > > > i-i needs to be fixed as well. > The database MUST always be , not up to the agent to decide. No, if the data store is candidate, then the i-i must point to something in candidate, if you do a validate of candidate. I propose the following change (and similar for the other case; must/when/path): OLD: - If this leaf represents configuration data, the tree is the data in one of the NETCONF datastores. The XPath root node has all top-level configuration data nodes in all modules as children. NEW: - If this leaf represents configuration data, the tree is the data in the NETCONF datastore where the leaf exists. The XPath root node has all top-level configuration data nodes in all modules as children. > >> 3) There are no compelling use-cases for including leafref objects > >> in the database. > > > > I strongly disagree. Cross references are common in configuration > > data. For example, see the ipfix module. For an SNMP example, see > > how many MIBs have references to ifIndex. Search the ML archives for > > more examples. Our customers use it (or rather the somewhat older > > 'keyref') all the time. > > 1) I am not convinced that the ipfix model is implementable > by mere mortals. When somebody actually has it working in > running code, then I will be proved wrong. > > 2) INDEX by reference is trivial to support in SMIv2, > and could be as well in YANG. YANG allows nested tabled > instead of flattened out tables like SMIv2, so table linkage > can be done multiple ways. > > What is the use-case for leafref pointing at leafref? This is a cross reference to something which happens to have a cross reference to something else. If you want to discuss implementation strategies for leafrefs, I am happy to do that (off-line). > YANG tools needs to check leafref: This is good - it is always easier to make progress when there is a concrete proposal to discuss. > - mandatory pointing at optional There is no reason this should be illegal - it might be bad design, but the semantics are clear. In order to create a valid configuration, the mandatory leafref MUST be set. And it MUST point to something that exists, so the optional leaf (or more likeley, the list entry) MUST also exist. > - conditional pointing at different conditional > - not conditional pointing at conditional > A YANG compiler MUST detect these fatal errors. > A YANG module is invalid and will not be usable > if any leafref object has these conditions. If by conditional you mean 'if-feature' I agree. But it is not trivial to describe this. For example this should be valid: feature a { ... } feature b { if-feature a; ... } feature c { if-feature b; ... } list x { if-feature c; key y; ... } leaf z { if-feature a; type leafref { path /x/c; } } Can you propose some text to describe this? (Assuming this is what you had in mind). /martin From mbj@tail-f.com Fri Aug 14 05:07: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 56D883A6964 for ; Fri, 14 Aug 2009 05:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.187, 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 6Zt+0i5c68wN for ; Fri, 14 Aug 2009 05:07:38 -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 37F323A69EC for ; Fri, 14 Aug 2009 05:07:38 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8286676C4D1; Fri, 14 Aug 2009 13:19:43 +0200 (CEST) Date: Fri, 14 Aug 2009 13:19:43 +0200 (CEST) Message-Id: <20090814.131943.195753685.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A853A60.1040809@netconfcentral.com> References: <4A8455F8.3070509@netconfcentral.com> <20090814.081713.43129145.mbj@tail-f.com> <4A853A60.1040809@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] leafref problems 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: Fri, 14 Aug 2009 12:07:39 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> 1) this must be a bug, because it discusses the i-i type > >> in the section about the leafref builtin type. > > > > Fixed bug, as already mentioned. > > > > i-i needs to be fixed as well. > The database MUST always be , not up to the agent to decide. No, if the data store is candidate, then the i-i must point to something in candidate, if you do a validate of candidate. I propose the following change (and similar for the other case; must/when/path): OLD: - If this leaf represents configuration data, the tree is the data in one of the NETCONF datastores. The XPath root node has all top-level configuration data nodes in all modules as children. NEW: - If this leaf represents configuration data, the tree is the data in the NETCONF datastore where the leaf exists. The XPath root node has all top-level configuration data nodes in all modules as children. > >> 3) There are no compelling use-cases for including leafref objects > >> in the database. > > > > I strongly disagree. Cross references are common in configuration > > data. For example, see the ipfix module. For an SNMP example, see > > how many MIBs have references to ifIndex. Search the ML archives for > > more examples. Our customers use it (or rather the somewhat older > > 'keyref') all the time. > > 1) I am not convinced that the ipfix model is implementable > by mere mortals. When somebody actually has it working in > running code, then I will be proved wrong. > > 2) INDEX by reference is trivial to support in SMIv2, > and could be as well in YANG. YANG allows nested tabled > instead of flattened out tables like SMIv2, so table linkage > can be done multiple ways. > > What is the use-case for leafref pointing at leafref? This is a cross reference to something which happens to have a cross reference to something else. If you want to discuss implementation strategies for leafrefs, I am happy to do that (off-line). > YANG tools needs to check leafref: This is good - it is always easier to make progress when there is a concrete proposal to discuss. > - mandatory pointing at optional There is no reason this should be illegal - it might be bad design, but the semantics are clear. In order to create a valid configuration, the mandatory leafref MUST be set. And it MUST point to something that exists, so the optional leaf (or more likeley, the list entry) MUST also exist. > - conditional pointing at different conditional > - not conditional pointing at conditional > A YANG compiler MUST detect these fatal errors. > A YANG module is invalid and will not be usable > if any leafref object has these conditions. If by conditional you mean 'if-feature' I agree. But it is not trivial to describe this. For example this should be valid: feature a { ... } feature b { if-feature a; ... } feature c { if-feature b; ... } list x { if-feature c; key y; ... } leaf z { if-feature a; type leafref { path /x/c; } } Can you propose some text to describe this? (Assuming this is what you had in mind). /martin From andy@netconfcentral.com Fri Aug 14 06:25: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 64EC03A6A22 for ; Fri, 14 Aug 2009 06:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 cbgZOdm5P3hi for ; Fri, 14 Aug 2009 06:25:48 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 58B843A689A for ; Fri, 14 Aug 2009 06:25:48 -0700 (PDT) Received: (qmail 87692 invoked from network); 14 Aug 2009 13:23:58 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 13:23:57 -0000 X-YMail-OSG: 2elWPn0VM1mN1auxEG_5yifjxXK_6In_ypvumZbJ2a08RmPq4YZoOhjRjOvIMw9eRiiQnsiY5mqRYuW1LuYuMrGIjoDL8VCiDdUjzk6UnFKhGeeowLiBcCq08ig1hLbpiqpbCf_NVBDlOUAqNVVuuxIQ4VtezO8kB5vAODLPhmrHvl_UMsvxYZO7L7t2xgHmBj1tw2PIf4AD7cj3herzsbsIygQxCaXAjOPSBLT0KEWpXfC.X2ujbViOp_0lM4Pn32n2ixzKZWDE9q.TWgcs6AjpS1IO75RbOFkkSkHclOG17OFB4ccKvKa2hyV2GJVr8Y_D.2uGQpZlJ.4ctmI6WI7pIuMbQFkCdCT1Rnt5YinS.QMy X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A856559.4040402@netconfcentral.com> Date: Fri, 14 Aug 2009 06:23:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8455F8.3070509@netconfcentral.com> <20090814.081713.43129145.mbj@tail-f.com> <4A853A60.1040809@netconfcentral.com> <20090814.131943.195753685.mbj@tail-f.com> In-Reply-To: <20090814.131943.195753685.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Fri, 14 Aug 2009 13:25:49 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> 1) this must be a bug, because it discusses the i-i type >>>> in the section about the leafref builtin type. >>> Fixed bug, as already mentioned. >>> >> i-i needs to be fixed as well. >> The database MUST always be , not up to the agent to decide. > > No, if the data store is candidate, then the i-i must point to > something in candidate, if you do a validate of candidate. > > I propose the following change (and similar for the other case; > must/when/path): > > OLD: > > - If this leaf represents configuration data, the tree is the data in > one of the NETCONF datastores. The XPath root node has all > top-level configuration data nodes in all modules as children. > > NEW: > > - If this leaf represents configuration data, the tree is the data in > the NETCONF datastore where the leaf exists. The XPath root node > has all top-level configuration data nodes in all modules as > children. > rpc barf { input { leaf a { type leafref { path /foo/bar/baz; } } } } So which database is this leafref in? Can the agent just pick one? This proposal does not work. The leafref MUST point at . The only valid config is . YANG specifies what goes in a valid database. NETCONF specifies how the protocol operations work. IMO, leafref and instance-identifier are both broken. > >>>> 3) There are no compelling use-cases for including leafref objects >>>> in the database. >>> I strongly disagree. Cross references are common in configuration >>> data. For example, see the ipfix module. For an SNMP example, see >>> how many MIBs have references to ifIndex. Search the ML archives for >>> more examples. Our customers use it (or rather the somewhat older >>> 'keyref') all the time. >> 1) I am not convinced that the ipfix model is implementable >> by mere mortals. When somebody actually has it working in >> running code, then I will be proved wrong. >> >> 2) INDEX by reference is trivial to support in SMIv2, >> and could be as well in YANG. YANG allows nested tabled >> instead of flattened out tables like SMIv2, so table linkage >> can be done multiple ways. >> >> What is the use-case for leafref pointing at leafref? > > This is a cross reference to something which happens to have a cross > reference to something else. > > If you want to discuss implementation strategies for leafrefs, I am > happy to do that (off-line). > I think leafref and instance-identifier are really problematic and need to be fixed or removed from YANG. >> YANG tools needs to check leafref: > > This is good - it is always easier to make progress when there is > a concrete proposal to discuss. > >> - mandatory pointing at optional > > There is no reason this should be illegal - it might be bad design, > but the semantics are clear. In order to create a valid > configuration, the mandatory leafref MUST be set. And it MUST point > to something that exists, so the optional leaf (or more likeley, the > list entry) MUST also exist. bad design? IMO broken YANG. This is the mandatory-by-indirection part of leafref. Anything a mandatory leafref points at is also mandatory. > >> - conditional pointing at different conditional >> - not conditional pointing at conditional >> A YANG compiler MUST detect these fatal errors. >> A YANG module is invalid and will not be usable >> if any leafref object has these conditions. > > If by conditional you mean 'if-feature' I agree. But it is not > trivial to describe this. For example this should be valid: > I mean any form of conditional object. YANG has so many to choose from, and a tool must get it right for all of them, not just 1. This is close to impossible to implement, but I could say that about several parts of YANG. > feature a { ... } > feature b { if-feature a; ... } > feature c { if-feature b; ... } > > list x { > if-feature c; > key y; > ... > } > leaf z { > if-feature a; > type leafref { path /x/c; } > } > > Can you propose some text to describe this? (Assuming this is what > you had in mind). > yes - remove leafref -- it is broken, complex, and easily misused. I propose to let tools figure it out like the rest of the complexity in YANG. > > /martin > Andy From mbj@tail-f.com Fri Aug 14 06:34: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 3AE313A694A for ; Fri, 14 Aug 2009 06:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.179, 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 YZZwP1NX0Lsc for ; Fri, 14 Aug 2009 06:34:23 -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 BAF243A67E7 for ; Fri, 14 Aug 2009 06:34:05 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F7B676C4D1; Fri, 14 Aug 2009 15:32:32 +0200 (CEST) Date: Fri, 14 Aug 2009 15:32:32 +0200 (CEST) Message-Id: <20090814.153232.162557664.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A856559.4040402@netconfcentral.com> References: <4A853A60.1040809@netconfcentral.com> <20090814.131943.195753685.mbj@tail-f.com> <4A856559.4040402@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] leafref problems 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: Fri, 14 Aug 2009 13:34:24 -0000 Andy Bierman wrote: > > I propose the following change (and similar for the other case; > > must/when/path): > > > > OLD: > > > > - If this leaf represents configuration data, the tree is the data in > > one of the NETCONF datastores. The XPath root node has all > > top-level configuration data nodes in all modules as children. > > > > NEW: > > > > - If this leaf represents configuration data, the tree is the data in > > the NETCONF datastore where the leaf exists. The XPath root node > > has all top-level configuration data nodes in all modules as > > children. > > > > > rpc barf { > input { > leaf a { > type leafref { path /foo/bar/baz; } > } > } > } > > So which database is this leafref in? > Can the agent just pick one? Andy, please check the text. See the last bullet in section 9.9.2. With the change I propose for the first bullet, the new complete text is: o The context node is the node in the data tree for which the "path" statement is defined. The accessible tree depends on the context node: o If the context node represents configuration data, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children. o Otherwise the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. > This proposal does not work. > The leafref MUST point at . Yes, that how it works, since the last bullet apply in your rpc example. /martin From andy@netconfcentral.com Fri Aug 14 06:59: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 17F553A6A3A for ; Fri, 14 Aug 2009 06:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 IP9ksj64VozX for ; Fri, 14 Aug 2009 06:59:27 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 395AC3A67E7 for ; Fri, 14 Aug 2009 06:59:27 -0700 (PDT) Received: from [68.142.194.243] by n20.bullet.mail.mud.yahoo.com with NNFMP; 14 Aug 2009 13:58:00 -0000 Received: from [68.142.201.248] by t1.bullet.mud.yahoo.com with NNFMP; 14 Aug 2009 13:58:00 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 14 Aug 2009 13:58:00 -0000 X-Yahoo-Newman-Id: 47984.58083.bm@omp409.mail.mud.yahoo.com Received: (qmail 50023 invoked from network); 14 Aug 2009 13:57:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2009 13:57:59 -0000 X-YMail-OSG: dkQQSr4VM1kUrw3asG8SoB2tjlulBOtoOvEV4P8LZhunfVf3KvXj_b3Jqhpgx1zzmOWI4XFgIM0pQtVIZIxQbm6.ZTEWy.gHJA9Edmj5nFz_JfHup.VAgJJIdzCalK4h_VL2OKPQubfJ9QL_s_21D6gKuoKtuAHV16co.WlMEWYGILvKnYDGgQhWI8K6sRBGcPw94OyYbBp_nlxRW4dNbb1bsuYuza7UBAsd05lR9B8orDBSLuGoKsCVe3eM7gFatjSrKRZkyPSUcTc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A856DCD.1050802@netconfcentral.com> Date: Fri, 14 Aug 2009 06:59:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] YANG must work with NETCONF 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: Fri, 14 Aug 2009 13:59:28 -0000 Hi, There are several details in YANG that are legal, yet they represent data models which cannot possibly be supported on any NETCONF agent. Mandatory top-level nodes are allowed in YANG but not supportable in a NETCONF agent. If an agent is free to choose what mandatory means, then since all YANG modules need to work with all conforming NETCONF implementations, the top-level cannot be mandatory. leafref objects are allowed to point at non-existent nodes in YANG but this is not implementable on the agent. If the pointed-at object is not present, then any object pointing at that object must also be removed from the agent (ripple out until done). YANG is already extremely difficult to learn. It is way worse trying to explain to people why their perfectly valid YANG module cannot be supported by any NETCONF agent. SMIv2 does not work this way. You cannot use SMIv2 to construct valid definitions which are not supportable in SNMP. If SMIv2 says it's OK, then it MUST work on a compliant SNMP agent. YANG/NETCONF MUST work the same way. Andy From andy@netconfcentral.com Fri Aug 14 07:10: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 0DC673A6A0C for ; Fri, 14 Aug 2009 07:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 axRxfoYYZfPP for ; Fri, 14 Aug 2009 07:10:25 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 313AA3A694A for ; Fri, 14 Aug 2009 07:10:25 -0700 (PDT) Received: (qmail 14342 invoked from network); 14 Aug 2009 14:09:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 14:09:06 -0000 X-YMail-OSG: eRWZzl8VM1mlEiHQgL2vOvSTlUCBQKG7unAS7shmRDfDA_c.cPIOrXYYmTzA_sezZL_cdWjRTRw54bAwsFocU3cO8JTjCA6CWnsTVArUPdLrgyhPAzxCuU6OJflxCoD03Djh8E8ZUR8bO0sKWmybLZV75uz1vFZeNRWltoG_LJfvWFd_6Gyiimi7QsMtLnN5Cp.kM3vkSLL.Z2SQ_HnMC4dKemJ4MvxC0HkTksB0K15nOlJXQfGTawfJghO6.7UM9MiVPZFKoUCfu7J3Jmq5Lgv70K6h201hUKFV0hFQNxziL8ZrhkWr7gDMWR8cpAI.MxSa_9unmeEZmqprboGJQ2HLyrdgWuW3A5V5EnXDyP9uimNI X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A857069.2070608@netconfcentral.com> Date: Fri, 14 Aug 2009 07:10:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A853A60.1040809@netconfcentral.com> <20090814.131943.195753685.mbj@tail-f.com> <4A856559.4040402@netconfcentral.com> <20090814.153232.162557664.mbj@tail-f.com> In-Reply-To: <20090814.153232.162557664.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Fri, 14 Aug 2009 14:10:27 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>> I propose the following change (and similar for the other case; >>> must/when/path): >>> >>> OLD: >>> >>> - If this leaf represents configuration data, the tree is the data in >>> one of the NETCONF datastores. The XPath root node has all >>> top-level configuration data nodes in all modules as children. >>> >>> NEW: >>> >>> - If this leaf represents configuration data, the tree is the data in >>> the NETCONF datastore where the leaf exists. The XPath root node >>> has all top-level configuration data nodes in all modules as >>> children. >>> >> >> rpc barf { >> input { >> leaf a { >> type leafref { path /foo/bar/baz; } >> } >> } >> } >> >> So which database is this leafref in? >> Can the agent just pick one? > > Andy, please check the text. See the last bullet in section 9.9.2. > With the change I propose for the first bullet, the new complete text > is: > I read the text. I don't think it works. How does the agent know from that PDU which database it is in? What would a leafref definition look like that wasn't associated with config? leaf huh { type leafref [path { /who/knows; } } This definition is not specific to candidate or running or startup. It is just a config leaf that exists in all 3 databases. So the phrase 'the NETCONF datastore where the context node exists' is totally wrong. It assumes there is 1 datastore where the node exists, and it assumes the agent will know which one. > o The context node is the node in the data tree for which the "path" > statement is defined. > > The accessible tree depends on the context node: > > o If the context node represents configuration data, the tree is the > data in the NETCONF datastore where the context node exists. The > XPath root node has all top-level configuration data nodes in all > modules as children. > > o Otherwise the tree is all state data on the device, and the > datastore. The XPath root node has all top-level data > nodes in all modules as children. > > >> This proposal does not work. >> The leafref MUST point at . > > Yes, that how it works, since the last bullet apply in your rpc > example. > > > /martin > Andy From mehmet.ersue@nsn.com Fri Aug 14 07:16: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 34A153A69F6 for ; Fri, 14 Aug 2009 07:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.189 X-Spam-Level: X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=1.410, 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 0x+7GiIg6Kii for ; Fri, 14 Aug 2009 07:16:56 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 22AC63A694A for ; Fri, 14 Aug 2009 07:16:55 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7EEGMgr019200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2009 16:16:22 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7EEGMp0031159; Fri, 14 Aug 2009 16:16:22 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 16:16:22 +0200 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: Fri, 14 Aug 2009 16:16:21 +0200 Message-ID: In-Reply-To: <4A856DCD.1050802@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] YANG must work with NETCONF Thread-Index: Acoc53ZME+MKatCvT3Cgcb7+N3wC7gAAk2mw References: <4A856DCD.1050802@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "NETMOD Working Group" X-OriginalArrivalTime: 14 Aug 2009 14:16:22.0468 (UTC) FILETIME=[CCEF6840:01CA1CE9] Subject: Re: [netmod] YANG must work with NETCONF 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: Fri, 14 Aug 2009 14:16:57 -0000 +1 Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Friday, August 14, 2009 4:00 PM > To: NETMOD Working Group > Subject: [netmod] YANG must work with NETCONF >=20 > Hi, >=20 > There are several details in YANG that are legal, > yet they represent data models which cannot possibly > be supported on any NETCONF agent. >=20 > Mandatory top-level nodes are allowed in YANG > but not supportable in a NETCONF agent. > If an agent is free to choose what mandatory means, > then since all YANG modules need to > work with all conforming NETCONF implementations, > the top-level cannot be mandatory. >=20 > leafref objects are allowed to point at non-existent > nodes in YANG but this is not implementable on > the agent. If the pointed-at object is not present, > then any object pointing at that object must also > be removed from the agent (ripple out until done). >=20 > YANG is already extremely difficult to learn. > It is way worse trying to explain to people > why their perfectly valid YANG module cannot > be supported by any NETCONF agent. >=20 > SMIv2 does not work this way. > You cannot use SMIv2 to construct valid > definitions which are not supportable in SNMP. > If SMIv2 says it's OK, then it MUST work on > a compliant SNMP agent. YANG/NETCONF MUST work > the same way. >=20 >=20 >=20 > Andy >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mbj@tail-f.com Fri Aug 14 07:18: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 9E6E33A6A63 for ; Fri, 14 Aug 2009 07:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.172, 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 JTpDgBlTXYyd for ; Fri, 14 Aug 2009 07:18: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 E0A5F3A699F for ; Fri, 14 Aug 2009 07:18:30 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 838FE76C4D1; Fri, 14 Aug 2009 16:18:21 +0200 (CEST) Date: Fri, 14 Aug 2009 16:18:21 +0200 (CEST) Message-Id: <20090814.161821.206465520.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A857069.2070608@netconfcentral.com> References: <4A856559.4040402@netconfcentral.com> <20090814.153232.162557664.mbj@tail-f.com> <4A857069.2070608@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] leafref problems 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: Fri, 14 Aug 2009 14:18:31 -0000 Andy Bierman wrote: > I read the text. > I don't think it works. > How does the agent know from that PDU > which database it is in? Your example was this: rpc barf { input { leaf a { type leafref { path /foo/bar/baz; } } } } The context node is leaf "a" in the rpc. Thus, the second bullet applies, and the leafref points to and state. > What would a leafref definition look like > that wasn't associated with config? > > > leaf huh { > type leafref [path { /who/knows; } > } > > This definition is not specific to candidate or running or startup. > It is just a config leaf that exists in all 3 databases. > So the phrase 'the NETCONF datastore where the context node exists' > is totally wrong. It assumes there is 1 datastore where the node > exists, and it assumes the agent will know which one. No, if you validate the candidate, the context node is in the candidate, and the node it refers to must also exist in the candidate. /martin From mbj@tail-f.com Fri Aug 14 07:35: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 11FF03A6A4D for ; Fri, 14 Aug 2009 07:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.165, 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 DTx0vZQrF58s for ; Fri, 14 Aug 2009 07:35:26 -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 4322E3A6951 for ; Fri, 14 Aug 2009 07:35:26 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F95B76C4D1; Fri, 14 Aug 2009 16:35:24 +0200 (CEST) Date: Fri, 14 Aug 2009 16:35:24 +0200 (CEST) Message-Id: <20090814.163524.165368278.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A856DCD.1050802@netconfcentral.com> References: <4A856DCD.1050802@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] YANG must work with NETCONF 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: Fri, 14 Aug 2009 14:35:27 -0000 Hi, It's hard not to agree with the statement in the title. Andy Bierman wrote: > There are several details in YANG that are legal, > yet they represent data models which cannot possibly > be supported on any NETCONF agent. > > Mandatory top-level nodes are allowed in YANG > but not supportable in a NETCONF agent. I disagree. See the email thread "mandatory mess". If you have a top-level mandatory leaf, it MUST have a value in a valid database. So, when the system has started and the NETCONF i/f is up and running, the leaf MUST exist. A user can then modify it, but not delete it. > If an agent is free to choose what mandatory means, > then since all YANG modules need to > work with all conforming NETCONF implementations, > the top-level cannot be mandatory. The agent is not free to choose what mandatory means. It means that the leaf MUST exist in a valid data store. > leafref objects are allowed to point at non-existent > nodes in YANG but this is not implementable on > the agent. If the pointed-at object is not present, > then any object pointing at that object must also > be removed from the agent (ripple out until done). I assume you refer to leafrefs which point to leafs with if-feature? As I wrote in the other email thread, I think this is a valid concern, and we should fix it. I prefer to keep the discussion in one email thread though. > YANG is already extremely difficult to learn. I don't know what you base this on, and I don't know what do to with this comment. From my experience with pioneer YANG writers, I disagree though. /martin From andy@netconfcentral.com Fri Aug 14 07:57: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 AD3FE3A6C66 for ; Fri, 14 Aug 2009 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Y9OZ-mAjoZE3 for ; Fri, 14 Aug 2009 07:57:23 -0700 (PDT) Received: from n8.bullet.mail.mud.yahoo.com (n8.bullet.mail.mud.yahoo.com [209.191.86.156]) by core3.amsl.com (Postfix) with SMTP id C02063A6C46 for ; Fri, 14 Aug 2009 07:57:23 -0700 (PDT) Received: from [68.142.200.224] by n8.bullet.mail.mud.yahoo.com with NNFMP; 14 Aug 2009 14:56:49 -0000 Received: from [68.142.201.251] by t5.bullet.mud.yahoo.com with NNFMP; 14 Aug 2009 14:56:49 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 14 Aug 2009 14:56:49 -0000 X-Yahoo-Newman-Id: 519210.55978.bm@omp412.mail.mud.yahoo.com Received: (qmail 65893 invoked from network); 14 Aug 2009 14:56:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2009 14:56:48 -0000 X-YMail-OSG: TFRSwF4VM1n5.7SrRfGaIHHBKNfmNQZOz8v3fJuzN.bwaa47l9oGGjmuFfbewfTjtu4sY5u0G2H.DxtMKjN8nrXPDBMgHfm5AYYNJp2pHLfkETFve8aRi_DIwEqYiyjArsbC0Cpn1KVaXvtrPJHRyANb49WMUPfUiBXFhbmEoqo9EC6Y5VbNTUSQuhNTrq27EDSJohMBkcA32vqUY9RUYuYwo.t_RB8Rjdgc6u.lvElznCC.CWCtUUZp_gq.SjQmbDo7bWORjvJC3IiPxQaXe1t5qpASVj1Wu7wQeJ7vahZCuhAsM4BNXI1I8xr3r4wrkEGUoCvzXGao X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A857B97.4040501@netconfcentral.com> Date: Fri, 14 Aug 2009 07:58:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A856DCD.1050802@netconfcentral.com> <20090814.163524.165368278.mbj@tail-f.com> In-Reply-To: <20090814.163524.165368278.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG must work with NETCONF 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: Fri, 14 Aug 2009 14:57:24 -0000 Martin Bjorklund wrote: > Hi, > > It's hard not to agree with the statement in the title. > > Andy Bierman wrote: >> There are several details in YANG that are legal, >> yet they represent data models which cannot possibly >> be supported on any NETCONF agent. >> >> Mandatory top-level nodes are allowed in YANG >> but not supportable in a NETCONF agent. > > I disagree. See the email thread "mandatory mess". If you have a > top-level mandatory leaf, it MUST have a value in a valid database. > So, when the system has started and the NETCONF i/f is up and running, > the leaf MUST exist. A user can then modify it, but not delete it. > But mandatory means the agent may or may not create it. Since all YANG modules need to work with all valid NETCONF agents, no valid YANG module can have a top-level module, becase a valid agent implementation is allowed to choose not to provide that node. Consider that host address for the command. You really think it makes sense for the agent to pick an IP address at random and start pinging it, in oder to provide a value? Sometimes, the data modeler decides that there is no possible default -- the agent must not choose a value at random. YANG needs to support that type of data model. >> If an agent is free to choose what mandatory means, >> then since all YANG modules need to >> work with all conforming NETCONF implementations, >> the top-level cannot be mandatory. > > The agent is not free to choose what mandatory means. It means that > the leaf MUST exist in a valid data store. > >> leafref objects are allowed to point at non-existent >> nodes in YANG but this is not implementable on >> the agent. If the pointed-at object is not present, >> then any object pointing at that object must also >> be removed from the agent (ripple out until done). > > I assume you refer to leafrefs which point to leafs with if-feature? > As I wrote in the other email thread, I think this is a valid concern, > and we should fix it. I prefer to keep the discussion in one email > thread though. > >> YANG is already extremely difficult to learn. > > I don't know what you base this on, and I don't know what do to with > this comment. From my experience with pioneer YANG writers, I > disagree though. > We shall see in the end of the review cycle whether lots of people agree with you or not. The issue about leafref combined with deviate not-supported was never addressed. This cannot be checked by a YANG compiler. It is something the agent must check. IMO, any leafref object that includes a path statement with non-existent nodes (or any reason) is an invalid object, and the agent must remove that object or shutdown. > > /martin > Andy From reid@snmp.com Fri Aug 14 08:42: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 6FF143A6CCA for ; Fri, 14 Aug 2009 08:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 sjQO-RxMpXKn for ; Fri, 14 Aug 2009 08:42:22 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 99F4E3A6C2D for ; Fri, 14 Aug 2009 08:42:22 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA08568; Fri, 14 Aug 2009 11:42:26 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA26959; Fri, 14 Aug 2009 11:42:26 -0400 (EDT) Message-Id: <200908141542.LAA26959@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 12 Aug 2009 10:52:41 +0200. <20090812.105241.134338006.mbj@tail-f.com> Date: Fri, 14 Aug 2009 11:42:25 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] staying in synch on data model discovery X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:42:23 -0000 > But you advertise your deviations module, and include the revision > there: > > urn:foo?module=foo&revision=2009-01-01?deviations=bar > urn:bar?module=bar&revision=2009-04-01 > > So even if the bar module exists in multiple revisions (this would > happen if bar contains deviations AND reusable typedefs / groupings, > and some other modules import bar by different revision...), only one > is implemented by the device. We do not support that you advertise > multiple versions of a module with data nodes and / or deviations. > I want to make sure I understand this. Does this mean that it would be invalid for a netconf server to support 2 different revisions of the same yang module. For example: urn:foo?module=foo&revision=2008-04-05 urn:foo?module=foo&revision=2009-01-01 -David Reid From andy@netconfcentral.com Fri Aug 14 09:36: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 63BC428C1AD for ; Fri, 14 Aug 2009 09:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=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 vL457Ls3xlIe for ; Fri, 14 Aug 2009 09:36:30 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 96C2028C17A for ; Fri, 14 Aug 2009 09:36:30 -0700 (PDT) Received: (qmail 12418 invoked from network); 14 Aug 2009 16:36:32 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 16:36:32 -0000 X-YMail-OSG: lChpw8AVM1k7zj4U_Pn9UHnvesh75KHpB6KBqDhiiOSxDtLjgPYk4NsrZxDkkLgn_5B.Gq2r6w1ywfhzIMHfIXY5sMQiA6nhBjnuOy4UD_T_VRxqfHAruZYl2kPxrIXQxvzPPQHhreN30QwmnjS9z9UN.RXoXeVHcA7FmzRZ2nT9Thm9UszZzxGmhV.lUiW4e15woO2Wy4NKX62QDNbc3qXFGPm17oerWUGZyIjEUDKjGJFPyPn7_8xT0cbaI71RVNTWaNg_AFG.j44- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8592F7.4010208@netconfcentral.com> Date: Fri, 14 Aug 2009 09:38:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: David Reid References: <200908141542.LAA26959@adminfs.snmp.com> In-Reply-To: <200908141542.LAA26959@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] staying in synch on data model discovery 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: Fri, 14 Aug 2009 16:36:31 -0000 David Reid wrote: >> But you advertise your deviations module, and include the revision >> there: >> >> urn:foo?module=foo&revision=2009-01-01?deviations=bar >> urn:bar?module=bar&revision=2009-04-01 >> >> So even if the bar module exists in multiple revisions (this would >> happen if bar contains deviations AND reusable typedefs / groupings, >> and some other modules import bar by different revision...), only one >> is implemented by the device. We do not support that you advertise >> multiple versions of a module with data nodes and / or deviations. >> > > I want to make sure I understand this. Does this mean that it would be > invalid for a netconf server to support 2 different revisions of the > same yang module. For example: > > urn:foo?module=foo&revision=2008-04-05 > urn:foo?module=foo&revision=2009-01-01 > This would violate the entire purpose of import-by-revision. YANG tools need to deal with multiple revisions, and that includes the manager. The manager is going to check its local module-store for module=foo, revision=xxx, based on each individual capability URI. If not found, or the namespace statement does not match the module capability, then it is going to use to retrieve any missing files. Finally, it is going to attempt to compile and use the entire set of modules and deviations and enable the features that the agent advertised. Through hardwired code, it is going to figure out what it can from the particular combination of standard capabilities advertised for the session. Then the manager has the same exact view of the schema tree as the agent. This used to sometimes take NMS developers many person-years to get right with SNMP. Now it takes about 100 milli-seconds with NETCONF. That's why is so important and data silos are so evil. The agent must advertise everything it has. The manager must first figure out what the agent has, rather than build its 'agent view' incrementally. (tips from somebody who coded it wrong the first time...) > -David Reid > Andy From cfinss@dial.pipex.com Fri Aug 14 11:29: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 662913A6C2A for ; Fri, 14 Aug 2009 11:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 8nkUMSzZxXDC for ; Fri, 14 Aug 2009 11:29:57 -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 E5B6A3A6817 for ; Fri, 14 Aug 2009 11:29:56 -0700 (PDT) X-Trace: 131349494/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.187/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.187 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: Aq8EAF5JhUo+vGS7/2dsb2JhbACDMEIgjHrCdQmEEAWCKQ X-IronPort-AV: E=Sophos;i="4.43,381,1246834800"; d="scan'208";a="131349494" X-IP-Direction: IN Received: from 1cust187.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.187]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Aug 2009 19:29:59 +0100 Message-ID: <000e01ca1d04$b8422de0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Martin Bjorklund" References: <4A8455F8.3070509@netconfcentral.com><20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> Date: Fri, 14 Aug 2009 19:28:18 +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] leafref problems 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: Fri, 14 Aug 2009 18:29:58 -0000 Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Thursday, August 13, 2009 10:33 PM Subject: Re: [netmod] leafref problems > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> From yang-07, sec. 9.9.2 > >> > >> The "path" XPath expression is conceptually evaluated in the > >> following context, in addition to the definition in Section 6.4.1: > >> > >> o The context node is the node in the data tree for which the "path" > >> statement is defined. > >> > >> > >> The accessible tree depends on the context node: > >> > >> o If the leaf with the instance-identifier type represents > >> configuration data, the tree is the data in one of the NETCONF > >> datastores. The XPath root node has all top-level configuration > >> data nodes in all modules as children. > >> > >> o Otherwise the tree is all state data on the device, and the > >> datastore. The XPath root node has all top-level data > >> nodes in all modules as children. > >> > >> 1) this must be a bug, because it discusses the i-i type > >> in the section about the leafref builtin type. > > > > Yes, fixed in the upcoming -08. > > > > this needs to be changed for for i-i too, because that is just > as bad, and confusing. Sometimes an i-i points > to the , sometimes to the , > sometimes to candidate, sometimes to running, > sometimes who knows where because the target > is specified in a description clause. > > pg 132: > > o If the leaf with the instance-identifier type represents > configuration data, the tree is the data in one of the NETCONF > datastores. The XPath root node has all top-level configuration > data nodes in all modules as children. > > Does the operation check > the leafrefs against the candidate, and > checks them against the running config? > Or does the agent do whatever it wants? > Which "one of the NETCONF datastores" does an i-i represent? > This is very confusing. > > IMO, i-i should have a static format: > > /nc:rpc/... --> in the PDU > /nc:rpc-reply/... --> in the PDU > /ncn:notification/... --> in the PDU > > Everything else --> top-level node in the database > or conceptual state data available with > > The i-i data type is an absolute path expression, > so the parent context is irrelevant. > > >> 3) There are no compelling use-cases for including leafref objects > >> in the database. > > > > Haven't we had this discussion several times before? Are you now > > suggesting that no leafref type whatsoever is needed, or are you > > (still) concerned with leafref to non-key leafs? > > > > The recent issues I raised were discussed before and > resolved? I do not remember that. What was the resolution > to each issue? > An alternative view. 1) Balazs flagged this bug soon after -07 appeared (and I updated my copy as a result) 2) leafref in union is prohibited in s.9.12; I cannot recall any discussion on this. 3) there was a lengthy discussion on leafref and its use cases commencing in May 2009, triggered by Joel saying, most circumspectly, that it was incomprehensible (at least, that is what I thought). Andy came up with five use cases, expanded to six then contracted back to five. I pointed out that it was Andy in a similar thread in September who argued that leafref was needed, not just keyref. As is all too often the case on this list, it is very hard, for me at least, to understand what the consensus of this thread was (and I have re-read it at least five times, including, coincidentally, this week and last), even on the inclusion of require-instance; only when the I-D came out did I think that the consensus had been for require-instance to be dropped from leafref. Balazs en passant said it would be helpful if some clear statements made then were included in the I-D, but, sadly, they were not. Joel's characterisations I found helpful, again not included. So what was the consensus of that thread? I am unsure. What does the I-D tell me? Again, in several places, I am unsure. 4) is a new one on me, although mandatory, in general, is another of those topics which come up regularly, without a consensus that I can discern. If, as Joel/Balazs suggested, leafref constrains type and value, then a leafref to a non-existent node means: either there are no constraints, anything goes or the constraint is total, the leafref is also non-existent "All leafref nodes MUST reference existing leaf instances for the data to be valid" suggests the latter. Tom Petch > > > > /martin > > > > Andy From andy@netconfcentral.com Fri Aug 14 12:19: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 24E7628C1C1 for ; Fri, 14 Aug 2009 12:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 UZASpKGB-uAn for ; Fri, 14 Aug 2009 12:19:23 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 67F2F28C1B1 for ; Fri, 14 Aug 2009 12:19:08 -0700 (PDT) Received: (qmail 11427 invoked from network); 14 Aug 2009 19:19:11 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.61 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 19:19:10 -0000 X-YMail-OSG: DTYl3UkVM1kLmdOio0IIeQQ2EaQxdYrKcgQmwt7D30O4JQ40zTfeD4d2fDHQkTGfb08OQrmbl_6KDz7uTRUDIo4_ELKNjVvOcsPm0xp.6vVMDAW_1XbO5rNo17LAkb7kmjfTSmzI12VMzKoLjD.M.ooREWw3ZiTOuqLjl4ETfSTRt84cC2j7pD5YGKj2prMlQO.heQ_MPdmeg4qpcKwJER4HMLsl.sLuvzqHy3Md_TH_H2_2iDkbqNd_YgRTubNHN1V8k8IR17nwEq1NcE9TFJOz44PQ7Ws5uzjjQVnkdtTM8S7Jztg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A85B916.2070009@netconfcentral.com> Date: Fri, 14 Aug 2009 12:20:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "tom.petch" References: <4A8455F8.3070509@netconfcentral.com><20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> In-Reply-To: <000e01ca1d04$b8422de0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Fri, 14 Aug 2009 19:19:24 -0000 tom.petch wrote: ... > An alternative view. > > 1) Balazs flagged this bug soon after -07 appeared (and I updated my copy as a > result) > resolved > 2) leafref in union is prohibited in s.9.12; I cannot recall any discussion on > this. resolved > > 3) there was a lengthy discussion on leafref and its use cases commencing in May > 2009, triggered by Joel saying, most circumspectly, that it was incomprehensible > (at least, that is what I thought). Andy came up with five use cases, expanded > to six then contracted back to five. I pointed out that it was Andy in a > similar thread in September who argued that leafref was needed, not just keyref. > > As is all too often the case on this list, it is very hard, for me at least, to > understand what the consensus of this thread was (and I have re-read it at least > five times, including, coincidentally, this week and last), even on the > inclusion of require-instance; only when the I-D came out did I think that the > consensus had been for require-instance to be dropped from leafref. Balazs en > passant said it would be helpful if some clear statements made then were > included in the I-D, but, sadly, they were not. Joel's characterisations I > found helpful, again not included. > > So what was the consensus of that thread? I am unsure. What does the I-D tell > me? Again, in several places, I am unsure. > I don't want to go over use-cases again. All discussion of implementation details is kind of irrelevant because it is too subjective. But a manager needs to know what to expect from an agent wrt/ all aspects of YANG, and leafref is no exception there. > 4) is a new one on me, although mandatory, in general, is another of those > topics which come up regularly, without a consensus that I can discern. If, as > Joel/Balazs suggested, leafref constrains type and value, then a leafref to a > non-existent node means: > either there are no constraints, anything goes > or the constraint is total, the leafref is also non-existent > I have about 5 warnings in yangdump related to this. I want them all to be fatal errors instead. The agent will use a module with warnings, but not errors. There are 2 new issues not resolved: 1) YANG compile time: any possible scenario in which any path statement may not be valid in every possible compliant agent implementation MUST be considered a fatal error. The draft needs to make this clear. 2) agent run time: - What to do when the agent has a leafref object with an invalid path statement? - What to do at the time the deviation 'not-supported' removes the pointed-at object? - What to do if a dynamic if-feature or when statement changes from true to false, with leafrefs pointing at the newly removed leaf? > "All leafref nodes MUST reference > existing leaf instances for the data to be valid" > suggests the latter. So what happens to the pointing-leaf in the running config when the pointed-at leaf goes away? The running config cannot be invalid, but it is. So the agent must iterate through a pruning process, to make sure that each time it removes a dead leafref that it is OK to do that, and no other leafrefs now need to be pruned as well. Or the agent can shutdown I guess, but it cannot have an invalid running config. > Tom Petch > >>> /martin >>> >> Andy > > Andy From mbj@tail-f.com Fri Aug 14 13:41: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 A3BFE3A6AB1 for ; Fri, 14 Aug 2009 13:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.159, 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 LbgpfgFXZSjP for ; Fri, 14 Aug 2009 13:41:04 -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 2FFDF3A689A for ; Fri, 14 Aug 2009 13:41:04 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C89B76C4D1; Fri, 14 Aug 2009 22:41:07 +0200 (CEST) Date: Fri, 14 Aug 2009 22:41:06 +0200 (CEST) Message-Id: <20090814.224106.175526822.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A85B916.2070009@netconfcentral.com> References: <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> <4A85B916.2070009@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] leafref problems 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: Fri, 14 Aug 2009 20:41:05 -0000 Andy Bierman wrote: > > 4) is a new one on me, although mandatory, in general, is another of those > > topics which come up regularly, without a consensus that I can discern. If, > > as > > Joel/Balazs suggested, leafref constrains type and value, then a leafref to a > > non-existent node means: > > either there are no constraints, anything goes > > or the constraint is total, the leafref is also non-existent > > > > I have about 5 warnings in yangdump related > to this. I want them all to be fatal errors > instead. The agent will use a module with warnings, > but not errors. > > There are 2 new issues not resolved: > 1) YANG compile time: > any possible scenario in which any path statement > may not be valid in every possible compliant agent > implementation MUST be considered a fatal error. > The draft needs to make this clear. Please send me some suggestion for text to include! > 2) agent run time: > - What to do when the agent has a leafref object > with an invalid path statement? Such a config is not valid. It doesn't spontaneously happen - it happens b/c an operator tries to modify the config. This request must be rejected, just as a request that would invalidate a must constraint. > - What to do at the time the deviation 'not-supported' > removes the pointed-at object? We had a proposal to state that the module must still be valid after applying deviation statements. But noone commented so it wasn't included. And I'm not convinced it is needed - deviations are supposed to document what an implementation did, and it won't be possible to implement this, as you noted. > - What to do if a dynamic if-feature or when statement > changes from true to false, with leafrefs pointing at the > newly removed leaf? If a when statement changes to false, this is also an effect of an operator modifying the config, which must be rejected. > > "All leafref nodes MUST reference > > existing leaf instances for the data to be valid" > > suggests the latter. > > So what happens to the pointing-leaf in the > running config when the pointed-at leaf goes away? > The running config cannot be invalid, but it is. Again, the pointed-at leaf won't just "go away". It goes away when a client deletes it, and that will be an error. /martin From andy@netconfcentral.com Fri Aug 14 16:33: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 0925B3A6A4F for ; Fri, 14 Aug 2009 16:33: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 EqJMXHt86dEC for ; Fri, 14 Aug 2009 16:33:27 -0700 (PDT) Received: from n8a.bullet.mail.mud.yahoo.com (n8a.bullet.mail.mud.yahoo.com [209.191.87.104]) by core3.amsl.com (Postfix) with SMTP id F05023A6765 for ; Fri, 14 Aug 2009 16:33:26 -0700 (PDT) Received: from [209.191.108.97] by n8.bullet.mail.mud.yahoo.com with NNFMP; 14 Aug 2009 23:33:29 -0000 Received: from [68.142.201.254] by t4.bullet.mud.yahoo.com with NNFMP; 14 Aug 2009 23:33:29 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 14 Aug 2009 23:33:29 -0000 X-Yahoo-Newman-Id: 857741.38880.bm@omp415.mail.mud.yahoo.com Received: (qmail 6446 invoked from network); 14 Aug 2009 23:33:29 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2009 23:33:28 -0000 X-YMail-OSG: Onc0v.wVM1kyt75H1orKXfMD41B_y.XhdfuFsJRg_thqK3FrIj2Q0HHE6xe.D02LpVaAzv2H15ZUDh0pKLKJe0nYr3gAD6xBk0V2pFfyRyE6RzcGuccDzw2WKc5G1Py_oxFr9cT71uDpSfLeYVu4qVXvNP7uXSreopzkwL9WCQQ09Bv6uzzIuEtl9bhfb7FociACrA8aB9cZwxfTsdN8HNpvcVT1rZK_pztTlveE73NXEH5ps4dlkEp_CslXp9kqVctFbdt9ICMZiHuxhl2scc6azS_8fLrd1G6npiD7hVrQwDAq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A85F449.1020901@netconfcentral.com> Date: Fri, 14 Aug 2009 16:33:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> <4A85B916.2070009@netconfcentral.com> <20090814.224106.175526822.mbj@tail-f.com> In-Reply-To: <20090814.224106.175526822.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Fri, 14 Aug 2009 23:33:28 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>> 4) is a new one on me, although mandatory, in general, is another of those >>> topics which come up regularly, without a consensus that I can discern. If, >>> as >>> Joel/Balazs suggested, leafref constrains type and value, then a leafref to a >>> non-existent node means: >>> either there are no constraints, anything goes >>> or the constraint is total, the leafref is also non-existent >>> >> I have about 5 warnings in yangdump related >> to this. I want them all to be fatal errors >> instead. The agent will use a module with warnings, >> but not errors. >> >> There are 2 new issues not resolved: >> 1) YANG compile time: >> any possible scenario in which any path statement >> may not be valid in every possible compliant agent >> implementation MUST be considered a fatal error. >> The draft needs to make this clear. > > Please send me some suggestion for text to include! > (Here's what yangdump checks anyway -- maybe there is more to it than this...) leafref node ==> leaf containing a leafref type target leaf ==> leaf pointed at by a leafref path statement The leafref node cannot be more conditional than the target leaf. The following restrictions apply: - if the leafref is mandatory, then the target leaf SHOULD be mandatory as well. Managers need to make sure that an instance of the target leaf is present, or the leafref will not be valid. - if any if-feature statements apply to the leafref node, then they MUST also apply to the target leaf. - A when statement can apply to the leafref or target node in 3 ways (direct, inherited from all uses, inherited from augment). The conceptual AND expression formed from these 3 XPath expressions MUST be identical in the leafref and target leafs. >> 2) agent run time: >> - What to do when the agent has a leafref object >> with an invalid path statement? > > Such a config is not valid. It doesn't spontaneously happen - it > happens b/c an operator tries to modify the config. This request must > be rejected, just as a request that would invalidate a must constraint. > you are right. this is no different than if the startup config loaded into running is invalid. The agent needs to deal somehow with this situation already. I would like there to be a standard way for an agent to deal with a "good running config gone bad". >> - What to do at the time the deviation 'not-supported' >> removes the pointed-at object? > > We had a proposal to state that the module must still be valid after > applying deviation statements. But noone commented so it wasn't > included. And I'm not convinced it is needed - deviations are > supposed to document what an implementation did, and it won't be > possible to implement this, as you noted. > >> - What to do if a dynamic if-feature or when statement >> changes from true to false, with leafrefs pointing at the >> newly removed leaf? > > If a when statement changes to false, this is also an effect of an > operator modifying the config, which must be rejected. > maybe not the operator, but it does not matter. the agent either has an internal or external trigger to re-check the config, and the problem will be dealt with at that time. >>> "All leafref nodes MUST reference >>> existing leaf instances for the data to be valid" >>> suggests the latter. >> So what happens to the pointing-leaf in the >> running config when the pointed-at leaf goes away? >> The running config cannot be invalid, but it is. > > Again, the pointed-at leaf won't just "go away". It goes away when a > client deletes it, and that will be an error. > I know the pointed-at leaf will go away. So does the operator. But the operator may be astonished when the deleted-node ripple affect deletes other nodes, not just the first one. Side effects like this (and unlock(candidate) == discard-changes) may cause the tech-support phone to ring a lot, and we don't want that, do we? > > /martin > Andy From Washam.Fan@huaweisymantec.com Sat Aug 15 06: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 7DEB43A697B for ; Sat, 15 Aug 2009 06:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.683 X-Spam-Level: X-Spam-Status: No, score=0.683 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_50=0.001] 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 rKjeGsycUNlF for ; Sat, 15 Aug 2009 06:13:47 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id A7A023A69FF for ; Sat, 15 Aug 2009 06:13:47 -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.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KOF00GZX62H6040@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Sat, 15 Aug 2009 21:13:29 +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 <0KOF009R062HEH10@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Sat, 15 Aug 2009 21:13:29 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sat, 15 Aug 2009 21:13:29 +0800 From: WashamFan To: "tom.petch" Message-id: Date: Sat, 15 Aug 2009 21:13:29 +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: <000e01ca1d04$b8422de0$0601a8c0@allison> References: <4A8455F8.3070509@netconfcentral.com> <20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Sat, 15 Aug 2009 13:13:48 -0000 Hi, > 4) is a new one on me, although mandatory, in general, is another of those > topics which come up regularly, without a consensus that I can > discern. If, as > Joel/Balazs suggested, leafref constrains type and value, then a > leafref to a > non-existent node means: > either there are no constraints, anything goes > or the constraint is total, the leafref is also non-existent > > "All leafref nodes MUST reference > existing leaf instances for the data to be valid" > suggests the latter. > Tom Petch +1 That is the exact way I understand leafref. A leafref pointing to a non-existent node is invalid. And the removal of targeted-at node either cause the leafref to be deleted or the removal request is rejected at the beginning, IMO. washam From andy@netconfcentral.com Sat Aug 15 06:33:17 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 EC9B63A6B84 for ; Sat, 15 Aug 2009 06:33:17 -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 eWdzXh-V+foB for ; Sat, 15 Aug 2009 06:33:17 -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 5F41C3A6A34 for ; Sat, 15 Aug 2009 06:33:17 -0700 (PDT) Received: (qmail 30779 invoked from network); 15 Aug 2009 13:33:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 15 Aug 2009 13:33:19 -0000 X-YMail-OSG: kAy645kVM1m3gPSBlIb7C0_63f3l2KBq4QTXKICqeB7WTggLGOUxGH4SC224pqazpyV6ZT0T37y03SUNttIddDs7yWxguyWbEOWXOx7gvuSZoOF.YyPkoM6PDSe9TWgDSTHCPFks6tuI4fkIVeBA_XI1YM2OpOebdRHXUz6LX4d1Ss1C_HIH7_MiqERGVhEITDXh1rBGfhgTLWt04pzVZjVafd8.f8Sk3YEMHn1y7BDjWFBhAYPxAzfODDWcuuFIDTqkFNhdiKniu0E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A86B922.7070700@netconfcentral.com> Date: Sat, 15 Aug 2009 06:33:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A8455F8.3070509@netconfcentral.com> <20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Sat, 15 Aug 2009 13:33:18 -0000 WashamFan wrote: > Hi, > >> 4) is a new one on me, although mandatory, in general, is another of those >> topics which come up regularly, without a consensus that I can >> discern. If, as >> Joel/Balazs suggested, leafref constrains type and value, then a >> leafref to a >> non-existent node means: >> either there are no constraints, anything goes >> or the constraint is total, the leafref is also non-existent >> >> "All leafref nodes MUST reference >> existing leaf instances for the data to be valid" >> suggests the latter. >> Tom Petch > > +1 > That is the exact way I understand leafref. A leafref pointing to > a non-existent node is invalid. And the removal of targeted-at > node either cause the leafref to be deleted or the removal request > is rejected at the beginning, IMO. > with 'deviate not-supported', there is no manager request. what about that one? > washam > Andy From andy@netconfcentral.com Sat Aug 15 09:12: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 34F5728C24B for ; Sat, 15 Aug 2009 09:12:38 -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 UjsMIXB2mlLO for ; Sat, 15 Aug 2009 09:12:37 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 4916728C24C for ; Sat, 15 Aug 2009 09:12:37 -0700 (PDT) Received: (qmail 95182 invoked from network); 15 Aug 2009 16:12:36 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 15 Aug 2009 16:12:36 -0000 X-YMail-OSG: .pV2QZkVM1kSMqkOFfHWFNE88zhmLPgZq2z6Ao49CTizYIvFgxYMeiKomaTIZXbfb_Oy0Ep1WlDtmEBCV3y9tpOyeHni.uIm6RcuEH_xFSIAvQByUH8D8XospHcrpioM26UzecVbo_HTcguHW42FdwgNZB521Hpjmc52pvulTjfRXeUe_rGzQn7rtzVhFUHWOPcxrCQ50JE1VBZHjolvdX3YC2KZStdB.iUL8FZ_CGB117aXc6NoYDFF9miDuj7RyFTToTeq3WJkG1huBUy7.2A4cnpYb4SwuGvjkh0X2xxsg178x1QgL9UxpSHW X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A86DE78.8080906@netconfcentral.com> Date: Sat, 15 Aug 2009 09:12:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A8455F8.3070509@netconfcentral.com> <20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> <4A86B922.7070700@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Sat, 15 Aug 2009 16:12:38 -0000 WashamFan wrote: > Hi, > > ----- Original Message ----- > From: Andy Bierman > Date: Saturday, August 15, 2009 9:34 pm > Subject: Re: [netmod] leafref problems > To: WashamFan > Cc: "tom.petch" , Martin Bjorklund , netmod@ietf.org > > >> WashamFan wrote: >>> Hi, >>> >>>> 4) is a new one on me, although mandatory, in general, is another >> of those >>>> topics which come up regularly, without a consensus that I can >>>> discern. If, as >>>> Joel/Balazs suggested, leafref constrains type and value, then a >>>> leafref to a >>>> non-existent node means: >>>> either there are no constraints, anything goes >>>> or the constraint is total, the leafref is also non-existent >>>> >>>> "All leafref nodes MUST reference >>>> existing leaf instances for the data to be valid" >>>> suggests the latter. >>>> Tom Petch >>> +1 >>> That is the exact way I understand leafref. A leafref pointing to >>> a non-existent node is invalid. And the removal of targeted-at >>> node either cause the leafref to be deleted or the removal request >>> is rejected at the beginning, IMO. >>> So some agents will magically delete extra nodes and others will reject the request? Can we pick one standard agent behavior here? >> with 'deviate not-supported', there is no manager request. >> what about that one? >> > > IMO, The action to remove the targeted-at node would delete > the leafref node either regardless of the manager or system > trigger the action. Otherwise, the datastore would be invalid. > so what is the text for the one standard agent behavior for this situation? > washam > Andy From Washam.Fan@huaweisymantec.com Sat Aug 15 09:52: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 AF8F23A6B6F for ; Sat, 15 Aug 2009 09:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[AWL=0.589, 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 dIupAQiCR3eW for ; Sat, 15 Aug 2009 09:52:41 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id E0A6C3A6A16 for ; Sat, 15 Aug 2009 09:52:40 -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 <0KOF00E15DDHPT10@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Sat, 15 Aug 2009 23:51:17 +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 <0KOF00AY1DDHJ910@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Sat, 15 Aug 2009 23:51:17 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sat, 15 Aug 2009 23:51:17 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sat, 15 Aug 2009 23:51:17 +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: <4A86B922.7070700@netconfcentral.com> References: <4A8455F8.3070509@netconfcentral.com> <20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> <4A86B922.7070700@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Sat, 15 Aug 2009 16:52:41 -0000 Hi, ----- Original Message ----- From: Andy Bierman Date: Saturday, August 15, 2009 9:34 pm Subject: Re: [netmod] leafref problems To: WashamFan Cc: "tom.petch" , Martin Bjorklund , netmod@ietf.org > WashamFan wrote: > > Hi, > > > >> 4) is a new one on me, although mandatory, in general, is another > of those > >> topics which come up regularly, without a consensus that I can > >> discern. If, as > >> Joel/Balazs suggested, leafref constrains type and value, then a > >> leafref to a > >> non-existent node means: > >> either there are no constraints, anything goes > >> or the constraint is total, the leafref is also non-existent > >> > >> "All leafref nodes MUST reference > >> existing leaf instances for the data to be valid" > >> suggests the latter. > >> Tom Petch > > > > +1 > > That is the exact way I understand leafref. A leafref pointing to > > a non-existent node is invalid. And the removal of targeted-at > > node either cause the leafref to be deleted or the removal request > > is rejected at the beginning, IMO. > > > > with 'deviate not-supported', there is no manager request. > what about that one? > IMO, The action to remove the targeted-at node would delete the leafref node either regardless of the manager or system trigger the action. Otherwise, the datastore would be invalid. washam From Washam.Fan@huaweisymantec.com Sat Aug 15 18:51: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 75D853A6C1D for ; Sat, 15 Aug 2009 18:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=0.392, 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 R1M9PRf850TW for ; Sat, 15 Aug 2009 18:51:49 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id AAF293A6861 for ; Sat, 15 Aug 2009 18:51:49 -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 <0KOG00ENI55NPT40@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Sun, 16 Aug 2009 09:51:24 +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 <0KOG00FSV55N0W00@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Sun, 16 Aug 2009 09:51:23 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sun, 16 Aug 2009 09:51:23 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sun, 16 Aug 2009 09:51:23 +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: <4A86DE78.8080906@netconfcentral.com> References: <4A8455F8.3070509@netconfcentral.com> <20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> <4A86B922.7070700@netconfcentral.com> <4A86DE78.8080906@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Sun, 16 Aug 2009 01:51:50 -0000 Hi, > >>>> 4) is a new one on me, although mandatory, in general, is another > > >> of those > >>>> topics which come up regularly, without a consensus that I can > >>>> discern. If, as > >>>> Joel/Balazs suggested, leafref constrains type and value, then a > > >>>> leafref to a > >>>> non-existent node means: > >>>> either there are no constraints, anything goes > >>>> or the constraint is total, the leafref is also non-existent > >>>> > >>>> "All leafref nodes MUST reference > >>>> existing leaf instances for the data to be valid" > >>>> suggests the latter. > >>>> Tom Petch > >>> +1 > >>> That is the exact way I understand leafref. A leafref pointing to > >>> a non-existent node is invalid. And the removal of targeted-at > >>> node either cause the leafref to be deleted or the removal request > >>> is rejected at the beginning, IMO. > >>> > > So some agents will magically delete extra nodes and others will > reject the request? Can we pick one standard agent behavior here? Then, I'd like pick the former. > >> with 'deviate not-supported', there is no manager request. > >> what about that one? > >> > > > > IMO, The action to remove the targeted-at node would delete > > the leafref node either regardless of the manager or system > > trigger the action. Otherwise, the datastore would be invalid. > > > > so what is the text for the one standard agent behavior > for this situation? My interpretation, the referenced leaf defines the value constraint for the corresponding referencing leaf. The value constraint would change with the referenced leaf. When the referenced leaf is gone (regardless of who trigger it), the constraint is total, which means, the referencing leaf's gone with it. So, IMO, there might be something like that: With regard to any attempt (manager request, execution of 'not support' deviation,etc.) to remove a leaf which is referenced by another leaf via leafref, the referencing leaf would be deleted automatically with the referenced leaf, if the attempt succeeds. washam From cfinss@dial.pipex.com Sun Aug 16 02:32: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 C46123A6D60 for ; Sun, 16 Aug 2009 02:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001] 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 7gki6XUs4scP for ; Sun, 16 Aug 2009 02:32:53 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D369E3A6D52 for ; Sun, 16 Aug 2009 02:32:52 -0700 (PDT) X-Trace: 276367160/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.226/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.226 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: ApwEAKJvh0o+vGTi/2dsb2JhbACDMI1kwAcJhBAFgik X-IronPort-AV: E=Sophos;i="4.43,389,1246834800"; d="scan'208";a="276367160" X-IP-Direction: IN Received: from 1cust226.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.226]) by smtp.pipex.tiscali.co.uk with SMTP; 16 Aug 2009 10:32:43 +0100 Message-ID: <002c01ca1e4b$fdd29fa0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A853A60.1040809@netconfcentral.com><20090814.131943.195753685.mbj@tail-f.com><4A856559.4040402@netconfcentral.com> <20090814.153232.162557664.mbj@tail-f.com> Date: Sun, 16 Aug 2009 10:18:40 +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: [netmod] Terminology2 was Re: leafref problems 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: Sun, 16 Aug 2009 09:32:53 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Friday, August 14, 2009 3:32 PM Subject: Re: [netmod] leafref problems > Andy Bierman wrote: > > > I propose the following change (and similar for the other case; > > > must/when/path): > > > > > > OLD: > > > > > > - If this leaf represents configuration data, the tree is the data in > > > one of the NETCONF datastores. The XPath root node has all > > > top-level configuration data nodes in all modules as children. > > > > > > NEW: > > > > > > - If this leaf represents configuration data, the tree is the data in > > > the NETCONF datastore where the leaf exists. The XPath root node > > > has all top-level configuration data nodes in all modules as > > > children. > > > 'top-level' appears many times in the i-d and I would like to see the meaning better nailed down . It could refer to the substatements immediately below a module statement. It could be extended to the substatements immediately below the submodule statement of an included submodule. Since the reference, as here, is frequently to top-level data nodes, it could be read as any data node which has no other data node between it and the module statement so that in module m {grouping g { leaf x ... then x is regarded as top-level Or ... I would like this clarified, here and in the I-D Tom Petch From andy@netconfcentral.com Sun Aug 16 12:36: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 8CE733A6D1A for ; Sun, 16 Aug 2009 12:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 WXcRXVUFfo3d for ; Sun, 16 Aug 2009 12:36:53 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id A6B5C28C10F for ; Sun, 16 Aug 2009 12:36:53 -0700 (PDT) Received: (qmail 97168 invoked from network); 16 Aug 2009 19:36:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 16 Aug 2009 19:36:56 -0000 X-YMail-OSG: m1npGXsVM1n_kmqY6EsBkCiU4PyjuopHp7hhov.NXnFosIvdi3CAfdBjXaUxX9PgEHRZSpjXvGMmKGFqdcy8t3M11AEjYeuvPDJ9EzL4JCCo7CQWioaQ0vIOTpRIART_ngBAvkX7693xpFIo5v.jxAxr0QB0wnV0zLcq_RuyXqPto3lGUc0z.9nN2rboM4vXyvZEr2l4R.iwFPlnp9w8sKgahfvbBpQvCpNRBm5dc6u0HYxELdDJN63PgXAPWpvtDnfwd25B8H2nYiCst8YdLqne6B2aS95yWaLYGS0xm_Df2BbIS4c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A885FE3.1040007@netconfcentral.com> Date: Sun, 16 Aug 2009 12:37:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A8455F8.3070509@netconfcentral.com> <20090813.221318.55822339.mbj@tail-f.com> <4A847880.2030808@netconfcentral.com> <000e01ca1d04$b8422de0$0601a8c0@allison> <4A86B922.7070700@netconfcentral.com> <4A86DE78.8080906@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Sun, 16 Aug 2009 19:36:54 -0000 WashamFan wrote: > Hi, > >>>>>> 4) is a new one on me, although mandatory, in general, is another >>>> of those >>>>>> topics which come up regularly, without a consensus that I can >>>>>> discern. If, as >>>>>> Joel/Balazs suggested, leafref constrains type and value, then a >>>>>> leafref to a >>>>>> non-existent node means: >>>>>> either there are no constraints, anything goes >>>>>> or the constraint is total, the leafref is also non-existent >>>>>> >>>>>> "All leafref nodes MUST reference >>>>>> existing leaf instances for the data to be valid" >>>>>> suggests the latter. >>>>>> Tom Petch >>>>> +1 >>>>> That is the exact way I understand leafref. A leafref pointing to >>>>> a non-existent node is invalid. And the removal of targeted-at >>>>> node either cause the leafref to be deleted or the removal request >>>>> is rejected at the beginning, IMO. >>>>> >> So some agents will magically delete extra nodes and others will >> reject the request? Can we pick one standard agent behavior here? > > Then, I'd like pick the former. > OK -- I'll go with that. Whenever possible, pick the least astonishing choice, and since when-stmt, case-stmt, and NP containers can disappear as a side-effect, this should as well. For the most common use-case (foreign key), this is what you want. You delete the main table entry, and all the sub-ordinate entries get deleted as well. If these other tables were nested within the main table the way they should be, that is also what would happen. >>>> with 'deviate not-supported', there is no manager request. >>>> what about that one? >>>> >>> IMO, The action to remove the targeted-at node would delete >>> the leafref node either regardless of the manager or system >>> trigger the action. Otherwise, the datastore would be invalid. >>> >> so what is the text for the one standard agent behavior >> for this situation? > > My interpretation, the referenced leaf defines the value > constraint for the corresponding referencing leaf. The value > constraint would change with the referenced leaf. When the > referenced leaf is gone (regardless of who trigger it), the > constraint is total, which means, the referencing leaf's gone > with it. > > So, IMO, there might be something like that: > > With regard to any attempt (manager request, execution of > 'not support' deviation,etc.) to remove a leaf which is referenced > by another leaf via leafref, the referencing leaf would be deleted > automatically with the referenced leaf, if the attempt succeeds. > a bit confusing, but Martin will fix it :-) for deviate not-supported, there is no request and maybe this will succeed. If the syntax is valid, the agent is declaring a module patch, and all leafrefs pointing at this leaf are also not supported and will be removed. > washam > Andy From Washam.Fan@huaweisymantec.com Sun Aug 16 19:10: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 4EF733A6B0D for ; Sun, 16 Aug 2009 19:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_40=-0.185] 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 EYRdTxQz-yG6 for ; Sun, 16 Aug 2009 19:10:15 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 4F9093A6842 for ; Sun, 16 Aug 2009 19:10:15 -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 <0KOI00DZS0OMPH10@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Mon, 17 Aug 2009 10:09:58 +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 <0KOI00AVN0OMWB00@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Mon, 17 Aug 2009 10:09:58 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 17 Aug 2009 10:09:58 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 17 Aug 2009 10:09:58 +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: <4A82DC87.6000302@netconfcentral.com> References: <4A82DC87.6000302@netconfcentral.com> Cc: NETMOD Working Group Subject: Re: [netmod] CLR request 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: Mon, 17 Aug 2009 02:10:16 -0000 Hi, > I have some early implementation experience that suggests > that 2 specific corner-cases are very hard to implement > correctly in the agent protocol stack: > > 1) leafref chains (leafref points to leafref points to ...) > 2) leafrefs that point to instance-identifiers Why these are special cases? In 1), let assume leafref leaf A points to leafref leaf B points to leaf C, then A's value space would be constrained by B only, A doesn't need to care about C. In 2), why instance-identifier leaf is special? It could be interpreted as a string leaf with 'XPath like' value. I did not do relevant implementation yet. So, I am sorry if I miss somthing. washam From andy@netconfcentral.com Mon Aug 17 01:02: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 11AB928B797 for ; Mon, 17 Aug 2009 01:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 gTT0apHe3rUl for ; Mon, 17 Aug 2009 01:02:51 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 3EA883A6C2C for ; Mon, 17 Aug 2009 01:02:51 -0700 (PDT) Received: (qmail 56436 invoked from network); 17 Aug 2009 08:02:54 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 17 Aug 2009 08:02:54 -0000 X-YMail-OSG: FbslgmYVM1n1I4_cP.R.6lx4Bx45mx2chrP9GKb7sT10wWDbnfc344gmAJKq8OFGrS2iGteRKWfLBtdVUqsvrlntkbmMpSv.wQOYHFdUvdhuAHX_35wEvVys7C_3JCNxGYfHpDT6qlYWkfDoWv90foMWairPIOP7yY0XnuNqMOvD15bbiOEwNRuJ3YzTp6CW9gy1.IYDRz63F8amTjxpEIPcCfCedno.LsB0ns6iQvuu4uizJkXmcq4iqT3RgtjyVVsA4W7yiqV8ZslcZUTWGq5Pc9_OKazCumRxr7791eIrh5Oddv0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A890EBC.4020508@netconfcentral.com> Date: Mon, 17 Aug 2009 01:03:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A82DC87.6000302@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] CLR request 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: Mon, 17 Aug 2009 08:02:52 -0000 WashamFan wrote: > Hi, > >> I have some early implementation experience that suggests >> that 2 specific corner-cases are very hard to implement >> correctly in the agent protocol stack: >> >> 1) leafref chains (leafref points to leafref points to ...) >> 2) leafrefs that point to instance-identifiers > > Why these are special cases? > In 1), let assume leafref leaf A points to leafref leaf B points to > leaf C, then A's value space would be constrained by B only, A > doesn't need to care about C. > In 2), why instance-identifier leaf is special? It could be interpreted > as a string leaf with 'XPath like' value. > > I did not do relevant implementation yet. So, I am sorry if I miss > somthing. > we are not concerned with the implementation complexity of YANG, so you didn't miss anything. Every little YANG detail is wonderful and important and easy to code... > washam > Andy From mbj@tail-f.com Mon Aug 17 01:39: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 AB22F3A6950 for ; Mon, 17 Aug 2009 01:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.135, 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 6N+CszjwdWYn for ; Mon, 17 Aug 2009 01:39:26 -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 1FC943A6B69 for ; Mon, 17 Aug 2009 01:39:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B61F976C4E3; Mon, 17 Aug 2009 10:39:28 +0200 (CEST) Date: Mon, 17 Aug 2009 10:39:28 +0200 (CEST) Message-Id: <20090817.103928.125604250.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A85F449.1020901@netconfcentral.com> References: <4A85B916.2070009@netconfcentral.com> <20090814.224106.175526822.mbj@tail-f.com> <4A85F449.1020901@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] leafref problems 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: Mon, 17 Aug 2009 08:39:27 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> 1) YANG compile time: > >> any possible scenario in which any path statement > >> may not be valid in every possible compliant agent > >> implementation MUST be considered a fatal error. > >> The draft needs to make this clear. > > > > Please send me some suggestion for text to include! > > > > (Here's what yangdump checks anyway -- maybe there > is more to it than this...) > > leafref node ==> leaf containing a leafref type > target leaf ==> leaf pointed at by a leafref path statement > > > The leafref node cannot be more conditional than > the target leaf. > > The following restrictions apply: > - if the leafref is mandatory, then the target leaf > SHOULD be mandatory as well. Managers need to make > sure that an instance of the target leaf is present, > or the leafref will not be valid. According to this rule, would this model invalidate the SHOULD? list a { key x; leaf x { type int32; } } container b { presence "..."; leaf y { type leafref { path /a/x; } mandatory true; } } > - if any if-feature statements apply to the leafref node, > then they MUST also apply to the target leaf. Is this text clear enough to just include in the draft? Is it clear what it means that an "if-feature statement apply"? > - A when statement can apply to the leafref or target node > in 3 ways (direct, inherited from all uses, inherited from > augment). The conceptual AND expression formed > from these 3 XPath expressions MUST be identical > in the leafref and target leafs. How do you check if the conceptual expressions are identitical? If we really want to include text along these lines, it will require some effort to describe the logic in an interoperable way. > >> 2) agent run time: > >> - What to do when the agent has a leafref object > >> with an invalid path statement? > > > > Such a config is not valid. It doesn't spontaneously happen - it > > happens b/c an operator tries to modify the config. This request must > > be rejected, just as a request that would invalidate a must constraint. > > > > you are right. > this is no different than if the startup config > loaded into running is invalid. The agent needs to deal > somehow with this situation already. > > I would like there to be a standard way for an > agent to deal with a "good running config gone bad". But running won't just go bad - in fact running cannot go bad. So if the server gets an edit-config with removes a leaf that is referenced by a leafref, it will reply with a 'data-missing' error, with the error-app-tag 'instance-required' (see section 13.6). > >>> "All leafref nodes MUST reference > >>> existing leaf instances for the data to be valid" > >>> suggests the latter. > >> So what happens to the pointing-leaf in the > >> running config when the pointed-at leaf goes away? > >> The running config cannot be invalid, but it is. > > > > Again, the pointed-at leaf won't just "go away". It goes away when a > > client deletes it, and that will be an error. > > > > I know the pointed-at leaf will go away. > So does the operator. But the operator > may be astonished when the deleted-node ripple affect > deletes other nodes, not just the first one. There is no "deleted-node ripple effect". The delete on the first node will fail. /martin From andy@netconfcentral.com Mon Aug 17 01:48:14 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 EE1A228C16C for ; Mon, 17 Aug 2009 01:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 QKLjSgnnwQvp for ; Mon, 17 Aug 2009 01:48:13 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id D975A28C171 for ; Mon, 17 Aug 2009 01:48:12 -0700 (PDT) Received: (qmail 35510 invoked from network); 17 Aug 2009 08:48:15 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 17 Aug 2009 08:48:14 -0000 X-YMail-OSG: aWFA6OUVM1nrEoC.ePBdNix0ULuUc2n1JKoegWwLNEEhgg2XKkchZlW4ho2_lqN87UEUpfYrED2AndS6veL8T7V5xWoTu9NAurpwV1g9dyV4Z7j82i7wzodtinjZg5UgfTdvpCNeIm8x7UV7u2Ao3Sl.3gh6HJB6MpLQVMtaFQbfZuBFzLxVu4nvQA7X4l7BKSRxGxqM84zOMKc9MFzr0nPFm7trzojFpd7.Z1v41IVaJlJ42gkDyr8eVjgn2qV7v_CnqPLkuIAAGq.01eYFK8YydnedvPvy_Hg7Zl1UDSb5y4nnEEyn3QvWCnXCJufOIquNUWzFvYp0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A89195C.5060700@netconfcentral.com> Date: Mon, 17 Aug 2009 01:48:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A85B916.2070009@netconfcentral.com> <20090814.224106.175526822.mbj@tail-f.com> <4A85F449.1020901@netconfcentral.com> <20090817.103928.125604250.mbj@tail-f.com> In-Reply-To: <20090817.103928.125604250.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Mon, 17 Aug 2009 08:48:14 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> 1) YANG compile time: >>>> any possible scenario in which any path statement >>>> may not be valid in every possible compliant agent >>>> implementation MUST be considered a fatal error. >>>> The draft needs to make this clear. >>> Please send me some suggestion for text to include! >>> >> (Here's what yangdump checks anyway -- maybe there >> is more to it than this...) >> >> leafref node ==> leaf containing a leafref type >> target leaf ==> leaf pointed at by a leafref path statement >> >> >> The leafref node cannot be more conditional than >> the target leaf. >> >> The following restrictions apply: >> - if the leafref is mandatory, then the target leaf >> SHOULD be mandatory as well. Managers need to make >> sure that an instance of the target leaf is present, >> or the leafref will not be valid. > > According to this rule, would this model invalidate the SHOULD? > > list a { > key x; > leaf x { type int32; } > } > container b { > presence "..."; > leaf y { > type leafref { path /a/x; } > mandatory true; > } > } > why would it? A key leaf is implicitly mandatory. >> - if any if-feature statements apply to the leafref node, >> then they MUST also apply to the target leaf. > > Is this text clear enough to just include in the draft? Is it clear > what it means that an "if-feature statement apply"? > >> - A when statement can apply to the leafref or target node >> in 3 ways (direct, inherited from all uses, inherited from >> augment). The conceptual AND expression formed >> from these 3 XPath expressions MUST be identical >> in the leafref and target leafs. > > How do you check if the conceptual expressions are identitical? If we > really want to include text along these lines, it will require some > effort to describe the logic in an interoperable way. > you really can't do more than string compare the XPath expressions -- a totally stupid thing to do, but that's already how deviations work. >>>> 2) agent run time: >>>> - What to do when the agent has a leafref object >>>> with an invalid path statement? >>> Such a config is not valid. It doesn't spontaneously happen - it >>> happens b/c an operator tries to modify the config. This request must >>> be rejected, just as a request that would invalidate a must constraint. >>> >> you are right. >> this is no different than if the startup config >> loaded into running is invalid. The agent needs to deal >> somehow with this situation already. >> >> I would like there to be a standard way for an >> agent to deal with a "good running config gone bad". > > But running won't just go bad - in fact running cannot go bad. So if > the server gets an edit-config with removes a leaf that is referenced > by a leafref, it will reply with a 'data-missing' error, with the > error-app-tag 'instance-required' (see section 13.6). > where is that specified in the draft? I like Washam's plan better -- you delete the leaf, and all its references go away as well. >>>>> "All leafref nodes MUST reference >>>>> existing leaf instances for the data to be valid" >>>>> suggests the latter. >>>> So what happens to the pointing-leaf in the >>>> running config when the pointed-at leaf goes away? >>>> The running config cannot be invalid, but it is. >>> Again, the pointed-at leaf won't just "go away". It goes away when a >>> client deletes it, and that will be an error. >>> >> I know the pointed-at leaf will go away. >> So does the operator. But the operator >> may be astonished when the deleted-node ripple affect >> deletes other nodes, not just the first one. > > There is no "deleted-node ripple effect". The delete on the first > node will fail. > what about a choice-stmt than contains a case that contains a leaf that is pointed at by a leafref? The agent is forced to remove that case when a new one is entered. This also leaves dangling references to a deleted leaf. You want that to work sometimes, but not others? We already have a deleted-node ripple effect. > > /martin > Andy From mbj@tail-f.com Mon Aug 17 01:58: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 3447628C181 for ; Mon, 17 Aug 2009 01:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.129, 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 OZO6tLVZld-R for ; Mon, 17 Aug 2009 01:58:41 -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 28E9128C183 for ; Mon, 17 Aug 2009 01:58:40 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9A3CC76C4E3; Mon, 17 Aug 2009 10:58:45 +0200 (CEST) Date: Mon, 17 Aug 2009 10:58:45 +0200 (CEST) Message-Id: <20090817.105845.31891660.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A89195C.5060700@netconfcentral.com> References: <4A85F449.1020901@netconfcentral.com> <20090817.103928.125604250.mbj@tail-f.com> <4A89195C.5060700@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] leafref problems 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: Mon, 17 Aug 2009 08:58:42 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> The following restrictions apply: > >> - if the leafref is mandatory, then the target leaf > >> SHOULD be mandatory as well. Managers need to make > >> sure that an instance of the target leaf is present, > >> or the leafref will not be valid. > > > > According to this rule, would this model invalidate the SHOULD? > > > > list a { > > key x; > > leaf x { type int32; } > > } > > container b { > > presence "..."; > > leaf y { > > type leafref { path /a/x; } > > mandatory true; > > } > > } > > > > why would it? > A key leaf is implicitly mandatory. B/c the list may have in 0 instances. Why would that be different from container a { leaf x { type int32; } } I prefer to not add the SHOULD suggested above. > >>>> 2) agent run time: > >>>> - What to do when the agent has a leafref object > >>>> with an invalid path statement? > >>> Such a config is not valid. It doesn't spontaneously happen - it > >>> happens b/c an operator tries to modify the config. This request must > >>> be rejected, just as a request that would invalidate a must constraint. > >>> > >> you are right. > >> this is no different than if the startup config > >> loaded into running is invalid. The agent needs to deal > >> somehow with this situation already. > >> > >> I would like there to be a standard way for an > >> agent to deal with a "good running config gone bad". > > > > But running won't just go bad - in fact running cannot go bad. So if > > the server gets an edit-config with removes a leaf that is referenced > > by a leafref, it will reply with a 'data-missing' error, with the > > error-app-tag 'instance-required' (see section 13.6). > > > > where is that specified in the draft? Section 8.3.3 says that constraints for running are checked at edit-config time. Section 9 says that a leafref is such a constraint. And section 13.6 specifies the error message to use. > I like Washam's plan better -- you delete the leaf, > and all its references go away as well. This has been discussed before, and it was rejected at the time. /martin From mbj@tail-f.com Mon Aug 17 02:02: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 7E7DE28C1A1 for ; Mon, 17 Aug 2009 02:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.124, 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 C7aIBUb9XQ40 for ; Mon, 17 Aug 2009 02:02:41 -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 9F18628C1AA for ; Mon, 17 Aug 2009 02:02:41 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0CE3D76C4E3; Mon, 17 Aug 2009 11:02:45 +0200 (CEST) Date: Mon, 17 Aug 2009 11:02:45 +0200 (CEST) Message-Id: <20090817.110245.26949790.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <002c01ca1e4b$fdd29fa0$0601a8c0@allison> References: <4A856559.4040402@netconfcentral.com> <20090814.153232.162557664.mbj@tail-f.com> <002c01ca1e4b$fdd29fa0$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] Terminology2 was Re: leafref problems 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: Mon, 17 Aug 2009 09:02:42 -0000 Hi, "tom.petch" wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Friday, August 14, 2009 3:32 PM > Subject: Re: [netmod] leafref problems > > > Andy Bierman wrote: > > > > I propose the following change (and similar for the other case; > > > > must/when/path): > > > > > > > > OLD: > > > > > > > > - If this leaf represents configuration data, the tree is the data in > > > > one of the NETCONF datastores. The XPath root node has all > > > > top-level configuration data nodes in all modules as children. > > > > > > > > NEW: > > > > > > > > - If this leaf represents configuration data, the tree is the data in > > > > the NETCONF datastore where the leaf exists. The XPath root node > > > > has all top-level configuration data nodes in all modules as > > > > children. > > > > > > 'top-level' appears many times in the i-d and I would like to see the meaning > better nailed down . > > It could refer to the substatements immediately below a module statement. > > It could be extended to the substatements immediately below the submodule > statement of an included submodule. > > Since the reference, as here, is frequently to top-level data nodes, it could > be > read as any data node which has no other data node between it and the module > statement Yes. > so that in > > module m {grouping g { leaf x ... > > then x is regarded as top-level No, the grouping statement does not instantiate any data nodes. If you also had: uses g; then x would be a top-level data node. /martin From muenz@net.in.tum.de Mon Aug 17 04:20: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 8107628C2B1 for ; Mon, 17 Aug 2009 04:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, 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 E5vZoEiECRKB for ; Mon, 17 Aug 2009 04:20:15 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 9638B28C2AE for ; Mon, 17 Aug 2009 04:20:14 -0700 (PDT) Received: from [131.159.20.108] by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Md0GA-0004bY-Mh for netmod@ietf.org; Mon, 17 Aug 2009 13:20:18 +0200 Message-ID: <4A893CEC.6020208@net.in.tum.de> Date: Mon, 17 Aug 2009 13:20:12 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 11:20:16 -0000 Hi, Martin Bjorklund wrote: > Andy Bierman wrote: >> There are several details in YANG that are legal, >> yet they represent data models which cannot possibly >> be supported on any NETCONF agent. >> >> Mandatory top-level nodes are allowed in YANG >> but not supportable in a NETCONF agent. > > I disagree. See the email thread "mandatory mess". If you have a > top-level mandatory leaf, it MUST have a value in a valid database. > So, when the system has started and the NETCONF i/f is up and running, > the leaf MUST exist. A user can then modify it, but not delete it. Sorry that I have to ask again. I tried to explain the IPFIX use case in http://www.ietf.org/mail-archive/web/netmod/current/msg03297.html I only got one answer by Phil which did not really clarify the issue. Up to now, I've thought that "mandatory" means "MUST be provided by the user". Apparently, this is not true for top-level nodes. I'm confused. Does "mandatory" mean that the agent will create the node if it is missing (i.e., not provided by the user)? Is this a general rule or does this only apply to top-level nodes? For me, it is important to know if there is a difference because we have nodes in non-mandatory containers which will be created by the device if not created by the user. Do I have to declare them mandatory as well? Thanks, Gerhard > >> If an agent is free to choose what mandatory means, >> then since all YANG modules need to >> work with all conforming NETCONF implementations, >> the top-level cannot be mandatory. > > The agent is not free to choose what mandatory means. It means that > the leaf MUST exist in a valid data store. > >> leafref objects are allowed to point at non-existent >> nodes in YANG but this is not implementable on >> the agent. If the pointed-at object is not present, >> then any object pointing at that object must also >> be removed from the agent (ripple out until done). > > I assume you refer to leafrefs which point to leafs with if-feature? > As I wrote in the other email thread, I think this is a valid concern, > and we should fix it. I prefer to keep the discussion in one email > thread though. > >> YANG is already extremely difficult to learn. > > I don't know what you base this on, and I don't know what do to with > this comment. From my experience with pioneer YANG writers, I > disagree though. > > > /martin From andy@netconfcentral.com Mon Aug 17 04:23:17 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 390FF28C2B5 for ; Mon, 17 Aug 2009 04:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 zbuYiBdI9JPh for ; Mon, 17 Aug 2009 04:23:16 -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 5A2AD28C2A7 for ; Mon, 17 Aug 2009 04:23:16 -0700 (PDT) Received: (qmail 1113 invoked from network); 17 Aug 2009 11:23:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 17 Aug 2009 11:23:19 -0000 X-YMail-OSG: q5e3m9QVM1myA8DHERXuIkNMTD5ggu9Ri9KO.m8VoQcs_lzBXXfogiueS0Mo2KfeE6CilCijCjJKXX6dY_7ZEOXvvH7GPkLc2Wh3ggqyzxBAejYsh3NF1eiaEtWiITzLQ0Yc5AmxX8nFGlYX7TI1twe9EFuNDsFYtA5_EmGcAHlgWnrQb7D7X5sYdSQopoLizwRY4QPPeaAqsqSAYGmqH_vsXB_dSnBvHUDi8c.ko4zNN_JGjTX__lqr4iByG7stlluK2KKOrdxYDkjeLEla3NQjI7ASCmSm0Gm_hUmUVP_bIzjCXbaEmWGMPdl4dHK4Jmg8LsriHK2_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A893DB6.7040203@netconfcentral.com> Date: Mon, 17 Aug 2009 04:23:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A85F449.1020901@netconfcentral.com> <20090817.103928.125604250.mbj@tail-f.com> <4A89195C.5060700@netconfcentral.com> <20090817.105845.31891660.mbj@tail-f.com> In-Reply-To: <20090817.105845.31891660.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Mon, 17 Aug 2009 11:23:17 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> The following restrictions apply: >>>> - if the leafref is mandatory, then the target leaf >>>> SHOULD be mandatory as well. Managers need to make >>>> sure that an instance of the target leaf is present, >>>> or the leafref will not be valid. >>> According to this rule, would this model invalidate the SHOULD? >>> >>> list a { >>> key x; >>> leaf x { type int32; } >>> } >>> container b { >>> presence "..."; >>> leaf y { >>> type leafref { path /a/x; } >>> mandatory true; >>> } >>> } >>> >> why would it? >> A key leaf is implicitly mandatory. > > B/c the list may have in 0 instances. Why would that be different > from > > container a { > leaf x { type int32; } > } > > I prefer to not add the SHOULD suggested above. > >>>>>> 2) agent run time: >>>>>> - What to do when the agent has a leafref object >>>>>> with an invalid path statement? >>>>> Such a config is not valid. It doesn't spontaneously happen - it >>>>> happens b/c an operator tries to modify the config. This request must >>>>> be rejected, just as a request that would invalidate a must constraint. >>>>> >>>> you are right. >>>> this is no different than if the startup config >>>> loaded into running is invalid. The agent needs to deal >>>> somehow with this situation already. >>>> >>>> I would like there to be a standard way for an >>>> agent to deal with a "good running config gone bad". >>> But running won't just go bad - in fact running cannot go bad. So if >>> the server gets an edit-config with removes a leaf that is referenced >>> by a leafref, it will reply with a 'data-missing' error, with the >>> error-app-tag 'instance-required' (see section 13.6). >>> >> where is that specified in the draft? > > Section 8.3.3 says that constraints for running are checked at > edit-config time. Section 9 says that a leafref is such a > constraint. And section 13.6 specifies the error message to use. > > >> I like Washam's plan better -- you delete the leaf, >> and all its references go away as well. > > This has been discussed before, and it was rejected at the time. > I do not remember this. I remember you insisted an agent must delete the old case in a choice when a new case is set. Are you saying now that is not what the agent does? choice X { leaf a { type string; } leaf b { type string; } } leaf Y { type leafref { path /X/a/a; } } Are you saying that if /b is set, so /a is deleted, that this will fail if /Y exists, but work if /Y does not exist? > > > /martin > Andy From mbj@tail-f.com Mon Aug 17 05:00: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 B0DCF3A68E9 for ; Mon, 17 Aug 2009 05:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.119, 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 dHkGJ47NAh9H for ; Mon, 17 Aug 2009 05:00:39 -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 C827C3A68D4 for ; Mon, 17 Aug 2009 05:00:38 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 95F5F616011; Mon, 17 Aug 2009 14:00:42 +0200 (CEST) Date: Mon, 17 Aug 2009 14:00:42 +0200 (CEST) Message-Id: <20090817.140042.16625128.mbj@tail-f.com> To: muenz@net.in.tum.de From: Martin Bjorklund In-Reply-To: <4A893CEC.6020208@net.in.tum.de> References: <4A893CEC.6020208@net.in.tum.de> 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] YANG must work with NETCONF 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: Mon, 17 Aug 2009 12:00:39 -0000 Gerhard Muenz wrote: > > Hi, > > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> There are several details in YANG that are legal, > >> yet they represent data models which cannot possibly > >> be supported on any NETCONF agent. > >> > >> Mandatory top-level nodes are allowed in YANG > >> but not supportable in a NETCONF agent. > > I disagree. See the email thread "mandatory mess". If you have a > > top-level mandatory leaf, it MUST have a value in a valid database. > > So, when the system has started and the NETCONF i/f is up and running, > > the leaf MUST exist. A user can then modify it, but not delete it. > > Sorry that I have to ask again. I tried to explain the IPFIX use case in > http://www.ietf.org/mail-archive/web/netmod/current/msg03297.html > I only got one answer by Phil which did not really clarify the issue. > > Up to now, I've thought that "mandatory" means "MUST be provided by the > user". Yes this is true, and the way you have solved this in your module is IMO correct - i.e. use an optional leaf and specify the behavior in the description clause. > Apparently, this is not true for top-level nodes. I'm confused. It is also true for top-level nodes, but since such a node must exist in the initial data store it must be created as part of the initial system start. The data might be set using some initial CLI or using some other initial data. The important thing is the observed server behavior. If you do a get-config of running, the data you get back must be valid. If you create e.g. a list entry which has a mandatory leaf, you must set the value. The agent will not set it. > Does "mandatory" mean that the agent will create the node if it is missing > (i.e., not provided by the user)? No. > Is this a general rule or does this only apply to top-level nodes? I don't view this as created by the agent. I view it as being part of the initial (valid) data store. /martin From mbj@tail-f.com Mon Aug 17 05:13: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 BF55E28C190 for ; Mon, 17 Aug 2009 05:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.114, 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 1AJT2q5OSYIN for ; Mon, 17 Aug 2009 05:13:04 -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 E9BE828C187 for ; Mon, 17 Aug 2009 05:13:03 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8519376C4E3; Mon, 17 Aug 2009 14:13:08 +0200 (CEST) Date: Mon, 17 Aug 2009 14:13:08 +0200 (CEST) Message-Id: <20090817.141308.259239093.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A893DB6.7040203@netconfcentral.com> References: <4A89195C.5060700@netconfcentral.com> <20090817.105845.31891660.mbj@tail-f.com> <4A893DB6.7040203@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] leafref problems 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: Mon, 17 Aug 2009 12:13:04 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> I would like there to be a standard way for an > >>>> agent to deal with a "good running config gone bad". > >>> But running won't just go bad - in fact running cannot go bad. So if > >>> the server gets an edit-config with removes a leaf that is referenced > >>> by a leafref, it will reply with a 'data-missing' error, with the > >>> error-app-tag 'instance-required' (see section 13.6). > >>> > >> where is that specified in the draft? > > > > Section 8.3.3 says that constraints for running are checked at > > edit-config time. Section 9 says that a leafref is such a > > constraint. And section 13.6 specifies the error message to use. > > > > > >> I like Washam's plan better -- you delete the leaf, > >> and all its references go away as well. > > > > This has been discussed before, and it was rejected at the time. > > > > I do not remember this. See the mail thread "leafref issues", started by you 27 May 2009. A couple of emails objected against introducing automatic deletions of references, and no one insisted that it should be added. > I remember you insisted an agent must > delete the old case in a choice when a new case > is set. Are you saying now that is not what > the agent does? No. > choice X { > leaf a { type string; } > leaf b { type string; } > } > > leaf Y { > type leafref { path /X/a/a; } > } > > Are you saying that if /b is set, so /a is deleted, > that this will fail if /Y exists, but work if /Y > does not exist? Yes. Just like this: leaf Y { type string; must ". = /X/a"; } /martin From andy@netconfcentral.com Mon Aug 17 05:53:20 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 36C5728C146 for ; Mon, 17 Aug 2009 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 W7cPVrtQ+dhF for ; Mon, 17 Aug 2009 05:53:19 -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 62B3728C118 for ; Mon, 17 Aug 2009 05:53:19 -0700 (PDT) Received: (qmail 560 invoked from network); 17 Aug 2009 12:53:21 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 17 Aug 2009 12:53:21 -0000 X-YMail-OSG: JQLHKQ8VM1kB3IBISureroB_3Ei3ntE6i4FmYDVmpGAWvD4pD6CT2C80ugvy5KewekkxbG5LcemAvHq5iqv_71FIA.WjLXavYeT7w2dSVv26wp4BJcqV0kOyD7jd377wcLBmXQbH4oa7LOF6D.gMfXPdJOxTnnnuimoKFhWS0PNEiu4LiL0fXeCyVgvpoQD6lYa7.tSIWXyn6nLdhPba30uoHTjvDXRwFhwG7siBVjwcQEpxBniXp2rE3xgS3jXsOxm3G1q2h7bQshpVfCWy4bqxeNWXtT5fjYF7Dmkg9m6GYL36lddb4DbqyYxeObizlpWx4R4S9VRiMqykWp7BIpiTgJj8dDhQpSsFLo_PFEmSyYYN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8952D0.7090606@netconfcentral.com> Date: Mon, 17 Aug 2009 05:53:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A89195C.5060700@netconfcentral.com> <20090817.105845.31891660.mbj@tail-f.com> <4A893DB6.7040203@netconfcentral.com> <20090817.141308.259239093.mbj@tail-f.com> In-Reply-To: <20090817.141308.259239093.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Mon, 17 Aug 2009 12:53:20 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy Bierman wrote: >>>>>> I would like there to be a standard way for an >>>>>> agent to deal with a "good running config gone bad". >>>>> But running won't just go bad - in fact running cannot go bad. So if >>>>> the server gets an edit-config with removes a leaf that is referenced >>>>> by a leafref, it will reply with a 'data-missing' error, with the >>>>> error-app-tag 'instance-required' (see section 13.6). >>>>> >>>> where is that specified in the draft? >>> Section 8.3.3 says that constraints for running are checked at >>> edit-config time. Section 9 says that a leafref is such a >>> constraint. And section 13.6 specifies the error message to use. >>> >>> >>>> I like Washam's plan better -- you delete the leaf, >>>> and all its references go away as well. >>> This has been discussed before, and it was rejected at the time. >>> >> I do not remember this. > > See the mail thread "leafref issues", started by you 27 May 2009. A > couple of emails objected against introducing automatic deletions of > references, and no one insisted that it should be added. > >> I remember you insisted an agent must >> delete the old case in a choice when a new case >> is set. Are you saying now that is not what >> the agent does? > > No. > >> choice X { >> leaf a { type string; } >> leaf b { type string; } >> } >> >> leaf Y { >> type leafref { path /X/a/a; } >> } >> >> Are you saying that if /b is set, so /a is deleted, >> that this will fail if /Y exists, but work if /Y >> does not exist? > > Yes. > > Just like this: > > leaf Y { > type string; > must ". = /X/a"; > } > > but it is not just like a must-stmt. If the data model designer wants the behavior you are are suggesting, then they will use the must-stmt. Let's say an interface entry has 100 tables hanging off of it, all dependent on the existence of that specific interface entry. It would be extremely cumbersome to manually unwind all these data structures bottom up because they were designed like SMIv2 tables (foreign keys instead of nested tables). If the operator deletes an interface, then it is clear these tables with foreign keys are no longer needed as well. When an external config leafref points at a list entry, the normal behavior is also to delete the reference. Going back to an early example, it makes no sense at all to keep the 'my-favorite-channel' leafref if the 'channel-list' is deleted. > > /martin > Andy From mbj@tail-f.com Mon Aug 17 06:07: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 D1D4F28C17E for ; Mon, 17 Aug 2009 06:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.109, 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 zfrCPdE-eBDj for ; Mon, 17 Aug 2009 06:07:48 -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 161603A6F00 for ; Mon, 17 Aug 2009 06:07:48 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C04A76C4E3; Mon, 17 Aug 2009 15:07:52 +0200 (CEST) Date: Mon, 17 Aug 2009 15:07:51 +0200 (CEST) Message-Id: <20090817.150751.52288313.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8952D0.7090606@netconfcentral.com> References: <4A893DB6.7040203@netconfcentral.com> <20090817.141308.259239093.mbj@tail-f.com> <4A8952D0.7090606@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] leafref problems 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: Mon, 17 Aug 2009 13:07:48 -0000 Andy Bierman wrote: > but it is not just like a must-stmt. >From a validation point of view, a leafref behaves like a leaf with a must statement. But I agree; a leafref is more than a must in that it expclicitly defines a cross reference. > Let's say an interface entry has 100 tables hanging > off of it, all dependent on the existence of that > specific interface entry. It would be extremely cumbersome > to manually unwind all these data structures bottom up > because they were designed like SMIv2 tables (foreign > keys instead of nested tables). If the operator deletes > an interface, then it is clear these tables with foreign > keys are no longer needed as well. But as you said earlier we expect people to not use the flat structure, but rather make use of the hierarchy we have. Going back to the example which you said is valid YANG: list a { key x; leaf x { type int32; } } container b { presence "..."; leaf y { type leafref { path /a/x; } mandatory true; } } Suppose /a[x=1] exists, and /b/y is 1. Now if /a[x=1] is deleted, /b/y should be auto-deleted, right? Does this mean that /b is auto-deleted as well? This will indeed cause a delete ripple effect, which I think would be very confusing and bad. /martin From lhotka@cesnet.cz Mon Aug 17 06:24: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 2AA6B3A6833 for ; Mon, 17 Aug 2009 06:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.064, 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 lLBDT+y902rL for ; Mon, 17 Aug 2009 06:24:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8AFE528C18F for ; Mon, 17 Aug 2009 06:24:28 -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 A896DD80096 for ; Mon, 17 Aug 2009 15:24:28 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4A893CEC.6020208@net.in.tum.de> References: <4A893CEC.6020208@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 15:24:27 +0200 Message-Id: <1250515467.21629.34.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 13:24:55 -0000 Hi Gerhard, in fact, I started the thread "mandatory mess" because of the weaselness of the crucial (interrelated) terms such as configuration database, mandatory/optional leaves and default values. I have the impression that due to political requirements on vendor neutrality it is taboo to speak about any particular information model, but IMO this approach will backfire in the future - and the parallel discussion in NETCONF ML about database architecture seems to indicate the same thing. A possible solution - still quite neutral - would be to define a base infomation model and then the various vendor representations of config datastores as views of this base model. Anyway, for me a mandatory value is one that's required for the operation of a device or protocol and this definition is independent of whether there is any default value supplied either by the data model or "initial default configuration". Lada Gerhard Muenz píše v Po 17. 08. 2009 v 13:20 +0200: > Hi, > > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> There are several details in YANG that are legal, > >> yet they represent data models which cannot possibly > >> be supported on any NETCONF agent. > >> > >> Mandatory top-level nodes are allowed in YANG > >> but not supportable in a NETCONF agent. > > > > I disagree. See the email thread "mandatory mess". If you have a > > top-level mandatory leaf, it MUST have a value in a valid database. > > So, when the system has started and the NETCONF i/f is up and running, > > the leaf MUST exist. A user can then modify it, but not delete it. > > Sorry that I have to ask again. I tried to explain the IPFIX use case in > http://www.ietf.org/mail-archive/web/netmod/current/msg03297.html > I only got one answer by Phil which did not really clarify the issue. > > Up to now, I've thought that "mandatory" means "MUST be provided by the > user". Apparently, this is not true for top-level nodes. I'm confused. > > Does "mandatory" mean that the agent will create the node if it is > missing (i.e., not provided by the user)? > Is this a general rule or does this only apply to top-level nodes? > > For me, it is important to know if there is a difference because we have > nodes in non-mandatory containers which will be created by the device if > not created by the user. Do I have to declare them mandatory as well? > > Thanks, > Gerhard > > > > > >> If an agent is free to choose what mandatory means, > >> then since all YANG modules need to > >> work with all conforming NETCONF implementations, > >> the top-level cannot be mandatory. > > > > The agent is not free to choose what mandatory means. It means that > > the leaf MUST exist in a valid data store. > > > >> leafref objects are allowed to point at non-existent > >> nodes in YANG but this is not implementable on > >> the agent. If the pointed-at object is not present, > >> then any object pointing at that object must also > >> be removed from the agent (ripple out until done). > > > > I assume you refer to leafrefs which point to leafs with if-feature? > > As I wrote in the other email thread, I think this is a valid concern, > > and we should fix it. I prefer to keep the discussion in one email > > thread though. > > > >> YANG is already extremely difficult to learn. > > > > I don't know what you base this on, and I don't know what do to with > > this comment. From my experience with pioneer YANG writers, I > > disagree though. > > > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Aug 17 06:31: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 C3DA728C1BC for ; Mon, 17 Aug 2009 06:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 iJzigbuvvRn5 for ; Mon, 17 Aug 2009 06:31:35 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 31B0C3A6DA1 for ; Mon, 17 Aug 2009 06:31:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSolbuOdcPQDajc5XZF8b7fiQqlxUpDph@postini.com; Mon, 17 Aug 2009 06:31:39 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; Mon, 17 Aug 2009 06:25:24 -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); Mon, 17 Aug 2009 06:25:24 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 06:25:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 06:25: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 n7HDPNd23256; Mon, 17 Aug 2009 06:25: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 n7HDDY2G025624; Mon, 17 Aug 2009 13:13:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908171313.n7HDDY2G025624@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090817.150751.52288313.mbj@tail-f.com> Date: Mon, 17 Aug 2009 09:13:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Aug 2009 13:25:23.0690 (UTC) FILETIME=[2D002CA0:01CA1F3E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Mon, 17 Aug 2009 13:31:35 -0000 Martin Bjorklund writes: >Suppose /a[x=1] exists, and /b/y is 1. Now if /a[x=1] is deleted, >/b/y should be auto-deleted, right? Does this mean that /b is >auto-deleted as well? This will indeed cause a delete ripple effect, >which I think would be very confusing and bad. Are you talking only about running? In candidate, auto-deletion of /b/y is not reasonable, since the user could immediate make/load a new a[x=1]. The rules apply at validation time, so a workplace like candidate can be invalid during the construction of a new configuration. Working backwards from there, running should be valid after each edit-config, so an edit-config can deletes a[x=1] would make the configuration invalid. Is the best outcome to fail the operation (if test-then-set) or to auto-delete to force the configuration to be valid? Thanks, Phil From mbj@tail-f.com Mon Aug 17 06:41:20 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 AF08F3A6EBC for ; Mon, 17 Aug 2009 06:41:20 -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 wYBIboxNM6+N for ; Mon, 17 Aug 2009 06:41:19 -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 E578828C23D for ; Mon, 17 Aug 2009 06:40:02 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9B3B376C4E3; Mon, 17 Aug 2009 15:40:07 +0200 (CEST) Date: Mon, 17 Aug 2009 15:40:07 +0200 (CEST) Message-Id: <20090817.154007.126929046.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908171313.n7HDDY2G025624@idle.juniper.net> References: <20090817.150751.52288313.mbj@tail-f.com> <200908171313.n7HDDY2G025624@idle.juniper.net> 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] leafref problems 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: Mon, 17 Aug 2009 13:41:20 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Suppose /a[x=1] exists, and /b/y is 1. Now if /a[x=1] is deleted, > >/b/y should be auto-deleted, right? Does this mean that /b is > >auto-deleted as well? This will indeed cause a delete ripple effect, > >which I think would be very confusing and bad. > > Are you talking only about running? In candidate, auto-deletion > of /b/y is not reasonable, since the user could immediate make/load > a new a[x=1]. The rules apply at validation time, so a workplace > like candidate can be invalid during the construction of a new > configuration. This is another reason for keeping the current behavior (i.e. no auto-deletion). If we compare with 'choice', cases are auto-deleted, but it works the same in the candidate and running. I don't think we should introduce another flavor of auto-delete for leafrefs. /martin From j.schoenwaelder@jacobs-university.de Mon Aug 17 06:41: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 1BD2C3A6DA4 for ; Mon, 17 Aug 2009 06:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 we5ecFJ6q9Ez for ; Mon, 17 Aug 2009 06:41:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47B0C3A6DA7 for ; Mon, 17 Aug 2009 06:41:56 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D47B9C004F; Mon, 17 Aug 2009 15:42:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id voOYO5uo-d9j; Mon, 17 Aug 2009 15:41:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21594C004E; Mon, 17 Aug 2009 15:41:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1351CC6ECB6; Mon, 17 Aug 2009 15:41:58 +0200 (CEST) Date: Mon, 17 Aug 2009 15:41:58 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090817134157.GA3357@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , "netmod@ietf.org" References: <20090817.150751.52288313.mbj@tail-f.com> <200908171313.n7HDDY2G025624@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908171313.n7HDDY2G025624@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] leafref problems 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: Mon, 17 Aug 2009 13:41:58 -0000 On Mon, Aug 17, 2009 at 03:13:34PM +0200, Phil Shafer wrote: > Martin Bjorklund writes: > >Suppose /a[x=1] exists, and /b/y is 1. Now if /a[x=1] is deleted, > >/b/y should be auto-deleted, right? Does this mean that /b is > >auto-deleted as well? This will indeed cause a delete ripple effect, > >which I think would be very confusing and bad. > > Are you talking only about running? In candidate, auto-deletion > of /b/y is not reasonable, since the user could immediate make/load > a new a[x=1]. The rules apply at validation time, so a workplace > like candidate can be invalid during the construction of a new > configuration. > > Working backwards from there, running should be valid after each > edit-config, so an edit-config can deletes a[x=1] would make the > configuration invalid. Is the best outcome to fail the operation > (if test-then-set) or to auto-delete to force the configuration to > be valid? My stomach says the operation should fail and we should ensure referential integrity. If we do automatic deletions, then of course I expect the same behaviour if I commit candidate to running at commit time. /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 Mon Aug 17 06:48: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 D38543A6EE1 for ; Mon, 17 Aug 2009 06:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_29=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 f-ucgvtZwJgg for ; Mon, 17 Aug 2009 06:48:49 -0700 (PDT) Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id F419A3A6EDA for ; Mon, 17 Aug 2009 06:48:48 -0700 (PDT) Received: from [68.142.200.221] by n13.bullet.mail.mud.yahoo.com with NNFMP; 17 Aug 2009 13:48:52 -0000 Received: from [68.142.201.250] by t9.bullet.mud.yahoo.com with NNFMP; 17 Aug 2009 13:48:52 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 17 Aug 2009 13:48:52 -0000 X-Yahoo-Newman-Id: 318995.11474.bm@omp411.mail.mud.yahoo.com Received: (qmail 12900 invoked from network); 17 Aug 2009 13:48:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 17 Aug 2009 13:48:51 -0000 X-YMail-OSG: ePBEUbkVM1kmAxhggQlppJIFL5F950i5Y9m.Rn7wd5XTv_4g3EA2xnBuEavdaJGGJlbCM_UXCYziMxdxuZ0zgaNNL6v4S5U4SbtXbcIiLrWpbwLebfqldhbm4i4GP66YXCBw6M1eln272_oZBztJQMFg0v5AfO0m6F1FFfy6GGZigfeAtTG0L6RWTUvt5k2k3p9vy8TQYrJDfNITTqXWSGfBpx5f7LirdjT2w1UV9Tg9FTJ1_2bw1WWQZ7zs9rtXjIsTsdZDEUve1AY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A895FD3.1000102@netconfcentral.com> Date: Mon, 17 Aug 2009 06:49:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908171313.n7HDDY2G025624@idle.juniper.net> In-Reply-To: <200908171313.n7HDDY2G025624@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leafref problems 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: Mon, 17 Aug 2009 13:48:49 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> Suppose /a[x=1] exists, and /b/y is 1. Now if /a[x=1] is deleted, >> /b/y should be auto-deleted, right? Does this mean that /b is >> auto-deleted as well? This will indeed cause a delete ripple effect, >> which I think would be very confusing and bad. > > Are you talking only about running? In candidate, auto-deletion > of /b/y is not reasonable, since the user could immediate make/load > a new a[x=1]. The rules apply at validation time, so a workplace > like candidate can be invalid during the construction of a new > configuration. > > Working backwards from there, running should be valid after each > edit-config, so an edit-config can deletes a[x=1] would make the > configuration invalid. Is the best outcome to fail the operation > (if test-then-set) or to auto-delete to force the configuration to > be valid? > It comes down to a simple unix analogy: Do we want "rm -r" or "rm -rf"? (both of course) I am thinking about a similar code-point with a 'delete-all' value for the nc:operation attribute (for list and leaf-list). We could use the --force option in NETCONF by adding another enum to the nc:operation. (We could bundle all the new tweaks into 1 :newstuff-1.0 capability, instead of a bunch of independent tiny enhancements). The default in unix is "rm" (reject with error), so that seems to favor Martin's outcome. Done. I like your twist -- put this in the commit check, so a dangling leafref reference in candidate is not an error. (should already be coded that way). > Thanks, > Phil > Andy From andy@netconfcentral.com Mon Aug 17 06:55: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 D17E328C200 for ; Mon, 17 Aug 2009 06:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 bhvRmZTom1Nh for ; Mon, 17 Aug 2009 06:55:45 -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 C95553A6B7F for ; Mon, 17 Aug 2009 06:55:45 -0700 (PDT) Received: (qmail 6035 invoked from network); 17 Aug 2009 13:55:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 17 Aug 2009 13:55:47 -0000 X-YMail-OSG: ypj1ZrkVM1m1rUKKFYyyRgZm6ojTwvw6slH_If91uiqGsXd4_sW.z9eoM9LPsDs9FCIxzvA7uze9oIK09akSJJIw0yQPfnazZl5sJLjCPRiSlbtwr6Vs_MjMK.HfheA8mxEQcF_xzJJq7m0JvT2h.IJIFVRxjdc_AUQgTz9imClHqi3IAFeoHLKXqmWKd5kJ.OeIpKul_Y9PPKZiBD6_KWBZXIOHWSUtP6WB0rVbabZO0U3ayaT8eMv2FC9wEuVpi7gB5c_yBrak4zEWse75i_kBfWZHD4LRw.AQcHx_nT9N7sjWBjZLpuj4j1XxnTebmy6PSjRvWOSpy7gOrSY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A896173.8070301@netconfcentral.com> Date: Mon, 17 Aug 2009 06:56:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A893CEC.6020208@net.in.tum.de> <1250515467.21629.34.camel@missotis> In-Reply-To: <1250515467.21629.34.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 13:55:46 -0000 Ladislav Lhotka wrote: > Hi Gerhard, > > in fact, I started the thread "mandatory mess" because of the weaselness > of the crucial (interrelated) terms such as configuration database, > mandatory/optional leaves and default values. > > I have the impression that due to political requirements on vendor > neutrality it is taboo to speak about any particular information model, > but IMO this approach will backfire in the future - and the parallel > discussion in NETCONF ML about database architecture seems to indicate > the same thing. > > A possible solution - still quite neutral - would be to define a base > infomation model and then the various vendor representations of config > datastores as views of this base model. > > Anyway, for me a mandatory value is one that's required for the > operation of a device or protocol and this definition is independent of > whether there is any default value supplied either by the data model or > "initial default configuration". > I must say that I was surprised to find out that mandatory doesn't mean the manager must provide a value. That worries me, because if I do not want any default in my data model, and I want all implementations of this model to fail unless the mandatory node is set, there is no way to do that in YANG. Any agent is free to make up a value for a mandatory leaf. This is not the same is pre-loading the /system or /interfaces subtrees. Lists and containers cannot have the mandatory-stmt. They do not matter here. > Lada > Andy > Gerhard Muenz píše v Po 17. 08. 2009 v 13:20 +0200: >> Hi, >> >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> There are several details in YANG that are legal, >>>> yet they represent data models which cannot possibly >>>> be supported on any NETCONF agent. >>>> >>>> Mandatory top-level nodes are allowed in YANG >>>> but not supportable in a NETCONF agent. >>> I disagree. See the email thread "mandatory mess". If you have a >>> top-level mandatory leaf, it MUST have a value in a valid database. >>> So, when the system has started and the NETCONF i/f is up and running, >>> the leaf MUST exist. A user can then modify it, but not delete it. >> Sorry that I have to ask again. I tried to explain the IPFIX use case in >> http://www.ietf.org/mail-archive/web/netmod/current/msg03297.html >> I only got one answer by Phil which did not really clarify the issue. >> >> Up to now, I've thought that "mandatory" means "MUST be provided by the >> user". Apparently, this is not true for top-level nodes. I'm confused. >> >> Does "mandatory" mean that the agent will create the node if it is >> missing (i.e., not provided by the user)? >> Is this a general rule or does this only apply to top-level nodes? >> >> For me, it is important to know if there is a difference because we have >> nodes in non-mandatory containers which will be created by the device if >> not created by the user. Do I have to declare them mandatory as well? >> >> Thanks, >> Gerhard >> >> >>>> If an agent is free to choose what mandatory means, >>>> then since all YANG modules need to >>>> work with all conforming NETCONF implementations, >>>> the top-level cannot be mandatory. >>> The agent is not free to choose what mandatory means. It means that >>> the leaf MUST exist in a valid data store. >>> >>>> leafref objects are allowed to point at non-existent >>>> nodes in YANG but this is not implementable on >>>> the agent. If the pointed-at object is not present, >>>> then any object pointing at that object must also >>>> be removed from the agent (ripple out until done). >>> I assume you refer to leafrefs which point to leafs with if-feature? >>> As I wrote in the other email thread, I think this is a valid concern, >>> and we should fix it. I prefer to keep the discussion in one email >>> thread though. >>> >>>> YANG is already extremely difficult to learn. >>> I don't know what you base this on, and I don't know what do to with >>> this comment. From my experience with pioneer YANG writers, I >>> disagree though. >>> >>> >>> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Mon Aug 17 07:19: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 824C33A6B7F for ; Mon, 17 Aug 2009 07:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.102, 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 12HclYj7-Bmr for ; Mon, 17 Aug 2009 07:19:43 -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 BE0113A6A31 for ; Mon, 17 Aug 2009 07:19:43 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9EF7476C4E3; Mon, 17 Aug 2009 16:19:47 +0200 (CEST) Date: Mon, 17 Aug 2009 16:19:47 +0200 (CEST) Message-Id: <20090817.161947.131109689.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A896173.8070301@netconfcentral.com> References: <4A893CEC.6020208@net.in.tum.de> <1250515467.21629.34.camel@missotis> <4A896173.8070301@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] YANG must work with NETCONF 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: Mon, 17 Aug 2009 14:19:44 -0000 Andy Bierman wrote: > I must say that I was surprised to find out that > mandatory doesn't mean the manager must provide a value. The intention is that the manager must provide a value. > That worries me, because if I do not want any default > in my data model, and I want all implementations of this model > to fail unless the mandatory node is set Yes. > there is no way to do that > in YANG. Any agent is free to make up a value for a mandatory leaf. No, that is not the intention. > This is not the same is pre-loading the /system or /interfaces > subtrees. Lists and containers cannot have the mandatory-stmt. > They do not matter here. But the leaf /system/sysName might be mandatory, and can be preloaded. /martin From lhotka@cesnet.cz Mon Aug 17 07:27: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 1D90E3A672E for ; Mon, 17 Aug 2009 07:27:12 -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 PZriXca5CNo6 for ; Mon, 17 Aug 2009 07:27:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0455028C18F for ; Mon, 17 Aug 2009 07:27: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 8E992D800BD for ; Mon, 17 Aug 2009 16:27:15 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4A896173.8070301@netconfcentral.com> References: <4A893CEC.6020208@net.in.tum.de> <1250515467.21629.34.camel@missotis> <4A896173.8070301@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 16:27:14 +0200 Message-Id: <1250519234.21629.48.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 14:27:12 -0000 Andy Bierman píše v Po 17. 08. 2009 v 06:56 -0700: > I must say that I was surprised to find out that > mandatory doesn't mean the manager must provide a value. > That worries me, because if I do not want any default > in my data model, and I want all implementations of this model > to fail unless the mandatory node is set, there is no way to do that > in YANG. Any agent is free to make up a value for a mandatory leaf. That's why I'd prefer to handle the defaults as a separate problem from mandatory/optional. Parameters like MTU for an interface will most likely be configured to a value even in a virgin device (or hardwired in a dumb device), but in my view MTU is mandatory because the interface cannot work without having the value. Lada > > This is not the same is pre-loading the /system or /interfaces > subtrees. Lists and containers cannot have the mandatory-stmt. > They do not matter here. > > > > Lada > > > > > Andy > > > > Gerhard Muenz píše v Po 17. 08. 2009 v 13:20 +0200: > >> Hi, > >> > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> There are several details in YANG that are legal, > >>>> yet they represent data models which cannot possibly > >>>> be supported on any NETCONF agent. > >>>> > >>>> Mandatory top-level nodes are allowed in YANG > >>>> but not supportable in a NETCONF agent. > >>> I disagree. See the email thread "mandatory mess". If you have a > >>> top-level mandatory leaf, it MUST have a value in a valid database. > >>> So, when the system has started and the NETCONF i/f is up and running, > >>> the leaf MUST exist. A user can then modify it, but not delete it. > >> Sorry that I have to ask again. I tried to explain the IPFIX use case in > >> http://www.ietf.org/mail-archive/web/netmod/current/msg03297.html > >> I only got one answer by Phil which did not really clarify the issue. > >> > >> Up to now, I've thought that "mandatory" means "MUST be provided by the > >> user". Apparently, this is not true for top-level nodes. I'm confused. > >> > >> Does "mandatory" mean that the agent will create the node if it is > >> missing (i.e., not provided by the user)? > >> Is this a general rule or does this only apply to top-level nodes? > >> > >> For me, it is important to know if there is a difference because we have > >> nodes in non-mandatory containers which will be created by the device if > >> not created by the user. Do I have to declare them mandatory as well? > >> > >> Thanks, > >> Gerhard > >> > >> > >>>> If an agent is free to choose what mandatory means, > >>>> then since all YANG modules need to > >>>> work with all conforming NETCONF implementations, > >>>> the top-level cannot be mandatory. > >>> The agent is not free to choose what mandatory means. It means that > >>> the leaf MUST exist in a valid data store. > >>> > >>>> leafref objects are allowed to point at non-existent > >>>> nodes in YANG but this is not implementable on > >>>> the agent. If the pointed-at object is not present, > >>>> then any object pointing at that object must also > >>>> be removed from the agent (ripple out until done). > >>> I assume you refer to leafrefs which point to leafs with if-feature? > >>> As I wrote in the other email thread, I think this is a valid concern, > >>> and we should fix it. I prefer to keep the discussion in one email > >>> thread though. > >>> > >>>> YANG is already extremely difficult to learn. > >>> I don't know what you base this on, and I don't know what do to with > >>> this comment. From my experience with pioneer YANG writers, I > >>> disagree though. > >>> > >>> > >>> /martin > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Aug 17 07:36: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 E0C343A6AC3 for ; Mon, 17 Aug 2009 07:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 EABtRNCfNaY5 for ; Mon, 17 Aug 2009 07:36:47 -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 24B053A6A5A for ; Mon, 17 Aug 2009 07:36:47 -0700 (PDT) Received: from [68.142.200.227] by n10.bullet.mail.mud.yahoo.com with NNFMP; 17 Aug 2009 14:36:50 -0000 Received: from [68.142.201.68] by t8.bullet.mud.yahoo.com with NNFMP; 17 Aug 2009 14:36:50 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 17 Aug 2009 14:36:50 -0000 X-Yahoo-Newman-Id: 458104.92750.bm@omp420.mail.mud.yahoo.com Received: (qmail 63220 invoked from network); 17 Aug 2009 14:36:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 17 Aug 2009 14:36:49 -0000 X-YMail-OSG: rSj_p2UVM1kfEQ5J0mMYffbhv7ryVy05udRphYoXOP.Gi4ykqITv_ij49RfuOi6j0oFIEybtk1eO6Kr888NG_.KPTO1aqPIJeyMgdnMCMp2Nvw_MH7aDNyXrlnHQVASngPBsassxXe2nHjodISFt8n9eSEmYaAH2eInhmSUBb2kOB82OX1YMj.86rTI2WIorQiWCoEyO30OgsvHzwYQ8VcsmOUaGQLgQMvggbNDKBUrNLAdfOIl7LTja1EgcaqUqHhwukWogYuS9WgWWR5ZFFE8r7XK6T2TDkFGaP1BB8HvUxNAob.k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A896B11.8010700@netconfcentral.com> Date: Mon, 17 Aug 2009 07:37:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 14:36:48 -0000 Hi, We know that we are trying to represent 3 states with a boolean -- this has been brought in several times in the past. I do not want to replace 'mandatory' with 'agent-provided'. Why not solve the problem instead of pretending it is an agent implementation choice? Because it isn't. It is a data model designer's choice. 1) mandatory true means the manager must provide a value 2) 2 forms of default are needed: OLD: default-stmt = default-keyword sep string stmtend NEW: default-stmt = (agent-provided-keyword / default-keyword sep string) stmtend agent-provided-keyword = 'agent-provided' EXAMPLE: leaf A { description "manager must provide a value"; type string; mandatory true; } leaf B { description "agent must provide a value if the manager does not provide one"; type string; agent-default; } leaf C { description "agent must provide the specified default if the manager does not provide a value."; type string; default 'fred'; } IMO, this would solve the problem better than combining A and B. Andy From lhotka@cesnet.cz Mon Aug 17 07:50: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 3FF353A6EBC for ; Mon, 17 Aug 2009 07:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_05=-1.11, 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 REsH0x-W5jAA for ; Mon, 17 Aug 2009 07:50:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 74B813A699F for ; Mon, 17 Aug 2009 07:50:32 -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 EB540D800BD; Mon, 17 Aug 2009 16:50:36 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090731.165515.82188649.mbj@tail-f.com> References: <4A7061A6.6050903@netconfcentral.com> <1248947407.5754.24.camel@nomad> <4A7200AB.9030905@netconfcentral.com> <20090731.165515.82188649.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 16:50:35 +0200 Message-Id: <1250520635.21629.62.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] prefixes in groupings example 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: Mon, 17 Aug 2009 14:50:33 -0000 Hi, after two weeks of vacations I don't dare to reply to any particular post in this loooong thread. While I do believe the rules below could work, I have to agree with Andy and Tom that they are far from intuitive. Perhaps some simplification options should be considered, for example: What if typedefs were only allowed at the top level of a module? What are the use cases for having them elsewhere? Lada Martin Bjorklund píše v Pá 31. 07. 2009 v 16:55 +0200: > Andy Bierman wrote: > > I updated my example to show some of the ambiguities > > that need to be cleared up. > > > > It would be nice if there was a simple consistent rule > > that applied to all statements, inside or outside a grouping, > > and regardless of which module contains the uses-stmt. > > This is what we came up with: > > o The set of namespace declarations is the set of all "import" > statements' prefix and namespace pairs in the module where the > XPath expression is specified, and the "prefix" statement's prefix > for the "namespace" statement's URI. > > This says that the prefix is bound to a namespace in the module where > the must/when expression occurs. > > o Names without a namespace prefix belong to the same namespace as > the identifier of the current node. Inside a grouping that > namespace is affected by where the grouping is used (see > Section 7.12). > > And in section 7.12: > > The identifiers defined in the grouping are not bound to a namespace > until the contents of the grouping are added to the schema tree via a > "uses" statement that does not appear inside a "grouping" statement, > a which point they are bound to the namespace of the current module. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Aug 17 07:56: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 CF15C3A6B2D for ; Mon, 17 Aug 2009 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 I7RKDPvH9PM7 for ; Mon, 17 Aug 2009 07:56:38 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id EBE053A6A31 for ; Mon, 17 Aug 2009 07:56:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSolvqfJWI8GIcIO0wALhWtIcy2qS9X+3@postini.com; Mon, 17 Aug 2009 07:56:43 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; Mon, 17 Aug 2009 07:49:36 -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); Mon, 17 Aug 2009 07:49:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 07:49:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 07:49:35 -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 n7HEnYd75470; Mon, 17 Aug 2009 07:49:34 -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 n7HEbjCR026249; Mon, 17 Aug 2009 14:37:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908171437.n7HEbjCR026249@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1250519234.21629.48.camel@missotis> Date: Mon, 17 Aug 2009 10:37:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Aug 2009 14:49:35.0064 (UTC) FILETIME=[EFDAAD80:01CA1F49] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 14:56:38 -0000 Ladislav Lhotka writes: >Parameters like MTU for an interface will most >likely be configured to a value even in a virgin device (or hardwired in >a dumb device), but in my view MTU is mandatory because the interface >cannot work without having the value. This makes a great example for explaining the YANG take on defaults and mandatory. An operating interface must have an MTU, but the configuration for that MTU is not considered mandatory in YANG, since the device will provide a default value if there is not one in the configuration. Thanks, Phil From lhotka@cesnet.cz Mon Aug 17 08:09: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 33A443A6F22 for ; Mon, 17 Aug 2009 08:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[AWL=0.097, 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 2dGK4QUO4tG2 for ; Mon, 17 Aug 2009 08:09:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 73BED3A6F1F for ; Mon, 17 Aug 2009 08:09:48 -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 60C91D80095 for ; Mon, 17 Aug 2009 17:09:53 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4A896B11.8010700@netconfcentral.com> References: <4A896B11.8010700@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 17:09:51 +0200 Message-Id: <1250521791.21629.77.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 15:09:56 -0000 Andy Bierman píše v Po 17. 08. 2009 v 07:37 -0700: > Hi, > > We know that we are trying to represent 3 states > with a boolean -- this has been brought in several > times in the past. > > I do not want to replace 'mandatory' with 'agent-provided'. > Why not solve the problem instead of pretending it is > an agent implementation choice? Because it isn't. > It is a data model designer's choice. Another and IMO simpler option is to decouple mandatory/optional and default: 1. A leaf is mandatory if it must be present in a valid configuration, unless it is contained in a container with presence or a choice's case (these two cases require special handling). 2. Default values defined in the data model is an indication for the server about which values are to be suppressed when returning the configuration in the mode with-defaults=false. So if the factory setup of a device assumes valid configuration, all mandatory leafs must be provided, either to a default specified in a data model or to something else. Therefore, 'mandatory' and 'default' wouldn't be mutually exclusive. Lada > > 1) mandatory true means the manager must provide a value > > 2) 2 forms of default are needed: > > OLD: > > default-stmt = default-keyword sep string stmtend > > NEW: > > default-stmt = (agent-provided-keyword / > default-keyword sep string) stmtend > > agent-provided-keyword = 'agent-provided' > > EXAMPLE: > > leaf A { > description > "manager must provide a value"; > type string; > mandatory true; > } > > leaf B { > description > "agent must provide a value if the manager does > not provide one"; > type string; > agent-default; > } > > leaf C { > description > "agent must provide the specified default if the > manager does not provide a value."; > type string; > default 'fred'; > } > > > IMO, this would solve the problem better than combining A and B. > > > > Andy > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Aug 17 08:12: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 787743A6A0D for ; Mon, 17 Aug 2009 08:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 CtpeuJxxs5RT for ; Mon, 17 Aug 2009 08:12:56 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 86F613A6DA4 for ; Mon, 17 Aug 2009 08:12:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSolzfKuHIQ/k3T12v4QOQ+VE5J1nnSWO@postini.com; Mon, 17 Aug 2009 08:13: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; Mon, 17 Aug 2009 08:07:15 -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); Mon, 17 Aug 2009 08:07:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 08:07:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 08:07:14 -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 n7HF7Ed86017; Mon, 17 Aug 2009 08:07:14 -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 n7HEtP1r026596; Mon, 17 Aug 2009 14:55:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908171455.n7HEtP1r026596@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A896B11.8010700@netconfcentral.com> Date: Mon, 17 Aug 2009 10:55:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Aug 2009 15:07:14.0363 (UTC) FILETIME=[673EE0B0:01CA1F4C] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 15:12:57 -0000 Andy Bierman writes: >I do not want to replace 'mandatory' with 'agent-provided'. s/agent/server/ or /system/ Using the term "agent" is SNMP-specific, and does not work with folks who are not aware of the odd way this protocol used this term. It is needlessly confusing and we are trying to move to more modern terms. In normal CS terminology, an agent is a semi-independent piece of software that acts on behalf of a user, which is very different from the "server" role that the netconf server performs. The existing proposal for "assigned-by system" solves the problem you are refering to. Thanks, Phil From lhotka@cesnet.cz Mon Aug 17 08:13: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 966C73A6F27 for ; Mon, 17 Aug 2009 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.091, 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 lnxHOtOWzYZk for ; Mon, 17 Aug 2009 08:13:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A5C073A6DA4 for ; Mon, 17 Aug 2009 08:13:43 -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 A65C3D80095; Mon, 17 Aug 2009 17:13:48 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908171437.n7HEbjCR026249@idle.juniper.net> References: <200908171437.n7HEbjCR026249@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 17:13:46 +0200 Message-Id: <1250522026.21629.80.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 15:13:44 -0000 Phil Shafer píše v Po 17. 08. 2009 v 10:37 -0400: > Ladislav Lhotka writes: > >Parameters like MTU for an interface will most > >likely be configured to a value even in a virgin device (or hardwired in > >a dumb device), but in my view MTU is mandatory because the interface > >cannot work without having the value. > > This makes a great example for explaining the YANG take on defaults > and mandatory. > > An operating interface must have an MTU, but the configuration for > that MTU is not considered mandatory in YANG, since the device will > provide a default value if there is not one in the configuration. What is the relationship of this "default value" to YANG 'default' statement? Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 17 08:39: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 75EA23A6F3E for ; Mon, 17 Aug 2009 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 9lt7xWsbh0MK for ; Mon, 17 Aug 2009 08:39:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D187D3A6F3B for ; Mon, 17 Aug 2009 08:38:55 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9721AC0069; Mon, 17 Aug 2009 17:39:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yOtxOQrRRbaD; Mon, 17 Aug 2009 17:38:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 998D7C0051; Mon, 17 Aug 2009 17:38:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8E456C6F2A6; Mon, 17 Aug 2009 17:38:57 +0200 (CEST) Date: Mon, 17 Aug 2009 17:38:57 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090817153857.GB3661@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , NETMOD Working Group References: <200908171437.n7HEbjCR026249@idle.juniper.net> <1250522026.21629.80.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250522026.21629.80.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 15:39:54 -0000 On Mon, Aug 17, 2009 at 05:13:46PM +0200, Ladislav Lhotka wrote: > Phil Shafer p????e v Po 17. 08. 2009 v 10:37 -0400: > > Ladislav Lhotka writes: > > >Parameters like MTU for an interface will most > > >likely be configured to a value even in a virgin device (or hardwired in > > >a dumb device), but in my view MTU is mandatory because the interface > > >cannot work without having the value. > > > > This makes a great example for explaining the YANG take on defaults > > and mandatory. > > > > An operating interface must have an MTU, but the configuration for > > that MTU is not considered mandatory in YANG, since the device will > > provide a default value if there is not one in the configuration. > > What is the relationship of this "default value" to YANG 'default' > statement? None. If you plug a PCMCIA network card in your notebook, you will see a suitable MTU - you did not configure it nor is it going to be the same for all possible network cards. /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 Mon Aug 17 08:41: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 A6C763A6AFA for ; Mon, 17 Aug 2009 08:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 dJ80b290VhTU for ; Mon, 17 Aug 2009 08:41:15 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 76D773A68D2 for ; Mon, 17 Aug 2009 08:41:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSol6H9s+XBpDolGvd96iaM63gAMnDyuN@postini.com; Mon, 17 Aug 2009 08:41:20 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; Mon, 17 Aug 2009 08:34:10 -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); Mon, 17 Aug 2009 08:34:10 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 08:34:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 08:34:09 -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 n7HFY9d02876; Mon, 17 Aug 2009 08:34:09 -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 n7HFMKRw026896; Mon, 17 Aug 2009 15:22:20 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908171522.n7HFMKRw026896@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1250522026.21629.80.camel@missotis> Date: Mon, 17 Aug 2009 11:22:20 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Aug 2009 15:34:09.0437 (UTC) FILETIME=[29E79CD0:01CA1F50] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 15:41:23 -0000 Ladislav Lhotka writes: >> An operating interface must have an MTU, but the configuration for >> that MTU is not considered mandatory in YANG, since the device will >> provide a default value if there is not one in the configuration. >What is the relationship of this "default value" to YANG 'default' >statement? They are identical. Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Aug 17 08:42: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 ED86228C16B for ; Mon, 17 Aug 2009 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 5hOUc4jGMrfa for ; Mon, 17 Aug 2009 08:42: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 03B703A6F21 for ; Mon, 17 Aug 2009 08:42:24 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDE4CC0069; Mon, 17 Aug 2009 17:42:28 +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 6TjyvCn6MF3h; Mon, 17 Aug 2009 17:42:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21B92C0051; Mon, 17 Aug 2009 17:42:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0DA28C6F35B; Mon, 17 Aug 2009 17:42:27 +0200 (CEST) Date: Mon, 17 Aug 2009 17:42:26 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090817154226.GC3661@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250521791.21629.77.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 15:42:25 -0000 On Mon, Aug 17, 2009 at 05:09:51PM +0200, Ladislav Lhotka wrote: > 2. Default values defined in the data model is an indication for the > server about which values are to be suppressed when returning the > configuration in the mode with-defaults=false. Sounds like we are designing something completely new now... /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 Mon Aug 17 08:48: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 E27F528C14E for ; Mon, 17 Aug 2009 08:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 y-Pl95N2t1pu for ; Mon, 17 Aug 2009 08:48:44 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 1E2B528C0E3 for ; Mon, 17 Aug 2009 08:48:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSol73YHXFpIjCUV8dN+5plamk0DGY+MN@postini.com; Mon, 17 Aug 2009 08:48:49 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; Mon, 17 Aug 2009 08:42:21 -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); Mon, 17 Aug 2009 08:42:21 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 08:42:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 08:42:19 -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 n7HFgJd08037; Mon, 17 Aug 2009 08:42:19 -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 n7HFUUY6027104; Mon, 17 Aug 2009 15:30:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908171530.n7HFUUY6027104@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090817153857.GB3661@elstar.local> Date: Mon, 17 Aug 2009 11:30:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Aug 2009 15:42:19.0843 (UTC) FILETIME=[4E35A130:01CA1F51] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 15:48:45 -0000 Juergen Schoenwaelder writes: >None. If you plug a PCMCIA network card in your notebook, you will see >a suitable MTU - you did not configure it nor is it going to be the >same for all possible network cards. Depending on if the 'default' statement appears inside the model. If the model has a default statement and the configuration was made using this model, then the device should honor that model's default value. Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Aug 17 09:14: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 6045F3A6D3A for ; Mon, 17 Aug 2009 09:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 SWUec7SfaGEb for ; Mon, 17 Aug 2009 09:14:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CACF13A6F3C for ; Mon, 17 Aug 2009 09:14:33 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91484C006A; Mon, 17 Aug 2009 18:14:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KyXJ4m1d2XHh; Mon, 17 Aug 2009 18:14:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90CEAC0051; Mon, 17 Aug 2009 18:14:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 879D7C6F4A1; Mon, 17 Aug 2009 18:14:36 +0200 (CEST) Date: Mon, 17 Aug 2009 18:14:36 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090817161436.GA3731@elstar.local> Mail-Followup-To: Phil Shafer , Ladislav Lhotka , NETMOD Working Group References: <20090817153857.GB3661@elstar.local> <200908171530.n7HFUUY6027104@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908171530.n7HFUUY6027104@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 16:14:55 -0000 On Mon, Aug 17, 2009 at 05:30:30PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >None. If you plug a PCMCIA network card in your notebook, you will see > >a suitable MTU - you did not configure it nor is it going to be the > >same for all possible network cards. > > Depending on if the 'default' statement appears inside the model. > If the model has a default statement and the configuration was > made using this model, then the device should honor that model's > default value. But in the example we discussed, such a default statement does not make sense. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Aug 17 10:59: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 E345E28C2E9 for ; Mon, 17 Aug 2009 10:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=0.087, 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 qJ5kLVAcFQtO for ; Mon, 17 Aug 2009 10:59:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B99B028C2CF for ; Mon, 17 Aug 2009 10:59:19 -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 6296AD80095; Mon, 17 Aug 2009 19:59:23 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090817153857.GB3661@elstar.local> References: <200908171437.n7HEbjCR026249@idle.juniper.net> <1250522026.21629.80.camel@missotis> <20090817153857.GB3661@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 19:59:21 +0200 Message-Id: <1250531961.21629.112.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 17:59:56 -0000 Juergen Schoenwaelder píše v Po 17. 08. 2009 v 17:38 +0200: > On Mon, Aug 17, 2009 at 05:13:46PM +0200, Ladislav Lhotka wrote: > > Phil Shafer p????e v Po 17. 08. 2009 v 10:37 -0400: > > > Ladislav Lhotka writes: > > > >Parameters like MTU for an interface will most > > > >likely be configured to a value even in a virgin device (or hardwired in > > > >a dumb device), but in my view MTU is mandatory because the interface > > > >cannot work without having the value. > > > > > > This makes a great example for explaining the YANG take on defaults > > > and mandatory. > > > > > > An operating interface must have an MTU, but the configuration for > > > that MTU is not considered mandatory in YANG, since the device will > > > provide a default value if there is not one in the configuration. > > > > What is the relationship of this "default value" to YANG 'default' > > statement? > > None. If you plug a PCMCIA network card in your notebook, you will see > a suitable MTU - you did not configure it nor is it going to be the > same for all possible network cards. I think making the notion of mandatory dependent on manager actions is broken, especially because there can be multiple managers. Say the "mtu" leaf is declared mandatory in the data model and the device "calls home" after being switched on and the vendor's manager application sets the "mtu" parameter. Is it OK with respect to YANG rules? What's the difference between mandatory and optional in this case? I very much prefer the static notion of optional/mandatory that's common in XML schema languages, which says whether the element must be present in a valid document. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Aug 17 11:06: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 B020D3A6830 for ; Mon, 17 Aug 2009 11:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.082, 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 JbPPGFOA1510 for ; Mon, 17 Aug 2009 11:06:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DE2373A6937 for ; Mon, 17 Aug 2009 11:06:53 -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 DFC19D800BD; Mon, 17 Aug 2009 20:06:58 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090817154226.GC3661@elstar.local> References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 20:06:56 +0200 Message-Id: <1250532416.21629.118.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 18:06:54 -0000 Juergen Schoenwaelder píše v Po 17. 08. 2009 v 17:42 +0200: > On Mon, Aug 17, 2009 at 05:09:51PM +0200, Ladislav Lhotka wrote: > > > 2. Default values defined in the data model is an indication for the > > server about which values are to be suppressed when returning the > > configuration in the mode with-defaults=false. > > Sounds like we are designing something completely new now... I don't think so, I am just trying to give a precise meaning to the 'default' statement because YANG spec does it in a hand-waving way: The "default" statement, which is optional, takes as an argument a string which contains a default value for the leaf. But apparently there are at least two types of default values and one of them has nothing to do with the 'default' statement, as you said in another mail. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 17 11:30: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 531F43A689E for ; Mon, 17 Aug 2009 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 rJgplgDxG2cm for ; Mon, 17 Aug 2009 11:30:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4B6B83A6BFF for ; Mon, 17 Aug 2009 11:30:10 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 163EEC006D; Mon, 17 Aug 2009 20:30:15 +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 vBgIn0te9kJ5; Mon, 17 Aug 2009 20:30:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3665EC006C; Mon, 17 Aug 2009 20:30:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2EB61C6F880; Mon, 17 Aug 2009 20:30:13 +0200 (CEST) Date: Mon, 17 Aug 2009 20:30:13 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090817183013.GB4255@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250532416.21629.118.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 18:30:11 -0000 On Mon, Aug 17, 2009 at 08:06:56PM +0200, Ladislav Lhotka wrote: > > > > Sounds like we are designing something completely new now... > > I don't think so, I am just trying to give a precise meaning to the > 'default' statement because YANG spec does it in a hand-waving way: > > The "default" statement, which is optional, takes as an argument a > string which contains a default value for the leaf. It has been clear to us I thought up until now that the YANG default statement is like the SMIv2 DEFAULT clause except that the value is binding. And here is another quote from YANG: If a leaf has a "default" statement, the leaf's default value is set to 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 set to the type's default value. In all other cases, the leaf does not have a default value. If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. I think this is a much better quote than what you did select. > But apparently there are at least two types of default values and one of > them has nothing to do with the 'default' statement, as you said in > another mail. There are system assigned values and yes a system assigned value is not the same as a default. The MTU of an interface is system assigned based on the system's knowledge of the hardware. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Aug 17 11:33: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 052F83A689E for ; Mon, 17 Aug 2009 11:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=0.078, 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 brgNcfdk7qI5 for ; Mon, 17 Aug 2009 11:33:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 33A383A67BE for ; Mon, 17 Aug 2009 11:33:23 -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 4FAF9D80096; Mon, 17 Aug 2009 20:33:24 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908171522.n7HFMKRw026896@idle.juniper.net> References: <200908171522.n7HFMKRw026896@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 20:33:22 +0200 Message-Id: <1250534002.21629.123.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 18:33:24 -0000 Phil Shafer píše v Po 17. 08. 2009 v 11:22 -0400: > Ladislav Lhotka writes: > >> An operating interface must have an MTU, but the configuration for > >> that MTU is not considered mandatory in YANG, since the device will > >> provide a default value if there is not one in the configuration. > >What is the relationship of this "default value" to YANG 'default' > >statement? > > They are identical. If there is no 'default' statement in the data model, perhaps because there is no single "right" default value, the "vendor default" may (must) still be set, if I understand you correctly. So they are not identical. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Aug 17 11:34: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 459E23A6F60 for ; Mon, 17 Aug 2009 11:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.075, 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 6GqUIheTm9Bf for ; Mon, 17 Aug 2009 11:34:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 974353A6F73 for ; Mon, 17 Aug 2009 11:34:49 -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 6F0E9D80095; Mon, 17 Aug 2009 20:34:54 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908171530.n7HFUUY6027104@idle.juniper.net> References: <200908171530.n7HFUUY6027104@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 20:34:52 +0200 Message-Id: <1250534092.21629.125.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 18:34:58 -0000 Phil Shafer píše v Po 17. 08. 2009 v 11:30 -0400: > Juergen Schoenwaelder writes: > >None. If you plug a PCMCIA network card in your notebook, you will see > >a suitable MTU - you did not configure it nor is it going to be the > >same for all possible network cards. > > Depending on if the 'default' statement appears inside the model. > If the model has a default statement and the configuration was > made using this model, then the device should honor that model's > default value. Where is this specified? Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Aug 17 12:03: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 C41E83A6F83 for ; Mon, 17 Aug 2009 12:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Txc3ZIW8Ln4Q for ; Mon, 17 Aug 2009 12:03:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B56713A6F58 for ; Mon, 17 Aug 2009 12:03:50 -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 990B8D80095; Mon, 17 Aug 2009 21:03:55 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090817183013.GB4255@elstar.local> References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 21:03:53 +0200 Message-Id: <1250535833.21629.147.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 19:03:51 -0000 Juergen Schoenwaelder píše v Po 17. 08. 2009 v 20:30 +0200: > On Mon, Aug 17, 2009 at 08:06:56PM +0200, Ladislav Lhotka wrote: > > > > > > Sounds like we are designing something completely new now... > > > > I don't think so, I am just trying to give a precise meaning to the > > 'default' statement because YANG spec does it in a hand-waving way: > > > > The "default" statement, which is optional, takes as an argument a > > string which contains a default value for the leaf. > > It has been clear to us I thought up until now that the YANG default > statement is like the SMIv2 DEFAULT clause except that the value is > binding. And here is another quote from YANG: > > If a leaf has a "default" statement, the leaf's default value is set > to 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 set to the type's default value. In all > other cases, the leaf does not have a default value. > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. > > I think this is a much better quote than what you did select. The problem is with "the NETCONF client". If I wanted to work around any defaults specified in the data model, I would equip my device with a script declared as "built-in NETCONF client" that automatically creates the instances a sets their value to anything within the limits of the datatypes. This satisfies the above requirement but from the human user's point of view the defaults specified in the data model mean nothing. Lada > > > But apparently there are at least two types of default values and one of > > them has nothing to do with the 'default' statement, as you said in > > another mail. > > There are system assigned values and yes a system assigned value is > not the same as a default. The MTU of an interface is system assigned > based on the system's knowledge of the hardware. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 17 12:04: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 F1FE33A6CCA for ; Mon, 17 Aug 2009 12:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 XziLrJxQpvET for ; Mon, 17 Aug 2009 12:04:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4D6D33A6F96 for ; Mon, 17 Aug 2009 12:04:52 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DF39C006D; Mon, 17 Aug 2009 21:04:56 +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 cv+rkSrZ9w2A; Mon, 17 Aug 2009 21:04:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3F94C006C; Mon, 17 Aug 2009 21:04:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CDD13C6FA19; Mon, 17 Aug 2009 21:04:53 +0200 (CEST) Date: Mon, 17 Aug 2009 21:04:53 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090817190453.GE4255@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , NETMOD Working Group References: <200908171437.n7HEbjCR026249@idle.juniper.net> <1250522026.21629.80.camel@missotis> <20090817153857.GB3661@elstar.local> <1250531961.21629.112.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250531961.21629.112.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 19:04:58 -0000 On Mon, Aug 17, 2009 at 07:59:21PM +0200, Ladislav Lhotka wrote: > I think making the notion of mandatory dependent on manager actions is > broken, especially because there can be multiple managers. Say the "mtu" > leaf is declared mandatory in the data model and the device "calls home" > after being switched on and the vendor's manager application sets the > "mtu" parameter. Is it OK with respect to YANG rules? What's the > difference between mandatory and optional in this case? Section 7.6.4 spells out what mandatory means. Can you phrase your question relative to the text in 7.6.4? > I very much prefer the static notion of optional/mandatory that's common > in XML schema languages, which says whether the element must be present > in a valid document. I think this is what section 7.6.4 says. It establishes an existance constraint on leafs. What is wrong with that? /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 Mon Aug 17 12:11: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 058163A6F85 for ; Mon, 17 Aug 2009 12:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 59uW+ZuAJkvR for ; Mon, 17 Aug 2009 12:11:08 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id E007A3A68A3 for ; Mon, 17 Aug 2009 12:11:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSomrT9Zd36TtMJPrjW8BKtpH3hYJxATX@postini.com; Mon, 17 Aug 2009 12:11:13 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; Mon, 17 Aug 2009 12:03:51 -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); Mon, 17 Aug 2009 12:03:51 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 12:03:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 12:03:49 -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 n7HJ3nd40491; Mon, 17 Aug 2009 12:03:49 -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 n7HIq052028666; Mon, 17 Aug 2009 18:52:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908171852.n7HIq052028666@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1250534002.21629.123.camel@missotis> Date: Mon, 17 Aug 2009 14:51:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Aug 2009 19:03:49.0910 (UTC) FILETIME=[74737360:01CA1F6D] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 19:11:09 -0000 Ladislav Lhotka writes: >> >What is the relationship of this "default value" to YANG 'default' >> >statement? >> >> They are identical. > >If there is no 'default' statement in the data model, perhaps because >there is no single "right" default value, the "vendor default" may >(must) still be set, if I understand you correctly. So they are not >identical. Yup, if there's no default statement in the data model, they are not identical, and there's no relationship (since having a relationship with something that does not exist is difficult). Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Aug 17 12:15:01 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 095CA3A6F95 for ; Mon, 17 Aug 2009 12:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Tz316zEfOLBT for ; Mon, 17 Aug 2009 12:15:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 38BD63A6CCE for ; Mon, 17 Aug 2009 12:14:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05294C006D; Mon, 17 Aug 2009 21:14:44 +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 xBhqXLtEgMni; Mon, 17 Aug 2009 21:14:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 326ACC006C; Mon, 17 Aug 2009 21:14:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C781C6FB27; Mon, 17 Aug 2009 21:14:42 +0200 (CEST) Date: Mon, 17 Aug 2009 21:14:42 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090817191442.GA4407@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250535833.21629.147.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 19:15:01 -0000 On Mon, Aug 17, 2009 at 09:03:53PM +0200, Ladislav Lhotka wrote: > The problem is with "the NETCONF client". If I wanted to work around > any defaults specified in the data model, I would equip my device > with a script declared as "built-in NETCONF client" that > automatically creates the instances a sets their value to anything > within the limits of the datatypes. This satisfies the above > requirement but from the human user's point of view the defaults > specified in the data model mean nothing. You are having a problem that can't be fixed with a specification. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Aug 17 12:24: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 142D828C264 for ; Mon, 17 Aug 2009 12:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.069, 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 tpJx1YazZHwy for ; Mon, 17 Aug 2009 12:24:56 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 828B328C304 for ; Mon, 17 Aug 2009 12:24:35 -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 402CCD80095; Mon, 17 Aug 2009 21:24:40 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090817190453.GE4255@elstar.local> References: <200908171437.n7HEbjCR026249@idle.juniper.net> <1250522026.21629.80.camel@missotis> <20090817153857.GB3661@elstar.local> <1250531961.21629.112.camel@missotis> <20090817190453.GE4255@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 21:24:38 +0200 Message-Id: <1250537078.21629.152.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 19:24:57 -0000 Juergen Schoenwaelder píše v Po 17. 08. 2009 v 21:04 +0200: > On Mon, Aug 17, 2009 at 07:59:21PM +0200, Ladislav Lhotka wrote: > > > I think making the notion of mandatory dependent on manager actions is > > broken, especially because there can be multiple managers. Say the "mtu" > > leaf is declared mandatory in the data model and the device "calls home" > > after being switched on and the vendor's manager application sets the > > "mtu" parameter. Is it OK with respect to YANG rules? What's the > > difference between mandatory and optional in this case? > > Section 7.6.4 spells out what mandatory means. Can you phrase your > question relative to the text in 7.6.4? > > > I very much prefer the static notion of optional/mandatory that's common > > in XML schema languages, which says whether the element must be present > > in a valid document. > > I think this is what section 7.6.4 says. It establishes an existance > constraint on leafs. What is wrong with that? Nothing, and I am perfectly fine with it, but it also doesn't say that mandatory leafs must be set by the manager, unless "MUST exist" means that. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Aug 17 12:26: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 F14A828C305 for ; Mon, 17 Aug 2009 12:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, 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 xlLNqMPLstk9 for ; Mon, 17 Aug 2009 12:26:12 -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 3284128C2FD for ; Mon, 17 Aug 2009 12:26:12 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2571376C4E3; Mon, 17 Aug 2009 21:26:16 +0200 (CEST) Date: Mon, 17 Aug 2009 21:26:15 +0200 (CEST) Message-Id: <20090817.212615.111397162.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A896B11.8010700@netconfcentral.com> References: <4A896B11.8010700@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] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 19:26:13 -0000 Andy Bierman wrote: > Hi, > > We know that we are trying to represent 3 states > with a boolean -- this has been brought in several > times in the past. > > I do not want to replace 'mandatory' with 'agent-provided'. > Why not solve the problem instead of pretending it is > an agent implementation choice? Because it isn't. > It is a data model designer's choice. While I agree with all this, I think the consensus was to not include a specific statement for this in YANG 1.0. See the ML thread starting at http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html. I think the approach taken by Gerhard in the ipfix module is what can be done in YANG 1.0 - i.e. make the leaf optional and describe the behavior in the description clause. /martin From lhotka@cesnet.cz Mon Aug 17 12:36: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 3C81B3A6CE7 for ; Mon, 17 Aug 2009 12:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=0.066, 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 HGJ2hoAaVXYF for ; Mon, 17 Aug 2009 12:36:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 79D813A6AD3 for ; Mon, 17 Aug 2009 12:36:01 -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 28B8FD80095; Mon, 17 Aug 2009 21:36:06 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090817191442.GA4407@elstar.local> References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 17 Aug 2009 21:36:04 +0200 Message-Id: <1250537764.21629.164.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 19:36:02 -0000 Juergen Schoenwaelder píše v Po 17. 08. 2009 v 21:14 +0200: > On Mon, Aug 17, 2009 at 09:03:53PM +0200, Ladislav Lhotka wrote: > > > The problem is with "the NETCONF client". If I wanted to work around > > any defaults specified in the data model, I would equip my device > > with a script declared as "built-in NETCONF client" that > > automatically creates the instances a sets their value to anything > > within the limits of the datatypes. This satisfies the above > > requirement but from the human user's point of view the defaults > > specified in the data model mean nothing. > > You are having a problem that can't be fixed with a specification. I don't have any problem. The question is: 1. Do we want to enforce the defaults in the data model on vendors? In my view, this is hopeless, see above. 2. Do we want to use defaults in the data model as a mean for simplifying configurations presented to clients? This will work fine: if the value is missing in a get-config reply, ANY client will know that the default value is implied. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 17 12: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 0066B28C333 for ; Mon, 17 Aug 2009 12:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 ZKMiqOk-0QM2 for ; Mon, 17 Aug 2009 12: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 D41FE28C21E for ; Mon, 17 Aug 2009 12:55:23 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CF6BC006E; Mon, 17 Aug 2009 21:55:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3sLTWZkQNrXh; Mon, 17 Aug 2009 21:55:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61EFAC006D; Mon, 17 Aug 2009 21:55:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5C298C6FC24; Mon, 17 Aug 2009 21:55:25 +0200 (CEST) Date: Mon, 17 Aug 2009 21:55:25 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090817195525.GA4453@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , NETMOD Working Group References: <200908171437.n7HEbjCR026249@idle.juniper.net> <1250522026.21629.80.camel@missotis> <20090817153857.GB3661@elstar.local> <1250531961.21629.112.camel@missotis> <20090817190453.GE4255@elstar.local> <1250537078.21629.152.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250537078.21629.152.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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: Mon, 17 Aug 2009 19:55:25 -0000 On Mon, Aug 17, 2009 at 09:24:38PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v Po 17. 08. 2009 v 21:04 +0200: > > On Mon, Aug 17, 2009 at 07:59:21PM +0200, Ladislav Lhotka wrote: > > > > > I think making the notion of mandatory dependent on manager actions is > > > broken, especially because there can be multiple managers. Say the "mtu" > > > leaf is declared mandatory in the data model and the device "calls home" > > > after being switched on and the vendor's manager application sets the > > > "mtu" parameter. Is it OK with respect to YANG rules? What's the > > > difference between mandatory and optional in this case? > > > > Section 7.6.4 spells out what mandatory means. Can you phrase your > > question relative to the text in 7.6.4? > > > > > I very much prefer the static notion of optional/mandatory that's common > > > in XML schema languages, which says whether the element must be present > > > in a valid document. > > > > I think this is what section 7.6.4 says. It establishes an existance > > constraint on leafs. What is wrong with that? > > Nothing, and I am perfectly fine with it, but it also doesn't say that > mandatory leafs must be set by the manager, unless "MUST exist" means > that. Mandatory leafs must exist in a valid configuration. We agree on that I think and it seems we even agree that the text in the ID is fine. The remaining discussion how those leafs are created is more a philosophical discussion about what configuration is in the first place. Some people argue configuration is all information needed to make a (sub)system work while others argue that a (sub)system has a default behaviour that is not part of the (sub)system's configuration as long as it is not changed or set explicitely. As far as I know, this is currently best explained in the :with-defaults document. Unfortunately, the world has not yet reached agreement on a common definition what configuration really is and as long as this does not happen, we will not have a final answer about questions such as "who creates mandatory leafs". So what are our options? a) Agree on a common definition what configuration is. This would solve many problems - but it might be hard to find agreement. b) Accept 2-3 different definitions and be explicit what things mean according to systems following the different approaches. Not nice, lots of work, looks complicated (like the real world). c) Ignore the differences and leave some details open to variations in implementation. This last approach allows us to get started in a timely manner. It might cause additional work later down the road if this technology gets widely used - but this is perhaps goodness because some of this is going to be easier to understand with more implementation and usage experience and perhaps we can have BCPs that describe how to best practice documents what configuration really is or should be. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 17 13:15: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 376873A6DB1 for ; Mon, 17 Aug 2009 13:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 C7nAVYIVZ6Wc for ; Mon, 17 Aug 2009 13:15:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 272223A6D90 for ; Mon, 17 Aug 2009 13:15:38 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 189B3C0071; Mon, 17 Aug 2009 22:15:38 +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 bg3pgLwHnnmt; Mon, 17 Aug 2009 22:15:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3941C006D; Mon, 17 Aug 2009 22:15:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EDB5CC6FCB4; Mon, 17 Aug 2009 22:15:35 +0200 (CEST) Date: Mon, 17 Aug 2009 22:15:35 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090817201535.GB4453@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> <1250537764.21629.164.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250537764.21629.164.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 17 Aug 2009 20:15:39 -0000 On Mon, Aug 17, 2009 at 09:36:04PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v Po 17. 08. 2009 v 21:14 +0200: > > On Mon, Aug 17, 2009 at 09:03:53PM +0200, Ladislav Lhotka wrote: > > > > > The problem is with "the NETCONF client". If I wanted to work around > > > any defaults specified in the data model, I would equip my device > > > with a script declared as "built-in NETCONF client" that > > > automatically creates the instances a sets their value to anything > > > within the limits of the datatypes. This satisfies the above > > > requirement but from the human user's point of view the defaults > > > specified in the data model mean nothing. > > > > You are having a problem that can't be fixed with a specification. > > I don't have any problem. Good to hear. > The question is: > > 1. Do we want to enforce the defaults in the data model on vendors? In > my view, this is hopeless, see above. As hopeless as a SHOULD or MUST - everything can be ignored. The power of specifications has clear limits and if an implementation argues to have an embedded manager that does surprising things to defaults, well let the market decide. Yes, the default statement is a very sharp tool as are must and when statements. I am sure we will have to pay some price while learning how to use these tools and perhaps there will be a BCP after a few years explaining when it is safe to use these tools and when not. > 2. Do we want to use defaults in the data model as a mean for > simplifying configurations presented to clients? This will work fine: if > the value is missing in a get-config reply, ANY client will know that > the default value is implied. This is for me a completely new definition of the default statement and it only makes sense to some interpretations what configuration data really is. So I am not in favour - I would rather drop the default statement altogether instead of using it as a filter. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Aug 18 01:55: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 760A73A69EC for ; Tue, 18 Aug 2009 01:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=0.063, 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 n77LCt2SnjnM for ; Tue, 18 Aug 2009 01:55:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9FE133A67F1 for ; Tue, 18 Aug 2009 01:55:48 -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 9F5BBD80096; Tue, 18 Aug 2009 10:54:00 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090817195525.GA4453@elstar.local> References: <200908171437.n7HEbjCR026249@idle.juniper.net> <1250522026.21629.80.camel@missotis> <20090817153857.GB3661@elstar.local> <1250531961.21629.112.camel@missotis> <20090817190453.GE4255@elstar.local> <1250537078.21629.152.camel@missotis> <20090817195525.GA4453@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 18 Aug 2009 10:53:58 +0200 Message-Id: <1250585638.3645.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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, 18 Aug 2009 08:55:49 -0000 Juergen Schoenwaelder píše v Po 17. 08. 2009 v 21:55 +0200: > > a) Agree on a common definition what configuration is. This would > solve many problems - but it might be hard to find agreement. > > b) Accept 2-3 different definitions and be explicit what things mean > according to systems following the different approaches. Not nice, > lots of work, looks complicated (like the real world). > > c) Ignore the differences and leave some details open to variations in > implementation. > > This last approach allows us to get started in a timely manner. It > might cause additional work later down the road if this technology > gets widely used - but this is perhaps goodness because some of this > is going to be easier to understand with more implementation and usage > experience and perhaps we can have BCPs that describe how to best > practice documents what configuration really is or should be. Well, it means that I would always write the model for network interface with "mtu" declared as mandatory (because this configuration parameter must be present in every valid configuration) but Phil would leave it as optional, as he suggested. I think this is a problem. My preference is clearly (a). The fact that one approach just presents a diff against a system-assigned configuration can be accomodated in this scenario. Lada Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Aug 18 01:59: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 EA75F3A69EC for ; Tue, 18 Aug 2009 01:59:24 -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 8K4fQ7Sc3JEz for ; Tue, 18 Aug 2009 01:59:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2F3633A67F1 for ; Tue, 18 Aug 2009 01:59:09 -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 3C938D80095; Tue, 18 Aug 2009 10:57:01 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090817201535.GB4453@elstar.local> References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> <1250537764.21629.164.camel@missotis> <20090817201535.GB4453@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 18 Aug 2009 10:56:59 +0200 Message-Id: <1250585820.3645.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 08:59:25 -0000 Juergen Schoenwaelder píše v Po 17. 08. 2009 v 22:15 +0200: > > > 2. Do we want to use defaults in the data model as a mean for > > simplifying configurations presented to clients? This will work fine: if > > the value is missing in a get-config reply, ANY client will know that > > the default value is implied. > > This is for me a completely new definition of the default statement > and it only makes sense to some interpretations what configuration > data really is. So I am not in favour - I would rather drop the > default statement altogether instead of using it as a filter. Hmm, for me the main purpose of the 'default' statement has been so far that it makes certain parameters available to the with-defaults capability. If it is not so, I am seriously confused. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Aug 18 02:50: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 328923A691E for ; Tue, 18 Aug 2009 02:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 FxZ7fZN1LxSv for ; Tue, 18 Aug 2009 02:50:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 499583A6892 for ; Tue, 18 Aug 2009 02:50:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8E56C0074; Tue, 18 Aug 2009 11:41:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W4pjOSoA7exA; Tue, 18 Aug 2009 11:41:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE004C0071; Tue, 18 Aug 2009 11:41:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B39F5C70778; Tue, 18 Aug 2009 11:41:42 +0200 (CEST) Date: Tue, 18 Aug 2009 11:41:42 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090818094142.GA5344@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> <1250537764.21629.164.camel@missotis> <20090817201535.GB4453@elstar.local> <1250585820.3645.13.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250585820.3645.13.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 09:50:06 -0000 On Tue, Aug 18, 2009 at 10:56:59AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v Po 17. 08. 2009 v 22:15 +0200: > > > > > 2. Do we want to use defaults in the data model as a mean for > > > simplifying configurations presented to clients? This will work fine: if > > > the value is missing in a get-config reply, ANY client will know that > > > the default value is implied. > > > > This is for me a completely new definition of the default statement > > and it only makes sense to some interpretations what configuration > > data really is. So I am not in favour - I would rather drop the > > default statement altogether instead of using it as a filter. > > Hmm, for me the main purpose of the 'default' statement has been so far > that it makes certain parameters available to the with-defaults > capability. If it is not so, I am seriously confused. We need to discuss what is in the document and not interpretations of it. Which text in draft-ietf-netmod-yang-07 makes you believe the default statement acts as a magic filter for :with-defaults? Section 7.6. I think spells out what a default does to a leaf: If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. It does not talk about filtering. And section 1.2 of draft-ietf-netconf-with-defaults-03 explains the different ways server deal with default config data - trim is only one out of three options. /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 Tue Aug 18 04:00: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 640333A6B58 for ; Tue, 18 Aug 2009 04:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 1EluE7F7myff for ; Tue, 18 Aug 2009 04:00:06 -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 BEBEC3A680E for ; Tue, 18 Aug 2009 04:00:06 -0700 (PDT) Received: (qmail 82955 invoked from network); 18 Aug 2009 10:58:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 18 Aug 2009 10:58:05 -0000 X-YMail-OSG: AvxGBBoVM1mzaprFgg0DrTYN9DuHmR4Jv4ovt0JPZkNE.mtJKByXadE0tOj3v65xnUtN3FnWpAY8ZV4amNJJ3jRUfvIB07rqliDVndzG8Ql_Szniq1zs_090i3VwJq4gs30PKmbv3rI8Iip9As7vvJZ9SjaKUF44SXRW2O7KVMdPimupb4xPErT7eClJPOXlLDXd2GZf4AjSWY97qLiXdQhcJCcCppWhkhH_vKP3AiBo3DtrXqpm8EKfr6gPAZ6QrTAEx0v8MJYnvbc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8A8951.8050705@netconfcentral.com> Date: Tue, 18 Aug 2009 03:58:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <200908171437.n7HEbjCR026249@idle.juniper.net> <1250522026.21629.80.camel@missotis> <20090817153857.GB3661@elstar.local> <1250531961.21629.112.camel@missotis> <20090817190453.GE4255@elstar.local> <1250537078.21629.152.camel@missotis> <20090817195525.GA4453@elstar.local> <1250585638.3645.10.camel@missotis> In-Reply-To: <1250585638.3645.10.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG must work with NETCONF 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, 18 Aug 2009 11:00:07 -0000 Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v Po 17. 08. 2009 v 21:55 +0200: >> a) Agree on a common definition what configuration is. This would >> solve many problems - but it might be hard to find agreement. >> >> b) Accept 2-3 different definitions and be explicit what things mean >> according to systems following the different approaches. Not nice, >> lots of work, looks complicated (like the real world). >> >> c) Ignore the differences and leave some details open to variations in >> implementation. >> >> This last approach allows us to get started in a timely manner. It >> might cause additional work later down the road if this technology >> gets widely used - but this is perhaps goodness because some of this >> is going to be easier to understand with more implementation and usage >> experience and perhaps we can have BCPs that describe how to best >> practice documents what configuration really is or should be. > > Well, it means that I would always write the model for network interface > with "mtu" declared as mandatory (because this configuration parameter > must be present in every valid configuration) but Phil would leave it as > optional, as he suggested. I think this is a problem. > > My preference is clearly (a). The fact that one approach just presents a > diff against a system-assigned configuration can be accomodated in this > scenario. I agree with Lada's interpretation of mandatory. > Lada > > Andy From lhotka@cesnet.cz Tue Aug 18 04:42: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 4F6213A68FF for ; Tue, 18 Aug 2009 04:42:55 -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 OoCopnwE-YxM for ; Tue, 18 Aug 2009 04:42:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E64053A676A for ; Tue, 18 Aug 2009 04:42:51 -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 883CBD80095; Tue, 18 Aug 2009 13:16:05 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090818094142.GA5344@elstar.local> References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> <1250537764.21629.164.camel@missotis> <20090817201535.GB4453@elstar.local> <1250585820.3645.13.camel@missotis> <20090818094142.GA5344@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 18 Aug 2009 13:16:03 +0200 Message-Id: <1250594163.3645.59.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 11:42:55 -0000 Juergen Schoenwaelder píše v Út 18. 08. 2009 v 11:41 +0200: > On Tue, Aug 18, 2009 at 10:56:59AM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v Po 17. 08. 2009 v 22:15 +0200: > > > > > > > 2. Do we want to use defaults in the data model as a mean for > > > > simplifying configurations presented to clients? This will work fine: if > > > > the value is missing in a get-config reply, ANY client will know that > > > > the default value is implied. > > > > > > This is for me a completely new definition of the default statement > > > and it only makes sense to some interpretations what configuration > > > data really is. So I am not in favour - I would rather drop the > > > default statement altogether instead of using it as a filter. > > > > Hmm, for me the main purpose of the 'default' statement has been so far > > that it makes certain parameters available to the with-defaults > > capability. If it is not so, I am seriously confused. > > We need to discuss what is in the document and not interpretations of > it. Which text in draft-ietf-netmod-yang-07 makes you believe the > default statement acts as a magic filter for :with-defaults? Section draft-ietf-netconf-with-defaults-03: "Default values SHOULD be specified in documents describing the data models supported by the NETCONF server." It is IMO a mistake that YANG draft completely ignores this function. Without it, the 'default' statement is pretty much useless and serves only as a source for confusion. > 7.6. I think spells out what a default does to a leaf: > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. Again, this sentence is carefully formulated to avoid any reference to a particular information model and is therefore ambiguous. What "use internally" means in terms of configuration datastores? Is it OK if a device in the factory default state has the DM-default value in the startup datastore and another value in running? Or the other way around? In both cases the default value is "used internally". What about the "built-in NETCONF client" trick, or another form of NETCONF-client-in-the-middle? As a result, the sentence provides actually no guarantees that the default value will really appear in any particular datastore when the device completes the boot procedure. Lada > > It does not talk about filtering. And section 1.2 of > draft-ietf-netconf-with-defaults-03 explains the different ways server > deal with default config data - trim is only one out of three options. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Aug 18 05:14: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 810123A67F5 for ; Tue, 18 Aug 2009 05:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 7njCqcrbkBUf for ; Tue, 18 Aug 2009 05:14:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 56A803A67A3 for ; Tue, 18 Aug 2009 05:14:53 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D4F9C015E; Tue, 18 Aug 2009 13:51:57 +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 zudMHYUqlADQ; Tue, 18 Aug 2009 13:51:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20F80C014F; Tue, 18 Aug 2009 13:51:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 11250C70AB9; Tue, 18 Aug 2009 13:51:55 +0200 (CEST) Date: Tue, 18 Aug 2009 13:51:55 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090818115154.GE5344@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> <1250537764.21629.164.camel@missotis> <20090817201535.GB4453@elstar.local> <1250585820.3645.13.camel@missotis> <20090818094142.GA5344@elstar.local> <1250594163.3645.59.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250594163.3645.59.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 12:14:54 -0000 On Tue, Aug 18, 2009 at 01:16:03PM +0200, Ladislav Lhotka wrote: > It is IMO a mistake that YANG draft completely ignores this function. > Without it, the 'default' statement is pretty much useless and serves > only as a source for confusion. Well, we do not have to agree. > > 7.6. I think spells out what a default does to a leaf: > > > > If the leaf has a default value, the server MUST use this value > > internally if no value is provided by the NETCONF client when the > > instance is created. > > Again, this sentence is carefully formulated to avoid any reference to a > particular information model and is therefore ambiguous. What "use > internally" means in terms of configuration datastores? Is it OK if a > device in the factory default state has the DM-default value in the > startup datastore and another value in running? Or the other way around? > In both cases the default value is "used internally". What about the > "built-in NETCONF client" trick, or another form of > NETCONF-client-in-the-middle? > > As a result, the sentence provides actually no guarantees that the > default value will really appear in any particular datastore when the > device completes the boot procedure. The server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. You can always use the "built-in NETCONF client" trick to arbitrary things and I do not think a specification can prevent this. In Phils interpretation, however, such a "built-in NETCONF client" would leave explicit config around - so things become visible. I do not think we make progress so I stop here. /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 Tue Aug 18 05:35:21 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 77DB33A69EF for ; Tue, 18 Aug 2009 05:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 FKvqOFkehmgW for ; Tue, 18 Aug 2009 05:35:20 -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 209A83A680E for ; Tue, 18 Aug 2009 05:35:20 -0700 (PDT) Received: (qmail 7791 invoked from network); 18 Aug 2009 12:33:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2009 12:33:05 -0000 X-YMail-OSG: t1Vkst0VM1nCPRjlJ3C3y0jyrGE1fMVmR.JVIHFZn_SLJaOLen5BAU.gmS2VtAi3vpYbK7qD3zAD.mV4U9rCL9LIi9F.JeHkWDDiBIwj1.9sSrlAJl0qyyVDh3FNhSZUCfjlb5K5T89BG__3ONwgtO7k1VywCVuZmIGr5FKOvNkDieTOMW2EwuJAIYrmeeVLs8ywK_B5p30eRPn3B335kRV1mVK_J6NJq3Um8rYNHEcFO.pqA.Hag2JhtaluqUc8dAzpmYcJiaHHzJI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8A9F96.2070201@netconfcentral.com> Date: Tue, 18 Aug 2009 05:33:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A896B11.8010700@netconfcentral.com> <1250521791.21629.77.camel@missotis> <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> <1250537764.21629.164.camel@missotis> <20090817201535.GB4453@elstar.local> <1250585820.3645.13.camel@missotis> <20090818094142.GA5344@elstar.local> <1250594163.3645.59.camel@missotis> In-Reply-To: <1250594163.3645.59.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 12:35:21 -0000 Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v Út 18. 08. 2009 v 11:41 +0200: >> On Tue, Aug 18, 2009 at 10:56:59AM +0200, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder p????e v Po 17. 08. 2009 v 22:15 +0200: >>>>> 2. Do we want to use defaults in the data model as a mean for >>>>> simplifying configurations presented to clients? This will work fine: if >>>>> the value is missing in a get-config reply, ANY client will know that >>>>> the default value is implied. >>>> This is for me a completely new definition of the default statement >>>> and it only makes sense to some interpretations what configuration >>>> data really is. So I am not in favour - I would rather drop the >>>> default statement altogether instead of using it as a filter. >>> Hmm, for me the main purpose of the 'default' statement has been so far >>> that it makes certain parameters available to the with-defaults >>> capability. If it is not so, I am seriously confused. >> We need to discuss what is in the document and not interpretations of >> it. Which text in draft-ietf-netmod-yang-07 makes you believe the >> default statement acts as a magic filter for :with-defaults? Section > > draft-ietf-netconf-with-defaults-03: "Default values SHOULD be specified > in documents describing the data models supported by the NETCONF > server." > > It is IMO a mistake that YANG draft completely ignores this function. > Without it, the 'default' statement is pretty much useless and serves > only as a source for confusion. > >> 7.6. I think spells out what a default does to a leaf: >> >> If the leaf has a default value, the server MUST use this value >> internally if no value is provided by the NETCONF client when the >> instance is created. > > Again, this sentence is carefully formulated to avoid any reference to a > particular information model and is therefore ambiguous. What "use > internally" means in terms of configuration datastores? Is it OK if a > device in the factory default state has the DM-default value in the > startup datastore and another value in running? Or the other way around? > In both cases the default value is "used internally". What about the > "built-in NETCONF client" trick, or another form of > NETCONF-client-in-the-middle? > > As a result, the sentence provides actually no guarantees that the > default value will really appear in any particular datastore when the > device completes the boot procedure. > I share your concern. The standard gives the impression that there is going to be some sort of consistent behavior across implementations, yet nothing could be further from the truth. I can't believe with all the little esoteric machine-clauses in YANG, that the best this WG can do is leave this issue up to the description clauses. There are 3 agreed upon states, but only 2 of them need machine-readable clauses? Which means that 2 of the 3 modes are ambiguous and worthless to managers. > Lada Andy From andy@netconfcentral.com Tue Aug 18 05:51: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 5AA6E3A6A04 for ; Tue, 18 Aug 2009 05:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 y34fCDq+awFm for ; Tue, 18 Aug 2009 05:51:23 -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 75D913A69EF for ; Tue, 18 Aug 2009 05:51:23 -0700 (PDT) Received: from [209.191.108.97] by n10.bullet.mail.mud.yahoo.com with NNFMP; 18 Aug 2009 12:48:50 -0000 Received: from [68.142.201.251] by t4.bullet.mud.yahoo.com with NNFMP; 18 Aug 2009 12:48:50 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 18 Aug 2009 12:48:50 -0000 X-Yahoo-Newman-Id: 435209.19775.bm@omp412.mail.mud.yahoo.com Received: (qmail 85196 invoked from network); 18 Aug 2009 12:48:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 18 Aug 2009 12:48:49 -0000 X-YMail-OSG: U0PXKq0VM1nzfpKgUyefXvvrTwCdN9nzExzUKfSxrIETCMFMtEEE0Tai_yOIcXdyIzc5vVq6dlPpCw7Q7Ap.GmL6G0Ht.ezN9JsWnIynu6_BR0UuPa1CGd.xP3VcpHGmiMDEybTrdy0lC90_lcHKz51IMfrHGn4IepCYjp_Ea.GFKoSIM94LEVQA0vubmWbbuH6.FI6hILhfSFM80pk5nuylbfxkxoEJDfzpnnk8eqv9cdGDywaVVpJXeQJ7YWaZjukxbh7BnissnzEOn02PcB1ni5tdRMLdjSkhrWeN4OQQA7Rmhrw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8AA2CC.9060605@netconfcentral.com> Date: Tue, 18 Aug 2009 05:47:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908171455.n7HEtP1r026596@idle.juniper.net> In-Reply-To: <200908171455.n7HEtP1r026596@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: [netmod] terminology (was Re: agent-default -- new 3rd state) 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, 18 Aug 2009 12:51:24 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I do not want to replace 'mandatory' with 'agent-provided'. > > s/agent/server/ or /system/ > > Using the term "agent" is SNMP-specific, and does not work with > folks who are not aware of the odd way this protocol used this term. > It is needlessly confusing and we are trying to move to more modern > terms. In normal CS terminology, an agent is a semi-independent > piece of software that acts on behalf of a user, which is very > different from the "server" role that the netconf server performs. > I do not agree with this terminology rule. Manager and agent are network management specific, not SNMP specific. I do not see any value forcing the use of the generic 'client/server' terms. The NETCONF RFC says manager <--> client and agent <--> server, so there is no need to change any text. We can use either terminology. Both are acceptable. > The existing proposal for "assigned-by system" solves the problem > you are refering to. > > Thanks, > Phil > Andy From andy@netconfcentral.com Tue Aug 18 06:31: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 AF9343A67A3 for ; Tue, 18 Aug 2009 06:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 YxjqSWwsPRoq for ; Tue, 18 Aug 2009 06:31:55 -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 D2BC63A68F3 for ; Tue, 18 Aug 2009 06:31:55 -0700 (PDT) Received: (qmail 30832 invoked from network); 18 Aug 2009 13:24:34 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2009 13:24:33 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8AABA5.7050901@netconfcentral.com> Date: Tue, 18 Aug 2009 06:24:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ladislav Lhotka , "netmod@ietf.org" References: <20090817154226.GC3661@elstar.local> <1250532416.21629.118.camel@missotis> <20090817183013.GB4255@elstar.local> <1250535833.21629.147.camel@missotis> <20090817191442.GA4407@elstar.local> <1250537764.21629.164.camel@missotis> <20090817201535.GB4453@elstar.local> <1250585820.3645.13.camel@missotis> <20090818094142.GA5344@elstar.local> <1250594163.3645.59.camel@missotis> <20090818115154.GE5344@elstar.local> In-Reply-To: <20090818115154.GE5344@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 13:31:56 -0000 Juergen Schoenwaelder wrote: > On Tue, Aug 18, 2009 at 01:16:03PM +0200, Ladislav Lhotka wrote: > >> It is IMO a mistake that YANG draft completely ignores this function. >> Without it, the 'default' statement is pretty much useless and serves >> only as a source for confusion. > > Well, we do not have to agree. > >>> 7.6. I think spells out what a default does to a leaf: >>> >>> If the leaf has a default value, the server MUST use this value >>> internally if no value is provided by the NETCONF client when the >>> instance is created. >> Again, this sentence is carefully formulated to avoid any reference to a >> particular information model and is therefore ambiguous. What "use >> internally" means in terms of configuration datastores? Is it OK if a >> device in the factory default state has the DM-default value in the >> startup datastore and another value in running? Or the other way around? >> In both cases the default value is "used internally". What about the >> "built-in NETCONF client" trick, or another form of >> NETCONF-client-in-the-middle? >> >> As a result, the sentence provides actually no guarantees that the >> default value will really appear in any particular datastore when the >> device completes the boot procedure. > > The server MUST use this value internally if no value is provided by > the NETCONF client when the instance is created. You can always use > the "built-in NETCONF client" trick to arbitrary things and I do not > think a specification can prevent this. In Phils interpretation, > however, such a "built-in NETCONF client" would leave explicit config > around - so things become visible. > > I do not think we make progress so I stop here. > We are confusing implementations of data models and specification of data models. The data model designer needs a way to indicate that the model does not allow for any implementation of the model to use an unspecified value. create-interface(name) ping(host-addr) I don't care what the statement is called. It is useful for automation tools to know that the agent MUST NOT provide a value for a mandatory leaf. The ifMtu object would have a default-stmt if there was a static default. Calling this object mandatory is wrong. Calling it optional is wrong. What about calling it 'dynamic-default'? (Then mandatory means manager-must-set.) This is an important use-case that is going to show up a lot. > /js > Andy From mbj@tail-f.com Tue Aug 18 06:41:59 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 3DCF528C1A8 for ; Tue, 18 Aug 2009 06:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.115, 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 XPRYB6J71gyr for ; Tue, 18 Aug 2009 06:41:58 -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 522D73A6B49 for ; Tue, 18 Aug 2009 06:41:58 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D660F76C4E3; Tue, 18 Aug 2009 15:41:25 +0200 (CEST) Date: Tue, 18 Aug 2009 15:41:25 +0200 (CEST) Message-Id: <20090818.154125.262734760.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8AABA5.7050901@netconfcentral.com> References: <1250594163.3645.59.camel@missotis> <20090818115154.GE5344@elstar.local> <4A8AABA5.7050901@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] agent-default -- new 3rd state 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, 18 Aug 2009 13:41:59 -0000 Andy Bierman wrote: > The data model designer needs a way to indicate > that the model does not allow for any implementation > of the model to use an unspecified value. Absolutely. It is called 'mandatory'. /martin From mbj@tail-f.com Tue Aug 18 06: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 670243A69D1 for ; Tue, 18 Aug 2009 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.111, 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 03zMvg3ONXoM for ; Tue, 18 Aug 2009 06:55:24 -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 9F81D3A6909 for ; Tue, 18 Aug 2009 06:55:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 786CD76C4E3; Tue, 18 Aug 2009 15:55:29 +0200 (CEST) Date: Tue, 18 Aug 2009 15:55:29 +0200 (CEST) Message-Id: <20090818.155529.264931316.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A85F449.1020901@netconfcentral.com> References: <4A85B916.2070009@netconfcentral.com> <20090814.224106.175526822.mbj@tail-f.com> <4A85F449.1020901@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] leafref problems 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, 18 Aug 2009 13:55:25 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Please send me some suggestion for text to include! > > > > (Here's what yangdump checks anyway -- maybe there > is more to it than this...) > > leafref node ==> leaf containing a leafref type > target leaf ==> leaf pointed at by a leafref path statement > > > The leafref node cannot be more conditional than > the target leaf. Hmm. It should be the other way around, right? list x { if-feature foo; key y; ... } leaf xref { // legal if-feature foo; if-feature bar; type leafref { path /x/y; } } leaf xref2 { // illegal type leafref { path /x/y; } } How about this: If the leaf that the leafref refers to is conditional based on one or more features (see ^if-feature^), then the leaf with the leafref type MUST also be conditional based on at least the same set of features. /martin From jmh@joelhalpern.com Tue Aug 18 06:56: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 1137E3A69D1 for ; Tue, 18 Aug 2009 06:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 KmwfdbTvuXJ0 for ; Tue, 18 Aug 2009 06:56:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 44E7B3A6B33 for ; Tue, 18 Aug 2009 06:56:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B25DC4300E8; Tue, 18 Aug 2009 06:56:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id E01F54300C1; Tue, 18 Aug 2009 06:56:21 -0700 (PDT) Message-ID: <4A8AB302.4070308@joelhalpern.com> Date: Tue, 18 Aug 2009 09:56:18 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Martin Bjorklund References: <1250594163.3645.59.camel@missotis> <20090818115154.GE5344@elstar.local> <4A8AABA5.7050901@netconfcentral.com> <20090818.154125.262734760.mbj@tail-f.com> In-Reply-To: <20090818.154125.262734760.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 13:56:18 -0000 I have been watching this debate, which appears to consist of people talking past each other. Maybe my addition will just add confusion, although I beleive I agree with Andy and Juergen. (As a caveat, I use "means" below to indicate what I think the YANG text explicitly requires.) 1) Mandatory means that if a manager is writing that part of the tree, the manager MUST provide a value for that item. 2) Default means that if no manager has not set the item, the item will have the explicit value given in the default clause in the data model. So the question is what to do with a value that must have an item, but which the system will generate a value if one is not provided, and which the data model writer can not define that value in advance? To remove a corner case, if the manager is not allowed to set the item, then it is not config data, and this whole debate is irrelevant. We are talking only about config data. As far as I can tell, when the mandatory and default clauses were defined, we did not think about this case. (Or, if some folks thought about it, it was not discussed and articulated.) As a result, it is simply not covered. There are, as far as I can tell, a couple of ways out, of varying attractiveness. 1) We can follow Andy's suggestion and create a keyword to represent this case. 2) We can add words to say that this case will NOT use Mandatory, will not use Default, and that instead the description clause will tell the human being what value is likely to be found here. As far as I can tell, nothing in the YANG document prevents the system from setting values that have not been set by managers and which are not Mandatory. Since the system will provide a value, this would work. It means that from an automaton perspective, the model does not distinguish between things the system sets and things that are truly optional. 3) We could do nothing and say nothing in the document. This would seem to be a mistake, because different model writers and different manager / agent implementors will do different things. Interoperability is likely to fail. (Given that we have differing interpretations already demonstrated on the list, I think "likely" is an understatement.) Personally, I would go with 1. But I can live with 2. Yours, Joel Martin Bjorklund wrote: > Andy Bierman wrote: >> The data model designer needs a way to indicate >> that the model does not allow for any implementation >> of the model to use an unspecified value. > > Absolutely. It is called 'mandatory'. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Tue Aug 18 07:05: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 A297B3A69F1 for ; Tue, 18 Aug 2009 07:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 uaLordGRr5PL for ; Tue, 18 Aug 2009 07:05:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A5D723A67A3 for ; Tue, 18 Aug 2009 07:05:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91DDCC0091; Tue, 18 Aug 2009 16:05:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1xkK2-dttiLD; Tue, 18 Aug 2009 16:05:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C66BC0090; Tue, 18 Aug 2009 16:05:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 13C43C70DB2; Tue, 18 Aug 2009 16:05:08 +0200 (CEST) Date: Tue, 18 Aug 2009 16:05:08 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090818140507.GB5921@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <200908171455.n7HEtP1r026596@idle.juniper.net> <4A8AA2CC.9060605@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8AA2CC.9060605@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] terminology (was Re: agent-default -- new 3rd state) 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, 18 Aug 2009 14:05:06 -0000 On Tue, Aug 18, 2009 at 02:47:08PM +0200, Andy Bierman wrote: > The NETCONF RFC says manager <--> client and agent <--> server, > so there is no need to change any text. We can use either terminology. > Both are acceptable. Which page of RFC 4741 do I have to look at? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Aug 18 07: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 5B17D28C1D9 for ; Tue, 18 Aug 2009 07:36:38 -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 mRztj5WfJjV3 for ; Tue, 18 Aug 2009 07:36:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 59ED13A6B04 for ; Tue, 18 Aug 2009 07:36:37 -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 21580D80096; Tue, 18 Aug 2009 16:36:28 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4A8AB302.4070308@joelhalpern.com> References: <1250594163.3645.59.camel@missotis> <20090818115154.GE5344@elstar.local> <4A8AABA5.7050901@netconfcentral.com> <20090818.154125.262734760.mbj@tail-f.com> <4A8AB302.4070308@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 18 Aug 2009 16:36:26 +0200 Message-Id: <1250606186.3645.88.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 14:36:38 -0000 Joel M. Halpern píše v Út 18. 08. 2009 v 09:56 -0400: > 1) We can follow Andy's suggestion and create a keyword to represent > this case. > > 2) We can add words to say that this case will NOT use Mandatory, will > not use Default, and that instead the description clause will tell the > human being what value is likely to be found here. As far as I can > tell, nothing in the YANG document prevents the system from setting > values that have not been set by managers and which are not Mandatory. > Since the system will provide a value, this would work. It means that > from an automaton perspective, the model does not distinguish between > things the system sets and things that are truly optional. > > 3) We could do nothing and say nothing in the document. This would seem > to be a mistake, because different model writers and different manager / > agent implementors will do different things. Interoperability is likely > to fail. (Given that we have differing interpretations already > demonstrated on the list, I think "likely" is an understatement.) I think there is yet another possibility: 4) Using the rules for "mandatory" in Sec. 3.1, the device MUST determine the minimum valid configuration and make sure all mandatory leaves in the "running" configuration are initialized with values that are valid according to the data model. These system-assigned values SHOULD be described in system documentation. Lada > > Personally, I would go with 1. But I can live with 2. > > Yours, > Joel > > > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> The data model designer needs a way to indicate > >> that the model does not allow for any implementation > >> of the model to use an unspecified value. > > > > Absolutely. It is called 'mandatory'. > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Tue Aug 18 07:45: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 4C18628C15A for ; Tue, 18 Aug 2009 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 somw3yQ+ioW6 for ; Tue, 18 Aug 2009 07:45:12 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 6542628C144 for ; Tue, 18 Aug 2009 07:45:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSoq+eWoT1vKKeHiTgpPn25fw/x0MUf2x@postini.com; Tue, 18 Aug 2009 07:45:17 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, 18 Aug 2009 07:36:02 -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, 18 Aug 2009 07:36:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 07:36:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 07:36:01 -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 n7IEa0d96017; Tue, 18 Aug 2009 07:36:00 -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 n7IEOAPR041250; Tue, 18 Aug 2009 14:24:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908181424.n7IEOAPR041250@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4A8AB302.4070308@joelhalpern.com> Date: Tue, 18 Aug 2009 10:24:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2009 14:36:01.0403 (UTC) FILETIME=[35499CB0:01CA2011] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 14:45:13 -0000 "Joel M. Halpern" writes: >I have been watching this debate, which appears to consist of people >talking past each other. We have a rich history of such debates. >Maybe my addition will just add confusion, although I beleive I agree >with Andy and Juergen. My understanding was that Andy and Juergen did not agree here. >1) Mandatory means that if a manager is writing that part of the tree, >the manager MUST provide a value for that item. Sort of. With candidate, there's no validation until the commit operation, so a valid configuration MUST contain a value, but when and how it appears is flexible (meaning that I can do one edit-config operation to make that part of the tree, and then another operation to populate some missing mandatory values. Running is more straight-forward, since the configuration must be valid after each operation. >2) Default means that if no manager has not set the item, the item will >have the explicit value given in the default clause in the data model. And this issue here is what "the item will have" means. Will this node appear in the database or not? Is the default implicit or does it become part of the configuration? If you didn't set "mtu" but there's a default, will a get return that default? >As far as I can tell, when the mandatory and default clauses were >defined, we did not think about this case. (Or, if some folks thought >about it, it was not discussed and articulated.) As a result, it is >simply not covered. I believe it was articulated in the "assigned-by system" proposal: http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 I am personally in favor of this, but the concensus was not. The issue is still marked open, so perhaps it's time for another concensus call? Thanks, Phil From mbj@tail-f.com Tue Aug 18 07: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 8A5D63A6E44 for ; Tue, 18 Aug 2009 07:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.108, 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 8VDVYSvpyKOj for ; Tue, 18 Aug 2009 07:54:53 -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 4E7FA3A6E2A for ; Tue, 18 Aug 2009 07:54:52 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4484B76C4E3; Tue, 18 Aug 2009 16:54:56 +0200 (CEST) Date: Tue, 18 Aug 2009 16:54:56 +0200 (CEST) Message-Id: <20090818.165456.143451979.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908181424.n7IEOAPR041250@idle.juniper.net> References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> 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] agent-default -- new 3rd state 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, 18 Aug 2009 14:54:54 -0000 Phil Shafer wrote: > I believe it was articulated in the "assigned-by system" proposal: > > http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 > > I am personally in favor of this, but the concensus was not. The > issue is still marked open, so perhaps it's time for another concensus > call? I'm also in favor of this, but I'm not sure I want to re-open the concensus call. See the email http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html for some open issues. My main concern is that if we add this it will delay the process. This is a known issue, and the WG decided to not add any more features. This issue was known at the time. There are more nice to haves that could be added, but at some point we have to stop. /martin From phil@juniper.net Tue Aug 18 07:55: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 129853A6AB1 for ; Tue, 18 Aug 2009 07:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 YGtu6SN+ysQr for ; Tue, 18 Aug 2009 07:55:25 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 6DD613A6A26 for ; Tue, 18 Aug 2009 07:55:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSorA4TRnYe839friKN91Bk9cA39bGx8c@postini.com; Tue, 18 Aug 2009 07:55:30 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, 18 Aug 2009 07:49:46 -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, 18 Aug 2009 07:49:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 07:49:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 07:49:45 -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 n7IEnid03025; Tue, 18 Aug 2009 07:49:44 -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 n7IEbsFQ041423; Tue, 18 Aug 2009 14:37:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908181437.n7IEbsFQ041423@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A8AA2CC.9060605@netconfcentral.com> Date: Tue, 18 Aug 2009 10:37:53 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2009 14:49:45.0367 (UTC) FILETIME=[20688A70:01CA2013] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] terminology (was Re: agent-default -- new 3rd state) 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, 18 Aug 2009 14:55:26 -0000 Andy Bierman writes: >The NETCONF RFC says manager <--> client and agent <--> server, >so there is no need to change any text. We can use either terminology. In 4741, the term "agent" appears only one, in the section on filters that you wrote. I think this is a typo that Rob missed. By contrast, the term "client" appears dozens of times. The YANG draft avoids the term "agent" completely. Googling for "network management agent" yields snmp-related pages, as well as many references to "agents" in the modern sense: An Agent-Based Network Management System This paper describes ongoing research work to build a network management system from autonomous software agents, using the BT Zeus Agent Building Toolkit. So even if the NM world, the term is confusing. I firmly believe this is an SNMP-specific term, perhaps reanimated from GDMO, that is confusing to non-snmp folks. We should bury it. Thanks, Phil From phil@juniper.net Tue Aug 18 08:02: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 72FD03A6E46 for ; Tue, 18 Aug 2009 08:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 HgTfP4yS18kb for ; Tue, 18 Aug 2009 08:02:55 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 033423A6A61 for ; Tue, 18 Aug 2009 08:02:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSorCmuQwZdLeRHhztPIRm6okZMSYHG7H@postini.com; Tue, 18 Aug 2009 08:03: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, 18 Aug 2009 07:57:28 -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, 18 Aug 2009 07:57:29 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 07:57:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 07:57:27 -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 n7IEvRd07296; Tue, 18 Aug 2009 07:57:27 -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 n7IEjaDM041538; Tue, 18 Aug 2009 14:45:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908181445.n7IEjaDM041538@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1250606186.3645.88.camel@missotis> Date: Tue, 18 Aug 2009 10:45:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2009 14:57:27.0708 (UTC) FILETIME=[33FC2DC0:01CA2014] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 15:02:56 -0000 Ladislav Lhotka writes: >4) Using the rules for "mandatory" in Sec. 3.1, the device MUST >determine the minimum valid configuration and make sure all mandatory >leaves in the "running" configuration are initialized with values that >are valid according to the data model. These system-assigned values >SHOULD be described in system documentation. This is a completely different concept of "mandatory" than what YANG has. YANG's mandatory is a contraint on the contents of the configuration database. Your concept is rather the opposite, telling the device to create values when none is provided. I think this is a non-starter, since the instances where I want the system to assign a value are very very rare. If we adopted your concept, how would you represent the current "mandatory", where the device cannot determine a valid value? If I made "first-name" mandatory under a list of s, how would the value be determined? Thanks, Phil From jmh@joelhalpern.com Tue Aug 18 08:04: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 AA3C63A6AB1 for ; Tue, 18 Aug 2009 08:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 GtHuo4OXZvJ9 for ; Tue, 18 Aug 2009 08:04:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4A30E3A6E78 for ; Tue, 18 Aug 2009 08:04:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 78CB04300E8; Tue, 18 Aug 2009 08:04:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B8CBC4300EF; Tue, 18 Aug 2009 08:04:02 -0700 (PDT) Message-ID: <4A8AC2DF.2010000@joelhalpern.com> Date: Tue, 18 Aug 2009 11:03:59 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> In-Reply-To: <20090818.165456.143451979.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 15:04:55 -0000 I could certainly live with adding "agent-supplied value", or "assigned-by-system." I understand Martin's argument for not adding a new feature. But if we are not going to add a feature, then I think we MUST (in the ineroperability sense) add some words that explain how this is supposed to work. It is quite clear that people understand it differently. (Ladislav's understanding of how one could use Mandatory for this is just one example. I do not read the text as allowing the behavior he understand in good faith to be correct and appropraite.) Yours, Joel Martin Bjorklund wrote: > Phil Shafer wrote: >> I believe it was articulated in the "assigned-by system" proposal: >> >> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 >> >> I am personally in favor of this, but the concensus was not. The >> issue is still marked open, so perhaps it's time for another concensus >> call? > > I'm also in favor of this, but I'm not sure I want to re-open the > concensus call. See the email > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html for > some open issues. My main concern is that if we add this it will > delay the process. This is a known issue, and the WG decided to not > add any more features. This issue was known at the time. There are > more nice to haves that could be added, but at some point we have to > stop. > > > /martin > From lhotka@cesnet.cz Tue Aug 18 09:59: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 EF16528C18F for ; Tue, 18 Aug 2009 09:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=0.055, 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 k8Ehuu4Wdxyj for ; Tue, 18 Aug 2009 09:59:30 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2DA9F3A6BB1 for ; Tue, 18 Aug 2009 09:59:04 -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 22C50D80095; Tue, 18 Aug 2009 18:59:09 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908181445.n7IEjaDM041538@idle.juniper.net> References: <200908181445.n7IEjaDM041538@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 18 Aug 2009 18:59:06 +0200 Message-Id: <1250614746.3645.146.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 16:59:31 -0000 Phil Shafer píše v Út 18. 08. 2009 v 10:45 -0400: > Ladislav Lhotka writes: > >4) Using the rules for "mandatory" in Sec. 3.1, the device MUST > >determine the minimum valid configuration and make sure all mandatory > >leaves in the "running" configuration are initialized with values that > >are valid according to the data model. These system-assigned values > >SHOULD be described in system documentation. > > This is a completely different concept of "mandatory" than what > YANG has. YANG's mandatory is a contraint on the contents of the > configuration database. Right, from sec. 3.1 and 7.6.4 it follows that all mandatory leafs MUST exist (and I understand this as "MUST exist for the configuration to be valid"). Therefore, the initial configuration can be valid only if all mandatory leafs (and, transitively, all mandatory nodes) exist. Why is my formulation "a completely different concept"? Do you want to allow an initial configuration that is invalid? > > Your concept is rather the opposite, telling the device to create > values when none is provided. I think this is a non-starter, since No, this is only relevant for the mandatory leafs in the minimum valid configuration, essentialy those that are either top-level or reachable from the root node through non-presence containers or lists with min-elements>0. For everything else that is added later via edit-config operations, the client must always supply all mandatory nodes so that the resulting configuration is again valid. > the instances where I want the system to assign a value are very > very rare. Sure, the minimum valid configuration can also be empty. > > If we adopted your concept, how would you represent the current > "mandatory", where the device cannot determine a valid value? Either as optional without any default specified, or, if the device really cannot operate without it, it would be defined as mandatory, but then the device must not start the NETCONF subsystem before such a value is provided by other means, perhaps by editing a file or via an initial configuration dialog. > > If I made "first-name" mandatory under a list of s, how > would the value be determined? If the list has min-elements=0, the device will start with an empty list (which is valid configuration), and then of course every edit-config operation that adds an entry must provide "first-name" for the entry. If the data model specifies min-elements=1, then the device should add "Joe Admin" or start an initial setup dialog the fills the first entry. But in my view every device must have a valid running configuration as soon as it starts accepting NETCONF sessions and so all mandatory nodes must be present at that time. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Tue Aug 18 10:29: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 CDC6C3A6BAD for ; Tue, 18 Aug 2009 10:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 tUZLKYTFnidm for ; Tue, 18 Aug 2009 10:29:25 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id D289928C1C5 for ; Tue, 18 Aug 2009 10:29:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSork3CL7xskdv9kmKA809d1rUIuwLpwD@postini.com; Tue, 18 Aug 2009 10:29: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, 18 Aug 2009 10:22:27 -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, 18 Aug 2009 10:22:27 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:22:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:22:26 -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 n7IHMQd87012; Tue, 18 Aug 2009 10:22:26 -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 n7IHAaZF042972; Tue, 18 Aug 2009 17:10:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908181710.n7IHAaZF042972@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1250614746.3645.146.camel@missotis> Date: Tue, 18 Aug 2009 13:10:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2009 17:22:26.0933 (UTC) FILETIME=[75209250:01CA2028] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 17:29:25 -0000 Ladislav Lhotka writes: >Phil Shafer píše v Út 18. 08. 2009 v 10:45 -0400: >> Ladislav Lhotka writes: >> >4) Using the rules for "mandatory" in Sec. 3.1, the device MUST >> >determine the minimum valid configuration and make sure all mandatory >> >leaves in the "running" configuration are initialized with values that >> >are valid according to the data model. These system-assigned values >> >SHOULD be described in system documentation. >... Why is >my formulation "a completely different concept"? Do you want to allow an >initial configuration that is invalid? Sorry. My bad. I completely missed that you are talking about initial configurations. The comment "the device MUST ... make sure all mandatory leaves ... are initialized with values" confused me, since this sounds like the device must fill in those values. You are just saying that should be valid when the box boots up, and I agree with this. Thanks, Phil From cfinss@dial.pipex.com Tue Aug 18 10:47: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 3372E3A69E1 for ; Tue, 18 Aug 2009 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 p4gHqjnOy0O6 for ; Tue, 18 Aug 2009 10:47:08 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 1C4163A6A13 for ; Tue, 18 Aug 2009 10:47:07 -0700 (PDT) X-Trace: 242534404/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.84/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.84 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: AtMEALeFiko+vGlU/2dsb2JhbACDMGKNEMhECYQQBYIq X-IronPort-AV: E=Sophos;i="4.43,403,1246834800"; d="scan'208";a="242534404" X-IP-Direction: IN Received: from 1cust84.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.84]) by smtp.pipex.tiscali.co.uk with SMTP; 18 Aug 2009 18:46:40 +0100 Message-ID: <005401ca2023$51fd9d40$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A856559.4040402@netconfcentral.com><20090814.153232.162557664.mbj@tail-f.com><002c01ca1e4b$fdd29fa0$0601a8c0@allison> <20090817.110245.26949790.mbj@tail-f.com> Date: Tue, 18 Aug 2009 18:42:55 +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] Terminology2 was Re: leafref problems 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, 18 Aug 2009 17:47:09 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Monday, August 17, 2009 11:02 AM > > "tom.petch" wrote: > > > > 'top-level' appears many times in the i-d and I would like to see the meaning > > better nailed down . > > > > It could refer to the substatements immediately below a module statement. > > > > It could be extended to the substatements immediately below the submodule > > statement of an included submodule. > > > > Since the reference, as here, is frequently to top-level data nodes, it could > > be > > read as any data node which has no other data node between it and the module > > statement > > Yes. > > > so that in > > > > module m {grouping g { leaf x ... > > > > then x is regarded as top-level > > No, the grouping statement does not instantiate any data nodes. If > you also had: > > uses g; > > then x would be a top-level data node. Thanks Martin, Logical but, taken together, that's a surprise. So with suitable imports and prefixes module m {grouping g { leaf x ... module n {uses g ... x is not top-level in module m but is top-level in module n. I would like this spelt out in the I-D; I suggest amending 5.5 to become only top-level types and groupings ie those appearing as substatements to a module or submodule statement can be used outside the module or 6.2.1 bullet 7 I am unclear about; does a 'module n { uses g make leaf x top level in this case? Add A top-level configuration data node is one where there is no other data node between it and a module or submodule statement. Note that the 'grouping' and 'uses' statements do not themselves instantiate data nodes but that a 'uses' statement that is not within a grouping instantiates the nodes that appear in the 'grouping' statement that it references. If that sounds complicated, well it is:-) It is needed for the usual suspects, 'when' 'path' 'instance-identifier' 'must', could appear in all four or perhaps better in 6.2.1 or 6.4. Tom Petch > > /martin From andy@netconfcentral.com Tue Aug 18 12:19:32 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 9E36A3A6A13 for ; Tue, 18 Aug 2009 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 F1TASXS+8b84 for ; Tue, 18 Aug 2009 12:19:31 -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 A49923A69F5 for ; Tue, 18 Aug 2009 12:19:31 -0700 (PDT) Received: (qmail 3124 invoked from network); 18 Aug 2009 19:19:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2009 19:19:33 -0000 X-YMail-OSG: GF2V78EVM1kUHEGyuwiEdft8iauKM4s860JcVVHOooVETxlMVc3fLy.IO96Git8B4tIlHORpV4iVl2gqYoB_Ud0uj72v7cnQq9txW.mEYJ0FeKoNqOZqkbA3Qi02DCPS0bWUYjjAx8zX_GMZJc6E9H5OY.Bsj9PA0Xs0S1jYB0j44KyX2COn97Vcb1VicFJcmDAdunYvQIrNQsX6OgHKomY1ixuGneaTwAoPbZvHgcbUW5zUVbJnDHwk3VVNyboO71t40bQBT1d52POoprdDtbOeCm.i8mp_J80N8BuxWZd8liE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8AFEC4.7000800@netconfcentral.com> Date: Tue, 18 Aug 2009 12:19:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> <4A8AC2DF.2010000@joelhalpern.com> In-Reply-To: <4A8AC2DF.2010000@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 19:19:32 -0000 Joel M. Halpern wrote: > I could certainly live with adding "agent-supplied value", or > "assigned-by-system." > I understand Martin's argument for not adding a new feature. > > But if we are not going to add a feature, then I think we MUST (in the > ineroperability sense) add some words that explain how this is supposed > to work. It is quite clear that people understand it differently. > (Ladislav's understanding of how one could use Mandatory for this is > just one example. I do not read the text as allowing the behavior he > understand in good faith to be correct and appropraite.) > The only value YANG provides to the world at this time is as the description of contract between the application and the device. (Not manager and agent -- that's not what 4741 calls it -- sorry.) It is only the extra details that make a NETCONF database different than an XML instance document, than gives YANG any reason to exist. Otherwise we would just use RelaxNG and not bother with trying to characterize network configuration at all. Martin's proposal for assigned-by is almost perfect. The only problem is that 'assigned-by' (system/user) seems too much like 'ordered-by' (system/user). The real semantics of assigned-by is (user/all) [default: all]. Assigned-by user can be used with mandatory (true/false). Here is the full set of values with 2 independent variables: leaf A { type string; mandatory true; assigned-by all; } leaf B { type string; mandatory false; assigned-by all; } leaf C { type string; mandatory true; assigned-by user; } leaf D { type string; mandatory false; assigned-by user; } The CLR is that assigned-by user and default-stmt do not make sense together. A: current ambiguous mandatory=true in yang-07; agent may provide a value B: current ambiguous optional leaf (may get created or not) C: user must provide a value; server will not provide any default D: user may provide a value; server will not provide any default Does this help or make things worse? > Yours, > Joel > Andy > > Martin Bjorklund wrote: >> Phil Shafer wrote: >>> I believe it was articulated in the "assigned-by system" proposal: >>> >>> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 >>> >>> I am personally in favor of this, but the concensus was not. The >>> issue is still marked open, so perhaps it's time for another concensus >>> call? >> >> I'm also in favor of this, but I'm not sure I want to re-open the >> concensus call. See the email >> http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html for >> some open issues. My main concern is that if we add this it will >> delay the process. This is a known issue, and the WG decided to not >> add any more features. This issue was known at the time. There are >> more nice to haves that could be added, but at some point we have to >> stop. >> >> >> /martin >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Tue Aug 18 12:24: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 A9A7628C367 for ; Tue, 18 Aug 2009 12:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=0.053, 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 9yzifU2448lm for ; Tue, 18 Aug 2009 12:24:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C75143A6E4D for ; Tue, 18 Aug 2009 12:24:57 -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 3D32CD80096; Tue, 18 Aug 2009 21:25:02 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908181710.n7IHAaZF042972@idle.juniper.net> References: <200908181710.n7IHAaZF042972@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 18 Aug 2009 21:25:00 +0200 Message-Id: <1250623500.3645.154.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 19:24:58 -0000 Phil Shafer píše v Út 18. 08. 2009 v 13:10 -0400: > Ladislav Lhotka writes: > >Phil Shafer píše v Út 18. 08. 2009 v 10:45 -0400: > >> Ladislav Lhotka writes: > >> >4) Using the rules for "mandatory" in Sec. 3.1, the device MUST > >> >determine the minimum valid configuration and make sure all mandatory > >> >leaves in the "running" configuration are initialized with values that > >> >are valid according to the data model. These system-assigned values > >> >SHOULD be described in system documentation. > >... Why is > >my formulation "a completely different concept"? Do you want to allow an > >initial configuration that is invalid? > > Sorry. My bad. I completely missed that you are talking about > initial configurations. The comment "the device MUST ... make sure > all mandatory leaves ... are initialized with values" confused me, > since this sounds like the device must fill in those values. You > are just saying that should be valid when the box boots > up, and I agree with this. Yes, only initial configuration is special. Other mandatory leafs should be set explicitly by a client. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Tue Aug 18 13:03: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 03D353A6B9F for ; Tue, 18 Aug 2009 13:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.559 X-Spam-Level: X-Spam-Status: No, score=-7.559 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, GB_I_LETTER=-2, 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 gu4LZutj7ZUe for ; Tue, 18 Aug 2009 13:03:05 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id DA1DE3A6BEC for ; Tue, 18 Aug 2009 13:03:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSosI9BaBatrcJ0sbtZCvF1bbfiV7M/Jp@postini.com; Tue, 18 Aug 2009 13:03:10 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, 18 Aug 2009 12:58:18 -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, 18 Aug 2009 12:58:18 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 12:58:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 12:58:17 -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 n7IJwGd66697; Tue, 18 Aug 2009 12:58:17 -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 n7IJkR2G045103; Tue, 18 Aug 2009 19:46:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908181946.n7IJkR2G045103@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A8AFEC4.7000800@netconfcentral.com> Date: Tue, 18 Aug 2009 15:46:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2009 19:58:17.0514 (UTC) FILETIME=[3A8200A0:01CA203E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 20:03:06 -0000 Andy Bierman writes: >The CLR is that assigned-by user and default-stmt do >not make sense together. "assigned-by user" is the normal (aka default ;^) behavior, so mixing this with the default statement is fine. > A: current ambiguous mandatory=true in yang-07; agent may provide a value I don't think mandatory is ambiguous in yang. Mandatory means the value must appear in a valid configuration. > B: current ambiguous optional leaf (may get created or not) "leaf" is ambiguous? When did this happen? I think there are eight cases, with three axis: statement value code mandatory (true | false) mf | mt assigned-by (system | user) as | au default (given | none) dg | dn Using a stupid two-letter code for each axis gives: mt-as-dg: error: invalid combination (mandatory plus assigned-by system) mt-as-dn: error: " " mt-au-dg: error: invalid combination (mandatory plus default) mt-au-dn: value must be present mf-as-dg: error: invalid combination (assigned-by system plus default) mf-as-dn: system will assign a value if none is present mf-au-dg: default will be implicitly used if none is configured mf-au-dn: no value will be used if none is configured So the CLRs are: - mandatory cannot be true if assigned-by system or a default value is given - assigned-by system cannot be set if a default value is given But the WG concensus was against assigned-by, so we should let this topic drop. Thanks, Phil From andy@netconfcentral.com Tue Aug 18 13:35: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 71F913A6DDB for ; Tue, 18 Aug 2009 13:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, GB_I_LETTER=-2] 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 KILm3H+rwMW9 for ; Tue, 18 Aug 2009 13:35:03 -0700 (PDT) Received: from n11a.bullet.mail.mud.yahoo.com (n11a.bullet.mail.mud.yahoo.com [209.191.125.176]) by core3.amsl.com (Postfix) with SMTP id 938093A6B7D for ; Tue, 18 Aug 2009 13:35:03 -0700 (PDT) Received: from [68.142.194.243] by n11.bullet.mail.mud.yahoo.com with NNFMP; 18 Aug 2009 20:35:06 -0000 Received: from [68.142.201.72] by t1.bullet.mud.yahoo.com with NNFMP; 18 Aug 2009 20:35:06 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 18 Aug 2009 20:35:06 -0000 X-Yahoo-Newman-Id: 938100.94915.bm@omp424.mail.mud.yahoo.com Received: (qmail 16880 invoked from network); 18 Aug 2009 20:35:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 18 Aug 2009 20:35:06 -0000 X-YMail-OSG: y6a4H98VM1lwEwRXBHP9K7vJrZt0x0sHnoc0Y2.EpkalXgxgKqZJW0n7AqFWSLl2nH4fMnaXFs6cY8HgEfYH2iOriZfHoMIL4QPWPhOqNB92fAEHTE8JaLhrMHDhatiI3WfximcEGHSm6pw6Y.arMAJ_2T5AcrNYLGYPPi1977ACxZolwPlThRW.htGhk8YOYwIckS_ac_knsU_bRm2dtE1oFLtYRPpm500vkXrdZMaV9WkrO.Ps3D2jE2iXCgbP.Q26hj2VdgYt9Jo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8B1079.2030205@netconfcentral.com> Date: Tue, 18 Aug 2009 13:35:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908181946.n7IJkR2G045103@idle.juniper.net> In-Reply-To: <200908181946.n7IJkR2G045103@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 20:35:04 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The CLR is that assigned-by user and default-stmt do >> not make sense together. > > "assigned-by user" is the normal (aka default ;^) behavior, so > mixing this with the default statement is fine. > no -- you have it backwards. YANG does not support 'assigned-by user' at all, except in description statements. >> A: current ambiguous mandatory=true in yang-07; agent may provide a value > > I don't think mandatory is ambiguous in yang. Mandatory means > the value must appear in a valid configuration. > >> B: current ambiguous optional leaf (may get created or not) > > "leaf" is ambiguous? When did this happen? > > I think there are eight cases, with three axis: > statement value code > mandatory (true | false) mf | mt > assigned-by (system | user) as | au > default (given | none) dg | dn > > Using a stupid two-letter code for each axis gives: > > mt-as-dg: error: invalid combination (mandatory plus assigned-by system) > mt-as-dn: error: " " > mt-au-dg: error: invalid combination (mandatory plus default) > mt-au-dn: value must be present > mf-as-dg: error: invalid combination (assigned-by system plus default) > mf-as-dn: system will assign a value if none is present > mf-au-dg: default will be implicitly used if none is configured > mf-au-dn: no value will be used if none is configured > > So the CLRs are: > - mandatory cannot be true if assigned-by system or a default value is given > - assigned-by system cannot be set if a default value is given > > But the WG concensus was against assigned-by, so we should let this > topic drop. > The current meaning of mandatory=true is not clear. There is no way in the YANG data model for the application developer to get satisfactory answers question for a few simple questions: leaf foo { type string; } "If I do not provide the leaf, will the agent pick some value, or not?" "If the agent does not support with-defaults=report-all, then how would I even find out if this is the source of the config problem?" leaf bar { mandatory true; type string; } "If I do not provide the leaf, will the agent pick some value, or will I eventually get back a 'data-missing' error?" > Thanks, > Phil > Andy From andy@netconfcentral.com Tue Aug 18 14:04: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 9C1003A6A17 for ; Tue, 18 Aug 2009 14:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 HHOMSYyeMxpg for ; Tue, 18 Aug 2009 14:04:57 -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 DAD673A67B7 for ; Tue, 18 Aug 2009 14:04:57 -0700 (PDT) Received: (qmail 39394 invoked from network); 18 Aug 2009 21:04:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2009 21:04:59 -0000 X-YMail-OSG: YbSlESIVM1kLOib2MNwYHZt5zOdARoKIcGITm0aLY0o5E2ohlVs8mEGIkPO2y6OkMoxFQvRoPFHOZ5xqa6vpBrcIKRPjJRz2k4KFcNvNE3kbCzvLKT3qDJgNVBAXZcMPv2e2798ZaigW274apx25RMqQ1NGX1zTFzEO9876ge8DgOb7VeiJ_Pq75W1U79GTvZLdRXy7SxQ.mXgxX8xDV0H1czu2_ts0pbMlb4joWlh4GDsRI49UpTZahKd1xvpNhk_1cNzYzVFctzhE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8B177B.2040503@netconfcentral.com> Date: Tue, 18 Aug 2009 14:04:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908181946.n7IJkR2G045103@idle.juniper.net> <4A8B1079.2030205@netconfcentral.com> In-Reply-To: <4A8B1079.2030205@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 21:04:58 -0000 Andy Bierman wrote: ... > > leaf foo { > type string; > } > > "If I do not provide the leaf, will the agent pick some value, > or not?" > > "If the agent does not support with-defaults=report-all, then how would > I even find out if this is the source of the config problem?" > > > leaf bar { > mandatory true; > type string; > } > > "If I do not provide the leaf, will the agent pick some value, > or will I eventually get back a 'data-missing' error?" > > choice fubar { mandatory true; case a { leaf X { type string; } leaf Y { type string; mandatory true; } } leaf b { type string; } } If the device hides all defaults, then how do I know if the candidate has /X or /b or neither? The answer also has an impact on NP containers. A mandatory child leaf within an NP container is only mandatory if any of its siblings exist. The very fuzzy definition of a default value in YANG makes it impossible to know if that mandatory leaf needs to be created or not. A leaf without a default can also exist because the agent created it, so the issue is not related to the YANG default-stmt. This is a very important application-centric question. Every single developer of every single YANG module ever written is going to ask the same question "Do I have to provide that leaf, and therefore write some code to do that, or not?" > >> Thanks, >> Phil >> > Andy From phil@juniper.net Tue Aug 18 15:24: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 0A2133A6B23 for ; Tue, 18 Aug 2009 15:24:36 -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 W25+XClk8Czv for ; Tue, 18 Aug 2009 15:24:35 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 6FE523A6AD4 for ; Tue, 18 Aug 2009 15:24:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSosp+AzvTDiLa8FlFlZ+j2LGmVgwqMph@postini.com; Tue, 18 Aug 2009 15:24:40 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, 18 Aug 2009 15:22:05 -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, 18 Aug 2009 15:22:06 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 15:22:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 15:22:04 -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 n7IMM4d35078; Tue, 18 Aug 2009 15:22:04 -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 n7IMAEWk046169; Tue, 18 Aug 2009 22:10:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908182210.n7IMAEWk046169@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A8B177B.2040503@netconfcentral.com> Date: Tue, 18 Aug 2009 18:10:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2009 22:22:04.0949 (UTC) FILETIME=[50DC1C50:01CA2052] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 22:24:36 -0000 Andy Bierman writes: >Every single developer of every single YANG module ever written >is going to ask the same question "Do I have to provide that leaf, >and therefore write some code to do that, or not?" If mandatory is true, the configuration is not valid if the leaf does not have a value. Baring miracles, the application should understand that providing that value is part of its job. Thanks, Phil From phil@juniper.net Tue Aug 18 15:32: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 009C33A6A89 for ; Tue, 18 Aug 2009 15:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_64=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 BMq7lwCXx8V2 for ; Tue, 18 Aug 2009 15:32:46 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 5B5033A6A2C for ; Tue, 18 Aug 2009 15:32:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSosrqEsuO77hH+wo/rwqjfLLcbBa7D2v@postini.com; Tue, 18 Aug 2009 15:32:51 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, 18 Aug 2009 15:29:45 -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, 18 Aug 2009 15:29:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 15:29:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 15:29:45 -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 n7IMTid38366; Tue, 18 Aug 2009 15:29:44 -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 n7IMHs5h046209; Tue, 18 Aug 2009 22:17:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908182217.n7IMHs5h046209@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A8B1079.2030205@netconfcentral.com> Date: Tue, 18 Aug 2009 18:17:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2009 22:29:45.0180 (UTC) FILETIME=[632DC9C0:01CA2053] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 22:32:47 -0000 Andy Bierman writes: >YANG does not support 'assigned-by user' at all, >except in description statements. All config=true leafs in YANG can be assigned by the user. > leaf foo { > type string; > } > > "If I do not provide the leaf, will the agent pick some value, > or not?" This is the hole that the lack of "assigned-by system" leaves. The WG concensus is that we are skipping it. Move along. These aren't the 'droids you're looking for..... > "If the agent does not support with-defaults=report-all, then how would > I even find out if this is the source of the config problem?" The leaf is not mandatory. There is no default. It's not the source of your config problem. > leaf bar { > mandatory true; > type string; > } > > "If I do not provide the leaf, will the agent pick some value, > or will I eventually get back a 'data-missing' error?" No, the agent will not pick some value. The 'mandatory true' means that if you make this hierarchy in which this leaf belongs and you don't make this leaf, your configuration is not valid. When you validate it, you will get an error. No clue which error. Thanks, Phil From andy@netconfcentral.com Tue Aug 18 16:20: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 1B54F28C2D3 for ; Tue, 18 Aug 2009 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=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 U3O6-0OJEOm5 for ; Tue, 18 Aug 2009 16:20:54 -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 7767A3A686D for ; Tue, 18 Aug 2009 16:20:54 -0700 (PDT) Received: (qmail 80156 invoked from network); 18 Aug 2009 23:20:57 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 18 Aug 2009 23:20:57 -0000 X-YMail-OSG: L3C2oUoVM1ljw6h4zcVtL8mdUn2Xn0lFnB7e9RjiuCfklXP.3oz2t1gG3RIwwB3JVeVdnYKcnc4gC09gP48sd2tKoKvVp0zc1riSTHkaPY5a4VnrgQY5j9C2DJ6VtBRWXGpBhuEo5BCaXh3Wjnlz.0TDdXzUvbXZ4aPhG1KGjgM5obU.sj8Y3AAH_lv5MjX0O78kP4QQaaDp76eQaVScdVWHmilrUorUFKZcH_jq8BViCFF2QfrtOTziNTEECXVSYnckocMXowTZN5U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8B36E0.9070002@netconfcentral.com> Date: Tue, 18 Aug 2009 16:18:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908182210.n7IMAEWk046169@idle.juniper.net> In-Reply-To: <200908182210.n7IMAEWk046169@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 18 Aug 2009 23:20:55 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Every single developer of every single YANG module ever written >> is going to ask the same question "Do I have to provide that leaf, >> and therefore write some code to do that, or not?" > > If mandatory is true, the configuration is not valid if the leaf > does not have a value. Baring miracles, the application should > understand that providing that value is part of its job. > I don't know why you would reach that conclusion. The mandatory-stmt does not mean the application must supply a value. It has no utility at all to an application. On the device-side, if I had some data model like the ping control table in ping.yang, then I never want the device to fill in the host address to ping. If I commit the candidate, I want it to fail, not start pinging a random address because the agent filled in a mandatory leaf (because all mandatory means is that some value must be present). Ironically, the only thing an application can count on is the default-stmt, if no leaf is provided. But since the device MUST provide the exact static value, it is very likely that WGs and vendors will not be able to agree on 1 static value in every possible scenario. So most leafs will have undocumented defaults (where defaults='trim'). We can't agree on what a default even means, so on devices where default='explicit', you have no idea how to even discover the default values. > Thanks, > Phil > Andy From andy@netconfcentral.com Tue Aug 18 17:29: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 436BB3A6869 for ; Tue, 18 Aug 2009 17:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 1jTpR-sDISOY for ; Tue, 18 Aug 2009 17:29:39 -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 817BC3A684E for ; Tue, 18 Aug 2009 17:29:39 -0700 (PDT) Received: (qmail 26091 invoked from network); 19 Aug 2009 00:29:42 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2009 00:29:42 -0000 X-YMail-OSG: QxpuGI0VM1m9WCIGWFDUcpYDKoxIH_D80cfygD_4GeE2j8k5kH4Sb9dgRmeAcBwQn1dT.gGR7tDxTlN7Q3OHWPZX9dFseOt4TYGIKcOzamvw5sMSXg49PJrTkZyUmUTtUJ1Qk1B3nQPoFUg3H5sPfNcOAf64zcZ_cj.drW9CLaUoC1X0aKNakmVIRc_y0Y8G0RST_MOrJAbMUdy4wbboc_gkOmxj_BOIj.uL707YnxFxrqzKhcN3sFs9QBlxQG1RTBvptICTiGa4gSIT.o.0fBoeYDRYtWYTLM16rLq_prapin2z2lmqkEWRhQQUYzsJoZK55J.G1jBkb9tI0uI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8B4777.6010200@netconfcentral.com> Date: Tue, 18 Aug 2009 17:29:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> In-Reply-To: <20090818.165456.143451979.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 00:29:40 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> I believe it was articulated in the "assigned-by system" proposal: >> >> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 ... My main concern is that if we add this it will > delay the process. If it is the IETF WG process you mean, than I don't see how that is possible. So what happens if we stop discussions now because we are out of time? We move forward with a WG Last Call, and ask "does anybody have any issues with this draft?" Hurrying up so we can get to WGLC only delays a resolution; it does not avoid it. This is a known issue, and the WG decided to not > add any more features. This issue was known at the time. There are > more nice to haves that could be added, but at some point we have to > stop. I find the leafref to be much more esoteric and corner-case nice-to-have than properties as basic as 'default' and 'mandatory'. A lot more effort went into leafref, and these database properties are much more important than cross references. > > > /martin Andy From andy@netconfcentral.com Tue Aug 18 17:40:59 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 09C7F3A6862 for ; Tue, 18 Aug 2009 17:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 AOU9m8JoYmOI for ; Tue, 18 Aug 2009 17:40:57 -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 109D43A681C for ; Tue, 18 Aug 2009 17:40:57 -0700 (PDT) Received: (qmail 56384 invoked from network); 19 Aug 2009 00:40:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2009 00:40:53 -0000 X-YMail-OSG: wQP1wbgVM1lkpXMZy2xlQoVzudpCgoJP1vGEv7wCsWm5lKCsjnnEe1COZ5MKVCg2_9e9kigm_6X7i9O3YjCs_zURlb9.KUkwV_0oziCX5bVC8cHXYIPTLMnPv3wSVBO3Nf5Cqwz8H0neAZVujf3x0_jMy_o1htOZhN_5d3.M.7VawtrYTVoMsNtWU_rRzS7k1cnAFu.092o8.U10uw5hFxt9_9fCYGyjN4tHMGbymUkeH7VS5llUGlzTrtOc9gOe.YE5Ga3v44WSzKA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8B4A15.3010100@netconfcentral.com> Date: Tue, 18 Aug 2009 17:40:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908182210.n7IMAEWk046169@idle.juniper.net> In-Reply-To: <200908182210.n7IMAEWk046169@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 00:40:59 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Every single developer of every single YANG module ever written >> is going to ask the same question "Do I have to provide that leaf, >> and therefore write some code to do that, or not?" > > If mandatory is true, the configuration is not valid if the leaf > does not have a value. Baring miracles, the application should > understand that providing that value is part of its job. > But you say that the ifMtu object should not be mantatory, right? leaf if-mtu { type uint32; mandatory true; } leaf ping-target { type inet:ip-address; mandatory true; } Every implementation must have these 2 objects in a valid configuration. In one case, the device is going to pick a suitable default every time, and the data modeler wants that to happen. In the other case, the data modeler does not ever want a default value picked by the device. So how does a YANG tool tell these 2 very different use-cases apart? Humans may guess by the leaf name, but the tool can't. I do not agree with you that an application developer does not need to know the difference between these two leafs that have identical machine-readable properties. > Thanks, > Phil > Andy From mbj@tail-f.com Tue Aug 18 23:52: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 4991F3A6BB9 for ; Tue, 18 Aug 2009 23:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.056, 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 LVlcqofTSZyy for ; Tue, 18 Aug 2009 23:52:44 -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 3F2053A6A1F for ; Tue, 18 Aug 2009 23:52:44 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DF9776C595; Wed, 19 Aug 2009 08:52:43 +0200 (CEST) Date: Wed, 19 Aug 2009 08:52:43 +0200 (CEST) Message-Id: <20090819.085243.113447441.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <005401ca2023$51fd9d40$0601a8c0@allison> References: <002c01ca1e4b$fdd29fa0$0601a8c0@allison> <20090817.110245.26949790.mbj@tail-f.com> <005401ca2023$51fd9d40$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] Terminology2 was Re: leafref problems 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, 19 Aug 2009 06:52:45 -0000 "tom.petch" wrote: > Logical but, taken together, that's a surprise. So with suitable imports and > prefixes > > module m {grouping g { leaf x ... > module n {uses g ... > > x is not top-level in module m but is top-level in module n. Yes. > I would like this spelt out in the I-D; I suggest amending > 5.5 to become > only top-level types and groupings > ie those appearing as substatements to a module or submodule statement > can be used outside the module or Ok, fixed. > 6.2.1 bullet 7 I am unclear about; does a > 'module n { uses g > make leaf x top level in this case? Yes. I changed this a bit into: - All leafs, leaf-lists, lists, containers, choices, rpcs, notifications, and anyxmls defined (directly or through a uses statement) within a parent node or at the top-level of the module or its submodules share the same identifier namespace. > Add > A top-level configuration data node is one where there is no other data node > between it and a module or submodule statement. Note that the 'grouping' and > 'uses' statements do not themselves instantiate data nodes but that a 'uses' > statement that is not within a grouping instantiates the nodes that appear in > the 'grouping' statement that it references. > > If that sounds complicated, well it is:-) > > It is needed for the usual suspects, 'when' 'path' 'instance-identifier' > 'must', > could appear in all four or perhaps better in 6.2.1 or 6.4. How about putting it in the Terminology section? Also, I am not convinced the "Note" part is necessary. Section 7.11 on grouping says: The grouping statement is not a data definition statement and, as such, does not define any nodes in the schema tree. Note that we also have: - data definition statement: A statement that defines new data nodes. One of container, leaf, leaf-list, list, choice, case, augment, uses, and anyxml. So I hope it is clear that 'uses' defines data nodes but groupings do not. I propose to add this to Terminology: - top-level data node: A data node where there is no other data node between it and a module or submodule statement. /martin From lhotka@cesnet.cz Wed Aug 19 00:01:32 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 A67D33A6A1F for ; Wed, 19 Aug 2009 00:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=0.051, 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 yeQ417Q3KzT3 for ; Wed, 19 Aug 2009 00:01:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8E9693A6996 for ; Wed, 19 Aug 2009 00:01:31 -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 C1EBED800C1; Wed, 19 Aug 2009 09:01:35 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4A8AC2DF.2010000@joelhalpern.com> References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> <4A8AC2DF.2010000@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 09:01:33 +0200 Message-Id: <1250665293.24768.56.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 07:01:32 -0000 Joel M. Halpern píše v Út 18. 08. 2009 v 11:03 -0400: > I could certainly live with adding "agent-supplied value", or > "assigned-by-system." > I understand Martin's argument for not adding a new feature. > > But if we are not going to add a feature, then I think we MUST (in the > ineroperability sense) add some words that explain how this is supposed > to work. It is quite clear that people understand it differently. > (Ladislav's understanding of how one could use Mandatory for this is > just one example. I do not read the text as allowing the behavior he > understand in good faith to be correct and appropraite.) I also have to apologize for contributing to the confusion. After reading Phil's later message I realized the misunderstanding was mainly due to the lack of distinction between the assumptions on the initial configuration on one side and subsequent edits on the other. Some explanation of the former is needed in the sense that the server must provide certain minimum set of mandatory nodes in order to make the initial configuration valid - these nodes are thus implicitly "assigned-by system". Otherwise, the rules seem to be OK if we assume that any other mandatory nodes are up to the client to fill in. Lada > > Yours, > Joel > > > Martin Bjorklund wrote: > > Phil Shafer wrote: > >> I believe it was articulated in the "assigned-by system" proposal: > >> > >> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 > >> > >> I am personally in favor of this, but the concensus was not. The > >> issue is still marked open, so perhaps it's time for another concensus > >> call? > > > > I'm also in favor of this, but I'm not sure I want to re-open the > > concensus call. See the email > > http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html for > > some open issues. My main concern is that if we add this it will > > delay the process. This is a known issue, and the WG decided to not > > add any more features. This issue was known at the time. There are > > more nice to haves that could be added, but at some point we have to > > stop. > > > > > > /martin > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Aug 19 00:13: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 6767228C241 for ; Wed, 19 Aug 2009 00:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.053, 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 1E487Q805C85 for ; Wed, 19 Aug 2009 00:13:39 -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 62B8B28C23B for ; Wed, 19 Aug 2009 00:13:39 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0926576C59C; Wed, 19 Aug 2009 09:13:44 +0200 (CEST) Date: Wed, 19 Aug 2009 09:13:43 +0200 (CEST) Message-Id: <20090819.091343.73121620.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8B4777.6010200@netconfcentral.com> References: <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> <4A8B4777.6010200@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] agent-default -- new 3rd state 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, 19 Aug 2009 07:13:40 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Phil Shafer wrote: > >> I believe it was articulated in the "assigned-by system" proposal: > >> > >> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 > > ... > > My main concern is that if we add this it will > > delay the process. > > If it is the IETF WG process you mean, > than I don't see how that is possible. > > So what happens if we stop discussions now because > we are out of time? We move forward with a WG Last Call, > and ask "does anybody have any issues with this draft?" > Hurrying up so we can get to WGLC only delays a resolution; > it does not avoid it. There are many things we could add to YANG in order to make more precise data models and to help the tools automation process. We will never be able to have formal statements for everything, so we know that we will also have to rely on description clauses. At some point we will have to be done with version 1, publish it and get experience. In fact, we already decided that we have reached this point. The features we have are good enough for version 1. These are my concerns. But at the same time, if we agree that what we have does not work without a new statement, then we will have to fix it. /martin From mbj@tail-f.com Wed Aug 19 00:39: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 52DDA28C35A for ; Wed, 19 Aug 2009 00:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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 hiB5QFCukCRC for ; Wed, 19 Aug 2009 00:39: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 EC8D028C366 for ; Wed, 19 Aug 2009 00:39:23 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EE02F76C595; Wed, 19 Aug 2009 09:39:00 +0200 (CEST) Date: Wed, 19 Aug 2009 09:39:00 +0200 (CEST) Message-Id: <20090819.093900.34596919.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8B36E0.9070002@netconfcentral.com> References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B36E0.9070002@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] agent-default -- new 3rd state 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, 19 Aug 2009 07:39:30 -0000 Andy Bierman wrote: > The mandatory-stmt does not mean the application must supply > a value. It has no utility at all to an application. This is not true. If the client creates data in which there is a mandatory leaf, it must provide a value for that leaf to make the config valid. This means that there are some use cases which cannot be perfectly defined today. For example, a leaf which is initialized by the server if it is not provided. One use case that has been described before is the 'uid' of a user. If a 'user' is created without a value for the 'uid', the server will assign a value for this leaf. This is not a (dynamic) default value; it is really present in the config. A client can read it and change it. In one sense such a leaf is mandatory, since it is always present in the config. But just marking it as 'mandatory true' is not correct, since this will make the client think it MUST provide a value. Currently, such a leaf must be defined as 'mandatory false', and the behavior defined in the description clause. The statement 'assigned-by system' was an attempt to support this use case. Another use case that cannot be perfectly defined is the case of dynamic default values. These comes in many flavors; here are three: o The default value depends on some state data, e.g. the default mtu depends on the card type. o The default value depends on some other config data, e.g. the listen-port for a server depends on the protocol (smtp port 25, http port 80 etc). o The default value is the value of another leaf (this has been called default ref in past discussions). E.g. there is a global idle-timeout leaf which is used unless a specific idle-timeout leaf is defined for a server. I'm sure there are more variants. Currently, these leafs must be defined as 'mandatory false', and the behavior defined in description clauses (and/or with YANG extensions). Do we add formal YANG statements for all these use cases? As I wrote in some other thread, in general I am in favor for more precise models and more support for automation, but at some point we have to stop. /martin From j.schoenwaelder@jacobs-university.de Wed Aug 19 01:16: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 4150328C206 for ; Wed, 19 Aug 2009 01:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Rfyy9g8IUOJq for ; Wed, 19 Aug 2009 01:16:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2DD828C1D6 for ; Wed, 19 Aug 2009 01:16:27 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EA9BC000E; Wed, 19 Aug 2009 10:02:04 +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 wl1Q8Y6gLRS3; Wed, 19 Aug 2009 10:02:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A59D6C009D; Wed, 19 Aug 2009 10:02:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5658EC724CA; Wed, 19 Aug 2009 10:02:01 +0200 (CEST) Date: Wed, 19 Aug 2009 10:02:01 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090819080201.GD6741@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8B4A15.3010100@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 08:16:29 -0000 On Wed, Aug 19, 2009 at 02:40:53AM +0200, Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> Every single developer of every single YANG module ever written > >> is going to ask the same question "Do I have to provide that leaf, > >> and therefore write some code to do that, or not?" > > > > If mandatory is true, the configuration is not valid if the leaf > > does not have a value. Baring miracles, the application should > > understand that providing that value is part of its job. > > > > But you say that the ifMtu object should not be mantatory, right? > > leaf if-mtu { > type uint32; > mandatory true; > } > > leaf ping-target { > type inet:ip-address; > mandatory true; > } > > Every implementation must have these 2 objects in a valid > configuration. In one case, the device is going to pick > a suitable default every time, and the data modeler wants > that to happen. In the other case, the data modeler does > not ever want a default value picked by the device. I think the MTU value that pops up when I initialize an interface with no explicit configuration is operational state and not config state. So the above definition of if-mtu is likely a data modeling error. And perhaps most parameters a system uses if you switch it on are just operational state and not really config data. A home router might boot up with a default non-global IP address and this can again be considered operational state since there is no config data yet. I guess I start to like the model where stuff that has not be explicitely configured really is not configuration and thus not part of a configuration datastore. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Aug 19 01:25:19 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 3CCA83A68ED for ; Wed, 19 Aug 2009 01:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.047, 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 nmMP7j3uy8CR for ; Wed, 19 Aug 2009 01:25:18 -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 5B0C53A683D for ; Wed, 19 Aug 2009 01:25:18 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5941776C59C for ; Wed, 19 Aug 2009 10:24:58 +0200 (CEST) Date: Wed, 19 Aug 2009 10:24:57 +0200 (CEST) Message-Id: <20090819.102457.207114260.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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 Subject: [netmod] leaf-list problem 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, 19 Aug 2009 08:25:19 -0000 Hi, Consider this data model from the draft: leaf-list domain-search { type string; description "List of domain names to search"; } Suppose that a client wants to set this to the same list on many servers. It can build an edit-config request with: high.example.com low.example.com But since the default operation is 'merge', this will just append the two domains to the end of the current leaf-list on each device. It really wants to replace the contents of this leaf-list, regardless of what was there, so it might try: high.example.com low.example.com where the first line supposedly replaces the entire list with one entry 'high.example.com', and the second line appends the second entry. But this doesn't work, b/c the current text says: If the operation is "merge" or "replace" the leaf-list entry is created if it does not exist. So the first line would just append high.example.com, just as merge would have done. I suggest we change this text to: If the operation is "merge" the leaf-list entry is created if it does not exist. If the operation is "replace" the complete leaf-list contents is replaced with the new leaf-list entry. /martin From j.schoenwaelder@jacobs-university.de Wed Aug 19 01:39: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 3AAC33A6ABA for ; Wed, 19 Aug 2009 01:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 LnF1mRbYQKjY for ; Wed, 19 Aug 2009 01:39:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B41D128C237 for ; Wed, 19 Aug 2009 01:39:45 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93F9BC000E; Wed, 19 Aug 2009 10:39:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xqa9zj3sjz6l; Wed, 19 Aug 2009 10:39: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 A0127C009D; Wed, 19 Aug 2009 10:39:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64680C726E8; Wed, 19 Aug 2009 10:39:48 +0200 (CEST) Date: Wed, 19 Aug 2009 10:39:48 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090819083948.GE6741@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20090819.102457.207114260.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090819.102457.207114260.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] leaf-list problem 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, 19 Aug 2009 08:39:47 -0000 On Wed, Aug 19, 2009 at 10:24:57AM +0200, Martin Bjorklund wrote: > Hi, > > Consider this data model from the draft: > > leaf-list domain-search { > type string; > description "List of domain names to search"; > } > > Suppose that a client wants to set this to the same list on many > servers. It can build an edit-config request with: > > high.example.com > low.example.com > > But since the default operation is 'merge', this will just append the > two domains to the end of the current leaf-list on each device. It > really wants to replace the contents of this leaf-list, regardless of > what was there, so it might try: > > high.example.com > low.example.com > > where the first line supposedly replaces the entire list with one > entry 'high.example.com', and the second line appends the second > entry. > > But this doesn't work, b/c the current text says: > > If the operation is "merge" or "replace" the leaf-list entry is > created if it does not exist. > > So the first line would just append high.example.com, just as merge > would have done. > > > I suggest we change this text to: > > If the operation is "merge" the leaf-list entry is > created if it does not exist. > > If the operation is "replace" the complete leaf-list contents is > replaced with the new leaf-list entry. I agree that this is an issue to resolve; I did run into this myself recently. But given the new wording, what is the effect of doing this: low.example.com high.example.com Do we state anywhere that things are processed in sequential order? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Aug 19 01:53: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 896BE3A6BA7 for ; Wed, 19 Aug 2009 01:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.045, 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 I48kDIOE8NzK for ; Wed, 19 Aug 2009 01:53:06 -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 882DB3A6AE8 for ; Wed, 19 Aug 2009 01:53:06 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A0B8276C595; Wed, 19 Aug 2009 10:53:10 +0200 (CEST) Date: Wed, 19 Aug 2009 10:53:10 +0200 (CEST) Message-Id: <20090819.105310.158497656.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090819083948.GE6741@elstar.local> References: <20090819.102457.207114260.mbj@tail-f.com> <20090819083948.GE6741@elstar.local> 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] leaf-list problem 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, 19 Aug 2009 08:53:07 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 19, 2009 at 10:24:57AM +0200, Martin Bjorklund wrote: > > Hi, > > > > Consider this data model from the draft: > > > > leaf-list domain-search { > > type string; > > description "List of domain names to search"; > > } > > > > Suppose that a client wants to set this to the same list on many > > servers. It can build an edit-config request with: > > > > high.example.com > > low.example.com > > > > But since the default operation is 'merge', this will just append the > > two domains to the end of the current leaf-list on each device. It > > really wants to replace the contents of this leaf-list, regardless of > > what was there, so it might try: > > > > high.example.com > > low.example.com > > > > where the first line supposedly replaces the entire list with one > > entry 'high.example.com', and the second line appends the second > > entry. > > > > But this doesn't work, b/c the current text says: > > > > If the operation is "merge" or "replace" the leaf-list entry is > > created if it does not exist. > > > > So the first line would just append high.example.com, just as merge > > would have done. > > > > > > I suggest we change this text to: > > > > If the operation is "merge" the leaf-list entry is > > created if it does not exist. > > > > If the operation is "replace" the complete leaf-list contents is > > replaced with the new leaf-list entry. > > I agree that this is an issue to resolve; I did run into this myself > recently. But given the new wording, what is the effect of doing this: > > low.example.com > high.example.com > > Do we state anywhere that things are processed in sequential order? >From 7.7.7: If several entries in an "ordered-by user" leaf-list are modified in the same request, the entires are modified one at the time, in the order of the XML elements in the request. We can change this: s/"ordered-by user"// Oh, there's a typo: s/entires/entries/. Now fixed (in two places). /martin From lhotka@cesnet.cz Wed Aug 19 02:26: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 5E6DA3A6D47 for ; Wed, 19 Aug 2009 02:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=0.050, 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 WciQpeZkT54C for ; Wed, 19 Aug 2009 02:26:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8C4A93A6D23 for ; Wed, 19 Aug 2009 02:26:44 -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 5088BD80095; Wed, 19 Aug 2009 11:26:49 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090819080201.GD6741@elstar.local> References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 11:26:48 +0200 Message-Id: <1250674008.24768.114.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 09:26:45 -0000 Juergen Schoenwaelder píše v St 19. 08. 2009 v 10:02 +0200: > I think the MTU value that pops up when I initialize an interface with > no explicit configuration is operational state and not config state. > So the above definition of if-mtu is likely a data modeling error. > > And perhaps most parameters a system uses if you switch it on are just > operational state and not really config data. A home router might boot > up with a default non-global IP address and this can again be > considered operational state since there is no config data yet. I It may write this address to configuration data as well, as it is also explicitly configured (not obtained from DHCP). I just reset my web camera to the factory default state and the auto-assigned address appeared in the configuration form. So it can work both ways. > guess I start to like the model where stuff that has not be > explicitely configured really is not configuration and thus not part > of a configuration datastore. In this case the link between the IP address as state data and the corresponding configuration slot is also important. If the IP address is manually configured, the state data item is essentially a leafref. But is it reasonable to continue working with both interpretations and allow both modelling approaches? The simple question whether "mtu" should be defined as mandatory or not then has no simple answer. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Wed Aug 19 02:59: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 E32EA3A6C03 for ; Wed, 19 Aug 2009 02:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 JoeEUK4PUzKf for ; Wed, 19 Aug 2009 02:59:55 -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 BC5EB3A6D4D for ; Wed, 19 Aug 2009 02:59:41 -0700 (PDT) Received: (qmail 61296 invoked from network); 19 Aug 2009 09:59:44 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2009 09:59:44 -0000 X-YMail-OSG: c.uMr0IVM1mcK9PoIVJTzVHBif82K98y2LX2bDeQbOMs5CMFcPY7.xI4HuaeFNR2kwGL7o7n0SbKc01xeEw_7CaBrccukCW9nWOeX0ysCBSnlP7bUChBVFegvJIUtpFEYoTlZ7CSkHK_ViuMcF3opsUct3T35zfk.y.LxVPQ4l7XR1H7bdRkMys2Gvj3t6VeqbJapQsMkreIQjCB0wTnuCche2MCnvLY_qLxMWvlF8KY7cdVVvfKjqRIAxxonIHY0Jh3NfIMkOHqNpj19vBY8o867q_UW7.ImMZPpTAwXuMpAgZTgsAq2NyR5ozF.MA8Vja.UfvcI5Qlcn5Wfelyj4BLOCTPZygLrZO5Sf2dQWjzJ1BN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8BCD11.3090703@netconfcentral.com> Date: Wed, 19 Aug 2009 02:59:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B36E0.9070002@netconfcentral.com> <20090819.093900.34596919.mbj@tail-f.com> In-Reply-To: <20090819.093900.34596919.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 09:59:56 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> The mandatory-stmt does not mean the application must supply >> a value. It has no utility at all to an application. > > This is not true. If the client creates data in which there is a > mandatory leaf, it must provide a value for that leaf to make the > config valid. > I'll drop this thread, but none of you actually seem to understand the difference between MUST and SHOULD. > This means that there are some use cases which cannot be perfectly > defined today. For example, a leaf which is initialized by the server > if it is not provided. One use case that has been described before is > the 'uid' of a user. If a 'user' is created without a value for the > 'uid', the server will assign a value for this leaf. This is not a > (dynamic) default value; it is really present in the config. A client > can read it and change it. In one sense such a leaf is mandatory, > since it is always present in the config. But just marking it as > 'mandatory true' is not correct, since this will make the client think > it MUST provide a value. Currently, such a leaf must be defined as > 'mandatory false', and the behavior defined in the description clause. > The statement 'assigned-by system' was an attempt to support this use > case. > > Another use case that cannot be perfectly defined is the case of > dynamic default values. These comes in many flavors; here are three: > > o The default value depends on some state data, e.g. the default > mtu depends on the card type. > > o The default value depends on some other config data, e.g. the > listen-port for a server depends on the protocol (smtp port 25, > http port 80 etc). > > o The default value is the value of another leaf (this has been > called default ref in past discussions). E.g. there is a global > idle-timeout leaf which is used unless a specific idle-timeout > leaf is defined for a server. > > I'm sure there are more variants. Currently, these leafs must be > defined as 'mandatory false', and the behavior defined in description > clauses (and/or with YANG extensions). > These account for lots of data model objects. The static default-stmt may not get used a lot by WGs or vendors. > Do we add formal YANG statements for all these use cases? As I wrote > in some other thread, in general I am in favor for more precise models > and more support for automation, but at some point we have to stop. > what kind of strawman is this? I am talking about 1 bit of information. What happens on every device if a mandatory leaf is not provided? Will this be silently accepted, or rejected with an error? The official answer is "who cares", but I was looking for "yes" or "no". > > > /martin > Andy From andy@netconfcentral.com Wed Aug 19 03:05: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 8EF303A6C44 for ; Wed, 19 Aug 2009 03:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=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 CP3bpWu0GgLg for ; Wed, 19 Aug 2009 03:05:14 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id B46163A6A51 for ; Wed, 19 Aug 2009 03:05:14 -0700 (PDT) Received: (qmail 55877 invoked from network); 19 Aug 2009 10:05:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2009 10:05:18 -0000 X-YMail-OSG: 8e91VzoVM1lwZkwZeMp0gekPFTjQdDthmugtDDRxtkGnUzlETU7pWUO2tNTgs8N87_zrnstrlWLr8Y4Ek8eUmyvcUjY3j.mwGA4bHb6UlDVzF8JNnb9Ej7drzn20qy.6OKJUP4w3NGQQZsu4T1iTpKjylKbSPfZO1OL26eP27tAN4CWA.n4JGYgjaJaeBBQtdMUGtfx1NFfmHnNBpnqjcw7j_QKfj9d0oQ9j0TMKx6qIWFb_fKoCfnUOc7YFrouKyj._3KtRW4cig7HlKsTzkZ2AI95cyJFD2ZqJbFMjqHtsRjXWgiTTXAhsSncCfsowgqekYPk5eo6PypzbAdyP1nc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8BCE60.6020803@netconfcentral.com> Date: Wed, 19 Aug 2009 03:05:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <20090819.102457.207114260.mbj@tail-f.com> In-Reply-To: <20090819.102457.207114260.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-list problem 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, 19 Aug 2009 10:05:15 -0000 Martin Bjorklund wrote: > Hi, > > Consider this data model from the draft: > > leaf-list domain-search { > type string; > description "List of domain names to search"; > } > > Suppose that a client wants to set this to the same list on many > servers. It can build an edit-config request with: > > high.example.com > low.example.com > > But since the default operation is 'merge', this will just append the > two domains to the end of the current leaf-list on each device. It > really wants to replace the contents of this leaf-list, regardless of > what was there, so it might try: > > high.example.com > low.example.com > > where the first line supposedly replaces the entire list with one > entry 'high.example.com', and the second line appends the second > entry. > > But this doesn't work, b/c the current text says: > > If the operation is "merge" or "replace" the leaf-list entry is > created if it does not exist. > > So the first line would just append high.example.com, just as merge > would have done. > > > I suggest we change this text to: > > If the operation is "merge" the leaf-list entry is > created if it does not exist. > > If the operation is "replace" the complete leaf-list contents is > replaced with the new leaf-list entry. > > This is a new feature request. I do not want to change the meaning of nc:replace now. The nc:operation attribute applies only to the subtree it appears in -- not its siblings. This is a massive change to the NETCONF protocol. Delete the whole leaf-list, then add it back. Problem solved. > /martin Andy From andy@netconfcentral.com Wed Aug 19 03: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 26EE33A685A for ; Wed, 19 Aug 2009 03:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.227, 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 lGHJ9RbI85X0 for ; Wed, 19 Aug 2009 03:15:40 -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 3E1503A6767 for ; Wed, 19 Aug 2009 03:15:40 -0700 (PDT) Received: (qmail 53333 invoked from network); 19 Aug 2009 10:15:44 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2009 10:15:43 -0000 X-YMail-OSG: 1qSlnH4VM1kUKIHkAMXilLEpnXDKwUXIPpy72Wz56pnLW661ZqAs5oQY6eipWHub2iZ44WdZrhezUNfvJo4ebf67HQgJpsaJXyePctR9782gz1pYhrWhcYYf0h7Vi.FyZtcCG76EHh2EvC0z3Nna6XQSD4PiAaLgdCGD6UGxjFjLqLeQYxZ6UQhI9MDAVVBlueb4nkuatRyrLClirG9KbrZtFdwpMpo3rlMs9gb02JevHDFjNsbZOlYrdAtknQ_01h873.eYYXh8oWw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8BD0D1.9020503@netconfcentral.com> Date: Wed, 19 Aug 2009 03:15:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> In-Reply-To: <20090819080201.GD6741@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 10:15:41 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 19, 2009 at 02:40:53AM +0200, Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Every single developer of every single YANG module ever written >>>> is going to ask the same question "Do I have to provide that leaf, >>>> and therefore write some code to do that, or not?" >>> If mandatory is true, the configuration is not valid if the leaf >>> does not have a value. Baring miracles, the application should >>> understand that providing that value is part of its job. >>> >> But you say that the ifMtu object should not be mantatory, right? >> >> leaf if-mtu { >> type uint32; >> mandatory true; >> } >> >> leaf ping-target { >> type inet:ip-address; >> mandatory true; >> } >> >> Every implementation must have these 2 objects in a valid >> configuration. In one case, the device is going to pick >> a suitable default every time, and the data modeler wants >> that to happen. In the other case, the data modeler does >> not ever want a default value picked by the device. > > I think the MTU value that pops up when I initialize an interface with > no explicit configuration is operational state and not config state. > So the above definition of if-mtu is likely a data modeling error. > You would be right about this except for one tiny detail. If an MTU is configured, then the interface will use the supplied value and not pick its own value. That makes it configuration data, not operational state. > And perhaps most parameters a system uses if you switch it on are just > operational state and not really config data. A home router might boot > up with a default non-global IP address and this can again be > considered operational state since there is no config data yet. I > guess I start to like the model where stuff that has not be > explicitely configured really is not configuration and thus not part > of a configuration datastore. > My home DSL modem has an override in the WEB pages for MTU. You can configure it use 1500 and NOT to pick its own value. Just because this is rarely done does not change the leaf to config=false. > /js > Andy From mbj@tail-f.com Wed Aug 19 03:36: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 C0A163A6CD9 for ; Wed, 19 Aug 2009 03:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, 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 qRtw7ZQEzfDm for ; Wed, 19 Aug 2009 03:36:54 -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 0A63C3A6A1F for ; Wed, 19 Aug 2009 03:36:54 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C1FDB76C59C; Wed, 19 Aug 2009 12:36:57 +0200 (CEST) Date: Wed, 19 Aug 2009 12:36:57 +0200 (CEST) Message-Id: <20090819.123657.33686085.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8BCD11.3090703@netconfcentral.com> References: <4A8B36E0.9070002@netconfcentral.com> <20090819.093900.34596919.mbj@tail-f.com> <4A8BCD11.3090703@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] agent-default -- new 3rd state 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, 19 Aug 2009 10:36:54 -0000 Andy Bierman wrote: > What happens on every device if a mandatory leaf is not provided? > Will this be silently accepted, or rejected with an error? > The official answer is "who cares", but I was looking for "yes" or "no". No, that's not what I said, and that's not what Phil said. At validation time (i.e. of candidate, or of running), you will get an error if a mandatory leaf is not provided. /martin From j.schoenwaelder@jacobs-university.de Wed Aug 19 03:39: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 C84CA3A6902 for ; Wed, 19 Aug 2009 03:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 dvfFZkyVf9df for ; Wed, 19 Aug 2009 03:39: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 A3F2E3A6D70 for ; Wed, 19 Aug 2009 03:39:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4362C009F; Wed, 19 Aug 2009 12:39:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NH2O+pLa6tdP; Wed, 19 Aug 2009 12:39:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EBABC009E; Wed, 19 Aug 2009 12:39:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B644C72DC1; Wed, 19 Aug 2009 12:39:32 +0200 (CEST) Date: Wed, 19 Aug 2009 12:39:32 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090819103932.GB7797@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8BD0D1.9020503@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 10:39:30 -0000 On Wed, Aug 19, 2009 at 12:15:45PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Wed, Aug 19, 2009 at 02:40:53AM +0200, Andy Bierman wrote: > >> Phil Shafer wrote: > >>> Andy Bierman writes: > >>>> Every single developer of every single YANG module ever written > >>>> is going to ask the same question "Do I have to provide that leaf, > >>>> and therefore write some code to do that, or not?" > >>> If mandatory is true, the configuration is not valid if the leaf > >>> does not have a value. Baring miracles, the application should > >>> understand that providing that value is part of its job. > >>> > >> But you say that the ifMtu object should not be mantatory, right? > >> > >> leaf if-mtu { > >> type uint32; > >> mandatory true; > >> } > >> > >> leaf ping-target { > >> type inet:ip-address; > >> mandatory true; > >> } > >> > >> Every implementation must have these 2 objects in a valid > >> configuration. In one case, the device is going to pick > >> a suitable default every time, and the data modeler wants > >> that to happen. In the other case, the data modeler does > >> not ever want a default value picked by the device. > > > > I think the MTU value that pops up when I initialize an interface with > > no explicit configuration is operational state and not config state. > > So the above definition of if-mtu is likely a data modeling error. > > > > You would be right about this except for one > tiny detail. If an MTU is configured, then > the interface will use the supplied value > and not pick its own value. > > That makes it configuration data, not operational state. Yes, but my point was that as long as the MTU is not configured explicitly, it is not config data and there is no need to have boxes generate config data upon startup since this blurs the line between operational state and config data. > > And perhaps most parameters a system uses if you switch it on are just > > operational state and not really config data. A home router might boot > > up with a default non-global IP address and this can again be > > considered operational state since there is no config data yet. I > > guess I start to like the model where stuff that has not be > > explicitely configured really is not configuration and thus not part > > of a configuration datastore. > > > > My home DSL modem has an override in the WEB pages for MTU. > You can configure it use 1500 and NOT to pick its own value. > Just because this is rarely done does not change > the leaf to config=false. I fail to see the point. I am not saying there should not be a config leaf. My point was that (a) making it mandatory is questionable and (b) a box that boots up and has no further information might have an MTU but it is not config. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Aug 19 03:40: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 A33D83A6A1F for ; Wed, 19 Aug 2009 03:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=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 TDLpKxvbgjm0 for ; Wed, 19 Aug 2009 03:40:35 -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 DBF643A6902 for ; Wed, 19 Aug 2009 03:40:34 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DB69D76C5F7; Wed, 19 Aug 2009 12:40:39 +0200 (CEST) Date: Wed, 19 Aug 2009 12:40:39 +0200 (CEST) Message-Id: <20090819.124039.168937723.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8BCE60.6020803@netconfcentral.com> References: <20090819.102457.207114260.mbj@tail-f.com> <4A8BCE60.6020803@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] leaf-list problem 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, 19 Aug 2009 10:40:35 -0000 Andy Bierman wrote: > This is a new feature request. > I do not want to change the meaning of nc:replace now. > The nc:operation attribute applies only to > the subtree it appears in -- not its siblings. Absolutely! This subtree: high.example.com replaces the domain-search leaf-list. And this subtree: low.example.com merges a new entry with the existing list. > Delete the whole leaf-list, then add it back. > Problem solved. That would be perfectly fine, but how do you delete a leaf-list? The draft says: o If the operation is "delete" the entry is deleted from the leaf-list if it exists. So this won't work: b/c it will delete the leaf-list entry "". /martin From lhotka@cesnet.cz Wed Aug 19 04:28: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 C9F2328C3BF for ; Wed, 19 Aug 2009 04:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=0.048, 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 bWMPZCVqqlKL for ; Wed, 19 Aug 2009 04:28:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 06A6728C3B7 for ; Wed, 19 Aug 2009 04:28:24 -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 B557FD800C0; Wed, 19 Aug 2009 13:28:28 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090819103932.GB7797@elstar.local> References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> <20090819103932.GB7797@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 13:28:26 +0200 Message-Id: <1250681306.24768.161.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 11:28:24 -0000 Juergen Schoenwaelder píše v St 19. 08. 2009 v 12:39 +0200: > Yes, but my point was that as long as the MTU is not configured > explicitly, it is not config data and there is no need to have boxes The simple fact is that the MTU parameter is absolutely essential for the operation of an Ethernet interface, so any implementation must make sure it is set to a valid value - which can be achieved in multiple ways - and IMO this information should somehow be contained in its data model. In the data model for an L3 interface, do you want to have the IP address parameter optional? So what if I add a new network card that NV memory has no data for? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Aug 19 04: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 02BA928C3BF for ; Wed, 19 Aug 2009 04:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 sHyeEOou0VXl for ; Wed, 19 Aug 2009 04:38:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CD12528C3BA for ; Wed, 19 Aug 2009 04:38:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE733C009F; Wed, 19 Aug 2009 13:38:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WFe41fyz274m; Wed, 19 Aug 2009 13:38:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8609C009E; Wed, 19 Aug 2009 13:38:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9A1FCC730EC; Wed, 19 Aug 2009 13:38:46 +0200 (CEST) Date: Wed, 19 Aug 2009 13:38:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090819113846.GD7647@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> <20090819103932.GB7797@elstar.local> <1250681306.24768.161.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250681306.24768.161.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 11:38:45 -0000 On Wed, Aug 19, 2009 at 01:28:26PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v St 19. 08. 2009 v 12:39 +0200: > > > Yes, but my point was that as long as the MTU is not configured > > explicitly, it is not config data and there is no need to have boxes > > The simple fact is that the MTU parameter is absolutely essential for > the operation of an Ethernet interface, so any implementation must make > sure it is set to a valid value - which can be achieved in multiple ways > - and IMO this information should somehow be contained in its data > model. > > In the data model for an L3 interface, do you want to have the IP > address parameter optional? So what if I add a new network card that NV > memory has no data for? The IP interface won't work until it is configured or there is operational state (e.g. obtained via DHCP) that provides a suitable address. For me, it does not matter whether a protocol like DHCP is involved or the kernel or firmware does the job in some other way. The result in all cases is that the system did generate operational state that might make a device do something useful but it is not really configuration data in my admittedly strict interpretation what config data really is. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Aug 19 05:05: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 E179B3A6E65 for ; Wed, 19 Aug 2009 05:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.047, 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 olv9XWsoGJ8Y for ; Wed, 19 Aug 2009 05:05:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CC2273A6E62 for ; Wed, 19 Aug 2009 05:05:06 -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 E7B4CD80095; Wed, 19 Aug 2009 14:05:11 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090819113846.GD7647@elstar.local> References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> <20090819103932.GB7797@elstar.local> <1250681306.24768.161.camel@missotis> <20090819113846.GD7647@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 14:05:10 +0200 Message-Id: <1250683510.24768.184.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 12:05:08 -0000 Juergen Schoenwaelder píše v St 19. 08. 2009 v 13:38 +0200: > On Wed, Aug 19, 2009 at 01:28:26PM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v St 19. 08. 2009 v 12:39 +0200: > > > > > Yes, but my point was that as long as the MTU is not configured > > > explicitly, it is not config data and there is no need to have boxes > > > > The simple fact is that the MTU parameter is absolutely essential for > > the operation of an Ethernet interface, so any implementation must make > > sure it is set to a valid value - which can be achieved in multiple ways > > - and IMO this information should somehow be contained in its data > > model. > > > > In the data model for an L3 interface, do you want to have the IP > > address parameter optional? So what if I add a new network card that NV > > memory has no data for? > > The IP interface won't work until it is configured or there is > operational state (e.g. obtained via DHCP) that provides a suitable > address. For me, it does not matter whether a protocol like DHCP is > involved or the kernel or firmware does the job in some other way. > The result in all cases is that the system did generate operational > state that might make a device do something useful but it is not > really configuration data in my admittedly strict interpretation what > config data really is. I am not against having the state data where the actual address (from DHCP or manually assigned) is recorded, like in the /proc filesystem. But you said that your home router has a static preconfigured address, so let's forget about DHCP for the moment. I understood that since the preconfigured address is state data, the data model for the interface *configuration* will have IP address defined as optional, to allow for a valid configuration where this parameter is not present. However, this data model is wrong for an interface on the extension card because there is no preconfiguration available and the configuration will be declared valid even though an essential parameter may be missing. So you would have to have another model for the other interface with mandatory IP address. It is IMO much better to have one data model for both interfaces and just accept that for the built-in interface the IP address is configured by the device itself. With DHCP it is the same, there will be a choice with one case for DHCP and another for manual address, but the choice must have "mandatory=true". Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Aug 19 05:39: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 1532E3A694D for ; Wed, 19 Aug 2009 05:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 TpJpXJQX4b0q for ; Wed, 19 Aug 2009 05:39: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 CACDD3A6D66 for ; Wed, 19 Aug 2009 05:39:11 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFE89C00B3; Wed, 19 Aug 2009 14:39:16 +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 OylGjEkdnzgO; Wed, 19 Aug 2009 14:39:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9432AC00AF; Wed, 19 Aug 2009 14:39:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 65E61C73459; Wed, 19 Aug 2009 14:39:14 +0200 (CEST) Date: Wed, 19 Aug 2009 14:39:14 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090819123914.GB8406@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> <20090819103932.GB7797@elstar.local> <1250681306.24768.161.camel@missotis> <20090819113846.GD7647@elstar.local> <1250683510.24768.184.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250683510.24768.184.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 12:39:25 -0000 On Wed, Aug 19, 2009 at 02:05:10PM +0200, Ladislav Lhotka wrote: > I am not against having the state data where the actual address (from > DHCP or manually assigned) is recorded, like in the /proc filesystem. > > But you said that your home router has a static preconfigured address, > so let's forget about DHCP for the moment. I understood that since the > preconfigured address is state data, the data model for the interface > *configuration* will have IP address defined as optional, to allow for a > valid configuration where this parameter is not present. However, this > data model is wrong for an interface on the extension card because there > is no preconfiguration available and the configuration will be declared > valid even though an essential parameter may be missing. So you would > have to have another model for the other interface with mandatory IP > address. It is IMO much better to have one data model for both > interfaces and just accept that for the built-in interface the IP > address is configured by the device itself. Sorry, but you are interpreting too much into the concept of "valid". Valid means consistent with the data model. It does not mean correct and usable. I am saying a data model which requires an IP address for a valid configuration is broken since I can run for example DHCP. If you want to formally express notions like "this leaf is mandatory if some other condition is true" we will likely need years to come up with a correct data model. > With DHCP it is the same, there will be a choice with one case for > DHCP and another for manual address, but the choice must have > "mandatory=true". I choose to disagree. I might very well simply choose to not use IP at all since all my box is doing is sniffing packets. If we go over board with constraints in data models, we will kill ourself. Authors of YANG data models applicable to a wide range of boxes better we very careful with their usage of must, when, mandatory, default - these are sharp tools to hurt yourself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Aug 19 06:00: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 5C7D13A6CB6 for ; Wed, 19 Aug 2009 06:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=0.046, 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 MnUlYd42YZI7 for ; Wed, 19 Aug 2009 06:00:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3AE223A6A8C for ; Wed, 19 Aug 2009 06:00: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 552E5D80095; Wed, 19 Aug 2009 15:00:16 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090819123914.GB8406@elstar.local> References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> <20090819103932.GB7797@elstar.local> <1250681306.24768.161.camel@missotis> <20090819113846.GD7647@elstar.local> <1250683510.24768.184.camel@missotis> <20090819123914.GB8406@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 15:00:14 +0200 Message-Id: <1250686814.24768.198.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 13:00:12 -0000 Juergen Schoenwaelder píše v St 19. 08. 2009 v 14:39 +0200: > On Wed, Aug 19, 2009 at 02:05:10PM +0200, Ladislav Lhotka wrote: > > > I am not against having the state data where the actual address (from > > DHCP or manually assigned) is recorded, like in the /proc filesystem. > > > > But you said that your home router has a static preconfigured address, > > so let's forget about DHCP for the moment. I understood that since the > > preconfigured address is state data, the data model for the interface > > *configuration* will have IP address defined as optional, to allow for a > > valid configuration where this parameter is not present. However, this > > data model is wrong for an interface on the extension card because there > > is no preconfiguration available and the configuration will be declared > > valid even though an essential parameter may be missing. So you would > > have to have another model for the other interface with mandatory IP > > address. It is IMO much better to have one data model for both > > interfaces and just accept that for the built-in interface the IP > > address is configured by the device itself. > > Sorry, but you are interpreting too much into the concept of > "valid". Valid means consistent with the data model. It does not mean > correct and usable. > > I am saying a data model which requires an IP address for a valid > configuration is broken since I can run for example DHCP. If you want See below for DHCP. > to formally express notions like "this leaf is mandatory if some other > condition is true" we will likely need years to come up with a correct > data model. > > > With DHCP it is the same, there will be a choice with one case for > > DHCP and another for manual address, but the choice must have > > "mandatory=true". > > I choose to disagree. I might very well simply choose to not use IP at > all since all my box is doing is sniffing packets. If we go over board > with constraints in data models, we will kill ourself. Authors of YANG > data models applicable to a wide range of boxes better we very careful > with their usage of must, when, mandatory, default - these are sharp > tools to hurt yourself. This way we can just get rid of "mandatory" completely. I could argue for any parameter that it is optional because I might choose to use the box as paperweight. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Aug 19 06:04:32 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 B934428C150 for ; Wed, 19 Aug 2009 06:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_05=-1.11, 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 enER7a4FUbGi for ; Wed, 19 Aug 2009 06:04:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8AF2D3A68C6 for ; Wed, 19 Aug 2009 06:04:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B3DEC00AF; Wed, 19 Aug 2009 15:04:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G9bisYEa+edG; Wed, 19 Aug 2009 15:04:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 029DBC00A2; Wed, 19 Aug 2009 15:04:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D7233C735ED; Wed, 19 Aug 2009 15:04:24 +0200 (CEST) Date: Wed, 19 Aug 2009 15:04:24 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090819130424.GA8606@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> <20090819103932.GB7797@elstar.local> <1250681306.24768.161.camel@missotis> <20090819113846.GD7647@elstar.local> <1250683510.24768.184.camel@missotis> <20090819123914.GB8406@elstar.local> <1250686814.24768.198.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250686814.24768.198.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 13:04:32 -0000 On Wed, Aug 19, 2009 at 03:00:14PM +0200, Ladislav Lhotka wrote: > This way we can just get rid of "mandatory" completely. I could argue > for any parameter that it is optional because I might choose to use the > box as paperweight. We are really making progress here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed Aug 19 06:19: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 BDDC43A6D66 for ; Wed, 19 Aug 2009 06:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 au-jfsY4QNDx for ; Wed, 19 Aug 2009 06:19:25 -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 D6AFF3A6F4F for ; Wed, 19 Aug 2009 06:19:10 -0700 (PDT) X-Trace: 132409797/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.137/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.137 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: AnAGAGyYi0o+vGmJ/2dsb2JhbABEgmxijRLGCAmEEQU X-IronPort-AV: E=Sophos;i="4.43,408,1246834800"; d="scan'208";a="132409797" X-IP-Direction: IN Received: from 1cust137.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.137]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Aug 2009 14:19:13 +0100 Message-ID: <010101ca20c7$1e9459e0$0601a8c0@allison> From: "tom.petch" To: "Joel M. Halpern" , "Martin Bjorklund" References: <1250594163.3645.59.camel@missotis> <20090818115154.GE5344@elstar.local> <4A8AABA5.7050901@netconfcentral.com><20090818.154125.262734760.mbj@tail-f.com> <4A8AB302.4070308@joelhalpern.com> Date: Wed, 19 Aug 2009 11:23:09 +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] agent-default -- new 3rd state 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, 19 Aug 2009 13:19:26 -0000 ----- Original Message ----- From: "Joel M. Halpern" To: "Martin Bjorklund" Cc: Sent: Tuesday, August 18, 2009 3:56 PM > I have been watching this debate, which appears to consist of people > talking past each other. > > Maybe my addition will just add confusion, although I beleive I agree > with Andy and Juergen. (As a caveat, I use "means" below to indicate > what I think the YANG text explicitly requires.) > > 1) Mandatory means that if a manager is writing that part of the tree, > the manager MUST provide a value for that item. > > 2) Default means that if no manager has not set the item, the item will > have the explicit value given in the default clause in the data model. > > So the question is what to do with a value that must have an item, but > which the system will generate a value if one is not provided, and which > the data model writer can not define that value in advance? Joel Nice summary, except that I want a different third state, that is one where the item must have a value and the data model writer can define one in advance. For me, that is the overwhelming case, when I look at a device configuration, see all the things I might have specified but never have, but equally can see that the system needs them (timers, minimum and maximum values, thresholds, ...) As the I-D stands, I cannot have mandatory and default, so I agree with Lada, "'mandatory' and 'default' wouldn't be mutually exclusive". (But I can also see, as Lada points out, that this also depends on a definition of datastore and that without that, we are unlikely to agree). Perhaps we are trying to be too clever and should allow for some intelligence to reside in data-modellers, expect them not to provide a default if there is no meaningful default. And yes, this general issue has recurred on this list, many, many times. At one time, we had three parameters and a possible eight states. Tom Petch > To remove a corner case, if the manager is not allowed to set the item, > then it is not config data, and this whole debate is irrelevant. We are > talking only about config data. > > As far as I can tell, when the mandatory and default clauses were > defined, we did not think about this case. (Or, if some folks thought > about it, it was not discussed and articulated.) As a result, it is > simply not covered. > > There are, as far as I can tell, a couple of ways out, of varying > attractiveness. > > 1) We can follow Andy's suggestion and create a keyword to represent > this case. > > 2) We can add words to say that this case will NOT use Mandatory, will > not use Default, and that instead the description clause will tell the > human being what value is likely to be found here. As far as I can > tell, nothing in the YANG document prevents the system from setting > values that have not been set by managers and which are not Mandatory. > Since the system will provide a value, this would work. It means that > from an automaton perspective, the model does not distinguish between > things the system sets and things that are truly optional. > > 3) We could do nothing and say nothing in the document. This would seem > to be a mistake, because different model writers and different manager / > agent implementors will do different things. Interoperability is likely > to fail. (Given that we have differing interpretations already > demonstrated on the list, I think "likely" is an understatement.) > > Personally, I would go with 1. But I can live with 2. > > Yours, > Joel > From lhotka@cesnet.cz Wed Aug 19 06:24: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 B6B093A6D66 for ; Wed, 19 Aug 2009 06:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.044, 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 XwmEdVuCS6gP for ; Wed, 19 Aug 2009 06:24:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3531E3A6E91 for ; Wed, 19 Aug 2009 06:24:25 -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 843B8D800CE; Wed, 19 Aug 2009 15:24:21 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090819130424.GA8606@elstar.local> References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8BD0D1.9020503@netconfcentral.com> <20090819103932.GB7797@elstar.local> <1250681306.24768.161.camel@missotis> <20090819113846.GD7647@elstar.local> <1250683510.24768.184.camel@missotis> <20090819123914.GB8406@elstar.local> <1250686814.24768.198.camel@missotis> <20090819130424.GA8606@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 15:24:20 +0200 Message-Id: <1250688260.24768.208.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 13:24:27 -0000 Juergen Schoenwaelder píše v St 19. 08. 2009 v 15:04 +0200: > On Wed, Aug 19, 2009 at 03:00:14PM +0200, Ladislav Lhotka wrote: > > > This way we can just get rid of "mandatory" completely. I could argue > > for any parameter that it is optional because I might choose to use the > > box as paperweight. > > We are really making progress here. OK, my point just is that if there is any parameter at all that is absolutely essential for a device or protocol, it should be declared as mandatory in the generic data model. The fact that some implementations choose to set it from NVRAM or even have it hardwired doesn't make it optional and/or state data. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Wed Aug 19 06:42: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 D92343A6F62 for ; Wed, 19 Aug 2009 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 7xA0NR0lW2sY for ; Wed, 19 Aug 2009 06:42:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E0C5C3A6DF7 for ; Wed, 19 Aug 2009 06:42:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 809714301EC; Wed, 19 Aug 2009 06:42:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 764C84301BA; Wed, 19 Aug 2009 06:42:47 -0700 (PDT) Message-ID: <4A8C0153.8050607@joelhalpern.com> Date: Wed, 19 Aug 2009 09:42:43 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> <4A8AC2DF.2010000@joelhalpern.com> <1250665293.24768.56.camel@missotis> In-Reply-To: <1250665293.24768.56.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 13:42:53 -0000 The problem however remains for later additions. The user, via the management application (manager), adds a new piece of configuration. That piece of configuration has a piece of information in it that must exist for the system to work. Currently, if we label that piece of information "mandatory", then the user / manager must include that piece of information in the provided config. If, instead, we tag that piece as having a default, the current definitions require that the model writer define the default value, and that the node have that value. Thus, if the system is capable of setting the value, but the user is allowed to set it, the model must leave off both the mandatory and the default statements. But this piece of information has significant semantic differences from a fully optional element. If we do not want to define a new statement to represent this kind of configuration information, then we need text to reduce the human astonishment. If the user does not provide a value, and the system does provide a value, does that magically appear when the user does a get of that configuration? Or does it appear only for with-defaults even though the item has no default statement? Yours, Joel Ladislav Lhotka wrote: > Joel M. Halpern píše v Út 18. 08. 2009 v 11:03 -0400: >> I could certainly live with adding "agent-supplied value", or >> "assigned-by-system." >> I understand Martin's argument for not adding a new feature. >> >> But if we are not going to add a feature, then I think we MUST (in the >> ineroperability sense) add some words that explain how this is supposed >> to work. It is quite clear that people understand it differently. >> (Ladislav's understanding of how one could use Mandatory for this is >> just one example. I do not read the text as allowing the behavior he >> understand in good faith to be correct and appropraite.) > > I also have to apologize for contributing to the confusion. After > reading Phil's later message I realized the misunderstanding was mainly > due to the lack of distinction between the assumptions on the initial > configuration on one side and subsequent edits on the other. > > Some explanation of the former is needed in the sense that the server > must provide certain minimum set of mandatory nodes in order to make the > initial configuration valid - these nodes are thus implicitly > "assigned-by system". Otherwise, the rules seem to be OK if we assume > that any other mandatory nodes are up to the client to fill in. > > Lada > >> Yours, >> Joel >> >> >> Martin Bjorklund wrote: >>> Phil Shafer wrote: >>>> I believe it was articulated in the "assigned-by system" proposal: >>>> >>>> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 >>>> >>>> I am personally in favor of this, but the concensus was not. The >>>> issue is still marked open, so perhaps it's time for another concensus >>>> call? >>> I'm also in favor of this, but I'm not sure I want to re-open the >>> concensus call. See the email >>> http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html for >>> some open issues. My main concern is that if we add this it will >>> delay the process. This is a known issue, and the WG decided to not >>> add any more features. This issue was known at the time. There are >>> more nice to haves that could be added, but at some point we have to >>> stop. >>> >>> >>> /martin >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From lhotka@cesnet.cz Wed Aug 19 07:05: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 A7CD03A6DF7 for ; Wed, 19 Aug 2009 07:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=0.043, 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 SP8m1ufed74c for ; Wed, 19 Aug 2009 07:05:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7E4013A67F3 for ; Wed, 19 Aug 2009 07:05:40 -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 A0688D80095; Wed, 19 Aug 2009 16:05:41 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4A8C0153.8050607@joelhalpern.com> References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> <4A8AC2DF.2010000@joelhalpern.com> <1250665293.24768.56.camel@missotis> <4A8C0153.8050607@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 16:05:39 +0200 Message-Id: <1250690739.24768.239.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 14:05:41 -0000 Joel M. Halpern píše v St 19. 08. 2009 v 09:42 -0400: > The problem however remains for later additions. > The user, via the management application (manager), adds a new piece of > configuration. > That piece of configuration has a piece of information in it that must > exist for the system to work. > Currently, if we label that piece of information "mandatory", then the > user / manager must include that piece of information in the provided > config. > If, instead, we tag that piece as having a default, the current > definitions require that the model writer define the default value, and > that the node have that value. > > Thus, if the system is capable of setting the value, but the user is > allowed to set it, the model must leave off both the mandatory and the > default statements. > But this piece of information has significant semantic differences from > a fully optional element. The current "mandatory" clause addresses the static state of a datastore and I would prefer to keep it that way because the DSDL mapping relies on it. The specification whether a particular leaf's value may/must be set by the client, server or both is a new orthogonal feature and should be handled separately, but probably not now, as Martin said. Lada > > If we do not want to define a new statement to represent this kind of > configuration information, then we need text to reduce the human > astonishment. If the user does not provide a value, and the system does > provide a value, does that magically appear when the user does a get of > that configuration? Or does it appear only for with-defaults even > though the item has no default statement? > > Yours, > Joel > > > Ladislav Lhotka wrote: > > Joel M. Halpern píše v Út 18. 08. 2009 v 11:03 -0400: > >> I could certainly live with adding "agent-supplied value", or > >> "assigned-by-system." > >> I understand Martin's argument for not adding a new feature. > >> > >> But if we are not going to add a feature, then I think we MUST (in the > >> ineroperability sense) add some words that explain how this is supposed > >> to work. It is quite clear that people understand it differently. > >> (Ladislav's understanding of how one could use Mandatory for this is > >> just one example. I do not read the text as allowing the behavior he > >> understand in good faith to be correct and appropraite.) > > > > I also have to apologize for contributing to the confusion. After > > reading Phil's later message I realized the misunderstanding was mainly > > due to the lack of distinction between the assumptions on the initial > > configuration on one side and subsequent edits on the other. > > > > Some explanation of the former is needed in the sense that the server > > must provide certain minimum set of mandatory nodes in order to make the > > initial configuration valid - these nodes are thus implicitly > > "assigned-by system". Otherwise, the rules seem to be OK if we assume > > that any other mandatory nodes are up to the client to fill in. > > > > Lada > > > >> Yours, > >> Joel > >> > >> > >> Martin Bjorklund wrote: > >>> Phil Shafer wrote: > >>>> I believe it was articulated in the "assigned-by system" proposal: > >>>> > >>>> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 > >>>> > >>>> I am personally in favor of this, but the concensus was not. The > >>>> issue is still marked open, so perhaps it's time for another concensus > >>>> call? > >>> I'm also in favor of this, but I'm not sure I want to re-open the > >>> concensus call. See the email > >>> http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html for > >>> some open issues. My main concern is that if we add this it will > >>> delay the process. This is a known issue, and the WG decided to not > >>> add any more features. This issue was known at the time. There are > >>> more nice to haves that could be added, but at some point we have to > >>> stop. > >>> > >>> > >>> /martin > >>> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Wed Aug 19 07:29: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 E96263A6851 for ; Wed, 19 Aug 2009 07:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 H9thBHiIGUqG for ; Wed, 19 Aug 2009 07:29:35 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DB3F33A6EAB for ; Wed, 19 Aug 2009 07:29:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 81C3943020E; Wed, 19 Aug 2009 07:29:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7736E430224; Wed, 19 Aug 2009 07:29:37 -0700 (PDT) Message-ID: <4A8C0C4D.8030009@joelhalpern.com> Date: Wed, 19 Aug 2009 10:29:33 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A8AB302.4070308@joelhalpern.com> <200908181424.n7IEOAPR041250@idle.juniper.net> <20090818.165456.143451979.mbj@tail-f.com> <4A8AC2DF.2010000@joelhalpern.com> <1250665293.24768.56.camel@missotis> <4A8C0153.8050607@joelhalpern.com> <1250690739.24768.239.camel@missotis> In-Reply-To: <1250690739.24768.239.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 14:29:41 -0000 In one sense, I follow your reasoning. "Mandatory" means "must exist when validation occurs" (which allows for the differences between running and other configs as to when validation occurs.) Therefore, you can argue that if the system provides the value, then the mandatory value "exists" at the right time, even though the managing application did not provide such a value, even for things created during system operation. However, from the point of view of a managing application trying to use the data-model, that appears to make the "mandatory" flag irrelevant. Under the model in which the managing application had to provide all mandatory elements before verification would pass, a smart human interface application could build up the model as things were defined, and could warn the human being before he hits the verify/commit button that critical things are missing. Another potential use for "mandatory" would be to have a generalized validator that runs on the managed device to check that configs match the data model before they get committed. (In some designs, that could reduce later error checks.) However, as best I can imagine, for that to have any utility it would have to run before any system processes that fill in special values. So it can not complain about missing mandatory elements, since the system may decide "oh, that's okay, I know what to do about that missing value." Again, "mandatory" becomes part of the description, telling humans that if they don't provide it, the system will. Under the interpretation whereby the system might choose to fill it in, the mandatory tag might as well be part of the description clause for all the good I can understand. Yours, Joel Ladislav Lhotka wrote: > Joel M. Halpern píše v St 19. 08. 2009 v 09:42 -0400: >> The problem however remains for later additions. >> The user, via the management application (manager), adds a new piece of >> configuration. >> That piece of configuration has a piece of information in it that must >> exist for the system to work. >> Currently, if we label that piece of information "mandatory", then the >> user / manager must include that piece of information in the provided >> config. >> If, instead, we tag that piece as having a default, the current >> definitions require that the model writer define the default value, and >> that the node have that value. >> >> Thus, if the system is capable of setting the value, but the user is >> allowed to set it, the model must leave off both the mandatory and the >> default statements. >> But this piece of information has significant semantic differences from >> a fully optional element. > > The current "mandatory" clause addresses the static state of a datastore > and I would prefer to keep it that way because the DSDL mapping relies > on it. The specification whether a particular leaf's value may/must be > set by the client, server or both is a new orthogonal feature and should > be handled separately, but probably not now, as Martin said. > > Lada > >> If we do not want to define a new statement to represent this kind of >> configuration information, then we need text to reduce the human >> astonishment. If the user does not provide a value, and the system does >> provide a value, does that magically appear when the user does a get of >> that configuration? Or does it appear only for with-defaults even >> though the item has no default statement? >> >> Yours, >> Joel >> >> >> Ladislav Lhotka wrote: >>> Joel M. Halpern píše v Út 18. 08. 2009 v 11:03 -0400: >>>> I could certainly live with adding "agent-supplied value", or >>>> "assigned-by-system." >>>> I understand Martin's argument for not adding a new feature. >>>> >>>> But if we are not going to add a feature, then I think we MUST (in the >>>> ineroperability sense) add some words that explain how this is supposed >>>> to work. It is quite clear that people understand it differently. >>>> (Ladislav's understanding of how one could use Mandatory for this is >>>> just one example. I do not read the text as allowing the behavior he >>>> understand in good faith to be correct and appropraite.) >>> I also have to apologize for contributing to the confusion. After >>> reading Phil's later message I realized the misunderstanding was mainly >>> due to the lack of distinction between the assumptions on the initial >>> configuration on one side and subsequent edits on the other. >>> >>> Some explanation of the former is needed in the sense that the server >>> must provide certain minimum set of mandatory nodes in order to make the >>> initial configuration valid - these nodes are thus implicitly >>> "assigned-by system". Otherwise, the rules seem to be OK if we assume >>> that any other mandatory nodes are up to the client to fill in. >>> >>> Lada >>> >>>> Yours, >>>> Joel >>>> >>>> >>>> Martin Bjorklund wrote: >>>>> Phil Shafer wrote: >>>>>> I believe it was articulated in the "assigned-by system" proposal: >>>>>> >>>>>> http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01622 >>>>>> >>>>>> I am personally in favor of this, but the concensus was not. The >>>>>> issue is still marked open, so perhaps it's time for another concensus >>>>>> call? >>>>> I'm also in favor of this, but I'm not sure I want to re-open the >>>>> concensus call. See the email >>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg01622.html for >>>>> some open issues. My main concern is that if we add this it will >>>>> delay the process. This is a known issue, and the WG decided to not >>>>> add any more features. This issue was known at the time. There are >>>>> more nice to haves that could be added, but at some point we have to >>>>> stop. >>>>> >>>>> >>>>> /martin >>>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod From jmh@joelhalpern.com Wed Aug 19 07:38: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 2B3A93A6F62 for ; Wed, 19 Aug 2009 07:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 pvCIFSNF9TSd for ; Wed, 19 Aug 2009 07:38:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 722393A6EAB for ; Wed, 19 Aug 2009 07:38:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1961F43020D for ; Wed, 19 Aug 2009 07:38:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 906E94301EC for ; Wed, 19 Aug 2009 07:38:30 -0700 (PDT) Message-ID: <4A8C0E62.9090609@joelhalpern.com> Date: Wed, 19 Aug 2009 10:38:26 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "netmod@ietf.org" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> In-Reply-To: <20090819080201.GD6741@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 14:38:26 -0000 This is an interesting idea. Given that the data model already requires that the modeller figure out what is mandatory and what isn't (and that providing for system-provided values requires the modeler to understand what the system can or can not provide), I think the variation in situations (in Lada's comments on this) merely indicates that one model does not cover all cases. (I presume that careful use of choice would allow one to cover more cases, but probably not all.) Allow me to paraphrase to see if I understand you correctly. For a piece of configurable information which the system will create a value (essentially a more complex default), one can model this with a pair of pieces of information: A state variable, for example in-use-mtu A configuration variable, for example configured-mtu. The configured variable would not be mandatory. If it is not provided, it is not present. If a manager wants to know what value is being used, he can always read the state variable. (There is no leafref, since the values of the two are loosely coupled.) While there is a bit of a loss of semantic content, this is useable. If we decide this is how we think this aspect should be handled, we need to tell people in the model itself. Otherwise, folks will do all sorts of different things, and management applications will have no clue what is going on. Yours, Joel Juergen Schoenwaelder wrote: .. > I think the MTU value that pops up when I initialize an interface with > no explicit configuration is operational state and not config state. > So the above definition of if-mtu is likely a data modeling error. > > And perhaps most parameters a system uses if you switch it on are just > operational state and not really config data. A home router might boot > up with a default non-global IP address and this can again be > considered operational state since there is no config data yet. I > guess I start to like the model where stuff that has not be > explicitely configured really is not configuration and thus not part > of a configuration datastore. > > /js > From andy@netconfcentral.com Wed Aug 19 07:58: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 A9A183A6F8B for ; Wed, 19 Aug 2009 07:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=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 GvAc9u3ppOGG for ; Wed, 19 Aug 2009 07:58:31 -0700 (PDT) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id CA3CD3A6F6D for ; Wed, 19 Aug 2009 07:58:30 -0700 (PDT) Received: from [68.142.200.221] by n21.bullet.mail.mud.yahoo.com with NNFMP; 19 Aug 2009 14:58:34 -0000 Received: from [68.142.201.241] by t9.bullet.mud.yahoo.com with NNFMP; 19 Aug 2009 14:58:34 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 19 Aug 2009 14:58:34 -0000 X-Yahoo-Newman-Id: 307771.76499.bm@omp402.mail.mud.yahoo.com Received: (qmail 65132 invoked from network); 19 Aug 2009 14:58:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2009 14:58:33 -0000 X-YMail-OSG: oTwsr08VM1nhlNrCbUheWwDqwQVW1sg1pKWgPoeuJsdcpYTyBu0loVnZe02Oro50n8CNAxneBO_Rxh192kEjqXEatS_TTh.dnrjR7Ch4GA52Vhz3whsnIDdY5vdWWwtvP0Fl91p3cAlVWhDkI24BxfrGWwI565fQxmhGw15DtVlXMXfzLdBME9L6vd2c1lGhj_KevHFWCXE7tPJqefAMTYWEXTHMsuMNjrJuXnk62H97kKtV2ZEuHQvsGmskxXtE.ChQhgiaH5tZiJbtbsuN1dwf6QjHOOiq6yOlrlhaADjOY00V5HDBhDPq1HRvvyPIEc9cntdq1KgATToYQ.i4MDe9U3LY2XNKgBy2WQzF5YQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8C12A3.2020309@netconfcentral.com> Date: Wed, 19 Aug 2009 07:56:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <20090819.102457.207114260.mbj@tail-f.com> <4A8BCE60.6020803@netconfcentral.com> <20090819.124039.168937723.mbj@tail-f.com> In-Reply-To: <20090819.124039.168937723.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-list problem 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, 19 Aug 2009 14:58:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> This is a new feature request. >> I do not want to change the meaning of nc:replace now. >> The nc:operation attribute applies only to >> the subtree it appears in -- not its siblings. > > Absolutely! > > This subtree: > > high.example.com > > replaces the domain-search leaf-list. no -- it replaces the 1 leaf-list node with the value 'high.example.com'. It does not affect any siblings of the 'high.example.com' instance. each leaf-list value is unique and separate 1 2 3 This is 3 leaf-list nodes, not 1 leaf-list. > > And this subtree: > > low.example.com > > merges a new entry with the existing list. > >> Delete the whole leaf-list, then add it back. >> Problem solved. > > That would be perfectly fine, but how do you delete a leaf-list? The > draft says: > > o If the operation is "delete" the entry is deleted from > the leaf-list if it exists. > 1 result: 2 3 > So this won't work: > > > > b/c it will delete the leaf-list entry "". > correct -- you have to specify the value of the leaf-list getting deleted > > /martin > > Andy From andy@netconfcentral.com Wed Aug 19 09:16: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 5FD2C3A6B3D for ; Wed, 19 Aug 2009 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 qXRkTn4k0CQt for ; Wed, 19 Aug 2009 09:16:09 -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 6DBAC3A677D for ; Wed, 19 Aug 2009 09:16:09 -0700 (PDT) Received: from [209.191.108.96] by n9.bullet.mail.mud.yahoo.com with NNFMP; 19 Aug 2009 16:16:13 -0000 Received: from [68.142.201.254] by t3.bullet.mud.yahoo.com with NNFMP; 19 Aug 2009 16:16:12 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 19 Aug 2009 16:15:49 -0000 X-Yahoo-Newman-Id: 169069.31630.bm@omp415.mail.mud.yahoo.com Received: (qmail 2001 invoked from network); 19 Aug 2009 16:15:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2009 16:15:48 -0000 X-YMail-OSG: LqTfQb8VM1ncT8F3CyVBqSm2T5GNmTVJetsc36qzC155qLcblw01taEhsXdOfMmhRMBAB6gtwZ7dM8LLEaqe_B55GUY9tDUT4l9EXNkU4ARjHBjLi8HARw_yaRdPoQ.j8mC2mNpvojv7ISe4.w5izcTjOnuq6dF9E80EU.oQHdQTSh_c4xeCk7dk1Vua3_YMW_NBtLx4xz9.Pyr3NcIZpO.Fp2O4yTqDfU.zfn0oUn5QZIDWVVXs6N2ZNvxE9DOuzvjwKrDBZP2opMqk_66akqOtntpiTAInVQ75tBMRRyCdH5M- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8C2533.7020909@netconfcentral.com> Date: Wed, 19 Aug 2009 09:15:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200908182210.n7IMAEWk046169@idle.juniper.net> <4A8B4A15.3010100@netconfcentral.com> <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> In-Reply-To: <4A8C0E62.9090609@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 16:16:10 -0000 Joel M. Halpern wrote: > This is an interesting idea. > > Given that the data model already requires that the modeller figure out > what is mandatory and what isn't (and that providing for system-provided > values requires the modeler to understand what the system can or can not > provide), I think the variation in situations (in Lada's comments on > this) merely indicates that one model does not cover all cases. (I > presume that careful use of choice would allow one to cover more cases, > but probably not all.) > > Allow me to paraphrase to see if I understand you correctly. > For a piece of configurable information which the system will create a > value (essentially a more complex default), one can model this with a > pair of pieces of information: > A state variable, for example in-use-mtu > A configuration variable, for example configured-mtu. > We are drifting into data model design issues, but that is good, because the if-mtu object is the poster child for confusion about interactions between the mandatory and default statements. There seems to be 3 ways to model this object (so far): A) if-mtu { type uint32; mandatory true; } B) if-mtu { type uint32; // assigned-by system } C) if-mtu { type uint32; config false; } desired-if-mtu { type uint32; } > The configured variable would not be mandatory. If it is not provided, > it is not present. If a manager wants to know what value is being used, > he can always read the state variable. (There is no leafref, since the > values of the two are loosely coupled.) > > While there is a bit of a loss of semantic content, this is useable. > I am still concerned about the lack of any mechanism in YANG for the data modeler to declare a parameter that MUST NOT have a device-assigned value. This applies to /rpc/input, not just data nodes. It will be left to description statements and extensions. > If we decide this is how we think this aspect should be handled, we need > to tell people in the model itself. Otherwise, folks will do all sorts > of different things, and management applications will have no clue what > is going on. > > Yours, > Joel > Andy > Juergen Schoenwaelder wrote: > .. >> I think the MTU value that pops up when I initialize an interface with >> no explicit configuration is operational state and not config state. >> So the above definition of if-mtu is likely a data modeling error. >> >> And perhaps most parameters a system uses if you switch it on are just >> operational state and not really config data. A home router might boot >> up with a default non-global IP address and this can again be >> considered operational state since there is no config data yet. I >> guess I start to like the model where stuff that has not be >> explicitely configured really is not configuration and thus not part >> of a configuration datastore. >> >> /js >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Wed Aug 19 09:41: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 C0A773A6DB9 for ; Wed, 19 Aug 2009 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.065, 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 WIegFwcO2N3T for ; Wed, 19 Aug 2009 09:41:34 -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 BC85D3A6877 for ; Wed, 19 Aug 2009 09:41:33 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B211E76C595; Wed, 19 Aug 2009 18:41:37 +0200 (CEST) Date: Wed, 19 Aug 2009 18:41:37 +0200 (CEST) Message-Id: <20090819.184137.195313323.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8C2533.7020909@netconfcentral.com> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@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] agent-default -- new 3rd state 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, 19 Aug 2009 16:41:35 -0000 Andy Bierman wrote: > We are drifting into data model design issues, > but that is good, because the if-mtu object > is the poster child for confusion about > interactions between the mandatory and default statements. > > There seems to be 3 ways to model this object (so far): > > A) > if-mtu { > type uint32; > mandatory true; > } > > B) > if-mtu { > type uint32; > // assigned-by system > } > > C) > if-mtu { > type uint32; > config false; > } > desired-if-mtu { > type uint32; > } D) leaf if-mtu { type uint32; // dynamic-default; } You might argue that D isn't very good, b/c it relies on the with-defaults capability for a client to learn what the value is. B isn't perhaps very common, since it will actually create a something in the config data store. > I am still concerned about the lack of any mechanism > in YANG for the data modeler to declare a parameter > that MUST NOT have a device-assigned value. You keep saying that, and I keep saying that this is what 'mandatory' does. I think the original concern was with mandatory top-level nodes which by definition cannot be created by a NETCONF client, but can be created as part of initial pre-loading. /martin From jmh@joelhalpern.com Wed Aug 19 09:54: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 AEB1F3A6B1B for ; Wed, 19 Aug 2009 09:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 aVXoFLvz78Oc for ; Wed, 19 Aug 2009 09: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 8A09B3A69E7 for ; Wed, 19 Aug 2009 09:53:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 34290430288; Wed, 19 Aug 2009 09:54:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 72C8443027A; Wed, 19 Aug 2009 09:54:03 -0700 (PDT) Message-ID: <4A8C2E27.8040609@joelhalpern.com> Date: Wed, 19 Aug 2009 12:53:59 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Martin Bjorklund References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> In-Reply-To: <20090819.184137.195313323.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 16:54:24 -0000 That (D) seems confusing to me. Continuing below. Martin Bjorklund wrote: ... > D) > leaf if-mtu { > type uint32; > // dynamic-default; > } > > You might argue that D isn't very good, b/c it relies on the > with-defaults capability for a client to learn what the value is. If we are going to say that something that is declared without a default clause may a) have a value b) not appear in response to a normal get c) appear in response to a get with-defaults then we better document that VERY clearly. It would seem to me that at that point the managing application would have to do a get with-defaults all the time, because otherwise it would not know what values things have, or whether things have a value. If we were willing to have feature creep, and wanted to have a way to represent this, I suppose we could have a default syntax along the lines of "default-dynamic" as an actual statement with no parameters, which would at least tell the application what is happening. (Personally, I don't care what syntax is used to represent this case assigned-by, dynamic-default, ... I can even live with significant explanatory text. But I would not bet on itneroperability as things stand right now.) Yours, Joel From andy@netconfcentral.com Wed Aug 19 10:08: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 B42703A68E8 for ; Wed, 19 Aug 2009 10:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 ifQ-hBJtQYfL for ; Wed, 19 Aug 2009 10:08:27 -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 D3DB83A69E7 for ; Wed, 19 Aug 2009 10:08:27 -0700 (PDT) Received: (qmail 53945 invoked from network); 19 Aug 2009 17:08:31 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2009 17:08:31 -0000 X-YMail-OSG: rm_tQuIVM1nngVY.IalxcQFMXdABW6Sn4gE3.CXZe4jcWqLCjjLeH0crh1AHKvWjRhO.prPXxklCVAzNewcxNnnjnmsZE.32WElvaXKZppjUghHmYH44pi4SLasTRqHKDd3CzzMfsZfdNnmBXtxXwuGDNcVkg0rGYjgDjykBLofQX.c8Sw0P2saEIq36MzRF0Uz7v8zRpg0AElwQoADex3pJBiktp2RZsgirg5SPlVh43NV6NKHbmyUob2OzYGIAEH7aDyUnRSezkV4t4GOAY_TXgZVRdmuNPYwZrmjY7TvPImz21ymX29V.Fp36NAzvPMPIgwRL1nmyUbkKETh3B1Rz38YSdEdeSRWwNAneBDmaO_by X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8C318E.1040307@netconfcentral.com> Date: Wed, 19 Aug 2009 10:08:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> In-Reply-To: <20090819.184137.195313323.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 17:08:28 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> We are drifting into data model design issues, >> but that is good, because the if-mtu object >> is the poster child for confusion about >> interactions between the mandatory and default statements. >> >> There seems to be 3 ways to model this object (so far): >> >> A) >> if-mtu { >> type uint32; >> mandatory true; >> } >> >> B) >> if-mtu { >> type uint32; >> // assigned-by system >> } >> >> C) >> if-mtu { >> type uint32; >> config false; >> } >> desired-if-mtu { >> type uint32; >> } > > D) > leaf if-mtu { > type uint32; > // dynamic-default; > } > > You might argue that D isn't very good, b/c it relies on the > with-defaults capability for a client to learn what the value is. > no -- it is good. If the device saved the if-mtu leaf in NV-storage, it would definitely be (A). If not, then it is still ambiguous, because of the way defaults work in YANG. I think (B) and (D) are going to be far more prevalent than we would like, which is not good news for automation tool developers. We can see how things work out, and if any proprietary extensions do a good job of addressing the issues. > B isn't perhaps very common, since it will actually create a something > in the config data store. > >> I am still concerned about the lack of any mechanism >> in YANG for the data modeler to declare a parameter >> that MUST NOT have a device-assigned value. > > You keep saying that, and I keep saying that this is what 'mandatory' > does. No. The definition in the draft just refers to a valid configuration. It says nothing about how the value got there. This issue applies to /rpc/input and data nodes. rpc ping { input { leaf host { type inet:ip-address; mandatory true; } } } A device is allowed to provide its own value for mandatory=true leafs. That isn't what I want in this data model design. Just because 192.168.0.1 is a valid address, does not mean that would be a good address to ping, in case is missing. It MUST be a data-missing error in all implementations. Is that what this YANG specifies? Or does it say the opposite -- that an agent MAY provide a value in this case? > > I think the original concern was with mandatory top-level nodes which > by definition cannot be created by a NETCONF client, but can be > created as part of initial pre-loading. > > > /martin > Andy From mbj@tail-f.com Wed Aug 19 10:27: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 4EC2B3A6BCD for ; Wed, 19 Aug 2009 10:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.062, 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 cYKaIatONjq0 for ; Wed, 19 Aug 2009 10:27:52 -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 7D31D3A6A3C for ; Wed, 19 Aug 2009 10:27:52 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DBC476C595; Wed, 19 Aug 2009 19:27:57 +0200 (CEST) Date: Wed, 19 Aug 2009 19:27:56 +0200 (CEST) Message-Id: <20090819.192756.52226506.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8C318E.1040307@netconfcentral.com> References: <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <4A8C318E.1040307@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] agent-default -- new 3rd state 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, 19 Aug 2009 17:27:53 -0000 Andy Bierman wrote: > >> I am still concerned about the lack of any mechanism > >> in YANG for the data modeler to declare a parameter > >> that MUST NOT have a device-assigned value. > > > > You keep saying that, and I keep saying that this is what 'mandatory' > > does. > > No. The definition in the draft just refers to > a valid configuration. It says nothing about > how the value got there. What text would you like to see added? > This issue applies to /rpc/input and data nodes. > > rpc ping { > input { > leaf host { > type inet:ip-address; > mandatory true; > } > } > } > > A device is allowed to provide its own value for mandatory=true leafs. > That isn't what I want in this data model design. Just because > 192.168.0.1 is a valid address, does not mean that would be a good > address to ping, in case is missing. It MUST be a data-missing > error in all implementations. > > Is that what this YANG specifies? That's the intention. > Or does it say the opposite -- that an agent MAY provide a value > in this case? No. > > I think the original concern was with mandatory top-level nodes which > > by definition cannot be created by a NETCONF client, but can be > > created as part of initial pre-loading. But at the same time I want to allow devices to do initial pre-loading of the data store. /martin From andy@netconfcentral.com Wed Aug 19 10:39: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 61E1B3A6C75 for ; Wed, 19 Aug 2009 10:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 l4a7HjcTszKe for ; Wed, 19 Aug 2009 10:39:30 -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 01AF128C0CE for ; Wed, 19 Aug 2009 10:38:54 -0700 (PDT) Received: (qmail 59651 invoked from network); 19 Aug 2009 17:38:58 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2009 17:38:58 -0000 X-YMail-OSG: is_.RC0VM1kGuJdTG8xVzg9V3XZN9dJiPzHeY1XvFOmPgFWD2g9nLxrQ4dbyAZj8z6ZhCbYp._a02yvhr1ZECFR8M65GT9V61rrVEB8r9o1WBkiJTyVDoXiZ1tPRRKWeL98I5ICKLNduTYDjTQs3J9kQ2ggxYl7gPgviu.F2eajIUk1SuyAOnpbxigTwlBMYz1CxS8xolsrgrr.LLZF2Ka5kVghuRlCnRsdwsBY4VrAPIFXklqxP9FxrDD5Ef4dAoSa_zxqdEuq5A2PPhv5nnDiJ7oKXsF.l7SP4OZlHsyZMh4RcmNIVNqN.lKk6iXH5RxpKbNKwbeLF X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8C38B2.6090302@netconfcentral.com> Date: Wed, 19 Aug 2009 10:38:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <4A8C318E.1040307@netconfcentral.com> <20090819.192756.52226506.mbj@tail-f.com> In-Reply-To: <20090819.192756.52226506.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 17:39:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>>> I am still concerned about the lack of any mechanism >>>> in YANG for the data modeler to declare a parameter >>>> that MUST NOT have a device-assigned value. >>> You keep saying that, and I keep saying that this is what 'mandatory' >>> does. >> No. The definition in the draft just refers to >> a valid configuration. It says nothing about >> how the value got there. > > What text would you like to see added? > 7.13.2, para 2: OLD: If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC invocation. NEW: If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC invocation. Otherwise, a device MUST return a 'data-missing' error. Since there is ambiguity about how an existing data node can become present in the database, we should make it clear there is no ambiguity about rpc/input. I'm sorry it took so many emails to get to the 1 sentence that I would like to see added to the draft. >> This issue applies to /rpc/input and data nodes. >> >> rpc ping { >> input { >> leaf host { >> type inet:ip-address; >> mandatory true; >> } >> } >> } >> >> A device is allowed to provide its own value for mandatory=true leafs. >> That isn't what I want in this data model design. Just because >> 192.168.0.1 is a valid address, does not mean that would be a good >> address to ping, in case is missing. It MUST be a data-missing >> error in all implementations. >> >> Is that what this YANG specifies? > > That's the intention. > >> Or does it say the opposite -- that an agent MAY provide a value >> in this case? > > No. > good >>> I think the original concern was with mandatory top-level nodes which >>> by definition cannot be created by a NETCONF client, but can be >>> created as part of initial pre-loading. > > But at the same time I want to allow devices to do initial pre-loading > of the data store. > > > /martin > Andy From cfinss@dial.pipex.com Wed Aug 19 11:02: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 435273A6EAB for ; Wed, 19 Aug 2009 11:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 2g7RqyOz2rp2 for ; Wed, 19 Aug 2009 11:02:22 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 26B563A6B66 for ; Wed, 19 Aug 2009 11:02:22 -0700 (PDT) X-Trace: 277347853/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.123/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.123 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: AnAGAH/ai0o+vGR7/2dsb2JhbABEgmxijRLGTwmEEQU X-IronPort-AV: E=Sophos;i="4.43,409,1246834800"; d="scan'208";a="277347853" X-IP-Direction: IN Received: from 1cust123.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.123]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Aug 2009 19:02:25 +0100 Message-ID: <001001ca20ee$ade5bc20$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <002c01ca1e4b$fdd29fa0$0601a8c0@allison><20090817.110245.26949790.mbj@tail-f.com><005401ca2023$51fd9d40$0601a8c0@allison> <20090819.085243.113447441.mbj@tail-f.com> Date: Wed, 19 Aug 2009 15:47:14 +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] Terminology2 was Re: leafref problems 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, 19 Aug 2009 18:02:23 -0000 ---- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Wednesday, August 19, 2009 8:52 AM > "tom.petch" wrote: > > Logical but, taken together, that's a surprise. So with suitable imports and > > prefixes > > > > module m {grouping g { leaf x ... > > module n {uses g ... > > > > x is not top-level in module m but is top-level in module n. > > Yes. Logical > > I would like this spelt out in the I-D; I suggest amending > > 5.5 to become > > only top-level types and groupings > > ie those appearing as substatements to a module or submodule statement > > can be used outside the module or > > Ok, fixed. > Good > > 6.2.1 bullet 7 I am unclear about; does a > > 'module n { uses g > > make leaf x top level in this case? > > Yes. I changed this a bit into: > > - All leafs, leaf-lists, lists, containers, choices, rpcs, > notifications, and anyxmls defined (directly or through a uses > statement) within a parent node or at the top-level of the module or > its submodules share the same identifier namespace. Good > > Add > > A top-level configuration data node is one where there is no other data node > > between it and a module or submodule statement. Note that the 'grouping' and > > 'uses' statements do not themselves instantiate data nodes but that a 'uses' > > statement that is not within a grouping instantiates the nodes that appear in > > the 'grouping' statement that it references. > > > > If that sounds complicated, well it is:-) > > > > It is needed for the usual suspects, 'when' 'path' 'instance-identifier' > > 'must', > > could appear in all four or perhaps better in 6.2.1 or 6.4. > > How about putting it in the Terminology section? Also, I am not > convinced the "Note" part is necessary. Section 7.11 on grouping > says: > > The grouping statement is not a data definition statement and, as > such, does not define any nodes in the schema tree. > > Note that we also have: > > - data definition statement: A statement that defines new data > nodes. One of container, leaf, leaf-list, list, choice, case, > augment, uses, and anyxml. > > So I hope it is clear that 'uses' defines data nodes but groupings do > not. > > I propose to add this to Terminology: > > - top-level data node: A data node where there is no other data node > between it and a module or submodule statement. Um. We have schema tree and data tree and schema nodes go in the schema tree and data nodes go in ... the schema tree:-( I have tripped over this more than once, so I am wary around data nodes. But it is grouping that is the bigger problem. It is not even a schema node, yet its position w.r.t schema nodes is significant, top-level or no, what parent it has. I think of it as another type of node, but don't have a term for that type. Thus there are data nodes: container, leaf, leaf-list, list, anyxml schema nodes: data nodes plus choice, case, rpc, input, output, notification grouping: a reusable set of nodes which aren't actually anything until a uses statement appears. So while the clarification is there in 7.11 it is missing from terminology, and until I had grasped all the YANG statements, I had not noticed its absence. Hence my tendency to hammer the point that grouping may not be anything like you've seen before (see prefixes in groupings:-). Pro tem., I suggest adding your definition of top-level data node to Terminology but also adding that sentence from 7.11 to grouping in Terminology. And I will mull over it some more, how else grouping might be characterised. Tom Petch > /martin From phil@juniper.net Wed Aug 19 12:14: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 2AFA73A693F for ; Wed, 19 Aug 2009 12:14: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 P4wga1npjMEB for ; Wed, 19 Aug 2009 12:14:46 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 8EE753A67F3 for ; Wed, 19 Aug 2009 12:14:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSoxPKVu8rprwQ4si/X1BnQ25ZR+cVPXC@postini.com; Wed, 19 Aug 2009 12:14:52 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, 19 Aug 2009 12:06:24 -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, 19 Aug 2009 12:06:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:06:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:06: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 n7JJ6Md66430; Wed, 19 Aug 2009 12:06: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 n7JIsVmr057111; Wed, 19 Aug 2009 18:54:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908191854.n7JIsVmr057111@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A8C318E.1040307@netconfcentral.com> Date: Wed, 19 Aug 2009 14:54:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Aug 2009 19:06:23.0046 (UTC) FILETIME=[248DA660:01CA2100] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 19:14:47 -0000 Andy Bierman writes: >We can see how things work out, and if any proprietary >extensions do a good job of addressing the issues. Sounds good. Let's let this issue drop. Thanks, Phil From phil@juniper.net Wed Aug 19 12:18: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 891973A693F for ; Wed, 19 Aug 2009 12:18:48 -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 1C9G13y0qAYR for ; Wed, 19 Aug 2009 12:18:47 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 943283A67DB for ; Wed, 19 Aug 2009 12:18:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSoxQGVj0Niq/sRW9aJio5MAdzM4Uha9o@postini.com; Wed, 19 Aug 2009 12:18: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; Wed, 19 Aug 2009 12:10:53 -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, 19 Aug 2009 12:10:53 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:10:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:10:52 -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 n7JJAqd69272; Wed, 19 Aug 2009 12:10:52 -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 n7JIwxoV057206; Wed, 19 Aug 2009 18:59:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908191859.n7JIwxoV057206@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1250688260.24768.208.camel@missotis> Date: Wed, 19 Aug 2009 14:58:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Aug 2009 19:10:52.0585 (UTC) FILETIME=[C5360990:01CA2100] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 19:18:48 -0000 Ladislav Lhotka writes: >OK, my point just is that if there is any parameter at all that is >absolutely essential for a device or protocol, it should be declared as >mandatory in the generic data model. The fact that some implementations >choose to set it from NVRAM or even have it hardwired doesn't make it >optional and/or state data. This is where the quality and flexibility of the model will come into play. If the model is tightly drawn, the number of deviations will be high. If the model is more flexible, then the need for deviations should be low. Thanks, Phil From andy@netconfcentral.com Wed Aug 19 12:32:01 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 DA6633A6F7E for ; Wed, 19 Aug 2009 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 oml1pFRTuK-a for ; Wed, 19 Aug 2009 12:32:01 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 188023A6A76 for ; Wed, 19 Aug 2009 12:32:01 -0700 (PDT) Received: from [68.142.200.225] by n17.bullet.mail.mud.yahoo.com with NNFMP; 19 Aug 2009 19:32:04 -0000 Received: from [68.142.201.241] by t6.bullet.mud.yahoo.com with NNFMP; 19 Aug 2009 19:32:04 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 19 Aug 2009 19:32:04 -0000 X-Yahoo-Newman-Id: 665432.91387.bm@omp402.mail.mud.yahoo.com Received: (qmail 20877 invoked from network); 19 Aug 2009 19:32:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2009 19:32:03 -0000 X-YMail-OSG: DqAZXDEVM1nhgwh.6x6GdrlQyZPqE5qmhMHU0cvSp0QYmRumIRFxt2YfZ4WYWnRJanT6m_YcZ9A2VBPscwJDCycCYFt7u93eH7Zzz1H3A5tianDmpihG3WiL_t40z1wXYWlNk_x.3XWyAgqVl.Rng4OsB_S63zEXA5oRKuuGbzdnuHpDEsPE98MkSEJxeu4GcMR.QNQS3577LlmAWFBrVxcxWH9Ltsx6c4S3GQOdq.Za2Vnk.jQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8C5333.4080806@netconfcentral.com> Date: Wed, 19 Aug 2009 12:32:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200908191859.n7JIwxoV057206@idle.juniper.net> In-Reply-To: <200908191859.n7JIwxoV057206@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 19:32:01 -0000 Phil Shafer wrote: > Ladislav Lhotka writes: >> OK, my point just is that if there is any parameter at all that is >> absolutely essential for a device or protocol, it should be declared as >> mandatory in the generic data model. The fact that some implementations >> choose to set it from NVRAM or even have it hardwired doesn't make it >> optional and/or state data. > > This is where the quality and flexibility of the model will come > into play. If the model is tightly drawn, the number of deviations > will be high. If the model is more flexible, then the need for > deviations should be low. > This would only prove the standard specification was too vague. Dynamic defaults are a good use of deviations, to fully document the device behavior. > Thanks, > Phil Andy From phil@juniper.net Wed Aug 19 12: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 A3D9C3A6C08 for ; Wed, 19 Aug 2009 12:51:16 -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 dK42Iugwya7g for ; Wed, 19 Aug 2009 12:51:16 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 2883F3A6996 for ; Wed, 19 Aug 2009 12:51:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSoxXtcIQgXuj0MR9bmTvKXzb6dW0E6Oa@postini.com; Wed, 19 Aug 2009 12:51:21 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, 19 Aug 2009 12:42:10 -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, 19 Aug 2009 12:42:10 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:42:09 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:42:09 -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 n7JJg7d84537; Wed, 19 Aug 2009 12:42:07 -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 n7JJUGbo057710; Wed, 19 Aug 2009 19:30:16 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908191930.n7JJUGbo057710@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A8C5333.4080806@netconfcentral.com> Date: Wed, 19 Aug 2009 15:30:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Aug 2009 19:42:09.0321 (UTC) FILETIME=[23D53990:01CA2105] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 19:51:16 -0000 Andy Bierman writes: >This would only prove the standard specification was too vague. >Dynamic defaults are a good use of deviations, to fully document >the device behavior. I guess this depends on the style of modeling. The JUNOS models don't include a default MTU, with the expectation that each interface will choose a reasonable one. IMHO forcing this issue (on which reasonable implementations disagree) means you are drawing the model too tightly. Thanks, Phil From mbj@tail-f.com Wed Aug 19 12:55: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 EC2733A6851 for ; Wed, 19 Aug 2009 12:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, 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 pskrDUJWNOtF for ; Wed, 19 Aug 2009 12:55:11 -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 F30D73A67E1 for ; Wed, 19 Aug 2009 12:55:10 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E069616006; Wed, 19 Aug 2009 21:55:15 +0200 (CEST) Date: Wed, 19 Aug 2009 21:55:15 +0200 (CEST) Message-Id: <20090819.215515.145179613.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8C38B2.6090302@netconfcentral.com> References: <4A8C318E.1040307@netconfcentral.com> <20090819.192756.52226506.mbj@tail-f.com> <4A8C38B2.6090302@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] agent-default -- new 3rd state 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, 19 Aug 2009 19:55:12 -0000 Andy Bierman wrote: > > What text would you like to see added? > > > > 7.13.2, para 2: > > OLD: > If a leaf in the input tree has a "mandatory" statement with the > value "true", the leaf MUST be present in a NETCONF RPC invocation. > > NEW: > If a leaf in the input tree has a "mandatory" statement with the > value "true", the leaf MUST be present in a NETCONF RPC invocation. > Otherwise, a device MUST return a 'data-missing' error. Fixed. (with s/a device/the server/). /martin From jmh@joelhalpern.com Wed Aug 19 12:57: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 DE43E3A67E1 for ; Wed, 19 Aug 2009 12:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 YrE84SDi+hJ8 for ; Wed, 19 Aug 2009 12:57:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3BF783A67DB for ; Wed, 19 Aug 2009 12:57:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CADBF4302A9; Wed, 19 Aug 2009 12:57:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 1020F43025B; Wed, 19 Aug 2009 12:57:34 -0700 (PDT) Message-ID: <4A8C592A.9040506@joelhalpern.com> Date: Wed, 19 Aug 2009 15:57:30 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Phil Shafer References: <200908191930.n7JJUGbo057710@idle.juniper.net> In-Reply-To: <200908191930.n7JJUGbo057710@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 19:57:30 -0000 My concern is that given a model, it appears from the discussion that different device implementors will do different things, thinking that they are doing exactly what the model tells them. Similarly, different management applications will draw different interpretations. That does not sound like a recipe for interoperability. Yours, Joel Phil Shafer wrote: > Andy Bierman writes: >> This would only prove the standard specification was too vague. >> Dynamic defaults are a good use of deviations, to fully document >> the device behavior. > > I guess this depends on the style of modeling. The JUNOS models > don't include a default MTU, with the expectation that each interface > will choose a reasonable one. IMHO forcing this issue (on which > reasonable implementations disagree) means you are drawing the > model too tightly. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Wed Aug 19 13:21:19 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 DBAE528C142 for ; Wed, 19 Aug 2009 13:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=0.042, 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 E6F4iY0EFRXp for ; Wed, 19 Aug 2009 13:21:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 06A1B28C13F for ; Wed, 19 Aug 2009 13:21:19 -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 855A6D80095; Wed, 19 Aug 2009 22:21:23 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090819.184137.195313323.mbj@tail-f.com> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 19 Aug 2009 22:21:21 +0200 Message-Id: <1250713281.24768.242.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 20:21:19 -0000 Martin Bjorklund píše v St 19. 08. 2009 v 18:41 +0200: > Andy Bierman wrote: > > We are drifting into data model design issues, > > but that is good, because the if-mtu object > > is the poster child for confusion about > > interactions between the mandatory and default statements. > > > > There seems to be 3 ways to model this object (so far): > > > > A) > > if-mtu { > > type uint32; > > mandatory true; > > } > > > > B) > > if-mtu { > > type uint32; > > // assigned-by system > > } > > > > C) > > if-mtu { > > type uint32; > > config false; > > } > > desired-if-mtu { > > type uint32; > > } > > D) > leaf if-mtu { > type uint32; > // dynamic-default; > } So let me add one more: E) leaf if-mtu { type uint32; default 1500; } Lada > > You might argue that D isn't very good, b/c it relies on the > with-defaults capability for a client to learn what the value is. > > B isn't perhaps very common, since it will actually create a something > in the config data store. > > > I am still concerned about the lack of any mechanism > > in YANG for the data modeler to declare a parameter > > that MUST NOT have a device-assigned value. > > You keep saying that, and I keep saying that this is what 'mandatory' > does. > > I think the original concern was with mandatory top-level nodes which > by definition cannot be created by a NETCONF client, but can be > created as part of initial pre-loading. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Wed Aug 19 13:29: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 B4EB23A6D32 for ; Wed, 19 Aug 2009 13:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 awdK-zcVFKFb for ; Wed, 19 Aug 2009 13:29:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B8FFF3A6FCC for ; Wed, 19 Aug 2009 13:29:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6E4554302AF; Wed, 19 Aug 2009 13:29:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 6E21D43029A; Wed, 19 Aug 2009 13:29:24 -0700 (PDT) Message-ID: <4A8C609E.1060804@joelhalpern.com> Date: Wed, 19 Aug 2009 16:29:18 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ladislav Lhotka , NETMOD Working Group References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> In-Reply-To: <1250713281.24768.242.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] agent-default -- new 3rd state 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, 19 Aug 2009 20:29:54 -0000 If that were what the data model said, then presumably an application which knew that no one had modified the object (for example, it had jsut created the object), could reasoanbly assume that the mtu would be 1500, and does not need to read it to confirm that. If that is not the case, then the value in the default statement appears to be without meaning. Yours, Joel Ladislav Lhotka wrote: ... > So let me add one more: > > E) > leaf if-mtu { > type uint32; > default 1500; > } > > Lada ... From Washam.Fan@huaweisymantec.com Wed Aug 19 19:37: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 2DC2F3A6DBF for ; Wed, 19 Aug 2009 19:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_20=-0.74, 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 rladgi0-RgmD for ; Wed, 19 Aug 2009 19:37:25 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 58CEA3A6D0E for ; Wed, 19 Aug 2009 19:37:25 -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 <0KON00HL3LXNNX20@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 10:36:59 +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 <0KON00JZRLXNE900@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 10:36:59 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 20 Aug 2009 10:36:59 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 20 Aug 2009 10:36:59 +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: <20090819.184137.195313323.mbj@tail-f.com> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 02:37:26 -0000 Hi, > I think the original concern was with mandatory top-level nodes which > by definition cannot be created by a NETCONF client, but can be > created as part of initial pre-loading. mandatory top-level nodes are alway kept in my mind. Those nodes could not be set via , they should be set before NETCONF is started. So how to interpret 'mandatory' for top-level nodes? washam From Washam.Fan@huaweisymantec.com Wed Aug 19 20:06: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 1DBC03A6930 for ; Wed, 19 Aug 2009 20:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.489 X-Spam-Level: X-Spam-Status: No, score=0.489 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_05=-1.11, 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 D8kkxeVaxVhy for ; Wed, 19 Aug 2009 20:06:03 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 439FA3A6A8B for ; Wed, 19 Aug 2009 20:06:03 -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 <0KON00HZ6N9DNX20@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 11:05:38 +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 <0KON00I36N9D3T10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 11:05:37 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 20 Aug 2009 11:05:37 +0800 From: WashamFan To: "Joel M. Halpern" Message-id: Date: Thu, 20 Aug 2009 11:05:37 +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: <4A8CB82A.60803@joelhalpern.com> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <4A8CB82A.60803@joelhalpern.com> Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 03:06:04 -0000 Hi, > Why do you say that they (mandatory top level nodes) can not be set by > > edit-config. > While it is true that they must exist in all configs, that does not > prevent an edit-config operation from changing the value. You are right, mandatory top level nodes can be MODIFIED by edit-config definitely. Sorry for that and thank you for pointing it out. I meant, (a) some mandatory nodes should be created when the hierarchy (which is not the whole module) is created, and (b) some mandatory nodes (including top-level mandatory) should be created when the module is loaded. In the latter case, the mandatory nodes should be CREATED before can be used. Since the prevalent interpretation of 'mandatory' is the value should be supplied by manager. My concern is how to do that in the case (b) with NETCONF. Thanks, washam > Yours, > Joel > > > WashamFan wrote: > > Hi, > > > >> I think the original concern was with mandatory top-level nodes which > >> by definition cannot be created by a NETCONF client, but can be > >> created as part of initial pre-loading. > > > > mandatory top-level nodes are alway kept in my mind. Those nodes could > > not be set via , they should be set before NETCONF is > started. > > So how to interpret 'mandatory' for top-level nodes? > > > > washam > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > From andy@netconfcentral.com Wed Aug 19 20:31: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 073C028C115 for ; Wed, 19 Aug 2009 20:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 ao-WaTm1AvBR for ; Wed, 19 Aug 2009 20:31:15 -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 5644C28C0F5 for ; Wed, 19 Aug 2009 20:31:15 -0700 (PDT) Received: (qmail 52488 invoked from network); 20 Aug 2009 03:31:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 20 Aug 2009 03:31:19 -0000 X-YMail-OSG: MDv9P1QVM1nA4pBKroZEnU2fn_QFOX1yLqCWXqJLEErGniMv6X38vYyq0FENr_B.LvC0smrKFW7EVWJHPP7EEaDBhpDnOE7J0Rb5Sjdmbuj0dvM5fFR0bdJbOvqDxBJKk17SnbiFc9pciyKn3a5vW3Id2XLO5qpGmzVqeIGlOT2XMMASjHMCnEruS7zxxcKU_DpYOQRtG10zZNOnUbsL_7Yra9aSndRwErmuJcIgOnKQMtI0qVM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8CC389.7090907@netconfcentral.com> Date: Wed, 19 Aug 2009 20:31:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <4A8CB82A.60803@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 03:31:16 -0000 WashamFan wrote: > Hi, > >> Why do you say that they (mandatory top level nodes) can not be set by >> >> edit-config. >> While it is true that they must exist in all configs, that does not >> prevent an edit-config operation from changing the value. > > You are right, mandatory top level nodes can be MODIFIED by edit-config > definitely. Sorry for that and thank you for pointing it out. > > I meant, (a) some mandatory nodes should be created when the hierarchy (which > is not the whole module) is created, and (b) some mandatory nodes (including > top-level mandatory) should be created when the module is loaded. In the > latter case, the mandatory nodes should be CREATED before > can be used. > > Since the prevalent interpretation of 'mandatory' is the value should be > supplied by manager. My concern is how to do that in the case (b) with > NETCONF. > Since the client does not know if the server is going to create a mandatory leaf at module-load-time, the only safe thing to do is never define a top-level mandatory node in a YANG module. That is what yang-usage-01 specifies. > Thanks, > washam Andy From Washam.Fan@huaweisymantec.com Wed Aug 19 20:47: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 C63B328C0D0 for ; Wed, 19 Aug 2009 20:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_05=-1.11, 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 EtaZ1ULAgKI9 for ; Wed, 19 Aug 2009 20:47:41 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id E52CD3A6932 for ; Wed, 19 Aug 2009 20:47:40 -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 <0KON00HJZP67NX30@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 11:46:56 +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 <0KON00I5VP67RC10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 11:46:55 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 20 Aug 2009 11:46:55 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Thu, 20 Aug 2009 11:46:55 +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: <4A8CC389.7090907@netconfcentral.com> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <4A8CB82A.60803@joelhalpern.com> <4A8CC389.7090907@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 03:47:41 -0000 Hi, > >> Why do you say that they (mandatory top level nodes) can not be > set by > >> > >> edit-config. > >> While it is true that they must exist in all configs, that does > not > >> prevent an edit-config operation from changing the value. > > > > You are right, mandatory top level nodes can be MODIFIED by edit-config > > definitely. Sorry for that and thank you for pointing it out. > > > > I meant, (a) some mandatory nodes should be created when the > hierarchy (which > > is not the whole module) is created, and (b) some mandatory nodes (including > > top-level mandatory) should be created when the module is loaded. > In the > > latter case, the mandatory nodes should be CREATED before > > can be used. > > > > Since the prevalent interpretation of 'mandatory' is the value > should be > > supplied by manager. My concern is how to do that in the case (b) with > > NETCONF. > > > > Since the client does not know if the server is going to > create a mandatory leaf at module-load-time, the only > safe thing to do is never define a top-level mandatory node > in a YANG module. Shouldn't mandatory nodes be created only by the client? Why the client care about the behavior of the server? 'mandatory' means the value MUST exist and MUST be supplied by the client, does it? I am still confused. Thanks, washam > That is what yang-usage-01 specifies. From andy@netconfcentral.com Wed Aug 19 21:09: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 BC4B93A6D0C for ; Wed, 19 Aug 2009 21:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 L-usU8JslJkb for ; Wed, 19 Aug 2009 21:09:40 -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 1FC023A6CF9 for ; Wed, 19 Aug 2009 21:09:22 -0700 (PDT) Received: (qmail 55987 invoked from network); 20 Aug 2009 04:09:26 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2009 04:09:26 -0000 X-YMail-OSG: VP6bZyoVM1kmK0__WI3YJPByeXTHyxGpA8wdKc3DZbaFdRd5QH5BZ4ijXfGaOHepFvrATwOSlkusUxWPRh.rYvEPVWCwV.42VGs.VwD0FRT882EGZyraz9nJzdxpx5paoc6GeTU4KyVD7O5c9Mn5TZmpecc8mX1VIBn_OY4rv.OBlhUIECj653_90cso2OqJzK74uuSSa9wkwAHSnHiKQA387nuHHfvmSFY1BH5srh35aQAD7BjhwygqXV8s5baVSk_dKVz1FX4uAnc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8CCBFE.2010705@netconfcentral.com> Date: Wed, 19 Aug 2009 21:07:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <4A8CB82A.60803@joelhalpern.com> <4A8CC389.7090907@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 04:09:41 -0000 WashamFan wrote: > Hi, > >> >> Why do you say that they (mandatory top level nodes) can not be >> set by >> >> >> >> edit-config. >> >> While it is true that they must exist in all configs, that does >> not >> >> prevent an edit-config operation from changing the value. >> > >> > You are right, mandatory top level nodes can be MODIFIED by edit-config >> > definitely. Sorry for that and thank you for pointing it out. >> > >> > I meant, (a) some mandatory nodes should be created when the >> hierarchy (which >> > is not the whole module) is created, and (b) some mandatory nodes (including >> > top-level mandatory) should be created when the module is loaded. >> In the >> > latter case, the mandatory nodes should be CREATED before >> > can be used. >> > >> > Since the prevalent interpretation of 'mandatory' is the value >> should be >> > supplied by manager. My concern is how to do that in the case (b) with >> > NETCONF. >> > >> >> Since the client does not know if the server is going to >> create a mandatory leaf at module-load-time, the only >> safe thing to do is never define a top-level mandatory node >> in a YANG module. > > Shouldn't mandatory nodes be created only by the client? Why > the client care about the behavior of the server? 'mandatory' > means the value MUST exist and MUST be supplied by the client, > does it? I am still confused. > no. that is only for /rpc/input. for data nodes, mandatory=true just means the node MUST exist in the running database. > Thanks, > washam > Andy From Washam.Fan@huaweisymantec.com Wed Aug 19 21:09: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 0E31C3A6CDA for ; Wed, 19 Aug 2009 21:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, 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 YkT+MYH62zxg for ; Wed, 19 Aug 2009 21:09:56 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 40C2E3A6BDE for ; Wed, 19 Aug 2009 21:09:56 -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.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KON00FE1Q8FNV80@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 12:09:51 +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 <0KON00I9AQ8E3R10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 20 Aug 2009 12:09:51 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 20 Aug 2009 12:09:50 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 20 Aug 2009 12:09:50 +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: <20090819.124039.168937723.mbj@tail-f.com> References: <20090819.102457.207114260.mbj@tail-f.com> <4A8BCE60.6020803@netconfcentral.com> <20090819.124039.168937723.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] leaf-list problem 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: Thu, 20 Aug 2009 04:09:57 -0000 Hi, ----- Original Message ----- From: Martin Bjorklund Date: Wednesday, August 19, 2009 6:41 pm Subject: Re: [netmod] leaf-list problem To: andy@netconfcentral.com Cc: netmod@ietf.org > Andy Bierman wrote: > > This is a new feature request. > > I do not want to change the meaning of nc:replace now. > > The nc:operation attribute applies only to > > the subtree it appears in -- not its siblings. > > Absolutely! > > This subtree: > > high.example.com > > replaces the domain-search leaf-list. > > And this subtree: > > low.example.com > > merges a new entry with the existing list. > > > Delete the whole leaf-list, then add it back. > > Problem solved. > > That would be perfectly fine, but how do you delete a leaf-list? The > draft says: > > o If the operation is "delete" the entry is deleted from > the leaf-list if it exists. > > So this won't work: > > > > b/c it will delete the leaf-list entry "". If I understand correctly, the behavior of 'replace' you'd like can be divided into 2 steps: 1) delete all existing leaf-list entries 2) merge the new entry. As I know, you could not achieve step 1) at once especially there exists many entries. So, I prefer add a feature to clean up a leaf-list at once instead of integrating this feature into 'replace' semantics if it is neccessary. washam From andy@netconfcentral.com Wed Aug 19 22:49: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 A9BDE3A6B8D for ; Wed, 19 Aug 2009 22:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=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 DM8hWZcz9nBf for ; Wed, 19 Aug 2009 22:49:56 -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 0B91C3A68D9 for ; Wed, 19 Aug 2009 22:49:40 -0700 (PDT) Received: (qmail 12142 invoked from network); 20 Aug 2009 05:49:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 20 Aug 2009 05:49:42 -0000 X-YMail-OSG: pCerizcVM1nmvUTHUazcEGxDrt9xlQcXKi2VKhTlWD6jFJzLoyge4TTNGWtZRgti1xb5xHiOKGaBclKIo.V2Pg4rDG2pgZhue2lYBclPy_RZNp.Uzn5s2rczTNpxnSiU5rxzOf5npXnyPbyL3.TN1tzWGNpIlNOWoDV.vs_vi9Wu0IuW56pFaCb0PH4W1eg2.j3xS1Wg7ZHSIOI.xmRsF8LC.4PPf.ZDeeJUdB1NycY2uAyoTJU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8CE380.9000909@netconfcentral.com> Date: Wed, 19 Aug 2009 22:47:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <20090819.102457.207114260.mbj@tail-f.com> <4A8BCE60.6020803@netconfcentral.com> <20090819.124039.168937723.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] leaf-list problem 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: Thu, 20 Aug 2009 05:49:57 -0000 WashamFan wrote: > Hi, > > ----- Original Message ----- > From: Martin Bjorklund > Date: Wednesday, August 19, 2009 6:41 pm > Subject: Re: [netmod] leaf-list problem > To: andy@netconfcentral.com > Cc: netmod@ietf.org > > >> Andy Bierman wrote: >> > This is a new feature request. >> > I do not want to change the meaning of nc:replace now. >> > The nc:operation attribute applies only to >> > the subtree it appears in -- not its siblings. >> >> Absolutely! >> >> This subtree: >> >> high.example.com >> >> replaces the domain-search leaf-list. >> >> And this subtree: >> >> low.example.com >> >> merges a new entry with the existing list. >> >> > Delete the whole leaf-list, then add it back. >> > Problem solved. >> >> That would be perfectly fine, but how do you delete a leaf-list? The >> draft says: >> >> o If the operation is "delete" the entry is deleted from >> the leaf-list if it exists. >> >> So this won't work: >> >> >> >> b/c it will delete the leaf-list entry "". > > If I understand correctly, the behavior of 'replace' you'd like can be divided > into 2 steps: 1) delete all existing leaf-list entries 2) merge the new entry. > > As I know, you could not achieve step 1) at once especially there exists > many entries. So, I prefer add a feature to clean up a leaf-list at once > instead of integrating this feature into 'replace' semantics if it is neccessary. > I agree. I do not want to change the way nc:operation works by overloading one of the existing values. That is very confusing, and kind of a hack. Right now, the application has to retrieve the current leaf-list from each device and provide delete operations for them. Just like list entries. I prefer this consistent behavior, and also keeping the nc:operation attribute to process only the current sub-tree. high.example.com low.example.com ftp.example.com www.example.com The current proposal is broken just by including 2 replace operations for the same leaf-list: high.example.com low.example.com This is perfectly valid according to RFC 4741 because each replace applies only to the domain-search leaf-list instance. Not all instances of the leaf-list. This is an issue for RFC4741-bis -- whether or not to change the meaning of the nc:operation attribute. > washam > Andy From mbj@tail-f.com Thu Aug 20 00:24: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 7F8F43A6A4B for ; Thu, 20 Aug 2009 00:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.104, 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 kdFvJd03p+7i for ; Thu, 20 Aug 2009 00:24:28 -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 D645B3A6DBF for ; Thu, 20 Aug 2009 00:24:17 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DCE0476C4E3; Thu, 20 Aug 2009 09:24:21 +0200 (CEST) Date: Thu, 20 Aug 2009 09:24:21 +0200 (CEST) Message-Id: <20090820.092421.205342337.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <20090819.215515.145179613.mbj@tail-f.com> References: <20090819.192756.52226506.mbj@tail-f.com> <4A8C38B2.6090302@netconfcentral.com> <20090819.215515.145179613.mbj@tail-f.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] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 07:24:29 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > > > What text would you like to see added? > > > > > > > 7.13.2, para 2: > > > > OLD: > > If a leaf in the input tree has a "mandatory" statement with the > > value "true", the leaf MUST be present in a NETCONF RPC invocation. > > > > NEW: > > If a leaf in the input tree has a "mandatory" statement with the > > value "true", the leaf MUST be present in a NETCONF RPC invocation. > > Otherwise, a device MUST return a 'data-missing' error. > > Fixed. (with s/a device/the server/). I was too quick. The error message should be 'missing-element'. /martin From lhotka@cesnet.cz Thu Aug 20 02:36:17 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 B23733A6FF9 for ; Thu, 20 Aug 2009 02:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=0.040, 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 pz3UYqmoyLsp for ; Thu, 20 Aug 2009 02:36:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E8FC53A6FD6 for ; Thu, 20 Aug 2009 02:36:16 -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 412C5D80095 for ; Thu, 20 Aug 2009 11:36:22 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 20 Aug 2009 11:36:20 +0200 Message-Id: <1250760980.23073.6.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 09:36:17 -0000 WashamFan píše v Čt 20. 08. 2009 v 10:36 +0800: > Hi, > > > I think the original concern was with mandatory top-level nodes which > > by definition cannot be created by a NETCONF client, but can be > > created as part of initial pre-loading. > > mandatory top-level nodes are alway kept in my mind. Those nodes could > not be set via , they should be set before NETCONF is started. > So how to interpret 'mandatory' for top-level nodes? My proposal is to require the device to set all mandatory nodes in the "minimum valid configuration" (which may also include leafs that are not top-level). Lada > > washam > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Thu Aug 20 07:32: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 445FB3A67F7 for ; Thu, 20 Aug 2009 07:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_VALUE=0.525] 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 4ENcmCuvEFXH for ; Thu, 20 Aug 2009 07:32:39 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 81D733A68B7 for ; Thu, 20 Aug 2009 07:32:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5435B437E53; Thu, 20 Aug 2009 07:32:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9CF7E438016; Thu, 20 Aug 2009 07:32:44 -0700 (PDT) Message-ID: <4A8D5E8B.5070401@joelhalpern.com> Date: Thu, 20 Aug 2009 10:32:43 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250760980.23073.6.camel@missotis> In-Reply-To: <1250760980.23073.6.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 14:32:40 -0000 I am not sure I follow what you are suggesting. In the initial config, that the box comes up with, all configuration level mandatory nodes must exist. Whether this is done by the manufacturer preloading such a config, by magic, or by the device creating likely useful vvalues for these does not change them. However, when a netconf application uses netconf to create a piece of configuration (for example, the top level of a module), then that application (and / or the user behind it) is responsible for providing all top level mandatory pieces of information. That can be done in steps, for example in :candidate before a commit. But the user is responsible. I think we are talking about the strange case where the component is defined in a module, but is separate from the basic thing the user is trying to create. As far as I can tell, it is still the users responsbility to create it, because there is no time point in time before the commit when the system can create it / them for him. And at the commit what the user has provided has to be valid. Admittedly, this is pretty awkward. As such, Andy's recommendation in the usage guidelines is probably the right answer. "Don't do that." Yours, Joel Ladislav Lhotka wrote: > WashamFan píše v Čt 20. 08. 2009 v 10:36 +0800: >> Hi, >> >>> I think the original concern was with mandatory top-level nodes which >>> by definition cannot be created by a NETCONF client, but can be >>> created as part of initial pre-loading. >> mandatory top-level nodes are alway kept in my mind. Those nodes could >> not be set via , they should be set before NETCONF is started. >> So how to interpret 'mandatory' for top-level nodes? > > My proposal is to require the device to set all mandatory nodes in the > "minimum valid configuration" (which may also include leafs that are not > top-level). > > Lada > >> washam >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From cfinss@dial.pipex.com Thu Aug 20 10:55: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 CBF293A7025 for ; Thu, 20 Aug 2009 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_20=-0.74, DATE_IN_PAST_06_12=1.069] 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 lmEb+DY9-0sE for ; Thu, 20 Aug 2009 10:55:57 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id B21AC3A6858 for ; Thu, 20 Aug 2009 10:55:56 -0700 (PDT) X-Trace: 277665280/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.60/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.60 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: AhsFANMqjUo+vGk8/2dsb2JhbABFgmxkjQ3HdQmEDwWBTw X-IronPort-AV: E=Sophos;i="4.43,415,1246834800"; d="scan'208";a="277665280" X-IP-Direction: IN Received: from 1cust60.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.60]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Aug 2009 18:56:00 +0100 Message-ID: <001301ca21b6$f24a4ac0$0601a8c0@allison> From: "tom.petch" To: "Joel M. Halpern" , "Ladislav Lhotka" , "NETMOD Working Group" References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com><1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> Date: Thu, 20 Aug 2009 11:43:15 +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] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 17:55:57 -0000 ----- Original Message ----- From: "Joel M. Halpern" To: "Ladislav Lhotka" ; "NETMOD Working Group" Sent: Wednesday, August 19, 2009 10:29 PM > If that were what the data model said, then presumably an application > which knew that no one had modified the object (for example, it had jsut > created the object), could reasoanbly assume that the mtu would be 1500, > and does not need to read it to confirm that. > > If that is not the case, then the value in the default statement appears > to be without meaning. Joel The meaning I give it is that the writer of the data model knows best, perhaps because that is the WG in the SDO that developed the protocol and has evolved it over the years. So this is telling the application that unless the user of the application comes up with a better idea, then this is the value that should be set in the device. The manufacturer of the device may have different ideas, which no longer reflect best practice. (Plenty of examples in IPv6 of that). Alternatively, we could say that the manufacturer MUST ship the box with values as per data model, but I prefer the first approach. Of course, the value in question may be critical to the operation of the box and cannot be omitted but, of course, the leaf cannot be defined as 'mandatory'. Tom Petch > Yours, > Joel > > Ladislav Lhotka wrote: > ... > > So let me add one more: > > > > E) > > leaf if-mtu { > > type uint32; > > default 1500; > > } > > > > Lada > ... > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From jmh@joelhalpern.com Thu Aug 20 11:13: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 1862E28C1B2 for ; Thu, 20 Aug 2009 11:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 ip9naWw0riYA for ; Thu, 20 Aug 2009 11:13: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 3C21328C1AC for ; Thu, 20 Aug 2009 11:13:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E466943801F; Thu, 20 Aug 2009 11:13:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id F364A438019; Thu, 20 Aug 2009 11:13:11 -0700 (PDT) Message-ID: <4A8D9236.6090809@joelhalpern.com> Date: Thu, 20 Aug 2009 14:13:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "tom.petch" References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com><1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> In-Reply-To: <001301ca21b6$f24a4ac0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 18:13:08 -0000 To paraphrase, you are looking at the default statement as a SHOULD strength statement about what the value ought to be in a newly created item. As far as I can tell, that means that if a managing entity cares about that value, it better provide it even if the value it would provide is the same as the default. Becuase it can not count on the machinery actually ending up with that value if it does not set it. That is defensible, but it sure isn't what I thought the definition of the statement said. Yours, Joel tom.petch wrote: > ----- Original Message ----- > From: "Joel M. Halpern" > To: "Ladislav Lhotka" ; "NETMOD Working Group" > > Sent: Wednesday, August 19, 2009 10:29 PM > >> If that were what the data model said, then presumably an application >> which knew that no one had modified the object (for example, it had jsut >> created the object), could reasoanbly assume that the mtu would be 1500, >> and does not need to read it to confirm that. >> >> If that is not the case, then the value in the default statement appears >> to be without meaning. > > Joel > > The meaning I give it is that the writer of the data model knows best, > perhaps because that is the WG in the SDO that developed the > protocol and has evolved it over the years. > > So this is telling the application that unless the user of the application > comes up with a better idea, then this is the value that should be > set in the device. The manufacturer of the device may have different ideas, > which no longer reflect best practice. (Plenty of examples in IPv6 > of that). > > Alternatively, we could say that the manufacturer MUST ship the box > with values as per data model, but I prefer the first approach. > > Of course, the value in question may be critical to the operation of > the box and cannot be omitted but, of course, the leaf cannot be defined > as 'mandatory'. > > Tom Petch > >> Yours, >> Joel >> >> Ladislav Lhotka wrote: >> ... >>> So let me add one more: >>> >>> E) >>> leaf if-mtu { >>> type uint32; >>> default 1500; >>> } >>> >>> Lada >> ... >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > From andy@netconfcentral.com Thu Aug 20 11:29: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 148AB3A691D for ; Thu, 20 Aug 2009 11:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 nJSpC4wU+gTu for ; Thu, 20 Aug 2009 11:29:55 -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 B903E28C1AA for ; Thu, 20 Aug 2009 11:29:26 -0700 (PDT) Received: (qmail 47072 invoked from network); 20 Aug 2009 18:29:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.70.200 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2009 18:29:11 -0000 X-YMail-OSG: xVhb_.IVM1lt3yjbJA016PMPzqPoo3CIkrQswMZpPxBzSr2sd0eX2ZeYh_KW4b7u9T9z97PN1trsJ0qU1s5Ira7SqcsgNeXJnQx1izeFSUMORCJwnbpVRY2gz3Ez7Zh7dkRZ41YVcKEUd3.S.fnTmYpAmHUGiMMf3gcqznd0YSNgx5yt7V_vIHnwVWTw1vw.EHVWjXHK.tMVwNieVhd2YVfZJHt7Sb8Rig8d8WucwQY3fZ30ZXlhLLUGw70NnyAMSUd_.f8zHu6dtF1A_7Tfw8ScCvIaRVoUh.1ilC3sJQmbOqEDDve.EtcJtD1QdkyQCMcO_YIwdvWvrr9DCiI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8D9580.4060204@netconfcentral.com> Date: Thu, 20 Aug 2009 11:27:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com><1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <4A8D9236.6090809@joelhalpern.com> In-Reply-To: <4A8D9236.6090809@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 18:29:56 -0000 Joel M. Halpern wrote: > To paraphrase, you are looking at the default statement as a SHOULD > strength statement about what the value ought to be in a newly created > item. > that got my attention... We must not go back to the worthless SMIv2 DEFVAL design. Let's keep 'default-stmt' mandatory-to-use by the device. I have found many instances of writing YANG module that the static default-stmt could be used. I think a consensus has emerged that more machine-readable standard language statements would be more precise than the current 'mandatory=true' property. However, there is no consensus on the solution, so it should be left out of YANG 1.0. > As far as I can tell, that means that if a managing entity cares about > that value, it better provide it even if the value it would provide is > the same as the default. Becuase it can not count on the machinery > actually ending up with that value if it does not set it. > > That is defensible, but it sure isn't what I thought the definition of > the statement said. > > Yours, > Joel > Andy > tom.petch wrote: >> ----- Original Message ----- >> From: "Joel M. Halpern" >> To: "Ladislav Lhotka" ; "NETMOD Working Group" >> >> Sent: Wednesday, August 19, 2009 10:29 PM >> >>> If that were what the data model said, then presumably an application >>> which knew that no one had modified the object (for example, it had jsut >>> created the object), could reasoanbly assume that the mtu would be 1500, >>> and does not need to read it to confirm that. >>> >>> If that is not the case, then the value in the default statement appears >>> to be without meaning. >> >> Joel >> >> The meaning I give it is that the writer of the data model knows best, >> perhaps because that is the WG in the SDO that developed the >> protocol and has evolved it over the years. >> >> So this is telling the application that unless the user of the >> application >> comes up with a better idea, then this is the value that should be >> set in the device. The manufacturer of the device may have different >> ideas, >> which no longer reflect best practice. (Plenty of examples in IPv6 >> of that). >> >> Alternatively, we could say that the manufacturer MUST ship the box >> with values as per data model, but I prefer the first approach. >> >> Of course, the value in question may be critical to the operation of >> the box and cannot be omitted but, of course, the leaf cannot be defined >> as 'mandatory'. >> >> Tom Petch >> >>> Yours, >>> Joel >>> >>> Ladislav Lhotka wrote: >>> ... >>>> So let me add one more: >>>> >>>> E) >>>> leaf if-mtu { >>>> type uint32; >>>> default 1500; >>>> } >>>> >>>> Lada >>> ... >>> _______________________________________________ >>> 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 Thu Aug 20 11:33: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 293083A6D88 for ; Thu, 20 Aug 2009 11:33:46 -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 U1aluqz5xTnO for ; Thu, 20 Aug 2009 11:33:45 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 0BAB63A672E for ; Thu, 20 Aug 2009 11:33:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSo2W1li2I3OUoSmbu61TGooIolRh7jT6@postini.com; Thu, 20 Aug 2009 11:33:51 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; Thu, 20 Aug 2009 11:27:40 -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); Thu, 20 Aug 2009 11:27:40 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 11:27:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 11:27:39 -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 n7KIRcd95984; Thu, 20 Aug 2009 11:27: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 n7KIFk8I066368; Thu, 20 Aug 2009 18:15:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908201815.n7KIFk8I066368@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4A8D9236.6090809@joelhalpern.com> Date: Thu, 20 Aug 2009 14:15:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2009 18:27:39.0578 (UTC) FILETIME=[E61251A0:01CA21C3] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Thu, 20 Aug 2009 18:33:46 -0000 "Joel M. Halpern" writes: >To paraphrase, you are looking at the default statement as a SHOULD >strength statement about what the value ought to be in a newly created item. The default is a MUST strength statement: If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. >As far as I can tell, that means that if a managing entity cares about >that value, it better provide it even if the value it would provide is >the same as the default. Becuase it can not count on the machinery >actually ending up with that value if it does not set it. Neither is true. The managing entity can know that the device will behave according to the "contract" that the YANG module represents, and can count on the default value being used internally when a value is not present in the configuration. Thanks, Phil From mbj@tail-f.com Thu Aug 20 12:42: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 A4BBA3A6D97 for ; Thu, 20 Aug 2009 12:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.058, 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 b7LHnfii-RIr for ; Thu, 20 Aug 2009 12:42:10 -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 D86043A6A3B for ; Thu, 20 Aug 2009 12:42:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CACC376C4E3; Thu, 20 Aug 2009 21:42:13 +0200 (CEST) Date: Thu, 20 Aug 2009 21:42:13 +0200 (CEST) Message-Id: <20090820.214213.147266575.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <001001ca20ee$ade5bc20$0601a8c0@allison> References: <005401ca2023$51fd9d40$0601a8c0@allison> <20090819.085243.113447441.mbj@tail-f.com> <001001ca20ee$ade5bc20$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] Terminology2 was Re: leafref problems 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: Thu, 20 Aug 2009 19:42:10 -0000 "tom.petch" wrote: > Pro tem., I suggest adding your definition of top-level data node to > Terminology > but also adding that sentence from 7.11 to grouping in Terminology. Just to make sure I get it right... when you say "that sentence", do you mean: The grouping statement is not a data definition statement and, as such, does not define any nodes in the schema tree. /martin From phil@juniper.net Thu Aug 20 12:47: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 7164028C1BF for ; Thu, 20 Aug 2009 12:47:05 -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 VulxEljoPUqZ for ; Thu, 20 Aug 2009 12:47:04 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 8826328C1A6 for ; Thu, 20 Aug 2009 12:47:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSo2oPfz6tvAM6ID4lueYXRh+3kKr1y45@postini.com; Thu, 20 Aug 2009 12:47:10 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; Thu, 20 Aug 2009 12:36:17 -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); Thu, 20 Aug 2009 12:36:17 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 12:36:17 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 12:36:16 -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 n7KJaGd37328 for ; Thu, 20 Aug 2009 12:36:16 -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 n7KJOOWU067179 for ; Thu, 20 Aug 2009 19:24:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908201924.n7KJOOWU067179@idle.juniper.net> To: netmod@ietf.org Date: Thu, 20 Aug 2009 15:24:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2009 19:36:16.0946 (UTC) FILETIME=[7C36D120:01CA21CD] MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] Pattern "ok"? 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: Thu, 20 Aug 2009 19:47:05 -0000 Does the regular expression given in the "pattern" statement match the whole string, or just a portion? That is, is there an implicit "^" and "$"? pattern "(not )?ok"; // Does this match "yokel"? pattern "[a-f]{1,3}"; // Does this match "tobacco"? Given that most expressions will need to match the entire string, can we make the "^" and "$" implicit? Or will we allow this to be a common source of errors? If they are implicit, one can match a portion of the string using ".*", like: pattern ".*ok.*"; Thanks, Phil From per@tail-f.com Thu Aug 20 13:39: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 5A5B53A6F65 for ; Thu, 20 Aug 2009 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 vOsq00mkalLd for ; Thu, 20 Aug 2009 13:39:47 -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 55F9428C13A for ; Thu, 20 Aug 2009 13:39:20 -0700 (PDT) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 84A4E76C4E3; Thu, 20 Aug 2009 22:39:25 +0200 (CEST) Message-ID: <4A8DB47E.1050306@tail-f.com> Date: Thu, 20 Aug 2009 22:39:26 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Phil Shafer References: <200908201924.n7KJOOWU067179@idle.juniper.net> In-Reply-To: <200908201924.n7KJOOWU067179@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Pattern "ok"? 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: Thu, 20 Aug 2009 20:39:48 -0000 On 2009-08-20 21:24, Phil Shafer wrote: > Does the regular expression given in the "pattern" statement match > the whole string, or just a portion? That is, is there an implicit > "^" and "$"? There is, per the definition in [XSD-TYPES] - might also be inferred from the last example in the draft, and maybe from "...values that _completely_ matches the pattern." But I guess it wouldn't hurt to spell it out. --Per Hedeland From david.partain@ericsson.com Fri Aug 21 03:34: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 29F3128C120 for ; Fri, 21 Aug 2009 03:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 w3Un-YfZ6eJS for ; Fri, 21 Aug 2009 03:34:57 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 261CA28C10C for ; Fri, 21 Aug 2009 03:34:56 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-3d-4a8e78543731 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id C8.FE.18827.5587E8A4; Fri, 21 Aug 2009 12:35:01 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 12:35:00 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 12:35:00 +0200 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Fri, 21 Aug 2009 12:34:58 +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: <200908211234.59155.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2009 10:35:00.0728 (UTC) FILETIME=[094AF780:01CA224B] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Please submit open issues separately 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: Fri, 21 Aug 2009 10:34:58 -0000 Hi all, I'm have EXTREME difficulty understanding where people are and even what they think the issues are. As such, I'd like to request the following: If there is an issue that you think remains unresolved, please send mail to the list with (1) a relevant subject stating what the issue is (2) a pointer to the text in the document that you think has the issue, and (3) if possible, a suggested textual fix that we can discuss. We're all over the place at the moment, which concerns me. Cheers, David ps. I hope to submit minutes in the next few hours for your comments. From david.partain@ericsson.com Fri Aug 21 05:57: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 8D81C3A6A10 for ; Fri, 21 Aug 2009 05:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, 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 pfuQViwM8Y4I for ; Fri, 21 Aug 2009 05:57:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D54863A6880 for ; Fri, 21 Aug 2009 05:57:07 -0700 (PDT) X-AuditID: c1b4fb3e-b7b24ae000003bbc-e8-4a8e9901e1e1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F9.F2.15292.1099E8A4; Fri, 21 Aug 2009 14:54:25 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 14:54:23 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 14:54:22 +0200 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Fri, 21 Aug 2009 14:54:22 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_+jpjKH7JEBlncHN" Message-Id: <200908211454.22242.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2009 12:54:22.0922 (UTC) FILETIME=[818C82A0:01CA225E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Draft minutes for IETF75 NETMOD sessions 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: Fri, 21 Aug 2009 12:57:11 -0000 --Boundary-00=_+jpjKH7JEBlncHN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Greetings, Please find my draft minutes for the two recent sessions at the 75th IETF in Stockholm. Thanks very much to the notetakers! I will submit these on Monday, so please have a look as soon as possible. Cheers, David --Boundary-00=_+jpjKH7JEBlncHN Content-Type: text/plain; charset="iso 8859-15"; name="netmod-minutes-ietf75.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="netmod-minutes-ietf75.txt" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IETF 75, NETMOD WG MONDAY, July 27, 2009, 1300-1500 David Kessens, David Partain The chairs wish to thanks the notetakers: Phil Shafer Balazs Lengyel Bert Wijnen Ladislav Lhotka Audio feed archive: ftp://videolab.uoregon.edu/pub/videolab/media/ietf75/ietf75-mon-caberet-pm.mp3 Agenda slides: http://www.ietf.org/proceedings/75/slides/netmod-3.ppt David Partain: No new work to be chartered before all current items are in the hands of the IESG. We still believe we will send all documents to IESG in September =================================================================== Architecture draft: Phil Shafer Slides: http://www.ietf.org/proceedings/75/slides/netmod-2.ppt Phil Shafer: Modified with comments, IMO it is ready. David Partain: We will send it to last call after the IETF. =================================================================== Common Data Types: Juergen Schoenwaelder Slides: http://www.ietf.org/proceedings/75/slides/netmod-6.pdf Juergen Schoenwaelder: If people have read the doc, please support it actively! 1. new proposed type: date David Partain: it seems a good idea Straw poll: 6 for, against 0 2. new proposed type: time types David Partain: Looks more difficult. Phil Shafer: What is the use case? What about weeks, fortnight? Balazs Lengyel: seems too many Ladislav Lhotka: 'units' YANG construct makes this superfluous, against it Andy Bierman: 'units' must be used consistently, standardizing them makes it more uniform Juergen Schoenwaelder: We can't force their usage anyway David Partain: straw poll: yes 0, no 6-7 Andy Bierman: Could put suggested units name in usage draft; that would be good enough 3. flagging SNMP compatibility Juergen Schoenwaelder: OID, timeticks are not SNMP-specific David Partain: What is the motivation? Juergen Schoenwaelder: These types should not be used for anything but SNMP Andy Bierman: not clear how these SMI types are used in NETCONF David Partain: So they should not be used for anything but SNMP related stuff, is that correct Andy? David Partain: straw poll: yes 0 no 6-7 Andy Bierman: the YANG object identifier is an XPath expression Juergen Schoenwaelder: That's his terminology 4. absolute schema node ID type Juergen Schoenwaelder: useful, but namespace prefixes are a problem Martin Bjorklund: prefix mapping can be similar to the one for instance identifier Juergen Schoenwaelder: this points to schema nodes Martin Bjorklund: this could point to choices, cases etc. Martin Bjorklund: What is the use case, where would you use it? Andy Bierman: leave it out I guess -- don't care David Partain: straw poll yes: 0 no: 6-7 5. date-and-time timestamp type, must be in UTC Juergen Schoenwaelder: does not see the difference between this and current date and time, why must we enforce UTC? Brent Chapman: conversion from localtime to UTC is a big problem, so forcing UTC is a good practice. Juergen Schoenwaelder: date-and-time has a suffix/offset in hours and minutes, so translation should be easy. Andy Bierman: I do not remember making this request; YANG canonical format -- agent MUST send UTC only Ladislav Lhotka: true canonical format is UTC David Partain/Juergen Schoenwaelder: So this is not an issue at all. Phil Shafer: I don't want to be forced to use UTC, we lose local time info. Martin Bjorklund: does the agent have to send the canonical format? Balazs Lengyel: yes, canonical must be used. Brent Chapman: we need the local time. e.g. some thing can only be done during the local night 6. date-and-time-delta type: Juergen Schoenwaelder: Proposal needs details, discussion missing Andy Bierman: SMIv2 has it, so we need it Bert Wijnen: Andy, please clarify. David Harrington: IMO we don't have it in SMIv2. Why are we adding new types this late? Andy Bierman: do we need any time intervals or just absolute time in NETCONF? Brent Chapman: I am missing a data type for a duration? e.g 20 millisec. What data type do I use to express those durations? Juergen Schoenwaelder: No such data type. Part of the problem is that the range would need to cover such a wide space in a generic data type. Brent Chapman: is this the result because SNMP being mostly considered a monitoring standard? Since this is configuration, whether it was in SNMP or not is not relevant. Balazs Lengyel: this is the same question as slide 2 Brent Chapman: Certainly related Juergen Schoenwaelder: this asks for a generic duration type that covers 2 msecs and 2 years as well David Partain: is this too big too late? David Harrington: ask yes or no! Too big, handle later. Juergen Schoenwaelder: people should come up with a concrete proposal. Martin Bjorklund: there is a duration type in XSD. David Partain: is this too big, too late? yes 6-7 no 1 7. XSD and RNG translations Juergen Schoenwaelder: should we keep them? David Partain: was it not the original idea to help people understand the types? It might not be needed anymore. Seems you are worried about precedent. We don't want the translations in all future documents. Juergen Schoenwaelder: A free tool for translation is available. Ladislav Lhotka: understanding datatypes is easy; vote against. Brent Chapman: If you have 3 description, you get the question which is authoritative. Juergen Schoenwaelder: YANG is the real one David Partain: can we put a link to a tool in a draft? maybe the tools name? David Partain: remove straw poll: yes 10 no 0 David Partain: Can we put a URL in the draft? Dan Romascanu: If it's normative then don't do it, if informative it might be acceptable. Juergen Schoenwaelder: we might point to guidelines document or some tool page. David Partain: how many read the data-types doc: 5-6 =================================================================== draft-ietf-netmod-yang-07.txt - Martin Bjorklund Slides: http://www.ietf.org/proceedings/75/slides/netmod-6.pdf 1. Nested choices Martin Bjorklund: let's allow them Ladislav Lhotka: there are problems, but don't remember them Martin Bjorklund: makes implementation difficult, but still remove it Phil Shafer: should not make it difficult Martin Bjorklund: naming is still difficult Phil Shafer: so clarify naming rules Andy Bierman: no, it is not. The selected case can itself consist of a leaf and another choice. Vote: allow them yes 6-7 no 0 2. prefixes in groupings (Editor: note the example in the slide is incorrect) Martin Bjorklund: don't use prefixes for internal references in groupings Ladislav Lhotka: David Partain: Is this a good start? 5-6 hands shown Andy Bierman: do not make XPath parsers treat expressions in groupings differently. Martin Bjorklund: different from what? (Confusion about Andy comments.) Andy Bierman: Is it OK to map local-prefix:/X in a grouping to the node X, even though the namespace will change later? Martin Bjorklund: with this proposal no. Prefix will be fixed. Martin Bjorklund: Should we allow references to external entities without a prefix? Juergen Schoenwaelder: allow it Andy Bierman: this rule makes off-the-shelf XPath parsing impossible, right? the parser needs to allow prefixes outside a grouping, but not allow it inside a grouping Ladislav Lhotka: I see a use case for this, similar use case could be for leafref. A name without a namespace only gets its prefix when it is used Andy Bierman: leafref path is not XPath Phil Shafer: you can use a stock parser, but use it at build time. I dislike this proposal. It is easy to make mistakes. Can you refer to non-existent nodes? and can you allow this in groupings? You should not allow this generally. In groupings it could be done, but its fragile. Martin Bjorklund: yes this is fragile, but that's OK, tools can still check it. if not at compile time then later. Andy Bierman: I agree with Juergen. This is just a constant expression, no reason to add CLRs to XPath Ladislav Lhotka: you need to manipulate XPath namespaces for standard XPath tools anyway Martin Bjorklund: yes, you need to prefixes Balazs Lengyel: hard to understand all cases. Phil Shafer: referring to non-existing stuff will be a problem Juergen Schoenwaelder: this is a macro kind of thing, so it will find C node Martin Bjorklund: it will work Phil Shafer: 2 issues 1) Can you refer to a node that does not exist. Must be an error. 2) Can you refer to stuff for things outside the grouping. Is fragile, but can live with it Andy Bierman: XPath does not treat this as an error. It is just a YANG warning, not an error. Ladislav Lhotka: this reference to external node C might be intentional. Phil Shafer: If C is not there in the user module, how will it fail? It should fail early at compile. Phil Shafer: XPATH does not detect it, it is difficult to debug. Martin Bjorklund: So if we detect a references to something non-existing should we detect that? Phil Shafer: Some of these are just run-time errors. That's bad. Issue 1) Can I have a must referring to a non-existent node or namespace Issue 2) Inside can you refer to something outside the grouping? Andy Bierman: no -- missing xmlns for a prefix is an error in XPath Phil Shafer: I want to make this a compiler error. Juergen Schoenwaelder: We should not make too many mandatory checks, we must not mandate it too make perfect tools to be YANG compatible. Ladislav Lhotka: resolve any prefixes when defining the grouping, leave everything alone. Andy Bierman: it is a compile time error because the XPath expression would be invalid. Andy Bierman: there are lots of ways to produce garbage XPath; do not understand proposal. Phil Shafer: the question is if such references are legal. Martin Bjorklund: this is legal XPath, it is just stupid, so allow it and give a warning. Juergen Schoenwaelder: We allow 0<1 as well Ladislav Lhotka: rather give only warnings, not errors. David Partain: I am worried about pointing at garbage. Martin Bjorklund: it is valid XPATH. Phil Shafer: it is still garbage. Juergen Schoenwaelder: there are so many ways to produce garbage, how many do we want to check (and force to be checked)? David Kessens: Maybe put it into a usage guidelines? Phil Shafer: if it is clearly garbage it is still an error. Ladislav Lhotka: augment can correct it. David Partain: let's take the simple example without groupings David Partain: it seems we agree on allowing pointers in groupings to point outside. Should we generally allow pointing at garbage? IMO NO. David Partain: Should we have flexible/fragile groupings: yes 4 no 1 David Partain: pointing at undefined elements valid YANG: yes 4 no 4 David Partain: take second one to list or resolve it for Wednesday meeting =================================================================== draft-ietf-netmod-dsdl-map-03.txt - Ladislav Lhotka Slides: http://www.ietf.org/proceedings/75/slides/netmod-5.pdf See slides, which Ladislav followed closely in his presentation. No questions or comments. David Partain: how many read it: 3. Too few... problem. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IETF 75, NETMOD WG WEDNESDAY, July 29, 2009, 1300-1500 David Kessens, David Partain Audio archive: ftp://videolab.uoregon.edu/pub/videolab/media/ietf75/ietf75-wed-rm307-pm.mp3 Slides: http://www.ietf.org/proceedings/75/slides/netmod-8.ppt =================================================================== Issue Resolution Day 2 (David Partain) Issue #1 XPath warnings What to do with valid XPath which is clearly an error? Is it compile time error? In last meeting, there was no rough concensus. Proposal: It is valid YANG; do not mandate that compilers have to find this. Phil Shafer: We have compilers that can do something, we don't claim they will do everything. Andy Bierman and David Reid (both on Jabber) agree with the proposal. 8:2 consensus in favor of the proposal. Issue #2 - date-and-time canonicalization Phil Shafer: Do we have any other datatype that discard information (i.e. are evil)? Juergen Schoenwaelder: It depends on whether you want just date and time information or timezone location as well. Phil Shafer: We should have two separate datatypes, one for local time and another for UTC time. Juergen Schoenwaelder: What's your definition of local time? Phil Shafer: For instance, I want to run backups between 2 and 3 AM local time. Juergen Schoenwaelder: So your local time means time without timezone information. Mark Ellison: If operators know the timezone of each device, it's OK. Juergen Schoenwaelder: Device's timezone is not the same as a time recorded in configuration. Rough consensus for using UTC as the canonical value. Issue #3 - types document: include 'date' type Are there any use-cases? Proposal: do not include 'date' 7-0: so goes to list as consensus Issue #4 - include prefix in IANA registry Bert Wijnen: TBD for IANA has to be included in a draft with instructions how IANA is supposed to use the registry. Martin Bjorklund: Do we have to change anything in the draft? Juergen Schoenwaelder will help to compose text for IANA considerations section Bert Wijnen: So the draft will start the registry. Martin Bjorklund: Yes. Balazs Lengyel: There are actually two things: one is starting the registry and another proposal is that the prefixes will be required unique in all modules published by IETF. Andy Bierman: This will not help. People will think all prefixes are unique, but vendor prefixes will never be unique. Ladislav Lhotka: The developers will take the prefixes for granted and will not care about URIs. This happened in XML and led to interoperability problems. Juergen Schoenwaelder: We can also publish conflicting prefixes. We must make it clear what tools have to do. Andy Bierman: Which mandatory prefixes do I have to use? Do I also have to import modules with the registered prefixes? Does not agree with proposal. Balazs Lengyel: You SHOULD, not MUST. Bert Wijnen: We have two questions here: (i) Do we want to have prefixes in an IANA registry? (ii) What are the rules for their use? Ladislav Lhotka: Short prefixes will get exhausted and this will force developers to choose longer ones, which impacts readability. No need to register prefix. Andy Bierman: We will effectively crunch readable module names into unreadable prefixes. So why don't we use module names as prefixes? Phil Shafer: If YANG is so successful that we run out of short prefixes, we can change the policy. Balazs Lengyel: we do not want to use long prefixes. Andy Bierman: Ladislav is right. This looks good for 5 modules, but how about 300? Rough consensus 7:3 in favor of including the prefixes in IANA. Balazs Lengyel: as I proposed: you SHOULD use unique prefixes.... we cannot guarantee it. Mark Ellison: I don't care but don't think this is needed. Juergen Schoenwaelder: Registering is enough, we don't need to require uniqueness. Probably IETF prefixes will be unique for a while. David Partain: agrees with Juergen (as contributor) Andy Bierman: what if vendors have a prefix that IANA adds later to the registry? Rough consensus 6:1 for not requiring uniqueness. =================================================================== YANG Usage Guidelines (Martin Bjorklund for Andy Bierman) Slides: http://www.ietf.org/proceedings/75/slides/netmod-4.pdf Slide 1 - BCP versus informational David Partain: It's fine to start this I-D as informational. - Identityref versus enumeration Martin Bjorklund: Identityref should be used if the set of values is designed to be extensible. David Partain: suggest we wait till we see text or leave it out if using enums is considered better. Andy Bierman: OK, I can leave this out if enums are considered better. Juergen Schoenwaelder: The document refers to MIB security templates, this doesn't make sense. Slide 2 - interim URIs - temp namespace for module namespace URI while work-in-progress (and not leave it blank as in SMIv2) so that it is a valid name Phil Shafer: It might be better to use URNs and scope them properly. Juergen Schoenwaelder: We should take the URI that the module will eventually have, and modify it so that the modification can be removed when the module is published. Andy Bierman: I-D name is OK. David Partain: we look forward for some proposals on the list - number of top level elements do we want a recommendation? if so should it be 1? Balazs Lengyel: Modules with a single root are easier to understand, the guidelines should recommend that only one root be used. Juergen Schoenwaelder: I don't know why modules with a single root are easier to understand. This is just another unnecessary rule. Andy Bierman: agrees to not add a rule - mandatory nodes at the top level not really deployable... (see slide) should this condition be a SHOULD NOT or MUST NOT or just a warning? or should this be an error in the YANG I-D? Balazs Lengyel: They are not a problem, devices always create some skeleton configuration. There seems there is some confusion between Martin Bjorklund, Phil, Balazs and Andy on what mandatory means. Andy Bierman: Mandatory means that manager must provide a value. Balazs Lengyel: No, mandatory means that the value must be present. Andy Bierman: That's not my understanding of "mandatory". David Partain: We should move this discussion to the mailing list. Juergen Schoenwaelder [looked up the definition of mandatory]: It is not clear in the text. Ladislav Lhotka: Are the initial values filled in by the device default values or something else? Andy Bierman: Why is then default-stmt not allowed together with mandatory? The question is: Is the agent allowed to supply a value for a mandatory leaf? Phil Shafer: Yes. Balazs Lengyel: The draft says: "Mandatory leaf must exist." Ladislav Lhotka: The draft says that "preceding" and "preceding-sibling" axes (and their "following" counterparts) SHOULD NOT be used. I sent examples to the mailing list where these axes are useful, so I don't agree with it. Andy Bierman: OK, I can remove this recommendation and say that the order may not be stable. David Partain: We need to discuss these open issues more and we need a new draft. Action Item: Martin Bjorklund to take a look at mandatory statement. (Editor: significant discussion on the list after the IETF) =================================================================== David Partain: We are not entertaining any new work BEFORE we have the deliverables out the door but it is OK to air ideas. =================================================================== Translation of MIBv2 to YANG (Juergen Schoenwaelder) Slides: http://www.ietf.org/proceedings/75/slides/netmod-0.pdf David Partain: thinks this is great, so it gives us some real modules to look at. Dan Romascanu: Also thinks this very useful. We can look at this when current work completes. Dan Romascanu: Should the autogenerated modules refer to the existing registry? Andy Bierman: Is SMIv2 intended to be used as a framework for developing new YANG modules? Juergen Schoenwaelder: If new modules can be developed from scratch, they should be done that way. This is just a way to reuse existing work. Andy Bierman: How will the translations be used in the standardization process? David Partain: This is up to the WG. Dan Romascanu: If there is a standard mapping, modules generated from standard MIBs could be automatically accepted. Mehmet Ersue: Shouldn't we rather encourage people to write YANG? Juergen Schoenwaelder: I just wrote the tool, it doesn't imply it will be used in one way or another. Dan Romascanu: This work should be discussed in the process of rechartering. Andy Bierman: This is a useful work. David Reid: I also support it and send comments to the mailing list. David Partain: It is OK to discuss this on the mailing list. =================================================================== Complex Types and Typed Instance Identifiers (Bernd Linowski) Slides: http://www.ietf.org/proceedings/75/slides/netmod-7.ppt Slide 7 Juergen Schoenwaelder: Where is the type info in the XML document? Bernd Linowski: It is in the elements prefixed with "ymi:". Slide 8 Ladislav Lhotka: The draft says the complex types don't have any corresponding nodes in the instance document. So where does a instance identifier typed to a complex type point to? Bernd Linowski: It looks the same as now in XML. There is always an element that has the complex type. =================================================================== David Partain: reminds the WG about OPS area open meeting - Juergen Schoenwaelder will present a NETCONF/YANG tutorial there. David Partain: Presented a roadmap for the WG items. WGLC for Architecture Second WGLC for YANG Same for YANG Data Types DSDL Mapping document NOTE: we MUST have feedback on WG LC, for all documents Martin Bjorklund: Why do we need a second WGLC for the datatypes draft? David Partain: There were no comments during the first WGLC. This means people didn't read it. So, yes. --Boundary-00=_+jpjKH7JEBlncHN-- From lhotka@cesnet.cz Fri Aug 21 07:13: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 33C2328C194 for ; Fri, 21 Aug 2009 07:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, SARE_OBFU_VALUE=0.525] 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 t9fDQmzwA-0L for ; Fri, 21 Aug 2009 07:13:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EF93728C189 for ; Fri, 21 Aug 2009 07:13:06 -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 C7941D800C1; Fri, 21 Aug 2009 16:13:10 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4A8D5E8B.5070401@joelhalpern.com> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250760980.23073.6.camel@missotis> <4A8D5E8B.5070401@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 21 Aug 2009 16:13:09 +0200 Message-Id: <1250863989.3702.11.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] agent-default -- new 3rd state 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: Fri, 21 Aug 2009 14:13:11 -0000 Joel M. Halpern píše v Čt 20. 08. 2009 v 10:32 -0400: > I am not sure I follow what you are suggesting. > In the initial config, that the box comes up with, all configuration > level mandatory nodes must exist. Whether this is done by the Not all of them, for example, mandatory nodes inside containers with presence needn't be created, they become mandatory only when the container is created. The idea simply is that the device has to start the NETCONF session with a valid configuration. > manufacturer preloading such a config, by magic, or by the device > creating likely useful vvalues for these does not change them. > > However, when a netconf application uses netconf to create a piece of > configuration (for example, the top level of a module), then that > application (and / or the user behind it) is responsible for providing > all top level mandatory pieces of information. That can be done in > steps, for example in :candidate before a commit. But the user is > responsible. Yes, at least for configuration data, rpcs and notifications are special. > > I think we are talking about the strange case where the component is > defined in a module, but is separate from the basic thing the user is > trying to create. I don't get what you mean here. Lada > As far as I can tell, it is still the users responsbility to create it, > because there is no time point in time before the commit when the system > can create it / them for him. And at the commit what the user has > provided has to be valid. > > Admittedly, this is pretty awkward. As such, Andy's recommendation in > the usage guidelines is probably the right answer. "Don't do that." > > Yours, > Joel > > Ladislav Lhotka wrote: > > WashamFan píše v Čt 20. 08. 2009 v 10:36 +0800: > >> Hi, > >> > >>> I think the original concern was with mandatory top-level nodes which > >>> by definition cannot be created by a NETCONF client, but can be > >>> created as part of initial pre-loading. > >> mandatory top-level nodes are alway kept in my mind. Those nodes could > >> not be set via , they should be set before NETCONF is started. > >> So how to interpret 'mandatory' for top-level nodes? > > > > My proposal is to require the device to set all mandatory nodes in the > > "minimum valid configuration" (which may also include leafs that are not > > top-level). > > > > Lada > > > >> washam > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Fri Aug 21 07:22: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 4A9BD3A69EF for ; Fri, 21 Aug 2009 07:22:06 -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 vIMJRoyBdnj6 for ; Fri, 21 Aug 2009 07:22:05 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 72C6A3A6909 for ; Fri, 21 Aug 2009 07:22:05 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSo6tkBOyCsJvMNur4p7v2af7KFuLM8tE@postini.com; Fri, 21 Aug 2009 07:22:11 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; Fri, 21 Aug 2009 07:14:27 -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); Fri, 21 Aug 2009 07:14:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 07:14:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 07:14:26 -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 n7LEEPd59114; Fri, 21 Aug 2009 07:14:25 -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 n7LE2Xus072918; Fri, 21 Aug 2009 14:02:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908211402.n7LE2Xus072918@idle.juniper.net> To: Per Hedeland In-Reply-To: <4A8DB47E.1050306@tail-f.com> Date: Fri, 21 Aug 2009 10:02:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2009 14:14:26.0369 (UTC) FILETIME=[B0A05B10:01CA2269] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Pattern "ok"? 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: Fri, 21 Aug 2009 14:22:06 -0000 Per Hedeland writes: >There is, per the definition in [XSD-TYPES] - might also be inferred >from the last example in the draft, and maybe from "...values that >_completely_ matches the pattern." But I guess it wouldn't hurt to spell >it out. Sounds good. One more question: Is the restriction of pattern to string-based types a CLR? Could I not use: type int { pattern "[0-9]*[24680]; } to restrict my value to even numbers? Or: type decimal64 { fractional-digits 2; pattern ".*\.{00,25,50,75}"; } Not common, but I'm just not seeing the need to restrict it to string. We would need to say that these strings apply to the canonical form of the value. Thanks, Phil From jmh@joelhalpern.com Fri Aug 21 07:22: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 B718E3A69EF for ; Fri, 21 Aug 2009 07:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 i60bKyIlwRM9 for ; Fri, 21 Aug 2009 07:22:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F28A03A6909 for ; Fri, 21 Aug 2009 07:22:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EE93F430158; Fri, 21 Aug 2009 07:22:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 520FB43009E; Fri, 21 Aug 2009 07:22:42 -0700 (PDT) Message-ID: <4A8EADAF.1070308@joelhalpern.com> Date: Fri, 21 Aug 2009 10:22:39 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250760980.23073.6.camel@missotis> <4A8D5E8B.5070401@joelhalpern.com> <1250863989.3702.11.camel@missotis> In-Reply-To: <1250863989.3702.11.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] "mandatory" extras in modules. 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: Fri, 21 Aug 2009 14:22:37 -0000 I am trying to explore what your suggestion means. Suppose that we have a Module, with two top level items, A and B. The module defines B as "mandatory". (That seems to be just a mistake, but it is allowed by our definitions.) Now, a user wants to create an A, as defined by the module. You seem to be asserting that the system can (and should / will?) fill in the "mandatory" B. I don't see how. Assuming that the user is using a configuration with deferred validation, when that validation finally occurs, the B must be there. In that config. In order for the system to add the "B" by itself, some very interesting manipulation of the validation step would have to occur. Manipulation that is not called for by the document. As such, even if some implementation can magically cause the B to appear, the management system that is creating the configuration, and presumably has logic to assist the user in enforcing the rules, will have to assume that it is the user / management system that is responsible for creating "B". This is different from mandatory top level nodes in the base config, since those were presumably created before any management interactions occurred. Yours, Joel Ladislav Lhotka wrote: > Joel M. Halpern píše v Čt 20. 08. 2009 v 10:32 -0400: ... >> I think we are talking about the strange case where the component is >> defined in a module, but is separate from the basic thing the user is >> trying to create. > > I don't get what you mean here. > > Lada > >> As far as I can tell, it is still the users responsbility to create it, >> because there is no time point in time before the commit when the system >> can create it / them for him. And at the commit what the user has >> provided has to be valid. >> >> Admittedly, this is pretty awkward. As such, Andy's recommendation in >> the usage guidelines is probably the right answer. "Don't do that." >> >> Yours, >> Joel >> From lhotka@cesnet.cz Fri Aug 21 07:38: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 3921A28C127 for ; Fri, 21 Aug 2009 07:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.044, 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 3aEvYpw1EFZc for ; Fri, 21 Aug 2009 07:38:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2CE803A6C39 for ; Fri, 21 Aug 2009 07:38:01 -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 A0C08D80096; Fri, 21 Aug 2009 16:38:06 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <001301ca21b6$f24a4ac0$0601a8c0@allison> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 21 Aug 2009 16:38:05 +0200 Message-Id: <1250865485.3702.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Fri, 21 Aug 2009 14:38:02 -0000 tom.petch píše v Čt 20. 08. 2009 v 11:43 +0200: > ----- Original Message ----- > From: "Joel M. Halpern" > To: "Ladislav Lhotka" ; "NETMOD Working Group" > > Sent: Wednesday, August 19, 2009 10:29 PM > > > If that were what the data model said, then presumably an application > > which knew that no one had modified the object (for example, it had jsut > > created the object), could reasoanbly assume that the mtu would be 1500, > > and does not need to read it to confirm that. > > > > If that is not the case, then the value in the default statement appears > > to be without meaning. > > Joel > > The meaning I give it is that the writer of the data model knows best, > perhaps because that is the WG in the SDO that developed the > protocol and has evolved it over the years. > > So this is telling the application that unless the user of the application > comes up with a better idea, then this is the value that should be > set in the device. The manufacturer of the device may have different ideas, > which no longer reflect best practice. (Plenty of examples in IPv6 > of that). > > Alternatively, we could say that the manufacturer MUST ship the box > with values as per data model, but I prefer the first approach. Me too. IMO, defaults cannot be enforced. In fact, if the leaf's data type permits a certain set of values, it is reasonable to assume that none of them is a priori wrong, so why should one value be prescribed? > > Of course, the value in question may be critical to the operation of > the box and cannot be omitted but, of course, the leaf cannot be defined > as 'mandatory'. As a matter of fact, with the "explicit" strategy of defaults handling, such values are mandatory meaning that they can never be missing in the configuration. They are either set explicitly or have the default value. Lada > > Tom Petch > > > Yours, > > Joel > > > > Ladislav Lhotka wrote: > > ... > > > So let me add one more: > > > > > > E) > > > leaf if-mtu { > > > type uint32; > > > default 1500; > > > } > > > > > > Lada > > ... > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Aug 21 07:43: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 9B5CC28C192 for ; Fri, 21 Aug 2009 07:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.056, 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 6MHh2BUKLOdj for ; Fri, 21 Aug 2009 07:43:10 -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 CEF1728C190 for ; Fri, 21 Aug 2009 07:43:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4AFFC76C54F; Fri, 21 Aug 2009 16:43:14 +0200 (CEST) Date: Fri, 21 Aug 2009 16:43:14 +0200 (CEST) Message-Id: <20090821.164314.87945618.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A8EADAF.1070308@joelhalpern.com> References: <4A8D5E8B.5070401@joelhalpern.com> <1250863989.3702.11.camel@missotis> <4A8EADAF.1070308@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] "mandatory" extras in modules. 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: Fri, 21 Aug 2009 14:43:10 -0000 "Joel M. Halpern" wrote: > I am trying to explore what your suggestion means. > Suppose that we have a Module, with two top level items, A and B. > The module defines B as "mandatory". (That seems to be just a mistake, but it > is allowed by our definitions.) > > Now, a user wants to create an A, as defined by the module. > You seem to be asserting that the system can (and should / will?) fill in the > "mandatory" B. I don't see how. When the NETCONF server advertises the namespace of Module in the hello message, it guarantees that running contains valid data for Module. (If there are no mandatory top-level nodes, this "valid data" may be empty). Thus, the server needs to make sure that B has a value when the NETCONF service starts. How this is done is implementation specific, but can be done through some initial CLI, by pre-loading the data base with some factory data, etc. /martin From lhotka@cesnet.cz Fri Aug 21 07:46:03 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 3872B3A6DFA for ; Fri, 21 Aug 2009 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=0.043, 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 vBhHArji1A6a for ; Fri, 21 Aug 2009 07:46:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 762BA3A68DB for ; Fri, 21 Aug 2009 07:46:02 -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 DACFED800C0; Fri, 21 Aug 2009 16:46:07 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908201815.n7KIFk8I066368@idle.juniper.net> References: <200908201815.n7KIFk8I066368@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 21 Aug 2009 16:46:06 +0200 Message-Id: <1250865966.3702.29.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Fri, 21 Aug 2009 14:46:03 -0000 Phil Shafer píše v Čt 20. 08. 2009 v 14:15 -0400: > "Joel M. Halpern" writes: > >To paraphrase, you are looking at the default statement as a SHOULD > >strength statement about what the value ought to be in a newly created item. > > The default is a MUST strength statement: > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when > the instance is created. What does "use internally" mean? Lada > > >As far as I can tell, that means that if a managing entity cares about > >that value, it better provide it even if the value it would provide is > >the same as the default. Becuase it can not count on the machinery > >actually ending up with that value if it does not set it. > > Neither is true. The managing entity can know that the device > will behave according to the "contract" that the YANG module > represents, and can count on the default value being used > internally when a value is not present in the configuration. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Fri Aug 21 07:47:22 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 9DB973A6E15 for ; Fri, 21 Aug 2009 07:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 aY2s8FlkOXHg for ; Fri, 21 Aug 2009 07:47: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 EADD33A6DFA for ; Fri, 21 Aug 2009 07:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E78534300B6; Fri, 21 Aug 2009 07:47:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 23CAD43013A; Fri, 21 Aug 2009 07:47:27 -0700 (PDT) Message-ID: <4A8EB37C.5080809@joelhalpern.com> Date: Fri, 21 Aug 2009 10:47:24 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <4A8D5E8B.5070401@joelhalpern.com> <1250863989.3702.11.camel@missotis> <4A8EADAF.1070308@joelhalpern.com> <20090821.164314.87945618.mbj@tail-f.com> In-Reply-To: <20090821.164314.87945618.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] "mandatory" extras in modules. 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: Fri, 21 Aug 2009 14:47:22 -0000 That at least has the advantage of putting mandatory module components on the same basis as mandatory basic configuration components. I can buy that. This looks like something that should be qualified, but if we want to allow it at all, this provides a reasonable model for what it means to have a mandatory top level item in a module. Yours, Joel Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> I am trying to explore what your suggestion means. >> Suppose that we have a Module, with two top level items, A and B. >> The module defines B as "mandatory". (That seems to be just a mistake, but it >> is allowed by our definitions.) >> >> Now, a user wants to create an A, as defined by the module. >> You seem to be asserting that the system can (and should / will?) fill in the >> "mandatory" B. I don't see how. > > When the NETCONF server advertises the namespace of Module in the > hello message, it guarantees that running contains valid data for > Module. (If there are no mandatory top-level nodes, this "valid data" > may be empty). Thus, the server needs to make sure that B has a value > when the NETCONF service starts. How this is done is implementation > specific, but can be done through some initial CLI, by pre-loading the > data base with some factory data, etc. > > > /martin > From jmh@joelhalpern.com Fri Aug 21 07:56: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 20ACC28C17C for ; Fri, 21 Aug 2009 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_35=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 cCyTI4+xyyDD for ; Fri, 21 Aug 2009 07:56: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 35A8228C194 for ; Fri, 21 Aug 2009 07:56:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EDEB04301D0; Fri, 21 Aug 2009 07:56:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 09800430190; Fri, 21 Aug 2009 07:56:28 -0700 (PDT) Message-ID: <4A8EB599.4040207@joelhalpern.com> Date: Fri, 21 Aug 2009 10:56:25 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ladislav Lhotka References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> In-Reply-To: <1250865485.3702.21.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Fri, 21 Aug 2009 14:56:25 -0000 I understand your and Tom's reasoning. But that is not what the YANG document says "default" means. The YANG document says that "[I]f the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created." Not "SHOULD use". "MUST use". It sure seems to me that if you implement what you and Tom are asking for, without getting a spec change, then what you are doing is not what the spec says. And the application attempting to set things is likely to be very confused because it can reasonably depend upon the behavior that is called for in the spec. If you argue that the system changing the value from the default is no different from some other human changing the value, and if you can persuade the rest of the working group to agree with you, then I would ask that we remove the sentence in question from the spec, as it is meaningless. And we instead replace it with something that says what you think default actually means. Note, that at least as far as I can tell, there is significant disagreement with your interpretation. But it is not my call to make. Yours, Joel Ladislav Lhotka wrote: > tom.petch píše v Čt 20. 08. 2009 v 11:43 +0200: >> ----- Original Message ----- >> From: "Joel M. Halpern" >> To: "Ladislav Lhotka" ; "NETMOD Working Group" >> >> Sent: Wednesday, August 19, 2009 10:29 PM >> >>> If that were what the data model said, then presumably an application >>> which knew that no one had modified the object (for example, it had jsut >>> created the object), could reasoanbly assume that the mtu would be 1500, >>> and does not need to read it to confirm that. >>> >>> If that is not the case, then the value in the default statement appears >>> to be without meaning. >> Joel >> >> The meaning I give it is that the writer of the data model knows best, >> perhaps because that is the WG in the SDO that developed the >> protocol and has evolved it over the years. >> >> So this is telling the application that unless the user of the application >> comes up with a better idea, then this is the value that should be >> set in the device. The manufacturer of the device may have different ideas, >> which no longer reflect best practice. (Plenty of examples in IPv6 >> of that). >> >> Alternatively, we could say that the manufacturer MUST ship the box >> with values as per data model, but I prefer the first approach. > > Me too. IMO, defaults cannot be enforced. In fact, if the leaf's data > type permits a certain set of values, it is reasonable to assume that > none of them is a priori wrong, so why should one value be prescribed? > >> Of course, the value in question may be critical to the operation of >> the box and cannot be omitted but, of course, the leaf cannot be defined >> as 'mandatory'. > > As a matter of fact, with the "explicit" strategy of defaults handling, > such values are mandatory meaning that they can never be missing in the > configuration. They are either set explicitly or have the default value. > > Lada > >> Tom Petch >> >>> Yours, >>> Joel >>> >>> Ladislav Lhotka wrote: >>> ... >>>> So let me add one more: >>>> >>>> E) >>>> leaf if-mtu { >>>> type uint32; >>>> default 1500; >>>> } >>>> >>>> Lada >>> ... >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod From lhotka@cesnet.cz Fri Aug 21 08:01: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 7C8B328C1F3 for ; Fri, 21 Aug 2009 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=0.042, 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 JOEkhWTEJ-Pf for ; Fri, 21 Aug 2009 08:01:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B62E128C1F4 for ; Fri, 21 Aug 2009 08:01:43 -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 728E3D80095; Fri, 21 Aug 2009 17:01:49 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908211402.n7LE2Xus072918@idle.juniper.net> References: <200908211402.n7LE2Xus072918@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 21 Aug 2009 17:01:48 +0200 Message-Id: <1250866908.3702.31.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Pattern "ok"? 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: Fri, 21 Aug 2009 15:01:44 -0000 Phil Shafer píše v Pá 21. 08. 2009 v 10:02 -0400: > Per Hedeland writes: > >There is, per the definition in [XSD-TYPES] - might also be inferred > >from the last example in the draft, and maybe from "...values that > >_completely_ matches the pattern." But I guess it wouldn't hurt to spell > >it out. > > Sounds good. > > One more question: Is the restriction of pattern to string-based > types a CLR? Could I not use: I think it isn't, because the regex patterns work exclusively in lexical space. Lada > > type int { > pattern "[0-9]*[24680]; > } > > to restrict my value to even numbers? Or: > > type decimal64 { > fractional-digits 2; > pattern ".*\.{00,25,50,75}"; > } > > Not common, but I'm just not seeing the need to restrict it to > string. We would need to say that these strings apply to the > canonical form of the value. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From muenz@net.in.tum.de Fri Aug 21 08:08: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 48F2C28C211 for ; Fri, 21 Aug 2009 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_38=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 B3cEjoYH3KVl for ; Fri, 21 Aug 2009 08:08:26 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 3757A28C20E for ; Fri, 21 Aug 2009 08:08:26 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 34170480F0 for ; Fri, 21 Aug 2009 17:08:30 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 28E3F54D3 for ; Fri, 21 Aug 2009 17:08:30 +0200 (CEST) Message-ID: <4A8EB86E.8060404@net.in.tum.de> Date: Fri, 21 Aug 2009 17:08:30 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: netmod@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080405020604060700060005" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [netmod] Question about condition in must-statement 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: Fri, 21 Aug 2009 15:08:27 -0000 This is a cryptographically signed message in MIME format. --------------ms080405020604060700060005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, In PSAMP, there are packet filters using hash functions which are applied to specific header or payload bits. Which bits are used as input of the hash function is specified with an octet string. This octet string is applied like a mask to the header or payload section, however the zero bits will be removed (not kept). Currently, the YANG part to configure such a filter looks like this (which hopefully can be understood with the descriptions): container filterHash { leaf ipVersion { type inet:ip-version; description "IP version of packets to be selected."; } leaf headerBits { type binary; must "not(addrType = 'ipv4') or not(addrType = 'ipv6') or (../addrType = 'ipv4' and string-length() = 20) or (../addrType = 'ipv6' and string-length() = 40)"; description "This parameter specifies an octet string defining the IP header bits used as input to the hash function, starting with the first header octet. The length of the octet string must be 20 if addrType is 'ipv4', and 40 if addrType is 'ipv6'."; } leaf payloadBytes { type uint32; units octets; default 0; description "Number of IP payload octets used as input to the hash function, counted from the beginning of the payload section. If the IP payload is shorter than the configured value, all payload octets are used as input."; } leaf payloadBits { type binary; must "string-length() = ../payloadBytes"; description "This parameter specifies an octet string defining the IP payload bits used as input to the hash function, starting with the first payload octet. If this parameter is configured, the length of the octet string must equal the maximum number of payload octets specified by payloadBytes."; } ... } I have three questions: 1) Should I use binary or string for headerBits and payloadBits? 2) Can I restrict the length of a binary leaf with string-length()? 3) If yes, does string-length() return the length in base64 symbols or in octets? Thanks, Gerhard --------------ms080405020604060700060005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODIxMTUwODMwWjAjBgkqhkiG9w0BCQQxFgQU tOFR5Ax6I4DTujWDX6gn+0evWM4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBACthUQ8oPJODLi0Keja8SFYTEgw7SBwitXwG6kKhpVUA8pJW iz04EgPJctkBKQ7nPOyhRD7Bh+AKhjyoIS0n2GspvdlkYEcSFHcBgbWtW64kFnnO3sedB0rB fHXEcUEj10jX0RpxrjChLGnqxDzGvL2LZDwbSrYCs/VNk3FXg/eraYDRyz7CR3oqi/p1h8kq GxxfCnTOLDTeOBHHjcFA53kc1U9ljCMOQ5aIAC7WBbGfDQ8S/YcNiL2IZlanGOyHa49wjh2N /kZbG3kmXtZmF6hfeCoTZG3gDQVD0l2flZrnSU4oKd2w/+ttBWaCNfBwgf76GFdCnnUIxkzh vBp/AGgAAAAAAAA= --------------ms080405020604060700060005-- From lhotka@cesnet.cz Fri Aug 21 08:35: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 E75C03A6DFB for ; Fri, 21 Aug 2009 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 xKUm1s0ypFyP for ; Fri, 21 Aug 2009 08:35:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B969128C1A2 for ; Fri, 21 Aug 2009 08:35:14 -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 0EC81D80096; Fri, 21 Aug 2009 17:35:20 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <4A8EB599.4040207@joelhalpern.com> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 21 Aug 2009 17:35:18 +0200 Message-Id: <1250868918.3702.62.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Fri, 21 Aug 2009 15:35:16 -0000 Joel M. Halpern píše v Pá 21. 08. 2009 v 10:56 -0400: > I understand your and Tom's reasoning. > > But that is not what the YANG document says "default" means. The YANG > document says that "[I]f the leaf has a default value, the server MUST > use this value internally if no value is provided by the NETCONF client > when the instance is created." But I am questioning here what "use internally" means. For example, in Linux, the hotplug subsystem allows for user-space hooks that are run after the component is initialized. So even if the kernel driver sets a default value ("uses it internally") for a parameter, it may be changed before the user can do anything about it, and various distributions indeed make their choices. > > Not "SHOULD use". "MUST use". It sure seems to me that if you IMO, SHOULD has effectively the same strength as MUST in this case. > implement what you and Tom are asking for, without getting a spec > change, then what you are doing is not what the spec says. And the > application attempting to set things is likely to be very confused > because it can reasonably depend upon the behavior that is called for in > the spec. > > If you argue that the system changing the value from the default is no > different from some other human changing the value, and if you can > persuade the rest of the working group to agree with you, then I would > ask that we remove the sentence in question from the spec, as it is > meaningless. And we instead replace it with something that says what > you think default actually means. I agree. I can see how defaults may be useful as a way for controlled simplification of configurations presented to the clients, but they really have nothing to do with validity of configurations. Lada > Note, that at least as far as I can tell, there is significant > disagreement with your interpretation. But it is not my call to make. > > Yours, > Joel > > Ladislav Lhotka wrote: > > tom.petch píše v Čt 20. 08. 2009 v 11:43 +0200: > >> ----- Original Message ----- > >> From: "Joel M. Halpern" > >> To: "Ladislav Lhotka" ; "NETMOD Working Group" > >> > >> Sent: Wednesday, August 19, 2009 10:29 PM > >> > >>> If that were what the data model said, then presumably an application > >>> which knew that no one had modified the object (for example, it had jsut > >>> created the object), could reasoanbly assume that the mtu would be 1500, > >>> and does not need to read it to confirm that. > >>> > >>> If that is not the case, then the value in the default statement appears > >>> to be without meaning. > >> Joel > >> > >> The meaning I give it is that the writer of the data model knows best, > >> perhaps because that is the WG in the SDO that developed the > >> protocol and has evolved it over the years. > >> > >> So this is telling the application that unless the user of the application > >> comes up with a better idea, then this is the value that should be > >> set in the device. The manufacturer of the device may have different ideas, > >> which no longer reflect best practice. (Plenty of examples in IPv6 > >> of that). > >> > >> Alternatively, we could say that the manufacturer MUST ship the box > >> with values as per data model, but I prefer the first approach. > > > > Me too. IMO, defaults cannot be enforced. In fact, if the leaf's data > > type permits a certain set of values, it is reasonable to assume that > > none of them is a priori wrong, so why should one value be prescribed? > > > >> Of course, the value in question may be critical to the operation of > >> the box and cannot be omitted but, of course, the leaf cannot be defined > >> as 'mandatory'. > > > > As a matter of fact, with the "explicit" strategy of defaults handling, > > such values are mandatory meaning that they can never be missing in the > > configuration. They are either set explicitly or have the default value. > > > > Lada > > > >> Tom Petch > >> > >>> Yours, > >>> Joel > >>> > >>> Ladislav Lhotka wrote: > >>> ... > >>>> So let me add one more: > >>>> > >>>> E) > >>>> leaf if-mtu { > >>>> type uint32; > >>>> default 1500; > >>>> } > >>>> > >>>> Lada > >>> ... > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Fri Aug 21 08:37: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 16BEA3A6E3F for ; Fri, 21 Aug 2009 08:37:09 -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 iZlOv8n9geyt for ; Fri, 21 Aug 2009 08:37:08 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 9808A3A6E3A for ; Fri, 21 Aug 2009 08:37:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSo6/IPRPtT0RQ8S5aYLsXdV9kDzemqiD@postini.com; Fri, 21 Aug 2009 08:37:14 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; Fri, 21 Aug 2009 08:28:46 -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); Fri, 21 Aug 2009 08:28:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 08:28:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 08:28:44 -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 n7LFSid93585; Fri, 21 Aug 2009 08:28:44 -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 n7LFGpwX073580; Fri, 21 Aug 2009 15:16:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908211516.n7LFGpwX073580@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1250865966.3702.29.camel@missotis> Date: Fri, 21 Aug 2009 11:16:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2009 15:28:44.0789 (UTC) FILETIME=[120D4250:01CA2274] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Fri, 21 Aug 2009 15:37:09 -0000 Ladislav Lhotka writes: >> If the leaf has a default value, the server MUST use this value >> internally if no value is provided by the NETCONF client when >> the instance is created. > >What does "use internally" mean? Are you truly not following, or just wanting better words? Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Aug 21 12:53:20 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 BE0A33A6C28 for ; Fri, 21 Aug 2009 12:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_20=-0.74, 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 kBSamoOPwLzN for ; Fri, 21 Aug 2009 12:53:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AB8153A6B63 for ; Fri, 21 Aug 2009 12:53:19 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04808C000A; Fri, 21 Aug 2009 21: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 (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Oa2GVCa1982u; Fri, 21 Aug 2009 21:53:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7110C0005; Fri, 21 Aug 2009 21:53:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B274BC7797D; Fri, 21 Aug 2009 21:53:22 +0200 (CEST) Date: Fri, 21 Aug 2009 21:53:22 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20090821195322.GA13676@elstar.local> Mail-Followup-To: Gerhard Muenz , "netmod@ietf.org" References: <4A8EB86E.8060404@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8EB86E.8060404@net.in.tum.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Question about condition in must-statement 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: Fri, 21 Aug 2009 19:53:20 -0000 On Fri, Aug 21, 2009 at 05:08:30PM +0200, Gerhard Muenz wrote: > I have three questions: > > 1) Should I use binary or string for headerBits and payloadBits? What speaks against binary for binary data? > 2) Can I restrict the length of a binary leaf with string-length()? The xpath expression is evaluated on the canonical stringified value representation (section 7.5.3 of the YANG ID), which for the binary YANG type would be a base64 encoding. So you have to be careful. > 3) If yes, does string-length() return the length in base64 symbols or > in octets? See above - it will be the number of characters needed for the base64 encoding. Note that there is always a description clause; sometimes it might be simpler to spell things out in written words. ;-) /js PS: We prefer the header-bits and payload-bits writing style in YANG models so far. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Aug 21 12:58: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 B70DA3A6B63 for ; Fri, 21 Aug 2009 12:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Lr+VDZ63fUVR for ; Fri, 21 Aug 2009 12:58:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CEE893A69F5 for ; Fri, 21 Aug 2009 12:58:01 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51A97C000A; Fri, 21 Aug 2009 21:58:07 +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 Y8v4ROY11BXy; Fri, 21 Aug 2009 21:58:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCF88C0005; Fri, 21 Aug 2009 21:58:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8675AC779FA; Fri, 21 Aug 2009 21:58:04 +0200 (CEST) Date: Fri, 21 Aug 2009 21:58:04 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090821195804.GB13676@elstar.local> Mail-Followup-To: Phil Shafer , Per Hedeland , "netmod@ietf.org" References: <4A8DB47E.1050306@tail-f.com> <200908211402.n7LE2Xus072918@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908211402.n7LE2Xus072918@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Pattern "ok"? 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: Fri, 21 Aug 2009 19:58:02 -0000 On Fri, Aug 21, 2009 at 04:02:33PM +0200, Phil Shafer wrote: > Per Hedeland writes: > >There is, per the definition in [XSD-TYPES] - might also be inferred > >from the last example in the draft, and maybe from "...values that > >_completely_ matches the pattern." But I guess it wouldn't hurt to spell > >it out. > > Sounds good. > > One more question: Is the restriction of pattern to string-based > types a CLR? Could I not use: > > type int { > pattern "[0-9]*[24680]; > } > > to restrict my value to even numbers? Or: > > type decimal64 { > fractional-digits 2; > pattern ".*\.{00,25,50,75}"; > } > > Not common, but I'm just not seeing the need to restrict it to > string. We would need to say that these strings apply to the > canonical form of the value. Section 7.5.3. already says this: Note that since all leaf values in the data tree are conceptually stored in their canonical form (see Section 7.6 and Section 7.7), any XPath comparisons are done on the canonical value. The text is trying to say the right thing, although the wording can be improved - it does not matter how values are "stored" - it would be more helpful to simply spell out that the expressions are evaluated against the canonical representation of values. /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 Fri Aug 21 13:01: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 0D65928C16B for ; Fri, 21 Aug 2009 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 iNH6XDAYYtoy for ; Fri, 21 Aug 2009 13:01:37 -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 1CE8D3A6C8D for ; Fri, 21 Aug 2009 13:01:37 -0700 (PDT) Received: (qmail 75012 invoked from network); 21 Aug 2009 20:01:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 21 Aug 2009 20:01:40 -0000 X-YMail-OSG: vy8gw.cVM1nmDBEeFif5BaZdOCQIhpzJDPWUXc6X58dMrh.Tgp1QTwTpqvjqNc5RTxlqj4RXAnIHu7k2v96qDv3WmyoxHE1a_rSnNjWX9n62CKG0zgO6cA5mozMB7vhDCFF2VNaDGa7j5.x7Odw6g8Vj7eqmebZGsBH6ExVMZFPNtbdzx0iWxxg1TXaDoM4LgC9dY9aGTFKFVHN0AZj4ysHajxvbm6gLptPrDOLKof7wrYz9QuC71wp_8FY_DF8rm43TL4epuYmz6AZ2VmdK30rDvE97CtfLI6a.rDt6FyfDMejPl2o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8EFD30.6010308@netconfcentral.com> Date: Fri, 21 Aug 2009 13:01:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Gerhard Muenz , "netmod@ietf.org" References: <4A8EB86E.8060404@net.in.tum.de> <20090821195322.GA13676@elstar.local> In-Reply-To: <20090821195322.GA13676@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Question about condition in must-statement 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: Fri, 21 Aug 2009 20:01:38 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 21, 2009 at 05:08:30PM +0200, Gerhard Muenz wrote: >> I have three questions: >> >> 1) Should I use binary or string for headerBits and payloadBits? > > What speaks against binary for binary data? > indeed -- this would be a good test for the binary data type. It is so user-unfriendly that it will be interesting to see how the support for the binary built-in type varies across tools. Entering base64 by hand or reading it raw is beyond unlikely. >> 2) Can I restrict the length of a binary leaf with string-length()? > > The xpath expression is evaluated on the canonical stringified value > representation (section 7.5.3 of the YANG ID), which for the binary > YANG type would be a base64 encoding. So you have to be careful. > >> 3) If yes, does string-length() return the length in base64 symbols or >> in octets? > > See above - it will be the number of characters needed for the base64 > encoding. Note that there is always a description clause; sometimes it > might be simpler to spell things out in written words. ;-) > > /js > > PS: We prefer the header-bits and payload-bits writing style in YANG > models so far. > Andy From j.schoenwaelder@jacobs-university.de Fri Aug 21 13:04: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 119713A691B for ; Fri, 21 Aug 2009 13:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Rw7WCR55plfA for ; Fri, 21 Aug 2009 13:04:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 837D028C16B for ; Fri, 21 Aug 2009 13:04:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 062CAC000D; Fri, 21 Aug 2009 22:04:13 +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 AVOXbp-GSl6r; Fri, 21 Aug 2009 22:04:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2E2DC0005; Fri, 21 Aug 2009 22:04:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4591AC77AC3; Fri, 21 Aug 2009 22:04:10 +0200 (CEST) Date: Fri, 21 Aug 2009 22:04:10 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090821200410.GC13676@elstar.local> Mail-Followup-To: Ladislav Lhotka , "Joel M. Halpern" , NETMOD Working Group References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <1250868918.3702.62.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250868918.3702.62.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] 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: Fri, 21 Aug 2009 20:04:53 -0000 On Fri, Aug 21, 2009 at 05:35:18PM +0200, Ladislav Lhotka wrote: > Joel M. Halpern p????e v P?? 21. 08. 2009 v 10:56 -0400: > > I understand your and Tom's reasoning. > > > > But that is not what the YANG document says "default" means. The YANG > > document says that "[I]f the leaf has a default value, the server MUST > > use this value internally if no value is provided by the NETCONF client > > when the instance is created." > > But I am questioning here what "use internally" means. For example, in > Linux, the hotplug subsystem allows for user-space hooks that are run > after the component is initialized. So even if the kernel driver sets a > default value ("uses it internally") for a parameter, it may be changed > before the user can do anything about it, and various distributions > indeed make their choices. Are we still talking about config or already about operational state? -- 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 Fri Aug 21 14:18: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 47CD428C1F8 for ; Fri, 21 Aug 2009 14:18:41 -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 TXkXwG7N2NrV for ; Fri, 21 Aug 2009 14:18:40 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 5E08B3A6ABB for ; Fri, 21 Aug 2009 14:18:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSo8PMDwBaUKGD/p7OZa8so9ZmK8v1EhG@postini.com; Fri, 21 Aug 2009 14:18:46 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; Fri, 21 Aug 2009 14:15:58 -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); Fri, 21 Aug 2009 14:15:58 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 14:15:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 14:15:57 -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 n7LLFud61418; Fri, 21 Aug 2009 14:15:57 -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 n7LL43L4076165; Fri, 21 Aug 2009 21:04:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908212104.n7LL43L4076165@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090821195804.GB13676@elstar.local> Date: Fri, 21 Aug 2009 17:04:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2009 21:15:57.0630 (UTC) FILETIME=[936485E0:01CA22A4] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] Pattern "ok"? 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: Fri, 21 Aug 2009 21:18:41 -0000 Juergen Schoenwaelder writes: >> Not common, but I'm just not seeing the need to restrict it to >> string. We would need to say that these strings apply to the >> canonical form of the value. > >Section 7.5.3. already says this: > > Note that since all leaf values in the data tree are conceptually > stored in their canonical form (see Section 7.6 and Section 7.7), any > XPath comparisons are done on the canonical value. > >The text is trying to say the right thing, although the wording can be >improved - it does not matter how values are "stored" - it would be >more helpful to simply spell out that the expressions are evaluated >against the canonical representation of values. It definitely needs better wording, so cover non-xpath ('pattern' statement) comparisons. How about: - XPath comparisons are done on the canonical value. + comparisons from 'pattern' constraints or XPath expressions + are done on the canonical value. Are you okay with removing the string-only CLR for pattern? Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Aug 21 15:19: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 124F83A69EA for ; Fri, 21 Aug 2009 15:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 k0SJbe-zcKIC for ; Fri, 21 Aug 2009 15:19:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DB27A3A6359 for ; Fri, 21 Aug 2009 15:19:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63040C000A; Sat, 22 Aug 2009 00:20:00 +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 ii1VQRoKcaXf; Sat, 22 Aug 2009 00:19:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4ECDBC0005; Sat, 22 Aug 2009 00:19:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B089CC77E17; Sat, 22 Aug 2009 00:19:57 +0200 (CEST) Date: Sat, 22 Aug 2009 00:19:57 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090821221957.GA13897@elstar.local> Mail-Followup-To: Phil Shafer , Per Hedeland , "netmod@ietf.org" References: <20090821195804.GB13676@elstar.local> <200908212104.n7LL43L4076165@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908212104.n7LL43L4076165@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Pattern "ok"? 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: Fri, 21 Aug 2009 22:19:56 -0000 On Fri, Aug 21, 2009 at 11:04:03PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >> Not common, but I'm just not seeing the need to restrict it to > >> string. We would need to say that these strings apply to the > >> canonical form of the value. > > > >Section 7.5.3. already says this: > > > > Note that since all leaf values in the data tree are conceptually > > stored in their canonical form (see Section 7.6 and Section 7.7), any > > XPath comparisons are done on the canonical value. > > > >The text is trying to say the right thing, although the wording can be > >improved - it does not matter how values are "stored" - it would be > >more helpful to simply spell out that the expressions are evaluated > >against the canonical representation of values. > > It definitely needs better wording, so cover non-xpath ('pattern' > statement) comparisons. How about: > > - XPath comparisons are done on the canonical value. > + comparisons from 'pattern' constraints or XPath expressions > + are done on the canonical value. 7.5.3. is about must statements - this is the way the document is organized; pattern are handled elsewhere. > Are you okay with removing the string-only CLR for pattern? >From the way the YANG specification is written, this is a rather heavy editing change. If this is really a CLR, then it is anchored deeply in the specs. I am probably not sure yet of the value of allowing pattern for numeric types nor do I have personally much experience with using regular expressions to restrict number spaces - but this might just be my ignorance. XSD allows pattern restrictions pretty much everywhere - even for the type boolean which has the two values 'true' and 'false'. It is kind of difficult to come up with a use case for a pattern on boolean but if you allow it everywhere, then there certainly is no CLR. ;-) So what is your proposal - pattern restrictions for all types? /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 Fri Aug 21 15:23: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 E08373A6BD4 for ; Fri, 21 Aug 2009 15:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 SwzM+os-aJtI for ; Fri, 21 Aug 2009 15:23:50 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 08A7B3A69EA for ; Fri, 21 Aug 2009 15:23:49 -0700 (PDT) Received: from [68.142.200.227] by n18.bullet.mail.mud.yahoo.com with NNFMP; 21 Aug 2009 22:23:54 -0000 Received: from [68.142.201.254] by t8.bullet.mud.yahoo.com with NNFMP; 21 Aug 2009 22:23:54 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 21 Aug 2009 22:23:54 -0000 X-Yahoo-Newman-Id: 252174.7536.bm@omp415.mail.mud.yahoo.com Received: (qmail 49540 invoked from network); 21 Aug 2009 22:23:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2009 22:23:53 -0000 X-YMail-OSG: MeXeSJ8VM1nMSTAcnqflg4Y7Fe9ktP9G4erpaiH39oMTEKnXYeuthHzs0UWv.F9g0A17Al3Xj2liGRDnlKc2m2nr9XiVptZ22m0L5jJsSBtnaIL.I.8zbJbNnspkokEBLa.fSlXAKWlc14QzIp99I4Qia7onwrYu5z_TRV85609w2trrMjCFRHVTp1eV3n5afqMyKoRPQulFR1gPF88IFTOr6_B_jDGQxDBAhiL.VfMxM6DyIQU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8F1E87.1010708@netconfcentral.com> Date: Fri, 21 Aug 2009 15:24:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908212104.n7LL43L4076165@idle.juniper.net> In-Reply-To: <200908212104.n7LL43L4076165@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Pattern "ok"? 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: Fri, 21 Aug 2009 22:23:51 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >>> Not common, but I'm just not seeing the need to restrict it to >>> string. We would need to say that these strings apply to the >>> canonical form of the value. >> Section 7.5.3. already says this: >> >> Note that since all leaf values in the data tree are conceptually >> stored in their canonical form (see Section 7.6 and Section 7.7), any >> XPath comparisons are done on the canonical value. >> >> The text is trying to say the right thing, although the wording can be >> improved - it does not matter how values are "stored" - it would be >> more helpful to simply spell out that the expressions are evaluated >> against the canonical representation of values. > > It definitely needs better wording, so cover non-xpath ('pattern' > statement) comparisons. How about: > > - XPath comparisons are done on the canonical value. > + comparisons from 'pattern' constraints or XPath expressions > + are done on the canonical value. > > Are you okay with removing the string-only CLR for pattern? > What is the string-only CLR? Why are we talking about changing the way patterns work now? It is not needed for any other built-in data types besides string. > Thanks, > Phil Andy From phil@juniper.net Fri Aug 21 20:04: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 B40073A68EF for ; Fri, 21 Aug 2009 20:04:38 -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 NeabNJ5acyQK for ; Fri, 21 Aug 2009 20:04:38 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id B8C133A6A6F for ; Fri, 21 Aug 2009 20:04:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSo9gQOLkQIwLcQF1E0W5wFTUkiLxopTb@postini.com; Fri, 21 Aug 2009 20:04:37 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; Fri, 21 Aug 2009 20:02:44 -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); Fri, 21 Aug 2009 20:02:43 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 20:02:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 20:02:42 -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 n7M32fd02463; Fri, 21 Aug 2009 20:02:41 -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 n7M2olY5078183; Sat, 22 Aug 2009 02:50:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908220250.n7M2olY5078183@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090821221957.GA13897@elstar.local> Date: Fri, 21 Aug 2009 22:50:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2009 03:02:42.0589 (UTC) FILETIME=[041D54D0:01CA22D5] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] Pattern "ok"? 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: Sat, 22 Aug 2009 03:04:38 -0000 Juergen Schoenwaelder writes: >So what is your proposal - pattern restrictions for all types? Yup. The fix is something like: - defined in ^XSD-TYPES^. It is used to - restrict the built-in type "string", or types derived from "string", - to values that completely matches the pattern. + defined in ^XSD-TYPES^. These regular expressions + are applied to the canonical format of the value + and match the complete string, with an implicitly "^" + and "$" before and after the given pattern string. Thanks, Phil From j.schoenwaelder@jacobs-university.de Sat Aug 22 00:15: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 EB4073A6820 for ; Sat, 22 Aug 2009 00:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 5bkaeSOf7wgx for ; Sat, 22 Aug 2009 00:15:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 14F813A67B0 for ; Sat, 22 Aug 2009 00:15:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98FF1C0008; Sat, 22 Aug 2009 09:15:09 +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 7Utgf04ntsSI; Sat, 22 Aug 2009 09:15:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A76A4C0005; Sat, 22 Aug 2009 09:15:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 55E7DC78365; Sat, 22 Aug 2009 09:15:07 +0200 (CEST) Date: Sat, 22 Aug 2009 09:15:06 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090822071506.GA14326@elstar.local> Mail-Followup-To: Phil Shafer , Per Hedeland , "netmod@ietf.org" References: <20090821221957.GA13897@elstar.local> <200908220250.n7M2olY5078183@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908220250.n7M2olY5078183@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Pattern "ok"? 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: Sat, 22 Aug 2009 07:15:06 -0000 On Sat, Aug 22, 2009 at 04:50:47AM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >So what is your proposal - pattern restrictions for all types? > > Yup. The fix is something like: > > - defined in ^XSD-TYPES^. It is used to > - restrict the built-in type "string", or types derived from "string", > - to values that completely matches the pattern. > + defined in ^XSD-TYPES^. These regular expressions > + are applied to the canonical format of the value > + and match the complete string, with an implicitly "^" > + and "$" before and after the given pattern string. Not correct. Look at the ABNF and there are other places in the text talking about restrictions that would need to be adapted. /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 Sat Aug 22 01:52:17 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 D0CC33A6A92 for ; Sat, 22 Aug 2009 01:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 SkU3sBHvu21M for ; Sat, 22 Aug 2009 01:52:17 -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 17E1C3A6921 for ; Sat, 22 Aug 2009 01:52:17 -0700 (PDT) Received: (qmail 48799 invoked from network); 22 Aug 2009 08:52:20 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 22 Aug 2009 08:52:20 -0000 X-YMail-OSG: qzDEdEcVM1ma8km71LRPQvzY8sb756k9zhKl7CxcqHG5RUvJv10eadHwOrB1pHbJh9r2gfmKxPYNqe9DgCXyUMFjtNVtlKFpJdplv66HhPAF5N2nfHNUATCaIT6.tcIwFpnzruhFQVpSddDtBA6I284WCOPqIPnfknbq8Z6zYx8caZsQaxkk2CWujBm2XrkLAuEZaXQ5UVhb_5CKmT7l1ksy.PPM51NpMwZZSw4kK8WNTbbZe.V9fOmEAcGVZ2CTrmBMBkQzyiy3vno- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8FB1D4.8010005@netconfcentral.com> Date: Sat, 22 Aug 2009 01:52:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908220250.n7M2olY5078183@idle.juniper.net> In-Reply-To: <200908220250.n7M2olY5078183@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Pattern "ok"? 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: Sat, 22 Aug 2009 08:52:17 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> So what is your proposal - pattern restrictions for all types? > > Yup. The fix is something like: > So what problem does this solve in YANG? We have ranges for numbers, so we don't need patterns there. We have enum strings and bit names, sure don't need them there. We have identityrefs and instance-identifiers, sure don't need them there. Boolean? binary? No. So what YANG data modeling problem does this solution address? This is just piling on complexity without reason. > - defined in ^XSD-TYPES^. It is used to > - restrict the built-in type "string", or types derived from "string", > - to values that completely matches the pattern. > + defined in ^XSD-TYPES^. These regular expressions > + are applied to the canonical format of the value > + and match the complete string, with an implicitly "^" > + and "$" before and after the given pattern string. > > Thanks, > Phil Andy From mbj@tail-f.com Sat Aug 22 06:20: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 9B85D3A6A8C for ; Sat, 22 Aug 2009 06:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.054, 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 PnI8XnKj7FlZ for ; Sat, 22 Aug 2009 06:20:04 -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 C0F193A687F for ; Sat, 22 Aug 2009 06:20: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 14F7276C4E3; Sat, 22 Aug 2009 15:20:09 +0200 (CEST) Date: Sat, 22 Aug 2009 15:20:08 +0200 (CEST) Message-Id: <20090822.152008.05394584.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A8FB1D4.8010005@netconfcentral.com> References: <200908220250.n7M2olY5078183@idle.juniper.net> <4A8FB1D4.8010005@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] Pattern "ok"? 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: Sat, 22 Aug 2009 13:20:05 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> So what is your proposal - pattern restrictions for all types? > > > > Yup. The fix is something like: > > > > > So what problem does this solve in YANG? > We have ranges for numbers, so we don't need patterns there. > We have enum strings and bit names, sure don't need them there. > We have identityrefs and instance-identifiers, sure don't need > them there. Boolean? binary? No. > > So what YANG data modeling problem does this solution address? > > This is just piling on complexity without reason. +1 The only other type it could be used is as some kind of hack for integer types, but if we want to provide more powerful integer restrictions we may want to look at other statements. For example, a customer asked if something like this is possible: type int32 { range "10..1000" { step 10; } } This would probably be more useful than pattern. (But I don't propose that we add it!) > > - defined in ^XSD-TYPES^. It is used to > > - restrict the built-in type "string", or types derived from "string", > > - to values that completely matches the pattern. > > + defined in ^XSD-TYPES^. These regular expressions > > + are applied to the canonical format of the value > > + and match the complete string, with an implicitly "^" > > + and "$" before and after the given pattern string. Re. implict ^ and $, I don't think it is a good idea to point out just this. There are many regular expression "dialects", and we define which one we use (XSD). That is precise and IMO enough. This document is not the right place to educate people on differences between regular expression dialects. /martin From phil@juniper.net Sat Aug 22 09:37: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 C1DF33A6A14 for ; Sat, 22 Aug 2009 09:37:52 -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 hJH8rQ2QDYCd for ; Sat, 22 Aug 2009 09:37:52 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 014723A6918 for ; Sat, 22 Aug 2009 09:37:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSpAe4uTNGSsb+CPGfr73GiD2BZMGNw6r@postini.com; Sat, 22 Aug 2009 09:37: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; Sat, 22 Aug 2009 09:35:51 -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); Sat, 22 Aug 2009 09:35:51 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Aug 2009 09:35:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Aug 2009 09:35:49 -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 n7MGZmd93558; Sat, 22 Aug 2009 09:35:48 -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 n7MGNsjb081060; Sat, 22 Aug 2009 16:23:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908221623.n7MGNsjb081060@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090822.152008.05394584.mbj@tail-f.com> Date: Sat, 22 Aug 2009 12:23:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2009 16:35:49.0830 (UTC) FILETIME=[9B938660:01CA2346] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Pattern "ok"? 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: Sat, 22 Aug 2009 16:37:52 -0000 >Andy Bierman wrote: >> This is just piling on complexity without reason. No, it's removing the CLR that says pattern is only valid for string-based types. >Martin wrote: >Re. implict ^ and $, I don't think it is a good idea to point out just >this. There are many regular expression "dialects", and we define >which one we use (XSD). That is precise and IMO enough. This >document is not the right place to educate people on differences >between regular expression dialects. I think we need to point out that it's matching the complete string, so we don't see a lot of patterns like "^ok$". Thanks, Phil From lhotka@cesnet.cz Mon Aug 24 01:00: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 B50743A659C for ; Mon, 24 Aug 2009 01:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_50=0.001, 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 pkDTccbX6iPS for ; Mon, 24 Aug 2009 01:00:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E5C903A6DC8 for ; Mon, 24 Aug 2009 01:00:27 -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 A1C89D800C5; Mon, 24 Aug 2009 10:00:28 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908211516.n7LFGpwX073580@idle.juniper.net> References: <200908211516.n7LFGpwX073580@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 10:00:27 +0200 Message-Id: <1251100827.7051.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 24 Aug 2009 08:00:28 -0000 Phil Shafer píše v Pá 21. 08. 2009 v 11:16 -0400: > Ladislav Lhotka writes: > >> If the leaf has a default value, the server MUST use this value > >> internally if no value is provided by the NETCONF client when > >> the instance is created. > > > >What does "use internally" mean? > > Are you truly not following, or just wanting better words? Both. Could it be reformulated like this? "An edit-config operation that creates the instance but does not provide a value for such a leaf MUST have the same effect as if the default value for that leaf was explicitly specified." But neither this nor the original sentence covers the case where no NETCONF client/operation is involved, i.e. when the instance is a part of the initial configuration or is created automatically after a new piece of hardware is plugged in. Are there any assumptions for these cases? Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Aug 24 01:20: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 21ECD3A6D4A for ; Mon, 24 Aug 2009 01:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 38h1BMW30Zls for ; Mon, 24 Aug 2009 01:20:25 -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 5C1383A6CAB for ; Mon, 24 Aug 2009 01:20:25 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 44B6076C5DE for ; Mon, 24 Aug 2009 10:20:30 +0200 (CEST) Date: Mon, 24 Aug 2009 10:20:33 +0200 (CEST) Message-Id: <20090824.102033.118206378.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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 Subject: [netmod] bit statement bug 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: Mon, 24 Aug 2009 08:20:26 -0000 Hi, A bit name is currently restricted to be an identifier. I think this is a bug - at some point in time both enums and bits were supposed to be identifiers, but we relaxed this. The text reflects this for enums, but not for bits. For example, the usage example in 9.7.5 has this: bit 10-Mb-only { position 2; } but this is not legal according to the current text and grammar. I suggest this change to 9.7.4: OLD The "bit" statement, which is a substatement to the "type" statement, MUST be present if the type is "bits". It is repeatedly used to specify each assigned named bit of a bits type. It takes as an argument a string which is the assigned name of the bit. It is followed by a block of substatements which holds detailed bit information. A bit name follows the same syntax rules as an identifier (see Section 6.2). NEW The "bit" statement, which is a substatement to the "type" statement, MUST be present if the type is "bits". It is repeatedly used to specify each assigned named bit of a bits type. It takes as an argument a string which is the assigned name of the bit. The string MUST NOT be empty and MUST NOT contain any whitespace characters. The use of control codes SHOULD be avoided. The statement is optionally followed by a block of substatements which holds detailed bit information. /martin From j.schoenwaelder@jacobs-university.de Mon Aug 24 01:45: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 15C423A6DDB for ; Mon, 24 Aug 2009 01:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_05=-1.11, 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 jVDc2mPESLMt for ; Mon, 24 Aug 2009 01:45:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E84643A6BF0 for ; Mon, 24 Aug 2009 01:45:40 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83246C0022; Mon, 24 Aug 2009 10:45: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 U68jdoitDaP7; Mon, 24 Aug 2009 10:45:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E733C001A; Mon, 24 Aug 2009 10:45:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 40CD3C7A17A; Mon, 24 Aug 2009 10:45:44 +0200 (CEST) Date: Mon, 24 Aug 2009 10:45:44 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090824084544.GC15710@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20090824.102033.118206378.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090824.102033.118206378.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] bit statement bug 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: Mon, 24 Aug 2009 08:45:42 -0000 On Mon, Aug 24, 2009 at 10:20:33AM +0200, Martin Bjorklund wrote: > Hi, > > A bit name is currently restricted to be an identifier. I think this > is a bug - at some point in time both enums and bits were supposed to > be identifiers, but we relaxed this. The text reflects this for > enums, but not for bits. For example, the usage example in 9.7.5 has > this: > > bit 10-Mb-only { > position 2; > } > > but this is not legal according to the current text and grammar. > > I suggest this change to 9.7.4: > > OLD > > The "bit" statement, which is a substatement to the "type" statement, > MUST be present if the type is "bits". It is repeatedly used to > specify each assigned named bit of a bits type. It takes as an > argument a string which is the assigned name of the bit. It is > followed by a block of substatements which holds detailed bit > information. A bit name follows the same syntax rules as an > identifier (see Section 6.2). > > NEW > > The "bit" statement, which is a substatement to the "type" statement, > MUST be present if the type is "bits". It is repeatedly used to > specify each assigned named bit of a bits type. It takes as an > argument a string which is the assigned name of the bit. The > string MUST NOT be empty and MUST NOT contain any > whitespace characters. The use of control codes SHOULD be avoided. > > The statement is optionally followed by a block of substatements > which holds detailed bit information. I agree that the text for enums and bits should be identical. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Aug 24 02:05: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 9030A3A6DEB for ; Mon, 24 Aug 2009 02:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, 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 I7JmuxIq5shE for ; Mon, 24 Aug 2009 02:05:04 -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 C539D3A6B5D for ; Mon, 24 Aug 2009 02:05:03 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 6FF3576C5DE; Mon, 24 Aug 2009 11:05:09 +0200 (CEST) Date: Mon, 24 Aug 2009 11:05:12 +0200 (CEST) Message-Id: <20090824.110512.240734501.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090824084544.GC15710@elstar.local> References: <20090824.102033.118206378.mbj@tail-f.com> <20090824084544.GC15710@elstar.local> 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] bit statement bug 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: Mon, 24 Aug 2009 09:05:04 -0000 Juergen Schoenwaelder wrote: > I agree that the text for enums and bits should be identical. Clever ;) Ok, so the enum text has this: The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. And my proposed bit text has this: The string MUST NOT be empty and MUST NOT contain any whitespace characters. The reason for the latter is that bits are encoded as space separated list of the string values: disable-nagle 10-Mb-only So we can't allow whitespace in the name. So then the question becomes - should we limit enum names to not contain whitespace just so that enums and bits are treated the same? /martin From j.schoenwaelder@jacobs-university.de Mon Aug 24 03:09: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 3BBA03A6E16 for ; Mon, 24 Aug 2009 03:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_20=-0.74, 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 HSBDdHI7l7XW for ; Mon, 24 Aug 2009 03:09: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 D188D3A686C for ; Mon, 24 Aug 2009 03:09:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C217C0025; Mon, 24 Aug 2009 12:09:22 +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 yGmEYFSVGbBT; Mon, 24 Aug 2009 12:09:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95BFCC001A; Mon, 24 Aug 2009 12:09:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2928CC7A487; Mon, 24 Aug 2009 12:09:19 +0200 (CEST) Date: Mon, 24 Aug 2009 12:09:19 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090824100919.GE15936@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20090824.102033.118206378.mbj@tail-f.com> <20090824084544.GC15710@elstar.local> <20090824.110512.240734501.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090824.110512.240734501.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] bit statement bug 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: Mon, 24 Aug 2009 10:09:25 -0000 On Mon, Aug 24, 2009 at 11:05:12AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > I agree that the text for enums and bits should be identical. > > Clever ;) > > Ok, so the enum text has this: > > The string MUST NOT be empty and MUST NOT have any leading or > trailing whitespace characters. > > And my proposed bit text has this: > > The string MUST NOT be empty and MUST NOT contain any whitespace > characters. > > The reason for the latter is that bits are encoded as space separated > list of the string values: > > disable-nagle 10-Mb-only > > So we can't allow whitespace in the name. > > So then the question becomes - should we limit enum names to not > contain whitespace just so that enums and bits are treated the same? I see, there is a technical reason for the difference. I guess for most data model writers it is simpler if there is only one set of rules and for both enums and bits but hardcore no CLR people will surely argue that we have no technical reason to disallow whitespace inside an enum label. I understand both sides but I guess I tend towards making the rules for enums and bits identical. If we make them different, we should perhaps shortly explain why they are different so we easily recall the reason. /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 Mon Aug 24 03:30:19 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 494B43A69AF for ; Mon, 24 Aug 2009 03:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] 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 nlffohUrSk4m for ; Mon, 24 Aug 2009 03:30:18 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id 730233A6A5C for ; Mon, 24 Aug 2009 03:30:18 -0700 (PDT) Received: from [68.142.200.226] by n14.bullet.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 10:30:22 -0000 Received: from [68.142.201.250] by t7.bullet.mud.yahoo.com with NNFMP; 24 Aug 2009 10:30:22 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 10:30:22 -0000 X-Yahoo-Newman-Id: 600875.15280.bm@omp411.mail.mud.yahoo.com Received: (qmail 20764 invoked from network); 24 Aug 2009 10:30:22 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2009 10:30:21 -0000 X-YMail-OSG: G1tLZB8VM1lWKzgmUD.jNel6TbWO.YRi1q0Yzovkab2_j0NaRAnE0RKOJVp7reAWRfV1srvjUlmLrM3LdHC9ZACiLzE0CDsbvBrFy79YCeskcoIdtf_f31.gP811xyS_2X7VPGv89qqsbohbXBn0Unx2MEQX1WeDV6lxvAbI.5BAcjRX2oMcrGAhsmRM3bFwsoyBJyCNB_w3o1L92zd_dXHmaJG2pnf2V4L5Bj4uwBQ8CnlzxytcVLTtSz5jIB7uww-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A926BBF.2050605@netconfcentral.com> Date: Mon, 24 Aug 2009 03:30:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20090824.102033.118206378.mbj@tail-f.com> <20090824084544.GC15710@elstar.local> <20090824.110512.240734501.mbj@tail-f.com> In-Reply-To: <20090824.110512.240734501.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] bit statement bug 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: Mon, 24 Aug 2009 10:30:19 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> I agree that the text for enums and bits should be identical. > > Clever ;) > > Ok, so the enum text has this: > > The string MUST NOT be empty and MUST NOT have any leading or > trailing whitespace characters. > > And my proposed bit text has this: > > The string MUST NOT be empty and MUST NOT contain any whitespace > characters. > > The reason for the latter is that bits are encoded as space separated > list of the string values: > > disable-nagle 10-Mb-only > > So we can't allow whitespace in the name. > > So then the question becomes - should we limit enum names to not > contain whitespace just so that enums and bits are treated the same? > This is not a bug, it is a feature. ;-) We went over this entire issue a year ago (or more). We decided that bit names needed to be valid identifiers. I do not see any compelling reason to change that now. The number of specialized CLRs in YANG is already high enough. This would be yet another variant of a special rule. > > /martin Andy From cfinss@dial.pipex.com Mon Aug 24 03:51: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 537C03A6934 for ; Mon, 24 Aug 2009 03:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001] 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 cWMzN0YaAlHk for ; Mon, 24 Aug 2009 03:51:45 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 609483A686C for ; Mon, 24 Aug 2009 03:51:45 -0700 (PDT) X-Trace: 243876791/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.76/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.76 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: Ap0EALANkko+vGlM/2dsb2JhbACDLUCNK8IOCYQRBQ X-IronPort-AV: E=Sophos;i="4.44,265,1249254000"; d="scan'208";a="243876791" X-IP-Direction: IN Received: from 1cust76.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.76]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Aug 2009 11:51:49 +0100 Message-ID: <000201ca24a0$575165c0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <005401ca2023$51fd9d40$0601a8c0@allison><20090819.085243.113447441.mbj@tail-f.com><001001ca20ee$ade5bc20$0601a8c0@allison> <20090820.214213.147266575.mbj@tail-f.com> Date: Fri, 21 Aug 2009 19:05:18 +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] Terminology2 was Re: leafref problems 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: Mon, 24 Aug 2009 10:51:46 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, August 20, 2009 9:42 PM Subject: Re: Terminology2 was Re: [netmod] leafref problems > "tom.petch" wrote: > > Pro tem., I suggest adding your definition of top-level data node to > > Terminology > > but also adding that sentence from 7.11 to grouping in Terminology. > > Just to make sure I get it right... when you say "that sentence", do > you mean: > > The grouping statement is not a data definition statement and, as > such, does not define any nodes in the schema tree. Martin Yes, I meant add that statement to the definition of grouping in terminology. Tom Petch > > > /martin From cfinss@dial.pipex.com Mon Aug 24 03:51: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 8A0673A686C for ; Mon, 24 Aug 2009 03:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.194, 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 b6m4yzSBPJDR for ; Mon, 24 Aug 2009 03:51:47 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 3F7AC3A6783 for ; Mon, 24 Aug 2009 03:51:47 -0700 (PDT) X-Trace: 243876800/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.76/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.76 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: Ap0EALANkko+vGlM/2dsb2JhbACDLUCNK8IOCYQRBYFR X-IronPort-AV: E=Sophos;i="4.44,265,1249254000"; d="scan'208";a="243876800" X-IP-Direction: IN Received: from 1cust76.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.76]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Aug 2009 11:51:50 +0100 Message-ID: <000301ca24a0$580a0760$0601a8c0@allison> From: "tom.petch" To: "Joel M. Halpern" , "Ladislav Lhotka" References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> Date: Mon, 24 Aug 2009 11:23:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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 Working Group Subject: Re: [netmod] 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: Mon, 24 Aug 2009 10:51:48 -0000 ----- Original Message ----- From: "Joel M. Halpern" To: "Ladislav Lhotka" Cc: "tom.petch" ; "NETMOD Working Group" Sent: Friday, August 21, 2009 4:56 PM > I understand your and Tom's reasoning. > > But that is not what the YANG document says "default" means. The YANG > document says that "[I]f the leaf has a default value, the server MUST > use this value internally if no value is provided by the NETCONF client > when the instance is created." > > Not "SHOULD use". "MUST use". It sure seems to me that if you > implement what you and Tom are asking for, without getting a spec > change, then what you are doing is not what the spec says. And the > application attempting to set things is likely to be very confused > because it can reasonably depend upon the behavior that is called for in > the spec. > > If you argue that the system changing the value from the default is no > different from some other human changing the value, and if you can > persuade the rest of the working group to agree with you, then I would > ask that we remove the sentence in question from the spec, as it is > meaningless. And we instead replace it with something that says what > you think default actually means. > Note, that at least as far as I can tell, there is significant > disagreement with your interpretation. But it is not my call to make. I agree that what I want is not what the spec currently says. What I see as a common use case is not covered. Also, I have a problem with the spec. I see information coming from four sources; device-manufacturer, model-writer (could be SDO), manager-implementer and user, and any one of the four may know best in a given situation, nor do I think we have the skills to prescribe any particular precedence. I expect manufacturers to implement best practice at the time the box is built, but what do they do as best practice (and the SDO-provided data model) moves on? either create non-conformance statements, or ship upgrades to change their values to current best practice. I don't see either as realistic; what we ask for seems, well, unrealistic, and so likely to be ignored. Given that, I think we can find a better use for the default substatement. Tom Petch > Yours, > Joel > > Ladislav Lhotka wrote: > > tom.petch píše v Čt 20. 08. 2009 v 11:43 +0200: > >> ----- Original Message ----- > >> From: "Joel M. Halpern" > >> To: "Ladislav Lhotka" ; "NETMOD Working Group" > >> > >> Sent: Wednesday, August 19, 2009 10:29 PM > >> > >>> If that were what the data model said, then presumably an application > >>> which knew that no one had modified the object (for example, it had jsut > >>> created the object), could reasoanbly assume that the mtu would be 1500, > >>> and does not need to read it to confirm that. > >>> > >>> If that is not the case, then the value in the default statement appears > >>> to be without meaning. > >> Joel > >> > >> The meaning I give it is that the writer of the data model knows best, > >> perhaps because that is the WG in the SDO that developed the > >> protocol and has evolved it over the years. > >> > >> So this is telling the application that unless the user of the application > >> comes up with a better idea, then this is the value that should be > >> set in the device. The manufacturer of the device may have different ideas, > >> which no longer reflect best practice. (Plenty of examples in IPv6 > >> of that). > >> > >> Alternatively, we could say that the manufacturer MUST ship the box > >> with values as per data model, but I prefer the first approach. > > > > Me too. IMO, defaults cannot be enforced. In fact, if the leaf's data > > type permits a certain set of values, it is reasonable to assume that > > none of them is a priori wrong, so why should one value be prescribed? > > > >> Of course, the value in question may be critical to the operation of > >> the box and cannot be omitted but, of course, the leaf cannot be defined > >> as 'mandatory'. > > > > As a matter of fact, with the "explicit" strategy of defaults handling, > > such values are mandatory meaning that they can never be missing in the > > configuration. They are either set explicitly or have the default value. > > > > Lada > > > >> Tom Petch > >> > >>> Yours, > >>> Joel > >>> > >>> Ladislav Lhotka wrote: > >>> ... > >>>> So let me add one more: > >>>> > >>>> E) > >>>> leaf if-mtu { > >>>> type uint32; > >>>> default 1500; > >>>> } > >>>> > >>>> Lada > >>> ... > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod From cfinss@dial.pipex.com Mon Aug 24 03:51: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 6758B3A686C for ; Mon, 24 Aug 2009 03:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, 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 367kbU0r-KxT for ; Mon, 24 Aug 2009 03:51:48 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 653853A6E14 for ; Mon, 24 Aug 2009 03:51:48 -0700 (PDT) X-Trace: 243876830/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.76/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.76 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: Ap0EALANkko+vGlM/2dsb2JhbACDLUCNK8IOCYQRBQ X-IronPort-AV: E=Sophos;i="4.44,265,1249254000"; d="scan'208";a="243876830" X-IP-Direction: IN Received: from 1cust76.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.76]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Aug 2009 11:51:53 +0100 Message-ID: <000401ca24a0$59be6e20$0601a8c0@allison> From: "tom.petch" To: "David Partain" , "NETMOD Working Group" References: <200908211234.59155.david.partain@ericsson.com> Date: Mon, 24 Aug 2009 11: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 Subject: Re: [netmod] Please submit open issues separately 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: Mon, 24 Aug 2009 10:51:49 -0000 ----- Original Message ----- From: "David Partain" To: "NETMOD Working Group" Sent: Friday, August 21, 2009 12:34 PM > > I'm have EXTREME difficulty understanding where people are and even what they > think the issues are. > > As such, I'd like to request the following: If there is an issue that you > think remains unresolved, please send mail to the list with > > (1) a relevant subject stating what the issue is > (2) a pointer to the text in the document that you think has the issue, and > (3) if possible, a suggested textual fix that we can discuss. > > We're all over the place at the moment, which concerns me. I agree. The problem is see is two-fold. On the one hand, our discussions aren't steered to a conclusion, so that going back and re-reading our longer threads, I am unclear what conclusion we reached or if we reached one at all. We do a lot of hard work and then seem to let it slip away at the last. And the number of people speaking up on an issue is small, so that as and when we do reach a consensus, it is fragile, and can be overturned by one person changing their mind. Both of these are process, not technical, issues and my dictum is that there are process solutions to technical issues, but not technical solutions to process issues. Tom Petch > Cheers, > > David > > ps. I hope to submit minutes in the next few hours for your comments. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Mon Aug 24 04:48: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 585923A6E43 for ; Mon, 24 Aug 2009 04:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 CltURo4Z62y6 for ; Mon, 24 Aug 2009 04:48:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2E2433A6DC1 for ; Mon, 24 Aug 2009 04:48:36 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2406FC002A; Mon, 24 Aug 2009 13:48:42 +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 UfcstRusvvk8; Mon, 24 Aug 2009 13:48:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC69DC0025; Mon, 24 Aug 2009 13:48:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 975BBC7ACFF; Mon, 24 Aug 2009 13:48:39 +0200 (CEST) Date: Mon, 24 Aug 2009 13:48:39 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090824114839.GB16365@elstar.local> Mail-Followup-To: "tom.petch" , "Joel M. Halpern" , Ladislav Lhotka , NETMOD Working Group References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000301ca24a0$580a0760$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] 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: Mon, 24 Aug 2009 11:48:37 -0000 On Mon, Aug 24, 2009 at 11:23:17AM +0200, tom.petch wrote: [...] > I don't see either as realistic; what we ask for seems, well, > unrealistic, and so likely to be ignored. Given that, I think we > can find a better use for the default substatement. It is difficult to speculate here. All we know is that DEFVALs have been used quite a bit in SNMP land. Now, the SMIv2 DEFVAL statement was advisory but not a MUST. It would be an exercise to go over all DEFVALs in MIB modules in order to determine which of the DEFVAL uses are actually hard defaults and which ones not. I am sure there are a number of DEFVALs where there is probably no dispute that they should be hard DEFVALs. You want the default statement to have a very different meaning. So we seem to have three proposals on the table: a) A default statement defines a value that MUST be assigned when the manager does not provide a value. b) A default statement defines a value that SHOULD be assigned when the manager does not provide a value. c) A default statement defines a value that can be assumed if config is retrieved with an option to supress defaults. Right now, the YANG specification says a). If my list above is correct, perhaps the chairs can do a concensus call and we move on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Aug 24 04:48: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 5271E3A6E3B for ; Mon, 24 Aug 2009 04:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.837, 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 OBitaFMupNNK for ; Mon, 24 Aug 2009 04:48: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 7C21C3A6E2E for ; Mon, 24 Aug 2009 04:48:50 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 7D17E76C5DE; Mon, 24 Aug 2009 13:48:55 +0200 (CEST) Date: Mon, 24 Aug 2009 13:48:58 +0200 (CEST) Message-Id: <20090824.134858.211095739.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <000301ca24a0$580a0760$0601a8c0@allison> References: <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$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] 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: Mon, 24 Aug 2009 11:48:51 -0000 "tom.petch" wrote: > I agree that what I want is not what the spec currently says. What I see as > a common use case is not covered. It seems you are saying that you don't think the current default statement is very useful. If this is a correct interpretation, I can respect that, but at the same time I would like to know if you see any technical problems with the current text? > Also, I have a problem with the spec. I see information coming from four > sources; device-manufacturer, model-writer (could be SDO), manager-implementer > and user, and any one of the four may know best in a given situation, nor do > I think we have the skills to prescribe any particular precedence. > > I expect manufacturers to implement best practice at the time the box is > built, but what do they do as best practice (and the SDO-provided data model) > moves on? either create non-conformance statements, or ship upgrades to change > their values to current best practice. > > I don't see either as realistic; what we ask for seems, well, unrealistic, and > so > likely to be ignored. Given that, I think we can find a better use for the > default substatement. Given the discussions we have had about this, and that we don't have a concrete proposal to discuss, shouldn't this wait? /martin From lhotka@cesnet.cz Mon Aug 24 05:22: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 AA0FC28C0E6 for ; Mon, 24 Aug 2009 05:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 Z3FNGmfTLZ-9 for ; Mon, 24 Aug 2009 05:22:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B18963A659C for ; Mon, 24 Aug 2009 05:22:25 -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 37DD6D800C0; Mon, 24 Aug 2009 14:22:31 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090824114839.GB16365@elstar.local> References: <20090819080201.GD6741@elstar.local> <4A8C0E62.9090609@joelhalpern.com> <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> <20090824114839.GB16365@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 14:22:29 +0200 Message-Id: <1251116549.7051.60.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 12:22:26 -0000 Juergen Schoenwaelder píše v Po 24. 08. 2009 v 13:48 +0200: > On Mon, Aug 24, 2009 at 11:23:17AM +0200, tom.petch wrote: > > [...] > > > I don't see either as realistic; what we ask for seems, well, > > unrealistic, and so likely to be ignored. Given that, I think we > > can find a better use for the default substatement. > > It is difficult to speculate here. All we know is that DEFVALs have > been used quite a bit in SNMP land. Now, the SMIv2 DEFVAL statement > was advisory but not a MUST. It would be an exercise to go over all > DEFVALs in MIB modules in order to determine which of the DEFVAL uses > are actually hard defaults and which ones not. I am sure there are a > number of DEFVALs where there is probably no dispute that they should > be hard DEFVALs. If the default is only advisory, it is not a big issue if different implementors interpret the default statement differently since a reasonable manager should always check that the default value is really in the expected place. A MUST requires a precise specification, otherwise interoperability problems are much more likely than in the advisory case. Lada > > You want the default statement to have a very different meaning. So we > seem to have three proposals on the table: > > a) A default statement defines a value that MUST be assigned when the > manager does not provide a value. > > b) A default statement defines a value that SHOULD be assigned when > the manager does not provide a value. > > c) A default statement defines a value that can be assumed if config > is retrieved with an option to supress defaults. > > Right now, the YANG specification says a). If my list above is > correct, perhaps the chairs can do a concensus call and we move on. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 24 05:32: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 42D3528C1C1 for ; Mon, 24 Aug 2009 05:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_05=-1.11, 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 MNGTEBBjwb-V for ; Mon, 24 Aug 2009 05:32:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1CDDF28C1BE for ; Mon, 24 Aug 2009 05:32:23 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2A48C002A; Mon, 24 Aug 2009 14:32:28 +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 7XvTJSfVnSvH; Mon, 24 Aug 2009 14:32:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4778C001A; Mon, 24 Aug 2009 14:32:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 83F39C7B057; Mon, 24 Aug 2009 14:32:26 +0200 (CEST) Date: Mon, 24 Aug 2009 14:32:26 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090824123226.GA16957@elstar.local> Mail-Followup-To: Ladislav Lhotka , "tom.petch" , "Joel M. Halpern" , NETMOD Working Group References: <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> <20090824114839.GB16365@elstar.local> <1251116549.7051.60.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1251116549.7051.60.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] 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: Mon, 24 Aug 2009 12:32:24 -0000 On Mon, Aug 24, 2009 at 02:22:29PM +0200, Ladislav Lhotka wrote: > If the default is only advisory, it is not a big issue if different > implementors interpret the default statement differently since a > reasonable manager should always check that the default value is really > in the expected place. Which means the default statement is pretty pointless. It is easier to simply send the default value in this case instead of checking what got assigned and fixing things. > A MUST requires a precise specification, otherwise interoperability > problems are much more likely than in the advisory case. The default clause is IMHO as precise as you can make it. Not sure what is lacking. Perhaps you can post suggested text so I can better understand. Note that implementors can use a deviation to handle the case where they choose to not comply to the specification. So a manager needs to be able to parse deviations to understand the support implemented on the device. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Aug 24 05:55: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 DCFDA3A6DD2 for ; Mon, 24 Aug 2009 05:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=0.078, 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 ne-qtMz+O9ob for ; Mon, 24 Aug 2009 05:55:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D3BD93A6DB5 for ; Mon, 24 Aug 2009 05:55:54 -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 BE305D800C8; Mon, 24 Aug 2009 14:56:00 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090824123226.GA16957@elstar.local> References: <4A8C2533.7020909@netconfcentral.com> <20090819.184137.195313323.mbj@tail-f.com> <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> <20090824114839.GB16365@elstar.local> <1251116549.7051.60.camel@missotis> <20090824123226.GA16957@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 14:55:58 +0200 Message-Id: <1251118558.7051.81.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 12:55:55 -0000 Juergen Schoenwaelder píše v Po 24. 08. 2009 v 14:32 +0200: > On Mon, Aug 24, 2009 at 02:22:29PM +0200, Ladislav Lhotka wrote: > > > If the default is only advisory, it is not a big issue if different > > implementors interpret the default statement differently since a > > reasonable manager should always check that the default value is really > > in the expected place. > > Which means the default statement is pretty pointless. It is easier to > simply send the default value in this case instead of checking what > got assigned and fixing things. We are in a perfect agreement here. > > > A MUST requires a precise specification, otherwise interoperability > > problems are much more likely than in the advisory case. > > The default clause is IMHO as precise as you can make it. Not sure > what is lacking. Perhaps you can post suggested text so I can better > understand. I sent an alternative formulation earlier today in this thread but I suspect it will be found too weak. Given the differences in datastore models, possible interactions of operational and configuration parameters etc., it is really difficult to tell what the implications of the default statement are. For example, with the following module: module foo { namespace "http://example.org/foo"; prefix foo; leaf bar { type uint8; default 42; } } Now, if I unwrap the device implementing this module and start the first NETCONF session, what can I rely on regarding the value of "bar", if anything at all? Lada > > Note that implementors can use a deviation to handle the case where > they choose to not comply to the specification. So a manager needs to > be able to parse deviations to understand the support implemented on > the device. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Aug 24 06:04:59 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 195C63A6BE4 for ; Mon, 24 Aug 2009 06:04:59 -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 P+6yeKssxiUW for ; Mon, 24 Aug 2009 06:04:58 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id D02B93A69E5 for ; Mon, 24 Aug 2009 06:04:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSpKP+41MKeKupbNWLsmS24nb0UosWOM1@postini.com; Mon, 24 Aug 2009 06:05:04 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; Mon, 24 Aug 2009 06:00:15 -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); Mon, 24 Aug 2009 06:00:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:00:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:00:13 -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 n7OD07d57735; Mon, 24 Aug 2009 06:00:12 -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 n7OCmArp091168; Mon, 24 Aug 2009 12:48:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908241248.n7OCmArp091168@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090824114839.GB16365@elstar.local> Date: Mon, 24 Aug 2009 08:48:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Aug 2009 13:00:13.0868 (UTC) FILETIME=[D1F7DEC0:01CA24BA] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 13:04:59 -0000 Juergen Schoenwaelder writes: >a) A default statement defines a value that MUST be assigned when the > manager does not provide a value. > >b) A default statement defines a value that SHOULD be assigned when > the manager does not provide a value. > >c) A default statement defines a value that can be assumed if config > is retrieved with an option to supress defaults. > >Right now, the YANG specification says a). If my list above is >correct, perhaps the chairs can do a concensus call and we move on. I disagree with the words "be assigned" in (a). The current spec says something between (a) if "be assigned" were changed to "be used internally" and (c) with no mention of the "suppress defaults" option. If a leaf has a "default" statement, the leaf's default value is set to 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 set to the type's default value. In all other cases, the leaf does not have a default value. If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. I think Lada's "behave as if" words are much more descriptive than "use internally". Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Aug 24 06:05: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 8E2AE3A6AFF for ; Mon, 24 Aug 2009 06:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_05=-1.11, 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 y9xUYEfobkMs for ; Mon, 24 Aug 2009 06:05:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 69A873A69E5 for ; Mon, 24 Aug 2009 06:05:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 610C4C001A; Mon, 24 Aug 2009 15:05:40 +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 PmTMN2yIFdZ5; Mon, 24 Aug 2009 15:05:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E728C000D; Mon, 24 Aug 2009 15:05:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DF93BC7B1ED; Mon, 24 Aug 2009 15:05:37 +0200 (CEST) Date: Mon, 24 Aug 2009 15:05:37 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090824130537.GA17038@elstar.local> Mail-Followup-To: Ladislav Lhotka , "tom.petch" , "Joel M. Halpern" , NETMOD Working Group References: <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> <20090824114839.GB16365@elstar.local> <1251116549.7051.60.camel@missotis> <20090824123226.GA16957@elstar.local> <1251118558.7051.81.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1251118558.7051.81.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] 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: Mon, 24 Aug 2009 13:05:35 -0000 On Mon, Aug 24, 2009 at 02:55:58PM +0200, Ladislav Lhotka wrote: > For example, with the following module: > > module foo { > namespace "http://example.org/foo"; > prefix foo; > leaf bar { > type uint8; > default 42; > } > } > > Now, if I unwrap the device implementing this module and start the first > NETCONF session, what can I rely on regarding the value of "bar", if > anything at all? Unless there are other semantics in description statements, there will be no instance. According to 7.6, default values become relevant "when the instance is created" and "no value is provided by the NETCONF client". Since the only way to create this instance is by writing a value, the default statement is somewhat pointless - unless there are other semantics that can lead to the instantiation of "bar" without writing an explicit value (so I think it is not wrong to allow for this example). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 24 06:12: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 C785028C1C3 for ; Mon, 24 Aug 2009 06:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 U5nbtt38GCYa for ; Mon, 24 Aug 2009 06:12:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 962CA3A6892 for ; Mon, 24 Aug 2009 06:12:33 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8AB81C0016; Mon, 24 Aug 2009 15:12:39 +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 fm-XO9FfCw0m; Mon, 24 Aug 2009 15:12:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A538EC001A; Mon, 24 Aug 2009 15:12:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5B1E2C7B3CA; Mon, 24 Aug 2009 15:12:37 +0200 (CEST) Date: Mon, 24 Aug 2009 15:12:37 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090824131237.GA17105@elstar.local> Mail-Followup-To: Phil Shafer , "tom.petch" , NETMOD Working Group References: <20090824114839.GB16365@elstar.local> <200908241248.n7OCmArp091168@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908241248.n7OCmArp091168@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] 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: Mon, 24 Aug 2009 13:12:34 -0000 On Mon, Aug 24, 2009 at 02:48:10PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >a) A default statement defines a value that MUST be assigned when the > > manager does not provide a value. > > > >b) A default statement defines a value that SHOULD be assigned when > > the manager does not provide a value. > > > >c) A default statement defines a value that can be assumed if config > > is retrieved with an option to supress defaults. > > > >Right now, the YANG specification says a). If my list above is > >correct, perhaps the chairs can do a concensus call and we move on. > > I disagree with the words "be assigned" in (a). The current spec > says something between (a) if "be assigned" were changed to "be > used internally" and (c) with no mention of the "suppress defaults" > option. > > If a leaf has a "default" statement, the leaf's default value is set > to 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 set to the type's default value. In all other > cases, the leaf does not have a default value. > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. > > I think Lada's "behave as if" words are much more descriptive than > "use internally". I agree; sorry for the sloppy wording. But we need to put this discussion somehow to an end. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon Aug 24 06:25: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 CC69A3A68F0 for ; Mon, 24 Aug 2009 06:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=0.076, 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 qDuGjF02H6x5 for ; Mon, 24 Aug 2009 06:25:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DA7D13A6852 for ; Mon, 24 Aug 2009 06:25:43 -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 C2401D80096; Mon, 24 Aug 2009 15:25:49 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20090824130537.GA17038@elstar.local> References: <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> <20090824114839.GB16365@elstar.local> <1251116549.7051.60.camel@missotis> <20090824123226.GA16957@elstar.local> <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 15:25:48 +0200 Message-Id: <1251120348.7051.100.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 13:25:44 -0000 Juergen Schoenwaelder píše v Po 24. 08. 2009 v 15:05 +0200: > On Mon, Aug 24, 2009 at 02:55:58PM +0200, Ladislav Lhotka wrote: > > > For example, with the following module: > > > > module foo { > > namespace "http://example.org/foo"; > > prefix foo; > > leaf bar { > > type uint8; > > default 42; > > } > > } > > > > Now, if I unwrap the device implementing this module and start the first > > NETCONF session, what can I rely on regarding the value of "bar", if > > anything at all? > > Unless there are other semantics in description statements, there will > be no instance. But what about running report-all ? > > According to 7.6, default values become relevant "when the instance is > created" and "no value is provided by the NETCONF client". > > Since the only way to create this instance is by writing a value, the > default statement is somewhat pointless - unless there are other > semantics that can lead to the instantiation of "bar" without writing > an explicit value (so I think it is not wrong to allow for this > example). Right, so let's expand it a bit: module foo { namespace "http://example.org/foo"; prefix foo; container wrap { presence "I mean something"; leaf bar { type uint8; default 42; } } Does the default statement then mean that the following two operations are equivalent (and nothing else)? running 42 running Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From per@tail-f.com Mon Aug 24 06:37: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 E76733A6914 for ; Mon, 24 Aug 2009 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 zHFPW8Dqk+yM for ; Mon, 24 Aug 2009 06:37:24 -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 C5E203A6852 for ; Mon, 24 Aug 2009 06:37:23 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B901576C5A3; Mon, 24 Aug 2009 15:37:28 +0200 (CEST) Message-ID: <4A929798.6040807@tail-f.com> Date: Mon, 24 Aug 2009 15:37:28 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Phil Shafer References: <200908241248.n7OCmArp091168@idle.juniper.net> In-Reply-To: <200908241248.n7OCmArp091168@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 13:37:25 -0000 On 2009-08-24 14:48, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> a) A default statement defines a value that MUST be assigned when the >> manager does not provide a value. >> >> b) A default statement defines a value that SHOULD be assigned when >> the manager does not provide a value. >> >> c) A default statement defines a value that can be assumed if config >> is retrieved with an option to supress defaults. >> >> Right now, the YANG specification says a). If my list above is >> correct, perhaps the chairs can do a concensus call and we move on. > > I disagree with the words "be assigned" in (a). The current spec > says something between (a) if "be assigned" were changed to "be > used internally" and (c) with no mention of the "suppress defaults" > option. > > If a leaf has a "default" statement, the leaf's default value is set > to 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 set to the type's default value. In all other > cases, the leaf does not have a default value. > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. > > I think Lada's "behave as if" words are much more descriptive than > "use internally". Well, the text Lada suggested, unless I have missed some message, was: "An edit-config operation that creates the instance but does not provide a value for such a leaf MUST have the same effect as if the default value for that leaf was explicitly specified." I think this is not acceptable, since "the same effect" would mean that it *was* actually "assigned". The description needs to capture that the device must function as if that value had been assigned, even though it hasn't actually been - i.e. it cannot imply that the value should be assigned in the data store. "behave as if" may be better than "use internally", but it would have to be qualified as to which behavior it is talking about - personally I'm fine with "use internally", since it is free from implications about data store contents. --Per Hedeland From j.schoenwaelder@jacobs-university.de Mon Aug 24 06:42: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 A55CB3A6E0A for ; Mon, 24 Aug 2009 06:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_20=-0.74, 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 OzsKBriqmDlg for ; Mon, 24 Aug 2009 06:42:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9C3923A6E03 for ; Mon, 24 Aug 2009 06:42:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37D83C0016; Mon, 24 Aug 2009 15:42:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TjBh+HtJV7hV; Mon, 24 Aug 2009 15:42:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11D9FC000D; Mon, 24 Aug 2009 15:42:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CD399C7B496; Mon, 24 Aug 2009 15:42:50 +0200 (CEST) Date: Mon, 24 Aug 2009 15:42:50 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20090824134250.GA17319@elstar.local> Mail-Followup-To: Ladislav Lhotka , "tom.petch" , "Joel M. Halpern" , NETMOD Working Group References: <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> <20090824114839.GB16365@elstar.local> <1251116549.7051.60.camel@missotis> <20090824123226.GA16957@elstar.local> <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1251120348.7051.100.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] 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: Mon, 24 Aug 2009 13:43:00 -0000 On Mon, Aug 24, 2009 at 03:25:48PM +0200, Ladislav Lhotka wrote: > Right, so let's expand it a bit: > > module foo { > namespace "http://example.org/foo"; > prefix foo; > container wrap { > presence "I mean something"; > leaf bar { > type uint8; > default 42; > } > } > > Does the default statement then mean that the following two operations > are equivalent (and nothing else)? > > > > running > > > 42 > > > > > > running > > > > The answer likely depends on how you define "equivalent". In terms of the behaviour of the device, they are equivalent. The presence property of wrap does not change anything related to the instantiation of bar as far as I understand things. My preferred model, as stated before, is the one where the server makes a distinction between config values that have been explicitely set and values that are operationally used but not explicitely configured and thus not part of a configuration datastore. So in both cases, according to my model, the box is going to use the value 42 if it needs a value for bar and hence the behaviour of the device should be the same in both cases. The first edit-config, however, makes the value 42 explicit 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 mbj@tail-f.com Mon Aug 24 06:46: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 D15233A68F0 for ; Mon, 24 Aug 2009 06:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.052, 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 w1Vpl348T1zr for ; Mon, 24 Aug 2009 06:46: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 F3AE43A692A for ; Mon, 24 Aug 2009 06:46: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 C85CC76C5DE; Mon, 24 Aug 2009 15:46:21 +0200 (CEST) Date: Mon, 24 Aug 2009 15:46:21 +0200 (CEST) Message-Id: <20090824.154621.47873687.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251120348.7051.100.camel@missotis> References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.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=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: Mon, 24 Aug 2009 13:46:16 -0000 Ladislav Lhotka wrote: > Right, so let's expand it a bit: > > module foo { > namespace "http://example.org/foo"; > prefix foo; > container wrap { > presence "I mean something"; > leaf bar { > type uint8; > default 42; > } > } > > Does the default statement then mean that the following two operations > are equivalent (and nothing else)? > > > > running > > > 42 > > > > > > running > > > > The behavior of the application in the server will be equivalent, but the difference is that in the first example, /wrap/bar exists in the config data store with a value of 42. In the second example, /wrap/bar does not exist in the data store. /martin From phil@juniper.net Mon Aug 24 06:47: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 A7B7B3A68F0 for ; Mon, 24 Aug 2009 06:47:40 -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 JMLOPJ33vZyZ for ; Mon, 24 Aug 2009 06:47:40 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id B67753A6E0C for ; Mon, 24 Aug 2009 06:47:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSpKZ+8HUS4ufPTD4PnHsoGV62nQQktmu@postini.com; Mon, 24 Aug 2009 06:47:46 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; Mon, 24 Aug 2009 06:43:58 -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); Mon, 24 Aug 2009 06:43:58 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:43:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:43:57 -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 n7ODhvd78138; Mon, 24 Aug 2009 06:43:57 -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 n7ODW1uh091464; Mon, 24 Aug 2009 13:32:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908241332.n7ODW1uh091464@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251118558.7051.81.camel@missotis> Date: Mon, 24 Aug 2009 09:32:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Aug 2009 13:43:57.0815 (UTC) FILETIME=[EDF66870:01CA24C0] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 13:47:40 -0000 Ladislav Lhotka writes: >We are in a perfect agreement here. But you are in disagreement with what operators want. There's an understandable difference between what applications want and what human users want, and IMHO NETCONF/YANG cannot succeed if they achieve programmatic access at the cost of human access. In particular, the human wants configuration to be brief, simple, and readable. They want to find the important bits, with the asssumption that making these bits more obvious means a simpler time finding and correcting errors. Populating a real config with default values is a non-starter. Given that we want to be better than existing schema langauges, are there any examples of existing schema langauges that _don't_ have the concept of default values? Thanks, Phil From phil@juniper.net Mon Aug 24 06:48: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 B3CAB3A67D8 for ; Mon, 24 Aug 2009 06:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 ZT0n+4SxIlcE for ; Mon, 24 Aug 2009 06:48:52 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 2987E3A68F0 for ; Mon, 24 Aug 2009 06:48:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSpKaRvt/c7EdE97YM7RMWH5VSvLW4wQL@postini.com; Mon, 24 Aug 2009 06:48: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; Mon, 24 Aug 2009 06:45:06 -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); Mon, 24 Aug 2009 06:45:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:45:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:45:04 -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 n7ODj2d78575; Mon, 24 Aug 2009 06:45:03 -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 n7ODX6KL091523; Mon, 24 Aug 2009 13:33:06 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908241333.n7ODX6KL091523@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090824131237.GA17105@elstar.local> Date: Mon, 24 Aug 2009 09:33:06 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Aug 2009 13:45:04.0594 (UTC) FILETIME=[15C41320:01CA24C1] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 13:48:52 -0000 Juergen Schoenwaelder writes: >we need to put this >discussion somehow to an end. +1 Thanks, Phil From phil@juniper.net Mon Aug 24 06:52: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 7EC2A28C0F2 for ; Mon, 24 Aug 2009 06:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 hDQbzaOPe7TM for ; Mon, 24 Aug 2009 06:52:50 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id F13213A6E28 for ; Mon, 24 Aug 2009 06:52:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSpKbNsp7cIQA45HPaKnvzRzF4jamYi9w@postini.com; Mon, 24 Aug 2009 06:52:57 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; Mon, 24 Aug 2009 06:49:22 -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); Mon, 24 Aug 2009 06:49:22 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:49:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:49:20 -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 n7ODnKd80886; Mon, 24 Aug 2009 06:49: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 n7ODbN4e091573; Mon, 24 Aug 2009 13:37:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908241337.n7ODbN4e091573@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251100827.7051.24.camel@missotis> Date: Mon, 24 Aug 2009 09:37:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Aug 2009 13:49:20.0664 (UTC) FILETIME=[AE654180:01CA24C1] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] agent-default -- new 3rd state 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: Mon, 24 Aug 2009 13:52:51 -0000 Ladislav Lhotka writes: >But neither this nor the original sentence covers the case where no >NETCONF client/operation is involved, i.e. when the instance is a part >of the initial configuration or is created automatically after a new >piece of hardware is plugged in. Are there any assumptions for these >cases? The assumption is that running is always valid, so if any client of any mechanism changes the contents of running, it must be left in a valid state. Otherwise, the contract implied by the YANG module is not being followed. Thanks, Phil From lhotka@cesnet.cz Mon Aug 24 06:56: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 EB0A33A6E2C for ; Mon, 24 Aug 2009 06:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.075, 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 fGnudC0IMUSs for ; Mon, 24 Aug 2009 06:56:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 17F273A6A5C for ; Mon, 24 Aug 2009 06:56:57 -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 1258AD80095; Mon, 24 Aug 2009 15:57:03 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090824.154621.47873687.mbj@tail-f.com> References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.154621.47873687.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 15:57:01 +0200 Message-Id: <1251122221.7051.110.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 13:56:58 -0000 Martin Bjorklund píše v Po 24. 08. 2009 v 15:46 +0200: > Ladislav Lhotka wrote: > > Right, so let's expand it a bit: > > > > module foo { > > namespace "http://example.org/foo"; > > prefix foo; > > container wrap { > > presence "I mean something"; > > leaf bar { > > type uint8; > > default 42; > > } > > } > > > > Does the default statement then mean that the following two operations > > are equivalent (and nothing else)? > > > > > > > > running > > > > > > 42 > > > > > > > > > > > > running > > > > > > > > > > The behavior of the application in the server will be equivalent, but > the difference is that in the first example, /wrap/bar exists in the > config data store with a value of 42. In the second example, > /wrap/bar does not exist in the data store. This again depends on the datastore model. But in any case, an immediate get-config with with-defaults set to "report-all" must return the same output, right? What's the answer to the first question in my previous mail? Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Aug 24 07:02:19 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 077C828C1BD for ; Mon, 24 Aug 2009 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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 KtOPHJebHxk7 for ; Mon, 24 Aug 2009 07:02:18 -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 AEBFB3A6E5A for ; Mon, 24 Aug 2009 07:02:16 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 580F476C5A3; Mon, 24 Aug 2009 16:02:22 +0200 (CEST) Date: Mon, 24 Aug 2009 16:02:22 +0200 (CEST) Message-Id: <20090824.160222.40416871.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251100827.7051.24.camel@missotis> References: <200908211516.n7LFGpwX073580@idle.juniper.net> <1251100827.7051.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] agent-default -- new 3rd state 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: Mon, 24 Aug 2009 14:02:19 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gUGhpbCBTaGFmZXIg cMOtxaFlIHYgUMOhIDIxLiAwOC4gMjAwOSB2IDExOjE2IC0wNDAwOg0KPiA+IExhZGlzbGF2IExo b3RrYSB3cml0ZXM6DQo+ID4gPj4gICAgIElmIHRoZSBsZWFmIGhhcyBhIGRlZmF1bHQgdmFsdWUs IHRoZSBzZXJ2ZXIgTVVTVCB1c2UgdGhpcyB2YWx1ZQ0KPiA+ID4+ICAgICBpbnRlcm5hbGx5IGlm IG5vIHZhbHVlIGlzIHByb3ZpZGVkIGJ5IHRoZSBORVRDT05GIGNsaWVudCB3aGVuDQo+ID4gPj4g ICAgIHRoZSBpbnN0YW5jZSBpcyBjcmVhdGVkLg0KPiA+ID4NCj4gPiA+V2hhdCBkb2VzICJ1c2Ug aW50ZXJuYWxseSIgbWVhbj8NCj4gPiANCj4gPiBBcmUgeW91IHRydWx5IG5vdCBmb2xsb3dpbmcs IG9yIGp1c3Qgd2FudGluZyBiZXR0ZXIgd29yZHM/DQo+IA0KPiBCb3RoLiBDb3VsZCBpdCBiZSBy ZWZvcm11bGF0ZWQgbGlrZSB0aGlzPw0KPiANCj4gICAgICJBbiBlZGl0LWNvbmZpZyBvcGVyYXRp b24gdGhhdCBjcmVhdGVzIHRoZSBpbnN0YW5jZSBidXQgZG9lcyBub3QgDQo+ICAgICAgcHJvdmlk ZSBhIHZhbHVlIGZvciBzdWNoIGEgbGVhZiBNVVNUIGhhdmUgdGhlIHNhbWUgZWZmZWN0IGFzIGlm DQo+ICAgICAgdGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoYXQgbGVhZiB3YXMgZXhwbGljaXRseSBz cGVjaWZpZWQuIg0KDQonZGVmYXVsdCcgYWZmZWN0cyBub3Qgb25seSBlZGl0LWNvbmZpZywgYnV0 IG90aGVyIG9wZXJhdGlvbnMgYW5kIHJwYw0KcGFyYW1ldGVycyBhcyB3ZWxsLg0KDQpBbmQgd2hh dCB5b3Ugc2F5IGhlcmUgaXMgbm90IGNvbXBsZXRlbHkgY29ycmVjdCAtIGl0IGRvZXMgbm90IGhh dmUNCiJ0aGUgc2FtZSBlZmZlY3QiIG9uIHRoZSBkYXRhIHN0b3JlLCBidXQgaXQgZG9lcyBoYXZl IHRoZSBzYW1lIGVmZmVjdA0Kb24gdGhlICJtYW5hZ2VkIGFwcGxpY2F0aW9uIi4NCg0KDQovbWFy dGluDQo= From mbj@tail-f.com Mon Aug 24 07:04:59 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 30C0D3A6E59 for ; Mon, 24 Aug 2009 07:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.048, 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 LhzRbvr4E+xD for ; Mon, 24 Aug 2009 07:04:58 -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 1FDDB28C210 for ; Mon, 24 Aug 2009 07:04:10 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 06D6A76C5A3; Mon, 24 Aug 2009 16:04:16 +0200 (CEST) Date: Mon, 24 Aug 2009 16:04:15 +0200 (CEST) Message-Id: <20090824.160415.74934092.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251120348.7051.100.camel@missotis> References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.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] 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: Mon, 24 Aug 2009 14:04:59 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyIHDDrcWhZSB2IFBvIDI0LiAwOC4gMjAwOSB2IDE1OjA1ICswMjAwOg0KPiA+IE9u IE1vbiwgQXVnIDI0LCAyMDA5IGF0IDAyOjU1OjU4UE0gKzAyMDAsIExhZGlzbGF2IExob3RrYSB3 cm90ZToNCj4gPiAgDQo+ID4gPiBGb3IgZXhhbXBsZSwgd2l0aCB0aGUgZm9sbG93aW5nIG1vZHVs ZToNCj4gPiA+IA0KPiA+ID4gbW9kdWxlIGZvbyB7DQo+ID4gPiAgICAgbmFtZXNwYWNlICJodHRw Oi8vZXhhbXBsZS5vcmcvZm9vIjsNCj4gPiA+ICAgICBwcmVmaXggZm9vOw0KPiA+ID4gICAgIGxl YWYgYmFyIHsNCj4gPiA+ICAgICAgICAgdHlwZSB1aW50ODsNCj4gPiA+ICAgICAgICAgZGVmYXVs dCA0MjsNCj4gPiA+ICAgICB9DQo+ID4gPiB9DQo+ID4gPiANCj4gPiA+IE5vdywgaWYgSSB1bndy YXAgdGhlIGRldmljZSBpbXBsZW1lbnRpbmcgdGhpcyBtb2R1bGUgYW5kIHN0YXJ0IHRoZSBmaXJz dA0KPiA+ID4gTkVUQ09ORiBzZXNzaW9uLCB3aGF0IGNhbiBJIHJlbHkgb24gcmVnYXJkaW5nIHRo ZSB2YWx1ZSBvZiAiYmFyIiwgaWYNCj4gPiA+IGFueXRoaW5nIGF0IGFsbD8NCj4gPiANCj4gPiBV bmxlc3MgdGhlcmUgYXJlIG90aGVyIHNlbWFudGljcyBpbiBkZXNjcmlwdGlvbiBzdGF0ZW1lbnRz LCB0aGVyZSB3aWxsDQo+ID4gYmUgbm8gPGJhcj4gaW5zdGFuY2UuDQo+IA0KPiBCdXQgd2hhdCBh Ym91dA0KPiANCj4gPG5jOmdldC1jb25maWc+DQo+ICAgPG5jOnNvdXJjZT5ydW5uaW5nPC9uYzpz b3VyY2U+DQo+ICAgPG53ZDp3aXRoLWRlZmF1bHRzPnJlcG9ydC1hbGw8L253ZDp3aXRoLWRlZmF1 bHRzPg0KPiA8L25jOmdldC1jb25maWc+DQo+IA0KPiA/DQoNCkluIHRoaXMgY2FzZSB5b3Ugd2ls bCBnZXQgPGJhcj4gd2l0aCB0aGUgdmFsdWUgNDIgaW4gdGhlIHJlcGx5Lg0KDQoNCi9tYXJ0aW4N Cg== From per@tail-f.com Mon Aug 24 07:06: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 BBA493A6E03 for ; Mon, 24 Aug 2009 07:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 oq3dbE6qBSZx for ; Mon, 24 Aug 2009 07:06:53 -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 CE8183A6E4F for ; Mon, 24 Aug 2009 07:06:52 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C2DB776C5A3; Mon, 24 Aug 2009 16:06:58 +0200 (CEST) Message-ID: <4A929E82.7010709@tail-f.com> Date: Mon, 24 Aug 2009 16:06:58 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Ladislav Lhotka References: <1250713281.24768.242.camel@missotis> <4A8C609E.1060804@joelhalpern.com> <001301ca21b6$f24a4ac0$0601a8c0@allison> <1250865485.3702.21.camel@missotis> <4A8EB599.4040207@joelhalpern.com> <000301ca24a0$580a0760$0601a8c0@allison> <20090824114839.GB16365@elstar.local> <1251116549.7051.60.camel@missotis> <20090824123226.GA16957@elstar.local> <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> In-Reply-To: <1251120348.7051.100.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 14:06:53 -0000 On 2009-08-24 15:25, Ladislav Lhotka wrote: > Juergen Schoenwaelder píae v Po 24. 08. 2009 v 15:05 +0200: >> On Mon, Aug 24, 2009 at 02:55:58PM +0200, Ladislav Lhotka wrote: >> >>> For example, with the following module: >>> >>> module foo { >>> namespace "http://example.org/foo"; >>> prefix foo; >>> leaf bar { >>> type uint8; >>> default 42; >>> } >>> } >>> >>> Now, if I unwrap the device implementing this module and start the first >>> NETCONF session, what can I rely on regarding the value of "bar", if >>> anything at all? Hm, I thought that it had finally been established that a device can have configuration before the first NETCONF session is started - e.g. preloaded before delivery (a.k.a. "factory default", where "default" of course has a very different meaning than the Yang default-statement) and/or via an initial CLI setup session. As far as I can see, such an initial configuration can be anything - a Yang data model has no way to specify restrictions on it beyond that it must be valid, and this seems perfectly reasonable to me. I also don't really see the problem - why would a NETCONF client need or want to treat a "freshly unwrapped" device any different than one that has been in service for a while (maybe in another network so it's "new" in its current deployment)? So, my answer would be "nothing at all". >> Unless there are other semantics in description statements, there will >> be no instance. Which should mean that if there is some part of the device's operation that is dependent on the value of , it should use the default value - shouldn't it? > But what about > > > running > report-all > If there is no instance, it should return 42. >> According to 7.6, default values become relevant "when the instance is >> created" and "no value is provided by the NETCONF client". Actually I think this text is not so good - "the instance" seems to refer to the leaf with the default value, but the "you can only create it by assigning a value to it" is always true for such a leaf. As in: > > running > > > > This creates the container, but it doesn't create the leaf within it - yet the consensus (+1) is that the default value of must now "be in effect". IMO, once is created, this is exactly the same case as a toplevel with a default value. --Per Hedeland From mbj@tail-f.com Mon Aug 24 07:18:03 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 BFF9828C1EA for ; Mon, 24 Aug 2009 07:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.047, 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 37GO1-evEe6x for ; Mon, 24 Aug 2009 07:18:03 -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 F015228C1D1 for ; Mon, 24 Aug 2009 07:18: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 CF5BC76C5A3; Mon, 24 Aug 2009 16:18:08 +0200 (CEST) Date: Mon, 24 Aug 2009 16:18:06 +0200 (CEST) Message-Id: <20090824.161806.165545117.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <20090824.160415.74934092.mbj@tail-f.com> References: <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.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=utf-8 Content-Transfer-Encoding: base64 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: Mon, 24 Aug 2009 14:18:03 -0000 TWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KPiBMYWRpc2xhdiBMaG90 a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBw w63FoWUgdiBQbyAyNC4gMDguIDIwMDkgdiAxNTowNSArMDIwMDoNCj4gPiA+IE9uIE1vbiwgQXVn IDI0LCAyMDA5IGF0IDAyOjU1OjU4UE0gKzAyMDAsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4g PiA+ICANCj4gPiA+ID4gRm9yIGV4YW1wbGUsIHdpdGggdGhlIGZvbGxvd2luZyBtb2R1bGU6DQo+ ID4gPiA+IA0KPiA+ID4gPiBtb2R1bGUgZm9vIHsNCj4gPiA+ID4gICAgIG5hbWVzcGFjZSAiaHR0 cDovL2V4YW1wbGUub3JnL2ZvbyI7DQo+ID4gPiA+ICAgICBwcmVmaXggZm9vOw0KPiA+ID4gPiAg ICAgbGVhZiBiYXIgew0KPiA+ID4gPiAgICAgICAgIHR5cGUgdWludDg7DQo+ID4gPiA+ICAgICAg ICAgZGVmYXVsdCA0MjsNCj4gPiA+ID4gICAgIH0NCj4gPiA+ID4gfQ0KPiA+ID4gPiANCj4gPiA+ ID4gTm93LCBpZiBJIHVud3JhcCB0aGUgZGV2aWNlIGltcGxlbWVudGluZyB0aGlzIG1vZHVsZSBh bmQgc3RhcnQgdGhlIGZpcnN0DQo+ID4gPiA+IE5FVENPTkYgc2Vzc2lvbiwgd2hhdCBjYW4gSSBy ZWx5IG9uIHJlZ2FyZGluZyB0aGUgdmFsdWUgb2YgImJhciIsIGlmDQo+ID4gPiA+IGFueXRoaW5n IGF0IGFsbD8NCj4gPiA+IA0KPiA+ID4gVW5sZXNzIHRoZXJlIGFyZSBvdGhlciBzZW1hbnRpY3Mg aW4gZGVzY3JpcHRpb24gc3RhdGVtZW50cywgdGhlcmUgd2lsbA0KPiA+ID4gYmUgbm8gPGJhcj4g aW5zdGFuY2UuDQo+ID4gDQo+ID4gQnV0IHdoYXQgYWJvdXQNCj4gPiANCj4gPiA8bmM6Z2V0LWNv bmZpZz4NCj4gPiAgIDxuYzpzb3VyY2U+cnVubmluZzwvbmM6c291cmNlPg0KPiA+ICAgPG53ZDp3 aXRoLWRlZmF1bHRzPnJlcG9ydC1hbGw8L253ZDp3aXRoLWRlZmF1bHRzPg0KPiA+IDwvbmM6Z2V0 LWNvbmZpZz4NCj4gPiANCj4gPiA/DQo+IA0KPiBJbiB0aGlzIGNhc2UgeW91IHdpbGwgZ2V0IDxi YXI+IHdpdGggdGhlIHZhbHVlIDQyIGluIHRoZSByZXBseS4NCg0KQWZ0ZXIgcmVhZGluZyBQZXIn cyByZXBseSAod2hpY2ggSSBmdWxseSBhZ3JlZSB3aXRoKSwgSSBzaG91bGQgYWRkDQp0aGF0IEkg cmVhZCB0aGUgcXVlc3Rpb246IFdpdGggdGhpcyBkYXRhIG1vZGVsLCBhbmQgaWYgbm90aGluZyBo YXMNCmJlZW4gc2V0IGluIHRoZSBkYXRhIHN0b3JlIChubyBwcmVsb2FkZWQgZGF0YSBldGMpLCB0 aGVuIHlvdSBnZXQgdGhlDQp2YWx1ZSA0Mi4NCg0KDQovbWFydGluDQo= From andy@netconfcentral.com Mon Aug 24 07:41: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 3AF1A28C20B for ; Mon, 24 Aug 2009 07:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 W6TG22E12s3x for ; Mon, 24 Aug 2009 07:41:16 -0700 (PDT) Received: from n22a.bullet.mail.mud.yahoo.com (n22a.bullet.mail.mud.yahoo.com [68.142.207.188]) by core3.amsl.com (Postfix) with SMTP id 704FB3A6DD0 for ; Mon, 24 Aug 2009 07:41:16 -0700 (PDT) Received: from [209.191.108.97] by n22.bullet.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 14:41:20 -0000 Received: from [68.142.201.240] by t4.bullet.mud.yahoo.com with NNFMP; 24 Aug 2009 14:41:20 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 14:41:20 -0000 X-Yahoo-Newman-Id: 459162.79717.bm@omp401.mail.mud.yahoo.com Received: (qmail 63678 invoked from network); 24 Aug 2009 14:41:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2009 14:41:19 -0000 X-YMail-OSG: TsBjWNAVM1nJo0Hk1yVeSvJjc_7WLYLmpCs4UVQYTDQigUqzFp60sxOqYTuDdQsfdn_D6VJ3T_VbnJ.dnyx0aF_.SilCDZntBuyIjJdPWvR_JpTdJfzyvTjB3Ml7UVznyB31K1D9WuTeRk_uRRdUGY6qhTsmB9ZIdzRXgasatuR7jCtUjL8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A92A691.4020601@netconfcentral.com> Date: Mon, 24 Aug 2009 07:41:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908241333.n7ODX6KL091523@idle.juniper.net> In-Reply-To: <200908241333.n7ODX6KL091523@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 14:41:18 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> we need to put this >> discussion somehow to an end. > > +1 > ^^2 We need to leave the default-stmt to be MUST implement. Otherwise it has no value at all to the application developer. It seems to me the entire purpose of a default would be (as Phil suggests) to allow the application to rely on the default, so that leaf can be effectively ignored by the operator. If the meaning of a default leaf changes from MUST to SHOULD, then operators will never be able to rely on it. > Thanks, > Phil Andy From lhotka@cesnet.cz Mon Aug 24 08:14: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 2DB3A3A6E26 for ; Mon, 24 Aug 2009 08:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.073, 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 y87vzdnK-kPm for ; Mon, 24 Aug 2009 08:14:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4FF313A6E0A for ; Mon, 24 Aug 2009 08:13:57 -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 46B24D80096; Mon, 24 Aug 2009 17:14:03 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090824.160415.74934092.mbj@tail-f.com> References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 17:14:01 +0200 Message-Id: <1251126841.7051.123.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 15:14:28 -0000 Martin Bjorklund píše v Po 24. 08. 2009 v 16:04 +0200: > Ladislav Lhotka wrote: > > Juergen Schoenwaelder píše v Po 24. 08. 2009 v 15:05 +0200: > > > On Mon, Aug 24, 2009 at 02:55:58PM +0200, Ladislav Lhotka wrote: > > > > > > > For example, with the following module: > > > > > > > > module foo { > > > > namespace "http://example.org/foo"; > > > > prefix foo; > > > > leaf bar { > > > > type uint8; > > > > default 42; > > > > } > > > > } > > > > > > > > Now, if I unwrap the device implementing this module and start the first > > > > NETCONF session, what can I rely on regarding the value of "bar", if > > > > anything at all? > > > > > > Unless there are other semantics in description statements, there will > > > be no instance. > > > > But what about > > > > > > running > > report-all > > > > > > ? > > In this case you will get with the value 42 in the reply. Does this follow from the statement in Sec. 7.6? If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. My interpretation is that the MUST only applies if the premise is satisfied, i.e., if the NETCONF client creates the instance but does not provide any value. BTW, the term "instance" is used quite often but AFAIK never defined in the draft, is it the same as "data node"? Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Aug 24 08:16: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 8B9C13A6BF0 for ; Mon, 24 Aug 2009 08:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=0.072, 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 t18mMCPvqpTS for ; Mon, 24 Aug 2009 08:16:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C32A33A6DD0 for ; Mon, 24 Aug 2009 08:16:07 -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 DE938D80095; Mon, 24 Aug 2009 17:16:13 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A92A691.4020601@netconfcentral.com> References: <200908241333.n7ODX6KL091523@idle.juniper.net> <4A92A691.4020601@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 17:16:11 +0200 Message-Id: <1251126971.7051.125.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 15:16:08 -0000 Andy Bierman píše v Po 24. 08. 2009 v 07:41 -0700: > Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> we need to put this > >> discussion somehow to an end. > > > > +1 > > > > ^^2 I am sorry, but since this has implications for the DSDL mapping draft, I want to make sure I understand it correctly. Lada > > We need to leave the default-stmt to be MUST implement. > Otherwise it has no value at all to the application > developer. > > It seems to me the entire purpose of a default > would be (as Phil suggests) to allow the application > to rely on the default, so that leaf can be > effectively ignored by the operator. > > If the meaning of a default leaf changes from MUST to SHOULD, > then operators will never be able to rely on it. > > > > Thanks, > > Phil > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Aug 24 09:21: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 DE0FA28C1E4 for ; Mon, 24 Aug 2009 09:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 ONaaUSBq+mks for ; Mon, 24 Aug 2009 09:21:34 -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 C606A28C217 for ; Mon, 24 Aug 2009 09:21:33 -0700 (PDT) Received: (qmail 89951 invoked from network); 24 Aug 2009 16:21:38 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 24 Aug 2009 16:21:38 -0000 X-YMail-OSG: DfJsY.cVM1m8tEWYB3wNbJk0b9zveeMqW1jftjOZbk8q8e6C8Hm6eJLVk2hRqOpUNzWSa3118utEucoUZTBiWSrS7su.n7yqye0a2Of.kys.PZNudJK5kM2zptA3mBazxL2CbXRR.CSuidksv7knu1iL8O12jQGjCN4v.shVxTKiNvVLncnJyHrfgeQDz35jdHzOqD_TEkokqBJsaPjJDE_TbHINjWcGzjTFMcT9o_nXj3IPAfFmP29CcgCblq4FLdTFDkvAnWoTsp_YW5h6cm9QJUj17AgWWTIUMjwzcrkirGkXZGvEbQdbxKj.w2YkmlHbOWINXxpPuJgMfafk86c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A92BE13.5020404@netconfcentral.com> Date: Mon, 24 Aug 2009 09:21:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis> In-Reply-To: <1251126841.7051.123.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 16:21:34 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Po 24. 08. 2009 v 16:04 +0200: >> Ladislav Lhotka wrote: >>> Juergen Schoenwaelder píše v Po 24. 08. 2009 v 15:05 +0200: >>>> On Mon, Aug 24, 2009 at 02:55:58PM +0200, Ladislav Lhotka wrote: >>>> >>>>> For example, with the following module: >>>>> >>>>> module foo { >>>>> namespace "http://example.org/foo"; >>>>> prefix foo; >>>>> leaf bar { >>>>> type uint8; >>>>> default 42; >>>>> } >>>>> } >>>>> >>>>> Now, if I unwrap the device implementing this module and start the first >>>>> NETCONF session, what can I rely on regarding the value of "bar", if >>>>> anything at all? >>>> Unless there are other semantics in description statements, there will >>>> be no instance. >>> But what about >>> >>> >>> running >>> report-all >>> >>> >>> ? >> In this case you will get with the value 42 in the reply. > > Does this follow from the statement in Sec. 7.6? > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. > > My interpretation is that the MUST only applies if the premise is > satisfied, i.e., if the NETCONF client creates the instance but does not > provide any value. > I do not interpret this text that way at all. The client is never allowed to provide invalid values in an edit-config or copy-config. The server will reject the leaf with an invalid-value (or whatever duplicate error-tag the server may pick). The problem (IMO) is that YANG won't go as far as to say that leafs with an agent-supplied value actually exist. This is confusing and perhaps harmful to interoperability. The server can supply missing configuration nodes at boot-time. That much is clear (I hope). If the leaf has a default value, the server MUST use this value internally if no instance of the leaf is provided when an instance of the parent data node is created. A top-level leaf node with a default statement is always present. IMO, this is closer to what we mean. > BTW, the term "instance" is used quite often but AFAIK never defined in > the draft, is it the same as "data node"? > > Lada > >> >> /martin Andy From phil@juniper.net Mon Aug 24 10:01: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 813813A6E1C for ; Mon, 24 Aug 2009 10:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 wBnxP2Qg4wXa for ; Mon, 24 Aug 2009 10:01:15 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id B97F53A6A07 for ; Mon, 24 Aug 2009 10:01:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSpLHX/ALzuRZbt+wrvikiWA8ClHRLRa5@postini.com; Mon, 24 Aug 2009 10:01:22 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; Mon, 24 Aug 2009 09:53:56 -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); Mon, 24 Aug 2009 09:53:56 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 09:53:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 09:53:54 -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 n7OGrsd71413; Mon, 24 Aug 2009 09:53:54 -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 n7OGfwmD093242; Mon, 24 Aug 2009 16:41:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908241641.n7OGfwmD093242@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251126971.7051.125.camel@missotis> Date: Mon, 24 Aug 2009 12:41:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Aug 2009 16:53:54.0841 (UTC) FILETIME=[771E9090:01CA24DB] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 17:01:16 -0000 Ladislav Lhotka writes: >I am sorry, but since this has implications for the DSDL mapping draft, >I want to make sure I understand it correctly. So let's work backwards: how different is the a:defaultValue in RNG from the default statement in YANG? What are the implications of the current definition? Thanks, Phil From lhotka@cesnet.cz Mon Aug 24 10:06: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 2C48328C2B3 for ; Mon, 24 Aug 2009 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.071, 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 EK6wDMYxIK5j for ; Mon, 24 Aug 2009 10:06:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 500C128C2B6 for ; Mon, 24 Aug 2009 10:06:37 -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 32B6ED80095; Mon, 24 Aug 2009 19:06:43 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A92BE13.5020404@netconfcentral.com> References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis> <4A92BE13.5020404@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 19:06:41 +0200 Message-Id: <1251133601.7051.135.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 17:06:38 -0000 Andy Bierman píše v Po 24. 08. 2009 v 09:21 -0700: > > If the leaf has a default value, the server MUST use this value > > internally if no value is provided by the NETCONF client when the > > instance is created. > > > > My interpretation is that the MUST only applies if the premise is > > satisfied, i.e., if the NETCONF client creates the instance but does not > > provide any value. > > > > I do not interpret this text that way at all. > The client is never allowed to provide invalid values > in an edit-config or copy-config. The server will > reject the leaf with an invalid-value (or whatever duplicate > error-tag the server may pick). Where do I say that the value can ever be invalid? > > The problem (IMO) is that YANG won't go as far as to say > that leafs with an agent-supplied value actually exist. > This is confusing and perhaps harmful to interoperability. > > The server can supply missing configuration nodes at boot-time. > That much is clear (I hope). Yes, but the question is whether the supplied value can differ from the default value, if one is specified by the data model. My take is that it can. Lada > > If the leaf has a default value, the server MUST use this value > internally if no instance of the leaf is provided when an > instance of the parent data node is created. A top-level > leaf node with a default statement is always present. > > IMO, this is closer to what we mean. > > > > > BTW, the term "instance" is used quite often but AFAIK never defined in > > the draft, is it the same as "data node"? > > > > Lada > > > >> > >> /martin > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Aug 24 10:14: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 02F263A6A0C for ; Mon, 24 Aug 2009 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 HL4Un5ILCyXW for ; Mon, 24 Aug 2009 10:14:53 -0700 (PDT) Received: from n22b.bullet.mail.mud.yahoo.com (n22b.bullet.mail.mud.yahoo.com [68.142.206.159]) by core3.amsl.com (Postfix) with SMTP id 804CF28C2B5 for ; Mon, 24 Aug 2009 10:14:44 -0700 (PDT) Received: from [68.142.200.225] by n22.bullet.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 17:14:48 -0000 Received: from [68.142.201.70] by t6.bullet.mud.yahoo.com with NNFMP; 24 Aug 2009 17:14:48 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 17:14:48 -0000 X-Yahoo-Newman-Id: 678680.67958.bm@omp422.mail.mud.yahoo.com Received: (qmail 98527 invoked from network); 24 Aug 2009 17:14:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2009 17:14:48 -0000 X-YMail-OSG: p7IKgSYVM1nhRGqFPlzWVzOfaO7.oawsDlWuKYEbOYkxyKNhbnofmFi2pJV87EM9lEJl70xp.TumBYCUX09V3Du_OjPYZNxLcQHH8Ewg.aO3jZeQTqyVJf.vC8ko5TTDXNKrdQmGoK1Lhc.ZwmDC9SS41__n6pt2sdrtX4_ur3FBtw9gitjBzeI1bdDlIdDOe82OCqi6q6r0ARE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A92CA12.3080208@netconfcentral.com> Date: Mon, 24 Aug 2009 10:12:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis> <4A92BE13.5020404@netconfcentral.com> <1251133601.7051.135.camel@missotis> In-Reply-To: <1251133601.7051.135.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 17:14:54 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 24. 08. 2009 v 09:21 -0700: > >>> If the leaf has a default value, the server MUST use this value >>> internally if no value is provided by the NETCONF client when the >>> instance is created. >>> >>> My interpretation is that the MUST only applies if the premise is >>> satisfied, i.e., if the NETCONF client creates the instance but does not >>> provide any value. >>> >> I do not interpret this text that way at all. >> The client is never allowed to provide invalid values >> in an edit-config or copy-config. The server will >> reject the leaf with an invalid-value (or whatever duplicate >> error-tag the server may pick). > > Where do I say that the value can ever be invalid? > >> The problem (IMO) is that YANG won't go as far as to say >> that leafs with an agent-supplied value actually exist. >> This is confusing and perhaps harmful to interoperability. >> >> The server can supply missing configuration nodes at boot-time. >> That much is clear (I hope). > > Yes, but the question is whether the supplied value can differ from the > default value, if one is specified by the data model. My take is that it > can. No. If there is a default-stmt that applies (via typedef or leaf), then that is the exact value that MUST be used by the server. If there is no default-stmt in affect, then the server MAY create a leaf instance with any valid value for that leaf. > > Lada Andy > >> If the leaf has a default value, the server MUST use this value >> internally if no instance of the leaf is provided when an >> instance of the parent data node is created. A top-level >> leaf node with a default statement is always present. >> >> IMO, this is closer to what we mean. >> >> >> >>> BTW, the term "instance" is used quite often but AFAIK never defined in >>> the draft, is it the same as "data node"? >>> >>> Lada >>> >>>> /martin >> Andy From lhotka@cesnet.cz Mon Aug 24 10:25: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 EC6FD3A6999 for ; Mon, 24 Aug 2009 10:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_37=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 HsAA3P65gA0L for ; Mon, 24 Aug 2009 10:25:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2FEE43A6C9F for ; Mon, 24 Aug 2009 10:25:37 -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 2A4F0D80095; Mon, 24 Aug 2009 19:25:43 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908241641.n7OGfwmD093242@idle.juniper.net> References: <200908241641.n7OGfwmD093242@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 19:25:41 +0200 Message-Id: <1251134741.7051.149.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 17:25:38 -0000 Phil Shafer píše v Po 24. 08. 2009 v 12:41 -0400: > Ladislav Lhotka writes: > >I am sorry, but since this has implications for the DSDL mapping draft, > >I want to make sure I understand it correctly. > > So let's work backwards: how different is the a:defaultValue in > RNG from the default statement in YANG? What are the implications > of the current definition? The annotation attribute is nma:default and is used essentially for changing the infoset of the instance document by adding the annotated element with the default value if it is are missing. This must be done before Schematron validation. However, if the default statement in YANG had another meaning (especially one expressed with MUST), the resulting DSDL schemas most likely won't be able to capture this semantics. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Aug 24 10:42: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 144BD3A6E3B for ; Mon, 24 Aug 2009 10:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=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 M8qRetvo-cGk for ; Mon, 24 Aug 2009 10:42:14 -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 511BE28C2D0 for ; Mon, 24 Aug 2009 10:42:14 -0700 (PDT) Received: (qmail 11999 invoked from network); 24 Aug 2009 17:42:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2009 17:42:18 -0000 X-YMail-OSG: mBEVBEAVM1m3TdjLRuRF5bJ2uRmiP.hoaAxYvtlrAlGqS2EbDrQg9cuNnJzrj7GOBtgjnL7SoAgvD2oOz5k8Lt4cjmwnOf1qd5c7HCEt2OzP3xPH79_p63c4x0m8ySQGplc4n8dP7DgyAtnF8dhI.HE.YczOeIIkxZApxt_hk7JKWpfrAUEbXaCuK4ybSddPolNvln92pjgOdovf4dzcW6nJ4Rks5x94bQN.eh5dS8Vby8Y0dXw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A92D082.5020008@netconfcentral.com> Date: Mon, 24 Aug 2009 10:40:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200908241641.n7OGfwmD093242@idle.juniper.net> <1251134741.7051.149.camel@missotis> In-Reply-To: <1251134741.7051.149.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 17:42:15 -0000 Ladislav Lhotka wrote: > Phil Shafer píše v Po 24. 08. 2009 v 12:41 -0400: >> Ladislav Lhotka writes: >>> I am sorry, but since this has implications for the DSDL mapping draft, >>> I want to make sure I understand it correctly. >> So let's work backwards: how different is the a:defaultValue in >> RNG from the default statement in YANG? What are the implications >> of the current definition? > > The annotation attribute is nma:default and is used essentially for > changing the infoset of the instance document by adding the annotated > element with the default value if it is are missing. This must be done > before Schematron validation. > > However, if the default statement in YANG had another meaning > (especially one expressed with MUST), the resulting DSDL schemas most > likely won't be able to capture this semantics. > But isn't the problem with mandatory (wrt/ DSDL) independent of the default-stmt? Mandatory=true means the contents of a valid database will contain the mandatory node. The WG agrees that is what mandatory=true means. This is needed to account for factory initialization and dynamically selected server defaults. So any schema language that describes the NETCONF PDUs instead of the contents of the conceptual NETCONF database is not going to be able to capture this semantics. > Lada > >> Thanks, >> Phil Andy From lhotka@cesnet.cz Mon Aug 24 10: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 5C4B528C2F4 for ; Mon, 24 Aug 2009 10:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.073, 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 nJ6plJzL8TCE for ; Mon, 24 Aug 2009 10:49:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 03F253A6BF0 for ; Mon, 24 Aug 2009 10:49:05 -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 E6E8AD80096; Mon, 24 Aug 2009 19:49:10 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A92CA12.3080208@netconfcentral.com> References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis> <4A92BE13.5020404@netconfcentral.com> <1251133601.7051.135.camel@missotis> <4A92CA12.3080208@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 19:49:08 +0200 Message-Id: <1251136148.7051.156.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 17:49:54 -0000 Andy Bierman píše v Po 24. 08. 2009 v 10:12 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Po 24. 08. 2009 v 09:21 -0700: > > > >>> If the leaf has a default value, the server MUST use this value > >>> internally if no value is provided by the NETCONF client when the > >>> instance is created. > >>> > >>> My interpretation is that the MUST only applies if the premise is > >>> satisfied, i.e., if the NETCONF client creates the instance but does not > >>> provide any value. > >>> > >> I do not interpret this text that way at all. > >> The client is never allowed to provide invalid values > >> in an edit-config or copy-config. The server will > >> reject the leaf with an invalid-value (or whatever duplicate > >> error-tag the server may pick). > > > > Where do I say that the value can ever be invalid? > > > >> The problem (IMO) is that YANG won't go as far as to say > >> that leafs with an agent-supplied value actually exist. > >> This is confusing and perhaps harmful to interoperability. > >> > >> The server can supply missing configuration nodes at boot-time. > >> That much is clear (I hope). > > > > Yes, but the question is whether the supplied value can differ from the > > default value, if one is specified by the data model. My take is that it > > can. > > No. > > If there is a default-stmt that applies (via typedef or leaf), > then that is the exact value that MUST be used by the server. > > If there is no default-stmt in affect, then the server MAY > create a leaf instance with any valid value for that leaf. So if the data model is module foo { namespace "http://example.org/foo"; prefix foo; leaf bar { type uint8; default 42; } } and my friendly vendor preloads the device with configuration 13 the device will be considered non-compliant? Lada > > > > > > Lada > > Andy > > > > >> If the leaf has a default value, the server MUST use this value > >> internally if no instance of the leaf is provided when an > >> instance of the parent data node is created. A top-level > >> leaf node with a default statement is always present. > >> > >> IMO, this is closer to what we mean. > >> > >> > >> > >>> BTW, the term "instance" is used quite often but AFAIK never defined in > >>> the draft, is it the same as "data node"? > >>> > >>> Lada > >>> > >>>> /martin > >> Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Aug 24 11:04: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 F06FE28C2F9 for ; Mon, 24 Aug 2009 11:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_37=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 UAbXA3wW9Kri for ; Mon, 24 Aug 2009 11:04:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 159E228C301 for ; Mon, 24 Aug 2009 11:04:54 -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 386E0D80095; Mon, 24 Aug 2009 20:05:00 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A92D082.5020008@netconfcentral.com> References: <200908241641.n7OGfwmD093242@idle.juniper.net> <1251134741.7051.149.camel@missotis> <4A92D082.5020008@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 20:04:58 +0200 Message-Id: <1251137098.7051.165.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group 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: Mon, 24 Aug 2009 18:04:56 -0000 Andy Bierman píše v Po 24. 08. 2009 v 10:40 -0700: > Ladislav Lhotka wrote: > > Phil Shafer píše v Po 24. 08. 2009 v 12:41 -0400: > >> Ladislav Lhotka writes: > >>> I am sorry, but since this has implications for the DSDL mapping draft, > >>> I want to make sure I understand it correctly. > >> So let's work backwards: how different is the a:defaultValue in > >> RNG from the default statement in YANG? What are the implications > >> of the current definition? > > > > The annotation attribute is nma:default and is used essentially for > > changing the infoset of the instance document by adding the annotated > > element with the default value if it is are missing. This must be done > > before Schematron validation. > > > > However, if the default statement in YANG had another meaning > > (especially one expressed with MUST), the resulting DSDL schemas most > > likely won't be able to capture this semantics. > > > > But isn't the problem with mandatory (wrt/ DSDL) independent > of the default-stmt? Mandatory=true means the contents of a valid > database will contain the mandatory node. The WG agrees that is > what mandatory=true means. This is needed to account for > factory initialization and dynamically selected server defaults. Yes, it is pretty much independent. Mandatory/optional is handled in RELAX NG and simply checks whether all non-optional elements are present in a given document. Whether an element is optional or not also depends on the document type that is being validated. A problem would be to capture semantics of assigned-by. > > So any schema language that describes the NETCONF PDUs instead of > the contents of the conceptual NETCONF database is not going > to be able to capture this semantics. A reply to get-config without any filter will be invalid if any of the mandatory nodes are missing. Lada > > > > > Lada > > > >> Thanks, > >> Phil > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Aug 24 11:14: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 E08633A69B2 for ; Mon, 24 Aug 2009 11:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 1c013WaKHdrD for ; Mon, 24 Aug 2009 11:14:30 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id DF5263A6E2B for ; Mon, 24 Aug 2009 11:14:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSpLYiPZp1OGDcZMPVKbMHAEy87oGLZRH@postini.com; Mon, 24 Aug 2009 11:14:35 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; Mon, 24 Aug 2009 11:02:13 -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); Mon, 24 Aug 2009 11:02:13 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 11:02:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 11:02: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 n7OI2Ad24213; Mon, 24 Aug 2009 11:02:10 -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 n7OHoE8Y094033; Mon, 24 Aug 2009 17:50:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908241750.n7OHoE8Y094033@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251136148.7051.156.camel@missotis> Date: Mon, 24 Aug 2009 13:50:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Aug 2009 18:02:12.0350 (UTC) FILETIME=[016CD1E0:01CA24E5] 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: Mon, 24 Aug 2009 18:14:31 -0000 Ladislav Lhotka writes: >So if the data model is >module foo { > namespace "http://example.org/foo"; > prefix foo; > leaf bar { > type uint8; > default 42; > } >} >and my friendly vendor preloads the device with configuration >13 >the device will be considered non-compliant? This is a gray area, since the your friendly vendor could say that there's a boot time client that did an operation that set the value of bar explicitly. If you get the configuration, you will see 13 so to your app, there's nothing strange afoot. But if you have delete , it should not reappear spontaneous. Or if you have: list foo { key name; leaf name { ... } lear bar { ... default 42; } ... } and your app makes a new and it's suddenly becomes set to 13, something it definitely broken. Thanks, Phil From lhotka@cesnet.cz Mon Aug 24 11:33: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 8E9F73A6E7E for ; Mon, 24 Aug 2009 11:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=0.076, 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 KwaJz+61HQzu for ; Mon, 24 Aug 2009 11:33:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C06133A68A7 for ; Mon, 24 Aug 2009 11:33:49 -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 7E337D80095; Mon, 24 Aug 2009 20:33:55 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908241750.n7OHoE8Y094033@idle.juniper.net> References: <200908241750.n7OHoE8Y094033@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Aug 2009 20:33:53 +0200 Message-Id: <1251138833.7051.178.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 18:33:50 -0000 Phil Shafer píše v Po 24. 08. 2009 v 13:50 -0400: > Ladislav Lhotka writes: > >So if the data model is > >module foo { > > namespace "http://example.org/foo"; > > prefix foo; > > leaf bar { > > type uint8; > > default 42; > > } > >} > >and my friendly vendor preloads the device with configuration > >13 > >the device will be considered non-compliant? > > This is a gray area, since the your friendly vendor could say that > there's a boot time client that did an operation that set the value > of bar explicitly. If you get the configuration, you will see > 13 so to your app, there's nothing strange afoot. Exactly! And if I plug in a new piece of hardware, the vendor can say there's a hotplug client that did the operation. But then in practice such default statements are not binding for the vendor. > > But if you have delete , it should not reappear > spontaneous. Or if you have: A datastore implementation that has the defaults explicitly represented ("report-all" style) will have to re-create with the default value. > > list foo { > key name; > leaf name { ... } > lear bar { ... default 42; } > ... > } > > and your app makes a new and it's suddenly > becomes set to 13, something it definitely broken. I agree here. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Aug 24 11: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 400F23A6DDC for ; Mon, 24 Aug 2009 11:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.045, 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 WoYi39ftO0B1 for ; Mon, 24 Aug 2009 11:40: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 6A2DE3A6AE0 for ; Mon, 24 Aug 2009 11:40: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 9597076C5A3; Mon, 24 Aug 2009 20:40:42 +0200 (CEST) Date: Mon, 24 Aug 2009 20:40:41 +0200 (CEST) Message-Id: <20090824.204041.256705389.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251138833.7051.178.camel@missotis> References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <1251138833.7051.178.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] 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: Mon, 24 Aug 2009 18:40:38 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gUGhpbCBTaGFmZXIg cMOtxaFlIHYgUG8gMjQuIDA4LiAyMDA5IHYgMTM6NTAgLTA0MDA6DQo+ID4gTGFkaXNsYXYgTGhv dGthIHdyaXRlczoNCj4gPiA+U28gaWYgdGhlIGRhdGEgbW9kZWwgaXMNCj4gPiA+bW9kdWxlIGZv byB7DQo+ID4gPiAgICBuYW1lc3BhY2UgImh0dHA6Ly9leGFtcGxlLm9yZy9mb28iOw0KPiA+ID4g ICAgcHJlZml4IGZvbzsNCj4gPiA+ICAgIGxlYWYgYmFyIHsNCj4gPiA+ICAgICAgICB0eXBlIHVp bnQ4Ow0KPiA+ID4gICAgICAgIGRlZmF1bHQgNDI7DQo+ID4gPiAgICB9DQo+ID4gPn0NCj4gPiA+ YW5kIG15IGZyaWVuZGx5IHZlbmRvciBwcmVsb2FkcyB0aGUgZGV2aWNlIHdpdGggY29uZmlndXJh dGlvbg0KPiA+ID48YmFyIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5vcmcvZm9vIj4xMzwvYmFyPg0K PiA+ID50aGUgZGV2aWNlIHdpbGwgYmUgY29uc2lkZXJlZCBub24tY29tcGxpYW50Pw0KPiA+IA0K PiA+IFRoaXMgaXMgYSBncmF5IGFyZWEsIHNpbmNlIHRoZSB5b3VyIGZyaWVuZGx5IHZlbmRvciBj b3VsZCBzYXkgdGhhdA0KPiA+IHRoZXJlJ3MgYSBib290IHRpbWUgY2xpZW50IHRoYXQgZGlkIGFu IG9wZXJhdGlvbiB0aGF0IHNldCB0aGUgdmFsdWUNCj4gPiBvZiBiYXIgZXhwbGljaXRseS4gIElm IHlvdSBnZXQgdGhlIGNvbmZpZ3VyYXRpb24sIHlvdSB3aWxsIHNlZQ0KPiA+IDxiYXI+MTM8L2Jh cj4gc28gdG8geW91ciBhcHAsIHRoZXJlJ3Mgbm90aGluZyBzdHJhbmdlIGFmb290Lg0KPiANCj4g RXhhY3RseSEgQW5kIGlmIEkgcGx1ZyBpbiBhIG5ldyBwaWVjZSBvZiBoYXJkd2FyZSwgdGhlIHZl bmRvciBjYW4gc2F5DQo+IHRoZXJlJ3MgYSBob3RwbHVnIGNsaWVudCB0aGF0IGRpZCB0aGUgb3Bl cmF0aW9uLiBCdXQgdGhlbiBpbiBwcmFjdGljZQ0KPiBzdWNoIGRlZmF1bHQgc3RhdGVtZW50cyBh cmUgbm90IGJpbmRpbmcgZm9yIHRoZSB2ZW5kb3IuDQoNCkl0IGlzLCBiL2MgaWYgeW91IGRvIGEg Z2V0LWNvbmZpZywgYW5kIHlvdSBkbyBOT1QgZ2V0IGEgdmFsdWUgZm9yIHRoaXMNCmxlYWYsIHlv dSBLTk9XIHRoYXQgdGhlIHNlcnZlciBpcyBpbnRlcm5hbGx5IHVzaW5nIHRoZSB2YWx1ZSA0Mi4N Cg0KDQovbWFydGluDQo= From andy@netconfcentral.com Mon Aug 24 11:56: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 913B93A6E2A for ; Mon, 24 Aug 2009 11:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, 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 YktOf0UR6CnI for ; Mon, 24 Aug 2009 11:56:14 -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 E362F3A6E27 for ; Mon, 24 Aug 2009 11:56:14 -0700 (PDT) Received: (qmail 26139 invoked from network); 24 Aug 2009 18:56:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2009 18:56:19 -0000 X-YMail-OSG: 5YkHyxcVM1lxENTn3tsTnBWDm05Lrf9cJ46sPJIuvNRylMjY0rd7hX5gJDj13HALGePBZ1lzxDUlllDk5nV1Zdr8cij4GjsyDF5STB7r_IGN0OjeDNvyJQjjNFWVgSQ2GifXoWDpe5PQfEDX7MQ62cJ6FVPNURzoV10iEXnsPrMy5Un11hIbUjTPzi0952FAiOslWfHNj9bOHLLTV7pqM9w0aVNxFj9QsCtp4bcopxtFoP2b7X8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A92E255.3070603@netconfcentral.com> Date: Mon, 24 Aug 2009 11:56:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <1251138833.7051.178.camel@missotis> In-Reply-To: <1251138833.7051.178.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Mon, 24 Aug 2009 18:56:15 -0000 Ladislav Lhotka wrote: > Phil Shafer píše v Po 24. 08. 2009 v 13:50 -0400: >> Ladislav Lhotka writes: >>> So if the data model is >>> module foo { >>> namespace "http://example.org/foo"; >>> prefix foo; >>> leaf bar { >>> type uint8; >>> default 42; >>> } >>> } >>> and my friendly vendor preloads the device with configuration >>> 13 >>> the device will be considered non-compliant? >> This is a gray area, since the your friendly vendor could say that >> there's a boot time client that did an operation that set the value >> of bar explicitly. If you get the configuration, you will see >> 13 so to your app, there's nothing strange afoot. > > Exactly! And if I plug in a new piece of hardware, the vendor can say > there's a hotplug client that did the operation. But then in practice > such default statements are not binding for the vendor. > It is binding. Phil is pointing out the possibility that the operator may be able to provide CLI parameters to the server that cause it to change from the assigned mandatory default to the desired value. So in this case, the mandatory default was conceptually assigned, and then re-assigned to the CLI value. In the absence of any initial configuration, the default statement value MUST be the value used by the server. >> But if you have delete , it should not reappear >> spontaneous. Or if you have: > > A datastore implementation that has the defaults explicitly represented > ("report-all" style) will have to re-create with the default > value. > >> list foo { >> key name; >> leaf name { ... } >> lear bar { ... default 42; } >> ... >> } >> >> and your app makes a new and it's suddenly >> becomes set to 13, something it definitely broken. > > I agree here. > > Lada > >> Thanks, >> Phil Andy From cfinss@dial.pipex.com Mon Aug 24 13:09: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 0BEB33A6EAA for ; Mon, 24 Aug 2009 13:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 OvLMeJjGcgVq for ; Mon, 24 Aug 2009 13:09:44 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id E47B73A69A7 for ; Mon, 24 Aug 2009 13:08:56 -0700 (PDT) X-Trace: 278470754/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.50/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.50 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: AuAEALOQkko+vGky/2dsb2JhbACDLUCNK8V/CYQRBQ X-IronPort-AV: E=Sophos;i="4.44,267,1249254000"; d="scan'208";a="278470754" X-IP-Direction: IN Received: from 1cust50.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.50]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Aug 2009 21:08:55 +0100 Message-ID: <000401ca24ee$2ab4f880$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <1250865485.3702.21.camel@missotis><4A8EB599.4040207@joelhalpern.com><000301ca24a0$580a0760$0601a8c0@allison> <20090824.134858.211095739.mbj@tail-f.com> Date: Mon, 24 Aug 2009 20:54:33 +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] 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: Mon, 24 Aug 2009 20:09:45 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; Sent: Monday, August 24, 2009 1:48 PM > "tom.petch" wrote: > > I agree that what I want is not what the spec currently says. What I see as > > a common use case is not covered. > > It seems you are saying that you don't think the current default > statement is very useful. If this is a correct interpretation, I can > respect that, but at the same time I would like to know if you see any > technical problems with the current text? Martin Weell, look at how the description starts: 'If a leaf has a "default" statement, the leaf's default value is set to the value of the "default" statement. ' :-) which is not exactly a definition, and as you see, I think of it as a SHOULD, the best available wisdom of the data modeller, and see that as more important than the issues of a manager knowing what will be set in advance, what it will get on a retrieval with various different options etc etc. These are valid considerations, problems to be solved, but, for me, secondary ones to be solved in other ways. (And yes, I do realise that there is more in 7.6 from which I quote, but that is the first 'definition' of default:-) The text probably should be strengthened once we have reached a consensus: eg insert before the sentence I quote The default value is the value that the server MUST use internally if no value is provided by the NETCONF client when the instance is created. and then go on to say where this default comes from, pace agreement about 'internally' which, like Lada, I am unclear about Tom Petch > > Also, I have a problem with the spec. I see information coming from four > > sources; device-manufacturer, model-writer (could be SDO), manager-implementer > > and user, and any one of the four may know best in a given situation, nor do > > I think we have the skills to prescribe any particular precedence. > > > > I expect manufacturers to implement best practice at the time the box is > > built, but what do they do as best practice (and the SDO-provided data model) > > moves on? either create non-conformance statements, or ship upgrades to change > > their values to current best practice. > > > > I don't see either as realistic; what we ask for seems, well, unrealistic, and > > so > > likely to be ignored. Given that, I think we can find a better use for the > > default substatement. > > Given the discussions we have had about this, and that we don't have a > concrete proposal to discuss, shouldn't this wait? > > > /martin From cfinss@dial.pipex.com Mon Aug 24 13:09: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 29AFE3A69A7 for ; Mon, 24 Aug 2009 13:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 Wy43imQqAJnK for ; Mon, 24 Aug 2009 13:09:44 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 31C3028C34E for ; Mon, 24 Aug 2009 13:08:58 -0700 (PDT) X-Trace: 278470766/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.50/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.50 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: AuAEALOQkko+vGky/2dsb2JhbACDLUCNK8V/CYQRBQ X-IronPort-AV: E=Sophos;i="4.44,267,1249254000"; d="scan'208";a="278470766" X-IP-Direction: IN Received: from 1cust50.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.50]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Aug 2009 21:08:58 +0100 Message-ID: <000601ca24ee$2c81c940$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Ladislav Lhotka" References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis><4A92BE13.5020404@netconfcentral.com><1251133601.7051.135.camel@missotis> <4A92CA12.3080208@netconfcentral.com> Date: Mon, 24 Aug 2009 20:55:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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] 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: Mon, 24 Aug 2009 20:09:45 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Ladislav Lhotka" Cc: Sent: Monday, August 24, 2009 7:12 PM > Ladislav Lhotka wrote: > > Andy Bierman píše v Po 24. 08. 2009 v 09:21 -0700: > > > >>> If the leaf has a default value, the server MUST use this value > >>> internally if no value is provided by the NETCONF client when the > >>> instance is created. > >>> > >>> My interpretation is that the MUST only applies if the premise is > >>> satisfied, i.e., if the NETCONF client creates the instance but does not > >>> provide any value. > >>> > >> I do not interpret this text that way at all. > >> The client is never allowed to provide invalid values > >> in an edit-config or copy-config. The server will > >> reject the leaf with an invalid-value (or whatever duplicate > >> error-tag the server may pick). > > > > Where do I say that the value can ever be invalid? > > > >> The problem (IMO) is that YANG won't go as far as to say > >> that leafs with an agent-supplied value actually exist. > >> This is confusing and perhaps harmful to interoperability. > >> > >> The server can supply missing configuration nodes at boot-time. > >> That much is clear (I hope). > > > > Yes, but the question is whether the supplied value can differ from the > > default value, if one is specified by the data model. My take is that it > > can. > > No. > > If there is a default-stmt that applies (via typedef or leaf), > then that is the exact value that MUST be used by the server. > > If there is no default-stmt in affect, then the server MAY > create a leaf instance with any valid value for that leaf. I have no problem with having this capability in YANG. It meets a use case and so has a reason to exist, so that manager-implementers have a ready way to know what is there. What then does not exist is what Joel so elegantly described as a SHOULD ie the model writer wants to say 'This value represents our recommended wisdom" so passing this on to device manufacturers, manager-implementers and all sorts of users without forcing them to modify products to suit, eg with code upgrades or non-compliance statements etc. Rather, this use case has to go in the 'description' substatement. As Juergen pointed out, " If we go over board with constraints in data models, we will kill ourself." so I am cautious about the (perhaps over-)use of MUST. Tom Petch > > Lada > > Andy > > > > >> If the leaf has a default value, the server MUST use this value > >> internally if no instance of the leaf is provided when an > >> instance of the parent data node is created. A top-level > >> leaf node with a default statement is always present. > >> > >> IMO, this is closer to what we mean. > >> > >> > >> > >>> BTW, the term "instance" is used quite often but AFAIK never defined in > >>> the draft, is it the same as "data node"? > >>> > >>> Lada > >>> > >>>> /martin > >> Andy From cfinss@dial.pipex.com Mon Aug 24 13:09: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 3A9CF3A6EAA for ; Mon, 24 Aug 2009 13:09:45 -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.443, 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 OYiemIUa-U54 for ; Mon, 24 Aug 2009 13:09:44 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 8BA8E28C1AA for ; Mon, 24 Aug 2009 13:08:57 -0700 (PDT) X-Trace: 278470757/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.50/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.50 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: AuAEALOQkko+vGky/2dsb2JhbACDLUCNK8V/CYQRBYFR X-IronPort-AV: E=Sophos;i="4.44,267,1249254000"; d="scan'208";a="278470757" X-IP-Direction: IN Received: from 1cust50.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.50]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Aug 2009 21:08:57 +0100 Message-ID: <000501ca24ee$2b8f2be0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com><1251126841.7051.123.camel@missotis> <4A92BE13.5020404@netconfcentral.com> Date: Mon, 24 Aug 2009 20:54:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: [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: Mon, 24 Aug 2009 20:09:45 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Ladislav Lhotka" Cc: Sent: Monday, August 24, 2009 6:21 PM Subject: Re: [netmod] meaning of default > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Po 24. 08. 2009 v 16:04 +0200: > >> Ladislav Lhotka wrote: > >>> Juergen Schoenwaelder píše v Po 24. 08. 2009 v 15:05 +0200: > >>>> On Mon, Aug 24, 2009 at 02:55:58PM +0200, Ladislav Lhotka wrote: > >>>> > >>>>> For example, with the following module: > >>>>> > >>>>> module foo { > >>>>> namespace "http://example.org/foo"; > >>>>> prefix foo; > >>>>> leaf bar { > >>>>> type uint8; > >>>>> default 42; > >>>>> } > >>>>> } > >>>>> > >>>>> Now, if I unwrap the device implementing this module and start the first > >>>>> NETCONF session, what can I rely on regarding the value of "bar", if > >>>>> anything at all? > >>>> Unless there are other semantics in description statements, there will > >>>> be no instance. > >>> But what about > >>> > >>> > >>> running > >>> report-all > >>> > >>> > >>> ? > >> In this case you will get with the value 42 in the reply. > > > > Does this follow from the statement in Sec. 7.6? > > > > If the leaf has a default value, the server MUST use this value > > internally if no value is provided by the NETCONF client when the > > instance is created. > > > > My interpretation is that the MUST only applies if the premise is > > satisfied, i.e., if the NETCONF client creates the instance but does not > > provide any value. > > > > I do not interpret this text that way at all. > The client is never allowed to provide invalid values > in an edit-config or copy-config. The server will > reject the leaf with an invalid-value (or whatever duplicate > error-tag the server may pick). > > The problem (IMO) is that YANG won't go as far as to say > that leafs with an agent-supplied value actually exist. > This is confusing and perhaps harmful to interoperability. > > The server can supply missing configuration nodes at boot-time. > That much is clear (I hope). Andy When I read Juergen saying 'My preferred model, as stated before, is the one where the server makes a distinction between config values that have been explicitely set and values that are operationally used but not explicitely configured and thus not part of a configuration datastore' I read something different, that what is supplied by the server at boot time is not then part of configuration - ever. Tom Petch > If the leaf has a default value, the server MUST use this value > internally if no instance of the leaf is provided when an > instance of the parent data node is created. A top-level > leaf node with a default statement is always present. > > IMO, this is closer to what we mean. > > > > > BTW, the term "instance" is used quite often but AFAIK never defined in > > the draft, is it the same as "data node"? > > > > Lada > > > >> > >> /martin > > Andy From cfinss@dial.pipex.com Mon Aug 24 13:09: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 6DBB23A69A7 for ; Mon, 24 Aug 2009 13:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, 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 3aEDi2L8oK2B for ; Mon, 24 Aug 2009 13:09:44 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id CA5BB28C352 for ; Mon, 24 Aug 2009 13:08:58 -0700 (PDT) X-Trace: 278470769/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.50/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.50 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: AuAEALOQkko+vGky/2dsb2JhbACDLUCNK8V/CYQRBQ X-IronPort-AV: E=Sophos;i="4.44,267,1249254000"; d="scan'208";a="278470769" X-IP-Direction: IN Received: from 1cust50.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.50]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Aug 2009 21:09:00 +0100 Message-ID: <000701ca24ee$2d639dc0$0601a8c0@allison> From: "tom.petch" To: "David Partain" , "NETMOD Working Group" References: <200908211234.59155.david.partain@ericsson.com> Date: Mon, 24 Aug 2009 21:03:19 +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: [netmod] Terminology wasRe: Please submit open issues separately 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: Mon, 24 Aug 2009 20:09:45 -0000 ... but if I were to pick one technical issue above others, it would be terminology, that a lot of our threads revolve around words that are not clearly defined or where we use different words for the same concept and perhaps talk past each other. Examples are - user/agent/application (not too important), - the importing of Clark notation and expanded names into prefix discussions (concepts we need and don't have terms for) - the different node types, which Lada unpicked for us, which in turn has much changed our use of XPath - nodes again with 'grouping' which I think still needs work - identifiers v names, which came up today - instance, again came up today .... Just examples, no one too major, but overall there is a fuzziness around, as if I am peering through a fog. Tom Petch ----- Original Message ----- From: "David Partain" To: "NETMOD Working Group" Sent: Friday, August 21, 2009 12:34 PM Subject: [netmod] Please submit open issues separately > Hi all, > > I'm have EXTREME difficulty understanding where people are and even what they > think the issues are. > > As such, I'd like to request the following: If there is an issue that you > think remains unresolved, please send mail to the list with > > (1) a relevant subject stating what the issue is > (2) a pointer to the text in the document that you think has the issue, and > (3) if possible, a suggested textual fix that we can discuss. > > We're all over the place at the moment, which concerns me. > > Cheers, > > David > > ps. I hope to submit minutes in the next few hours for your comments. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From per@tail-f.com Mon Aug 24 13:19: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 BBAB93A6AA3 for ; Mon, 24 Aug 2009 13:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 oRwZJ4cbKrsA for ; Mon, 24 Aug 2009 13:19:35 -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 AE57C3A6C1F for ; Mon, 24 Aug 2009 13:19:19 -0700 (PDT) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 9CB1976C59C; Mon, 24 Aug 2009 22:19:24 +0200 (CEST) Message-ID: <4A92F5C6.3030102@tail-f.com> Date: Mon, 24 Aug 2009 22:19:18 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Phil Shafer References: <200908241750.n7OHoE8Y094033@idle.juniper.net> In-Reply-To: <200908241750.n7OHoE8Y094033@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: Mon, 24 Aug 2009 20:19:35 -0000 On 2009-08-24 19:50, Phil Shafer wrote: > Ladislav Lhotka writes: >> So if the data model is >> module foo { >> namespace "http://example.org/foo"; >> prefix foo; >> leaf bar { >> type uint8; >> default 42; >> } >> } >> and my friendly vendor preloads the device with configuration >> 13 >> the device will be considered non-compliant? > > This is a gray area, since the your friendly vendor could say that > there's a boot time client that did an operation that set the value > of bar explicitly. Why would he say such a silly thing, instead of simply explaining that the device is preloaded with a configuration that (among other, hopefully specified, values) has the value 13 for the leaf? Do you consider the concept of a preloaded configuration to be somehow a violation of any YANG data model? Or just a preloaded configuration where some leafs have configured values other than the defaults specified in the data model? Yang describes how the operations of a NETCONF client affect the configuration, and other sources of configuration or configuration changes are outside its scope - but taking this to mean that no configuration other than that which has been provided by a NETCONF client can exist on the device, which this discussion seems to keep circling around to, has no basis either in the draft or in reality IMO. I do think the specification of when the server must use the default value is less than ideal though - not the "use internally", but the rest. I would like to suggest a change like the one below, which mirrors the specification of what "mandatory" means. But perhaps this is overkill, and it could end with "... internally." The (presumably intended meaning of the) original text is just a special case of "no value has been set". OLD: If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. NEW: If the leaf has a default value, and no value has been set, the server MUST use the default value internally in the following cases, depending 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. o Otherwise, if this ancestor is a case node, if any node from the case exists. o Otherwise, if the ancestor node exists. --Per Hedeland From andy@netconfcentral.com Mon Aug 24 13:27: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 04A8B28C243 for ; Mon, 24 Aug 2009 13:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.007, 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 HR+ER32ik8iP for ; Mon, 24 Aug 2009 13:27:01 -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 5B4CE3A6C84 for ; Mon, 24 Aug 2009 13:27:01 -0700 (PDT) Received: (qmail 2588 invoked from network); 24 Aug 2009 20:27:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.121.106.96 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2009 20:27:05 -0000 X-YMail-OSG: 5B8Jtg8VM1mDfiKC.5xHx3F_t5sUVO1B6dkVbTY7_qE3y5ZyQGElLd3AimBe0c87K4ZcRV2yN0mND4EEbhVI5o5hiRYcgxRZH2k.6nwyL0yfsKggUMOXdoeDiQR5lwDTdQjFFrjsOzv9P7vunX7deUEfMAP4vgC5bnMFWte0eu4AusJYcjwm9xn_F7aFr4QWWhb321n_AIWRAtD4d_FWgJvtphA7DPBU2RxM5Pr4lXWC03DsZRI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A92F79B.3080709@netconfcentral.com> Date: Mon, 24 Aug 2009 13:27:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com><1251126841.7051.123.camel@missotis> <4A92BE13.5020404@netconfcentral.com> <000501ca24ee$2b8f2be0$0601a8c0@allison> In-Reply-To: <000501ca24ee$2b8f2be0$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8 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: Mon, 24 Aug 2009 20:27:02 -0000 tom.petch wrote: .... > Andy > > When I read Juergen saying > > 'My preferred model, as stated before, is the one where the server > makes a distinction between config values that have been explicitely > set and values that are operationally used but not explicitely > configured and thus not part of a configuration datastore' > > I read something different, that what is supplied by the server > at boot time is not then part of configuration - ever. > huh? what page in the draft says this? If the client issues a operation on running and with-defaults=report-all, then the server-supplied values will be there, so why would you think otherwise? The use of static default-stmt values are limited to those cases where there is agreement on the exact value. If not, then the description statement is (by design) where information about dynamic defaults, or preferred defaults, or discouraged defaults, will be found. > Tom Petch > Andy From j.schoenwaelder@jacobs-university.de Mon Aug 24 15:17:20 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 49FB528C37B for ; Mon, 24 Aug 2009 15:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 98IcWMVTUudQ for ; Mon, 24 Aug 2009 15:17:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0133528C388 for ; Mon, 24 Aug 2009 15:17:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB5BDC0016; Tue, 25 Aug 2009 00:17:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1djkCCPrSELc; Tue, 25 Aug 2009 00:17:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E904C002A; Tue, 25 Aug 2009 00:17:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4F3FEC7BD30; Tue, 25 Aug 2009 00:17:22 +0200 (CEST) Date: Tue, 25 Aug 2009 00:17:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090824221721.GA17599@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local> <1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis> <4A92BE13.5020404@netconfcentral.com> <000501ca24ee$2b8f2be0$0601a8c0@allison> <4A92F79B.3080709@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A92F79B.3080709@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 22:17:20 -0000 On Mon, Aug 24, 2009 at 10:27:07PM +0200, Andy Bierman wrote: > tom.petch wrote: > .... > > Andy > > > > When I read Juergen saying > > > > 'My preferred model, as stated before, is the one where the server > > makes a distinction between config values that have been explicitely > > set and values that are operationally used but not explicitely > > configured and thus not part of a configuration datastore' > > > > I read something different, that what is supplied by the server > > at boot time is not then part of configuration - ever. > > > > huh? what page in the draft says this? > > If the client issues a operation > on running and with-defaults=report-all, then > the server-supplied values will be there, > so why would you think otherwise? Lets step back for a while and look at config files and what I like about some of them. Here is what I really like about some config files: They contain comments indicating settable objects and the default value that applies. Something simple like this: # bar=42 The config file tells me that there is a bar and what its default value is. If I want, I can copy the line and turn this to # bar=42 bar=42 and bar=42 becomes explicit part of my config. Of course, I can choose a different value, e.g. # bar=42 bar=24 and a software update might even lead to this (by updating the commented default): # bar=24 bar=24 I do not know about others, but I really love these kind of config files. They seem to make my life easier. Emulating this with NETCONF/YANG requires that there is a distinction between operationally used (default) values and config data. And, obviously, config data that happens to match the current default value should not cause any special processing or behaviour - the fact that the implemented default changed in the example above should not change the config snippet bar=24 at all. >From this perspective, the width-defaults draft kind of goes into the wrong direction. I would need instead a way to retrieve the operationally used values that are not config data. And it does not matter at all whether the YANG data model defines a machine readable default value - what I am interested is what the device operationally uses; and this in particular applies to objects that do not have a stable static default value in the data model. The width-defaults ID assumes that all parameters ultimately are part of the config and that only some of them happen to be magically hidden. I am not convinced this is the right model; I am a big fan of the explicit config model where stuff not explicitely configured is simply not part of the config datastore. In other words, the operationally used values that are not configured live somewhere else but not as part of the config. In the config file example shown above, comment characters are used to indicate exactly that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Mon Aug 24 19:10: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 E7F273A69EF for ; Mon, 24 Aug 2009 19:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=0.299, 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 9ceN0R7Qf9TF for ; Mon, 24 Aug 2009 19:10:09 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 1D6BE3A6837 for ; Mon, 24 Aug 2009 19:10:09 -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.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KOW008XZTZM9H00@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Tue, 25 Aug 2009 10:09:22 +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 <0KOW00D0FTZM3710@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Tue, 25 Aug 2009 10:09:22 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 25 Aug 2009 10:09:22 +0800 From: WashamFan To: Per Hedeland Message-id: Date: Tue, 25 Aug 2009 10:09:22 +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: <4A92F5C6.3030102@tail-f.com> References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> 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, 25 Aug 2009 02:10:10 -0000 Hi, > OLD: > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. > > NEW: > > If the leaf has a default value, and no value has been set, the > server MUST use the default value internally in the following cases, > depending 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. > > o Otherwise, if this ancestor is a case node, if any node from the > case exists. > > o Otherwise, if the ancestor node exists. Or If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created implicitly. ^^^^^ for simplicity? washam From phil@juniper.net Mon Aug 24 19:13: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 BF69028C3F9 for ; Mon, 24 Aug 2009 19:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 XFOOcDwPMUuZ for ; Mon, 24 Aug 2009 19:13:06 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id C99FC28C3BA for ; Mon, 24 Aug 2009 19:13:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSpNItGfmsdXyT81ttHiD9YHmAGWtMNke@postini.com; Mon, 24 Aug 2009 19:13:12 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; Mon, 24 Aug 2009 19:09:52 -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); Mon, 24 Aug 2009 19:09:52 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 19:09:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 19:09:51 -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 n7P29od21354; Mon, 24 Aug 2009 19:09:50 -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 n7P1vrEY097629; Tue, 25 Aug 2009 01:57:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908250157.n7P1vrEY097629@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090824221721.GA17599@elstar.local> Date: Mon, 24 Aug 2009 21:57:53 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 02:09:51.0268 (UTC) FILETIME=[21196640:01CA2529] MIME-Version: 1.0 Content-Type: text/plain 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, 25 Aug 2009 02:13:06 -0000 Juergen Schoenwaelder writes: >The width-defaults ID assumes that all parameters ultimately are part >of the config and that only some of them happen to be magically >hidden. I am not convinced this is the right model; I am a big fan of >the explicit config model where stuff not explicitely configured is >simply not part of the config datastore. In other words, the >operationally used values that are not configured live somewhere else >but not as part of the config. In the config file example shown above, >comment characters are used to indicate exactly that. Amen. One can look at this as two distinct problems: (a) Before I make a list item, what can I say about the leafs that I am not creating? ex: If I make an interface, but don't set the duplex, will it default to full, half, or auto? (b) After I create the list item, what can I learn about the leafs of the real instance of this item? ex: Now that I've made an interface, what is the duplex at this point in time? There are questions about giving feedback to the user of my application before they create the interface, but there are questions about the state of the interface that was defined in the configuration data. The interaction isn't as easy as the with-defaults ID makes it sound. With-defaults doesn't address (a) or (b). I can't do a with-defaults on a non-existant instance, so the source for (a) has to be the YANG module. And doing a with-defaults report-all for (b) will tell me the YANG default of "auto", not the current value of "full". "auto" may be interesting to know, but given that I had to write the code to find it for (a), finding it for (b) is trivial. Thanks, Phil From andy@netconfcentral.com Mon Aug 24 19:50: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 59F8D3A6EB9 for ; Mon, 24 Aug 2009 19:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 TSYDcSr7tQ4c for ; Mon, 24 Aug 2009 19:50:51 -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 647EA3A6862 for ; Mon, 24 Aug 2009 19:50:51 -0700 (PDT) Received: (qmail 34879 invoked from network); 25 Aug 2009 02:50:55 -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; 25 Aug 2009 02:50:55 -0000 X-YMail-OSG: DXuz5moVM1nieEs2moFFmRWDe3CogbDsDl3NT1SN3OVVSFpTAvxbpWpzR6YDmIRepGJedPFTyLlW.DD3_K0XjrZCnrINW24ZKflsPIXNoVx1PzI2PTnT3ynQsHJaDNHKgb0UYtF2K.yxwVdMPFJow0N4HtcjJT95LzrW9LrSDA7Rb.14nZLG387RDPFCpwrPHCqdeNfcuHmCKetoPkRwNGn2fEtuDhxzMKcAz4D1_vZOUw8QAW7MWtx4ADV8p04cQjNDpnRqrvkvlbZ6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A935191.4090504@netconfcentral.com> Date: Mon, 24 Aug 2009 19:50:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908250157.n7P1vrEY097629@idle.juniper.net> In-Reply-To: <200908250157.n7P1vrEY097629@idle.juniper.net> 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, 25 Aug 2009 02:50:52 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> The width-defaults ID assumes that all parameters ultimately are part >> of the config and that only some of them happen to be magically >> hidden. I am not convinced this is the right model; I am a big fan of >> the explicit config model where stuff not explicitely configured is >> simply not part of the config datastore. In other words, the >> operationally used values that are not configured live somewhere else >> but not as part of the config. In the config file example shown above, >> comment characters are used to indicate exactly that. > > Amen. One can look at this as two distinct problems: > > (a) Before I make a list item, what can I say about the > leafs that I am not creating? > ex: If I make an interface, but don't set the duplex, > will it default to full, half, or auto? > > (b) After I create the list item, what can I learn > about the leafs of the real instance of this item? > ex: Now that I've made an interface, what is the > duplex at this point in time? > > There are questions about giving feedback to the user of my application > before they create the interface, but there are questions about the > state of the interface that was defined in the configuration data. > The interaction isn't as easy as the with-defaults ID makes it > sound. > > With-defaults doesn't address (a) or (b). I can't do a with-defaults > on a non-existant instance, so the source for (a) has to be the > YANG module. And doing a with-defaults report-all for (b) will > tell me the YANG default of "auto", not the current value of "full". > "auto" may be interesting to know, but given that I had to write > the code to find it for (a), finding it for (b) is trivial. You could design a duplex-admin leaf and a duplex-operational leaf if you cared so much about this little corner case. For every other type of leaf, (B) works fine. (A) is the same result you get now, without with-defaults. The advantage of with-defaults=report-all is that it clearly shows the actual values in use on a specific agent at a specific time. That can be really useful in debugging. Before making changes to the config, it is often useful to know the current contents of the config. After making changes to the config, it is often useful to know exactly what happened. I agree with Juergen that the best way to really make progress is to have interoperability test events, and see if most implementations do things a certain way, and only 1 or 2 implementations are off in the weeds, wrt/ defaults. leaf foo { type string; } I am concerned that there will be many leafs of the type above. Telling customers to just look up the CLI documentation for all the server-provided leafs is fine, if you hate your customers. Using with-defaults=report-all is a million times less work for them. There is also no substitute for a direct answer to a direct question, at the time the information is needed. > > Thanks, > Phil > Andy From per@tail-f.com Mon Aug 24 23:57: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 038813A688F for ; Mon, 24 Aug 2009 23:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 bQWK3b9Tc776 for ; Mon, 24 Aug 2009 23:57:30 -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 2BC563A6874 for ; Mon, 24 Aug 2009 23:57:29 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CBC8A76C59E; Tue, 25 Aug 2009 08:57:34 +0200 (CEST) Message-ID: <4A938B5E.4020100@tail-f.com> Date: Tue, 25 Aug 2009 08:57:34 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: WashamFan References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> In-Reply-To: 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, 25 Aug 2009 06:57:31 -0000 On 2009-08-25 04:09, WashamFan wrote: > Hi, > >> OLD: >> >> If the leaf has a default value, the server MUST use this value >> internally if no value is provided by the NETCONF client when the >> instance is created. >> >> NEW: >> >> If the leaf has a default value, and no value has been set, the >> server MUST use the default value internally in the following cases, >> depending 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. >> >> o Otherwise, if this ancestor is a case node, if any node from the >> case exists. >> >> o Otherwise, if the ancestor node exists. > > Or > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created implicitly. > ^^^^^ > for simplicity? I disagree, on two counts. First, the leaf isn't created at all in the relevant case, neither implicitly nor explicitly. It is created by giving it a value, at which point the default value becomes irrelevant. Second, I specifically wanted to avoid the "operational" description that seems to be interpreted to mean that the usage of the default value is dependent on who created what and how. Whether the default value MUST be used can always be determined by observing the existing configuration, in a manner that is very similar to how it is determined that a leaf marked "mandatory" MUST exist. If a simpler version is wanted, I still vote for: If the leaf has a default value, and no value has been set, the server MUST use the default value internally. But that requires the reader to be able to figure out that the value, default or otherwise, of leafs in non-existing presence containers, list entries, or choice cases, is irrelevant. I don't know if that is a realistic requirement. --Per Hedeland From per@tail-f.com Tue Aug 25 00:25:22 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 16DFA3A688F for ; Tue, 25 Aug 2009 00:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 pfYStM43T0q0 for ; Tue, 25 Aug 2009 00:25: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 457B73A6845 for ; Tue, 25 Aug 2009 00:25:21 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5E78E76C59E; Tue, 25 Aug 2009 09:25:27 +0200 (CEST) Message-ID: <4A9391E7.1050706@tail-f.com> Date: Tue, 25 Aug 2009 09:25:27 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Phil Shafer References: <200908250157.n7P1vrEY097629@idle.juniper.net> In-Reply-To: <200908250157.n7P1vrEY097629@idle.juniper.net> 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, 25 Aug 2009 07:25:22 -0000 On 2009-08-25 03:57, Phil Shafer wrote: > > Amen. One can look at this as two distinct problems: > > (a) Before I make a list item, what can I say about the > leafs that I am not creating? > ex: If I make an interface, but don't set the duplex, > will it default to full, half, or auto? > > (b) After I create the list item, what can I learn > about the leafs of the real instance of this item? > ex: Now that I've made an interface, what is the > duplex at this point in time? > > There are questions about giving feedback to the user of my application > before they create the interface, but there are questions about the > state of the interface that was defined in the configuration data. > The interaction isn't as easy as the with-defaults ID makes it > sound. > > With-defaults doesn't address (a) or (b). It does address (b). > I can't do a with-defaults > on a non-existant instance, so the source for (a) has to be the > YANG module. And doing a with-defaults report-all for (b) will > tell me the YANG default of "auto", not the current value of "full". No, of course report-all will not report the default value for a leaf that has a different value. IMO this is obvious from the very motivation of the capability in the introduction section, the need to provide data that may otherwise be suppressed. Values that are different from the default value are never suppressed, hence the capability is irrelevant for those. If still in doubt, see the example. --Per Hedeland From cfinss@dial.pipex.com Tue Aug 25 02:37: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 4EB5B28C485 for ; Tue, 25 Aug 2009 02:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 DmkuboBQ4i6T for ; Tue, 25 Aug 2009 02:37:44 -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 429623A6ADF for ; Tue, 25 Aug 2009 02:37:44 -0700 (PDT) X-Trace: 189965120/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.168/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.168 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: AiAFANdNk0o+vGmo/2dsb2JhbACDLUAgjQzEZwmEEQU X-IronPort-AV: E=Sophos;i="4.44,271,1249254000"; d="scan'208";a="189965120" X-IP-Direction: IN Received: from 1cust168.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.168]) by smtp.pipex.tiscali.co.uk with SMTP; 25 Aug 2009 10:37:48 +0100 Message-ID: <000201ca255f$2992fc60$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <20090824.102033.118206378.mbj@tail-f.com> Date: Tue, 25 Aug 2009 10:05:08 +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] bit statement bug 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, 25 Aug 2009 09:37:45 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Sent: Monday, August 24, 2009 10:20 AM Subject: [netmod] bit statement bug > A bit name is currently restricted to be an identifier. I think this > is a bug - at some point in time both enums and bits were supposed to > be identifiers, but we relaxed this. The text reflects this for > enums, but not for bits. For example, the usage example in 9.7.5 has > this: > > bit 10-Mb-only { > position 2; > } > > but this is not legal according to the current text and grammar. > > I suggest this change to 9.7.4: > > OLD > > The "bit" statement, which is a substatement to the "type" statement, > MUST be present if the type is "bits". It is repeatedly used to > specify each assigned named bit of a bits type. It takes as an > argument a string which is the assigned name of the bit. It is > followed by a block of substatements which holds detailed bit > information. A bit name follows the same syntax rules as an > identifier (see Section 6.2). > > NEW > > The "bit" statement, which is a substatement to the "type" statement, > MUST be present if the type is "bits". It is repeatedly used to > specify each assigned named bit of a bits type. It takes as an > argument a string which is the assigned name of the bit. The > string MUST NOT be empty and MUST NOT contain any > whitespace characters. The use of control codes SHOULD be avoided. > > The statement is optionally followed by a block of substatements > which holds detailed bit information. Martin Yes, it works, but ... terminology. A minor point here but typical of what can be a bigger one elsewhere. Reading this suggests to me we have a concept of 'assigned name' which would then be different from a name which is of course different from an identifier:-) I am (again) left unsure if I know what it means - really. And you have omitted the next sentence which then refers not to 'assigned name' but to 'bit names':-( If 'assigned name' is not something special, then I would recast it along the lines of 'Each bit statement assigns (specifies) a name to (for) a bit. It takes as an argument a string which is the name of the bit.' or being analytical, get rid of adverbs whenever possible, use verbs for the action and reduce the number of terms to the number of concepts. At a tangent, I suggest in the ABNF comment for WSP /white space/whitespace/ I know I don't know what whitespace is in YANG but always struggle to find the formal definition when I search on 'whitespace'. Tom Petch > > /martin From mbj@tail-f.com Tue Aug 25 02:43: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 6986E3A6B11 for ; Tue, 25 Aug 2009 02:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=0.558, 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 fuXjXr1+wkKU for ; Tue, 25 Aug 2009 02:43: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 7F52E3A6B23 for ; Tue, 25 Aug 2009 02:43:37 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id CAC9176C59E for ; Tue, 25 Aug 2009 11:43:42 +0200 (CEST) Date: Tue, 25 Aug 2009 11:43:47 +0200 (CEST) Message-Id: <20090825.114347.55695945.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <4A938B5E.4020100@tail-f.com> References: <4A92F5C6.3030102@tail-f.com> <4A938B5E.4020100@tail-f.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 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, 25 Aug 2009 09:43:38 -0000 Hi, I think this discussion has found three issues that need to be addressed: o The presentation issue reported by Tom; first describe what a default value is, then how it is defined. o We need a more precise definition of *what* it is, i.e. what "use internally" means. o We need a more precise definition of *when* the default value is "used internally". The *how* text can be kept more or less as is, I think. The problem is that the description of all these three are intertwined. Here's an attempt. I made a new subsection for this. 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, 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. o Otherwise, the default value MUST be used if the ancestor node exists. 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. And also modify section 7.13.2 (and 7.13.3 and 7.14 similarly) If a leaf in the input tree has a default value, the NETCONF server MUST use this value in the same cases as described in Section 7.6.1. In these cases, the server MUST operationally behave as if the leaf was present in the NETCONF RPC invocation with the default value as its value. /martin From mbj@tail-f.com Tue Aug 25 03:00: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 E7A773A6A06 for ; Tue, 25 Aug 2009 03:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.418, 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 kYAXa2Ern45Y for ; Tue, 25 Aug 2009 03:00:00 -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 26F0A3A6821 for ; Tue, 25 Aug 2009 03:00:00 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 13C0376C59E; Tue, 25 Aug 2009 12:00:05 +0200 (CEST) Date: Tue, 25 Aug 2009 12:00:11 +0200 (CEST) Message-Id: <20090825.120011.261510938.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <000201ca255f$2992fc60$0601a8c0@allison> References: <20090824.102033.118206378.mbj@tail-f.com> <000201ca255f$2992fc60$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] bit statement bug 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, 25 Aug 2009 10:00:01 -0000 Hi, "tom.petch" wrote: > Yes, it works, So far, I am not introducing this change. Andy was against, Juergen was maybe for it. But your comments apply to the original text as well. > but ... terminology. A minor point here but typical of > what can be a bigger one elsewhere. > > Reading this suggests to me we have a concept of 'assigned name' which > would then be different from a name which is of course different from > an identifier:-) Section 9.7 says: The bits built-in type represents a bit set. That is, a bits value is a set of flags identified by small integer position numbers starting at 0. Each bit number has an assigned name. So this is where the "assigned name" is defined. Now, I guess we could s/assigned name/name/ but would that really solve a real problem? (we'd have to do it form enums as well). > I am (again) left unsure if I know what it means - really. > And you have omitted the next sentence which then refers not to 'assigned > name' but to 'bit names':-( Fixed. bit names is now assigned name. > At a tangent, I suggest in the ABNF comment for WSP > /white space/whitespace/ Fixed. /martin From per@tail-f.com Tue Aug 25 04:02: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 384503A6E27 for ; Tue, 25 Aug 2009 04:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 LQcn2MajLR7s for ; Tue, 25 Aug 2009 04:02:56 -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 74DA33A6F54 for ; Tue, 25 Aug 2009 04:02:56 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0CC9876C59E; Tue, 25 Aug 2009 13:03:02 +0200 (CEST) Message-ID: <4A93C4E5.4070509@tail-f.com> Date: Tue, 25 Aug 2009 13:03:01 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Martin Bjorklund References: <20090824.102033.118206378.mbj@tail-f.com> <000201ca255f$2992fc60$0601a8c0@allison> <20090825.120011.261510938.mbj@tail-f.com> In-Reply-To: <20090825.120011.261510938.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] bit statement bug 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, 25 Aug 2009 11:02:57 -0000 On 2009-08-25 12:00, Martin Bjorklund wrote: > > So far, I am not introducing this change. Andy was against, Juergen > was maybe for it. I don't think it is a big problem, but restricting the bit names to be identifiers seems like a completely arbitrary and pointless rule, which is something I generally find confusing. So here's a vote *for* the change (bugfix), and including a note motivating the difference from enum names as suggested by Juergen would be a good idea I think. Restricting also enum names to be identifiers would be worse than the current situation IMO. --Per Hedeland From lhotka@cesnet.cz Tue Aug 25 05:15:19 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 0E18C3A6B81 for ; Tue, 25 Aug 2009 05:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ro7cu15w4uuX for ; Tue, 25 Aug 2009 05:15:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 30ADA3A6B56 for ; Tue, 25 Aug 2009 05:15:18 -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 75584D800E8; Tue, 25 Aug 2009 14:13:28 +0200 (CEST) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <4A92F5C6.3030102@tail-f.com> References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 25 Aug 2009 14:13:26 +0200 Message-Id: <1251202406.32185.29.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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, 25 Aug 2009 12:15:19 -0000 Per Hedeland píše v Po 24. 08. 2009 v 22:19 +0200: > OLD: > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. > > NEW: > > If the leaf has a default value, and no value has been set, the > server MUST use the default value internally in the following cases, > depending 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. > > o Otherwise, if this ancestor is a case node, if any node from the > case exists. > > o Otherwise, if the ancestor node exists. > Actually, draft-ietf-netmod-dsdl-map-03 defines in Sec. 8.1.2 the term "implicit node" which tries to capture these conditions, although for the case node the formulation is different. An implicit node is a leaf with specified default, a non-presence container containing at least one such leaf as its child, etc. Using this term, YANG draft could perhaps formulate the requirement for defaults as follows: A valid configuration in which an implicit node is missing MUST be equivalent to another configuration which is identical except that the implicit node is present and, if it is a leaf, has the default value. This says for example that for the module module foo { namespace "http://example.org/foo"; prefix foo; container wrap { leaf bar { type uint8; default 42; } } the following configurations are equivalent: 1. empty configuration 2. 3. 42 Could this work? Lada > > --Per Hedeland > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From Washam.Fan@huaweisymantec.com Tue Aug 25 06:47:17 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 B583F28C1A8 for ; Tue, 25 Aug 2009 06:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=1.346, 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 tlGFatjjrDy7 for ; Tue, 25 Aug 2009 06:47:16 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id B433B3A686D for ; Tue, 25 Aug 2009 06:47:16 -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 <0KOX005RNQ9S2Z20@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Tue, 25 Aug 2009 21:46:40 +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 <0KOX0043RQ9SAJ20@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Tue, 25 Aug 2009 21:46:40 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 25 Aug 2009 21:46:40 +0800 From: WashamFan To: Per Hedeland Message-id: Date: Tue, 25 Aug 2009 21:46:40 +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: <4A938B5E.4020100@tail-f.com> References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <4A938B5E.4020100@tail-f.com> 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, 25 Aug 2009 13:47:17 -0000 Hi, ----- Original Message ----- From: Per Hedeland Date: Tuesday, August 25, 2009 2:58 pm Subject: Re: [netmod] meaning of default To: WashamFan Cc: netmod@ietf.org > On 2009-08-25 04:09, WashamFan wrote: > > Hi, > > > >> OLD: > >> > >> If the leaf has a default value, the server MUST use this value > >> internally if no value is provided by the NETCONF client when > the > >> instance is created. > >> > >> NEW: > >> > >> If the leaf has a default value, and no value has been set, the > >> server MUST use the default value internally in the following > cases, > >> depending 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. > >> > >> o Otherwise, if this ancestor is a case node, if any node from > the > >> case exists. > >> > >> o Otherwise, if the ancestor node exists. > > > > Or > > > > If the leaf has a default value, the server MUST use this value > > internally if no value is provided by the NETCONF client when > the > > instance is created implicitly. > > ^^^^^ > > for simplicity? > > I disagree, on two counts. First, the leaf isn't created at all in the > relevant case, neither implicitly nor explicitly. It is created by > giving it a value, at which point the default value becomes irrelevant. OK. That is related the issue whether default leaves belong to the config. Since majority does not think default leaves belong to the config. i.e., no default leaves exist in data tree, i.e., no instance at all. I am fine with that. > Second, I specifically wanted to avoid the "operational" description > that seems to be interpreted to mean that the usage of the default value > is dependent on who created what and how. Whether the default value MUST > be used can always be determined by observing the existing > configuration, in a manner that is very similar to how it is determined > that a leaf marked "mandatory" MUST exist. But the usage of the default value MUST be defined, I think Martin's proposal in another email is good. washam > If a simpler version is wanted, I still vote for: > > If the leaf has a default value, and no value has been set, the > server MUST use the default value internally. > > But that requires the reader to be able to figure out that the value, > default or otherwise, of leafs in non-existing presence containers, list > entries, or choice cases, is irrelevant. I don't know if that is a > realistic requirement. > > --Per Hedeland > > From Washam.Fan@huaweisymantec.com Tue Aug 25 07:03: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 8657F3A6E7D for ; Tue, 25 Aug 2009 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Mx2doUYHD-zO for ; Tue, 25 Aug 2009 07:03:43 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 7C4793A6EEF for ; Tue, 25 Aug 2009 07:03:43 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=iso-8859-15 Received: from hstml02-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 <0KOX00BAIR1Y8A90@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Tue, 25 Aug 2009 22:03:34 +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 <0KOX0056LR1XFT20@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Tue, 25 Aug 2009 22:03:34 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 25 Aug 2009 22:03:33 +0800 From: WashamFan To: Ladislav Lhotka Message-id: Date: Tue, 25 Aug 2009 22:03:33 +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: <1251202406.32185.29.camel@missotis> References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <1251202406.32185.29.camel@missotis> Content-transfer-encoding: quoted-printable 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, 25 Aug 2009 14:03:44 -0000 Hi=2C ----- Original Message ----- From=3A Ladislav Lhotka =3Clhotka=40cesnet=2Ecz=3E Date=3A Tuesday=2C August 25=2C 2009 8=3A17 pm Subject=3A Re=3A =5Bnetmod=5D meaning of default To=3A Per Hedeland =3Cper=40tail-f=2Ecom=3E Cc=3A netmod=40ietf=2Eorg =3E Per Hedeland p=ED=A8e v Po 24=2E 08=2E 2009 v 22=3A19 +0200=3A =3E = =3E =3E OLD=3A =3E =3E = =3E =3E If the leaf has a default value=2C the server MUST use this = value =3E =3E internally if no value is provided by the NETCONF client whe= n the =3E =3E instance is created=2E =3E =3E = =3E =3E NEW=3A =3E =3E = =3E =3E If the leaf has a default value=2C and no value has been set= =2C the =3E =3E server MUST use the default value internally in the followin= g cases=2C =3E =3E depending on the type of the leaf=27s closest ancestor node = in the =3E =3E schema tree which is not a non-presence container=3A =3E =3E = =3E =3E o If no such ancestor exists=2E =3E =3E = =3E =3E o Otherwise=2C if this ancestor is a case node=2C if any nod= e from the =3E =3E case exists=2E =3E =3E = =3E =3E o Otherwise=2C if the ancestor node exists=2E =3E =3E = =3E Actually=2C draft-ietf-netmod-dsdl-map-03 defines in Sec=2E 8=2E1=2E= 2 the term =3E =22implicit node=22 which tries to capture these conditions=2C alth= ough for =3E the case node the formulation is different=2E An implicit node is a= leaf =3E with specified default=2C a non-presence container containing at le= ast = =3E one =3E such leaf as its child=2C etc=2E Using this term=2C YANG draft coul= d perhaps =3E formulate the requirement for defaults as follows=3A I assume the implicit node refers to node in schema tree=2C right=3F I read the sec 8=2E1=2E2=2C but it did not say how about default leaf de= fined in = grouping=2C is it a implicit node in this case=3F =3E A valid configuration in which an implicit node is missing MUST be =3E equivalent to another configuration which is identical except that = the =3E implicit node is present and=2C if it is a leaf=2C has the default = value=2E I am not sure expressing in this way is legal or not=2C since default le= af might never present in the config in most people=27s POV=2E =3E This says for example that for the module =3E = =3E module foo =7B =3E namespace =22http=3A//example=2Eorg/foo=22=3B =3E prefix foo=3B =3E container wrap =7B =3E leaf bar =7B =3E type uint8=3B =3E default 42=3B =3E =7D =3E =7D =3E = =3E the following configurations are equivalent=3A =3E = =3E 1=2E empty configuration =3E = =3E 2=2E =3Cwrap xmlns=3D=22 I am not sure it is legal or not=3F Can you explicit a NP container without setting its children=3F washam =3E 3=2E =3Cwrap xmlns=3D=22 =3E =3Cbar=3E42=3C/bar=3E =3E =3C/wrap=3E =3E = =3E Could this work=3F =3E = =3E Lada =3E = =3E = =3E = =3E =3E = =3E =3E --Per Hedeland =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F =3E =3E netmod mailing list =3E =3E netmod=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netmod =3E -- = =3E Ladislav Lhotka=2C CESNET =3E PGP Key ID=3A E74E8C0C =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E netmod mailing list =3E netmod=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netmod =3E From lhotka@cesnet.cz Tue Aug 25 07:22: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 27C643A6A53 for ; Tue, 25 Aug 2009 07:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.073, 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 CV12lYj5yZEG for ; Tue, 25 Aug 2009 07:22:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EA3B33A68C5 for ; Tue, 25 Aug 2009 07:22:10 -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 B9C52D800CE; Tue, 25 Aug 2009 16:22:15 +0200 (CEST) From: Ladislav Lhotka To: WashamFan In-Reply-To: References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <1251202406.32185.29.camel@missotis> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 25 Aug 2009 16:22:14 +0200 Message-Id: <1251210134.11204.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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, 25 Aug 2009 14:22:12 -0000 WashamFan píše v Út 25. 08. 2009 v 22:03 +0800: > Hi, > > ----- Original Message ----- > From: Ladislav Lhotka > Date: Tuesday, August 25, 2009 8:17 pm > Subject: Re: [netmod] meaning of default > To: Per Hedeland > Cc: netmod@ietf.org > > > > Per Hedeland píše v Po 24. 08. 2009 v 22:19 +0200: > > > > > OLD: > > > > > > If the leaf has a default value, the server MUST use this value > > > internally if no value is provided by the NETCONF client when the > > > instance is created. > > > > > > NEW: > > > > > > If the leaf has a default value, and no value has been set, the > > > server MUST use the default value internally in the following cases, > > > depending 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. > > > > > > o Otherwise, if this ancestor is a case node, if any node from the > > > case exists. > > > > > > o Otherwise, if the ancestor node exists. > > > > > Actually, draft-ietf-netmod-dsdl-map-03 defines in Sec. 8.1.2 the term > > "implicit node" which tries to capture these conditions, although for > > the case node the formulation is different. An implicit node is a leaf > > with specified default, a non-presence container containing at least > > one > > such leaf as its child, etc. Using this term, YANG draft could perhaps > > formulate the requirement for defaults as follows: > > I assume the implicit node refers to node in schema tree, right? No, they are nodes in the data tree that are filled in, if they are missing, when generating the configuration in "report-all" style. So to be precise, the last bullet should actually read o As an exception to the above two rules, a leaf or container node that is defined inside a case of a choice can be implicit only if that case is declared as default by using the 'default' statement, see Section 7.9.3 in [5]. > I read the sec 8.1.2, but it did not say how about default leaf defined in > grouping, is it a implicit node in this case? No, only nodes in the data tree come into play, grouping definitions don't contribute to the data tree. > > > A valid configuration in which an implicit node is missing MUST be > > equivalent to another configuration which is identical except that the > > implicit node is present and, if it is a leaf, has the default value. > > I am not sure expressing in this way is legal or not, since default leaf > might never present in the config in most people's POV. It doesn't matter, I think. It just says that everything should work like when the node is present. I know, equivalence of configurations is also a bit vague, but not worse than "uses internally". The advantage is that it is expressed in terms of configurations, i.e., statically. > > > This says for example that for the module > > > > module foo { > > namespace "http://example.org/foo"; > > prefix foo; > > container wrap { > > leaf bar { > > type uint8; > > default 42; > > } > > } > > > > the following configurations are equivalent: > > > > 1. empty configuration > > > > 2. > washam > > > 3. > that seems to be interpreted to mean that the usage of the default value >> is dependent on who created what and how. Whether the default value MUST >> be used can always be determined by observing the existing >> configuration, in a manner that is very similar to how it is determined >> that a leaf marked "mandatory" MUST exist. > > But the usage of the default value MUST be defined, I think Martin's > proposal in another email is good. > We are never going to agree that mandatory=true means the client must set the leaf, because we cannot agree on a 3rd state like 'server-assigned'. You cannot observe the current config and know for certain what server-supplied values will be added if a new subtree is added to the config. As Phil pointed out, you can only retrieve data from the server that is already there. You have to read the YANG file, and it may or may not have default-stmt or description-stmt information that will help. SMIv2 is not nearly as precise as YANG in this area, so we should be happy with a big improvement. YANG has the default and description statements, and both are optional-to-use. It is up to the data model writer to make sure all relevant information is documented in the YANG module. > washam Andy From andy@netconfcentral.com Tue Aug 25 07:47: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 CBC843A6906 for ; Tue, 25 Aug 2009 07:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 Huu1Xr7FIps2 for ; Tue, 25 Aug 2009 07:47:34 -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 2211A3A6DB3 for ; Tue, 25 Aug 2009 07:47:34 -0700 (PDT) Received: (qmail 17673 invoked from network); 25 Aug 2009 14:47:37 -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; 25 Aug 2009 14:47:37 -0000 X-YMail-OSG: KHi8_MMVM1m.eO1YJfHst2ImTN_K6uJVQbDOXoCCL7Ia_AVaZ8WazyDEkjHzA6Cl5MylQAyQbqFYnt7.JmkLUia4J6bAbSU4LBrN8fH3fqpMskXkq3JBW0SvPdkfOiRicqR5PYIVj1Kf7DGxqhgR7Kf8YWlDXlIaRrtmMXF8xf43uPXBUKVekwnWaN8c0EcZPbhdB2LOhKgSOg8D1gXaUg8aH1rImZbNAo3DqxaE_Re.O9YtWY4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A93F912.5070508@netconfcentral.com> Date: Tue, 25 Aug 2009 07:45:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <4A938B5E.4020100@tail-f.com> <4A93F750.7010001@netconfcentral.com> In-Reply-To: <4A93F750.7010001@netconfcentral.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, 25 Aug 2009 14:47:34 -0000 Andy Bierman wrote: ... > As Phil pointed out, you can only retrieve data from > the server that is already there. You have to read > the YANG file, and it may or may not have default-stmt > or description-stmt information that will help. > This is not true if the server supports :candidate and :with-defaults capabilities. Then the client can lock the candidate, create any portion of the config, and retrieve it with-defaults=report-all. The operator does not have to carefully read a stack of YANG modules in this case, just to find out what the server will do. > >> washam > > Andy Andy From mbj@tail-f.com Tue Aug 25 07:50: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 0489B3A6F52 for ; Tue, 25 Aug 2009 07:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, 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 XVWbI3NVqkL0 for ; Tue, 25 Aug 2009 07:49: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 84B753A6F7D for ; Tue, 25 Aug 2009 07:49:54 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 979EE76C59E; Tue, 25 Aug 2009 16:50:00 +0200 (CEST) Date: Tue, 25 Aug 2009 16:50:00 +0200 (CEST) Message-Id: <20090825.165000.137852161.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A93F750.7010001@netconfcentral.com> References: <4A938B5E.4020100@tail-f.com> <4A93F750.7010001@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, 25 Aug 2009 14:50:00 -0000 Andy Bierman wrote: > > OK. That is related the issue whether default leaves belong to the > > config. Since majority does not think default leaves belong to the > > config. i.e., no default leaves exist in data tree, i.e., no instance at all. > > I am fine with that. > > > > > I am not convinced this is the WG consensus. Wait! The text is written so that it allows the server to handle defaults in any of the three ways described in the with-defaults I-D. Do any of you want to change this text now? > I believe the WG consensus is that server-supplied values are > actually present. server-supplied values is something different, with no formal YANG support. /martin From andy@netconfcentral.com Tue Aug 25 08:11: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 220F83A6AC1 for ; Tue, 25 Aug 2009 08:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 Oaumx-EhULBT for ; Tue, 25 Aug 2009 08:11:02 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id ACE3E3A680D for ; Tue, 25 Aug 2009 08:11:02 -0700 (PDT) Received: (qmail 13771 invoked from network); 25 Aug 2009 15:10:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 25 Aug 2009 15:10:53 -0000 X-YMail-OSG: KOrWF.oVM1laI8xT0Vc_hxOADRX8F1Py31kANptIBbXscxXa_uV0c5w.mpjfOOG7nqax6CNvZBtijjGmGO_EEksyKTG6JZkCFrCWMZ8p9vD8SWFk5DNo7zpErr_aIr.U5oXIxDp3ErsHZ.D7J3x_tnuWv_UrhrsQgoRQ2iBC30b3TRzg9gn4d0sA5A2Jwd_c0v8mEEiJbH2FjTyhGCtT6TLT17l1k68.Owg2cd7MZXCQKkJVGCPIhEqV7_hNlc1k5XlOiDHFEgG0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A93FE86.8080709@netconfcentral.com> Date: Tue, 25 Aug 2009 08:08:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A938B5E.4020100@tail-f.com> <4A93F750.7010001@netconfcentral.com> <20090825.165000.137852161.mbj@tail-f.com> In-Reply-To: <20090825.165000.137852161.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, 25 Aug 2009 15:11:04 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>> OK. That is related the issue whether default leaves belong to the >>> config. Since majority does not think default leaves belong to the >>> config. i.e., no default leaves exist in data tree, i.e., no instance at all. >>> I am fine with that. >>> >> >> I am not convinced this is the WG consensus. > > Wait! The text is written so that it allows the server to handle > defaults in any of the three ways described in the with-defaults I-D. > > Do any of you want to change this text now? > There is lots of text scattered throughout the draft. There is text that says (for must and when expressions) the set of defaults are included in the server data set. To me, the litmus test is the expected behavior for this example: container top { leaf foo { type string; } leaf bar { type string; default 'barney'; } leaf baz { type string; mandatory true; } } Client Creates: wilma Server Contains: (i.e., this is returned if with-defaults=report-all) fred barney wilma What happens when a for a server-supplied leaf is issued, without any :with-defaults support? We know that that the server can skip over defaults if the request is for an ancestor node of the default leaf, but what if the request is directly for the specified leaf? I think Lada brought up this issue before. IMO, all servers MUST return the requested data for this filter. >> I believe the WG consensus is that server-supplied values are >> actually present. > > server-supplied values is something different, with no formal YANG > support. > So both NETCONF and YANG are silent about whether or not all servers will respond in a consistent manner for this example? Why is this considered an acceptable level of interoperability? > > /martin > Andy From mbj@tail-f.com Tue Aug 25 08:20: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 3437D3A6AC1 for ; Tue, 25 Aug 2009 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.042, 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 w5zaXHikvFlU for ; Tue, 25 Aug 2009 08:20:23 -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 21D413A6F84 for ; Tue, 25 Aug 2009 08:20:23 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 159CF76C5A8; Tue, 25 Aug 2009 17:20:28 +0200 (CEST) Date: Tue, 25 Aug 2009 17:20:27 +0200 (CEST) Message-Id: <20090825.172027.98363293.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A93FE86.8080709@netconfcentral.com> References: <4A93F750.7010001@netconfcentral.com> <20090825.165000.137852161.mbj@tail-f.com> <4A93FE86.8080709@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, 25 Aug 2009 15:20:24 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >>> OK. That is related the issue whether default leaves belong to the > >>> config. Since majority does not think default leaves belong to the > >>> config. i.e., no default leaves exist in data tree, i.e., no instance at > >>> all. > >>> I am fine with that. > >>> > >> > >> I am not convinced this is the WG consensus. > > > > Wait! The text is written so that it allows the server to handle > > defaults in any of the three ways described in the with-defaults I-D. > > > > Do any of you want to change this text now? > > > > There is lots of text scattered throughout the draft. > There is text that says (for must and when expressions) > the set of defaults are included in the server data set. > > To me, the litmus test is the expected behavior for > this example: > > container top { > leaf foo { > type string; > } > leaf bar { > type string; > default 'barney'; > } > leaf baz { > type string; > mandatory true; > } > } > > > Client Creates: > > > > wilma > > So 'foo' is "server assigned"? > Server Contains: > (i.e., this is returned if with-defaults=report-all) > > > > fred > barney > wilma > > > > > What happens when a for a server-supplied > leaf is issued, without any :with-defaults support? > > > > > > > > > > > I can only speak for - if the server does not store defaults (with-defaults basic mode 'explicit'), bar will not be returned. As for foo, personally I would like it to be included, i.e. a server assigned value will always be part of the config, but it all depends on if/when the WG do 'server-assigned'. > We know that that the server can skip over defaults if > the request is for an ancestor node of the default leaf, > but what if the request is directly for the specified leaf? > I think Lada brought up this issue before. It will not be returned. /martin From andy@netconfcentral.com Tue Aug 25 08:34:59 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 BE4C428C42B for ; Tue, 25 Aug 2009 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 AELxHq1TWXFz for ; Tue, 25 Aug 2009 08:34:59 -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 724A728C4B6 for ; Tue, 25 Aug 2009 08:34:41 -0700 (PDT) Received: (qmail 761 invoked from network); 25 Aug 2009 15:34:45 -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; 25 Aug 2009 15:34:44 -0000 X-YMail-OSG: z6i_r80VM1n5meFig6jN3QmoXB0Tgvoeq7pszrLBSMNWwPXOL5z7CnT7JFLMXcSX_eOtTLLDw.Ng2.5UE4fN38ou9q1.dgsL5bKaTbNyewP4FFo.mHfjHHVnYNnZDyCLvjxqKS..6_R9_fVeIrfFezYFfyjgnSkf77r74qTxfPxeKhsvTM.NN0sVue1Vxq4gRLdlWPfJVsOZ2GPvFKLhKpN7ZtYZ1AVbwxSoEUZbbSu9EXvVFxchHPqTlPVmWjwEAfZ3dnROeAevFXPEX4nAzRiwpVF6thJTfm7NDoj3xOLrCRbTcq.IqaxMgJF62kwS._a9KSO8F81SSvsK1dMj8hfVuDNdnlZcQ7Rps28iPtKZyIe_mQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A940498.4090409@netconfcentral.com> Date: Tue, 25 Aug 2009 08:34:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A93F750.7010001@netconfcentral.com> <20090825.165000.137852161.mbj@tail-f.com> <4A93FE86.8080709@netconfcentral.com> <20090825.172027.98363293.mbj@tail-f.com> In-Reply-To: <20090825.172027.98363293.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, 25 Aug 2009 15:34:59 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>>> OK. That is related the issue whether default leaves belong to the >>>>> config. Since majority does not think default leaves belong to the >>>>> config. i.e., no default leaves exist in data tree, i.e., no instance at >>>>> all. >>>>> I am fine with that. >>>>> >>>> I am not convinced this is the WG consensus. >>> Wait! The text is written so that it allows the server to handle >>> defaults in any of the three ways described in the with-defaults I-D. >>> >>> Do any of you want to change this text now? >>> >> There is lots of text scattered throughout the draft. >> There is text that says (for must and when expressions) >> the set of defaults are included in the server data set. >> >> To me, the litmus test is the expected behavior for >> this example: >> >> container top { >> leaf foo { >> type string; >> } >> leaf bar { >> type string; >> default 'barney'; >> } >> leaf baz { >> type string; >> mandatory true; >> } >> } >> >> >> Client Creates: >> >> >> >> wilma >> >> > > So 'foo' is "server assigned"? > yes -- on this server, at this moment. It is undocumented, so you cannot assume anything about past or future instances of the leaf. >> Server Contains: >> (i.e., this is returned if with-defaults=report-all) >> >> >> >> fred >> barney >> wilma >> >> >> >> >> What happens when a for a server-supplied >> leaf is issued, without any :with-defaults support? >> >> >> >> >> >> >> >> >> >> >> > > I can only speak for - if the server does not store defaults > (with-defaults basic mode 'explicit'), bar will not be returned. > > As for foo, personally I would like it to be included, i.e. a server > assigned value will always be part of the config, but it all depends > on if/when the WG do 'server-assigned'. > >> We know that that the server can skip over defaults if >> the request is for an ancestor node of the default leaf, >> but what if the request is directly for the specified leaf? >> I think Lada brought up this issue before. > > It will not be returned. > I do not think this meets the minimum level of interoperability that an application developer needs to utilize this standard. I wonder what the IESG will think. We never had this behavior with SMIv2 and SNMP. I can't even imagine how much harder it would have been on the NMS developers, if get-next randomly skipped over nodes the user was authorized to retrieve. When 4741 was written, the concept that some vendors would omit portions of the data never came up. It was assumed the only filters were those defined in the standard. The idea that the server can contain configuration data which affects device behavior, but the client never needs to see it, is incorrect, and harmful to interoperability. It may be a goal of the NETCONF and NETMOD WGs to reflect industry practice and just expose the native API. That is fine, but it does not take precedence over the IETF's goal to achieve real protocol interoperability. > > /martin > Andy From phil@juniper.net Tue Aug 25 10:07: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 4F4933A6B32 for ; Tue, 25 Aug 2009 10:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 OM-3mSisKO-f for ; Tue, 25 Aug 2009 10:07:03 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id E2CBB3A69BD for ; Tue, 25 Aug 2009 10:05:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSpQZ+bX8Dkv+6GqeZ5ay/izSH5T97klZ@postini.com; Tue, 25 Aug 2009 10:07:10 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, 25 Aug 2009 10:01:15 -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, 25 Aug 2009 10:01:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:01:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:01:13 -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 n7PH1Cd44023; Tue, 25 Aug 2009 10:01: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 n7PGnFUY003708; Tue, 25 Aug 2009 16:49:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908251649.n7PGnFUY003708@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A93F912.5070508@netconfcentral.com> Date: Tue, 25 Aug 2009 12:49:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 17:01:13.0653 (UTC) FILETIME=[A715B650:01CA25A5] 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, 25 Aug 2009 17:07:04 -0000 Andy Bierman writes: >This is not true if the server supports :candidate >and :with-defaults capabilities. Then the client >can lock the candidate, create any portion of the config, >and retrieve it with-defaults=report-all. Translate that use case into real-world activity. If my application wants to display the default value for to some GUI user while he's building an ethernet interface, I need to: - lock the database - fake an entry - re-fetch w/defaults - discard changes - unlock Imho this is unworkable. Thanks, Phil From phil@juniper.net Tue Aug 25 10:09:59 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 37C243A6D9E for ; Tue, 25 Aug 2009 10:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 XNaySQ9Ng6a0 for ; Tue, 25 Aug 2009 10:09:58 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 92C8C3A6AC1 for ; Tue, 25 Aug 2009 10:09:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSpQa6WiDUHqdytIr5izUdUNFx3xTvqya@postini.com; Tue, 25 Aug 2009 10:10:05 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, 25 Aug 2009 10:04:45 -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, 25 Aug 2009 10:04:45 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:04:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:04:43 -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 n7PH4hd45347; Tue, 25 Aug 2009 10:04:43 -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 n7PGqkqO003777; Tue, 25 Aug 2009 16:52:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908251652.n7PGqkqO003777@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090825.172027.98363293.mbj@tail-f.com> Date: Tue, 25 Aug 2009 12:52:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 17:04:43.0880 (UTC) FILETIME=[2463CE80:01CA25A6] 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, 25 Aug 2009 17:09:59 -0000 >Andy Bierman wrote: >> We know that that the server can skip over defaults if >> the request is for an ancestor node of the default leaf, >> but what if the request is directly for the specified leaf? Martin Bjorklund writes: >It will not be returned. I agree with Martin, and agree that this is an issue that was decided long ago. Let's stop redesigning at last call. Thanks, Phil From andy@netconfcentral.com Tue Aug 25 10:32: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 8D3883A6EAB for ; Tue, 25 Aug 2009 10:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 9njaACoSxcUX for ; Tue, 25 Aug 2009 10:32:38 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id B53EC3A6F56 for ; Tue, 25 Aug 2009 10:32:38 -0700 (PDT) Received: from [209.191.108.97] by n17.bullet.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 17:32:36 -0000 Received: from [68.142.201.253] by t4.bullet.mud.yahoo.com with NNFMP; 25 Aug 2009 17:32:36 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 17:32:36 -0000 X-Yahoo-Newman-Id: 481593.37874.bm@omp414.mail.mud.yahoo.com Received: (qmail 51226 invoked from network); 25 Aug 2009 17:32:35 -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; 25 Aug 2009 17:32:35 -0000 X-YMail-OSG: Rf6Wk9cVM1kAGil47F6fw9h14fQXoV17vCmS1nspM7YxbYfO0ob2oqkEhGOHbBJtARnVEPLZ4CdaCOQdkSlpUB3xaNI4iiS1g9xnBnatsRRY7yzPwPjhuskUb54iXtg0KBWhDKeRT59ouoc66cETHMaujxDzX7TcgZGrBcubsaNeFEDBzF8SSuy44Va.GYfKC1MpMw0bZGhH4Brx84DisYdII3FN2P7bxbuJClpCdsFXnZQaPHE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A941FBE.9020201@netconfcentral.com> Date: Tue, 25 Aug 2009 10:30:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908251649.n7PGnFUY003708@idle.juniper.net> In-Reply-To: <200908251649.n7PGnFUY003708@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, 25 Aug 2009 17:32:39 -0000 Phil Shafer wrote: > Andy Bierman writes: >> This is not true if the server supports :candidate >> and :with-defaults capabilities. Then the client >> can lock the candidate, create any portion of the config, >> and retrieve it with-defaults=report-all. > > Translate that use case into real-world activity. If my application > wants to display the default value for to some GUI user while > he's building an ethernet interface, I need to: > > - lock the database > - fake an entry > - re-fetch w/defaults > - discard changes > - unlock > > Imho this is unworkable. > IMO this is simple, easy to use, deterministic, and already fully supported when :candidate and :with-defaults are enabled in the server. I can't imagine server code that would know the user was faking an entry, vs. creating a real scratchpad entry. This takes an operator all of a few minutes to complete. Looking up all the relevant vendor documentation, especially for leafs without YANG default statements, may not even be possible. Even if it is found, there could be a bug in the server, so the documentation is wrong. Retrieving the actual values in use at a particular moment is the best way for an operator to discover all the configuration parameter values affecting server behavior. > Thanks, > Phil > Andy From phil@juniper.net Tue Aug 25 10:36:01 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 8F8A73A6EAB for ; Tue, 25 Aug 2009 10:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Ind7E28k7YMN for ; Tue, 25 Aug 2009 10:36:00 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id C66DE3A6EF7 for ; Tue, 25 Aug 2009 10:35:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSpQhBKsvsBwR80UNv8lVCfD+HU7u/aya@postini.com; Tue, 25 Aug 2009 10:36:07 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, 25 Aug 2009 10:31:31 -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, 25 Aug 2009 10:31:31 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:31:30 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:31:30 -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 n7PHVTd59412; Tue, 25 Aug 2009 10:31:29 -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 n7PHJW2f004030; Tue, 25 Aug 2009 17:19:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908251719.n7PHJW2f004030@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A940498.4090409@netconfcentral.com> Date: Tue, 25 Aug 2009 13:19:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 17:31:30.0095 (UTC) FILETIME=[E1C4C3F0:01CA25A9] 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, 25 Aug 2009 17:36:01 -0000 Andy Bierman writes: >I wonder what the IESG will think. My hope is that they will understand what the word "default" means. It doesn't mean spontaneously appearing values, but values that are used when no value is given. If no value is given, then the non-value isn't part of the configuration, but the system will use the default value instead of failing. When I use "ping" with the default packet size, it doesn't rewrite my command line with that value. It uses the default value internally instead of failing with an error saying that it needs a packet size. When I edit /etc/rc.conf, I only enter the vital information, not page after page of values I do not care about. When the system boots up, no one rewrites /etc/rc.conf to include all the default values which I do not care about. When someone configures an interface in JUNOS, they don't need to specify values for the hundred or so configurables on that interface which they do not care about. When they view the configuration, I show them only what they have configured, not the hundred or so leafs that they did not. If I suggested that showing them this noise was a feature, I would be laughed off their network. I can't tell you what a bad idea populating default values into the configuration would be. I'm shocked we are still on this rat hole. >The idea that the server can contain configuration data which affects >device behavior, but the client never needs to see it, is incorrect, >and harmful to interoperability. The client can learn it from the YANG module. We are expecting clients to handle this, since the module will also tell the other vital information like keys, mandatory, ranges, and datatypes. If a client is not interested in learning the rules of the road as spelled out in the YANG module, I don't want that client managing my box. Do you believe we are writing YANG with the expectation that clients will be unwilling to parse and digest the information in YANG modules? >It may be a goal of the NETCONF and NETMOD WGs to reflect >industry practice and just expose the native API. That is >fine, but it does not take precedence over the IETF's >goal to achieve real protocol interoperability. I see no conflict between default values and interoperability. I see large conflict between bloated configurations and working networks. Thanks, Phil From andy@netconfcentral.com Tue Aug 25 10:39: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 81F5A3A6EF7 for ; Tue, 25 Aug 2009 10:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 Px5nxcA7C3Qt for ; Tue, 25 Aug 2009 10:39:33 -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 DF1583A6FA0 for ; Tue, 25 Aug 2009 10:39:17 -0700 (PDT) Received: (qmail 76993 invoked from network); 25 Aug 2009 17:39:24 -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; 25 Aug 2009 17:39:24 -0000 X-YMail-OSG: OY5J7WAVM1nIsiAEY1cgZLK1a7BxxCDyYMBuxJ91IQzeh0vRgcmlQk2cjTP2cjpLeZnNGsUtN9JriWWNzCKsnkbYpKmPI2htcCzlup5yrJpYDzVJ0w07II6t.6yHbW5EUqZQoim.JoR1D.8ZI_LfZR45TMbiELJj1sQLM8sgRjkLos5KIEzrKXhlYH7qf71G2_6Dy.GhhzWu3Hj2Y8b5bYFr1Fg6nQweTluX7QCKScDH8QT4jwGWYu_OPQ8QMrWyGdt75aclmEFyqBxlvGdDFNMVf5qGnKzCZdO1p0H3lebesYo4GrHtHK4f1JFgqvB.xqKcmQe37_2BX1DIyUuk5HS9kTn1lyOEr3AT6TfL4lIhnaaJ2A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A942154.9050005@netconfcentral.com> Date: Tue, 25 Aug 2009 10:37:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908251652.n7PGqkqO003777@idle.juniper.net> In-Reply-To: <200908251652.n7PGqkqO003777@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, 25 Aug 2009 17:39:34 -0000 Phil Shafer wrote: >> Andy Bierman wrote: >>> We know that that the server can skip over defaults if >>> the request is for an ancestor node of the default leaf, >>> but what if the request is directly for the specified leaf? > > Martin Bjorklund writes: >> It will not be returned. > > I agree with Martin, and agree that this is an issue that was decided > long ago. Let's stop redesigning at last call. > I understood the decision incorrectly. I thought it applied to retrieval of ancestor nodes, not to explicit retrieval requests. NETCONF has no explicit 'get' operation like SNMP, which is an interoperability problem. I thought an explicit request for a specific leaf instance would return the value in use, even if it was not set in some special way that makes a difference to this server's meaning of the term 'default'. Otherwise the standards value to an application developer is (IMO) too low to be approved by the IESG. > Thanks, > Phil > Andy From phil@juniper.net Tue Aug 25 10:48: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 495663A6FAE for ; Tue, 25 Aug 2009 10:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 aEsQJXGoaWlj for ; Tue, 25 Aug 2009 10:48:41 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id A39B23A68B3 for ; Tue, 25 Aug 2009 10:48:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSpQj+5S4LHph9BgMuaeAZBcMiakm5hMj@postini.com; Tue, 25 Aug 2009 10:48:48 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, 25 Aug 2009 10:41:36 -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, 25 Aug 2009 10:41:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:41:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:41:34 -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 n7PHfYd64944; Tue, 25 Aug 2009 10:41:34 -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 n7PHTbGw004226; Tue, 25 Aug 2009 17:29:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908251729.n7PHTbGw004226@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A941FBE.9020201@netconfcentral.com> Date: Tue, 25 Aug 2009 13:29:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 17:41:34.0687 (UTC) FILETIME=[4A222EF0:01CA25AB] 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, 25 Aug 2009 17:48:42 -0000 Andy Bierman writes: >This takes an operator all of a few minutes to complete. This isn't going anywhere, eh? As Randy Bush was fond of saying "I invite my competitors to architect their solution this way". Thanks, Phil From andy@netconfcentral.com Tue Aug 25 10:52: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 69ED43A6FBD for ; Tue, 25 Aug 2009 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 aDBfCNdzCUwL for ; Tue, 25 Aug 2009 10:52:04 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 4EDD43A6FBA for ; Tue, 25 Aug 2009 10:52:04 -0700 (PDT) Received: from [209.191.108.96] by n17.bullet.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 17:52:10 -0000 Received: from [68.142.201.68] by t3.bullet.mud.yahoo.com with NNFMP; 25 Aug 2009 17:52:10 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 17:52:10 -0000 X-Yahoo-Newman-Id: 411271.3892.bm@omp420.mail.mud.yahoo.com Received: (qmail 77832 invoked from network); 25 Aug 2009 17:52:09 -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; 25 Aug 2009 17:52:09 -0000 X-YMail-OSG: LJBu3asVM1kUcUR7YXv7yhjTJPz_z5cWgtPKuvGpi879pygqx_zYsMe5H.08rcPh_20NnPHC1p7ND6iMsqnjVWpcMQuu6h3dmPaCg1OETxR1EBU.Lvh5EWfFZeoXx5vQ2Tj0qMr9bQlQ57PU8srYBitOn9tPsIJyJExOcz0OcHIaI3lzJ1D20hPkiYgkC1c3lw0HmrE7bRMKZxXVNFj.aiM0B1uDS3UaDdwW5LQbRdkKKxZCzR0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A942450.9000801@netconfcentral.com> Date: Tue, 25 Aug 2009 10:50:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908251719.n7PHJW2f004030@idle.juniper.net> In-Reply-To: <200908251719.n7PHJW2f004030@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, 25 Aug 2009 17:52:05 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I wonder what the IESG will think. > > My hope is that they will understand what the word "default" means. > It doesn't mean spontaneously appearing values, but values that are > used when no value is given. If no value is given, then the non-value > isn't part of the configuration, but the system will use the default > value instead of failing. > > When I use "ping" with the default packet size, it doesn't rewrite > my command line with that value. It uses the default value internally > instead of failing with an error saying that it needs a packet size. > > When I edit /etc/rc.conf, I only enter the vital information, not > page after page of values I do not care about. When the system > boots up, no one rewrites /etc/rc.conf to include all the default > values which I do not care about. > > When someone configures an interface in JUNOS, they don't need to > specify values for the hundred or so configurables on that interface > which they do not care about. When they view the configuration, I > show them only what they have configured, not the hundred or so > leafs that they did not. If I suggested that showing them this > noise was a feature, I would be laughed off their network. > > I can't tell you what a bad idea populating default values into the > configuration would be. I'm shocked we are still on this rat hole. > >> The idea that the server can contain configuration data which affects >> device behavior, but the client never needs to see it, is incorrect, >> and harmful to interoperability. > > The client can learn it from the YANG module. We are expecting > clients to handle this, since the module will also tell the other > vital information like keys, mandatory, ranges, and datatypes. If > a client is not interested in learning the rules of the road as > spelled out in the YANG module, I don't want that client managing > my box. > > Do you believe we are writing YANG with the expectation > that clients will be unwilling to parse and digest the > information in YANG modules? > >> It may be a goal of the NETCONF and NETMOD WGs to reflect >> industry practice and just expose the native API. That is >> fine, but it does not take precedence over the IETF's >> goal to achieve real protocol interoperability. > > I see no conflict between default values and interoperability. I > see large conflict between bloated configurations and working > networks. > We are in strong disagreement here. If the operator explicitly selects a leaf in the , or uses with-defaults=report-all, then the operator knows best, not you (the vendor). I am not referring to other types of retrieval requests. IMO, there MUST be a way for an operator to retrieve all the nodes, even those that have some strange definition of a default value. The only way to do that in NETCONF is to construct a subtree or XPath filter that explicitly selects the desired leaf. This is not nearly as good as the SNMP Get PDU, but oh well. I don't not think the solution to let every server decide what a default means, and what nodes are going to be retrievable, has any standards value to an application developer attempting to use the YANG and NETCONF standards. > Thanks, > Phil > Andy From andy@netconfcentral.com Tue Aug 25 10:52: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 908823A6FBA for ; Tue, 25 Aug 2009 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 wMEjwx55JDna for ; Tue, 25 Aug 2009 10:52:04 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id A5E993A6FBB for ; Tue, 25 Aug 2009 10:52:04 -0700 (PDT) Received: from [209.191.108.96] by n17.bullet.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 17:52:08 -0000 Received: from [68.142.201.251] by t3.bullet.mud.yahoo.com with NNFMP; 25 Aug 2009 17:52:08 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 17:52:08 -0000 X-Yahoo-Newman-Id: 939657.68018.bm@omp412.mail.mud.yahoo.com Received: (qmail 67394 invoked from network); 25 Aug 2009 17:52:08 -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; 25 Aug 2009 17:52:08 -0000 X-YMail-OSG: LUNfVA0VM1nm5ZyfuW1RPTW3CdrTfvZiKy_cOWElj2XpqlAQdeezMWNxiIpTnruidqnZFs3eRVU2BuZil9I7YY9BgBMpnyhZK0l7SIuH2R7SPuUq.tv2_95Uj6T9rU0dg.BexIC1VBz2Se4nmdUdVtscP1aH1.I4R5DrKmDOIoq5UaNh8yvXRT9OB2Xu1YvrKitxYgv6ejQ52C847R3pFs0lv1TqUWd5xaSk59UVhjNpN54G92w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9424CC.9060302@netconfcentral.com> Date: Tue, 25 Aug 2009 10:52:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908251729.n7PHTbGw004226@idle.juniper.net> In-Reply-To: <200908251729.n7PHTbGw004226@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, 25 Aug 2009 17:52:05 -0000 Phil Shafer wrote: > Andy Bierman writes: >> This takes an operator all of a few minutes to complete. > > This isn't going anywhere, eh? As Randy Bush was fond of saying > "I invite my competitors to architect their solution this way". > you don't understand that :candidate+:with-defaults already supports what you call unworkable? > Thanks, > Phil > Andy From phil@juniper.net Tue Aug 25 10: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 E2BE328C4A7 for ; Tue, 25 Aug 2009 10:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Ol9uynGKOUTz for ; Tue, 25 Aug 2009 10:54:54 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 3A08628C4D4 for ; Tue, 25 Aug 2009 10:54:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSpQlTUOpMPUrcIe7YUDqQAMIw9GeR5kM@postini.com; Tue, 25 Aug 2009 10:54:33 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, 25 Aug 2009 10:50:30 -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, 25 Aug 2009 10:50:30 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:50:29 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:50:29 -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 n7PHoSd68747; Tue, 25 Aug 2009 10:50:28 -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 n7PHcV5F004326; Tue, 25 Aug 2009 17:38:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908251738.n7PHcV5F004326@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A942154.9050005@netconfcentral.com> Date: Tue, 25 Aug 2009 13:38:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 17:50:29.0558 (UTC) FILETIME=[88F10560:01CA25AC] 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, 25 Aug 2009 17:54:55 -0000 Andy Bierman writes: >I thought an explicit request for a specific leaf instance >would return the value in use, even if it was not set in >some special way that makes a difference to this server's >meaning of the term 'default'. "specific leaf instance" and "in use" imply that there's something there, but this is configuration data, not state data. Try this: Consider that configuration data is instructions from the user to the system that tell it what to do. The default value is the value that is used when a piece of the instructions are not given by the user. If I ask the server for a piece of the instructions, I'm asking it to tell me what I told it to do. If I didn't ask it to do something, then there are no instructions and it should tell me that I didn't tell it anything. It should not tell me what it might do since I didn't give it specific instructions. Thanks, Phil From andy@netconfcentral.com Tue Aug 25 11:13: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 AF3A83A6FCD for ; Tue, 25 Aug 2009 11:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 6U-srAzxHGg5 for ; Tue, 25 Aug 2009 11:13:06 -0700 (PDT) Received: from n63.bullet.mail.sp1.yahoo.com (n63.bullet.mail.sp1.yahoo.com [98.136.44.33]) by core3.amsl.com (Postfix) with SMTP id 965B13A68B2 for ; Tue, 25 Aug 2009 11:12:56 -0700 (PDT) Received: from [69.147.84.144] by n63.bullet.mail.sp1.yahoo.com with NNFMP; 25 Aug 2009 18:13:01 -0000 Received: from [209.191.108.96] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 25 Aug 2009 18:13:01 -0000 Received: from [68.142.201.72] by t3.bullet.mud.yahoo.com with NNFMP; 25 Aug 2009 18:13:01 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 18:13:01 -0000 X-Yahoo-Newman-Id: 101244.52968.bm@omp424.mail.mud.yahoo.com Received: (qmail 72907 invoked from network); 25 Aug 2009 18:13:00 -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; 25 Aug 2009 18:13:00 -0000 X-YMail-OSG: FKyfs7IVM1n9J7hKD5OGeIvSOrx7JHH4vFdp_Zp3TjuqcZQMOxhU5Z1cKR44jsDTEqQ5Ix_eYZ.uVaFKof8oYVxW_WA6dzyEZRcOcYPyVr_LhEDLMRNBgUTpElOz.LMfVqGjmBbXsqM9it9FrY68AWN5rGFyqqaZffBO1BfMn6CUWWN9ZbyI4sIL0JQ09qOumTlud4ViNtNp7V6XgZ4Yk9PZWNPgv1rBAPefnoOkRhI5lB6DDZo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9429B0.9010203@netconfcentral.com> Date: Tue, 25 Aug 2009 11:13:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908251738.n7PHcV5F004326@idle.juniper.net> In-Reply-To: <200908251738.n7PHcV5F004326@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, 25 Aug 2009 18:13:07 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I thought an explicit request for a specific leaf instance >> would return the value in use, even if it was not set in >> some special way that makes a difference to this server's >> meaning of the term 'default'. > > "specific leaf instance" and "in use" imply that there's something > there, but this is configuration data, not state data. > > Try this: Consider that configuration data is instructions from the > user to the system that tell it what to do. The default value is > the value that is used when a piece of the instructions are not > given by the user. > > If I ask the server for a piece of the instructions, I'm asking it > to tell me what I told it to do. If I didn't ask it to do something, > then there are no instructions and it should tell me that I didn't > tell it anything. It should not tell me what it might do since I > didn't give it specific instructions. > We do not view the problem space the same way. When I am debugging, I assume nothing, and trust nothing until it is verified. Normally, I don't want to look at the server-supplied config=true leafs. But normally, everything works. By definition, if I'm debugging, then something doesn't work. If I just assume that every possible setting in the server is just fine, then I don't know much about debugging, and could be at it forever, assuming only my settings could possibly be responsible for the current network problem. The WG consensus is that this is an optional server feature (:with-defaults). So I guess the market will decide if servers without this debugging feature are useful or not. I can't imagine any 3rd party application developer bothering with NETCONF/YANG at all, but YMMV. > Thanks, > Phil > Andy From phil@juniper.net Tue Aug 25 11:16: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 430C93A6981 for ; Tue, 25 Aug 2009 11:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Jf8CQfWeOya5 for ; Tue, 25 Aug 2009 11:16:27 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id DB54F3A6AE8 for ; Tue, 25 Aug 2009 11:16:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSpQqf+t0DWgb5Mt/aMblIOFswMmdNHM9@postini.com; Tue, 25 Aug 2009 11:16:34 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, 25 Aug 2009 11:10:09 -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, 25 Aug 2009 11:10:09 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 11:10:07 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 11:10:07 -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 n7PIA5d79834; Tue, 25 Aug 2009 11:10:05 -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 n7PHw8Hh004859; Tue, 25 Aug 2009 17:58:08 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908251758.n7PHw8Hh004859@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9424CC.9060302@netconfcentral.com> Date: Tue, 25 Aug 2009 13:58:08 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 18:10:07.0535 (UTC) FILETIME=[47120BF0:01CA25AF] 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, 25 Aug 2009 18:16:32 -0000 Andy Bierman writes: >you don't understand that :candidate+:with-defaults >already supports what you call unworkable? I think expecting to touch production boxes in non-maintenance windows to learn default values that are available in YANG modules would get me a thrashing by my customers. Thanks, Phil From phil@juniper.net Tue Aug 25 11:25:01 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 321E33A6B9F for ; Tue, 25 Aug 2009 11:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 V8lPLMO2R8TQ for ; Tue, 25 Aug 2009 11:25:00 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id B50EA3A6A07 for ; Tue, 25 Aug 2009 11:21:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSpQryBdysJ1AqanS+Qx1bKeJ+aGQk1Y2@postini.com; Tue, 25 Aug 2009 11:22:04 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, 25 Aug 2009 11:16:40 -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, 25 Aug 2009 11:16:40 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 11:16:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 11:16:39 -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 n7PIGcd83774; Tue, 25 Aug 2009 11:16: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 n7PI4flf004943; Tue, 25 Aug 2009 18:04:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908251804.n7PI4flf004943@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A942450.9000801@netconfcentral.com> Date: Tue, 25 Aug 2009 14:04:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2009 18:16:39.0251 (UTC) FILETIME=[308D2A30:01CA25B0] 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, 25 Aug 2009 18:25:01 -0000 Andy Bierman writes: >If the operator explicitly selects a leaf in the , >or uses with-defaults=report-all, then the operator knows best, >not you (the vendor). When the user explicitly adds a leaf, they are adding it to their set of instructions. I treat it as a piece of vital data. >I am not referring to other types of retrieval requests. You asked: >>>> What happens when a for a server-supplied >>>> leaf is issued, without any :with-defaults support? >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >I don't not think the solution to let every server decide >what a default means, and what nodes are going to be >retrievable, has any standards value to an application >developer attempting to use the YANG and NETCONF standards. I don't recall anyone suggesting that every server can decide a default means. Thanks, Phil From cfinss@dial.pipex.com Tue Aug 25 11:25: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 9FCE33A6FC6 for ; Tue, 25 Aug 2009 11:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 wnOU0KTyD4pJ for ; Tue, 25 Aug 2009 11:25:23 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 92A463A6FD5 for ; Tue, 25 Aug 2009 11:25:23 -0700 (PDT) X-Trace: 244290863/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.133/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.133 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: AqIEAOPIk0o+vGmF/2dsb2JhbACDLWCNEMgdCYQRBQ X-IronPort-AV: E=Sophos;i="4.44,273,1249254000"; d="scan'208";a="244290863" X-IP-Direction: IN Received: from 1cust133.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.133]) by smtp.pipex.tiscali.co.uk with SMTP; 25 Aug 2009 19:25:26 +0100 Message-ID: <006501ca25a8$df9ca940$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <20090824.102033.118206378.mbj@tail-f.com><000201ca255f$2992fc60$0601a8c0@allison> <20090825.120011.261510938.mbj@tail-f.com> Date: Tue, 25 Aug 2009 18:35:20 +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] bit statement bug 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, 25 Aug 2009 18:25:24 -0000 Martin OK Tom Petch ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, August 25, 2009 12:00 PM Subject: Re: [netmod] bit statement bug > Hi, > > "tom.petch" wrote: > > Yes, it works, > > So far, I am not introducing this change. Andy was against, Juergen > was maybe for it. But your comments apply to the original text as > well. > > > but ... terminology. A minor point here but typical of > > what can be a bigger one elsewhere. > > > > Reading this suggests to me we have a concept of 'assigned name' which > > would then be different from a name which is of course different from > > an identifier:-) > > Section 9.7 says: > > The bits built-in type represents a bit set. That is, a bits value > is a set of flags identified by small integer position numbers > starting at 0. Each bit number has an assigned name. > > So this is where the "assigned name" is defined. Now, I guess we > could s/assigned name/name/ but would that really solve a real > problem? (we'd have to do it form enums as well). > > > I am (again) left unsure if I know what it means - really. > > And you have omitted the next sentence which then refers not to 'assigned > > name' but to 'bit names':-( > > Fixed. bit names is now assigned name. > > > At a tangent, I suggest in the ABNF comment for WSP > > /white space/whitespace/ > > Fixed. > > > /martin From cfinss@dial.pipex.com Tue Aug 25 11:25: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 DEA5D3A684E for ; Tue, 25 Aug 2009 11:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, 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 OIsq-n73puZ0 for ; Tue, 25 Aug 2009 11:25:38 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id BC5B93A6B9F for ; Tue, 25 Aug 2009 11:25:37 -0700 (PDT) X-Trace: 244290866/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.133/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.133 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: AqIEABTKk0o+vGmF/2dsb2JhbACDLWCNEMd8CYQRBYFT X-IronPort-AV: E=Sophos;i="4.44,273,1249254000"; d="scan'208";a="244290866" X-IP-Direction: IN Received: from 1cust133.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.133]) by smtp.pipex.tiscali.co.uk with SMTP; 25 Aug 2009 19:25:28 +0100 Message-ID: <006601ca25a8$e076dca0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "WashamFan" References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <4A938B5E.4020100@tail-f.com> <4A93F750.7010001@netconfcentral.com> Date: Tue, 25 Aug 2009 19:21:43 +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] meaning of config really 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: Tue, 25 Aug 2009 18:25:39 -0000 ----- Original Message ----- From: "Andy Bierman" To: "WashamFan" Cc: Sent: Tuesday, August 25, 2009 4:38 PM Subject: Re: [netmod] meaning of default > WashamFan wrote: > > > > ----- Original Message ----- > > From: Per Hedeland > > Date: Tuesday, August 25, 2009 2:58 pm > > Subject: Re: [netmod] meaning of default > >> > >> I disagree, on two counts. First, the leaf isn't created at all in the > >> relevant case, neither implicitly nor explicitly. It is created by > >> giving it a value, at which point the default value becomes irrelevant. > > > > OK. That is related the issue whether default leaves belong to the > > config. Since majority does not think default leaves belong to the > > config. i.e., no default leaves exist in data tree, i.e., no instance at all. > > I am fine with that. > > > I am not convinced this is the WG consensus. > Will the co-Chairs please confirm. > > I believe the WG consensus is that server-supplied values are > actually present. The server is not required to return > those leafs unless the :with-defaults capability is supported. To quote a much-quoted phrase, "configuration data: The set of writable data that is required to transform a system from its initial default state into its current state " 'writable' tells me capable of being written to, even if noone in the world ever actually writes it. The alternative view, which keeps popping up, is 'The set of having been written data that has transformed the system from its initial default state into its current state " I think that the former prevails, but I am not too sure; I do think that this will not go away until we do something about it. I see server-generated values, which are writable, as part of configuration, perhaps even a writable leaf for which the server has not generated a value. Tom Petch > >> Second, I specifically wanted to avoid the "operational" description > >> that seems to be interpreted to mean that the usage of the default value > >> is dependent on who created what and how. Whether the default value MUST > >> be used can always be determined by observing the existing > >> configuration, in a manner that is very similar to how it is determined > >> that a leaf marked "mandatory" MUST exist. > > > > But the usage of the default value MUST be defined, I think Martin's > > proposal in another email is good. > > > > We are never going to agree that mandatory=true > means the client must set the leaf, because we cannot > agree on a 3rd state like 'server-assigned'. > > You cannot observe the current config and know for > certain what server-supplied values will be added > if a new subtree is added to the config. > > As Phil pointed out, you can only retrieve data from > the server that is already there. You have to read > the YANG file, and it may or may not have default-stmt > or description-stmt information that will help. > > SMIv2 is not nearly as precise as YANG > in this area, so we should be happy with a big improvement. > YANG has the default and description statements, and > both are optional-to-use. It is up to the data model > writer to make sure all relevant information is documented > in the YANG module. > > > > washam > > Andy From andy@netconfcentral.com Tue Aug 25 11:36: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 853B23A6B75 for ; Tue, 25 Aug 2009 11:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 osEws5QNeztM for ; Tue, 25 Aug 2009 11:36:33 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id E5C2E3A6B50 for ; Tue, 25 Aug 2009 11:36:33 -0700 (PDT) Received: (qmail 90488 invoked from network); 25 Aug 2009 18:36:38 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 25 Aug 2009 18:36:38 -0000 X-YMail-OSG: VHiQYwYVM1m50r5uYdp_qNhuXNlueBc9zhkP6wYJWzIBIDwano8_NZ1LpAQcJYJI0a5wfR4hKSTRuB6_XZoSoJbsFQNLSOePMN5nbIE02GBl1RLuLmjzT7W3JfVfgVBwEWW1qkj.Fc87j5JHReH2pE0P6zPCS7wDOJ7.rFQ5ubMO1CV_TNpISFczIGJZDqjNapL620qCFkXhPh6SXmgCFeM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A942EBF.1070605@netconfcentral.com> Date: Tue, 25 Aug 2009 11:34:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908251758.n7PHw8Hh004859@idle.juniper.net> In-Reply-To: <200908251758.n7PHw8Hh004859@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, 25 Aug 2009 18:36:34 -0000 Phil Shafer wrote: > Andy Bierman writes: >> you don't understand that :candidate+:with-defaults >> already supports what you call unworkable? > > I think expecting to touch production boxes in non-maintenance > windows to learn default values that are available in YANG modules > would get me a thrashing by my customers. > 1) Leafs without YANG default statements may not be documented in the YANG file. 2) This has no impact on the running network whatsoever, if the :candidate capability is implemented correctly. 3) It would be the network operator working for your customer spending 60 seconds instead of all day discovering this information. 4) Using some memory, then discarding the 'changes', is an operator decision, not a vendor decision. I guess this is going nowhere. I guess I'm the only one who thinks letting every server define its own undocumented meaning of a default, and therefore its own set of retrievable nodes for each YANG module, will impair interoperability for application developers. > Thanks, > Phil > Andy From Washam.Fan@huaweisymantec.com Tue Aug 25 11:53: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 610DE3A69A3 for ; Tue, 25 Aug 2009 11:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=0.021, 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 1VAcQ5yWXGdF for ; Tue, 25 Aug 2009 11:53:33 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 25E103A6F8D for ; Tue, 25 Aug 2009 11:52:59 -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.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KOY0011T4FKEG60@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 02:52:32 +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 <0KOY00A5B4FK9100@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 02:52:32 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 26 Aug 2009 02:52:32 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 26 Aug 2009 02:52:32 +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: <4A942450.9000801@netconfcentral.com> References: <200908251719.n7PHJW2f004030@idle.juniper.net> <4A942450.9000801@netconfcentral.com> 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, 25 Aug 2009 18:53:34 -0000 Hi, > IMO, there MUST be a way for an operator to retrieve all > the nodes, even those that have some strange definition > of a default value. The only way to do that in NETCONF > is to construct a subtree or XPath filter that explicitly > selects the desired leaf. This is not nearly as good > as the SNMP Get PDU, but oh well. > > I don't not think the solution to let every server decide > what a default means, and what nodes are going to be > retrievable, has any standards value to an application > developer attempting to use the YANG and NETCONF standards. Isn't that what :with-defaults is for? :with-defaults is introduced to manage defaults in a consistent way by users regardless of how servers handle them internally, IMO. Do you suggest :with-default should be mandatory-to-implement? washam From andy@netconfcentral.com Tue Aug 25 12: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 1569F28C336 for ; Tue, 25 Aug 2009 12:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 NdKvcFprsRVZ for ; Tue, 25 Aug 2009 12:02:03 -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 3F8F228C32E for ; Tue, 25 Aug 2009 12:02:03 -0700 (PDT) Received: (qmail 28176 invoked from network); 25 Aug 2009 19:01:46 -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; 25 Aug 2009 19:01:45 -0000 X-YMail-OSG: rb6tJlMVM1lZl54WpEPVaoroP.fwtrdw4wgAeZpVGAsV48yfrouCMxzb4wH9tFz3Lf7nLuf4WQGOVbR0Oe.Y7koSowgg0h_ZICguViAQU.YVeLeXflOsGMQNP3KlhexYF2AX.bwIhtaQcLWm4U9wf0sk4TBAorwYxXXpkOqiWLQt5tuwLaoOZaYHNLCAf69PQTIM1eBVvNvBRafvgMQuoxhL.BYaurxqAk.Q1GSDh1tcAyMFoUUbY8IdA.MP4pigUSTuRD3VSlpAY0kDirVx46iLKWmB5su7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9434A2.8020100@netconfcentral.com> Date: Tue, 25 Aug 2009 11:59:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" References: <200908241750.n7OHoE8Y094033@idle.juniper.net> <4A92F5C6.3030102@tail-f.com> <4A938B5E.4020100@tail-f.com> <4A93F750.7010001@netconfcentral.com> <006601ca25a8$e076dca0$0601a8c0@allison> In-Reply-To: <006601ca25a8$e076dca0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of config really 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: Tue, 25 Aug 2009 19:02:04 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "WashamFan" > Cc: > Sent: Tuesday, August 25, 2009 4:38 PM > Subject: Re: [netmod] meaning of default > >> WashamFan wrote: >>> ----- Original Message ----- >>> From: Per Hedeland >>> Date: Tuesday, August 25, 2009 2:58 pm >>> Subject: Re: [netmod] meaning of default >>>> I disagree, on two counts. First, the leaf isn't created at all in the >>>> relevant case, neither implicitly nor explicitly. It is created by >>>> giving it a value, at which point the default value becomes irrelevant. >>> OK. That is related the issue whether default leaves belong to the >>> config. Since majority does not think default leaves belong to the >>> config. i.e., no default leaves exist in data tree, i.e., no instance at > all. >>> I am fine with that. >>> >> I am not convinced this is the WG consensus. >> Will the co-Chairs please confirm. >> >> I believe the WG consensus is that server-supplied values are >> actually present. The server is not required to return >> those leafs unless the :with-defaults capability is supported. > > To quote a much-quoted phrase, > "configuration data: The set of writable data that is required to > transform a system from its initial default state into its current > state " > > 'writable' tells me capable of being written to, even if noone in > the world ever actually writes it. > > The alternative view, which keeps popping up, is > 'The set of having been written data that has transformed the > system from its initial default state into its current state " > > I think that the former prevails, but I am not too sure; I do think > that this will not go away until we do something about it. > > I see server-generated values, which are writable, as > part of configuration, perhaps even a writable leaf for which > the server has not generated a value. > agreed. According to the YANG spec, if they were not writable, then config=false. Although the default-stmt is allowed with config=false, so this 'magic filtering' problem has nothing to do with the config-stmt. The quote above is a normative reference to RFC 4741. We agreed that YANG is not redefining RFC 4741, so we are not going to change the YANG draft to use its own definition of configuration data (I hope). I cannot find any definition of a server-supplied default anywhere in the YANG document. According to the YANG draft, only leafs with a default (or typedef-inherited default) actually have a default value. (type1 below). Any other server-supplied leaf (type2 and type3 below) is undocumented. A server MAY create them, but the YANG spec does not actually say such nodes exist or not. The WG agreed that a server MAY create them, but it is still ignored in the spec. leaf type1 { type string; mandatory false; config true/false; default 'exact'; } leaf type2 { type string; mandatory false; config true/false; } leaf type3 { type string; mandatory true; config true/false; } > Tom Petch Andy From mbj@tail-f.com Tue Aug 25 13:50: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 72A1428C3D1 for ; Tue, 25 Aug 2009 13:50:30 -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 R458MlsAyxib for ; Tue, 25 Aug 2009 13:50: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 06DBC28C4CF for ; Tue, 25 Aug 2009 13:48: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 AD362616017; Tue, 25 Aug 2009 22:42:16 +0200 (CEST) Date: Tue, 25 Aug 2009 22:42:16 +0200 (CEST) Message-Id: <20090825.224216.118049693.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <006601ca25a8$e076dca0$0601a8c0@allison> References: <4A93F750.7010001@netconfcentral.com> <006601ca25a8$e076dca0$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] meaning of config really 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: Tue, 25 Aug 2009 20:50:30 -0000 "tom.petch" wrote: > To quote a much-quoted phrase, > "configuration data: The set of writable data that is required to > transform a system from its initial default state into its current > state " > > 'writable' tells me capable of being written to, even if noone in > the world ever actually writes it. "its current state" tells me that this "set of writable data" changes depending on the device's current state. So what the term "configuration data" means depends on the current state of the box (which presumably depends on how it is configured...) I am not sure what exactly you want to read into the quote above. > I see server-generated values, which are writable, as > part of configuration So do I. If we had a statement 'assigned-by system', the server would actually add the value to the config. As such, it would always be reported. /martin From andy@netconfcentral.com Tue Aug 25 14:09: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 14AA828C43A for ; Tue, 25 Aug 2009 14:09:41 -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 zMeZ90SVNHta for ; Tue, 25 Aug 2009 14:09:40 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 2270F3A689D for ; Tue, 25 Aug 2009 14:09:40 -0700 (PDT) Received: from [68.142.200.226] by n20.bullet.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 21:09:44 -0000 Received: from [68.142.201.247] by t7.bullet.mud.yahoo.com with NNFMP; 25 Aug 2009 21:09:44 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 25 Aug 2009 21:09:44 -0000 X-Yahoo-Newman-Id: 367021.93188.bm@omp408.mail.mud.yahoo.com Received: (qmail 85438 invoked from network); 25 Aug 2009 21:09:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 25 Aug 2009 21:09:43 -0000 X-YMail-OSG: 3p5E60kVM1kEOkRZRT0jIKbqm3AlirTeOZbF2y5Y_H.ocR2PlmIHSNouq103c0ysQWJxWVVuhW4uYhS2NfVdNy40Bd3Ses_E7HNkuZ6NQo.imEez_ZhV9BgPqwXuQ7UX8ytwjKLj4h383d2R0Heqq_KctB4GrLVfOxLXe9z6qvdhCdjBIqEQi1bvdWGcXhiq4HPiqbj3ma5679HnVi6c X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A94531B.9030205@netconfcentral.com> Date: Tue, 25 Aug 2009 14:09:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A93F750.7010001@netconfcentral.com> <006601ca25a8$e076dca0$0601a8c0@allison> <20090825.224216.118049693.mbj@tail-f.com> In-Reply-To: <20090825.224216.118049693.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 config really 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: Tue, 25 Aug 2009 21:09:41 -0000 Martin Bjorklund wrote: > "tom.petch" wrote: >> To quote a much-quoted phrase, >> "configuration data: The set of writable data that is required to >> transform a system from its initial default state into its current >> state " >> >> 'writable' tells me capable of being written to, even if noone in >> the world ever actually writes it. > > "its current state" tells me that this "set of writable data" changes > depending on the device's current state. So what the term > "configuration data" means depends on the current state of the box > (which presumably depends on how it is configured...) > > I am not sure what exactly you want to read into the quote above. > >> I see server-generated values, which are writable, as >> part of configuration > > So do I. If we had a statement 'assigned-by system', the server would > actually add the value to the config. As such, it would always be > reported. > this is much more than an existentialist discussion on server created leafs. It has an impact on the protocol as I (and others) have pointed out: - Do must statements apply to server-created leafs? - Do min-elements and max-elements constraints apply to server created leafs? - Do unique statement constraints apply to server-created leafs? - Are leafrefs allowed to contain values that exist only within a server-created leaf or leaf-list? - Are instance-identifiers (where require-instance=true) allowed to reference server-created leafs? - Do server-created leafs count as being a sibling node when deciding if a mandatory leaf is missing? - How does a client know which case is selected (if any) in an optional or mandatory choice, if only server-created nodes exist? - Does the nc:operation='create' fail if the client issues such an edit-config operation on a server-created leaf? - Does the nc:operation='delete' succeed if the client issues such an edit-config operation on a server-created leaf? - Does an XPath expression (must/when/select) encounter a missing-node or some value, if a server-created leaf is referenced? - Does a subtree filter with a select-node or a content-match node for a server-created leaf return any data, or not? Leaving all these questions unanswered does not meet the level of interoperability expectations I had for YANG. > > /martin > Andy From Washam.Fan@huaweisymantec.com Tue Aug 25 19:11: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 64D9C3A6CA3 for ; Tue, 25 Aug 2009 19:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.209 X-Spam-Level: X-Spam-Status: No, score=-0.209 tagged_above=-999 required=5 tests=[AWL=0.286, 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 rZ0wHyz180NT for ; Tue, 25 Aug 2009 19:11:51 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 665383A6BE0 for ; Tue, 25 Aug 2009 19:11:51 -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 <0KOY00GSSOR3IZ20@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 10:11:27 +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 <0KOY006ZAOR2Q000@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 10:11:27 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 26 Aug 2009 10:11:26 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 26 Aug 2009 10:11:26 +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: <4A935191.4090504@netconfcentral.com> References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> 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, 26 Aug 2009 02:11:52 -0000 Hi, ----- Original Message ----- From: Andy Bierman Date: Tuesday, August 25, 2009 10:52 am Subject: Re: [netmod] Configuration nodes was Re: meaning of defau To: Phil Shafer Cc: "netmod@ietf.org" > Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> The width-defaults ID assumes that all parameters ultimately are part > >> of the config and that only some of them happen to be magically > >> hidden. I am not convinced this is the right model; I am a big > fan of > >> the explicit config model where stuff not explicitely configured is > >> simply not part of the config datastore. In other words, the > >> operationally used values that are not configured live somewhere else > >> but not as part of the config. In the config file example shown above, > >> comment characters are used to indicate exactly that. > > > > Amen. One can look at this as two distinct problems: > > > > (a) Before I make a list item, what can I say about the > > leafs that I am not creating? > > ex: If I make an interface, but don't set the duplex, > > will it default to full, half, or auto? > > > > (b) After I create the list item, what can I learn > > about the leafs of the real instance of this item? > > ex: Now that I've made an interface, what is the > > duplex at this point in time? > > > > There are questions about giving feedback to the user of my application > > before they create the interface, but there are questions about the > > state of the interface that was defined in the configuration data. > > The interaction isn't as easy as the with-defaults ID makes it > > sound. > > > > With-defaults doesn't address (a) or (b). I can't do a with-defaults > > on a non-existant instance, so the source for (a) has to be the > > YANG module. And doing a with-defaults report-all for (b) will > > tell me the YANG default of "auto", not the current value of "full". > > "auto" may be interesting to know, but given that I had to write > > the code to find it for (a), finding it for (b) is trivial. > > You could design a duplex-admin leaf and > a duplex-operational leaf if you cared so much > about this little corner case. > > For every other type of leaf, (B) works fine. > (A) is the same result you get now, without with-defaults. > > The advantage of with-defaults=report-all is that it > clearly shows the actual values in use > on a specific agent at a specific time. > That can be really useful in debugging. > > Before making changes to the config, it is > often useful to know the current contents of the config. > After making changes to the config, it is > often useful to know exactly what happened. > > I agree with Juergen that the best way to really > make progress is to have interoperability test events, > and see if most implementations do things a certain > way, and only 1 or 2 implementations are off in the weeds, > wrt/ defaults. > > leaf foo { > type string; > } > > I am concerned that there will be many leafs of the type > above. Telling customers to just look up the CLI documentation > for all the server-provided leafs is fine, if you hate your customers. > > Using with-defaults=report-all is a million times less work > for them. There is also no substitute for a direct answer to > a direct question, at the time the information is needed. > Is the kinda server-supplied data returned when with-defaults=report-all or explicit or trim? How does :with-defaults see server-supplied data? defaults or config? washam From Washam.Fan@huaweisymantec.com Tue Aug 25 19:37: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 853A83A6934 for ; Tue, 25 Aug 2009 19:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[AWL=0.275, 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 x8K8gx+p5uyR for ; Tue, 25 Aug 2009 19:37:25 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 8B17C3A681E for ; Tue, 25 Aug 2009 19:37:25 -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 <0KOY00GFIPXIIZ30@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 10:36:55 +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 <0KOY0060EPXIWN10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 10:36:54 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 26 Aug 2009 10:36:54 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 26 Aug 2009 10:36:54 +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: <4A94531B.9030205@netconfcentral.com> References: <4A93F750.7010001@netconfcentral.com> <006601ca25a8$e076dca0$0601a8c0@allison> <20090825.224216.118049693.mbj@tail-f.com> <4A94531B.9030205@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] meaning of config really 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, 26 Aug 2009 02:37:26 -0000 Hi, ----- Original Message ----- From: Andy Bierman Date: Wednesday, August 26, 2009 5:11 am Subject: Re: [netmod] meaning of config really was meaning of default To: Martin Bjorklund Cc: cfinss@dial.pipex.com, Washam.Fan@huaweisymantec.com, netmod@ietf.org > Martin Bjorklund wrote: > > "tom.petch" wrote: > >> To quote a much-quoted phrase, > >> "configuration data: The set of writable data that is required to > >> transform a system from its initial default state into its current > >> state " > >> > >> 'writable' tells me capable of being written to, even if noone in > >> the world ever actually writes it. > > > > "its current state" tells me that this "set of writable data" changes > > depending on the device's current state. So what the term > > "configuration data" means depends on the current state of the box > > (which presumably depends on how it is configured...) > > > > I am not sure what exactly you want to read into the quote above. > > > >> I see server-generated values, which are writable, as > >> part of configuration > > > > So do I. If we had a statement 'assigned-by system', the server would > > actually add the value to the config. As such, it would always be > > reported. > > > > this is much more than an existentialist discussion on server > created leafs. It has an impact on the protocol as I (and others) have > pointed out: > > - Do must statements apply to server-created leafs? > - Do min-elements and max-elements constraints apply to > server created leafs? > - Do unique statement constraints apply to server-created leafs? > - Are leafrefs allowed to contain values that exist only > within a server-created leaf or leaf-list? > - Are instance-identifiers (where require-instance=true) allowed > to reference server-created leafs? > - Do server-created leafs count as being a sibling node when > deciding if > a mandatory leaf is missing? > - How does a client know which case is selected (if any) > in an optional or mandatory choice, if only server-created > nodes exist? > - Does the nc:operation='create' fail if the client issues > such an edit-config operation on a server-created leaf? > - Does the nc:operation='delete' succeed if the client issues > such an edit-config operation on a server-created leaf? > - Does an XPath expression (must/when/select) encounter a > missing-node or some value, if a server-created leaf is > referenced? > - Does a subtree filter with a select-node or a content-match > node for a server-created leaf return any data, or not? > > Leaving all these questions unanswered does not meet the > level of interoperability expectations I had for YANG. Why these questions are relevant to server-supplied nodes? These questions are relevant to instances existing in data tree, imo, and the rough consensus seems server-supplied nodes are in data tree. washam From andy@netconfcentral.com Tue Aug 25 19:42:01 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 0F1CD3A6934 for ; Tue, 25 Aug 2009 19:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 snTKmzchYgLr for ; Tue, 25 Aug 2009 19:41:59 -0700 (PDT) Received: from n72.bullet.mail.sp1.yahoo.com (n72.bullet.mail.sp1.yahoo.com [98.136.44.34]) by core3.amsl.com (Postfix) with SMTP id AF9FA3A681E for ; Tue, 25 Aug 2009 19:41:59 -0700 (PDT) Received: from [69.147.84.145] by n72.bullet.mail.sp1.yahoo.com with NNFMP; 26 Aug 2009 02:42:04 -0000 Received: from [68.142.200.225] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 26 Aug 2009 02:42:04 -0000 Received: from [68.142.201.240] by t6.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 02:42:04 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 02:42:04 -0000 X-Yahoo-Newman-Id: 87328.39306.bm@omp401.mail.mud.yahoo.com Received: (qmail 10928 invoked from network); 26 Aug 2009 02:42:03 -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; 26 Aug 2009 02:42:03 -0000 X-YMail-OSG: 6To7POAVM1krMb6ch9I1dBpnjDUMNL8Jdj1G9e6X0krhrEGs1vcUVAJvK0RFl7czMUIvDvdX4wGEH7ObfwGXPDdzoDPzB8TOov8nvn347a1ZE_boS6d.QgX.LULCpcncEi4CvHgdzauslcO_p.owLgI3O8mQHdTAoFwFJlbY46UJSLPGfHV89YU9JSL6sF2oUf8nE2Im.WuWBYh7jiEDb627rjzoHVZ6x0lbaj4IoLe.51k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A94A084.9020304@netconfcentral.com> Date: Tue, 25 Aug 2009 19:40:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> In-Reply-To: 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, 26 Aug 2009 02:42:01 -0000 WashamFan wrote: > Hi, > > ----- Original Message ----- > From: Andy Bierman > Date: Tuesday, August 25, 2009 10:52 am > Subject: Re: [netmod] Configuration nodes was Re: meaning of defau > To: Phil Shafer > Cc: "netmod@ietf.org" > > >> Phil Shafer wrote: >> > Juergen Schoenwaelder writes: >> >> The width-defaults ID assumes that all parameters ultimately are part >> >> of the config and that only some of them happen to be magically >> >> hidden. I am not convinced this is the right model; I am a big >> fan of >> >> the explicit config model where stuff not explicitely configured is >> >> simply not part of the config datastore. In other words, the >> >> operationally used values that are not configured live somewhere else >> >> but not as part of the config. In the config file example shown above, >> >> comment characters are used to indicate exactly that. >> > >> > Amen. One can look at this as two distinct problems: >> > >> > (a) Before I make a list item, what can I say about the >> > leafs that I am not creating? >> > ex: If I make an interface, but don't set the duplex, >> > will it default to full, half, or auto? >> > >> > (b) After I create the list item, what can I learn >> > about the leafs of the real instance of this item? >> > ex: Now that I've made an interface, what is the >> > duplex at this point in time? >> > >> > There are questions about giving feedback to the user of my application >> > before they create the interface, but there are questions about the >> > state of the interface that was defined in the configuration data. >> > The interaction isn't as easy as the with-defaults ID makes it >> > sound. >> > >> > With-defaults doesn't address (a) or (b). I can't do a with-defaults >> > on a non-existant instance, so the source for (a) has to be the >> > YANG module. And doing a with-defaults report-all for (b) will >> > tell me the YANG default of "auto", not the current value of "full". >> > "auto" may be interesting to know, but given that I had to write >> > the code to find it for (a), finding it for (b) is trivial. >> >> You could design a duplex-admin leaf and >> a duplex-operational leaf if you cared so much >> about this little corner case. >> >> For every other type of leaf, (B) works fine. >> (A) is the same result you get now, without with-defaults. >> >> The advantage of with-defaults=report-all is that it >> clearly shows the actual values in use >> on a specific agent at a specific time. >> That can be really useful in debugging. >> >> Before making changes to the config, it is >> often useful to know the current contents of the config. >> After making changes to the config, it is >> often useful to know exactly what happened. >> >> I agree with Juergen that the best way to really >> make progress is to have interoperability test events, >> and see if most implementations do things a certain >> way, and only 1 or 2 implementations are off in the weeds, >> wrt/ defaults. >> >> leaf foo { >> type string; >> } >> >> I am concerned that there will be many leafs of the type >> above. Telling customers to just look up the CLI documentation >> for all the server-provided leafs is fine, if you hate your customers. >> >> Using with-defaults=report-all is a million times less work >> for them. There is also no substitute for a direct answer to >> a direct question, at the time the information is needed. >> > > Is the kinda server-supplied data returned when with-defaults=report-all or > explicit or trim? How does :with-defaults see server-supplied data? defaults > or config? > The report-all enum is the only mandatory-to-implement option. This option returns everything the server contains, and does not filter out any nodes based on any definition of the term 'default'. The definition of the term 'all' in 'report-all' is consistent with the Merriam Webster definition of that word: http://www.merriam-webster.com/dictionary/all > washam > Andy From j.schoenwaelder@jacobs-university.de Tue Aug 25 23:36: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 EDC713A691D for ; Tue, 25 Aug 2009 23:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.098, 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 EU+LBsyi9O8x for ; Tue, 25 Aug 2009 23:36:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B58413A690D for ; Tue, 25 Aug 2009 23:36:36 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD7FDC002F; Wed, 26 Aug 2009 08:36:41 +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 V2nJ0Ico-MuB; Wed, 26 Aug 2009 08:36:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7016FC0006; Wed, 26 Aug 2009 08:36:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ED699C7D76E; Wed, 26 Aug 2009 08:36:38 +0200 (CEST) Date: Wed, 26 Aug 2009 08:36:38 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090826063638.GA19116@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A935191.4090504@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 06:36:38 -0000 On Tue, Aug 25, 2009 at 04:50:57AM +0200, Andy Bierman wrote: > The advantage of with-defaults=report-all is that it > clearly shows the actual values in use > on a specific agent at a specific time. > That can be really useful in debugging. We are in agreement that the retrieval of the actual values in use is important. But "actual values in use" means operational state not necessarily config state. In fact, we will have both situations, and we need to support both. The first example concerns values that are operationally used like an interface MTU or the detected speed of an interface. In most cases, these parameters are not configuration data and we would IMHO make a mistake if we claim they are config data. On the other hand, we will have config objects where a manager creates say a list entry and additional config values will be assigned by the server. A good example here is creation of a user account where you let the server pick an unused uid if you do not provide one while setting up the list entry. But once the uid has been assigned by the server, it pretty much becomes config data (and so it show up when I do a get-config, regardless of any with-defaults options). How we model the distinction with YANG statements needs to be worked out. But in my preferred approach, I pretty much need a way to retrieve operational state that I can easily map to config state and it seems with-defaults is not really getting me there. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Aug 25 23:43: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 6E2533A6910 for ; Tue, 25 Aug 2009 23:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 FBLokm8lQqCt for ; Tue, 25 Aug 2009 23:43:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 922783A6881 for ; Tue, 25 Aug 2009 23:43:40 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6E2CC002F; Wed, 26 Aug 2009 08:43:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7YcWwqGk2vGK; Wed, 26 Aug 2009 08:43: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 288C3C0006; Wed, 26 Aug 2009 08:43:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D14E3C7D812; Wed, 26 Aug 2009 08:43:44 +0200 (CEST) Date: Wed, 26 Aug 2009 08:43:44 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090826064344.GB19116@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , "netmod@ietf.org" References: <4A93F912.5070508@netconfcentral.com> <200908251649.n7PGnFUY003708@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908251649.n7PGnFUY003708@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] 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, 26 Aug 2009 06:43:41 -0000 On Tue, Aug 25, 2009 at 06:49:15PM +0200, Phil Shafer wrote: > Andy Bierman writes: > >This is not true if the server supports :candidate > >and :with-defaults capabilities. Then the client > >can lock the candidate, create any portion of the config, > >and retrieve it with-defaults=report-all. > > Translate that use case into real-world activity. If my application > wants to display the default value for to some GUI user while > he's building an ethernet interface, I need to: > > - lock the database > - fake an entry > - re-fetch w/defaults > - discard changes > - unlock Nice to see that you prefer to write an explicit discard-changes in example code instead of relying on the unlock side effect. :-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Aug 25 23:43: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 8D7CE3A6910 for ; Tue, 25 Aug 2009 23:43:41 -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 UoY8uVx2lU4F for ; Tue, 25 Aug 2009 23:43:41 -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 CEBC43A6A1C for ; Tue, 25 Aug 2009 23:43: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 56FA176C59C; Wed, 26 Aug 2009 08:43:46 +0200 (CEST) Date: Wed, 26 Aug 2009 08:43:45 +0200 (CEST) Message-Id: <20090826.084345.103935325.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090826063638.GA19116@elstar.local> References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> 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] 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, 26 Aug 2009 06:43:41 -0000 Juergen Schoenwaelder wrote: > How we model the distinction with YANG statements needs to be worked > out. Do you believe we need to work this out for YANG 1.0? Will the introduction of 'assigned-by server' solve the issues people are seeing? /martin From j.schoenwaelder@jacobs-university.de Wed Aug 26 00:31: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 806533A707A for ; Wed, 26 Aug 2009 00:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 Rx-D6rvsjskJ for ; Wed, 26 Aug 2009 00:31:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 52CDB3A7078 for ; Wed, 26 Aug 2009 00:31:45 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EEFFC002F; Wed, 26 Aug 2009 09:31:49 +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 BSS0OM-i7owA; Wed, 26 Aug 2009 09:31: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 3566EC0006; Wed, 26 Aug 2009 09:31:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CD62BC7DABD; Wed, 26 Aug 2009 09:31:46 +0200 (CEST) Date: Wed, 26 Aug 2009 09:31:46 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090826073146.GA19221@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> <20090826.084345.103935325.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090826.084345.103935325.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 07:31:46 -0000 On Wed, Aug 26, 2009 at 08:43:45AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > How we model the distinction with YANG statements needs to be worked > > out. > > Do you believe we need to work this out for YANG 1.0? Given the intensive discussion here, I think we better work this out now. > Will the introduction of 'assigned-by server' solve the issues people > are seeing? The addition of 'assigned-by server' helps to make an important distinction in the YANG data model and I am in favour of this approach; I actually believe that marking config nodes the server can be expected to fill in is much more important that the default statement itself, which only handles static values and for many use cases you have to ue the description statement anyway. I am more concerned about the bigger picture: * This includes the with-defaults document - I would prefer we can settle on the 'explicit' model plus automatically 'assigned-by server' leafs - but then I personally would not even need the with-defaults extension at all since a get-config always gives me the entire config anyway. * The question how I can effectively retrieve operationally used state and relate it _easily_ to config state and how we deal with differences in value sets between config state and operational state requires some thought. So far, in both the NETMOD/NETCONF WGs, we have pretty much ignored this point and perhaps this has been OK so far but we are reaching a point where we need to spend some cycles on this. /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 Aug 26 01:43: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 0C9423A7033 for ; Wed, 26 Aug 2009 01:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 Txy-5e6VNm4l for ; Wed, 26 Aug 2009 01:43:23 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id D3E263A7006 for ; Wed, 26 Aug 2009 01:42:34 -0700 (PDT) Received: from [209.191.108.96] by n17.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 08:42:32 -0000 Received: from [68.142.201.244] by t3.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 08:42:32 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 08:42:32 -0000 X-Yahoo-Newman-Id: 15907.77998.bm@omp405.mail.mud.yahoo.com Received: (qmail 50189 invoked from network); 26 Aug 2009 08:42:31 -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; 26 Aug 2009 08:42:31 -0000 X-YMail-OSG: 3qxvxK4VM1khx.FI7Egcb8fgxlZhkhca.kkHtwFEnD5wP9P_TWzuhTfgTcJHYFgcsyeVnj3fCeLkJgWo5XFyyxA4eQ3jt2JomYjEZs1GbVnzYRqvURHmS11ONpAm5cBawmwJJJGkINfyL1Xp8_BTOMI8CyA0FNsiUXx87_nK9uSVsYRlCpKaRgMFuPeGCZKcNfQqK2QHdRCjOaldaKsrs3uBSMSonpY9doloWRqrmMtsaXY_cMSMKm6veEzmxiHRZ6xO3Y04VowP2Nf3zSEOYDJ80yIf5g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A94F502.7070106@netconfcentral.com> Date: Wed, 26 Aug 2009 01:40:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> <20090826.084345.103935325.mbj@tail-f.com> <20090826073146.GA19221@elstar.local> In-Reply-To: <20090826073146.GA19221@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 26 Aug 2009 08:43:24 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 26, 2009 at 08:43:45AM +0200, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> How we model the distinction with YANG statements needs to be worked >>> out. >> Do you believe we need to work this out for YANG 1.0? > > Given the intensive discussion here, I think we better work this out > now. > >> Will the introduction of 'assigned-by server' solve the issues people >> are seeing? > > The addition of 'assigned-by server' helps to make an important > distinction in the YANG data model and I am in favour of this > approach; I actually believe that marking config nodes the server can > be expected to fill in is much more important that the default > statement itself, which only handles static values and for many use > cases you have to ue the description statement anyway. > > I am more concerned about the bigger picture: > > * This includes the with-defaults document - I would prefer we can > settle on the 'explicit' model plus automatically 'assigned-by > server' leafs - but then I personally would not even need the > with-defaults extension at all since a get-config always gives me > the entire config anyway. > > * The question how I can effectively retrieve operationally used state > and relate it _easily_ to config state and how we deal with > differences in value sets between config state and operational state > requires some thought. So far, in both the NETMOD/NETCONF WGs, we > have pretty much ignored this point and perhaps this has been OK so > far but we are reaching a point where we need to spend some cycles > on this. > I am concerned about consistent answers to the 11 questions I posted yesterday. It seems to me how a particular leaf got its value is a red herring and totally irrelevant. All that matters is whether server-supplied values count as an instance of a leaf (or leaf-list) or not. It is irrelevant whether we call it config, operational node, or something in between, if some servers behave as if there is no leaf present at all, and others behave as if there is a leaf present. These 'phantom' leafs may count towards a max-elements error (or not). They may cause a unique-error (or not). 11 different error conditions that may or may not be reported -- all supposedly from compliant servers. IMO, the complete lack of any predictable server behavior for these 11 conditions is a problem for interoperability. > /js > Andy From j.schoenwaelder@jacobs-university.de Wed Aug 26 02:35: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 D813128C0D9 for ; Wed, 26 Aug 2009 02:35:28 -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 e24aviLFP-fw for ; Wed, 26 Aug 2009 02:35:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9AF423A6844 for ; Wed, 26 Aug 2009 02:35:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F889C003A; Wed, 26 Aug 2009 11:34:51 +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 RTKDDJ9N0mEY; Wed, 26 Aug 2009 11:34:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D96B7C003B; Wed, 26 Aug 2009 11:34:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B300C7DF89; Wed, 26 Aug 2009 11:34:48 +0200 (CEST) Date: Wed, 26 Aug 2009 11:34:48 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090826093448.GG18811@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> <20090826.084345.103935325.mbj@tail-f.com> <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A94F502.7070106@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 09:35:28 -0000 On Wed, Aug 26, 2009 at 10:40:34AM +0200, Andy Bierman wrote: > I am concerned about consistent answers to the 11 questions > I posted yesterday. It seems to me how a particular leaf > got its value is a red herring and totally irrelevant. I do not think I said this. > All that matters is whether server-supplied values > count as an instance of a leaf (or leaf-list) or not. There are two cases to distinguish, namely the case of a box using a certain value without the value being part of the explicit configuration and a server generating explicit configuration as a side effect of creating say a list instance. Once we area clear about this distinction, I think everything falls out naturally. > It is irrelevant whether we call it config, operational node, > or something in between, if some servers behave as if there is no > leaf present at all, and others behave as if there is a leaf present. As I said, my preference is to adopt the explicit model and adding something to YANG to make the behaviour one can expect an explicit data model design decision. > These 'phantom' leafs may count towards a max-elements error (or not). > They may cause a unique-error (or not). 11 different error conditions > that may or may not be reported -- all supposedly from compliant servers. There are no phantom leafs in my preferred approach. > IMO, the complete lack of any predictable server behavior for these 11 > conditions is a problem for interoperability. I agree that we should agree on a common way to looking at configuration and my preference is the explicit approach with server generated config nodes marked explicitely in the data model (and perhaps even an explicit description that details how the server is generating config leafs). Sure, we will then have WGs discussing when to use this in data models but this is IMHO better than leaving it to the implementor's choice since interoperability is our goal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Aug 26 03:05: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 AC1643A6A49 for ; Wed, 26 Aug 2009 03:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.335, 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 EJLh3zytrfSL for ; Wed, 26 Aug 2009 03:05:45 -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 E34EA3A6A86 for ; Wed, 26 Aug 2009 03:05:44 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id EF1C576C59C; Wed, 26 Aug 2009 11:57:15 +0200 (CEST) Date: Wed, 26 Aug 2009 11:57:15 +0200 (CEST) Message-Id: <20090826.115715.02049001.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090826093448.GG18811@elstar.local> References: <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> <20090826093448.GG18811@elstar.local> 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] 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, 26 Aug 2009 10:05:45 -0000 Juergen Schoenwaelder wrote: > I agree that we should agree on a common way to looking at > configuration and my preference is the explicit approach with server > generated config nodes marked explicitely in the data model (and > perhaps even an explicit description that details how the server is > generating config leafs). > > Sure, we will then have WGs discussing when to use this in data models > but this is IMHO better than leaving it to the implementor's choice > since interoperability is our goal. Interoperability is our goal, but another goal is to get good data models. If I understand this correctly, you envision something like: leaf foo { type int32; server-assigned "some text"; } And then also mandate the explicit mode for defaults. My concern with this is that people in the explicit camp will do: leaf foo { type int32; default 42; } and people in the report-all camp will do: leaf foo { type int32; server-assigned "MUST set to: 42"; } /martin From j.schoenwaelder@jacobs-university.de Wed Aug 26 04:03:22 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 0580B3A6B3B for ; Wed, 26 Aug 2009 04:03:22 -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 AZRZmoLn-+gR for ; Wed, 26 Aug 2009 04:03:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4DFF23A690C for ; Wed, 26 Aug 2009 04:02:31 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80D4CC003A; Wed, 26 Aug 2009 12:42:50 +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 N22cHvmqq2lr; Wed, 26 Aug 2009 12:42: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 B9A47C0006; Wed, 26 Aug 2009 12:42:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29DECC7E350; Wed, 26 Aug 2009 12:42:47 +0200 (CEST) Date: Wed, 26 Aug 2009 12:42:46 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090826104246.GA19967@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> <20090826093448.GG18811@elstar.local> <20090826.115715.02049001.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090826.115715.02049001.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 11:03:22 -0000 On Wed, Aug 26, 2009 at 11:57:15AM +0200, Martin Bjorklund wrote: > My concern with this is that people in the explicit camp will do: > > leaf foo { > type int32; > default 42; > } > > and people in the report-all camp will do: > > leaf foo { > type int32; > server-assigned "MUST set to: 42"; > } So what are you concerned about - that one uses server-assigned while the other does not? I agree that this is a design decision that then needs to be taken for each object. Or that one does have a default statement and the other does have text in a textual clause? I am even willing to even give up on default, especially as when it is used to define default values that are used operationally but are not part of config (your first example above). I am not sure what the right syntax of server-assigned or assigned-by would be - the statement ideally reflects that server assignment only happens if there is no explicit value configured. So this would be more like if-server-assigned... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Aug 26 04:08:19 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 264273A690C for ; Wed, 26 Aug 2009 04:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.279, 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 q5GsZ5JjStoD for ; Wed, 26 Aug 2009 04:08:18 -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 2E0123A6B6F for ; Wed, 26 Aug 2009 04:07:40 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 27F1B76C59E; Wed, 26 Aug 2009 13:07:04 +0200 (CEST) Date: Wed, 26 Aug 2009 13:07:02 +0200 (CEST) Message-Id: <20090826.130702.42400844.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090826104246.GA19967@elstar.local> References: <20090826093448.GG18811@elstar.local> <20090826.115715.02049001.mbj@tail-f.com> <20090826104246.GA19967@elstar.local> 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] 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, 26 Aug 2009 11:08:19 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 26, 2009 at 11:57:15AM +0200, Martin Bjorklund wrote: > > > My concern with this is that people in the explicit camp will do: > > > > leaf foo { > > type int32; > > default 42; > > } > > > > and people in the report-all camp will do: > > > > leaf foo { > > type int32; > > server-assigned "MUST set to: 42"; > > } > > So what are you concerned about - that one uses server-assigned while > the other does not? Yes. People will ask what the difference is between these two ways of doing seemingly the same thing. From a data modelling perspective, there is no difference, so the data modeller will use one of them, depending on if he likes the explicit or report-all mode for defaults. This data model design decision has impacts on the protocol level. > I am even willing to even give up on default, > especially as when it is used to define default values that are used > operationally but are not part of config (your first example above). This seems to be completely the opposite to what you wrote in http://www.ietf.org/mail-archive/web/netmod/current/msg03594.html? I do not want to remove default. > I am not sure what the right syntax of server-assigned or assigned-by > would be - the statement ideally reflects that server assignment only > happens if there is no explicit value configured. So this would be > more like if-server-assigned... I think server-assigned or assigned-by system is correct - it means that the server will assign a value, and then of course the user can modify it. /martin From mbj@tail-f.com Wed Aug 26 05:55: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 9C5553A67F3 for ; Wed, 26 Aug 2009 05:55:24 -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 MVuhxCQmIwb4 for ; Wed, 26 Aug 2009 05:55:23 -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 779C03A67EF for ; Wed, 26 Aug 2009 05:55:23 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B579076C59E; Wed, 26 Aug 2009 14:48:54 +0200 (CEST) Date: Wed, 26 Aug 2009 14:48:54 +0200 (CEST) Message-Id: <20090826.144854.53929125.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090826120726.GA20262@elstar.local> References: <20090826104246.GA19967@elstar.local> <20090826.130702.42400844.mbj@tail-f.com> <20090826120726.GA20262@elstar.local> 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] 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, 26 Aug 2009 12:55:24 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 26, 2009 at 01:07:02PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Wed, Aug 26, 2009 at 11:57:15AM +0200, Martin Bjorklund wrote: > > > > > > > My concern with this is that people in the explicit camp will do: > > > > > > > > leaf foo { > > > > type int32; > > > > default 42; > > > > } > > > > > > > > and people in the report-all camp will do: > > > > > > > > leaf foo { > > > > type int32; > > > > server-assigned "MUST set to: 42"; > > > > } > > > > > > So what are you concerned about - that one uses server-assigned while > > > the other does not? > > > > Yes. People will ask what the difference is between these two ways of > > doing seemingly the same thing. From a data modelling perspective, > > there is no difference, so the data modeller will use one of them, > > depending on if he likes the explicit or report-all mode for defaults. > > This data model design decision has impacts on the protocol level. > > I do not see the impact on the protocol level. I also think the two > snippets do different things if I assume 'explicit'. And that is the problem - on some level they do different things, but for the guy with the domain knowledge writing his YANG module, the difference is subtle. Another way of looking at it is that when I write data models, I will always use the former style b/c I like the explicit mode, but my friend Balazs who likes report-all, will always use the latter style. Our models might look exactly the same in all other regards, but this. > > > I am even willing to even give up on default, > > > especially as when it is used to define default values that are used > > > operationally but are not part of config (your first example above). > > > > This seems to be completely the opposite to what you wrote in > > http://www.ietf.org/mail-archive/web/netmod/current/msg03594.html? > > > > I do not want to remove default. > > I am all in favour of being able to learn what is actually used like I > type ifconfig if I have debug something. But still, my interface > config does not include all the stuff ifconfig shows - and for a good > reason. I trust implementors to choose sensible defaults. > > Assuming the explicit config model, the default statement in > > leaf foo { > type int32; > default 42; > } > > tells me that if there is no config, 42 can be assumed for foo. And it > only covers the case where there is a fixed stable agreeable value, > which might be pretty rare. So I can give up on this YANG feature > since what I want really goes beyond that - I like to retrieve what > the box uses if I do not specify a value also in cases where there is > no fixed stable agreeable value or where the value is actually a > function of some other config/state of the device. I think we do not > have a good plan how to do this yet. I mentioned a couple of cases in http://www.ietf.org/mail-archive/web/netmod/current/msg03461.html But just b/c there are more cases, I do not want to give up the static default value we currently have. I do think it will be used. If we look at our favorite ipfix module, they have 13 static defaults, 4 server-assigned (and maybe 2 could be characterized as "dynamic defaults"). > > > I am not sure what the right syntax of server-assigned or assigned-by > > > would be - the statement ideally reflects that server assignment only > > > happens if there is no explicit value configured. So this would be > > > more like if-server-assigned... > > > > I think server-assigned or assigned-by system is correct - it means > > that the server will assign a value, and then of course the user can > > modify it. > > But I can create a user by sending down a uid to the server when I > create the user, no? Yes. Remember that save / load backups must work. /martin From jmh@joelhalpern.com Wed Aug 26 06:19: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 357503A6A5D for ; Wed, 26 Aug 2009 06:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 jlL7x3r1j6TA for ; Wed, 26 Aug 2009 06:19:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 58E763A6A32 for ; Wed, 26 Aug 2009 06:19:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AF5E74301A2 for ; Wed, 26 Aug 2009 06:17:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 28754430122 for ; Wed, 26 Aug 2009 06:17:43 -0700 (PDT) Message-ID: <4A9535F2.3080305@joelhalpern.com> Date: Wed, 26 Aug 2009 09:17:38 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "netmod@ietf.org" References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> In-Reply-To: <20090826063638.GA19116@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 26 Aug 2009 13:19:27 -0000 I think that there are two issues mixed together here. Firstly, there is the question of how one should compose a data model. What kinds of things should the operational (non-config) data in a netmod data model reflect. What kinds of knobs show such a model have, and how should they be organize, typed, etc. When should a model use groupings.. ad almost infinitum. This is a topic on which the YANG document ought not speak, in my opinion. In fact, it is probably a topic on which we do not have enough information to speak authoritatively. One aspect of modeling is that one can use an operational field to represent "the actual value of X, as determined by the system". This is particularly useful when the actual value used may be different from the configured value, but one would want to retain the configured value. There almost certainly are other cases where this is useful. You raise the issue of representing the semantic relationship between the operational information item and the configuration information item. At this time, I don't think we should try to do that. Firstly, it can clearly be represented in the descriptive text. Secondly, it is not clear what relationships (because there can be a range of these) it is useful to represent programmatically. The difficulty lies in knowing what a client (a managing application) will want to do based on this association. Yours, Joel Juergen Schoenwaelder wrote: > On Tue, Aug 25, 2009 at 04:50:57AM +0200, Andy Bierman wrote: > >> The advantage of with-defaults=report-all is that it >> clearly shows the actual values in use >> on a specific agent at a specific time. >> That can be really useful in debugging. > > We are in agreement that the retrieval of the actual values in use is > important. But "actual values in use" means operational state not > necessarily config state. In fact, we will have both situations, and > we need to support both. > > The first example concerns values that are operationally used like an > interface MTU or the detected speed of an interface. In most cases, > these parameters are not configuration data and we would IMHO make a > mistake if we claim they are config data. On the other hand, we will > have config objects where a manager creates say a list entry and > additional config values will be assigned by the server. A good > example here is creation of a user account where you let the server > pick an unused uid if you do not provide one while setting up the list > entry. But once the uid has been assigned by the server, it pretty > much becomes config data (and so it show up when I do a get-config, > regardless of any with-defaults options). > > How we model the distinction with YANG statements needs to be worked > out. But in my preferred approach, I pretty much need a way to > retrieve operational state that I can easily map to config state and > it seems with-defaults is not really getting me there. > > /js > From j.schoenwaelder@jacobs-university.de Wed Aug 26 06:20: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 54A113A6A5D for ; Wed, 26 Aug 2009 06:20:46 -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 U-pNU+i2k09x for ; Wed, 26 Aug 2009 06:20:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C22FB3A6861 for ; Wed, 26 Aug 2009 06:20:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BA0BC003A; Wed, 26 Aug 2009 14:07:31 +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 6iMU9cxxPTaf; Wed, 26 Aug 2009 14:07:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F974C0006; Wed, 26 Aug 2009 14:07:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D8EF2C7E654; Wed, 26 Aug 2009 14:07:27 +0200 (CEST) Date: Wed, 26 Aug 2009 14:07:27 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090826120726.GA20262@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <20090826093448.GG18811@elstar.local> <20090826.115715.02049001.mbj@tail-f.com> <20090826104246.GA19967@elstar.local> <20090826.130702.42400844.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090826.130702.42400844.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:20:46 -0000 On Wed, Aug 26, 2009 at 01:07:02PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Aug 26, 2009 at 11:57:15AM +0200, Martin Bjorklund wrote: > > > > > My concern with this is that people in the explicit camp will do: > > > > > > leaf foo { > > > type int32; > > > default 42; > > > } > > > > > > and people in the report-all camp will do: > > > > > > leaf foo { > > > type int32; > > > server-assigned "MUST set to: 42"; > > > } > > > > So what are you concerned about - that one uses server-assigned while > > the other does not? > > Yes. People will ask what the difference is between these two ways of > doing seemingly the same thing. From a data modelling perspective, > there is no difference, so the data modeller will use one of them, > depending on if he likes the explicit or report-all mode for defaults. > This data model design decision has impacts on the protocol level. I do not see the impact on the protocol level. I also think the two snippets do different things if I assume 'explicit'. The first tells me, you can assume the value 42 is used if there is no explicit config. The second says if there is no explicit config, the server will create a config leaf with the value set to 42. I do not see the impact on the protocol level. The protocol in both cases does what the data modeler wanted (assuming he knows what he is doing). > > I am even willing to even give up on default, > > especially as when it is used to define default values that are used > > operationally but are not part of config (your first example above). > > This seems to be completely the opposite to what you wrote in > http://www.ietf.org/mail-archive/web/netmod/current/msg03594.html? > > I do not want to remove default. I am all in favour of being able to learn what is actually used like I type ifconfig if I have debug something. But still, my interface config does not include all the stuff ifconfig shows - and for a good reason. I trust implementors to choose sensible defaults. Assuming the explicit config model, the default statement in leaf foo { type int32; default 42; } tells me that if there is no config, 42 can be assumed for foo. And it only covers the case where there is a fixed stable agreeable value, which might be pretty rare. So I can give up on this YANG feature since what I want really goes beyond that - I like to retrieve what the box uses if I do not specify a value also in cases where there is no fixed stable agreeable value or where the value is actually a function of some other config/state of the device. I think we do not have a good plan how to do this yet. > > I am not sure what the right syntax of server-assigned or assigned-by > > would be - the statement ideally reflects that server assignment only > > happens if there is no explicit value configured. So this would be > > more like if-server-assigned... > > I think server-assigned or assigned-by system is correct - it means > that the server will assign a value, and then of course the user can > modify it. But I can create a user by sending down a uid to the server when I create the user, no? Or is the idea that this keyword would render a write during creating a failure since only the server can assign or create this leaf? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Aug 26 06: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 1F1F13A6BCC for ; Wed, 26 Aug 2009 06:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_05=-1.11, 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 zsWZ16+xUiWh for ; Wed, 26 Aug 2009 06:22:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4C8D028B56A for ; Wed, 26 Aug 2009 06:22:27 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A094C0007; Wed, 26 Aug 2009 15:00:01 +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 jMVXKxpmRDup; Wed, 26 Aug 2009 15:00:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 030E6C0041; Wed, 26 Aug 2009 15:00:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91402C7EA72; Wed, 26 Aug 2009 14:59:58 +0200 (CEST) Date: Wed, 26 Aug 2009 14:59:58 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090826125958.GA20572@elstar.local> Mail-Followup-To: Martin Bjorklund , "andy@netconfcentral.com" , "netmod@ietf.org" References: <20090826104246.GA19967@elstar.local> <20090826.130702.42400844.mbj@tail-f.com> <20090826120726.GA20262@elstar.local> <20090826.144854.53929125.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090826.144854.53929125.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:22:28 -0000 On Wed, Aug 26, 2009 at 02:48:54PM +0200, Martin Bjorklund wrote: > Another way of looking at it is that when I write data models, I will > always use the former style b/c I like the explicit mode, but my > friend Balazs who likes report-all, will always use the latter style. > Our models might look exactly the same in all other regards, but this. This is the point. We either settle on one model and stick to it or we will have to accept diversity. I am in favour of at least trying to settle on one model. If we manage to agree on what is config and what not, we will be able to solve the other questions more easily. If we fail to settle on one approach, we will keep arguing about default statements and end up with carefully crafted wordings that allow different interpretations that will cause long term pain. > I do not want to remove default. Fine. I am fine keeping default. What I was trying to get across is that finding agreement on the config model is for me far more worth than keeping default. > > > I think server-assigned or assigned-by system is correct - it means > > > that the server will assign a value, and then of course the user can > > > modify it. > > > > But I can create a user by sending down a uid to the server when I > > create the user, no? > > Yes. Remember that save / load backups must work. But then server-assigned or assigned-by system is not telling the truth since I can assign by client as well... No, I do not have a good proposal (yet). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Aug 26 06:55:01 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 AC2B23A6C0E for ; Wed, 26 Aug 2009 06:55:01 -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 OJYSGLgnIJb9 for ; Wed, 26 Aug 2009 06:55:01 -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 D51FF3A6C09 for ; Wed, 26 Aug 2009 06:55:00 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 00CE476C59E; Wed, 26 Aug 2009 15:45:29 +0200 (CEST) Date: Wed, 26 Aug 2009 15:45:29 +0200 (CEST) Message-Id: <20090826.154529.143976153.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090826125958.GA20572@elstar.local> References: <20090826120726.GA20262@elstar.local> <20090826.144854.53929125.mbj@tail-f.com> <20090826125958.GA20572@elstar.local> 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] 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, 26 Aug 2009 13:55:01 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 26, 2009 at 02:48:54PM +0200, Martin Bjorklund wrote: > > > Another way of looking at it is that when I write data models, I will > > always use the former style b/c I like the explicit mode, but my > > friend Balazs who likes report-all, will always use the latter style. > > Our models might look exactly the same in all other regards, but this. > > This is the point. We either settle on one model and stick to it or we > will have to accept diversity. I am in favour of at least trying to > settle on one model. If you're talking about if default values are part of the config or not -- we've been there before. I don't think we can force one model onto devices. If we pick one way, all other devices will look at this and say they can't implement it. /martin From Washam.Fan@huaweisymantec.com Wed Aug 26 06:58: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 8B6353A67EF for ; Wed, 26 Aug 2009 06:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=1.070, 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 dXla6qULiXOq for ; Wed, 26 Aug 2009 06:58:30 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 9C4E73A67B5 for ; Wed, 26 Aug 2009 06:58:09 -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 <0KOZ008QPLDUCJA0@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 21:56:18 +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 <0KOZ00932LDU1E20@hstml02-in.huaweisymantec.com> for netmod@ietf.org; Wed, 26 Aug 2009 21:56:18 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Wed, 26 Aug 2009 21:56:18 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Wed, 26 Aug 2009 21:56:18 +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: <20090826125958.GA20572@elstar.local> References: <20090826104246.GA19967@elstar.local> <20090826.130702.42400844.mbj@tail-f.com> <20090826120726.GA20262@elstar.local> <20090826.144854.53929125.mbj@tail-f.com> <20090826125958.GA20572@elstar.local> 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, 26 Aug 2009 13:58:31 -0000 Hi, > But then server-assigned or assigned-by system is not telling the > truth since I can assign by client as well... No, I do not have a good > proposal (yet). If I understand correctly, mandatory=true nodes MUST be created by clients except top-level ones. server-assigned nodes could be created by servers, of cource, clients can always create and modify all config nodes. defaults nodes have never been created either by clients or servers, but have values which could be used internally by servers. washam From andy@netconfcentral.com Wed Aug 26 08:00: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 1F1753A6CA6 for ; Wed, 26 Aug 2009 08:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 qhjnMmGuCvKa for ; Wed, 26 Aug 2009 08:00:09 -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 8B5293A6B8D for ; Wed, 26 Aug 2009 08:00:09 -0700 (PDT) Received: (qmail 31475 invoked from network); 26 Aug 2009 14:58:13 -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; 26 Aug 2009 14:58:13 -0000 X-YMail-OSG: EKLaYNoVM1khjPzPZuesKeEM_mndtnKC3mRM8lIz2zV._E47urEtGv_M6tPPWXGLcF9SS0OZW01DpiF2moDFy3aDjcgQLxe4BAvK3or0ubGleuo8KF_mNzH8iTZluRJgMoOHM3VFBCRJfpIjPLvzg_9_QO5lNN4o1HVni1bxaSPymP8yyCYeO7PtgjZW_5X6rY3mJw.tQS2BKwvnSeCp6Cyc5bygsA2c0Ps76aYvuI.Ar0M2Jb.6xO3DY4Ycc10aU8eo4det4FAPWai5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A954D8A.9060108@netconfcentral.com> Date: Wed, 26 Aug 2009 07:58:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> <20090826.084345.103935325.mbj@tail-f.com> <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> <20090826093448.GG18811@elstar.local> In-Reply-To: <20090826093448.GG18811@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 26 Aug 2009 15:00:11 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 26, 2009 at 10:40:34AM +0200, Andy Bierman wrote: > >> I am concerned about consistent answers to the 11 questions >> I posted yesterday. It seems to me how a particular leaf >> got its value is a red herring and totally irrelevant. > > I do not think I said this. > >> All that matters is whether server-supplied values >> count as an instance of a leaf (or leaf-list) or not. > > There are two cases to distinguish, namely the case of a box using a > certain value without the value being part of the explicit > configuration and a server generating explicit configuration as a side > effect of creating say a list instance. Once we area clear about this > distinction, I think everything falls out naturally. > I disagree. I don't care if some other operator who worked here a year ago set some parameter explicitly, or if the device picked the value on its own. All that matters is the configuration parameter behavior in affect when I'm trying to debug a network outage. Anything I *can* set is configuration, not anything I've *already* set. IMO this is a big difference and the source of the problem with the standard. Making this an arbitrary choice within the YANG architecture is really hurting the simplicity and standards value of YANG. >> It is irrelevant whether we call it config, operational node, >> or something in between, if some servers behave as if there is no >> leaf present at all, and others behave as if there is a leaf present. > > As I said, my preference is to adopt the explicit model and adding > something to YANG to make the behaviour one can expect an explicit > data model design decision. > >> These 'phantom' leafs may count towards a max-elements error (or not). >> They may cause a unique-error (or not). 11 different error conditions >> that may or may not be reported -- all supposedly from compliant servers. > > There are no phantom leafs in my preferred approach. > >> IMO, the complete lack of any predictable server behavior for these 11 >> conditions is a problem for interoperability. > > I agree that we should agree on a common way to looking at > configuration and my preference is the explicit approach with server > generated config nodes marked explicitely in the data model (and > perhaps even an explicit description that details how the server is > generating config leafs). > > Sure, we will then have WGs discussing when to use this in data models > but this is IMHO better than leaving it to the implementor's choice > since interoperability is our goal. > > /js > Andy From andy@netconfcentral.com Wed Aug 26 08:26:22 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 B44F428C119 for ; Wed, 26 Aug 2009 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 gfdkCCi1wA2V for ; Wed, 26 Aug 2009 08:26:22 -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 F186628C0D6 for ; Wed, 26 Aug 2009 08:26:21 -0700 (PDT) Received: (qmail 11098 invoked from network); 26 Aug 2009 15:25:34 -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; 26 Aug 2009 15:25:34 -0000 X-YMail-OSG: x6cacu0VM1n4Ax9zUieR7RUlvQOqPnPSOJV_FtcLsxnOnLDb8r29uJdcKK.ljdLCx4LDNUssbUZaVofV_4Y1dE2SXtYz56KKaRWPjuVrklwtFBKIoWNHHQ1jUgfp96Ksv5acvx1zZ31YtpuvJ8R4580Bece5TIK14GXQjZGLMnBIOe16AIu8gjqStddfOvN8iBFYr3y65RFASA5oUdJgtnRw_XJp8U0dF21fqGCMZ17nI8RC9lHT0XgJEAHzbbFx9mSGtDxTrOdNrhsp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9553F3.2020208@netconfcentral.com> Date: Wed, 26 Aug 2009 08:25:39 -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] server supplied leafs and protocol operations 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, 26 Aug 2009 15:26:22 -0000 Hi, Juergen said these server-supplied leafs, which the server is allowed to choose if they exist or not, have no affect on the protocol. IMO they have a negative impact on the protocol, if the client is unaware of these phantom leafs. list A { key x; unique y; leaf x { type string; } leaf y { type int32; } } If either the client or the server creates /A, it will be visible because /A/x is a key and must be present. But the server may create as many instances as it wants of /A/y and /A/z. Not every list entry need have the same server-created leafs or values. If these server-created leafs are hidden from the client, then what happens? Start with 2 list entries: first // hidden server value 19 second // hidden server value 21 What happens if the client decides to merge in a value for /A/y? ... first 21 Q) Do we agree that the server MUST send a data-not-unique error because y=21 in the 2nd list entry, so y=21 in the first entry is rejected? * If no, then hiding server-created /A/y has a definite impact on the protocol. Is the server forced to change the y=21 in the 2nd list entry to another value, or does the unique-stmt violation get ignored? * If yes, then it proves these phantom leafs really do exist, and hiding them only makes it harder for a client to use NETCONF/YANG. Andy From andy@netconfcentral.com Wed Aug 26 09:10:59 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 DDABD3A6C6C for ; Wed, 26 Aug 2009 09:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_54=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 KK+fph9iU4MS for ; Wed, 26 Aug 2009 09:10:58 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id CD7713A69AA for ; Wed, 26 Aug 2009 09:10:58 -0700 (PDT) Received: (qmail 32054 invoked from network); 26 Aug 2009 16:11:03 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 26 Aug 2009 16:11:03 -0000 X-YMail-OSG: TSqKHJYVM1lSkRVi6TyU9i2Wllxjn41iZoR.PdZotZ4FPvxX8gGW9hwoh0Q7hkjPEuIiYkTJWGOVUTzfjD0y06uOoFsCA.DqJjfONSmAvWBQhb_nPszfcdmAAIbnluqFQmbTitJIhZC2uJ.JgVR5k.r7JyDQq.1WpYj9T6IOtTJObBY0BPVyqMq_3rZn.HwhfW.ejeLz.EUWpDkAPofzJKlVeEu4vb25E5JBd3AjGkFfMwbD8u6FOXY2oz2Wfy1QQ1dOzJ8czd1L6kH.vHkt6miIAauAzN5PrXCGIf0DFLohBr8FRdEe8v5EQlJVivek2IHjcAY5qHJ.7gGQi0zAXyAueHtBw.c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A955E9B.1020101@netconfcentral.com> Date: Wed, 26 Aug 2009 09:11:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20090826120726.GA20262@elstar.local> <20090826.144854.53929125.mbj@tail-f.com> <20090826125958.GA20572@elstar.local> <20090826.154529.143976153.mbj@tail-f.com> In-Reply-To: <20090826.154529.143976153.mbj@tail-f.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, 26 Aug 2009 16:11:00 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Wed, Aug 26, 2009 at 02:48:54PM +0200, Martin Bjorklund wrote: >> >>> Another way of looking at it is that when I write data models, I will >>> always use the former style b/c I like the explicit mode, but my >>> friend Balazs who likes report-all, will always use the latter style. >>> Our models might look exactly the same in all other regards, but this. >> This is the point. We either settle on one model and stick to it or we >> will have to accept diversity. I am in favour of at least trying to >> settle on one model. > > If you're talking about if default values are part of the config or > not -- we've been there before. I don't think we can force one model > onto devices. If we pick one way, all other devices will look at this > and say they can't implement it. > I think the problem is with-defaults basic behavior = explicit. All other variables really don't matter. basic=trim is fine because the YANG default-stmt serves as a marker to the client that the leaf instance is really there. I'm not even sure everyone agrees that all the YANG validation rules still apply to invisible leafs if the server uses with-defaults basic=explicit behavior. IMO, the concept that a leaf instance only exists if the client provides it is totally broken wrt/ YANG database validation concepts and mechanisms. The YANG validation rules need to apply to the entire configuration database. If we cannot agree on what 'entire' means, I don't think we have a workable standard. If the client cannot retrieve the entire configuration (except leafs set to the YANG default), then the client cannot use edit-config, validate, or commit effectively. The term 'flying blind' best describes this mode of database editing. > > /martin > Andy From phil@juniper.net Wed Aug 26 10:01: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 7E97528C380 for ; Wed, 26 Aug 2009 10:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_54=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 lZI1YqZZviMK for ; Wed, 26 Aug 2009 10:01:15 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id C90B228C2DB for ; Wed, 26 Aug 2009 10:01:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSpVqXyO0EnskWdrprVILc2u/W2K6NoUd@postini.com; Wed, 26 Aug 2009 10:01:22 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, 26 Aug 2009 09:55:36 -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, 26 Aug 2009 09:55:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 09:55:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 09:55:35 -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 n7QGtYd40017; Wed, 26 Aug 2009 09:55:34 -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 n7QGhaUY014584; Wed, 26 Aug 2009 16:43:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261643.n7QGhaUY014584@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A955E9B.1020101@netconfcentral.com> Date: Wed, 26 Aug 2009 12:43:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 16:55:35.0408 (UTC) FILETIME=[07E35F00:01CA266E] MIME-Version: 1.0 Content-Type: text/plain 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, 26 Aug 2009 17:01:16 -0000 Andy Bierman writes: >All other variables really don't matter. basic=trim is fine because >the YANG default-stmt serves as a marker to the client that the leaf >instance is really there. But with a default statement, the leaf instance is not really there. >I'm not even sure everyone agrees that all the YANG validation >rules still apply to invisible leafs if the server uses >with-defaults basic=explicit behavior. The YANG spec is pretty clear on this point. Constraints that refer to nodes will use their default value if the leaf does not exist. >IMO, the concept that a leaf instance only exists if the >client provides it is totally broken wrt/ YANG database validation >concepts and mechanisms. I strongly disagree. >The YANG validation rules need to apply to the entire configuration >database. If we cannot agree on what 'entire' means, I don't think we have >a workable standard. "entire" isn't the problem. The issue you are having is that you want default values to be populated in the configuration database as real leaf instances. I strongly oppose this. >If the client cannot retrieve the entire configuration >(except leafs set to the YANG default), then the client >cannot use edit-config, validate, or commit effectively. As mentioned many times, the client can use the YANG modules to learn default values. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 10:08: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 B822A28C3B3 for ; Wed, 26 Aug 2009 10:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_54=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 rn9HJzfzv4XQ for ; Wed, 26 Aug 2009 10:08:52 -0700 (PDT) Received: from n16b.bullet.mail.mud.yahoo.com (n16b.bullet.mail.mud.yahoo.com [68.142.207.237]) by core3.amsl.com (Postfix) with SMTP id EE64E3A6B85 for ; Wed, 26 Aug 2009 10:08:51 -0700 (PDT) Received: from [68.142.194.243] by n16.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 17:08:56 -0000 Received: from [68.142.201.244] by t1.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 17:08:56 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 17:08:56 -0000 X-Yahoo-Newman-Id: 851661.94647.bm@omp405.mail.mud.yahoo.com Received: (qmail 89940 invoked from network); 26 Aug 2009 17:08:56 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 26 Aug 2009 17:08:56 -0000 X-YMail-OSG: 6knkyrkVM1nbKxmlbjbTRJPcx1f3OzibIgVKOAnAVRHyQcq.ZkZixvnYyFITVTDdmiTQaBUFn_A2NBgzNEnYVLkLNmqx_pDyPmgOFXSbwxhcbURLB_q4DWFQQzjA2u_CE1TANcqWPMc3Yo1ckEa2n6gYocP.2IzVjPvH7kgHd2nWZfhm2KIO.bY81zDmGXYe6Qs8N_sjnBq_m.s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A956C2E.1070301@netconfcentral.com> Date: Wed, 26 Aug 2009 10:09:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908261643.n7QGhaUY014584@idle.juniper.net> In-Reply-To: <200908261643.n7QGhaUY014584@idle.juniper.net> 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, 26 Aug 2009 17:08:52 -0000 Phil Shafer wrote: > Andy Bierman writes: >> All other variables really don't matter. basic=trim is fine because >> the YANG default-stmt serves as a marker to the client that the leaf >> instance is really there. > > But with a default statement, the leaf instance is not really there. > >> I'm not even sure everyone agrees that all the YANG validation >> rules still apply to invisible leafs if the server uses >> with-defaults basic=explicit behavior. > > The YANG spec is pretty clear on this point. Constraints that > refer to nodes will use their default value if the leaf does not > exist. > >> IMO, the concept that a leaf instance only exists if the >> client provides it is totally broken wrt/ YANG database validation >> concepts and mechanisms. > > I strongly disagree. > >> The YANG validation rules need to apply to the entire configuration >> database. If we cannot agree on what 'entire' means, I don't think we have >> a workable standard. > > "entire" isn't the problem. The issue you are having is that > you want default values to be populated in the configuration > database as real leaf instances. I strongly oppose this. > >> If the client cannot retrieve the entire configuration >> (except leafs set to the YANG default), then the client >> cannot use edit-config, validate, or commit effectively. > > As mentioned many times, the client can use the YANG modules > to learn default values. > basic=explicit has nothing to do with the YANG default-stmt. That's the problem. You are describing basic=trim, and I said in the first sentence there is no problem there at all. > Thanks, > Phil > Andy From phil@juniper.net Wed Aug 26 10:11: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 9C41728C3CA for ; Wed, 26 Aug 2009 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 k+Poa+7cMkoP for ; Wed, 26 Aug 2009 10:11:29 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id B7E4028C31B for ; Wed, 26 Aug 2009 10:11:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSpVsxnp28ru7XaLJM4D3iLjIJ4zl5o0l@postini.com; Wed, 26 Aug 2009 10:11:36 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, 26 Aug 2009 10:04:37 -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, 26 Aug 2009 10:04:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:04:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:04: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 n7QH4ad45552; Wed, 26 Aug 2009 10:04: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 n7QGqcGs014651; Wed, 26 Aug 2009 16:52:38 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261652.n7QGqcGs014651@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A9553F3.2020208@netconfcentral.com> Date: Wed, 26 Aug 2009 12:52:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 17:04:36.0811 (UTC) FILETIME=[4A96E9B0:01CA266F] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] server supplied leafs and protocol operations 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, 26 Aug 2009 17:11:30 -0000 Andy Bierman writes: >Juergen said these server-supplied leafs, which the >server is allowed to choose if they exist or not, >have no affect on the protocol. IMO they have a >negative impact on the protocol, if the client is >unaware of these phantom leafs. I think you have a misunderstanding about "assigned-by system" leafs. When a parent hierarchy is created without the leaf, the system assigns a value to that leaf. At that point, the leaf becomes part of the configuration database. Such a leaf is not "hidden from the client". The value is fetch with normal NETCONF operations. Only the creation of the leaf has any amount of mystery to it. Other than that, it is normal configuration data. Most importantly, if the client includes a value for the leaf in an operation that creates the parent hierarchy, the system does not assign its own value, but honors the one given by the client. If the client assigns a value for the leaf in an operation that affects an existing instance of the parent hierarchy, the server will use the new value given, replacing the previous value, whether it was assigned by the system or a previous client. In other words, it behaves exactly like other configuration data. >What happens if the client decides to merge in a value for /A/y? This would be an error, since it violates the uniqueness constraint. > * If yes, then it proves these phantom leafs really do exist, and hiding > them only makes it harder for a client to use NETCONF/YANG. There are no phantom leafs and no one is hiding them. There's nothing in Area 51 either. Thanks, Phil From phil@juniper.net Wed Aug 26 10:13: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 928293A70B7 for ; Wed, 26 Aug 2009 10:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 zDAiLwE6F3Tf for ; Wed, 26 Aug 2009 10:13:54 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id A50C728C407 for ; Wed, 26 Aug 2009 10:12:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSpVtEmYrWxVkyaqRmyHkJqBsIU7SwQID@postini.com; Wed, 26 Aug 2009 10:12:55 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, 26 Aug 2009 10:08:35 -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, 26 Aug 2009 10:08:35 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:08:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:08:34 -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 n7QH8Xd47460; Wed, 26 Aug 2009 10:08: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 n7QGuZcZ014750; Wed, 26 Aug 2009 16:56:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261656.n7QGuZcZ014750@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090826125958.GA20572@elstar.local> Date: Wed, 26 Aug 2009 12:56:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 17:08:34.0122 (UTC) FILETIME=[D809B2A0:01CA266F] MIME-Version: 1.0 Content-Type: text/plain 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, 26 Aug 2009 17:13:55 -0000 Juergen Schoenwaelder writes: >But then server-assigned or assigned-by system is not telling the >truth since I can assign by client as well... No, I do not have a good >proposal (yet). "assigned-by system" means that the value for this leaf _can_ be assigned by the system, if one is not provided. If one is provided, the system will not assign one and the leaf will be treated like normal configuration data. Thanks, Phil From phil@juniper.net Wed Aug 26 10:27: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 78FCA3A6CAE for ; Wed, 26 Aug 2009 10:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 JCB0S7c8ujq5 for ; Wed, 26 Aug 2009 10:27:12 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id CB1653A6A6C for ; Wed, 26 Aug 2009 10:27:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSpVwdLLmaLYfeLnCqZWPnIt8hnibvi/O@postini.com; Wed, 26 Aug 2009 10:27:19 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, 26 Aug 2009 10:21:33 -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, 26 Aug 2009 10:21:33 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:21:32 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:21:32 -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 n7QHLVd54861; Wed, 26 Aug 2009 10:21:31 -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 n7QH9X9p014919; Wed, 26 Aug 2009 17:09:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261709.n7QH9X9p014919@idle.juniper.net> To: Andy Bierman Date: Wed, 26 Aug 2009 13:09:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 17:21:32.0273 (UTC) FILETIME=[A7DA1E10:01CA2671] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: [netmod] Answers to "assigned-by system" questions 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, 26 Aug 2009 17:27:13 -0000 Andy Bierman writes: > - Do must statements apply to server-created leafs? Yes. leafs with the "assigned-by system" statement are normal configuration data, so normal constraints apply. > - Do min-elements and max-elements constraints apply to > server created leafs? Yes. leafs with the "assigned-by system" statement are normal configuration data, so normal constraints apply. > - Do unique statement constraints apply to server-created leafs? Yes. leafs with the "assigned-by system" statement are normal configuration data, so normal constraints apply. > - Are leafrefs allowed to contain values that exist only > within a server-created leaf or leaf-list? Yes. leafs with the "assigned-by system" statement are normal configuration data, so normal constraints apply. I don't think we are talking about "a-by system" for leaf-lists. > - Are instance-identifiers (where require-instance=true) allowed > to reference server-created leafs? Yes. leafs with the "assigned-by system" statement are normal configuration data, so normal constraints apply. > - Do server-created leafs count as being a sibling node when deciding if > a mandatory leaf is missing? I don't follow this question. > - How does a client know which case is selected (if any) > in an optional or mandatory choice, if only server-created > nodes exist? Are you wanting "a-by system" nodes inside choices? I would think this would be disallowed. > - Does the nc:operation='create' fail if the client issues > such an edit-config operation on a server-created leaf? Yes, since the leaf has a value. Normal rules apply here. > - Does the nc:operation='delete' succeed if the client issues > such an edit-config operation on a server-created leaf? Yes, the leaf will be deleted. Normal rules apply here. > - Does an XPath expression (must/when/select) encounter a > missing-node or some value, if a server-created leaf is > referenced? Yes. leafs with the "assigned-by system" statement are normal configuration data, so normal constraints apply. > - Does a subtree filter with a select-node or a content-match > node for a server-created leaf return any data, or not? Yes. leafs with the "assigned-by system" statement are normal configuration data, so normal constraints apply. IMHO the only real question for "assigned-by system" nodes is _when_ is the value assigned by the system? Is it done at validation time or at edit-config time? In JUNOS, these are assigned at validation time. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 10:30: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 2D5ED28C499 for ; Wed, 26 Aug 2009 10:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 yoPhrV5zeqCh for ; Wed, 26 Aug 2009 10:30:55 -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 7CE1F3A6C1D for ; Wed, 26 Aug 2009 10:30:55 -0700 (PDT) Received: (qmail 65297 invoked from network); 26 Aug 2009 17:30:59 -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; 26 Aug 2009 17:30:58 -0000 X-YMail-OSG: w9wC1zEVM1lHANMIC7d.elEraKsqc80Ic12AzuFLTaBI.ObLUc20ywUQKa.Jffw5HyIysrb6etkCAL79we3O_MZP0AtNT7Ci43gveEm1on1dEFDR3c6b9Y2vcqZj92PXW6acGn1L2Tz9pZj9ymQ_4IPzSYWppNn6kdyfvemBItkQFK_CMZvRyhJ9AzUXP2vpe4DGODSw__T1UiM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A957157.3090407@netconfcentral.com> Date: Wed, 26 Aug 2009 10:31:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908261652.n7QGqcGs014651@idle.juniper.net> In-Reply-To: <200908261652.n7QGqcGs014651@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] server supplied leafs and protocol operations 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, 26 Aug 2009 17:30:56 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Juergen said these server-supplied leafs, which the >> server is allowed to choose if they exist or not, >> have no affect on the protocol. IMO they have a >> negative impact on the protocol, if the client is >> unaware of these phantom leafs. > > I think you have a misunderstanding about "assigned-by system" > leafs. When a parent hierarchy is created without the leaf, the > system assigns a value to that leaf. At that point, the leaf becomes > part of the configuration database. Such a leaf is not "hidden > from the client". The value is fetch with normal NETCONF operations. > > Only the creation of the leaf has any amount of mystery to it. > Other than that, it is normal configuration data. Most importantly, > if the client includes a value for the leaf in an operation that > creates the parent hierarchy, the system does not assign its own > value, but honors the one given by the client. If the client assigns > a value for the leaf in an operation that affects an existing > instance of the parent hierarchy, the server will use the new value > given, replacing the previous value, whether it was assigned by the > system or a previous client. > > In other words, it behaves exactly like other configuration data. > >> What happens if the client decides to merge in a value for /A/y? > > This would be an error, since it violates the uniqueness constraint. > >> * If yes, then it proves these phantom leafs really do exist, and hiding >> them only makes it harder for a client to use NETCONF/YANG. > > There are no phantom leafs and no one is hiding them. There's > nothing in Area 51 either. > I don't believe either. There are pictures of a massive complex at Groom Lake, but we digress... If what you say is true, then what exactly is basic=explicit behavior for handling defaults? The :with-defaults capability is optional-to-implement. We can't make it mandatory without changing the protocol version, or all existing 4741 implementations will be non-compliant. Unless the server supports :with-defaults, and it refuses to ever show the client any leaf that was set by the server (the definition of basic=explicit), then these are effectively hidden leafs. The client has to edit the database without knowing if any conflicts are being created with these hidden leafs. So you are saying that we don't have any server behavior (ever) that would prevent a leaf set by the server to a value other than the YANG default from being retrieved by the client? If that is the case, then we don't need 'explicit' in the with-defaults draft. > Thanks, > Phil > Andy From phil@juniper.net Wed Aug 26 10:32: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 6307B28C4DA for ; Wed, 26 Aug 2009 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 r2ADq9EYQMVB for ; Wed, 26 Aug 2009 10:32:23 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 0403828C4C7 for ; Wed, 26 Aug 2009 10:32:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSpVxqsZ5sgdIKnt6Jyk3lImgxKJpx99T@postini.com; Wed, 26 Aug 2009 10:32:30 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, 26 Aug 2009 10:25:55 -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, 26 Aug 2009 10:25:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:25:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:25:54 -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 n7QHPrd57723; Wed, 26 Aug 2009 10:25:53 -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 n7QHDtAw015034; Wed, 26 Aug 2009 17:13:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261713.n7QHDtAw015034@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A956C2E.1070301@netconfcentral.com> Date: Wed, 26 Aug 2009 13:13:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 17:25:54.0396 (UTC) FILETIME=[4416E9C0:01CA2672] MIME-Version: 1.0 Content-Type: text/plain 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, 26 Aug 2009 17:32:24 -0000 Andy Bierman writes: >basic=explicit has nothing to do with the YANG default-stmt. Can you explain this sentence? My understanding was that "explicit" meant you were attempting to fetch the config with a full set of default values. How can this have nothing to do with the YANG default statement? Thanks, Phil From andy@netconfcentral.com Wed Aug 26 10:46: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 07EF628C2C4 for ; Wed, 26 Aug 2009 10:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 J8Nup8Rfzb5L for ; Wed, 26 Aug 2009 10:46:05 -0700 (PDT) Received: from n12.bullet.mail.mud.yahoo.com (n12.bullet.mail.mud.yahoo.com [209.191.125.209]) by core3.amsl.com (Postfix) with SMTP id 3B52628C1E0 for ; Wed, 26 Aug 2009 10:46:05 -0700 (PDT) Received: from [68.142.200.221] by n12.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 17:46:10 -0000 Received: from [68.142.201.245] by t9.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 17:46:10 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 17:46:10 -0000 X-Yahoo-Newman-Id: 76023.16433.bm@omp406.mail.mud.yahoo.com Received: (qmail 71079 invoked from network); 26 Aug 2009 17:46:09 -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; 26 Aug 2009 17:46:09 -0000 X-YMail-OSG: dFqXuFsVM1lMoxy8raU.RJ2YHyKQpmr2nFTLkQpaFJT1Qc2ixj15Rba81FmG_uHnUDfRYQj1O7N1L8SVGQUNBW71LdndFGE46f3Rivf8t_hkb0y5.J5RXq1nfRnAgsIimnPtJqVl8vWvVgKSHM_3HbYrTHyq.PXoTH54eRyliwxECugFeEc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95746E.20006@netconfcentral.com> Date: Wed, 26 Aug 2009 10:44:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908261713.n7QHDtAw015034@idle.juniper.net> In-Reply-To: <200908261713.n7QHDtAw015034@idle.juniper.net> 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, 26 Aug 2009 17:46:06 -0000 Phil Shafer wrote: > Andy Bierman writes: >> basic=explicit has nothing to do with the YANG default-stmt. > > Can you explain this sentence? My understanding was that > "explicit" meant you were attempting to fetch the config > with a full set of default values. How can this have > nothing to do with the YANG default statement? > basic=explicit means that the server considers any leaf not explicitly provided by client to be a default. basic=trim means the server considers any leaf set to the schema default value to be a default, even if the client explicitly set the leaf to the schema-defined default value. I consider this inconsistency to be an interoperability problem. A default is a schema-assigned value when the element is missing in a valid configuration. The standard should decide what a default is, not every server implementation. There is no way to even discover what the server will do, unless :with-defaults is supported, in which case report-all is available, so there is no problem. Even worse, there is no guarantee that the server will use the same unspecified behavior across platforms, across versions, or even across sub-agents within the same implementation. > Thanks, > Phil > Andy From phil@juniper.net Wed Aug 26 11:03: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 0E75328C4E1 for ; Wed, 26 Aug 2009 11:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 6qZOXKaiPVLJ for ; Wed, 26 Aug 2009 11:03:30 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id D1F0628C414 for ; Wed, 26 Aug 2009 11:02:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSpV4x4bbK3ZHPotu+y4k6Ub8hV/0POGA@postini.com; Wed, 26 Aug 2009 11:02:48 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, 26 Aug 2009 10:58:02 -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, 26 Aug 2009 10:58:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:58:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:58:01 -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 n7QHw1d76864; Wed, 26 Aug 2009 10:58:01 -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 n7QHk3HA015559; Wed, 26 Aug 2009 17:46:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261746.n7QHk3HA015559@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A957157.3090407@netconfcentral.com> Date: Wed, 26 Aug 2009 13:46:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 17:58:01.0728 (UTC) FILETIME=[C0DE7000:01CA2676] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] server supplied leafs and protocol operations 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, 26 Aug 2009 18:03:31 -0000 Andy Bierman writes: >Unless the server supports :with-defaults, and it refuses to ever show the >client any leaf that was set by the server (the definition >of basic=explicit), then these are effectively hidden leafs. The definition of "basic=explicit" in the w-d draft needs repaired. o Explicitly set default data: Data that is explicitly set by the NETCONF client to its default value. Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. Your current definition is way too narrow, blocking SNMP, humans, etc. I suggest "Data that is explicitly set to its default value." Leafs that are "a-by system" and are assigned values by the value are normal configuration data. They should always be included in the data returned by get-config without regard for with-defaults. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 11:06: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 A446E28C4E7 for ; Wed, 26 Aug 2009 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 UAEcI8quDDi2 for ; Wed, 26 Aug 2009 11:06:25 -0700 (PDT) Received: from n15b.bullet.mail.mud.yahoo.com (n15b.bullet.mail.mud.yahoo.com [68.142.207.236]) by core3.amsl.com (Postfix) with SMTP id DAC6328C4E5 for ; Wed, 26 Aug 2009 11:06:24 -0700 (PDT) Received: from [68.142.200.221] by n15.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 18:06:30 -0000 Received: from [68.142.201.249] by t9.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 18:06:30 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 18:06:30 -0000 X-Yahoo-Newman-Id: 6115.61960.bm@omp410.mail.mud.yahoo.com Received: (qmail 82070 invoked from network); 26 Aug 2009 18:06:29 -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; 26 Aug 2009 18:06:28 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A957931.5070903@netconfcentral.com> Date: Wed, 26 Aug 2009 11:04:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908261709.n7QH9X9p014919@idle.juniper.net> In-Reply-To: <200908261709.n7QH9X9p014919@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Answers to "assigned-by system" questions 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, 26 Aug 2009 18:06:25 -0000 Phil Shafer wrote: There is no assigned-by system in YANG. I don't think there is any consensus on the details of this database property. You are saying that of course all the leafs count when validating a database -- we agree. But the idea that an application will be able to edit a NETCONF database without being able to retrieve all the leafs that affect validation is 'operationally-challenged'. Forcing a human to look it up in YANG description and/or vendor CLI documentation is not API-friendly, which is a stated goal of the NETCONF protocol: >From 4741-bis: 1. Introduction The NETCONF protocol defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets. > Thanks, > Phil > Andy From phil@juniper.net Wed Aug 26 12:04: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 15FF73A70D4 for ; Wed, 26 Aug 2009 12:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 0TU6nO9ImKXe for ; Wed, 26 Aug 2009 12:04:46 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 5A6E228C557 for ; Wed, 26 Aug 2009 12:04:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSpWHKw2FosH19GG/J3CXW11HIfpqCSsX@postini.com; Wed, 26 Aug 2009 12:04:17 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, 26 Aug 2009 12:00: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); Wed, 26 Aug 2009 12:00:21 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:00:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:00:20 -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 n7QJ0Ad11826; Wed, 26 Aug 2009 12:00:19 -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 n7QImA99016278; Wed, 26 Aug 2009 18:48:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261848.n7QImA99016278@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A957931.5070903@netconfcentral.com> Date: Wed, 26 Aug 2009 14:48:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 19:00:20.0610 (UTC) FILETIME=[756A8E20:01CA267F] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Answers to "assigned-by system" questions 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, 26 Aug 2009 19:04:51 -0000 Andy Bierman writes: >There is no assigned-by system in YANG. >I don't think there is any consensus on the >details of this database property. I thought that was part of the purpose of this discussion. >But the idea that an application will be >able to edit a NETCONF database without being >able to retrieve all the leafs that affect validation >is 'operationally-challenged'. I disagree. >Forcing a human to look it up in YANG description and/or >vendor CLI documentation is not API-friendly, which is >a stated goal of the NETCONF protocol: We make configuration data available via the API. We do not mix meta-data with data. For example, we don't tell you which leafs are mandatory, or have any of the constraints defined in YANG (unique, key, etc). I find it surprising that you want default values, which are less interesting to the average client than mandatory or key, to be intermixed with user-specific, vital and important configuration data. My code does't support exhibiting default values in the API at all. No one has ever asked for them to be in the API. I can' imagine someone wanting to populate the configuration database with default values. Configuration files are too large and complex when they contain the important parts. Adding noise is, well, it's completely outside my reality. Trying to put this behaviour in NETCONF is IMHO a mistake. If you want to make "report-all" an optional feature that works this way, we can leave it to the marketplace to decide the value. But trying to force the rest of the world to work this way is a non-starter. Thanks, Phil From mbj@tail-f.com Wed Aug 26 12:31: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 799D53A70C9 for ; Wed, 26 Aug 2009 12:31:07 -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 aiBCDuxfSz3l for ; Wed, 26 Aug 2009 12:31:06 -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 A3E5C3A70C7 for ; Wed, 26 Aug 2009 12:31:06 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D758776C59E for ; Wed, 26 Aug 2009 21:30:38 +0200 (CEST) Date: Wed, 26 Aug 2009 21:30:38 +0200 (CEST) Message-Id: <20090826.213038.126204555.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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 Subject: [netmod] default terminology 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, 26 Aug 2009 19:31:07 -0000 Hi, I think some of the confusion in the recent discussions comes from inconsistent terminolgy. When we say 'server assigned', or 'assigned-by system', it refers to data that is present in the config, just like normal, client created data ('assigned-by user' if you will). Since this data is part of the data store, it is not hidden, it is not phantom nodes, and it is reported in a normal get-config, regardless of the value of any with-defaults parameters. Then we have 'default data'. I like to view this as the value that is operationally used if the node is not present in the data store. YANG supports one kind of default data only - static defaults, i.e. a static value, guaranteed to be the same in all implementations, specified in the data model. One can imagine dynamic default values, and I think this is what Andy calls 'hidden' or 'phantom'. /martin From mbj@tail-f.com Wed Aug 26 12:45: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 4E8433A6853 for ; Wed, 26 Aug 2009 12:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_54=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 TbBRAjMZf22y for ; Wed, 26 Aug 2009 12:45:57 -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 C1E913A6B53 for ; Wed, 26 Aug 2009 12:45:56 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 35A8D76C59E; Wed, 26 Aug 2009 21:45:53 +0200 (CEST) Date: Wed, 26 Aug 2009 21:45:52 +0200 (CEST) Message-Id: <20090826.214552.81304929.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A95746E.20006@netconfcentral.com> References: <200908261713.n7QHDtAw015034@idle.juniper.net> <4A95746E.20006@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] 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, 26 Aug 2009 19:45:58 -0000 Andy Bierman wrote: > basic=explicit means that the server considers any leaf > not explicitly provided by client to be a default. > > basic=trim means the server considers any leaf set > to the schema default value to be a default, > even if the client explicitly set the leaf to the > schema-defined default value. > > I consider this inconsistency to be an interoperability problem. What exactly is the inconsistency, and how is it an interoperability problem? > A default is a schema-assigned value when the element > is missing in a valid configuration. > The standard should > decide what a default is, not every server implementation. > > There is no way to even discover what the server will do, > unless :with-defaults is supported, in which case report-all > is available, so there is no problem. > > Even worse, there is no guarantee that the server will > use the same unspecified behavior across platforms, > across versions, or even across sub-agents within > the same implementation. Look at this leaf from the ipfix module: leaf sourceIpAddress { type inet:ip-address; must "../transportProtocol='udp'"; description "Sets source IP address if UDP is transport protocol. If not configured, the IP address assigned to the outgoing interface is used."; } Do you want to make this illegal? Do you think a new YANG statement is needed to cover this case? server-assigned would not be appropriate to use, since it would fix this value, even if the IP address of the outgoing interface is used. /martin > > > > Thanks, > > Phil > > > > Andy > From mbj@tail-f.com Wed Aug 26 12:51: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 289ED3A6853 for ; Wed, 26 Aug 2009 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.042, 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 HZswfyuhWlnT for ; Wed, 26 Aug 2009 12:51:39 -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 6AF003A67F0 for ; Wed, 26 Aug 2009 12:51:39 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E72776C59E; Wed, 26 Aug 2009 21:51:35 +0200 (CEST) Date: Wed, 26 Aug 2009 21:51:35 +0200 (CEST) Message-Id: <20090826.215135.198254122.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A957157.3090407@netconfcentral.com> References: <200908261652.n7QGqcGs014651@idle.juniper.net> <4A957157.3090407@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] server supplied leafs and protocol operations 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, 26 Aug 2009 19:51:40 -0000 Andy Bierman wrote: > The :with-defaults capability is optional-to-implement. > We can't make it mandatory without changing the protocol version, > or all existing 4741 implementations will be non-compliant. But if we decide e.g. that we want to support dynamic defaults, and :with-defaults is the way to read the value, we could require :with-defaults for servers that implement any YANG module. > So you are saying that we don't have any server behavior (ever) > that would prevent a leaf set by the server to a value other > than the YANG default from being retrieved by the client? Is this the same as dynamic defaults? > If that is the case, then we don't need 'explicit' in the > with-defaults draft. If we make dynamic defaults illegal we don't need :with-defaults at all, except for convenience. /martin From mbj@tail-f.com Wed Aug 26 12:55: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 7D0C23A6A1E for ; Wed, 26 Aug 2009 12:55:10 -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 mhZo6J2DZsKw for ; Wed, 26 Aug 2009 12:55:09 -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 B27CB3A6853 for ; Wed, 26 Aug 2009 12:55:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 132F776C59E; Wed, 26 Aug 2009 21:55:16 +0200 (CEST) Date: Wed, 26 Aug 2009 21:55:15 +0200 (CEST) Message-Id: <20090826.215515.50853510.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908261713.n7QHDtAw015034@idle.juniper.net> References: <4A956C2E.1070301@netconfcentral.com> <200908261713.n7QHDtAw015034@idle.juniper.net> 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] 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, 26 Aug 2009 19:55:10 -0000 Phil Shafer wrote: > My understanding was that > "explicit" meant you were attempting to fetch the config > with a full set of default values. report-all gives you all default values. explicit gives you only the values actually configured (i.e. your sw would advertise basic=explicit) /martin From mbj@tail-f.com Wed Aug 26 12:58: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 860DD28C485 for ; Wed, 26 Aug 2009 12:58:31 -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 5x0AP6LUFZ1e for ; Wed, 26 Aug 2009 12:58:30 -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 4144E28C3B5 for ; Wed, 26 Aug 2009 12:57:31 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E849B76C59E; Wed, 26 Aug 2009 21:57:33 +0200 (CEST) Date: Wed, 26 Aug 2009 21:57:33 +0200 (CEST) Message-Id: <20090826.215733.158236260.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908261746.n7QHk3HA015559@idle.juniper.net> References: <4A957157.3090407@netconfcentral.com> <200908261746.n7QHk3HA015559@idle.juniper.net> 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] server supplied leafs and protocol operations 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, 26 Aug 2009 19:58:31 -0000 Phil Shafer wrote: > The definition of "basic=explicit" in the w-d draft needs repaired. > > o Explicitly set default data: Data that is explicitly set by the > NETCONF client to its default value. Some servers MAY treat > explicitly set default data as simple default data, as they may > not be able to differentiate between them. > > Your current definition is way too narrow, blocking SNMP, humans, > etc. I suggest "Data that is explicitly set to its default value." While I agree with the suggested change, note that the term 'explicit' has nothing to do with the term 'explicitly set default data'. A server that cares about 'explicitly set default data' implements the basic mode 'trim'. This is confusing, and should probably be fixed. /martin From phil@juniper.net Wed Aug 26 13:03: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 C71233A6D5E for ; Wed, 26 Aug 2009 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 BtbdRQZYCEuC for ; Wed, 26 Aug 2009 13:03:51 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id C71FB3A6CCC for ; Wed, 26 Aug 2009 13:03:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSpWVKvYo2LykTq8xhkk8d9xng2TMzTQR@postini.com; Wed, 26 Aug 2009 13:03:57 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, 26 Aug 2009 12:56:58 -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, 26 Aug 2009 12:56:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:56:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:56:57 -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 n7QJuvd42106; Wed, 26 Aug 2009 12:56:57 -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 n7QJixPu016923; Wed, 26 Aug 2009 19:44:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908261944.n7QJixPu016923@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090826.213038.126204555.mbj@tail-f.com> Date: Wed, 26 Aug 2009 15:44:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 19:56:57.0817 (UTC) FILETIME=[5E4F3490:01CA2687] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] default terminology 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, 26 Aug 2009 20:03:51 -0000 Martin Bjorklund writes: >One can imagine dynamic default values, >and I think this is what Andy calls 'hidden' or 'phantom'. I _think_ (but could easily be wrong) that Andy's hangup was the definition he had in the with-defaults draft, which said only _client_ supplied data values were returned with the "explicit" behaviour: o Explicitly set default data: Data that is explicitly set by the NETCONF client to its default value. Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. Since configuration data is set from a number of sources (including snmp, cli users, and "assigned-by system" data), the first paragraph here needs to be broadened to include data set by any source. (Default values in a YANG module would not constitute such a source.) I'm hoping that was the origin of the confusion, and that we can resolve this issue and move forward. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 13:05: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 1841428C55E for ; Wed, 26 Aug 2009 13:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 7HAzswSlyJlw for ; Wed, 26 Aug 2009 13:05:39 -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 80D4F28C559 for ; Wed, 26 Aug 2009 13:05:39 -0700 (PDT) Received: (qmail 7085 invoked from network); 26 Aug 2009 20:05:43 -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; 26 Aug 2009 20:05:43 -0000 X-YMail-OSG: 9B76zLMVM1lvyyV80fsvMyURfW0gqpWQLJxxGgg0lf5Kv7IYjRHOHf7o.9G1d9E7L0jGQIwpEY.UDQRGAN5XDb1AHGRbKNkkiHL.pFD08hx3wUgq.Idjis3SWxh9IPWp4Y8wbTB4o4P2.Rrgn5hhPDppz3njqij_n8HbNQ3x0wMnbxye5c6rUIXN0.fRs8dZTr7xvjXlL9LIWQTgt.uj4hC1EyhYBhCAqin22D7sPFws6i9dCCY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95959D.8000004@netconfcentral.com> Date: Wed, 26 Aug 2009 13:05:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A956C2E.1070301@netconfcentral.com> <200908261713.n7QHDtAw015034@idle.juniper.net> <20090826.215515.50853510.mbj@tail-f.com> In-Reply-To: <20090826.215515.50853510.mbj@tail-f.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, 26 Aug 2009 20:05:40 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> My understanding was that >> "explicit" meant you were attempting to fetch the config >> with a full set of default values. > > report-all gives you all default values. explicit gives you only the > values actually configured (i.e. your sw would advertise > basic=explicit) > > The with-defaults terms need to be more precice: OLD: o report-all: All default data is always reported. NEW: o report-all: All requested server data is always reported. > /martin > Andy From andy@netconfcentral.com Wed Aug 26 13:09: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 310AC3A6D66 for ; Wed, 26 Aug 2009 13:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_54=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 zTGhf6fX2XGE for ; Wed, 26 Aug 2009 13:09:09 -0700 (PDT) Received: from n78.bullet.mail.sp1.yahoo.com (n78.bullet.mail.sp1.yahoo.com [98.136.44.42]) by core3.amsl.com (Postfix) with SMTP id BC09B3A7061 for ; Wed, 26 Aug 2009 13:09:02 -0700 (PDT) Received: from [216.252.122.216] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 26 Aug 2009 20:09:08 -0000 Received: from [68.142.200.221] by t1.bullet.sp1.yahoo.com with NNFMP; 26 Aug 2009 20:09:08 -0000 Received: from [68.142.201.246] by t9.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 20:09:07 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 20:09:07 -0000 X-Yahoo-Newman-Id: 955093.53484.bm@omp407.mail.mud.yahoo.com Received: (qmail 86051 invoked from network); 26 Aug 2009 20:09:07 -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; 26 Aug 2009 20:09:07 -0000 X-YMail-OSG: DEoOKfwVM1nux0RSJH2SjcyvVN1i9ZwRKRZ7ODHTNHCYYA9am2gBPRWWH.t8eL3I3K6Et3.46ZzkdUkyVPtNRe.LdMPe.g1qLsyZe.soDwu4d1kw8sDDW_sHgzqlcPxI9A_tFluuSg.dpEeCZw1uXPCVy_h3XPAmronN9XsiCxKYdIOURiwmJQwGYeolTzP4OdVCAmEc5.CkdsG_Nph78qmFfZORbjpG7jp2fptCC3IwdZFFIE7KOV8c3.gdSOnoeBKfOVDvEb3. X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9595ED.5080601@netconfcentral.com> Date: Wed, 26 Aug 2009 13:07:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200908261713.n7QHDtAw015034@idle.juniper.net> <4A95746E.20006@netconfcentral.com> <20090826.214552.81304929.mbj@tail-f.com> In-Reply-To: <20090826.214552.81304929.mbj@tail-f.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, 26 Aug 2009 20:09:10 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> basic=explicit means that the server considers any leaf >> not explicitly provided by client to be a default. >> >> basic=trim means the server considers any leaf set >> to the schema default value to be a default, >> even if the client explicitly set the leaf to the >> schema-defined default value. >> >> I consider this inconsistency to be an interoperability problem. > > What exactly is the inconsistency, and how is it an interoperability > problem? > >> A default is a schema-assigned value when the element >> is missing in a valid configuration. >> The standard should >> decide what a default is, not every server implementation. >> >> There is no way to even discover what the server will do, >> unless :with-defaults is supported, in which case report-all >> is available, so there is no problem. >> >> Even worse, there is no guarantee that the server will >> use the same unspecified behavior across platforms, >> across versions, or even across sub-agents within >> the same implementation. > > Look at this leaf from the ipfix module: > > leaf sourceIpAddress { > type inet:ip-address; > must "../transportProtocol='udp'"; > description "Sets source IP address if UDP is transport > protocol. If not configured, the IP address assigned to the > outgoing interface is used."; > } > > Do you want to make this illegal? Do you think a new YANG statement > is needed to cover this case? server-assigned would not be > appropriate to use, since it would fix this value, even if the IP > address of the outgoing interface is used. > > I do not want to make any YANG illegal. I want to be able to retrieve all nodes on all servers in a simple and consistent manner (i.e., with-defaults=report-all). I never said I want this to be the only mode, or the default mode; just an available mode on all servers. If the server contains nodes which are being considered in any of the must/when/unique/mandatory/min/max/which-case-is-present/ create-allowed/delete-allowed/select type of database decisions, then the client needs to be able to retrieve them, in order to effectively use the NETCONF protocol. I think the NETMOD WG is trying to codify existing CLI practice too closely, and that is not entirely standards-worthy. Sometimes optional means nothing, like when we made all 9 groups of RMON-1 optional, but every RMON vendor implemented every group anyway. 3rd party developers vote with their feet, and that takes some time to realize. > > /martin > Andy From andy@netconfcentral.com Wed Aug 26 13:19: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 DC73D3A672E for ; Wed, 26 Aug 2009 13:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_54=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 mFcCQdVM5xzd for ; Wed, 26 Aug 2009 13:19:10 -0700 (PDT) Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by core3.amsl.com (Postfix) with SMTP id 0B0E23A6CCA for ; Wed, 26 Aug 2009 13:19:09 -0700 (PDT) Received: from [68.142.200.224] by n16.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 20:19:15 -0000 Received: from [68.142.201.246] by t5.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 20:19:15 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 20:19:15 -0000 X-Yahoo-Newman-Id: 150094.77505.bm@omp407.mail.mud.yahoo.com Received: (qmail 94596 invoked from network); 26 Aug 2009 20:19:14 -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; 26 Aug 2009 20:19:14 -0000 X-YMail-OSG: 9Lm8B.UVM1lLk04YweugWQmUnl5dYlG_ZvrAHapT.RBDEI9Lt_BOR.v7n_r.zZo7Ukdn3XGoNsFUwie894keiSZfOoFWUZcjr.fhjtdZQ0oU0v3q2K5r9gJ4pm_kujU7IJn8flFcu5bpnxhlwidAPzFY1dUFl_E_pEEo.I5N4KLGVek1snLzUhenUL5DRAUXtgI8Nb8A2MisG6ztKIkFnxAEKI39MMn.by1FX9Ixl2UhxJpGZ2jQ0tyeyn5K36n17V9ejpatxMGs X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A959850.7050509@netconfcentral.com> Date: Wed, 26 Aug 2009 13:17:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200908261713.n7QHDtAw015034@idle.juniper.net> <4A95746E.20006@netconfcentral.com> <20090826.214552.81304929.mbj@tail-f.com> In-Reply-To: <20090826.214552.81304929.mbj@tail-f.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, 26 Aug 2009 20:19:10 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> basic=explicit means that the server considers any leaf >> not explicitly provided by client to be a default. >> >> basic=trim means the server considers any leaf set >> to the schema default value to be a default, >> even if the client explicitly set the leaf to the >> schema-defined default value. >> >> I consider this inconsistency to be an interoperability problem. > > What exactly is the inconsistency, and how is it an interoperability > problem? > The NETMOD WG does not have a clear definition of server behavior for server created leafs which are not the YANG default-stmt value. The NETCONF server behavior for configuration retrieval is inconsistent across server implementations. This violates the spirit and intent of the NETCONF protocol, as specified in sec. 1, para 1, sentence 3: Applications can use this straightforward API to send and receive full and partial configuration data sets. Note the phrase "receive full". IMO, the NETCONF WG has failed to deliver on this objective, because every server -- not the standard -- decides what "receive a full configuration data set" means. I am unclear on the exact solution proposal (assigned-by-stmt?) that is being proposed. There have been many partially defined solutions over several months. Is there a complete definition somewhere for review? > > /martin > > > Andy From phil@juniper.net Wed Aug 26 13:24: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 6CD763A6D66 for ; Wed, 26 Aug 2009 13:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 TIKzlbmNenhW for ; Wed, 26 Aug 2009 13:24:03 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 60E283A672E for ; Wed, 26 Aug 2009 13:24:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSpWZ2Jg1j8htXlMukF/wHB6BOA9bjiCT@postini.com; Wed, 26 Aug 2009 13:24:10 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, 26 Aug 2009 13:18:53 -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, 26 Aug 2009 13:18:53 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 13:18:52 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 13:18:52 -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 n7QKIqd52982; Wed, 26 Aug 2009 13:18:52 -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 n7QK6rCn017133; Wed, 26 Aug 2009 20:06:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908262006.n7QK6rCn017133@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090826.215733.158236260.mbj@tail-f.com> Date: Wed, 26 Aug 2009 16:06:53 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 20:18:52.0812 (UTC) FILETIME=[6E1B84C0:01CA268A] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] server supplied leafs and protocol operations 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, 26 Aug 2009 20:24:04 -0000 Martin Bjorklund writes: >Phil Shafer wrote: >> The definition of "basic=explicit" in the w-d draft needs repaired. >> >> o Explicitly set default data: Data that is explicitly set by the >> NETCONF client to its default value. Some servers MAY treat >> explicitly set default data as simple default data, as they may >> not be able to differentiate between them. >> >> Your current definition is way too narrow, blocking SNMP, humans, >> etc. I suggest "Data that is explicitly set to its default value." > >While I agree with the suggested change, note that the term 'explicit' >has nothing to do with the term 'explicitly set default data'. A >server that cares about 'explicitly set default data' implements the >basic mode 'trim'. This is confusing, and should probably be fixed. "trim" means that if I set a leaf to the default value, it disappears, since the server will not report it. "explicit" means that if a user explicitly set it, it will be reported even if the value is equal to the default value. So I disagree that "the term 'explicit' has nothing to do with the term 'explicitly set default data'", since my behavior is to save configuration data that is explicitly set, regardless of value. I'm appended some examples below. Obviously I'm a fan of the "explicit" model, since that's how my code works, but I don't believe in forcing this model on the rest of the world, especially since I believe that will harm the ability of major vendors to adopt NETCONF. We should be able to express what the device is able to do and allow clients to deal with the differences. It's not a "one ring to rule them all" approach, but I believe it is valid, useful, and will help our work to be adopted and used by the largest number of devices. Thanks, Phil ----- In this example, the value for "multiplier" is set to the default (3) and it remains part of the configuration: [edit protocols bgp] phil@dent# show bfd-liveness-detection multiplier | display detail ## ## bfd-liveness-detection: Bidirectional Forwarding Detection (BFD) options ## ## multiplier: Detection time multiplier ## range: 1 .. 255 ## default: 3 ## multiplier 5; [edit protocols bgp] phil@dent# set bfd-liveness-detection multiplier 3 [edit protocols bgp] phil@dent# show bfd-liveness-detection minimum-interval 100; multiplier 3; [edit protocols bgp] phil@dent# show bfd-liveness-detection multiplier | display detail ## ## bfd-liveness-detection: Bidirectional Forwarding Detection (BFD) options ## multiplier: Detection time multiplier ## range: 1 .. 255 ## default: 3 ## multiplier 3; [edit protocols bgp] phil@dent# But other network vendors don't work this way. In this example, the "no exec" statement disappears when I set "exec" (the default) and the "width" statement appears and disappears when it is or isn't set to 80 (the default): terminal-server#show conf Using 1294 out of 32762 bytes ! version 11.3 ... line 16 no exec timeout login response 0 transport input telnet ... ! end terminal-server#conf t Enter configuration commands, one per line. End with CNTL/Z. terminal-server(config)#line 16 terminal-server(config-line)#exec terminal-server(config-line)#width 80 terminal-server(config-line)#^Z terminal-server#show running-config Building configuration... Current configuration: ! version 11.3 ... line 16 timeout login response 0 transport input telnet ... ! end terminal-server#conf t Enter configuration commands, one per line. End with CNTL/Z. terminal-server(config)#line 16 terminal-server(config-line)#width 75 terminal-server(config-line)#^Z terminal-server#show running-config Building configuration... Current configuration: ! version 11.3 ... line 16 timeout login response 0 width 75 transport input telnet ... ! end terminal-server#conf t Enter configuration commands, one per line. End with CNTL/Z. terminal-server(config)#line 16 terminal-server(config-line)#width 80 terminal-server(config-line)#^Z terminal-server#show running-config Building configuration... Current configuration: ! version 11.3 ... line 16 timeout login response 0 transport input telnet ... ! end terminal-server# From cfinss@dial.pipex.com Wed Aug 26 13:32: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 CF3203A6BD0 for ; Wed, 26 Aug 2009 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.385, 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 PcAzg5gyVTlK for ; Wed, 26 Aug 2009 13:32:04 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id AB39E28C58B for ; Wed, 26 Aug 2009 13:32:03 -0700 (PDT) X-Trace: 279093596/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.85/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.85 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: AuwEAGM4lUo+vGlV/2dsb2JhbACDLWCND8dFCYQRBQ X-IronPort-AV: E=Sophos;i="4.44,281,1249254000"; d="scan'208";a="279093596" X-IP-Direction: IN Received: from 1cust85.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.85]) by smtp.pipex.tiscali.co.uk with SMTP; 26 Aug 2009 21:32:07 +0100 Message-ID: <00ca01ca2683$bb6af280$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" References: <4A93F750.7010001@netconfcentral.com><006601ca25a8$e076dca0$0601a8c0@allison> <20090825.224216.118049693.mbj@tail-f.com> Date: Wed, 26 Aug 2009 21:30:16 +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] meaning of config really 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, 26 Aug 2009 20:32:04 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; Sent: Tuesday, August 25, 2009 10:42 PM > "tom.petch" wrote: > > To quote a much-quoted phrase, > > "configuration data: The set of writable data that is required to > > transform a system from its initial default state into its current > > state " > > > > 'writable' tells me capable of being written to, even if noone in > > the world ever actually writes it. > > "its current state" tells me that this "set of writable data" changes > depending on the device's current state. So what the term > "configuration data" means depends on the current state of the box > (which presumably depends on how it is configured...) > > I am not sure what exactly you want to read into the quote above. Apologies that I am not around to reply more promptly; my modus operandi, as you will have seen, means I only get to post a small number of times a day or sometimes only one. So I have read Andy's posts eg Anything I *can* set is configuration, not anything I've *already* set. IMO this is a big difference and the source of the problem with the standard. IMO, the concept that a leaf instance only exists if the client provides it is totally broken wrt/ YANG database validation concepts and mechanisms. and that is a view I agree with. My quote could be read that way but perhaps, more likely, it will be read as config data is only that which would be needed at this instant in time to create current state from 'default initial state' (which of course has nothing to do with the 'default' substatement), whether the value comes from server or client, so what I will actually get as part of config data, or what will be used for constraint checking, millisecond by millisecond, is unpredictable as the server instantiates values or whatever the opposite of instantiate is. That seems difficult operationally, compared with eg the SMI approach where there is an OID, which eg, I can fire a get at and get a response. I like Andy's idea that config data is anything I set, although that might be a stretch given the wording. > > I see server-generated values, which are writable, as > > part of configuration > > So do I. If we had a statement 'assigned-by system', the server would > actually add the value to the config. As such, it would always be > reported. This leaves me unclear where you stand. Agreeing with me seems to say that server-generated values count as config data so who needs assigned-by-system to achieve that? A server-generated value which is part of the configuration means to me that the server has added the value to the config. Tom Petch > > > /martin From phil@juniper.net Wed Aug 26 13:33: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 012CF28C55E for ; Wed, 26 Aug 2009 13:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 vsHR8XXZ9R-S for ; Wed, 26 Aug 2009 13:33:34 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 519B93A6817 for ; Wed, 26 Aug 2009 13:33:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSpWcCsu0AK21Ev5qmDWsO6JTgLr7MVWN@postini.com; Wed, 26 Aug 2009 13:33: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; Wed, 26 Aug 2009 13:28:57 -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, 26 Aug 2009 13:28:57 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 13:28:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 13:28:56 -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 n7QKStd57732; Wed, 26 Aug 2009 13:28:55 -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 n7QKGv58017220; Wed, 26 Aug 2009 20:16:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908262016.n7QKGv58017220@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A95959D.8000004@netconfcentral.com> Date: Wed, 26 Aug 2009 16:16:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 20:28:56.0636 (UTC) FILETIME=[D603BFC0:01CA268B] MIME-Version: 1.0 Content-Type: text/plain 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, 26 Aug 2009 20:33:35 -0000 Andy Bierman writes: >The with-defaults terms need to be more precice: >OLD: > o report-all: All default data is always reported. >NEW: > o report-all: All requested server data is always reported. But what does "server data" mean? As opposed to non-server data? Hmm... on second reading, the definition is considerably worse, since default values are not configuration data. How about: report-defaults: Default values are incorporated with the data returned. Hmmm... is "reported" the wrong term, since APIs return data, not report it. Should we use "return-defaults" or "include-defaults"? Thanks, Phil From phil@juniper.net Wed Aug 26 13:46: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 369CC28C567 for ; Wed, 26 Aug 2009 13:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 6cZR6FDxgdjU for ; Wed, 26 Aug 2009 13:46:42 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 7FBA728C4F2 for ; Wed, 26 Aug 2009 13:46:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSpWfNHGxoshNTO72M69NXGYGUqRDaKgV@postini.com; Wed, 26 Aug 2009 13:46:49 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, 26 Aug 2009 13:41:25 -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, 26 Aug 2009 13:41:25 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 13:41:25 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 13:41:24 -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 n7QKfOd64945; Wed, 26 Aug 2009 13:41:24 -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 n7QKTPZq017369; Wed, 26 Aug 2009 20:29:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908262029.n7QKTPZq017369@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A959850.7050509@netconfcentral.com> Date: Wed, 26 Aug 2009 16:29:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2009 20:41:24.0741 (UTC) FILETIME=[93EB8350:01CA268D] MIME-Version: 1.0 Content-Type: text/plain 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, 26 Aug 2009 20:46:43 -0000 Andy Bierman writes: >IMO, the NETCONF WG has failed to deliver on >this objective, because every server -- not the standard -- >decides what "receive a full configuration data set" means. The NETCONF and YANG WGs have worked hard to give some flexibility in terms of how defaults are handled. I do not see this as a failure but as a successful effort to deal with the world as it exists, without trying to force a single world view on every device. At the end of the day, a client can learn and deal with different devices in a reasonable manner. Devices can implement servers and modules with minimal deviation. Life is good. >I am unclear on the exact solution proposal (assigned-by-stmt?) >that is being proposed. There have been many partially defined >solutions over several months. Is there a complete definition >somewhere for review? The last WG concensus was that we did not want to include this work in the current YANG work. Perhaps a few of us should write this up as an I-D and see if the concensus still holds. But IMHO "assigned-by system" is a rare and uninteresting corner case. Pretending this casts the entire effort as a failure is sillyness. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 14:11:14 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 2FEF63A6C78 for ; Wed, 26 Aug 2009 14:11:14 -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 z-PWU69O2-56 for ; Wed, 26 Aug 2009 14:11:13 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 359E83A6781 for ; Wed, 26 Aug 2009 14:11:13 -0700 (PDT) Received: from [68.142.200.227] by n17.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 21:11:17 -0000 Received: from [68.142.201.254] by t8.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 21:11:17 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 21:11:17 -0000 X-Yahoo-Newman-Id: 544098.67788.bm@omp415.mail.mud.yahoo.com Received: (qmail 44367 invoked from network); 26 Aug 2009 21:11:17 -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; 26 Aug 2009 21:11:16 -0000 X-YMail-OSG: AyHIgz0VM1nwGNFVFI1B0brcGZJTnY5S5baoEkLwI87kSR5PxfPEDo5V7krB1ihtG5rMn2uG8f8iGd6a7lt.jxNamLoQrqU0bi8CdwS_ZIpct6BSKI959O1Y8AfPU0afyTxSGXqSVXyjIL2RQ6m7XkNqtYiFZTfwFkipvbmHcA0GLe.9ylV_R.ESyjzizSi9DH3_hG1y.RUdUr4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95A4FA.8090805@netconfcentral.com> Date: Wed, 26 Aug 2009 14:11:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908262029.n7QKTPZq017369@idle.juniper.net> In-Reply-To: <200908262029.n7QKTPZq017369@idle.juniper.net> 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, 26 Aug 2009 21:11:14 -0000 Phil Shafer wrote: > Andy Bierman writes: >> IMO, the NETCONF WG has failed to deliver on >> this objective, because every server -- not the standard -- >> decides what "receive a full configuration data set" means. > > The NETCONF and YANG WGs have worked hard to give some flexibility > in terms of how defaults are handled. I do not see this as a failure > but as a successful effort to deal with the world as it exists, > without trying to force a single world view on every device. > The true measure of a standard is interoperability, not flexibility. > At the end of the day, a client can learn and deal with different > devices in a reasonable manner. Devices can implement servers and > modules with minimal deviation. Life is good. > >> I am unclear on the exact solution proposal (assigned-by-stmt?) >> that is being proposed. There have been many partially defined >> solutions over several months. Is there a complete definition >> somewhere for review? > > The last WG concensus was that we did not want to include this work > in the current YANG work. Perhaps a few of us should write this > up as an I-D and see if the concensus still holds. > > But IMHO "assigned-by system" is a rare and uninteresting corner > case. Pretending this casts the entire effort as a failure is > sillyness. > It is not a failure, but IMO it is not that suitable for use by 3rd party developers who thought they were getting something really better than before. We're trading in the SMIv2 data silos for YANG data silos. We're trading in SMIv2 DESCRIPTION clauses for YANG description statements. It is obvious that automation-based tools are only going to work with servers that supply them with sufficient machine-readable and device-retrievable data. The IETF standards do not need to specify any automation requirements, or mandate that a server support any sort of automation. Even the description-stmt is optional in YANG, so the requirements for specifying data model semantics are as low as they can go. Every machine-readable statement except 'type-stmt' is optional-to-use. > Thanks, > Phil > Andy From mbj@tail-f.com Wed Aug 26 14:33: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 5CB9C28C53C for ; Wed, 26 Aug 2009 14:33:31 -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 r-2zIL4C96MT for ; Wed, 26 Aug 2009 14:33:30 -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 710FA28C4C3 for ; Wed, 26 Aug 2009 14:32:54 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EA9776C59E; Wed, 26 Aug 2009 23:33:00 +0200 (CEST) Date: Wed, 26 Aug 2009 23:32:59 +0200 (CEST) Message-Id: <20090826.233259.182862400.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <00ca01ca2683$bb6af280$0601a8c0@allison> References: <006601ca25a8$e076dca0$0601a8c0@allison> <20090825.224216.118049693.mbj@tail-f.com> <00ca01ca2683$bb6af280$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] meaning of config really 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, 26 Aug 2009 21:33:31 -0000 "tom.petch" wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: ; ; > > Sent: Tuesday, August 25, 2009 10:42 PM > > > "tom.petch" wrote: > > > I see server-generated values, which are writable, as > > > part of configuration > > > > So do I. If we had a statement 'assigned-by system', the server would > > actually add the value to the config. As such, it would always be > > reported. > > This leaves me unclear where you stand. Agreeing with me seems to say > that server-generated values count as config data Exactly. See also my mail on terminology (http://www.ietf.org/mail-archive/web/netmod/current/msg03665.html). > so who needs assigned-by-system to achieve that? It has been argued (e.g. in http://www.ietf.org/mail-archive/web/netmod/current/msg03437.html) that it is needed in order for the server to behave predictable. /martin From mbj@tail-f.com Wed Aug 26 14:38: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 0265F3A6CF5 for ; Wed, 26 Aug 2009 14:38:50 -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 eflzepGPxs1l for ; Wed, 26 Aug 2009 14:38:49 -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 1BB8C3A6A4A for ; Wed, 26 Aug 2009 14:38:49 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 711A776C59E; Wed, 26 Aug 2009 23:38:55 +0200 (CEST) Date: Wed, 26 Aug 2009 23:38:55 +0200 (CEST) Message-Id: <20090826.233855.25803494.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908262006.n7QK6rCn017133@idle.juniper.net> References: <20090826.215733.158236260.mbj@tail-f.com> <200908262006.n7QK6rCn017133@idle.juniper.net> 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] server supplied leafs and protocol operations 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, 26 Aug 2009 21:38:50 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Phil Shafer wrote: > >> The definition of "basic=explicit" in the w-d draft needs repaired. > >> > >> o Explicitly set default data: Data that is explicitly set by the > >> NETCONF client to its default value. Some servers MAY treat > >> explicitly set default data as simple default data, as they may > >> not be able to differentiate between them. > >> > >> Your current definition is way too narrow, blocking SNMP, humans, > >> etc. I suggest "Data that is explicitly set to its default value." > > > >While I agree with the suggested change, note that the term 'explicit' > >has nothing to do with the term 'explicitly set default data'. A > >server that cares about 'explicitly set default data' implements the > >basic mode 'trim'. This is confusing, and should probably be fixed. > > "trim" means that if I set a leaf to the default value, it > disappears, since the server will not report it. > > "explicit" means that if a user explicitly set it, it will > be reported even if the value is equal to the default value. > > So I disagree that "the term 'explicit' has nothing to do with the > term 'explicitly set default data'", since my behavior is to save > configuration data that is explicitly set, regardless of value. We agree here; what I meant was that if your mode is 'explicit', you treat any data set by the client the same way - you probably don't even check if it matches the default or not. So you don't care if it happens to match the term "explicitly set default data". But if your mode is 'trim', you have to care. > Obviously I'm a fan of the "explicit" model, since that's how > my code works, but I don't believe in forcing this model on the > rest of the world, especially since I believe that will harm the > ability of major vendors to adopt NETCONF. We should be able to > express what the device is able to do and allow clients to deal > with the differences. Agreed, and I still think that's what we're doing with the "default" statement in YANG and :with-defaults capability. /martin From andy@netconfcentral.com Wed Aug 26 14:42: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 57BC03A70DE for ; Wed, 26 Aug 2009 14:42:00 -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 Bt0HGeZBra8M for ; Wed, 26 Aug 2009 14:41:59 -0700 (PDT) Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id E2C733A70A9 for ; Wed, 26 Aug 2009 14:41:58 -0700 (PDT) Received: from [68.142.200.221] by n13.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 21:42:03 -0000 Received: from [68.142.201.248] by t9.bullet.mud.yahoo.com with NNFMP; 26 Aug 2009 21:42:03 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 26 Aug 2009 21:42:03 -0000 X-Yahoo-Newman-Id: 286533.57834.bm@omp409.mail.mud.yahoo.com Received: (qmail 90489 invoked from network); 26 Aug 2009 21:42:02 -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; 26 Aug 2009 21:42:02 -0000 X-YMail-OSG: ZNCEqsUVM1mmUzfkFdAWiyVGDuj9KAa6_pgd2FTDb9gKaF8TR6reF5DNY1IG5fi_3DQcg27Qu.T9S_TY.1Gw4yWIR2sE4chCglC2x21fpx0ptW.rZ0anU59eOfcP6xSzsYBFj3enoFfXFkI3JMVRXNqLaDIrDTe7rb61COkrwae5ftk.Y3nh4pBiyAmqVy9ZuLDzgXFZiAnCy4Ojq5EpqFzr_g4qiNRGV39WYFllQ3MD_vfoLDJvycNP9iL0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95AC30.5090405@netconfcentral.com> Date: Wed, 26 Aug 2009 14:42:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <006601ca25a8$e076dca0$0601a8c0@allison> <20090825.224216.118049693.mbj@tail-f.com> <00ca01ca2683$bb6af280$0601a8c0@allison> <20090826.233259.182862400.mbj@tail-f.com> In-Reply-To: <20090826.233259.182862400.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 config really 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, 26 Aug 2009 21:42:00 -0000 Martin Bjorklund wrote: > "tom.petch" wrote: >> ----- Original Message ----- >> From: "Martin Bjorklund" >> To: >> Cc: ; ; >> >> Sent: Tuesday, August 25, 2009 10:42 PM >> >>> "tom.petch" wrote: >>>> I see server-generated values, which are writable, as >>>> part of configuration >>> So do I. If we had a statement 'assigned-by system', the server would >>> actually add the value to the config. As such, it would always be >>> reported. >> This leaves me unclear where you stand. Agreeing with me seems to say >> that server-generated values count as config data > > Exactly. See also my mail on terminology > (http://www.ietf.org/mail-archive/web/netmod/current/msg03665.html). > >> so who needs assigned-by-system to achieve that? > > It has been argued > (e.g. in http://www.ietf.org/mail-archive/web/netmod/current/msg03437.html) > that it is needed in order for the server to behave predictable. > But Joel is confused along with the rest of us: ..... Maybe my addition will just add confusion, although I beleive I agree with Andy and Juergen. (As a caveat, I use "means" below to indicate what I think the YANG text explicitly requires.) 1) Mandatory means that if a manager is writing that part of the tree, the manager MUST provide a value for that item. 2) Default means that if no manager has not set the item, the item will have the explicit value given in the default clause in the data model. ..... Neither one of these assertions is correct. Mandatory means the node MUST exist in a valid database, and says nothing about client vs. server created. I'm not sure the WG has a real definition of a default. I know there are a lot of circular references that end up saying that a default is whatever the server decides it means. > > /martin > Andy From andy@netconfcentral.com Wed Aug 26 15:59: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 31F563A6CD0 for ; Wed, 26 Aug 2009 15:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_54=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 uR9NLFkMfLOe for ; Wed, 26 Aug 2009 15:59:46 -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 62B4B3A6A1B for ; Wed, 26 Aug 2009 15:59:46 -0700 (PDT) Received: (qmail 45160 invoked from network); 26 Aug 2009 22:59:51 -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; 26 Aug 2009 22:59:51 -0000 X-YMail-OSG: 0.zBljIVM1m55TV_La4YoUcbpwCS2vMxFWPpfrIcssyYYdoFl0yxHXWuHPcy39XSjKoEIlbYKXun1VhAZNeUyZomPWrbRFIO4tCWaUECi9rt7Vc7YPlwlCOxHvfVIVxA3pBc0zqzVlbO8Xh9cHIyqI02qucY3RZIbZdJ7bmQjRYRZzWMMcnCKk_dteipKl.ZtF3EkNoqNCvm4ugzfMsDpqAM43j.kf6CXlrZlnTG2uANEDEdJOwyj0r5BhWz4SoFVl4ereaMtT3dNbqy X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95BE6D.3090106@netconfcentral.com> Date: Wed, 26 Aug 2009 15:59:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908262029.n7QKTPZq017369@idle.juniper.net> In-Reply-To: <200908262029.n7QKTPZq017369@idle.juniper.net> 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, 26 Aug 2009 22:59:47 -0000 Phil Shafer wrote: ... > At the end of the day, a client can learn and deal with different > devices in a reasonable manner. Devices can implement servers and > modules with minimal deviation. Life is good. Really? The client can learn the operational values that are in use on the server? By client, you mean a human who knows where to look up YANG modules and other documentation? That counts as retrieving information through the NETCONF protocol? Imagine an independent NETCONF application that is started up in a new network. The application wants to examine what configuration is already in place for the 'foo' module, to do its job. But the server has decided that "the" client already knows what configuration settings "the" client has already provided, so it refuses to return those leafs. Except there isn't just one client, and it is absurd to expect all applications to keep in synch, instead of simply returning data the client asked for in a get request. That's how useful basic=explicit is to client applications. Let's look at basic=trim now. Instead of simply answering a direct get request with the current value of a leaf, the server can decide never to allow the client to retrieve this leaf, because the server-selected value MAY be documented in an off-line file somewhere. The server wants to make sure the client does not waste bandwidth. It is much better if the client just deduces the current operational state from available documentation. BTW, there is no mandatory standard way to ever know what a given server implementation considers to be a node which is not available for retrieval. There is a circular definition: if the server thinks the leaf is a default, then it is a default. Hey SNMP application developers! Can you imagine if this this was the way get, get-next and get-bulk PDUs worked? > ... > Thanks, > Phil > Andy From saperia@jdscons.com Wed Aug 26 16:18: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 3602F3A6CBF for ; Wed, 26 Aug 2009 16:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 XSl6+jSAZb86 for ; Wed, 26 Aug 2009 16:18:54 -0700 (PDT) Received: from rs40.luxsci.com (rs40.luxsci.com [65.61.166.82]) by core3.amsl.com (Postfix) with ESMTP id 05E483A6AB0 for ; Wed, 26 Aug 2009 16:18:53 -0700 (PDT) Received: from [10.1.10.148] (75-150-72-14-NewEngland.hfc.comcastbusiness.net [75.150.72.14] (may be forged)) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id n7QNIwtU023765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 26 Aug 2009 18:18:59 -0500 Message-Id: <1C4F63EA-DA9E-42D7-AB78-135D84188161@jdscons.com> From: Jon Saperia To: Andy Bierman In-Reply-To: <4A95BE6D.3090106@netconfcentral.com> Content-Type: multipart/alternative; boundary=Apple-Mail-13-291115032 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 19:18:58 -0400 References: <200908262029.n7QKTPZq017369@idle.juniper.net> <4A95BE6D.3090106@netconfcentral.com> X-Mailer: Apple Mail (2.936) 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, 26 Aug 2009 23:18:55 -0000 --Apple-Mail-13-291115032 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 26, 2009, at 6:59 PM, Andy Bierman wrote: > Phil Shafer wrote: > ... >> At the end of the day, a client can learn and deal with different >> devices in a reasonable manner. Devices can implement servers and >> modules with minimal deviation. Life is good. > > > Really? The client can learn the operational values that are > in use on the server? By client, you mean a human who > knows where to look up YANG modules and other documentation? > That counts as retrieving information through the NETCONF protocol? > > Imagine an independent NETCONF application that is > started up in a new network. The application wants to > examine what configuration is already in place for the 'foo' > module, to do its job. > > But the server has decided that "the" client already knows > what configuration settings "the" client > has already provided, so it refuses to return those leafs. > Except there isn't just one client, and > it is absurd to expect all applications to keep in synch, instead of > simply returning data the client asked for in a get request. > That's how useful basic=explicit is to client applications. > > Let's look at basic=trim now. > Instead of simply answering a direct get request > with the current value of a leaf, the server can decide > never to allow the client to retrieve this leaf, > because the server-selected value MAY be documented > in an off-line file somewhere. The server wants to > make sure the client does not waste bandwidth. > It is much better if the client just deduces > the current operational state from available documentation. If I understand Andy's point here, I think this is an issue of concern - to the extent one wants to write effective applications.. If one wants to write applications that are effective, they need to know, for any system they manage: What the defaults are for any values/parameters there are in the system. Are the defaults in use or where they changed as part of the creation, or after. Have the defaults changed. Knowing if the system supplied the information, it was provided by a CLI interaction or by another application is also important. The 'servers' in this context, not behaving consistently is a concern. I may have misunderstood, but not meeting these requirements would make applications more difficult. While it is possible to write software to read documentation if consistently and well written, but... It seems like an unnecessary and costly complication for the application developer. /jon > > BTW, there is no mandatory standard way to ever know what a > given server implementation considers to be a node which > is not available for retrieval. There is a circular definition: > if the server thinks the leaf is a default, then it is a default. > > Hey SNMP application developers! Can you imagine if > this this was the way get, get-next and get-bulk PDUs worked? > >> ... >> Thanks, >> Phil >> > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --Apple-Mail-13-291115032 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Aug 26, 2009, = at 6:59 PM, Andy Bierman wrote:

Phil = Shafer wrote:
...
At the end of the day, = a client can learn and deal with different
devices in a reasonable manner.  Devices can = implement servers and
modules = with minimal deviation.  Life is = good.


Really? The client can learn the = operational values that are
in use on the server?  By client, = you mean a human who
knows where to look up YANG modules and other = documentation?
That counts as retrieving information through the = NETCONF protocol?

Imagine an independent NETCONF application that = is
started up in a new network.  The application wants = to
examine what configuration is already in place for the = 'foo'
module, to do its job.

But the server has decided that = "the" client already knows
what configuration settings "the" = client
has already provided, so it refuses to return those = leafs.
Except there isn't just one client, and
it is absurd to = expect all applications to keep in synch, instead of
simply returning = data the client asked for in a get request.
That's how useful = basic=3Dexplicit is to client = applications.

Let's look at basic=3Dtrim now.
Instead of = simply answering a direct get request
with the current value of a = leaf, the server can decide
never to allow the client to retrieve = this leaf,
because the server-selected value MAY be documented
in = an off-line file somewhere.  The server wants to
make sure the = client does not waste bandwidth.
It is much better if the client just = deduces
the current operational state from available = documentation.

If I = understand Andy's point here, I think this is an issue of concern - to = the extent one wants to write effective applications..  If one = wants to write applications that are effective, they need to know, for = any system they manage:

  1. What the defaults are for any = values/parameters there are in the system.
  2. Are the defaults in = use or where they changed as part of the creation, or = after.
  3. Have the defaults changed.
  4. Knowing if the system = supplied the information, it was provided by a CLI interaction or by = another application is also important.
  5. The 'servers' in this = context, not behaving consistently is a = concern. 

I may have misunderstood, = but not meeting these requirements would make applications more = difficult.

While it is possible to = write software to read documentation if consistently and well written, = but...  It seems like an unnecessary and costly complication for = the application developer. =   

/jon

BTW, there is no mandatory standard way to ever = know what a
given server implementation considers to be a node = which
is not available for retrieval.  There is a circular = definition:
if the server thinks the leaf is a default, then it is a = default.

Hey SNMP application developers! Can you imagine = if
this this was the way get, get-next and get-bulk PDUs = worked?

...
Thanks,
= Phil


Andy
_______________________________= ________________
netmod mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod


= --Apple-Mail-13-291115032-- From andy@netconfcentral.com Wed Aug 26 17:17: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 6B5E53A6C13 for ; Wed, 26 Aug 2009 17:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_54=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 sbqHXeDBCHZ2 for ; Wed, 26 Aug 2009 17:17:23 -0700 (PDT) Received: from n71.bullet.mail.sp1.yahoo.com (n71.bullet.mail.sp1.yahoo.com [98.136.44.36]) by core3.amsl.com (Postfix) with SMTP id 9F14C3A6BCB for ; Wed, 26 Aug 2009 17:17:23 -0700 (PDT) Received: from [69.147.84.144] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 27 Aug 2009 00:17:28 -0000 Received: from [68.142.200.227] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 27 Aug 2009 00:17:28 -0000 Received: from [68.142.201.252] by t8.bullet.mud.yahoo.com with NNFMP; 27 Aug 2009 00:17:28 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 00:17:28 -0000 X-Yahoo-Newman-Id: 603394.9216.bm@omp413.mail.mud.yahoo.com Received: (qmail 22357 invoked from network); 27 Aug 2009 00:17:28 -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; 27 Aug 2009 00:17:28 -0000 X-YMail-OSG: PKoWYNIVM1mmjX1_vCXcHRKCjPE0W69iPH7UHYL5hNkGyoN_6EsrtnpiyInMBHbI3s.XkFDv4ZzbB6h68xyJhcMDS.x2PUgksdW8hsxs0loOfcedq.jIHUb66YkBPqP34bBnyYUfHkdWZ0K69FrSe6C1klHOgPIulkFICwJAKXNBZYYV.s8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95D09E.9090506@netconfcentral.com> Date: Wed, 26 Aug 2009 17:17:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jon Saperia References: <200908262029.n7QKTPZq017369@idle.juniper.net> <4A95BE6D.3090106@netconfcentral.com> <1C4F63EA-DA9E-42D7-AB78-135D84188161@jdscons.com> In-Reply-To: <1C4F63EA-DA9E-42D7-AB78-135D84188161@jdscons.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: Thu, 27 Aug 2009 00:17:24 -0000 Jon Saperia wrote: > > On Aug 26, 2009, at 6:59 PM, Andy Bierman wrote: > >> Phil Shafer wrote: >> ... >>> At the end of the day, a client can learn and deal with different >>> devices in a reasonable manner. Devices can implement servers and >>> modules with minimal deviation. Life is good. >> >> >> Really? The client can learn the operational values that are >> in use on the server? By client, you mean a human who >> knows where to look up YANG modules and other documentation? >> That counts as retrieving information through the NETCONF protocol? >> >> Imagine an independent NETCONF application that is >> started up in a new network. The application wants to >> examine what configuration is already in place for the 'foo' >> module, to do its job. >> >> But the server has decided that "the" client already knows >> what configuration settings "the" client >> has already provided, so it refuses to return those leafs. >> Except there isn't just one client, and >> it is absurd to expect all applications to keep in synch, instead of >> simply returning data the client asked for in a get request. >> That's how useful basic=explicit is to client applications. >> >> Let's look at basic=trim now. >> Instead of simply answering a direct get request >> with the current value of a leaf, the server can decide >> never to allow the client to retrieve this leaf, >> because the server-selected value MAY be documented >> in an off-line file somewhere. The server wants to >> make sure the client does not waste bandwidth. >> It is much better if the client just deduces >> the current operational state from available documentation. > > If I understand Andy's point here, I think this is an issue of concern - > to the extent one wants to write effective applications.. If one wants > to write applications that are effective, they need to know, for any > system they manage: > > 1. What the defaults are for any values/parameters there are in the > system. > 2. Are the defaults in use or where they changed as part of the > creation, or after. > 3. Have the defaults changed. > 4. Knowing if the system supplied the information, it was provided by > a CLI interaction or by another application is also important. > 5. The 'servers' in this context, not behaving consistently is a > concern. > > I don't really understand the relative importance of all these features. Which definition of the word 'default' are you using? > I may have misunderstood, but not meeting these requirements would make > applications more difficult. > > While it is possible to write software to read documentation if > consistently and well written, but... It seems like an unnecessary and > costly complication for the application developer. > Seems rather costly to me. Software that finds and reads all the relevant description statements and vendor documentation and then does useful work without any human intervention -- sounds expensive. I don't understand why it is considered a burden on NETCONF servers to return all the operational data. This was never considered a burden for SNMP agents, and managed device resources have increased 20 or 100 fold since SNMP made that standards decision. > /jon Andy From phil@juniper.net Wed Aug 26 17:53: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 645F93A6D51 for ; Wed, 26 Aug 2009 17:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 X-C2F1-cWKqT for ; Wed, 26 Aug 2009 17:53:32 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 677953A6D0E for ; Wed, 26 Aug 2009 17:53:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSpXY/apmCibIZXZCypCOAD8Go8FHkAE2@postini.com; Wed, 26 Aug 2009 17:53:20 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, 26 Aug 2009 17:51:29 -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, 26 Aug 2009 17:51:29 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 17:51:29 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 17:51:29 -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 n7R0pSd90067; Wed, 26 Aug 2009 17:51:28 -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 n7R0dUkM018865; Thu, 27 Aug 2009 00:39:30 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908270039.n7R0dUkM018865@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A95A4FA.8090805@netconfcentral.com> Date: Wed, 26 Aug 2009 20:39:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 00:51:29.0051 (UTC) FILETIME=[832F86B0:01CA26B0] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 00:53:33 -0000 Andy Bierman writes: >The true measure of a standard is interoperability, not flexibility. The true way to interoperability is thru flexibility and capability discovery, Grasshopper. >It is obvious that automation-based tools are only going >to work with servers that supply them with sufficient >machine-readable and device-retrievable data. YANG supplies them with these. Yes, there are odd corner cases that are not included in this first release, but they can be added via extensions. YANG offers a large set of descriptive modeling features in a reasonable small language. Let's publish and learn where the awkward points are. I'm willing to bet that "assigned-by system" is not on the Top Ten list. Thanks, Phil From phil@juniper.net Wed Aug 26 17:54:32 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 4D1693A6BBD for ; Wed, 26 Aug 2009 17:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 eQKdeLQtWXSo for ; Wed, 26 Aug 2009 17:54:31 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id B74493A6A0D for ; Wed, 26 Aug 2009 17:54:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSpXZSxvu0+PpT7aQBAi/T5ccpPMXZLdg@postini.com; Wed, 26 Aug 2009 17:54:38 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, 26 Aug 2009 17:52: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); Wed, 26 Aug 2009 17:52:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 17:52:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 17:52: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 n7R0qZd90401; Wed, 26 Aug 2009 17:52:35 -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 n7R0eaZw018896; Thu, 27 Aug 2009 00:40:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908270040.n7R0eaZw018896@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090826.233855.25803494.mbj@tail-f.com> Date: Wed, 26 Aug 2009 20:40:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 00:52:36.0082 (UTC) FILETIME=[AB23A520:01CA26B0] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] server supplied leafs and protocol operations 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: Thu, 27 Aug 2009 00:54:32 -0000 Martin Bjorklund writes: >We agree here; what I meant was that if your mode is 'explicit', you >treat any data set by the client the same way - you probably don't >even check if it matches the default or not. So you don't care if it >happens to match the term "explicitly set default data". But if your >mode is 'trim', you have to care. Ah, cool. We are in complete agreement. Thanks, Phil From phil@juniper.net Wed Aug 26 18:03: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 8AD2E3A6A21 for ; Wed, 26 Aug 2009 18:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 nP9Gxb5kElRs for ; Wed, 26 Aug 2009 18:03:53 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id DCC663A6BF8 for ; Wed, 26 Aug 2009 18:03:52 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSpXbZWuk9I7Q04cR/UIyxHheCm0P3LeF@postini.com; Wed, 26 Aug 2009 18:04:00 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, 26 Aug 2009 18:01:48 -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, 26 Aug 2009 18:01:48 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:01:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:01: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 n7R11jd95080; Wed, 26 Aug 2009 18:01: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 n7R0nlWO018984; Thu, 27 Aug 2009 00:49:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908270049.n7R0nlWO018984@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A95BE6D.3090106@netconfcentral.com> Date: Wed, 26 Aug 2009 20:49:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 01:01:46.0437 (UTC) FILETIME=[F32D2750:01CA26B1] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 01:03:54 -0000 Andy Bierman writes: >Really? The client can learn the operational values that are >in use on the server? Nope. We dealing with configuration models, not operational data. I don't think we're anywhere near messing with operational data. >By client, you mean a human who >knows where to look up YANG modules and other documentation? >That counts as retrieving information through the NETCONF protocol? Clients manipulating data in YANG-based models should know how to look up data in a YANG module. This is the minimum bar. We are not making YANG so modelers can write models that no one reads. >That's how useful basic=explicit is to client applications. Here we simply disagree, and I'm fairly certain that you aren't seeing it. We've stewed on this topic for long enough. I think we have concensus. I think we've hard concensus a number of times. Let's move on. Worse case: you are right, the working group is wrong, and the marketplace will mandate the implementation of the with-defaults capability. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 18:09: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 CD7943A6BF8 for ; Wed, 26 Aug 2009 18:09:25 -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 OWanu2Zx7DUA for ; Wed, 26 Aug 2009 18:09:25 -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 05A8C3A68A2 for ; Wed, 26 Aug 2009 18:09:24 -0700 (PDT) Received: (qmail 50468 invoked from network); 27 Aug 2009 01:09:30 -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; 27 Aug 2009 01:09:29 -0000 X-YMail-OSG: A12ncQIVM1n3ithBnyQ_InVnVkWP5nFEdZe.giCepG6YHArKkeA1Og94h7pSR0W2mKWuPBtUFQtlcJNpJEvtP.8VIAlDG3aGsis31lr5kkk5t2ZFwzH5YMVMT.X0a7dtDi1HbrhHriPHqt0GrIFYp5.8bM9qaPvsiXweA5ez42ULROW9q1Ck99ogHvcNL.meMZi3qC.rWxK76m1kpBTYOvrAefpC6XhDM5rdI_ZuWuHeih5cXJXnuKY9CIUzVlXK6h93ZOBFprwuZNtb X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95DC54.8080904@netconfcentral.com> Date: Wed, 26 Aug 2009 18:07:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908270039.n7R0dUkM018865@idle.juniper.net> In-Reply-To: <200908270039.n7R0dUkM018865@idle.juniper.net> 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: Thu, 27 Aug 2009 01:09:25 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The true measure of a standard is interoperability, not flexibility. > > The true way to interoperability is thru flexibility and > capability discovery, Grasshopper. spoken like a true server developer. > >> It is obvious that automation-based tools are only going >> to work with servers that supply them with sufficient >> machine-readable and device-retrievable data. > > YANG supplies them with these. Yes, there are odd corner cases > that are not included in this first release, but they can be added > via extensions. YANG offers a large set of descriptive modeling > features in a reasonable small language. > > Let's publish and learn where the awkward points are. I'm willing > to bet that "assigned-by system" is not on the Top Ten list. > At first, I accepted the premise that the "server does not store the defaults", so they cannot be returned. After a lot more thought and implementation experience, I think that is utter nonsense. If the server does not store the default, then it must know the value some other way, perhaps some is_value_default() callback. If the server does not know the leaf is a default, then it cannot know to skip it when it is requested in a or request. The sever MUST know the leaf exists if the 'default' leaf is being considered in YANG validation procedures, and we all agree that is the case. So the server is always capable of returning all leafs that it is using. All the complexity created for the client due to 'server flexibility' is unwarranted. > Thanks, > Phil > Andy From phil@juniper.net Wed Aug 26 18:15:21 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 226AB3A6BD1 for ; Wed, 26 Aug 2009 18:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 xMYt4DspRnEH for ; Wed, 26 Aug 2009 18:15:20 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 9DC703A6452 for ; Wed, 26 Aug 2009 18:15:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSpXeLRN+iAvKacrUHjUoh6Kc4lc3bbmJ@postini.com; Wed, 26 Aug 2009 18:15:27 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, 26 Aug 2009 18:11:20 -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, 26 Aug 2009 18:11:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:11:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:11:19 -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 n7R1BJd99158; Wed, 26 Aug 2009 18:11:19 -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 n7R0xKVO019068; Thu, 27 Aug 2009 00:59:20 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908270059.n7R0xKVO019068@idle.juniper.net> To: Jon Saperia In-Reply-To: <1C4F63EA-DA9E-42D7-AB78-135D84188161@jdscons.com> Date: Wed, 26 Aug 2009 20:59:20 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 01:11:19.0856 (UTC) FILETIME=[48F5F300:01CA26B3] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 01:15:21 -0000 Jon Saperia writes: >While it is possible to write software to read documentation if >consistently and well written, but... It seems like an unnecessary >and costly complication for the application developer. Given the investment in the YANG module, and the valuable content already there (hierarchy, types, mandatory, keys, unique, must, etc), the additional cost of learning default values is near zero. The application needs to know if it needs to make a leaf, needs to know its parent hierachy, its type definition, and a litany of constraints put on it by the modeler. The default value is the least of the application's concern. Mixing it (or any meta-data) into the configuration data is a mistake on par with decorating the leaf with attributes containing it's other meta-data: 42 Worse, since you can't differential a default from something a human user explicitly set. I count clear up the above by discarding all attributes, but I don't know enough to discard uninteresting defaults without discarding human input. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 18:25:17 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 9490A28C173 for ; Wed, 26 Aug 2009 18:25:17 -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 xmLBo3TIVCXg for ; Wed, 26 Aug 2009 18:25:16 -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 C9BE328C159 for ; Wed, 26 Aug 2009 18:25:16 -0700 (PDT) Received: (qmail 25559 invoked from network); 27 Aug 2009 01:25:21 -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; 27 Aug 2009 01:25:20 -0000 X-YMail-OSG: ldtvakMVM1lGtINaPtJtDGNz2uZ__cx1Qs2XiWhU1NZgo8Bo8Dz9Yd7DvemqbF8cUcn9teD.qG4zDtm7yeauASSprVsC.tXHEly7lBJn2K72eKdKoBBEjj8GcFefWV.1J13h3SA130M47vq2s1krT0ddo4hnI6NeTQjiWXK1q4RhBXU4drERyGMbeTX8K0Kq_72qs7JeqCTqu8LCrPy8t_qoFHxHj_y8m8.6ynufZV2p7Ln4ZWFMZ5f65OVATMyWLd0hcNRE4X4QL6Me X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95E086.3060606@netconfcentral.com> Date: Wed, 26 Aug 2009 18:25:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908270049.n7R0nlWO018984@idle.juniper.net> In-Reply-To: <200908270049.n7R0nlWO018984@idle.juniper.net> 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: Thu, 27 Aug 2009 01:25:17 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Really? The client can learn the operational values that are >> in use on the server? > > Nope. We dealing with configuration models, not operational > data. I don't think we're anywhere near messing with > operational data. > >> By client, you mean a human who >> knows where to look up YANG modules and other documentation? >> That counts as retrieving information through the NETCONF protocol? > > Clients manipulating data in YANG-based models should know how to > look up data in a YANG module. This is the minimum bar. We > are not making YANG so modelers can write models that no one > reads. Sure -- why use up 10 milli-seconds of the server's precious resources when you can hire sysadmins that can spend hours looking up the same information manually. What a great plan. > >> That's how useful basic=explicit is to client applications. > > Here we simply disagree, and I'm fairly certain that you aren't > seeing it. We've stewed on this topic for long enough. I think > we have concensus. I think we've hard concensus a number of times. > Let's move on. > > Worse case: you are right, the working group is wrong, and the > marketplace will mandate the implementation of the with-defaults > capability. > perhaps. IMO, the way YANG and NETCONF deal with defaults is very complicated, and makes the entire protocol harder to learn and understand. > Thanks, > Phil > Andy From phil@juniper.net Wed Aug 26 18:28: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 DB5173A6949 for ; Wed, 26 Aug 2009 18:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 eeHkbHQDHMIk for ; Wed, 26 Aug 2009 18:28:37 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id C89F928C2CE for ; Wed, 26 Aug 2009 18:28:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSpXhMzsrfBCu1TPQ8NLz93EWQ60GL5cW@postini.com; Wed, 26 Aug 2009 18:28:22 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; Wed, 26 Aug 2009 18:26:04 -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, 26 Aug 2009 18:26:04 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:26:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:26:03 -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 n7R1Q3d05909; Wed, 26 Aug 2009 18:26:03 -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 n7R1E43S019239; Thu, 27 Aug 2009 01:14:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908270114.n7R1E43S019239@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A95DC54.8080904@netconfcentral.com> Date: Wed, 26 Aug 2009 21:14:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 01:26:03.0866 (UTC) FILETIME=[57DF2BA0:01CA26B5] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 01:28:37 -0000 Andy Bierman writes: >So the server is always capable of returning all leafs that >it is using. All the complexity created for the client >due to 'server flexibility' is unwarranted. You are missing my point. When a user looks at configuration, they don't want to see the 50 or 100 knobs. They want to see the ones they care about. Interfaces in JUNOS have literally hundreds of knobs: % egrep 'attribute .* {' ddl/input/dcd.cnf.dd | wc -l 803 (attribute is the JUNOS equivalent of YANG's leaf; dcd is the daemon that handle interfaces; ".cnf.dd" are the configuration data model files) On a typical interface, less than 10 are set. Throwing hundreds of defaults for thousands of interfaces is simply not smart. It's not a server thing; I can certainly generate a couple of hundred thousand xml elements. But it's shipping this much data with values that are uninteresting to anyone is, well, not smart. Think about config archival; do I want to archive uninteresting default data? Think about user display; do I want to show the user a hundred knobs they've never heard of? Default values are not data; they are meta-data. Thanks, Phil From phil@juniper.net Wed Aug 26 18:29: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 4B7C03A6825 for ; Wed, 26 Aug 2009 18:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EsPuP+8MyfZr for ; Wed, 26 Aug 2009 18:29:39 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 688433A6949 for ; Wed, 26 Aug 2009 18:29:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSpXhh/xaODeFfDtZug5NYV0luVSmb0Ae@postini.com; Wed, 26 Aug 2009 18:29:46 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; Wed, 26 Aug 2009 18:27:04 -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, 26 Aug 2009 18:27:04 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:27:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 18:27:03 -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 n7R1R2d06409; Wed, 26 Aug 2009 18:27:02 -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 n7R1F4YG019273; Thu, 27 Aug 2009 01:15:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908270115.n7R1F4YG019273@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A95E086.3060606@netconfcentral.com> Date: Wed, 26 Aug 2009 21:15:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 01:27:03.0506 (UTC) FILETIME=[7B6B8320:01CA26B5] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 01:29:40 -0000 Andy Bierman writes: >Sure -- why use up 10 milli-seconds of the server's precious >resources when you can hire sysadmins that can >spend hours looking up the same information manually. It's in the YANG module. The application can look it up in less time than the server. Thanks, Phil From andy@netconfcentral.com Wed Aug 26 19:13:59 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 55E443A6B5E for ; Wed, 26 Aug 2009 19:13:59 -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 yb7QZOXS+zuj for ; Wed, 26 Aug 2009 19:13:58 -0700 (PDT) Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by core3.amsl.com (Postfix) with SMTP id 718013A682D for ; Wed, 26 Aug 2009 19:13:58 -0700 (PDT) Received: from [68.142.200.227] by n16.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 02:14:03 -0000 Received: from [68.142.201.68] by t8.bullet.mud.yahoo.com with NNFMP; 27 Aug 2009 02:14:03 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 02:14:03 -0000 X-Yahoo-Newman-Id: 350344.47559.bm@omp420.mail.mud.yahoo.com Received: (qmail 3683 invoked from network); 27 Aug 2009 02:14:02 -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; 27 Aug 2009 02:14:02 -0000 X-YMail-OSG: upqquaUVM1m2scbJgRNzlHvsfdUqDZ5zNp3F.MNOQ6b1onC1mK0j8HfTmmCTmrBwdcutZlZ3mlxV0TIP7shwqeeiLTaF2TrDFD0CNJSsAQiWHgzVDGUJZVAbstI_je_7J3ShLKkkWGRI0nGInSfLDU0uzrNBlCrcmmaMg0zUka7GXTAJgnR1OoAQGod83tMMnIFMlixjQDpuavM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A95EB78.7000009@netconfcentral.com> Date: Wed, 26 Aug 2009 19:12:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908270114.n7R1E43S019239@idle.juniper.net> In-Reply-To: <200908270114.n7R1E43S019239@idle.juniper.net> 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: Thu, 27 Aug 2009 02:13:59 -0000 Phil Shafer wrote: > Andy Bierman writes: >> So the server is always capable of returning all leafs that >> it is using. All the complexity created for the client >> due to 'server flexibility' is unwarranted. > > You are missing my point. When a user looks at configuration, they > don't want to see the 50 or 100 knobs. They want to see the ones > they care about. Interfaces in JUNOS have literally hundreds of > knobs: > no -- we went through this all before. It is up to the operator to decide what the operator wants, not the server. If I send an XPath select="/this/exact/leaf", then it's because I want that leaf. If with-defaults was mandatory-to-implement, then the operator would have the ability to force the server to return the data it wants, and let the server set its own default handling to 1 of 3 specific modes. The client would be able to determine the default handling in every . This would be much better than the current situation. But I don't know if that would be worth a new protocol version. IMO, there should be 1 'bundled' capability for all new 4741-bis features, and servers will advertise 4741bis plus 4741, but 4741bis capability would still be optional. > > Default values are not data; they are meta-data. disagree on that one too -- IMO, there is nothing that special about leaf that happens to conform to some particular definition of a default. There are just chucks of config that can be diffed edited, retrieved, etc. > > Thanks, > Phil > Andy From Washam.Fan@huaweisymantec.com Wed Aug 26 20:46: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 044843A69CD for ; Wed, 26 Aug 2009 20:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=0.264, 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 Cz24Hda+PIoY for ; Wed, 26 Aug 2009 20:46:51 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 075083A68A4 for ; Wed, 26 Aug 2009 20:46:51 -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 <0KP000L15NTEW500@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Thu, 27 Aug 2009 11:46:26 +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 <0KP000M5VNTEUA10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 27 Aug 2009 11:46:26 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 27 Aug 2009 11:46:26 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Thu, 27 Aug 2009 11:46:26 +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: <4A95AC30.5090405@netconfcentral.com> References: <006601ca25a8$e076dca0$0601a8c0@allison> <20090825.224216.118049693.mbj@tail-f.com> <00ca01ca2683$bb6af280$0601a8c0@allison> <20090826.233259.182862400.mbj@tail-f.com> <4A95AC30.5090405@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] meaning of config really 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: Thu, 27 Aug 2009 03:46:52 -0000 Hi, > But Joel is confused along with the rest of us: > > ..... > Maybe my addition will just add confusion, although I beleive I agree > with Andy and Juergen. (As a > caveat, I use "means" below to indicate what I think the YANG text > explicitly requires.) > > 1) Mandatory means that if a manager is writing that part of the > tree, the manager MUST provide a > value for that item. > > 2) Default means that if no manager has not set the item, the item > will have the explicit value > given in the default clause in the data model. > ..... > > Neither one of these assertions is correct. > Mandatory means the node MUST exist in a valid database, > and says nothing about client vs. server created. But my impression is the majority talks about mandatory things based on 1) above. > I'm not sure the WG has a real definition of a default. > I know there are a lot of circular references that end up > saying that a default is whatever the server decides it means. > My perception is, default leafs are not explicitly set, so they are not in config, but they have the same effect as they were presented in config. >From a server's view, data could be categorised into 1) the data that is explicitly set and the value doesn't equal to defaults if defaults is provided 2) the data that is explicitly set to the default values and defaults is provided 3) the data that is not explicitly set and defaults is provided, in this case, the value equals to defaults, but the data is not in config. >From a client's view, they can always retrieve 1), they can retrieve 2) if with-defaults=explict/report-all, they can retrieve 3) if with-defaults =report-all I can issue with-defaults=trim , then get data A I can issue with-defaults=explicit , then get data B I can issue with-defaults=report-all , then get data C Well, A is data within 1), B-A is data within 2), C-B is data within 3). washam From Washam.Fan@huaweisymantec.com Wed Aug 26 23:12: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 2C50E3A6AF1 for ; Wed, 26 Aug 2009 23:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[AWL=0.255, 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 Dt7-MZrY-5OQ for ; Wed, 26 Aug 2009 23:12:05 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 496243A6841 for ; Wed, 26 Aug 2009 23:12:05 -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 <0KP000LH4UJGW520@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Thu, 27 Aug 2009 14:11:41 +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 <0KP000MH5UJGUA10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Thu, 27 Aug 2009 14:11:40 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 27 Aug 2009 14:11:40 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 27 Aug 2009 14:11:40 +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: <20090826.213038.126204555.mbj@tail-f.com> References: <20090826.213038.126204555.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] default terminology 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: Thu, 27 Aug 2009 06:12:08 -0000 Hi, ----- Original Message ----- From: Martin Bjorklund Date: Thursday, August 27, 2009 3:31 am Subject: [netmod] default terminology To: netmod@ietf.org > Hi, > > I think some of the confusion in the recent discussions comes from > inconsistent terminolgy. > > When we say 'server assigned', or 'assigned-by system', it refers to > data that is present in the config, just like normal, client created > data ('assigned-by user' if you will). Since this data is part of the > data store, it is not hidden, it is not phantom nodes, and it is > reported in a normal get-config, regardless of the value of any > with-defaults parameters. > > Then we have 'default data'. I like to view this as the value that is > operationally used if the node is not present in the data store. YANG > supports one kind of default data only - static defaults, i.e. a > static value, guaranteed to be the same in all implementations, > specified in the data model. One can imagine dynamic default values, > and I think this is what Andy calls 'hidden' or 'phantom'. IMO, dynamic defaults should be treated as 'a-by system' or anything else and should be presented explicitly in the config. It makes little sense letting clients to deduce what the exact default is in different cases. washam From mbj@tail-f.com Thu Aug 27 00:49: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 695FA3A697E for ; Thu, 27 Aug 2009 00:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.239, 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 H-52ATTMUQ38 for ; Thu, 27 Aug 2009 00:48: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 877013A68D0 for ; Thu, 27 Aug 2009 00:48:59 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 5DA7176C5B6; Thu, 27 Aug 2009 09:41:00 +0200 (CEST) Date: Thu, 27 Aug 2009 09:40:59 +0200 (CEST) Message-Id: <20090827.094059.171210410.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A95EB78.7000009@netconfcentral.com> References: <200908270114.n7R1E43S019239@idle.juniper.net> <4A95EB78.7000009@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] 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: Thu, 27 Aug 2009 07:49:00 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> So the server is always capable of returning all leafs that > >> it is using. All the complexity created for the client > >> due to 'server flexibility' is unwarranted. > > > > You are missing my point. When a user looks at configuration, they > > don't want to see the 50 or 100 knobs. They want to see the ones > > they care about. Interfaces in JUNOS have literally hundreds of > > knobs: > > > > no -- we went through this all before. Indeed we did. And we realized that we will never be able to agree on one model for default handling. (The current discussion is evidence of that). So the NETCONF WG is chartered to work on how clients can learn how a server handles defaults. I don't think we should drop all this just b/c you now favor the 'report-all' mode. > It is up to the operator to decide > what the operator wants, not the server. > If I send an XPath select="/this/exact/leaf", > then it's because I want that leaf. And if the operator is used to the 'explicit' mode, he does not want to see stuff he did not set. This is no argument for either side. If anything it is an argument for :with-defaults which gives the operator the flexibility to choose. > If with-defaults was mandatory-to-implement, > then the operator would have the ability > to force the server to return the data it wants, > and let the server set its own default handling > to 1 of 3 specific modes. The client would be > able to determine the default handling in > every . This would be much better > than the current situation. > > But I don't know if that would be worth > a new protocol version. I still think we *could* make :with-defaults mandatory to implement if the server implements YANG models. But I really do not think it is necessary for interoperability. The YANG spec is clear that if a particular leaf is not present in a reply, and it has a default value, the default value is operationally used by the server. /martin From lhotka@cesnet.cz Thu Aug 27 00:55: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 64BDF3A695E for ; Thu, 27 Aug 2009 00:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=0.072, 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 K+0tFcMmPdre for ; Thu, 27 Aug 2009 00:55:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 968E53A67F3 for ; Thu, 27 Aug 2009 00:55:15 -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 BA0D7D80120 for ; Thu, 27 Aug 2009 09:55:21 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain Organization: CESNET Date: Thu, 27 Aug 2009 09:55:20 +0200 Message-Id: <1251359720.3665.75.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 07:55:16 -0000 Hi, Sec. 9.10.5 shows how local XML prefixes are used for representing values of "identityref" type. However, this won't work in XPath expressions because XPath doesn't know this type and there is no way for properly mapping the prefixes to URIs. For example, assume "my-crypto" model in 9.10.5 contains another top-level leaf leaf foo { when "../crypto = 'des:des3'"; .... } then the 'when' condition will be true for des:des3 but false for x:des3 even though the text says that both representations encode the same leaf. Possible solutions: 1. Use the module name for qualifying identity names, e.g. when "../crypto = 'des.des3'" and des.des3 (note that the module name and prefix are the same in the example) 2. Use full URI, e.g., when "../crypto = '{http://example.com/des}des3'" and {http://example.com/des}des3 3. Define an XPath extension function, e.g. when "yang:is-identity(../crypto, 'des:des3')"; Here, the XML instance representation could remain (with local prefixes). In my view, #1 would be the best compromise for YANG 1.0 provided that module names will be mostly unique. If YANG used other XPath extension functions, #3 would be probably the right solution. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 27 01:19: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 4B6723A6B91 for ; Thu, 27 Aug 2009 01:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.209, 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 kFuAd5VQq++z for ; Thu, 27 Aug 2009 01:19:47 -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 8A7E63A6A98 for ; Thu, 27 Aug 2009 01:19:47 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id B5F9676C5B6; Thu, 27 Aug 2009 10:19:53 +0200 (CEST) Date: Thu, 27 Aug 2009 10:19:54 +0200 (CEST) Message-Id: <20090827.101954.233768278.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251359720.3665.75.camel@missotis> References: <1251359720.3665.75.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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 08:19:48 -0000 Ladislav Lhotka wrote: > 3. Define an XPath extension function, e.g. > > when "yang:is-identity(../crypto, 'des:des3')"; > > Here, the XML instance representation could remain (with local > prefixes). > > In my view, #1 would be the best compromise for YANG 1.0 provided that > module names will be mostly unique. > > If YANG used other XPath extension functions, #3 would be probably the > right solution. Actually, YANG does define another extension function - current(). I sort of like the module.name syntax, but it is different from what we have in other places, so my preference would be #3 followed by #1. /martin From mbj@tail-f.com Thu Aug 27 01:23: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 090F03A6B0C for ; Thu, 27 Aug 2009 01:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, 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 rPkZKp0274oJ for ; Thu, 27 Aug 2009 01:23:56 -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 365E73A6A58 for ; Thu, 27 Aug 2009 01:23:56 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 8C97876C5B6; Thu, 27 Aug 2009 10:24:02 +0200 (CEST) Date: Thu, 27 Aug 2009 10:24:03 +0200 (CEST) Message-Id: <20090827.102403.52519173.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090826.233259.182862400.mbj@tail-f.com> <4A95AC30.5090405@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 config really 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: Thu, 27 Aug 2009 08:23:57 -0000 WashamFan wrote: > Hi, > > > But Joel is confused along with the rest of us: > > > > ..... > > Maybe my addition will just add confusion, although I beleive I agree > > with Andy and Juergen. (As a > > caveat, I use "means" below to indicate what I think the YANG text > > explicitly requires.) > > > > 1) Mandatory means that if a manager is writing that part of the > > tree, the manager MUST provide a > > value for that item. > > > > 2) Default means that if no manager has not set the item, the item > > will have the explicit value > > given in the default clause in the data model. > > ..... > > > > Neither one of these assertions is correct. > > Mandatory means the node MUST exist in a valid database, > > and says nothing about client vs. server created. > > But my impression is the majority talks about mandatory things based > on 1) above. I agree. This is what mandatory means. /martin From lhotka@cesnet.cz Thu Aug 27 01:48: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 0E3BF3A6D91 for ; Thu, 27 Aug 2009 01:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=0.071, 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 SQJCunm1zEbG for ; Thu, 27 Aug 2009 01:48:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3055D3A6DA9 for ; Thu, 27 Aug 2009 01:48: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 44311D800F3; Thu, 27 Aug 2009 10:48:29 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090827.101954.233768278.mbj@tail-f.com> References: <1251359720.3665.75.camel@missotis> <20090827.101954.233768278.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 10:48:28 +0200 Message-Id: <1251362908.3665.101.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 08:48:35 -0000 Martin Bjorklund píše v Čt 27. 08. 2009 v 10:19 +0200: > Ladislav Lhotka wrote: > > 3. Define an XPath extension function, e.g. > > > > when "yang:is-identity(../crypto, 'des:des3')"; > > > > Here, the XML instance representation could remain (with local > > prefixes). > > > > In my view, #1 would be the best compromise for YANG 1.0 provided that > > module names will be mostly unique. > > > > If YANG used other XPath extension functions, #3 would be probably the > > right solution. > > Actually, YANG does define another extension function - current(). I Well, current() isn't really new, it's an XSLT function and expressions that use it will in most cases work out of the box - e.g. in XSLT and Schematron. > sort of like the module.name syntax, but it is different from what we > have in other places, so my preference would be #3 followed by #1. I agree that #3 will be needed in the long term. For example, in the recent PSAMP example, must "yang:byte-length() = ../payloadBytes"; might come handy. The practical difficulty with this approach is that existing tools will not understand these functions unless the extensions are implemented in them. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Aug 27 02:04: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 C2E033A6A03 for ; Thu, 27 Aug 2009 02:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.070, 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 xzptOefU2AEp for ; Thu, 27 Aug 2009 02:04:30 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EF04E3A6841 for ; Thu, 27 Aug 2009 02:04:29 -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 93A77D80102; Thu, 27 Aug 2009 11:04:36 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A94F502.7070106@netconfcentral.com> References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> <20090826.084345.103935325.mbj@tail-f.com> <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 11:04:35 +0200 Message-Id: <1251363875.3665.108.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Thu, 27 Aug 2009 09:04:30 -0000 Andy Bierman píše v St 26. 08. 2009 v 01:40 -0700: > > I am concerned about consistent answers to the 11 questions > I posted yesterday. It seems to me how a particular leaf > got its value is a red herring and totally irrelevant. > All that matters is whether server-supplied values > count as an instance of a leaf (or leaf-list) or not. +1 > > It is irrelevant whether we call it config, operational node, > or something in between, if some servers behave as if there is no > leaf present at all, and others behave as if there is a leaf present. YANG actually requires that XPath expressions be evaluated as if the leaf is present. > > These 'phantom' leafs may count towards a max-elements error (or not). > They may cause a unique-error (or not). 11 different error conditions > that may or may not be reported -- all supposedly from compliant servers. > > IMO, the complete lack of any predictable server behavior for these 11 > conditions is a problem for interoperability. Yes, and also the long threads we are now enjoying in this mailing list prove that this ambiguity is really confusing. Lada > > > > /js > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 27 02:29: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 9336C3A69D8 for ; Thu, 27 Aug 2009 02:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, 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 PKdoI84-dlnA for ; Thu, 27 Aug 2009 02:29:46 -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 976DE3A6D69 for ; Thu, 27 Aug 2009 02:29:45 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 8E6A476C5B6; Thu, 27 Aug 2009 11:29:51 +0200 (CEST) Date: Thu, 27 Aug 2009 11:29:52 +0200 (CEST) Message-Id: <20090827.112952.115608025.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251363875.3665.108.camel@missotis> References: <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> <1251363875.3665.108.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] 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: Thu, 27 Aug 2009 09:29:47 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IFN0IDI2LiAwOC4gMjAwOSB2IDAxOjQwIC0wNzAwOg0KPiA+IA0KPiA+IEkgYW0g Y29uY2VybmVkIGFib3V0IGNvbnNpc3RlbnQgYW5zd2VycyB0byB0aGUgMTEgcXVlc3Rpb25zDQo+ ID4gSSBwb3N0ZWQgeWVzdGVyZGF5LiAgSXQgc2VlbXMgdG8gbWUgaG93IGEgcGFydGljdWxhciBs ZWFmDQo+ID4gZ290IGl0cyB2YWx1ZSBpcyBhIHJlZCBoZXJyaW5nIGFuZCB0b3RhbGx5IGlycmVs ZXZhbnQuDQo+ID4gQWxsIHRoYXQgbWF0dGVycyBpcyB3aGV0aGVyIHNlcnZlci1zdXBwbGllZCB2 YWx1ZXMNCj4gPiBjb3VudCBhcyBhbiBpbnN0YW5jZSBvZiBhIGxlYWYgKG9yIGxlYWYtbGlzdCkg b3Igbm90Lg0KPiANCj4gKzENCg0KWy4uLl0NCg0KPiA+IFRoZXNlICdwaGFudG9tJyBsZWFmcyBt YXkgY291bnQgdG93YXJkcyBhIG1heC1lbGVtZW50cyBlcnJvciAob3Igbm90KS4NCj4gPiBUaGV5 IG1heSBjYXVzZSBhIHVuaXF1ZS1lcnJvciAob3Igbm90KS4gIDExIGRpZmZlcmVudCBlcnJvciBj b25kaXRpb25zDQo+ID4gdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSByZXBvcnRlZCAtLSBhbGwgc3Vw cG9zZWRseSBmcm9tIGNvbXBsaWFudCBzZXJ2ZXJzLg0KPiA+IA0KPiA+IElNTywgdGhlIGNvbXBs ZXRlIGxhY2sgb2YgYW55IHByZWRpY3RhYmxlIHNlcnZlciBiZWhhdmlvciBmb3IgdGhlc2UgMTEN Cj4gPiBjb25kaXRpb25zIGlzIGEgcHJvYmxlbSBmb3IgaW50ZXJvcGVyYWJpbGl0eS4NCj4gDQo+ IFllcywgYW5kIGFsc28gdGhlIGxvbmcgdGhyZWFkcyB3ZSBhcmUgbm93IGVuam95aW5nIGluIHRo aXMgbWFpbGluZyBsaXN0DQo+IHByb3ZlIHRoYXQgdGhpcyBhbWJpZ3VpdHkgaXMgcmVhbGx5IGNv bmZ1c2luZy4NCg0KSSB3aWxsIGFuc3dlciB0aGlzIHdpdGggdGhlIHRlcm1pbm9sZ3kgSSBpbnRy b2R1Y2VkIGVhcmxpZXIsIGIvYyBJDQp0aGluayBtdWNoIG9mIHRoZSBjb25mdXNpb24gY29tZXMg ZnJvbSB1cyB1c2luZyB0aGUgc2FtZSB3b3JkcyBmb3INCmRpZmZlcmVudCB0aGluZ3MuDQoNCklm IHdlIHRhbGsgYWJvdXQgYXNzaWduZWQtYnktc3lzdGVtIHZhbHVlcywgdGhlcmUgaXMgbm8gYW1i aWd1aXR5Lg0KVGhleSBhcmUgcHJvcGVyIGluc3RhbmNlcywgc28gdGhlIGFuc3dlcnMgdG8gdGhl c2UgcXVlc3Rpb25zIGZhbGxzIG91dA0KbmF0dXJhbGx5LiAgU2VlIFBoaWwncyBlbWFpbC4gIFRo ZSBwcm9wb3NhbCB3ZSBoYWQgZm9yIGFuICJhc3NpZ25lZC1ieQ0Kc3lzdGVtL3VzZXIiIHN0YXRl bWVudCBmb3JtYWxpemVkIHRoZW0uDQoNCklmIHdlIHRhbGsgYWJvdXQgZHluYW1pYyBkZWZhdWx0 cywgSSBhZ3JlZSB0aGF0IGl0IGlzIHVuY2xlYXIgaG93IHRoZXkNCnNob3VsZCB3b3JrIGluIGdl bmVyYWwuICBCdXQgTk9URSAtLSB3ZSBkb24ndCBoYXZlIGFueSBkeW5hbWljDQpkZWZhdWx0cyBp biBZQU5HISAgSG93ZXZlciwgcGVvcGxlIGFyZSBmcmVlIHRvIGRlZmluZSBsZWFmcyBsaWtlDQoi c291cmNlSXBBZGRyZXNzIiBpbiB0aGUgaXBmaXggbW9kZWwuICBXaGF0IGlzIHRoZSBwcm9ibGVt IHdpdGggdGhpcz8NCg0KDQovbWFydGluDQo= From lhotka@cesnet.cz Thu Aug 27 02:33: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 840E528C29C for ; Thu, 27 Aug 2009 02:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.069, 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 XX2s-VKWGVcB for ; Thu, 27 Aug 2009 02:33:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 454853A6DA3 for ; Thu, 27 Aug 2009 02:32:38 -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 97584D80124; Thu, 27 Aug 2009 11:32:44 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090826.154529.143976153.mbj@tail-f.com> References: <20090826120726.GA20262@elstar.local> <20090826.144854.53929125.mbj@tail-f.com> <20090826125958.GA20572@elstar.local> <20090826.154529.143976153.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 11:32:43 +0200 Message-Id: <1251365563.3665.130.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Thu, 27 Aug 2009 09:33:34 -0000 Martin Bjorklund píše v St 26. 08. 2009 v 15:45 +0200: > Juergen Schoenwaelder wrote: > > On Wed, Aug 26, 2009 at 02:48:54PM +0200, Martin Bjorklund wrote: > > > > > Another way of looking at it is that when I write data models, I will > > > always use the former style b/c I like the explicit mode, but my > > > friend Balazs who likes report-all, will always use the latter style. > > > Our models might look exactly the same in all other regards, but this. > > > > This is the point. We either settle on one model and stick to it or we > > will have to accept diversity. I am in favour of at least trying to > > settle on one model. > > If you're talking about if default values are part of the config or > not -- we've been there before. I don't think we can force one model > onto devices. If we pick one way, all other devices will look at this > and say they can't implement it. This is not necessary. In an analogy to the MVC paradigm, YANG spec can define a single model, and implementations may work with different views of this model. One view can be identical to the model and such an implementation has no extra work. An implementor using a different view will have to (mentally) move back and forth between the view and the model but the mapping between them is not that difficult. I guess the situation is similar to two physicists, one of them using SI units and the other CGS. They can still talk together, read papers employing either system etc. They only need to exercise extra care. My preference is that the YANG model be of the report-all style because this is what XPath expressions assume, but I could live with another model, too, if it is precisely defined. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Aug 27 02:53: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 988AE28C263 for ; Thu, 27 Aug 2009 02:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=0.068, 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 YmEEeugjtwHl for ; Thu, 27 Aug 2009 02:53:42 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AA3E028C436 for ; Thu, 27 Aug 2009 02:53:10 -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 5A8F9D80096; Thu, 27 Aug 2009 11:53:17 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090827.112952.115608025.mbj@tail-f.com> References: <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> <1251363875.3665.108.camel@missotis> <20090827.112952.115608025.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 11:53:15 +0200 Message-Id: <1251366795.3665.145.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Thu, 27 Aug 2009 09:53:43 -0000 Martin Bjorklund píše v Čt 27. 08. 2009 v 11:29 +0200: > > I will answer this with the terminolgy I introduced earlier, b/c I > think much of the confusion comes from us using the same words for > different things. Yup, RFC 4741 talks about "initial default state", with-defaults draft has its defaults and YANG as well, but they are all different. > > If we talk about assigned-by-system values, there is no ambiguity. > They are proper instances, so the answers to these questions falls out > naturally. See Phil's email. The proposal we had for an "assigned-by > system/user" statement formalized them. Both Phil and Andy said at different moments - or at least I understood it so - that if there is a default specified for an assigned-by-system leaf, the system MUST assign this value. Independently of the fate of 'assigned-by', I would prefer if the 'default' statement was orthogonal and just postulated that certain configurations mean the same thing. Lada > > If we talk about dynamic defaults, I agree that it is unclear how they > should work in general. But NOTE -- we don't have any dynamic > defaults in YANG! However, people are free to define leafs like > "sourceIpAddress" in the ipfix model. What is the problem with this? > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 27 02:56: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 C3E853A6F95 for ; Thu, 27 Aug 2009 02:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.152, 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 c2QAwQwBeO0g for ; Thu, 27 Aug 2009 02:56:39 -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 01C2E3A6DB8 for ; Thu, 27 Aug 2009 02:56:38 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 5C56476C5B6; Thu, 27 Aug 2009 11:56:45 +0200 (CEST) Date: Thu, 27 Aug 2009 11:56:45 +0200 (CEST) Message-Id: <20090827.115645.81529576.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251366795.3665.145.camel@missotis> References: <1251363875.3665.108.camel@missotis> <20090827.112952.115608025.mbj@tail-f.com> <1251366795.3665.145.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=us-ascii 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: Thu, 27 Aug 2009 09:56:42 -0000 Ladislav Lhotka wrote: > > If we talk about assigned-by-system values, there is no ambiguity. > > They are proper instances, so the answers to these questions falls out > > naturally. See Phil's email. The proposal we had for an "assigned-by > > system/user" statement formalized them. > > Both Phil and Andy said at different moments - or at least I understood > it so - that if there is a default specified for an assigned-by-system > leaf, the system MUST assign this value. I'm not sure they did, but I disagree with this. > Independently of the fate of > 'assigned-by', I would prefer if the 'default' statement was orthogonal > and just postulated that certain configurations mean the same thing. I agree. /martin From lhotka@cesnet.cz Thu Aug 27 03:53: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 E816D28C4D5 for ; Thu, 27 Aug 2009 03:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=0.067, 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 IA1nn5AkYPYP for ; Thu, 27 Aug 2009 03:53:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 908E828C4DD for ; Thu, 27 Aug 2009 03:52:58 -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 15B10D800C1; Thu, 27 Aug 2009 12:53:05 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090827.115645.81529576.mbj@tail-f.com> References: <1251363875.3665.108.camel@missotis> <20090827.112952.115608025.mbj@tail-f.com> <1251366795.3665.145.camel@missotis> <20090827.115645.81529576.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 12:53:03 +0200 Message-Id: <1251370383.3665.160.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Thu, 27 Aug 2009 10:53:34 -0000 Martin Bjorklund píše v Čt 27. 08. 2009 v 11:56 +0200: > Ladislav Lhotka wrote: > > > If we talk about assigned-by-system values, there is no ambiguity. > > > They are proper instances, so the answers to these questions falls out > > > naturally. See Phil's email. The proposal we had for an "assigned-by > > > system/user" statement formalized them. > > > > Both Phil and Andy said at different moments - or at least I understood > > it so - that if there is a default specified for an assigned-by-system > > leaf, the system MUST assign this value. > > I'm not sure they did, but I disagree with this. > http://www.ietf.org/mail-archive/web/netmod/current/msg03410.html http://www.ietf.org/mail-archive/web/netmod/current/msg03579.html Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Thu Aug 27 05:39: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 0979C3A6DE6 for ; Thu, 27 Aug 2009 05:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 f9PFsRSi60EH for ; Thu, 27 Aug 2009 05:39:38 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 0C6F43A6DED for ; Thu, 27 Aug 2009 05:39:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSpZ+ikPSsvNW+/JtiQIDF9qBI8mfSSmo@postini.com; Thu, 27 Aug 2009 05:39:45 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; Thu, 27 Aug 2009 05:35:45 -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); Thu, 27 Aug 2009 05:35:45 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 05:35:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 05:35:44 -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 n7RCZid32666; Thu, 27 Aug 2009 05:35:44 -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 n7RCNiZ3022959; Thu, 27 Aug 2009 12:23:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271223.n7RCNiZ3022959@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251370383.3665.160.camel@missotis> Date: Thu, 27 Aug 2009 08:23:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 12:35:44.0250 (UTC) FILETIME=[E53F35A0:01CA2712] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 12:39:39 -0000 Ladislav Lhotka writes: >Martin Bjorklund píše v Čt 27. 08. 2009 v 11:56 +0200: >> Ladislav Lhotka wrote: >> > > If we talk about assigned-by-system values, there is no ambiguity. >> > > They are proper instances, so the answers to these questions falls out >> > > naturally. See Phil's email. The proposal we had for an "assigned-by >> > > system/user" statement formalized them. >> > >> > Both Phil and Andy said at different moments - or at least I understood >> > it so - that if there is a default specified for an assigned-by-system >> > leaf, the system MUST assign this value. >> >> I'm not sure they did, but I disagree with this. >> > >http://www.ietf.org/mail-archive/web/netmod/current/msg03410.html Depending on if the 'default' statement appears inside the model. If the model has a default statement and the configuration was made using this model, then the device should honor that model's default value. This is very different than the meaning you've given my words above. My meaning was this: if I make configuration for an interface using the ACME Interface Model and that model has an "mtu" leaf with a default of 1024, an interface made using that model should use that model's default value instead of my normal system model default of, say, 1500. Since you used the ACME model, I need to honor the default value that is defined inside that model, since your application can reasonably expect that behaviour. This is completely orthogonal to the "assigned-by system" issue. Thanks, Phil From phil@juniper.net Thu Aug 27 05:41: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 684993A6E11 for ; Thu, 27 Aug 2009 05:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 pRdS-4wK9SNA for ; Thu, 27 Aug 2009 05:41:54 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 5B4F33A6DF3 for ; Thu, 27 Aug 2009 05:41:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSpZ/FDzm3psFsRV65hOONJnb/o2k9Sc1@postini.com; Thu, 27 Aug 2009 05:42: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; Thu, 27 Aug 2009 05:38:32 -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); Thu, 27 Aug 2009 05:38:32 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 05:38:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 05:38:30 -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 n7RCcUd33756; Thu, 27 Aug 2009 05:38:30 -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 n7RCQVjm023045; Thu, 27 Aug 2009 12:26:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271226.n7RCQVjm023045@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090827.112952.115608025.mbj@tail-f.com> Date: Thu, 27 Aug 2009 08:26:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 12:38:30.0620 (UTC) FILETIME=[486941C0:01CA2713] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 12:41:55 -0000 Martin Bjorklund writes: >If we talk about dynamic defaults, I agree that it is unclear how they >should work in general. But NOTE -- we don't have any dynamic >defaults in YANG! However, people are free to define leafs like >"sourceIpAddress" in the ipfix model. What is the problem with this? In particular, dynamic defaults are not configuration data, so no mechanism that fetches configuration data should ever return them. They should be completely outside this discussion. Thanks, Phil From phil@juniper.net Thu Aug 27 05:48: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 9017628C537 for ; Thu, 27 Aug 2009 05:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 4gXp3YmDo+9C for ; Thu, 27 Aug 2009 05:48:52 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 49DCC28C536 for ; Thu, 27 Aug 2009 05:47:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSpaAerlmO9nwIe1LWZfqFMDLKXlSA9Q7@postini.com; Thu, 27 Aug 2009 05:47: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; Thu, 27 Aug 2009 05:42:28 -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); Thu, 27 Aug 2009 05:42:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 05:42:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 05:42:26 -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 n7RCgQd35925; Thu, 27 Aug 2009 05:42:26 -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 n7RCUR7o023091; Thu, 27 Aug 2009 12:30:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271230.n7RCUR7o023091@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251359720.3665.75.camel@missotis> Date: Thu, 27 Aug 2009 08:30:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 12:42:26.0706 (UTC) FILETIME=[D5211F20:01CA2713] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 12:48:53 -0000 Any of these three would be fine, but I thought identifyref was somehow imbued with the intelligence to handle prefixes in such a way that the value "des:des3" is more than just a string, so changing the prefix would be handled correctly. #2 is probably the most exact proposal, and #3 is the least, but all three are close enough that none has a serious advantage. Thanks, Phil Ladislav Lhotka writes: >Hi, > >Sec. 9.10.5 shows how local XML prefixes are used for representing >values of "identityref" type. However, this won't work in XPath >expressions because XPath doesn't know this type and there is no way for >properly mapping the prefixes to URIs. > >For example, assume "my-crypto" model in 9.10.5 contains another >top-level leaf > > leaf foo { > when "../crypto = 'des:des3'"; > .... > } > >then the 'when' condition will be true for > > des:des3 > >but false for > > x:des3 > >even though the text says that both representations encode the same >leaf. > >Possible solutions: > >1. Use the module name for qualifying identity names, e.g. > > when "../crypto = 'des.des3'" > > and > > des.des3 > > (note that the module name and prefix are the same in the example) > >2. Use full URI, e.g., > > when "../crypto = '{http://example.com/des}des3'" > > and > > {http://example.com/des}des3 > >3. Define an XPath extension function, e.g. > > when "yang:is-identity(../crypto, 'des:des3')"; > > Here, the XML instance representation could remain (with local > prefixes). > >In my view, #1 would be the best compromise for YANG 1.0 provided that >module names will be mostly unique. > >If YANG used other XPath extension functions, #3 would be probably the >right solution. > >Lada > >-- >Ladislav Lhotka, CESNET >PGP Key ID: E74E8C0C > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Thu Aug 27 06:08: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 66BA33A690E for ; Thu, 27 Aug 2009 06:08:54 -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 qlZU2nfT0fzQ for ; Thu, 27 Aug 2009 06:08:53 -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 9497C28C1CD for ; Thu, 27 Aug 2009 06:08:10 -0700 (PDT) Received: (qmail 94900 invoked from network); 27 Aug 2009 13:08:15 -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; 27 Aug 2009 13:08:15 -0000 X-YMail-OSG: 1ekHC9QVM1kfRQvlbTp8slvIYiOp8fRDNvIlOGsOg92lqNofUVI93LP_W8QodQt6AQtGoInJLEFbdeU7S.WlmXSsuvpdGStIRdUKDoUrHxD3upW2QR3LCdwjhPo0USFeVq3IOMTngyCrTIQjuyVbJLC_3AEj4sQ2r9F1pRpmSR9myGX0K_odc5XL4zmbWXGnO75TaqaSsw2os0sNDZhjeo92QQ6ft3gAwy8yIcCEfjhe7kHukCB9A1z8b8Q00NFLu4VC95H5Nbv4MjdAAxmlYN4djLo_NT0C0GFYKUMihWUjAci2hxVqGWKf_SZeETJzkZu6fRosxbDsEA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A968546.2070907@netconfcentral.com> Date: Thu, 27 Aug 2009 06:08:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200908270114.n7R1E43S019239@idle.juniper.net> <4A95EB78.7000009@netconfcentral.com> <20090827.094059.171210410.mbj@tail-f.com> In-Reply-To: <20090827.094059.171210410.mbj@tail-f.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: Thu, 27 Aug 2009 13:08:54 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> So the server is always capable of returning all leafs that >>>> it is using. All the complexity created for the client >>>> due to 'server flexibility' is unwarranted. >>> You are missing my point. When a user looks at configuration, they >>> don't want to see the 50 or 100 knobs. They want to see the ones >>> they care about. Interfaces in JUNOS have literally hundreds of >>> knobs: >>> >> no -- we went through this all before. > > Indeed we did. And we realized that we will never be able to agree on > one model for default handling. (The current discussion is evidence > of that). So the NETCONF WG is chartered to work on how clients can > learn how a server handles defaults. I don't think we should drop all > this just b/c you now favor the 'report-all' mode. > fine -- I invite application developers to write code to read description clauses, because 1 or 2 server vendors refuse to let them use the and code they already have. The market will decide on this one -- rather easily in fact. IMO, NETCONF is unusable in this 'offline lookup mode', but if others think it's a good use of their time to support this sort of device, then good luck with that. >> It is up to the operator to decide >> what the operator wants, not the server. >> If I send an XPath select="/this/exact/leaf", >> then it's because I want that leaf. > > And if the operator is used to the 'explicit' mode, he does not want > to see stuff he did not set. This is no argument for either side. If > anything it is an argument for :with-defaults which gives the operator > the flexibility to choose. > You do understand that there is just one bit devotes to 'set-explicit', right? You don't get to see just "your changes". You see whatever explicit operations all operators have made since the device was purchased. We used to let the NMS handle this sort of nonsense -- but there are still some SNMP agents that reset their counters in the device, instead of the NMS, because "the" operator wants the counters reset. >> If with-defaults was mandatory-to-implement, >> then the operator would have the ability >> to force the server to return the data it wants, >> and let the server set its own default handling >> to 1 of 3 specific modes. The client would be >> able to determine the default handling in >> every . This would be much better >> than the current situation. >> >> But I don't know if that would be worth >> a new protocol version. > > I still think we *could* make :with-defaults mandatory to implement if > the server implements YANG models. But I really do not think it is > necessary for interoperability. The YANG spec is clear that if a > particular leaf is not present in a reply, and it has a default value, > the default value is operationally used by the server. > I think prospects for interoperability in NETCONF/YANG are extremely low. Your client cannot even tell what the server isn't letting it retrieve without with-defaults. > > /martin > Andy From lhotka@cesnet.cz Thu Aug 27 06:10: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 6089628C548 for ; Thu, 27 Aug 2009 06:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=0.066, 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 MjqFd9lafpE8 for ; Thu, 27 Aug 2009 06:10:50 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B5D733A6808 for ; Thu, 27 Aug 2009 06:10:49 -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 3212BD800C0; Thu, 27 Aug 2009 15:10:56 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908271223.n7RCNiZ3022959@idle.juniper.net> References: <200908271223.n7RCNiZ3022959@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 15:10:54 +0200 Message-Id: <1251378654.3665.240.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit 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: Thu, 27 Aug 2009 13:10:53 -0000 Phil Shafer píše v Čt 27. 08. 2009 v 08:23 -0400: > Ladislav Lhotka writes: > >Martin Bjorklund píše v Čt 27. 08. 2009 v 11:56 +0200: > >> Ladislav Lhotka wrote: > >> > > If we talk about assigned-by-system values, there is no ambiguity. > >> > > They are proper instances, so the answers to these questions falls out > >> > > naturally. See Phil's email. The proposal we had for an "assigned-by > >> > > system/user" statement formalized them. > >> > > >> > Both Phil and Andy said at different moments - or at least I understood > >> > it so - that if there is a default specified for an assigned-by-system > >> > leaf, the system MUST assign this value. > >> > >> I'm not sure they did, but I disagree with this. > >> > > > >http://www.ietf.org/mail-archive/web/netmod/current/msg03410.html > > Depending on if the 'default' statement appears inside the model. > If the model has a default statement and the configuration was > made using this model, then the device should honor that model's > default value. > > This is very different than the meaning you've given my words above. > My meaning was this: if I make configuration for an interface using > the ACME Interface Model and that model has an "mtu" leaf with a > default of 1024, an interface made using that model should use that > model's default value instead of my normal system model default of, > say, 1500. Since you used the ACME model, I need to honor the > default value that is defined inside that model, since your application > can reasonably expect that behaviour. Hmm, so let me also paste in Juergens text that you replied to: >... If you plug a PCMCIA network card in your notebook, you will see >a suitable MTU - you did not configure it nor is it going to be the >same for all possible network cards. Depending on if the 'default' statement appears inside the model. If the model has a default statement and the configuration was made using this model, then the device should honor that model's default value. My reading is that if the "mtu" leaf had assigned-by system; default 1500; "should honor" means that I could rely on MTU being configured to 1500 (and get-config and report-all should report the same value). If this is what you meant, I don't agree. Lada > > This is completely orthogonal to the "assigned-by system" issue. > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Aug 27 06:11:17 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 F13D228C566 for ; Thu, 27 Aug 2009 06:11:17 -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 D7hjIoXVSwxA for ; Thu, 27 Aug 2009 06:11:17 -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 DE28F28C54A for ; Thu, 27 Aug 2009 06:11:16 -0700 (PDT) Received: (qmail 38315 invoked from network); 27 Aug 2009 13:11:21 -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; 27 Aug 2009 13:11:21 -0000 X-YMail-OSG: WaeDMkcVM1mmlIitDZXNYfwi9IeEYAb8ZslA7259cZrEh0ifau80ge2jBIo0PFt4L9n2Yq60LB6g_v63tMvy9qAXZapqgQlyImjfWqXqsaGmSZuB656meki9dqk2s3RMdK6fTTLqNydTgfKmql8dZqwcf5VQHAb7xze9rY7gDNlPzc08iWeoi6r27e_GmX.pKPOICbN.CpvO09kla4gbLRxNKdYBzSt7WXz0TXTiQ8I67FE1Y1WhHAaB5AJhtgAN7jSvFcNOA19AG0O5naswMVT5MNvgWfhBYiLkucHs2JHFnB1bUtAH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A968600.7080306@netconfcentral.com> Date: Thu, 27 Aug 2009 06:11:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1251359720.3665.75.camel@missotis> In-Reply-To: <1251359720.3665.75.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 13:11:18 -0000 Ladislav Lhotka wrote: > Hi, > > Sec. 9.10.5 shows how local XML prefixes are used for representing > values of "identityref" type. However, this won't work in XPath > expressions because XPath doesn't know this type and there is no way for > properly mapping the prefixes to URIs. > I see no reason to change this at all. I found it easy to code -- no problems at all. We cannot use des.des2 because we already decided not to reserve any legal identifier characters for delimiters. (IMO, rather shortsighted, again). (des.des2 is a legal YANG identifier.) Andy > For example, assume "my-crypto" model in 9.10.5 contains another > top-level leaf > > leaf foo { > when "../crypto = 'des:des3'"; > .... > } > > then the 'when' condition will be true for > > des:des3 > > but false for > > x:des3 > > even though the text says that both representations encode the same > leaf. > > Possible solutions: > > 1. Use the module name for qualifying identity names, e.g. > > when "../crypto = 'des.des3'" > > and > > des.des3 > > (note that the module name and prefix are the same in the example) > > 2. Use full URI, e.g., > > when "../crypto = '{http://example.com/des}des3'" > > and > > {http://example.com/des}des3 > > 3. Define an XPath extension function, e.g. > > when "yang:is-identity(../crypto, 'des:des3')"; > > Here, the XML instance representation could remain (with local > prefixes). > > In my view, #1 would be the best compromise for YANG 1.0 provided that > module names will be mostly unique. > > If YANG used other XPath extension functions, #3 would be probably the > right solution. > > Lada > From lhotka@cesnet.cz Thu Aug 27 06:26: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 67A9028C56A for ; Thu, 27 Aug 2009 06:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=0.065, 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 jrW54qjUBUGs for ; Thu, 27 Aug 2009 06:26:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 54A1C28C579 for ; Thu, 27 Aug 2009 06:26:52 -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 D4B6FD80096; Thu, 27 Aug 2009 15:26:58 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A968600.7080306@netconfcentral.com> References: <1251359720.3665.75.camel@missotis> <4A968600.7080306@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 15:26:57 +0200 Message-Id: <1251379617.3665.254.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 13:26:53 -0000 Andy Bierman píše v Čt 27. 08. 2009 v 06:11 -0700: > Ladislav Lhotka wrote: > > Hi, > > > > Sec. 9.10.5 shows how local XML prefixes are used for representing > > values of "identityref" type. However, this won't work in XPath > > expressions because XPath doesn't know this type and there is no way for > > properly mapping the prefixes to URIs. > > > > I see no reason to change this at all. > I found it easy to code -- no problems at all. For XPath 'des:des3' is just a plain string literal and '=' performs a string equality test. Of course, if you as a developer look at the condition, realize what it means and then implement it in your code, it's easy, but not how XPath is supposed to work. > > We cannot use des.des2 because we already decided > not to reserve any legal identifier characters > for delimiters. (IMO, rather shortsighted, again). > (des.des2 is a legal YANG identifier.) Right, dot mustn't be allowed in identifiers in this case. Lada > > > Andy > > > > For example, assume "my-crypto" model in 9.10.5 contains another > > top-level leaf > > > > leaf foo { > > when "../crypto = 'des:des3'"; > > .... > > } > > > > then the 'when' condition will be true for > > > > des:des3 > > > > but false for > > > > x:des3 > > > > even though the text says that both representations encode the same > > leaf. > > > > Possible solutions: > > > > 1. Use the module name for qualifying identity names, e.g. > > > > when "../crypto = 'des.des3'" > > > > and > > > > des.des3 > > > > (note that the module name and prefix are the same in the example) > > > > 2. Use full URI, e.g., > > > > when "../crypto = '{http://example.com/des}des3'" > > > > and > > > > {http://example.com/des}des3 > > > > 3. Define an XPath extension function, e.g. > > > > when "yang:is-identity(../crypto, 'des:des3')"; > > > > Here, the XML instance representation could remain (with local > > prefixes). > > > > In my view, #1 would be the best compromise for YANG 1.0 provided that > > module names will be mostly unique. > > > > If YANG used other XPath extension functions, #3 would be probably the > > right solution. > > > > Lada > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Aug 27 06:32:22 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 3AF8828C548 for ; Thu, 27 Aug 2009 06:32:22 -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 byKzgNwBdCEj for ; Thu, 27 Aug 2009 06:32:21 -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 886B928C573 for ; Thu, 27 Aug 2009 06:32:21 -0700 (PDT) Received: (qmail 80398 invoked from network); 27 Aug 2009 13:32:25 -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; 27 Aug 2009 13:32:25 -0000 X-YMail-OSG: RzTsBWAVM1kMhBD2Xee1KaaZ9qWCLVGOtEn7mfqBYMMhRHqw5X1xV4Otp32FqHxcx1avmAOY9hoaQg_KkkFHdaVJvT8oarpnkCB7WMX0Fu2x5.aunWUWGGoAaDvzUab8wOVAQJY.6ewBdVzcYJCeaGFtZjY3Ykahkl1KT1um5rEQE2lgKO7mS95C9xn06dUx79S6mWA602LKrmg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A968A74.3040601@netconfcentral.com> Date: Thu, 27 Aug 2009 06:30:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <200908250157.n7P1vrEY097629@idle.juniper.net> <4A935191.4090504@netconfcentral.com> <20090826063638.GA19116@elstar.local> <20090826.084345.103935325.mbj@tail-f.com> <20090826073146.GA19221@elstar.local> <4A94F502.7070106@netconfcentral.com> <1251363875.3665.108.camel@missotis> In-Reply-To: <1251363875.3665.108.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Thu, 27 Aug 2009 13:32:22 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 26. 08. 2009 v 01:40 -0700: >> I am concerned about consistent answers to the 11 questions >> I posted yesterday. It seems to me how a particular leaf >> got its value is a red herring and totally irrelevant. >> All that matters is whether server-supplied values >> count as an instance of a leaf (or leaf-list) or not. > > +1 > >> It is irrelevant whether we call it config, operational node, >> or something in between, if some servers behave as if there is no >> leaf present at all, and others behave as if there is a leaf present. > > YANG actually requires that XPath expressions be evaluated as if the > leaf is present. > I find the YANG concepts to be more confusing because the rules are not specified as if there exists a static database representation (as XPath expects). The NETCONF protocol is also more complicated because there is not a 'whole' database available on all devices. I find the problem premises to be absurd, and contrary to everything we learned over 20 years of monitoring with SNMP: 1) the server should decide what the client wants to retrieve 2) retrieving data that can be deduced from studying documentation is a waste of bandwidth I do not accept these assertions at all, even if the WG does. The with-defaults capability is a hack, piled on top of more hacks, to fix a kludged architecture. >> These 'phantom' leafs may count towards a max-elements error (or not). >> They may cause a unique-error (or not). 11 different error conditions >> that may or may not be reported -- all supposedly from compliant servers. >> >> IMO, the complete lack of any predictable server behavior for these 11 >> conditions is a problem for interoperability. > > Yes, and also the long threads we are now enjoying in this mailing list > prove that this ambiguity is really confusing. > > Lada > > Andy From andy@netconfcentral.com Thu Aug 27 07:01:20 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 F24D13A6E1D for ; Thu, 27 Aug 2009 07:01:20 -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 G63xFt-GAIE1 for ; Thu, 27 Aug 2009 07:01:20 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 298083A684A for ; Thu, 27 Aug 2009 07:01:20 -0700 (PDT) Received: (qmail 19239 invoked from network); 27 Aug 2009 14:01:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2009 14:01:24 -0000 X-YMail-OSG: Hu.x.BQVM1m0gPrKfz7.feVhL04qmn1N.VORRzMZ9_atXs4DQQYtU_G40q_INcZO3I_yJ2nSnhmu3o3Ett.VdPXTscEd._7S_sql5rOpSQlgVy.RsE3FjzoDmxLDlKdWkLPjrjvRR7c78dhg4rDuooeiqgCB9p5a9ztI68JoCtwMp3qJQH23nneyF3MsyEyFvjZtJOgcRZViPzdy1JcDRZR._We9b7wDvzLicZlsrZUWkIGltJXc53c7DfAcTAuq7VMa6s.idpNpTLLj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9691BB.7090502@netconfcentral.com> Date: Thu, 27 Aug 2009 07:01:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1251359720.3665.75.camel@missotis> <4A968600.7080306@netconfcentral.com> <1251379617.3665.254.camel@missotis> In-Reply-To: <1251379617.3665.254.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 14:01:21 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Čt 27. 08. 2009 v 06:11 -0700: >> Ladislav Lhotka wrote: >>> Hi, >>> >>> Sec. 9.10.5 shows how local XML prefixes are used for representing >>> values of "identityref" type. However, this won't work in XPath >>> expressions because XPath doesn't know this type and there is no way for >>> properly mapping the prefixes to URIs. >>> >> I see no reason to change this at all. >> I found it easy to code -- no problems at all. > > For XPath 'des:des3' is just a plain string literal and '=' performs a > string equality test. Of course, if you as a developer look at the > condition, realize what it means and then implement it in your code, > it's easy, but not how XPath is supposed to work. But I have to do that at least 10 times to implement XPath for YANG, so what's one more? You have to compare the value space, not the lexical space, or YANG doesn't actually work. You have to hunt down des:des3 or even just des3, because you know the base of the identityref from the YANG tpe. > >> We cannot use des.des2 because we already decided >> not to reserve any legal identifier characters >> for delimiters. (IMO, rather shortsighted, again). >> (des.des2 is a legal YANG identifier.) > > Right, dot mustn't be allowed in identifiers in this case. > > Lada > Andy From lhotka@cesnet.cz Thu Aug 27 07:16: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 B3FEE3A6E43 for ; Thu, 27 Aug 2009 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.064, 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 lk3hxnMS6V0O for ; Thu, 27 Aug 2009 07:16:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D5FE828C5DE for ; Thu, 27 Aug 2009 07:13:42 -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 5DB6BD80095; Thu, 27 Aug 2009 16:13:47 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A9691BB.7090502@netconfcentral.com> References: <1251359720.3665.75.camel@missotis> <4A968600.7080306@netconfcentral.com> <1251379617.3665.254.camel@missotis> <4A9691BB.7090502@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 16:13:45 +0200 Message-Id: <1251382425.3665.275.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 14:16:28 -0000 Andy Bierman píše v Čt 27. 08. 2009 v 07:01 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Čt 27. 08. 2009 v 06:11 -0700: > >> Ladislav Lhotka wrote: > >>> Hi, > >>> > >>> Sec. 9.10.5 shows how local XML prefixes are used for representing > >>> values of "identityref" type. However, this won't work in XPath > >>> expressions because XPath doesn't know this type and there is no way for > >>> properly mapping the prefixes to URIs. > >>> > >> I see no reason to change this at all. > >> I found it easy to code -- no problems at all. > > > > For XPath 'des:des3' is just a plain string literal and '=' performs a > > string equality test. Of course, if you as a developer look at the > > condition, realize what it means and then implement it in your code, > > it's easy, but not how XPath is supposed to work. > > But I have to do that at least 10 times to implement XPath > for YANG, so what's one more? > > You have to compare the value space, not the lexical space, > or YANG doesn't actually work. You have to hunt down des:des3 > or even just des3, because you know the base of the identityref > from the YANG tpe. Then it's YPath, not XPath. As long as YANG spec refers to XPath 1.0, it must follow its semantics. Extension functions is a mechanism that is supported by the (few) existing XPath processors I worked with, and made official in XPath 2.0. Lada Lada > > > > > >> We cannot use des.des2 because we already decided > >> not to reserve any legal identifier characters > >> for delimiters. (IMO, rather shortsighted, again). > >> (des.des2 is a legal YANG identifier.) > > > > Right, dot mustn't be allowed in identifiers in this case. > > > > Lada > > > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 27 07:20:22 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 7CD703A6C05 for ; Thu, 27 Aug 2009 07:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.101, 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 nIQKaUdkmNQz for ; Thu, 27 Aug 2009 07:20: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 7994C3A6C01 for ; Thu, 27 Aug 2009 07:20:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BB72276C5E0; Thu, 27 Aug 2009 16:20:26 +0200 (CEST) Date: Thu, 27 Aug 2009 16:20:26 +0200 (CEST) Message-Id: <20090827.162026.223580452.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251382425.3665.275.camel@missotis> References: <1251379617.3665.254.camel@missotis> <4A9691BB.7090502@netconfcentral.com> <1251382425.3665.275.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] identityref and XPath 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: Thu, 27 Aug 2009 14:20:22 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IMSMdCAyNy4gMDguIDIwMDkgdiAwNzowMSAtMDcwMDoNCj4gPiBMYWRpc2xhdiBM aG90a2Egd3JvdGU6DQo+ID4gPiBBbmR5IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDI3LiAwOC4gMjAw OSB2IDA2OjExIC0wNzAwOg0KPiA+ID4+IExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4gPiA+Pj4g SGksDQo+ID4gPj4+DQo+ID4gPj4+IFNlYy4gOS4xMC41IHNob3dzIGhvdyBsb2NhbCBYTUwgcHJl Zml4ZXMgYXJlIHVzZWQgZm9yIHJlcHJlc2VudGluZw0KPiA+ID4+PiB2YWx1ZXMgb2YgImlkZW50 aXR5cmVmIiB0eXBlLiBIb3dldmVyLCB0aGlzIHdvbid0IHdvcmsgaW4gWFBhdGgNCj4gPiA+Pj4g ZXhwcmVzc2lvbnMgYmVjYXVzZSBYUGF0aCBkb2Vzbid0IGtub3cgdGhpcyB0eXBlIGFuZCB0aGVy ZSBpcyBubyB3YXkgZm9yDQo+ID4gPj4+IHByb3Blcmx5IG1hcHBpbmcgdGhlIHByZWZpeGVzIHRv IFVSSXMuDQo+ID4gPj4+DQo+ID4gPj4gSSBzZWUgbm8gcmVhc29uIHRvIGNoYW5nZSB0aGlzIGF0 IGFsbC4NCj4gPiA+PiBJIGZvdW5kIGl0IGVhc3kgdG8gY29kZSAtLSBubyBwcm9ibGVtcyBhdCBh bGwuDQo+ID4gPiANCj4gPiA+IEZvciBYUGF0aCAnZGVzOmRlczMnIGlzIGp1c3QgYSBwbGFpbiBz dHJpbmcgbGl0ZXJhbCBhbmQgJz0nIHBlcmZvcm1zIGENCj4gPiA+IHN0cmluZyBlcXVhbGl0eSB0 ZXN0LiBPZiBjb3Vyc2UsIGlmIHlvdSBhcyBhIGRldmVsb3BlciBsb29rIGF0IHRoZQ0KPiA+ID4g Y29uZGl0aW9uLCByZWFsaXplIHdoYXQgaXQgbWVhbnMgYW5kIHRoZW4gaW1wbGVtZW50IGl0IGlu IHlvdXIgY29kZSwNCj4gPiA+IGl0J3MgZWFzeSwgYnV0IG5vdCBob3cgWFBhdGggaXMgc3VwcG9z ZWQgdG8gd29yay4NCj4gPiANCj4gPiBCdXQgSSBoYXZlIHRvIGRvIHRoYXQgYXQgbGVhc3QgMTAg dGltZXMgdG8gaW1wbGVtZW50IFhQYXRoDQo+ID4gZm9yIFlBTkcsIHNvIHdoYXQncyBvbmUgbW9y ZT8NCj4gPiANCj4gPiBZb3UgaGF2ZSB0byBjb21wYXJlIHRoZSB2YWx1ZSBzcGFjZSwgbm90IHRo ZSBsZXhpY2FsIHNwYWNlLA0KPiA+IG9yIFlBTkcgZG9lc24ndCBhY3R1YWxseSB3b3JrLiBZb3Ug aGF2ZSB0byBodW50IGRvd24gZGVzOmRlczMNCj4gPiBvciBldmVuIGp1c3QgZGVzMywgYmVjYXVz ZSB5b3Uga25vdyB0aGUgYmFzZSBvZiB0aGUgaWRlbnRpdHlyZWYNCj4gPiBmcm9tIHRoZSBZQU5H IHRwZS4NCj4gDQo+IFRoZW4gaXQncyBZUGF0aCwgbm90IFhQYXRoLiBBcyBsb25nIGFzIFlBTkcg c3BlYyByZWZlcnMgdG8gWFBhdGggMS4wLCBpdA0KPiBtdXN0IGZvbGxvdyBpdHMgc2VtYW50aWNz Lg0KDQorMQ0KDQo+IEV4dGVuc2lvbiBmdW5jdGlvbnMgaXMgYSBtZWNoYW5pc20gdGhhdCBpcw0K PiBzdXBwb3J0ZWQgYnkgdGhlIChmZXcpIGV4aXN0aW5nIFhQYXRoIHByb2Nlc3NvcnMgSSB3b3Jr ZWQgd2l0aCwgYW5kIG1hZGUNCj4gb2ZmaWNpYWwgaW4gWFBhdGggMi4wLg0KDQpCdXQgYWxzbyBY UGF0aCAxLjAgc3VwcG9ydHMgdGhhdCB3ZSBkZWZpbmUgb3VyIG93biBmdW5jdGlvbnMuDQpjdXJy ZW50KCkgbWlnaHQgYmUgaW1wbGVtZW50ZWQgaW4gbW9zdCBYUGF0aCBsaWJyYXJpZXMsIGJ1dCBp dCBpcw0Kc3RpbGwgdGVjaG5pY2FsbHkgYSBmdW5jdGlvbiB3ZSBoYXZlIGRlZmluZWQgaW4gWUFO Ry4gIEl0IGlzIG5vdCBwYXJ0DQpvZiB0aGUgY29yZSBmdW5jdGlvbiBsaWJyYXJ5IGluIFhQYXRo IDEuMC4NCg0KDQoNCi9tYXJ0aW4NCg== From andy@netconfcentral.com Thu Aug 27 07:28: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 52B5E28C5E3 for ; Thu, 27 Aug 2009 07:28:43 -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_13=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 8bOKoiN9k+qv for ; Thu, 27 Aug 2009 07:28:42 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 27F6E28C5E8 for ; Thu, 27 Aug 2009 07:28:09 -0700 (PDT) Received: (qmail 41625 invoked from network); 27 Aug 2009 14:28:14 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2009 14:28:14 -0000 X-YMail-OSG: Y.chpYwVM1kaVPBMMybZu6jZ48AUaHxcP1Gmvtu2UxJ96PoS0lNm8MtiE9ETvpH16COdtYd4UPXkedQfTlh_afKVniZhQerfPAiqzP57Yxk5Cmxm1_Y7lB_dkyegj4hkM9sjLaNzfRCggia_D3FUIzd3usStCgjj797jbyYi45nkNAcJadAad_FQoWe86_ahMzGBXjmKdV_diUfufolxhLjiU8yUo0xFCDk30fui41N.rmKVgyV47g5www2_iMG3otUw2FCH4hKdXwSk X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A969805.6070100@netconfcentral.com> Date: Thu, 27 Aug 2009 07:28:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1251359720.3665.75.camel@missotis> <4A968600.7080306@netconfcentral.com> <1251379617.3665.254.camel@missotis> <4A9691BB.7090502@netconfcentral.com> <1251382425.3665.275.camel@missotis> In-Reply-To: <1251382425.3665.275.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 14:28:43 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Čt 27. 08. 2009 v 07:01 -0700: >> Ladislav Lhotka wrote: >>> Andy Bierman píše v Čt 27. 08. 2009 v 06:11 -0700: >>>> Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> Sec. 9.10.5 shows how local XML prefixes are used for representing >>>>> values of "identityref" type. However, this won't work in XPath >>>>> expressions because XPath doesn't know this type and there is no way for >>>>> properly mapping the prefixes to URIs. >>>>> >>>> I see no reason to change this at all. >>>> I found it easy to code -- no problems at all. >>> For XPath 'des:des3' is just a plain string literal and '=' performs a >>> string equality test. Of course, if you as a developer look at the >>> condition, realize what it means and then implement it in your code, >>> it's easy, but not how XPath is supposed to work. >> But I have to do that at least 10 times to implement XPath >> for YANG, so what's one more? >> >> You have to compare the value space, not the lexical space, >> or YANG doesn't actually work. You have to hunt down des:des3 >> or even just des3, because you know the base of the identityref >> from the YANG tpe. > > Then it's YPath, not XPath. Oh, right. That's a bad thing. Officially, we use XPath and support off-the-shelf XML tools. I keep forgetting that. So we need to invent some XPath-ish thing nobody else is using, instead of a YANG-ish thing nobody else is using, even though the 'foo = x:bar' syntax is the most user-friendly we will find? YANG users who are not XPath experts will not know the difference, or care, and XPath experts will not know about the strange encoding in (2) or the new function in (3). They know about (foo=x:bar) though. As long as YANG spec refers to XPath 1.0, it > must follow its semantics. Extension functions is a mechanism that is > supported by the (few) existing XPath processors I worked with, and made > official in XPath 2.0. > > Lada > Andy From mbj@tail-f.com Thu Aug 27 07:29: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 5FFEC3A6B42 for ; Thu, 27 Aug 2009 07:29:58 -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 C57k7Z0cTmC9 for ; Thu, 27 Aug 2009 07:29:57 -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 7A15A3A68F2 for ; Thu, 27 Aug 2009 07:29:57 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CE0F176C5B6; Thu, 27 Aug 2009 16:30:03 +0200 (CEST) Date: Thu, 27 Aug 2009 16:30:03 +0200 (CEST) Message-Id: <20090827.163003.130650426.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A968546.2070907@netconfcentral.com> References: <4A95EB78.7000009@netconfcentral.com> <20090827.094059.171210410.mbj@tail-f.com> <4A968546.2070907@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] 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: Thu, 27 Aug 2009 14:29:58 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Phil Shafer wrote: > >>> Andy Bierman writes: > >>>> So the server is always capable of returning all leafs that > >>>> it is using. All the complexity created for the client > >>>> due to 'server flexibility' is unwarranted. > >>> You are missing my point. When a user looks at configuration, they > >>> don't want to see the 50 or 100 knobs. They want to see the ones > >>> they care about. Interfaces in JUNOS have literally hundreds of > >>> knobs: > >>> > >> no -- we went through this all before. > > > > Indeed we did. And we realized that we will never be able to agree on > > one model for default handling. (The current discussion is evidence > > of that). So the NETCONF WG is chartered to work on how clients can > > learn how a server handles defaults. I don't think we should drop all > > this just b/c you now favor the 'report-all' mode. > > > > fine Good! So I guess we can move on now. Leaving :with-defaults behind us, what is the result from this long discussion? Are there any issues around "server-assigned" or "dynamic defaults" that we need to cover now? /martin From andy@netconfcentral.com Thu Aug 27 07:49: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 E0C8D28C608 for ; Thu, 27 Aug 2009 07:49:29 -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 CYWy+3uvafKj for ; Thu, 27 Aug 2009 07:49:29 -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 1C07028C5D1 for ; Thu, 27 Aug 2009 07:49:29 -0700 (PDT) Received: (qmail 44705 invoked from network); 27 Aug 2009 14:49:24 -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; 27 Aug 2009 14:49:24 -0000 X-YMail-OSG: msLEyu0VM1k6.vOO0gwTM96eq.AYQ1E.JTiYJC23u1Ukl1H0ACOpa5qwavo0.c9pi6d9wngYbEDMGahCVAslgMAdziT3J6DG.Y7Tj15bk2GQxS4BMtqhcOBzs9_r5RZbh.RhYqqBkrKrtvnEC1LbYQsG8wY7RFcEg_0pXLS9X3Q3T6PZEQAzV_4rfYeyPrKJg8dYj3F66Jp2jK4ayz6uGPLxZmoYeLdsYhXdxkj8VXIA7Vv_YTAfqX5Wvm9uHJGJS0Lyaeh0R7u9bAFBu_y1NQbqfw3OcijkLQUX4x81HGBXekSPeBywgmuiBc5V5V8xpVnbCvxOXH.oqQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A969CFB.2030301@netconfcentral.com> Date: Thu, 27 Aug 2009 07:49:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A95EB78.7000009@netconfcentral.com> <20090827.094059.171210410.mbj@tail-f.com> <4A968546.2070907@netconfcentral.com> <20090827.163003.130650426.mbj@tail-f.com> In-Reply-To: <20090827.163003.130650426.mbj@tail-f.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: Thu, 27 Aug 2009 14:49:30 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Phil Shafer wrote: >>>>> Andy Bierman writes: >>>>>> So the server is always capable of returning all leafs that >>>>>> it is using. All the complexity created for the client >>>>>> due to 'server flexibility' is unwarranted. >>>>> You are missing my point. When a user looks at configuration, they >>>>> don't want to see the 50 or 100 knobs. They want to see the ones >>>>> they care about. Interfaces in JUNOS have literally hundreds of >>>>> knobs: >>>>> >>>> no -- we went through this all before. >>> Indeed we did. And we realized that we will never be able to agree on >>> one model for default handling. (The current discussion is evidence >>> of that). So the NETCONF WG is chartered to work on how clients can >>> learn how a server handles defaults. I don't think we should drop all >>> this just b/c you now favor the 'report-all' mode. >>> >> fine > > Good! So I guess we can move on now. > To the next review round anyway. IMO the NETCONF protocol is not usable on servers which refuse to allow the client to retrieve the full configuration datastore, as specified in RFC 4741. IMO, such servers are not even compliant because RFC 4741 never says anywhere such filtering is permitted. The NETCONF RFC only recognizes the existence of a config=true/false filter, and subtree or XPath filters to select a subset of the whole datastore. IMO, the NETMOD WG is not producing a standard consistent with the existing NETCONF standard. I don't think the NETCONF protocol as you want it to be is an improvement over SNMP monitoring. It was never too much of a burden for SNMP agents to return the data the manager requested. It is harmful to interoperability to support such low-performance, minimal features in NETCONF monitoring. There is a huge difference between a default mode of pruning response data, that the client can override, and a NETCONF server with an arbitrary set of 'write-only' nodes in its database. > Leaving :with-defaults behind us, what is the result from this long > discussion? Are there any issues around "server-assigned" or "dynamic > defaults" that we need to cover now? > > > /martin > Andy From lhotka@cesnet.cz Thu Aug 27 07:50: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 5C91F28C5D1 for ; Thu, 27 Aug 2009 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=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 vDJwbACr7z0f for ; Thu, 27 Aug 2009 07:50:56 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7F4AB28C613 for ; Thu, 27 Aug 2009 07:50:56 -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 51837D800C8; Thu, 27 Aug 2009 16:51:02 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A969805.6070100@netconfcentral.com> References: <1251359720.3665.75.camel@missotis> <4A968600.7080306@netconfcentral.com> <1251379617.3665.254.camel@missotis> <4A9691BB.7090502@netconfcentral.com> <1251382425.3665.275.camel@missotis> <4A969805.6070100@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 27 Aug 2009 16:51:00 +0200 Message-Id: <1251384660.3665.284.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 14:50:57 -0000 Andy Bierman píše v Čt 27. 08. 2009 v 07:28 -0700: > > > > Then it's YPath, not XPath. > > Oh, right. That's a bad thing. > Officially, we use XPath and support off-the-shelf XML tools. > I keep forgetting that. AFAIK, translating a YANG module to DSDL schemas is currently the only way for validating an XML instance configuration against that module, including the 'must' conditions etc. This is because off-the-shelf tools are used. > > So we need to invent some XPath-ish thing nobody else is using, > instead of a YANG-ish thing nobody else is using, even though > the 'foo = x:bar' syntax is the most user-friendly we will find? Writing an extension for libxslt (for example) is much easier than rewriting the guts. Lada > > YANG users who are not XPath experts > will not know the difference, or care, and XPath experts > will not know about the strange encoding in (2) or the new > function in (3). They know about (foo=x:bar) though. > > > As long as YANG spec refers to XPath 1.0, it > > must follow its semantics. Extension functions is a mechanism that is > > supported by the (few) existing XPath processors I worked with, and made > > official in XPath 2.0. > > > > Lada > > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Thu Aug 27 08:59: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 E46E728C185 for ; Thu, 27 Aug 2009 08:59: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 w0MKipR8qHR9 for ; Thu, 27 Aug 2009 08:59:35 -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 AAC8A3A67C0 for ; Thu, 27 Aug 2009 08:59:34 -0700 (PDT) Received: (qmail 59205 invoked from network); 27 Aug 2009 15:59:39 -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; 27 Aug 2009 15:59:39 -0000 X-YMail-OSG: D7n2ZbwVM1mI4OdntS06d5wrW4qflrFSXq58g0MA96.w3iuRwkSbPr6zMv0tpZivzOvSJ5stSrpEI6nGQWw.o4xKKWch1EueuQfaGh2kX.InzkWFfTfMo9POCwkUK9_0HftjiFg2PasMtJPUgbwwGoqB6n8ZMmul7vQsy1dOwG58HUQul2Ff3rJb3gPdZn8NiXriE5FIl81N4h.phaBhpcfRWpOR5iScVMX9.RRMckvQwNBJq4QW2p9nZOP4ypf4yfMeKQQLkB1V7.JrEOTg65f2bZot23LDIN.UHWTkvsdf89sQrATr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96ACF7.6010204@netconfcentral.com> Date: Thu, 27 Aug 2009 08:57:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A95EB78.7000009@netconfcentral.com> <20090827.094059.171210410.mbj@tail-f.com> <4A968546.2070907@netconfcentral.com> <20090827.163003.130650426.mbj@tail-f.com> In-Reply-To: <20090827.163003.130650426.mbj@tail-f.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: Thu, 27 Aug 2009 15:59:36 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Phil Shafer wrote: >>>>> Andy Bierman writes: >>>>>> So the server is always capable of returning all leafs that >>>>>> it is using. All the complexity created for the client >>>>>> due to 'server flexibility' is unwarranted. >>>>> You are missing my point. When a user looks at configuration, they >>>>> don't want to see the 50 or 100 knobs. They want to see the ones >>>>> they care about. Interfaces in JUNOS have literally hundreds of >>>>> knobs: >>>>> >>>> no -- we went through this all before. >>> Indeed we did. And we realized that we will never be able to agree on >>> one model for default handling. (The current discussion is evidence >>> of that). So the NETCONF WG is chartered to work on how clients can >>> learn how a server handles defaults. I don't think we should drop all >>> this just b/c you now favor the 'report-all' mode. >>> >> fine > > Good! So I guess we can move on now. > The reason this is a show-stopper for me is that I incorrectly assumed that a 'get-exact' (e.g., filter for exact leaf) would return a value. It was just another annoying YANG-ism I didn't like before that. The justification for this filtering is fatally flawed. The notion that the operator can look up documentation that describes what the server *should* be doing is somehow equivalent to using a monitoring mechanism to find out what the server *is* doing -- is just incorrect. If this filtering was just limited to YANG default-stmts, then it would be fine, but it is not. leaf ifMtu { // this counts as documentation type uint32; } leaf ifMtu { type uint32; description "Server defaults: on the x3100 platform this is set to 1500. on the x4100 platform this is set to 1514. on the x9100 platform this is set to 1518, unless the serial number begins with X222, then the default is 9000. If VLAN encapsulation is enabled on the interface, then add the appropriate number of bytes (refer to user manual) on these platforms. On all other platforms, refer to the chart at http://www.example.com/defaults/ifMtu"; } Imagine the client needs to get the ifMtu value for every server, as part of its work. (If you incorrectly insist that ifMtu is state data, then imagine a 'config false;' statement in these leafs.) In NETCONF, every server can decide "I have that information in my vendor documentation so I am not returning it to you". Or decide "that leaf isn't one of the leafs a previous session already set, so you don't need to know its value." So instead of a simple consistent request-response that works the same on all implementations of the standard, there is no standard at all. The client has no idea what the server will decide to hide and no way to find out. To the client code, the server probably appears not to support that leaf at all. IMO, the easiest solution is to make with-defaults (report-all) mandatory-to-implement as part of 4741bis. RFC 4741 should be deprecated as soon as 4741-bis is published. > /martin > Andy From mbj@tail-f.com Thu Aug 27 09:11: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 F182028C1DA for ; Thu, 27 Aug 2009 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.096, 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 2F5VbKyiKht2 for ; Thu, 27 Aug 2009 09:11:28 -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 E986928C1FE for ; Thu, 27 Aug 2009 09:11:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F41576C5F5; Thu, 27 Aug 2009 18:11:33 +0200 (CEST) Date: Thu, 27 Aug 2009 18:11:33 +0200 (CEST) Message-Id: <20090827.181133.198199458.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A96ACF7.6010204@netconfcentral.com> References: <4A968546.2070907@netconfcentral.com> <20090827.163003.130650426.mbj@tail-f.com> <4A96ACF7.6010204@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] 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: Thu, 27 Aug 2009 16:11:29 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> Phil Shafer wrote: > >>>>> Andy Bierman writes: > >>>>>> So the server is always capable of returning all leafs that > >>>>>> it is using. All the complexity created for the client > >>>>>> due to 'server flexibility' is unwarranted. > >>>>> You are missing my point. When a user looks at configuration, they > >>>>> don't want to see the 50 or 100 knobs. They want to see the ones > >>>>> they care about. Interfaces in JUNOS have literally hundreds of > >>>>> knobs: > >>>>> > >>>> no -- we went through this all before. > >>> Indeed we did. And we realized that we will never be able to agree on > >>> one model for default handling. (The current discussion is evidence > >>> of that). So the NETCONF WG is chartered to work on how clients can > >>> learn how a server handles defaults. I don't think we should drop all > >>> this just b/c you now favor the 'report-all' mode. > >>> > >> fine > > > > Good! So I guess we can move on now. > > > > > The reason this is a show-stopper for me is that I incorrectly > assumed that a 'get-exact' (e.g., filter for exact leaf) would > return a value. It was just another annoying YANG-ism I didn't > like before that. > > The justification for this filtering is fatally flawed. > The notion that the operator can look up documentation > that describes what the server *should* be doing is somehow > equivalent to using a monitoring mechanism to find out what > the server *is* doing -- is just incorrect. > > If this filtering was just limited to YANG default-stmts, > then it would be fine, but it is not. I am just talking about static defaults, i.e. as defined by the "default" statement. You are talking about "dynamic defaults", and - again - YANG does not have any support for dynamic defaults. The only thing YANG specifies is that *if* a leaf has the "default" statement (static defaults), the server may choose to not send the default. I don't know what makes you say that it also applies to dynamic defaults defined in description clauses. AFAIK we haven't really discussed this before. /martin From andy@netconfcentral.com Thu Aug 27 09:29: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 CC6DD28C227 for ; Thu, 27 Aug 2009 09:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Vi5HV+MqyIUT for ; Thu, 27 Aug 2009 09:29:00 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id DD9BF28C1FB for ; Thu, 27 Aug 2009 09:28:59 -0700 (PDT) Received: from [209.191.108.97] by n20.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 16:29:06 -0000 Received: from [68.142.201.242] by t4.bullet.mud.yahoo.com with NNFMP; 27 Aug 2009 16:29:06 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 16:29:06 -0000 X-Yahoo-Newman-Id: 811686.71008.bm@omp403.mail.mud.yahoo.com Received: (qmail 82676 invoked from network); 27 Aug 2009 16:29:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 27 Aug 2009 16:29:06 -0000 X-YMail-OSG: vlxeLQkVM1mufMHw7UopN9PLAmNheqimJxNbINWQEOBYzDl4SWQlNlwMgj.aztujz_uByfqhXxNmwR4JEOBkphD_QsSg2mwUwYk1DCPfBT5z2N6GrjOFxZR85g1heuCsN.110nkyaDcx3aa_0uH.iOt.K6O3_M5nHBFqGunXSZCM2aSeErLOj9L1uOUsDs3FqSqo9b8SC7KSkh5UNQSC9vexTjI1fJSlvsR0CjJabknoS8hI4dfcpZPXY4BlZI8V_Am9a4HoGcw8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96B3E0.2050906@netconfcentral.com> Date: Thu, 27 Aug 2009 09:27:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A968546.2070907@netconfcentral.com> <20090827.163003.130650426.mbj@tail-f.com> <4A96ACF7.6010204@netconfcentral.com> <20090827.181133.198199458.mbj@tail-f.com> In-Reply-To: <20090827.181133.198199458.mbj@tail-f.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: Thu, 27 Aug 2009 16:29:00 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy Bierman wrote: >>>>>> Phil Shafer wrote: >>>>>>> Andy Bierman writes: >>>>>>>> So the server is always capable of returning all leafs that >>>>>>>> it is using. All the complexity created for the client >>>>>>>> due to 'server flexibility' is unwarranted. >>>>>>> You are missing my point. When a user looks at configuration, they >>>>>>> don't want to see the 50 or 100 knobs. They want to see the ones >>>>>>> they care about. Interfaces in JUNOS have literally hundreds of >>>>>>> knobs: >>>>>>> >>>>>> no -- we went through this all before. >>>>> Indeed we did. And we realized that we will never be able to agree on >>>>> one model for default handling. (The current discussion is evidence >>>>> of that). So the NETCONF WG is chartered to work on how clients can >>>>> learn how a server handles defaults. I don't think we should drop all >>>>> this just b/c you now favor the 'report-all' mode. >>>>> >>>> fine >>> Good! So I guess we can move on now. >>> >> >> The reason this is a show-stopper for me is that I incorrectly >> assumed that a 'get-exact' (e.g., filter for exact leaf) would >> return a value. It was just another annoying YANG-ism I didn't >> like before that. >> >> The justification for this filtering is fatally flawed. >> The notion that the operator can look up documentation >> that describes what the server *should* be doing is somehow >> equivalent to using a monitoring mechanism to find out what >> the server *is* doing -- is just incorrect. >> >> If this filtering was just limited to YANG default-stmts, >> then it would be fine, but it is not. > > I am just talking about static defaults, i.e. as defined by the > "default" statement. You are talking about "dynamic defaults", and - > again - YANG does not have any support for dynamic defaults. The only > thing YANG specifies is that *if* a leaf has the "default" statement > (static defaults), the server may choose to not send the default. > > I don't know what makes you say that it also applies to dynamic > defaults defined in description clauses. AFAIK we haven't really > discussed this before. > The draft DOES support any notion of a default any server implementor thinks up. I completely disagree that 'any notion of a default' is somehow meta-data. The draft DOES NOT limit a server to filtering just leafs with YANG default-stmts. That's why it has no standards value for monitoring. If YANG ignores this topic -- RFC 4741 does not. It clearly states that the NETCONF server must be able to return a full configuration database. > > /martin > Andy From mbj@tail-f.com Thu Aug 27 10:09: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 F22D328C238 for ; Thu, 27 Aug 2009 10:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.093, 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 9rgMwhQhensu for ; Thu, 27 Aug 2009 10:09:57 -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 368C628C21B for ; Thu, 27 Aug 2009 10:09:56 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F18F76C5B6; Thu, 27 Aug 2009 19:10:03 +0200 (CEST) Date: Thu, 27 Aug 2009 19:10:02 +0200 (CEST) Message-Id: <20090827.191002.48739649.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A96B3E0.2050906@netconfcentral.com> References: <4A96ACF7.6010204@netconfcentral.com> <20090827.181133.198199458.mbj@tail-f.com> <4A96B3E0.2050906@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] 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: Thu, 27 Aug 2009 17:09:58 -0000 Andy Bierman wrote: > The draft DOES support any notion of a default > any server implementor thinks up. Can you provide a reference? /martin From andy@netconfcentral.com Thu Aug 27 10:35: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 CB14D3A6A29 for ; Thu, 27 Aug 2009 10:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 cMYEYW2P7pZB for ; Thu, 27 Aug 2009 10:35:43 -0700 (PDT) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id E0E9B3A6D65 for ; Thu, 27 Aug 2009 10:35:42 -0700 (PDT) Received: from [68.142.200.221] by n15.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 17:35:48 -0000 Received: from [68.142.201.249] by t9.bullet.mud.yahoo.com with NNFMP; 27 Aug 2009 17:35:48 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 17:35:47 -0000 X-Yahoo-Newman-Id: 984241.91045.bm@omp410.mail.mud.yahoo.com Received: (qmail 42149 invoked from network); 27 Aug 2009 17:35:47 -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; 27 Aug 2009 17:35:47 -0000 X-YMail-OSG: VSfNAXkVM1lPlxgtpTi6nd_xFZqOrCw4QKeP2JrybGfIP2Bq6anEQS7lbguAw6KfawYwjrxxVAthaWlcnKoz8cZQ1wRpRHhI1k8iXKUq2oRZI_qQa7Zn0srlJt3P659IiK0UkNNjGScoNdM8puA.xkDIis6qqdAXmRx.yLrLuj3fL8rcV9jR9uLn3Tu2UOqgC5y_Ohz94nLLhhnraeqonAZRht5pNrclL0Xn8hE4HHWA17IP2g4nBvopYApOLJZcppCv2fIrmgLh X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96C3FA.9010407@netconfcentral.com> Date: Thu, 27 Aug 2009 10:35:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A96ACF7.6010204@netconfcentral.com> <20090827.181133.198199458.mbj@tail-f.com> <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> In-Reply-To: <20090827.191002.48739649.mbj@tail-f.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: Thu, 27 Aug 2009 17:35:43 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> The draft DOES support any notion of a default >> any server implementor thinks up. > > Can you provide a reference? > no -- because there is no text in the draft that limits the server to filtering only leafs that contain the YANG default-stmt value. If that is how YANG is proposing to alter the NETCONF protocol, then I approve. But it isn't. The proposal is to be silent in the standard and let the server do whatever it wants. ******************************************************************* Re-work of a previous solution proposal: Let's make 'trim' (*) the default behavior, and force servers to implement an optional extension (with-defaults or 4741bis) in order to use 'explicit' or even mandatory 'report-all'. (*) == where 'trim' only applies to leafs containing the YANG default-stmt value ******************************************************************** That is what the 'least-astonishment principle' says to do. The only leaf type that is safe to omit in all conforming implementations is one with a YANG default. If the server advertises ':with-defaults?basic=explicit', then I have no problem with keeping 'explicit', even though it is not multi-user friendly. At least a new client will be warned and an old client is no worse off than it was before. But allowing the server to pick some unspecified filtering scheme that the client cannot discover through the protocol violates even Phil's First Principles of protocol design. > > /martin > Andy From cfinss@dial.pipex.com Thu Aug 27 13:01:03 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 0A78C28C146 for ; Thu, 27 Aug 2009 13:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 OgSZ5WLYjSLu for ; Thu, 27 Aug 2009 13:01:02 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D59C23A6D3A for ; Thu, 27 Aug 2009 13:01:01 -0700 (PDT) X-Trace: 279357529/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.178/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.178 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: Ap0EANuClko+vGmy/2dsb2JhbACDLUCNMsdXCYQQBQ X-IronPort-AV: E=Sophos;i="4.44,288,1249254000"; d="scan'208";a="279357529" X-IP-Direction: IN Received: from 1cust178.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.178]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Aug 2009 21:01:06 +0100 Message-ID: <000801ca2748$8fd7e5e0$0601a8c0@allison> From: "tom.petch" To: "Martin Bjorklund" , "Andy Bierman" , "Lada Lhotka" References: <20090826.233259.182862400.mbj@tail-f.com><4A95AC30.5090405@netconfcentral.com> <20090827.102403.52519173.mbj@tail-f.com> Date: Thu, 27 Aug 2009 20:53:40 +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: [netmod] mandatory Re: meaning of config really 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: Thu, 27 Aug 2009 20:01:03 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, August 27, 2009 10:24 AM Subject: Re: [netmod] meaning of config really was meaning of default > WashamFan wrote: > > > ..... > > > Maybe my addition will just add confusion, although I beleive I agree > > > with Andy and Juergen. (As a > > > caveat, I use "means" below to indicate what I think the YANG text > > > explicitly requires.) > > > > > > 1) Mandatory means that if a manager is writing that part of the > > > tree, the manager MUST provide a > > > value for that item. > > > > > > 2) Default means that if no manager has not set the item, the item > > > will have the explicit value > > > given in the default clause in the data model. > > > ..... > > > > > > Neither one of these assertions is correct. > > > Mandatory means the node MUST exist in a valid database, > > > and says nothing about client vs. server created. > > > > But my impression is the majority talks about mandatory things based > > on 1) above. > > I agree. This is what mandatory means. So we do not agree. Martin, Washam, I think you are saying that a writable leaf with mandatory substatement can only have a value set by a client, never by the server/manufacturer side AND such a leaf need not exist in the data tree, (Does it have to be NETCONF protocol or would CLI do? fudge that for the moment) this being the consensus arrived at recently but not yet in the I-D. And, what the I-D does say, is that such a leaf cannot have a default substatement (and yes there are also caveats about containers and case) Andy, I think you are saying that if a writable leaf has a mandatory substatement the leaf MUST exist in the data tree, which is how I read the I-D. Also, as the I-D says, such a leaf cannot have a default substatement (but a value can be set by server or client). Lada, I recall you saying you would like to decouple default and mandatory "Another and IMO simpler option is to decouple mandatory/optional and default: 1. A leaf is mandatory if it must be present in a valid configuration, unless it is contained in a container with presence or a choice's case (these two cases require special handling)." which sounds similar to Andy. Tom, I agree with Lada on mandatory (I am not yet into default). Phil, Juergen, Joel, Per, Balazs, Jon, David, ... I am uncertain where you stand but I do not see a consensus that mandatory means the first option, ie that the client/manager must provide the value and that the leaf need not exist in the data tree. Tom Petch > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.com Thu Aug 27 14:25: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 9B1CD3A68F2 for ; Thu, 27 Aug 2009 14:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 u7OFCqePdb2e for ; Thu, 27 Aug 2009 14:25:28 -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 743CD3A6914 for ; Thu, 27 Aug 2009 14:25:28 -0700 (PDT) Received: from [68.142.200.227] by n10.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 21:25:33 -0000 Received: from [68.142.201.245] by t8.bullet.mud.yahoo.com with NNFMP; 27 Aug 2009 21:25:33 -0000 Received: from [127.0.0.1] by omp406.mail.mud.yahoo.com with NNFMP; 27 Aug 2009 21:25:33 -0000 X-Yahoo-Newman-Id: 746995.33064.bm@omp406.mail.mud.yahoo.com Received: (qmail 55245 invoked from network); 27 Aug 2009 21:25:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 27 Aug 2009 21:25:33 -0000 X-YMail-OSG: dqi6nSoVM1lGdozSyZAItcAPYuEp_im0A0.LAkscawJVRR8x4_0PzQBzWjFtZo1b8grVxQsiop1KRgMZ5tQZLme1jiyeyB7yinkHPvP5L62zvdY4_VVvgvYHkmqagmEbff8GdkjTn_u_6bnBQ69PGmxLQOgh8EGAq45RuxKoQJ82lpq_wnp87xZK5rQ_7TPAB0Gu3cJWol2_nL7HfROA94wZ214XokUc X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96F9D4.1080407@netconfcentral.com> Date: Thu, 27 Aug 2009 14:25:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" References: <20090826.233259.182862400.mbj@tail-f.com><4A95AC30.5090405@netconfcentral.com> <20090827.102403.52519173.mbj@tail-f.com> <000801ca2748$8fd7e5e0$0601a8c0@allison> In-Reply-To: <000801ca2748$8fd7e5e0$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] mandatory Re: meaning of config really 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: Thu, 27 Aug 2009 21:25:29 -0000 tom.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, August 27, 2009 10:24 AM > Subject: Re: [netmod] meaning of config really was meaning of default > > >> WashamFan wrote: >>>> ..... >>>> Maybe my addition will just add confusion, although I beleive I agree >>>> with Andy and Juergen. (As a >>>> caveat, I use "means" below to indicate what I think the YANG text >>>> explicitly requires.) >>>> >>>> 1) Mandatory means that if a manager is writing that part of the >>>> tree, the manager MUST provide a >>>> value for that item. >>>> >>>> 2) Default means that if no manager has not set the item, the item >>>> will have the explicit value >>>> given in the default clause in the data model. >>>> ..... >>>> >>>> Neither one of these assertions is correct. >>>> Mandatory means the node MUST exist in a valid database, >>>> and says nothing about client vs. server created. >>> But my impression is the majority talks about mandatory things based >>> on 1) above. >> I agree. This is what mandatory means. > > So we do not agree. > This is because the standard is too loosely defined. Some may say poorly-specified. Some prefer the term 'under-specified'. A good standard is precisely defined, such that the MUST, SHOULD, MAY semantics as expressed in RFC 21119 can be easily identified by independent implementors. I think the 100s of emails on these mandatory and default topics is clear evidence the draft is not standards track quality yet. The requirements for mandatory are in 7.6.4 and they say only that a mandatory leaf MUST exist. Period. There is no normative recognition of client-created vs. server-created anywhere in yang-07 or 4741bis. Every single reference to a default in yang-07 refers to these paragraphs (7.6, para 6 & 7) If a leaf has a "default" statement, the leaf's default value is set to 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 set to the type's default value. In all other cases, the leaf does not have a default value. If the leaf has a default value, the server MUST use this value internally if no value is provided by the NETCONF client when the instance is created. There are no other variants of a default anywhere in yang-07 or 4741bis. There is normative text in 4741 (and 4741bis) that says a server must be capable of returning a full configuration (note lowercase must though). I cannot find any normative text in YANG or NETCONF which would lead anyone to conclude that any other forms of defaults processing are recognized by the standard. That means that every and any other form of defaults filtering is NON-COMPLIANT, AND NOT 'OK'. The conformance to the :with-defaults capability cannot possibly alter the contract specified by the 4741 base capability. That capability has no support at all for anything other than get/get-config of subtree filtering. Therefore, all RFC 4741 and 4741bis servers MUST ONLY use 'with-defaults=report-all'. The protocol standard does not contain anything at all that would suggest otherwise. Perhaps the IESG will be the only ones able to settle this. Andy > Martin, Washam, I think you are saying that a writable leaf with mandatory > substatement > can only have a value set by a client, never by the server/manufacturer side > AND such a leaf need not exist in the data tree, > (Does it have to be NETCONF protocol or would CLI do? fudge that for the moment) > this being the consensus arrived at recently but not yet in the I-D. And, what > the I-D does say, is that such a leaf cannot have a default substatement (and > yes there are also caveats about containers and case) > > Andy, I think you are saying that if a writable leaf has a mandatory > substatement > the leaf MUST exist in the data tree, which is how I read the I-D. Also, as the > I-D says, such a leaf cannot have a default substatement (but a value can be set > by server or client). > > Lada, I recall you saying you would like to decouple default and mandatory > > "Another and IMO simpler option is to decouple mandatory/optional and > default: > > 1. A leaf is mandatory if it must be present in a valid configuration, > unless it is contained in a container with presence or a choice's case > (these two cases require special handling)." > > which sounds similar to Andy. > > Tom, I agree with Lada on mandatory (I am not yet into default). > > Phil, Juergen, Joel, Per, Balazs, Jon, David, ... I am uncertain where you stand > > but I do not see a consensus that mandatory means the first option, > ie that the client/manager must provide the value and that the leaf need not > exist in the data tree. > > Tom Petch >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > From phil@juniper.net Thu Aug 27 14:29: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 217273A6914 for ; Thu, 27 Aug 2009 14:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 ecOg8uGgsgfX for ; Thu, 27 Aug 2009 14:29:12 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 2D96D3A68F2 for ; Thu, 27 Aug 2009 14:29:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb6qxHG906Ujv6gr1y3DewaAnBS8du1@postini.com; Thu, 27 Aug 2009 14:29:19 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; Thu, 27 Aug 2009 14:25:59 -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); Thu, 27 Aug 2009 14:25:59 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:25:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:25:57 -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 n7RLPvd99918; Thu, 27 Aug 2009 14:25:57 -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 n7RKPoFV026567; Thu, 27 Aug 2009 20:25:50 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908272025.n7RKPoFV026567@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251378654.3665.240.camel@missotis> Date: Thu, 27 Aug 2009 16:25:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:25:57.0854 (UTC) FILETIME=[F7A1EFE0:01CA275C] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 21:29:13 -0000 Ladislav Lhotka writes: >Hmm, so let me also paste in Juergens text that you replied to: > >>... If you plug a PCMCIA network card in your notebook, you will see >>a suitable MTU - you did not configure it nor is it going to be the >>same for all possible network cards. > >Depending on if the 'default' statement appears inside the model. >If the model has a default statement and the configuration was >made using this model, then the device should honor that model's >default value. > >My reading is that if the "mtu" leaf had > > assigned-by system; > default 1500; > >"should honor" means that I could rely on MTU being configured to 1500 >(and get-config and report-all should >report the same value). > >If this is what you meant, I don't agree. My "depending in the .. model" applies to Juergen's "not is it going to be the same" comment. If the model has a default value, then that default should be honored. This is a distinct issue from 'assigned-by system'. In fact, mixing defaults (which tell you how the system will behave if you don't give a value) with 'a-by system' (which tells you the system will assign a value if you don't) is pointless. If you don't assign a value, the default value tell both you and the sytem how it will behave. No assignment is needed. Thanks, Phil From phil@juniper.net Thu Aug 27 14:29: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 8F1ED3A6EA2 for ; Thu, 27 Aug 2009 14:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 hl6sK-M0zLFl for ; Thu, 27 Aug 2009 14:29:15 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id B0C333A68F2 for ; Thu, 27 Aug 2009 14:29:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb6rzVEhPQFXNnP7PPCtJtmtYNYo2sE@postini.com; Thu, 27 Aug 2009 14:29:22 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; Thu, 27 Aug 2009 14:26: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); Thu, 27 Aug 2009 14:26:01 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26: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 n7RLPxd99926; Thu, 27 Aug 2009 14:25: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 n7RHWjwb025406; Thu, 27 Aug 2009 17:32:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271732.n7RHWjwb025406@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A96C3FA.9010407@netconfcentral.com> Date: Thu, 27 Aug 2009 13:32:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:26:00.0151 (UTC) FILETIME=[F9006E70:01CA275C] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 21:29:16 -0000 Andy Bierman writes: >If that is how YANG is proposing to alter the NETCONF >protocol, then I approve. YANG is not proposing altering the NETCONF protocol. >That is what the 'least-astonishment principle' says to do. The "trim" behaviour means you can set a leaf, fetch that leaf, and get nothing back. This is hardly least astonishment. Thanks, Phil From phil@juniper.net Thu Aug 27 14:29: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 AA3C83A6EAD for ; Thu, 27 Aug 2009 14:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 lau24JacYqD1 for ; Thu, 27 Aug 2009 14:29:15 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id B93293A6914 for ; Thu, 27 Aug 2009 14:29:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb6sDNXBuVq5cBXot+SIhy9D2ZoO2+V@postini.com; Thu, 27 Aug 2009 14:29:23 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; Thu, 27 Aug 2009 14:26:03 -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); Thu, 27 Aug 2009 14:26:03 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:02 -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 n7RLQ2d99965; Thu, 27 Aug 2009 14:26:02 -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 n7RGNfad024764; Thu, 27 Aug 2009 16:23:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271623.n7RGNfad024764@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251382425.3665.275.camel@missotis> Date: Thu, 27 Aug 2009 12:23:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:26:02.0589 (UTC) FILETIME=[FA7470D0:01CA275C] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] identityref and XPath 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: Thu, 27 Aug 2009 21:29:16 -0000 Ladislav Lhotka writes: >Then it's YPath, not XPath. As long as YANG spec refers to XPath 1.0, it >must follow its semantics. Extension functions is a mechanism that is >supported by the (few) existing XPath processors I worked with, and made >official in XPath 2.0. This is way too narrow a line to draw. XSLT uses XPath 1.0 and manages to add new datatypes (RTF) and functions (even function-available()) without anyone trying to call it "XSLTPath". Standards are meant to be reused, and this means adapting them to their new environment. Defining a "qname" type, with a type-specific equality operator, does not mean we are severing our connection with XPath. Thanks, Phil From phil@juniper.net Thu Aug 27 14:29:17 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 62CCD3A6EA2 for ; Thu, 27 Aug 2009 14:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 s6YaanM2Ol2c for ; Thu, 27 Aug 2009 14:29:16 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 70B313A6E97 for ; Thu, 27 Aug 2009 14:29:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb6sDNXBuVq5cBXot+SIhy9D2ZoO2+V@postini.com; Thu, 27 Aug 2009 14:29:23 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; Thu, 27 Aug 2009 14:26:04 -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); Thu, 27 Aug 2009 14:26:04 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:03 -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 n7RLQ3d99978; Thu, 27 Aug 2009 14:26:03 -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 n7RGIgYP024677; Thu, 27 Aug 2009 16:18:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271618.n7RGIgYP024677@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A96ACF7.6010204@netconfcentral.com> Date: Thu, 27 Aug 2009 12:18:42 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:26:03.0448 (UTC) FILETIME=[FAF78380:01CA275C] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 21:29:17 -0000 Andy Bierman writes: > leaf ifMtu { > type uint32; > description > "Server defaults: > on the x3100 platform this is set to 1500. > on the x4100 platform this is set to 1514. > on the x9100 platform this is set to 1518, unless > the serial number begins with X222, then the > default is 9000. If VLAN encapsulation is > enabled on the interface, then add the appropriate > number of bytes (refer to user manual) on these platforms. > On all other platforms, refer to the chart at > http://www.example.com/defaults/ifMtu"; > } Follow you case one step deeper: description "defaults: on a type I pic: 1500 on a type II pic: 1514 on a type III pic: 4096" Now if I pull a type I pic and insert a type II pic, did my configuration change? Heck, no. This isn't configuration data. The default value does not belong in the configuration database. Hot plugging FRUs in my chassis does not change configuration data. Dynamic defaults are not configuration data. Can we please move on? Thanks, Phil From phil@juniper.net Thu Aug 27 14:29:19 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 E1CC43A6914 for ; Thu, 27 Aug 2009 14:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 GxSGlkGrzi9I for ; Thu, 27 Aug 2009 14:29:19 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id E33893A6EC2 for ; Thu, 27 Aug 2009 14:29:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb6svZDTQFjml+D6HM+EmhTyXGIU08D@postini.com; Thu, 27 Aug 2009 14:29: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; Thu, 27 Aug 2009 14:26:05 -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); Thu, 27 Aug 2009 14:26:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:04 -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 n7RLQ4d99985; Thu, 27 Aug 2009 14:26:04 -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 n7RGDSxr024593; Thu, 27 Aug 2009 16:13:28 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271613.n7RGDSxr024593@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A969CFB.2030301@netconfcentral.com> Date: Thu, 27 Aug 2009 12:13:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:26:04.0214 (UTC) FILETIME=[FB6C6560:01CA275C] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 21:29:20 -0000 Andy Bierman writes: >IMO the NETCONF protocol is not usable on servers >which refuse to allow the client to retrieve the full >configuration datastore, as specified in RFC 4741. >IMO, such servers are not even compliant because RFC 4741 >never says anywhere such filtering is permitted. You are including default values in your definition of "the full configuration datastore". YANG does not. YANG-based servers are not refusing to allow any configuration data, but they are not forcing implementations to consider default values as configuration data. Claiming this violates 4741 is baseless. >I don't think the NETCONF protocol as you want it to be >is an improvement over SNMP monitoring. NETCONF is meant for configuration, so claiming that we are not an improvement over SNMP monitoring is pointless. >It was never >too much of a burden for SNMP agents to return the >data the manager requested. IMHO this was a weakness of SNMP; real data could not be adequately separated from fake data. Would you have archived your configuration by saving a mibwalk of your snmp tree? SNMP gave two tools (get,get-next) and one data structure (key=value), which gave designer and modelers too few choices. NETCONF and YANG give far better tools, mechanisms, and features. Trying to say "but that's the way we did it in snmp" won't fly. The "NG" in "YANG" is supposed to mean something. >It is harmful to interoperability >to support such low-performance, minimal features in NETCONF monitoring. Not putting well-known, static default values in the configuration database is harmful to monitoring? I can't see any credibility to this claim. >There is a huge difference between a default mode >of pruning response data, that the client can override, >and a NETCONF server with an arbitrary set of 'write-only' >nodes in its database. Please point me at the discussion of "an arbitrary set of 'write-only' nodes". I don't think anyone has mentioned such. Thanks, Phil From phil@juniper.net Thu Aug 27 14:29:20 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 F174F3A6EC2 for ; Thu, 27 Aug 2009 14:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 VXTGTyb4vqmL for ; Thu, 27 Aug 2009 14:29:19 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 21E3A3A6EC8 for ; Thu, 27 Aug 2009 14:29:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb6sDNXBuVq5cBXot+SIhy9D2ZoO2+V@postini.com; Thu, 27 Aug 2009 14:29: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; Thu, 27 Aug 2009 14:26:02 -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); Thu, 27 Aug 2009 14:26:02 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:01 -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 n7RLQ0d99938; Thu, 27 Aug 2009 14:26:00 -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 n7RGTfR3024892; Thu, 27 Aug 2009 16:29:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271629.n7RGTfR3024892@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A96B3E0.2050906@netconfcentral.com> Date: Thu, 27 Aug 2009 12:29:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:26:01.0042 (UTC) FILETIME=[F9886320:01CA275C] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 21:29:20 -0000 Andy Bierman writes: >The draft DOES NOT limit a server to filtering >just leafs with YANG default-stmts. That's why >it has no standards value for monitoring. > >If YANG ignores this topic -- RFC 4741 does not. >It clearly states that the NETCONF server must be able >to return a full configuration database. I'm puzzled that you are mixing monitoring with configuration. How do you see them overlapping? Apps that monitor configuration? Thanks, Phil From phil@juniper.net Thu Aug 27 14: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 80D0C3A6E97 for ; Thu, 27 Aug 2009 14:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 rpmuq00tfOaP for ; Thu, 27 Aug 2009 14:29:24 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 386D93A6DD7 for ; Thu, 27 Aug 2009 14:29:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb6tL7+cMA3U7WfEvVIWies5L7W5snq@postini.com; Thu, 27 Aug 2009 14:29:31 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; Thu, 27 Aug 2009 14:26:07 -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); Thu, 27 Aug 2009 14:26:07 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:07 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:26:06 -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 n7RLQ5d00122; Thu, 27 Aug 2009 14:26:05 -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 n7RFpM4I024349; Thu, 27 Aug 2009 15:51:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908271551.n7RFpM4I024349@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1251378654.3665.240.camel@missotis> Date: Thu, 27 Aug 2009 11:51:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:26:06.0104 (UTC) FILETIME=[FC8CC980:01CA275C] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 21:29:24 -0000 Ladislav Lhotka writes: >Hmm, so let me also paste in Juergens text that you replied to: > >>... If you plug a PCMCIA network card in your notebook, you will see >>a suitable MTU - you did not configure it nor is it going to be the >>same for all possible network cards. > >Depending on if the 'default' statement appears inside the model. >If the model has a default statement and the configuration was >made using this model, then the device should honor that model's >default value. > >My reading is that if the "mtu" leaf had > > assigned-by system; > default 1500; > >"should honor" means that I could rely on MTU being configured to 1500 >(and get-config and report-all should >report the same value). > >If this is what you meant, I don't agree. My "depending in the .. model" applies to Juergen's "not is it going to be the same" comment. If the model has a default value, then that default should be honored. This is a distinct issue from 'assigned-by system'. In fact, mixing defaults (which tell you how the system will behave if you don't give a value) with 'a-by system' (which tells you the system will assign a value if you don't) is pointless. If you don't assign a value, the default value tell both you and the sytem how it will behave. No assignment is needed. Thanks, Phil From phil@juniper.net Thu Aug 27 14:41: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 9CB8928C245 for ; Thu, 27 Aug 2009 14:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 FYfouwiLW2ZB for ; Thu, 27 Aug 2009 14:41:30 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 6C64B28C220 for ; Thu, 27 Aug 2009 14:41:23 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSpb9iRrMnhQRMKGmfYjPCHnBIwdw4L5y@postini.com; Thu, 27 Aug 2009 14:41:37 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; Thu, 27 Aug 2009 14:37:53 -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); Thu, 27 Aug 2009 14:37:53 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:37:52 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 14:37:51 -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 n7RLbpd05598; Thu, 27 Aug 2009 14:37:51 -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 n7RLPp0J027198; Thu, 27 Aug 2009 21:25:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908272125.n7RLPp0J027198@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A96F9D4.1080407@netconfcentral.com> Date: Thu, 27 Aug 2009 17:25:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 21:37:51.0832 (UTC) FILETIME=[A1325580:01CA275E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] mandatory Re: meaning of config really 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: Thu, 27 Aug 2009 21:41:31 -0000 Andy Bierman writes: >This is because the standard is too loosely defined. >Some may say poorly-specified. Some prefer >the term 'under-specified'. Google for "why specs matter". >I think the 100s of emails on these mandatory and default >topics is clear evidence the draft is not standards track >quality yet. I can work with Martin to add suitable words to the draft to eliminate this confusion. We thought the wording was straight forward and direct, but if you believe that we were not sufficiently clear, that can be corrected. We can also work up a format proposal for "assigned-by system", since that seems to be the feature you are lobbying for. Thanks, Phil From andy@netconfcentral.com Thu Aug 27 14:43: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 417CE28C280 for ; Thu, 27 Aug 2009 14:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 iD-W0OpOeu1u for ; Thu, 27 Aug 2009 14:43:32 -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 7BEFF28C202 for ; Thu, 27 Aug 2009 14:43:15 -0700 (PDT) Received: (qmail 14553 invoked from network); 27 Aug 2009 21:43:20 -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; 27 Aug 2009 21:43:19 -0000 X-YMail-OSG: R8dqDjYVM1m6oR9pVyBjcr7ij2nsgxGv97rQfaNFKR5xHUPOnWJV0JfEb0H.Jy35Qf6igtmxH0seFfHv3T72ypvAJKGuLA6d.XJyjecrXyzPlnh1t8FR2JHOxUL06JyYeMWhaNxa5MifT801ur3SzROXyBthdg1MXjQhgvirZBRqaIyyrDXaZ0dgYm9i9aN4lTAnUDbSYA155qo6cqkE7cUDmIKR_.fkmw4MrUGNtdHoaRv.JyLdUTgd7r1AWvSE60okyJ7tSBJ6e26Z5BO09d8I2MKv32RdaCbbzf9Vq0vnWh1C8KoS X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96FD87.7030707@netconfcentral.com> Date: Thu, 27 Aug 2009 14:41:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908271618.n7RGIgYP024677@idle.juniper.net> In-Reply-To: <200908271618.n7RGIgYP024677@idle.juniper.net> 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: Thu, 27 Aug 2009 21:43:33 -0000 Phil Shafer wrote: > Andy Bierman writes: >> leaf ifMtu { >> type uint32; >> description >> "Server defaults: >> on the x3100 platform this is set to 1500. >> on the x4100 platform this is set to 1514. >> on the x9100 platform this is set to 1518, unless >> the serial number begins with X222, then the >> default is 9000. If VLAN encapsulation is >> enabled on the interface, then add the appropriate >> number of bytes (refer to user manual) on these platforms. >> On all other platforms, refer to the chart at >> http://www.example.com/defaults/ifMtu"; >> } > > Follow you case one step deeper: > > description "defaults: > on a type I pic: 1500 > on a type II pic: 1514 > on a type III pic: 4096" > > Now if I pull a type I pic and insert a type II pic, did my > configuration change? Heck, no. This isn't configuration data. > The default value does not belong in the configuration database. > Hot plugging FRUs in my chassis does not change configuration data. > > Dynamic defaults are not configuration data. Can we please move on? > You are only proving that the client needs to retrieve this leaf from the server, whether its config or not. Any standard that pretends looking this up in the vendor documentation is better than just returning the stupid number is a joke. > Thanks, > Phil > Andy From andy@netconfcentral.com Thu Aug 27 14:51: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 9B48D28C31C for ; Thu, 27 Aug 2009 14:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 ZsR0-GB7hKZ6 for ; Thu, 27 Aug 2009 14:51:11 -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 EC2CA28C364 for ; Thu, 27 Aug 2009 14:51:11 -0700 (PDT) Received: (qmail 82283 invoked from network); 27 Aug 2009 21:51:16 -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; 27 Aug 2009 21:51:16 -0000 X-YMail-OSG: 72gvn.YVM1kbTnwnji2c3XqlCzoTv12J.3idjSlVvhLJ4oR9rDQ6G04j7DIkLK3D.iqCYgo.lZKrrDcmDAm3ozCGRGPYDW66wZNCcfuHIhCRs.ZRaGwD8BIr0NbHlJbStH3UelSsMwdYCHoADSoiI4myMwqH0iUXX6ValrYLvErBdnnIwbnJq.9IFTm5BK_gZ3xAp8MtBM7qSew- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96FF60.4050606@netconfcentral.com> Date: Thu, 27 Aug 2009 14:49:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908271613.n7RGDSxr024593@idle.juniper.net> In-Reply-To: <200908271613.n7RGDSxr024593@idle.juniper.net> 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: Thu, 27 Aug 2009 21:51:12 -0000 Phil Shafer wrote: > Andy Bierman writes: >> IMO the NETCONF protocol is not usable on servers >> which refuse to allow the client to retrieve the full >> configuration datastore, as specified in RFC 4741. >> IMO, such servers are not even compliant because RFC 4741 >> never says anywhere such filtering is permitted. > > You are including default values in your definition of "the full > configuration datastore". YANG does not. YANG-based servers are > not refusing to allow any configuration data, but they are not > forcing implementations to consider default values as configuration > data. Claiming this violates 4741 is baseless. > It's OK if we keep the leafs that contain the YANG default-stmt value out of the database. Then you agree that every other config leaf is part of the database. That is what the draft says -- we all agree on that. The only definition YANG has for a configuration node is if the config-stmt value is set to true. We all agree on that. So, all YANG nodes where the config-stmt is set to true are part of the database. Yet we don't seem to agree on that. Therefore, all leafs that contain a value other than the YANG default-stmt value MUST be returned by the server. We don't seem to agree on that either. I'd like you to point to the normative text in YANG-07 that supports any other server behavior for defaults besides omitting leafs containing their YANG default-stmt value. > Thanks, > Phil > Andy From phil@juniper.net Thu Aug 27 15:03: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 6497B28C612 for ; Thu, 27 Aug 2009 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 RZ+7ITGxvTfK for ; Thu, 27 Aug 2009 15:03:35 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id C3B2128C693 for ; Thu, 27 Aug 2009 15:03:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSpcCqNqZeNBN5gxPNzkYhGXSj+/A6nT9@postini.com; Thu, 27 Aug 2009 15:03:23 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; Thu, 27 Aug 2009 15:00:56 -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); Thu, 27 Aug 2009 15:00:56 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 15:00:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 15:00:54 -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 n7RM0sd17512; Thu, 27 Aug 2009 15:00:54 -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 n7RLmscH027507; Thu, 27 Aug 2009 21:48:54 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908272148.n7RLmscH027507@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A96FF60.4050606@netconfcentral.com> Date: Thu, 27 Aug 2009 17:48:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2009 22:00:54.0975 (UTC) FILETIME=[D99D34F0:01CA2761] MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 27 Aug 2009 22:03:36 -0000 Andy Bierman writes: >So, all YANG nodes where the config-stmt is set to true >are part of the database. Yet we don't seem to agree on that. "YANG nodes" are not part of the database. YANG nodes are metadata. They describe the data that can appear in the database and the constraints placed against the data. If my YANG modules says the following: leaf foo { type string; } and I perform the following operation: ... ... yes ... then I have just added foo to the database. foo is in the database with the value of "yes". If I fetch it, I will get the value "yes". If I then perform the following operation: ... ... yes ... then I have deleted foo from the database. If is no longer part of the database. If I fetch it, it will not be there. Thanks, Phil From andy@netconfcentral.com Thu Aug 27 15:22: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 1F99B3A6E33 for ; Thu, 27 Aug 2009 15:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 94fy7vSdGoyq for ; Thu, 27 Aug 2009 15:22:28 -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 5EB053A6822 for ; Thu, 27 Aug 2009 15:22:28 -0700 (PDT) Received: (qmail 7771 invoked from network); 27 Aug 2009 22:22:32 -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; 27 Aug 2009 22:22:32 -0000 X-YMail-OSG: lT4XP0QVM1msxCOzvKaybCY7AJSAgZeZXGISKwrkWK7EYXL6hLy92SIUuY668mskZM4zPvxFMKExW3A7y6NSLF4UcwX7qj.3aX7fVvHAFnkNxbTbB3v334XqKVU6Dv3wPNAErVnCrgcKT2i0L5RWnXY__ZgsWkFgLeB6h5KUFmasIURtTn8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A970730.1070801@netconfcentral.com> Date: Thu, 27 Aug 2009 15:22:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908272148.n7RLmscH027507@idle.juniper.net> In-Reply-To: <200908272148.n7RLmscH027507@idle.juniper.net> 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: Thu, 27 Aug 2009 22:22:29 -0000 Phil Shafer wrote: > Andy Bierman writes: >> So, all YANG nodes where the config-stmt is set to true >> are part of the database. Yet we don't seem to agree on that. > > "YANG nodes" are not part of the database. YANG nodes are metadata. > They describe the data that can appear in the database and the > constraints placed against the data. > > If my YANG modules says the following: > Let's focus on what the standard says. It clearly says that any instance of a leaf where config-stmt=true, in which the value is not set to the YANG-specified default value, is part of the database. This has to be true because all these nodes are part of the database validation procedures. YANG has no concept of a node which is config=false if the server sets it but config=true if the client sets it. That is non-standard. I strongly disagree with this interpretation of a standard NETCONF configuration database. The draft clearly says that any node statically defined as config=true is retrievable with the get-config operation (unless it is set to the YANG default). I don't see any support in the standard for the :explicit with-defaults filtering scheme at all. YANG only recognizes with-defaults=trim. The with-defaults draft should just add :report-all, and drop :explicit. It is not part of the standard and should stay that way. Andy > leaf foo { > type string; > } > > and I perform the following operation: > > > ... > > ... > yes > ... > > then I have just added foo to the database. foo is in the database > with the value of "yes". If I fetch it, I will get the value "yes". > > If I then perform the following operation: > > > ... > > ... > yes > ... > > then I have deleted foo from the database. If is no longer > part of the database. If I fetch it, it will not be there. > > Thanks, > Phil > From phil@juniper.net Thu Aug 27 20:31: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 AC31C28C388 for ; Thu, 27 Aug 2009 20:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 JN5gAYiwUyqa for ; Thu, 27 Aug 2009 20:31:56 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id D299D28C33C for ; Thu, 27 Aug 2009 20:31:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSpdPr4aKuG1qcPpQXEiIOGIaTV/sMVPu@postini.com; Thu, 27 Aug 2009 20:32:04 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; Thu, 27 Aug 2009 20:28:35 -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); Thu, 27 Aug 2009 20:28:35 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 20:28:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 20:28:34 -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 n7S3SWd59157; Thu, 27 Aug 2009 20:28: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 n7S3GW3u031015; Fri, 28 Aug 2009 03:16:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908280316.n7S3GW3u031015@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A970730.1070801@netconfcentral.com> Date: Thu, 27 Aug 2009 23:16:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 03:28:34.0874 (UTC) FILETIME=[9FD3B9A0:01CA278F] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 03:31:57 -0000 Andy Bierman writes: >I don't see any support in the standard for the >:explicit with-defaults filtering scheme at all. >YANG only recognizes with-defaults=trim. The draft 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. These words are meant to allow both the "explicit" and the "trim" styles, since the server's removal of data nodes whose value is the default value is optional. Thanks, Phil From andy@netconfcentral.com Thu Aug 27 21:11: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 8C33E3A6880 for ; Thu, 27 Aug 2009 21:11:46 -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 K-QQhz+qX3S3 for ; Thu, 27 Aug 2009 21:11:45 -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 922E33A6866 for ; Thu, 27 Aug 2009 21:11:45 -0700 (PDT) Received: (qmail 23881 invoked from network); 28 Aug 2009 04:11:50 -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; 28 Aug 2009 04:11:50 -0000 X-YMail-OSG: fpDRg1oVM1kRaVUivkKF53lMkx0a6AmNjpuBWARld_vNCZGUZpZv2DSB09_iqrRwMLvtCmO8jqcXda5v4vz8FguvoMFoOWJY0HFXriiW_zEiVZuIbteN4iilDa7.YiXEc0Na.4dAeC5XqWP7I6pfU0GZjCeAhMpalVlxERI4uzr7nEHanBpX1mxaBvPbYqRvEZ6ZNK9ECPfeC8i6KAPM0oBbtXfy9oDebnDu6C4eoCw.oDl5nMomzvFNTLcJA878.7WOfiyr038io6eb X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97590E.3080000@netconfcentral.com> Date: Thu, 27 Aug 2009 21:11:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908280316.n7S3GW3u031015@idle.juniper.net> In-Reply-To: <200908280316.n7S3GW3u031015@idle.juniper.net> 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: Fri, 28 Aug 2009 04:11:46 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I don't see any support in the standard for the >> :explicit with-defaults filtering scheme at all. >> YANG only recognizes with-defaults=trim. > > The draft 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. > > These words are meant to allow both the "explicit" and the "trim" > styles, since the server's removal of data nodes whose value is the > default value is optional. > This is where I strongly disagree. The NETCONF WG deferred specification of the content layer to the NETMOD WG. The NETMOD WG is developing that YANG language, which has a specific definition of a default (7.6, para 5). That means the standard NETCONF content layer for YANG modules has a specific definition of a default. It also has a specific definition of a mandatory node and a configuration node. OK -- now you got me typing ASCII art... +------------------------------------------------------+ | | | +----------------------------------------------+ | | | | | | | | | | | +--------------------+ +---------------+ | | | | | | | | | | | | | config true; | | config true; | | | | | | no default-stmt | | value set to | | | | | | or value != to | | default-stmt | | | | | | default-stmt | | per sec. 7.6 | | | | | +--------------------+ +---------------+ | | | | | | | +----------------------------------------------+ | | | | +------------------+ +---------------------+ | | | | | | | | | config false; | | | | | +------------------+ *---------------------+ | | | +------------------------------------------------------+ IMO, this is what the standard has specified in it today. If this doesn't work for some reason, then the correct action in a SDO is to make the standard say what you mean, not what you just kinda hope it means. Stuff not specified in the standard is non-standard. 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. How the server returns the entire portion is just another implementation detail that is irrelevant to our standards discussion. This issue also has nothing to do with monitoring. It has to do with operator requirements: >From RFC 3535, section 3: 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. 6. Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems. It is important to minimize the impact caused by configuration changes. I do not think pruning by any other means than leaf=default-stmt-value is clearly defined in the YANG draft, and the NETMOD WG is failing to meet these 3 operator requirements, if the standard permits anything else. > Thanks, > Phil > Andy From phil@juniper.net Thu Aug 27 22:25: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 203383A6A50 for ; Thu, 27 Aug 2009 22:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Jm2hBZSgvba8 for ; Thu, 27 Aug 2009 22:25:03 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 693BE3A69ED for ; Thu, 27 Aug 2009 22:25:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSpdqMrWsDkfrOWh/R0vTS2AbUT0Rh3yn@postini.com; Thu, 27 Aug 2009 22:25:10 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; Thu, 27 Aug 2009 22:22:52 -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); Thu, 27 Aug 2009 22:22:52 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 22:22:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 22:22:51 -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 n7S5Mod06810; Thu, 27 Aug 2009 22:22:50 -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 n7S5ApVq031830; Fri, 28 Aug 2009 05:10:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908280510.n7S5ApVq031830@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A97590E.3080000@netconfcentral.com> Date: Fri, 28 Aug 2009 01:10:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 05:22:51.0108 (UTC) FILETIME=[96760240:01CA279F] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 05:25:06 -0000 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. They are not interesting to most clients, nor are they worth the effort or bandwidth. Then you claim that this is needed for clients that can't read the YANG module, and I reply that we are not writing YANG modules so that clients can ignore them, and that there are other important bits of meta-data in the module that any client will need (keys, mandatory, parents, unique, etc). Eventually we say that the with-default capability can handle this if people want to implement it, so let's let the marketplace decide. >From RFC 3535, section 3: (2) is covered by "config true/false". (3) is covered by (6) is covered by xml diff In 3535, I read a very strong "don't do what snmp did" message. We aren't taking a GDMO-like approach. We are following a simpler, non-object-based, CLI-like approach. I've used this approach for years under JUNOS and it continues to perform well in real-world scenarios with real-world customers. I think we hit every point on every list contained in 3535. But again, this is a repeat of many previous emails. We aren't moving the discussion along and aren't sorting things out or clarifying issues. These should all be FAQs by now, and we should be pointing at the previously published answers. Thanks, Phil From Washam.Fan@huaweisymantec.com Thu Aug 27 23:35: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 015E93A6AA3 for ; Thu, 27 Aug 2009 23:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=0.245, 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 bPoIZZbcKQKj for ; Thu, 27 Aug 2009 23:35:51 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 1A33F3A6ACB for ; Thu, 27 Aug 2009 23:35:51 -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 <0KP200F0XQB25V30@hstga02-in.huaweisymantec.com> for netmod@ietf.org; Fri, 28 Aug 2009 14:35:27 +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 <0KP200IKHQB20P10@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Fri, 28 Aug 2009 14:35:26 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 28 Aug 2009 14:35:26 +0800 From: WashamFan To: "tom.petch" Message-id: Date: Fri, 28 Aug 2009 14:35:26 +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: <000801ca2748$8fd7e5e0$0601a8c0@allison> References: <20090826.233259.182862400.mbj@tail-f.com> <4A95AC30.5090405@netconfcentral.com> <20090827.102403.52519173.mbj@tail-f.com> <000801ca2748$8fd7e5e0$0601a8c0@allison> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory Re: meaning of config really 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: Fri, 28 Aug 2009 06:35:52 -0000 Hi, > Martin, Washam, I think you are saying that a writable leaf with mandatory > substatement > can only have a value set by a client, never by the > server/manufacturer side > AND such a leaf need not exist in the data tree, no, that is not I was saying, such a leaf DOES exist in the data tree. > (Does it have to be NETCONF protocol or would CLI do? fudge that for > the moment) Except top-level mandatory leafs, all mandatory leafs should be set by client via NETCONF. top-level mandatory leafs might be pre-loaded or initialised via CLI. In this regard, the mandantory definition seems broken, I admit. > this being the consensus arrived at recently but not yet in the I-D. > And, what > the I-D does say, is that such a leaf cannot have a default > substatement (and > yes there are also caveats about containers and case) No default at all for mandatory leafs, they MUST be explicitly set whatever server or client did it. washam From j.schoenwaelder@jacobs-university.de Thu Aug 27 23:55: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 158123A6E73 for ; Thu, 27 Aug 2009 23:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 IZG-0PDNWwTD for ; Thu, 27 Aug 2009 23:55:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0ED513A6E6F for ; Thu, 27 Aug 2009 23:55:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84041C00A3; Fri, 28 Aug 2009 08:55:34 +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 Lh8gLeb9V-pP; Fri, 28 Aug 2009 08:55:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F766C0083; Fri, 28 Aug 2009 08:55:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CCCAFC806AA; Fri, 28 Aug 2009 08:55:31 +0200 (CEST) Date: Fri, 28 Aug 2009 08:55:31 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090828065531.GA21838@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , "netmod@ietf.org" References: <20090826125958.GA20572@elstar.local> <200908261656.n7QGuZcZ014750@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908261656.n7QGuZcZ014750@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 06:55:29 -0000 On Wed, Aug 26, 2009 at 06:56:35PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >But then server-assigned or assigned-by system is not telling the > >truth since I can assign by client as well... No, I do not have a good > >proposal (yet). > > "assigned-by system" means that the value for this leaf _can_ be > assigned by the system, if one is not provided. If one is provided, > the system will not assign one and the leaf will be treated like > normal configuration data. I understand the intended semantics. My point was that the proposed syntax can be easily misread. /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 Fri Aug 28 00:39: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 5BD843A6DCB for ; Fri, 28 Aug 2009 00:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 tAwjIHnQuQvI for ; Fri, 28 Aug 2009 00:39:04 -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 D2CAD3A694D for ; Fri, 28 Aug 2009 00:39:00 -0700 (PDT) Received: (qmail 21662 invoked from network); 28 Aug 2009 07:39:05 -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; 28 Aug 2009 07:39:05 -0000 X-YMail-OSG: ZI1.4zAVM1kDmSUPE6hqud.C92Ss59KVonlWyaj6zRZmikyjdgLFV3Lc2gPonbkFvMJav0fBb8BXo6bAoS8ZZLJBGKTs5af_IBaM8L0mXKdxyiiAbeyNhBGJe3uuxibxPIBq_5U.w0AgexdcFfQ6mLwPQkyVcNPKDRo7fFPL3ChTE3vVyhrrvB8qylWsvp5k9uuP5plrM9pFSCI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A978928.3070802@netconfcentral.com> Date: Fri, 28 Aug 2009 00:37:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908280510.n7S5ApVq031830@idle.juniper.net> In-Reply-To: <200908280510.n7S5ApVq031830@idle.juniper.net> 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: Fri, 28 Aug 2009 07:39:05 -0000 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. 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. The operators at the IAB workshop clearly asked for a retrieval mechanism for all types of NM data. Nobody at that meeting asked for an opportunity to practice looking up vendor documentation as a substitute for a retrieval mechanism. > They are not interesting to most clients, nor are they worth the > effort or bandwidth. Then you claim that this is needed for clients > that can't read the YANG module, and I reply that we are not writing > YANG modules so that clients can ignore them, and that there are > other important bits of meta-data in the module that any client > will need (keys, mandatory, parents, unique, etc). Eventually > we say that the with-default capability can handle this if people > want to implement it, so let's let the marketplace decide. > >>From RFC 3535, section 3: > > (2) is covered by "config true/false". then why do you think a node is config=false if the server sets it but config=true if the client set it? That is not specified anywhere in the draft. > (3) is covered by > (6) is covered by xml diff > XML diff is incomplete unless you have the whole database. The draft has no text at all that defines your notion of a NETCONF database. It just has a static mandatory true/false and a static default-stmt. > In 3535, I read a very strong "don't do what snmp did" message. We > aren't taking a GDMO-like approach. We are following a simpler, > non-object-based, CLI-like approach. I've used this approach for > years under JUNOS and it continues to perform well in real-world > scenarios with real-world customers. I think we hit every point > on every list contained in 3535. > You want to take a huge step backward. We figured out 25 years ago that a consistent device data retrieval mechanism was far more useful than "looking up what the number should be" in some offline documentation. That's not going back to SNMP. It's going back to pre-SNMP, pre-SGMP, pre-historic. > But again, this is a repeat of many previous emails. We aren't > moving the discussion along and aren't sorting things out or > clarifying issues. These should all be FAQs by now, and we should > be pointing at the previously published answers. > > Thanks, > Phil > Andy From mbj@tail-f.com Fri Aug 28 01:04: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 F2D873A6EEF for ; Fri, 28 Aug 2009 01:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.139, 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 KA-exd4kRqaI for ; Fri, 28 Aug 2009 01:04:04 -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 4081428C191 for ; Fri, 28 Aug 2009 01:03:13 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id B2E70616001; Fri, 28 Aug 2009 10:03:18 +0200 (CEST) Date: Fri, 28 Aug 2009 10:03:21 +0200 (CEST) Message-Id: <20090828.100321.220069022.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200908271623.n7RGNfad024764@idle.juniper.net> References: <1251382425.3665.275.camel@missotis> <200908271623.n7RGNfad024764@idle.juniper.net> 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] identityref and XPath 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: Fri, 28 Aug 2009 08:04:05 -0000 Phil Shafer wrote: > Ladislav Lhotka writes: > >Then it's YPath, not XPath. As long as YANG spec refers to XPath 1.0, it > >must follow its semantics. Extension functions is a mechanism that is > >supported by the (few) existing XPath processors I worked with, and made > >official in XPath 2.0. > > This is way too narrow a line to draw. XSLT uses XPath 1.0 and > manages to add new datatypes (RTF) and functions (even function-available()) > without anyone trying to call it "XSLTPath". > > Standards are meant to be reused, and this means adapting them to > their new environment. Defining a "qname" type, with a type-specific > equality operator, does not mean we are severing our connection > with XPath. Even if you are right, I think it would be a much bigger effort to introduce a 'qname' type, than adding a new function. (and I don't believe you are right - the XPath spec clearly allows you to define new functions, but it does not say anything about new types) /martin From mbj@tail-f.com Fri Aug 28 01:28: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 34FF328C293 for ; Fri, 28 Aug 2009 01:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.129, 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 2cizppeTcNvn for ; Fri, 28 Aug 2009 01:28:32 -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 7BBF128C22F for ; Fri, 28 Aug 2009 01:28:00 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 68E4C616001; Fri, 28 Aug 2009 10:28:06 +0200 (CEST) Date: Fri, 28 Aug 2009 10:28:08 +0200 (CEST) Message-Id: <20090828.102808.31895182.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A96C3FA.9010407@netconfcentral.com> References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@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] 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: Fri, 28 Aug 2009 08:28:33 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> The draft DOES support any notion of a default > >> any server implementor thinks up. > > > > Can you provide a reference? > > > > no -- because there is no text in the draft that > limits the server to filtering only leafs that > contain the YANG default-stmt value. But a dynamic default means that it is a value that the server operationally uses if the leaf *is not present in the config*. So since it is not present in the config, the server will not return it in a get-config. This does not mean that the server filters it out - how can it filter out something that isn't even there? > If that is how YANG is proposing to alter the NETCONF > protocol, then I approve. YANG does not alter NETCONF. > But it isn't. The proposal is to be silent in the standard > and let the server do whatever it wants. Would it help if we add text that says that a server MUST send all nodes that the client asks for, if he has access, except if the 'default' statement is present on a leaf? > ******************************************************************* > Re-work of a previous solution proposal: > > Let's make 'trim' (*) the default behavior, and force servers > to implement an optional extension (with-defaults or 4741bis) > in order to use 'explicit' or even mandatory 'report-all'. > > (*) == where 'trim' only applies to leafs containing > the YANG default-stmt value > ******************************************************************** The current text allows servers to do 'trim', 'explicit' or 'report-all'. I do not want to change that. > The only leaf type that is safe to omit in all conforming > implementations is one with a YANG default. > > If the server advertises ':with-defaults?basic=explicit', > then I have no problem with keeping 'explicit', even though > it is not multi-user friendly. At least a new client > will be warned and an old client is no worse off than it was before. > > But allowing the server to pick some unspecified filtering scheme that > the client cannot discover through the protocol > violates even Phil's First Principles of protocol design. AFAIK, no one has suggested that we should allow servers to do unspecified filtering mechanisms. /martin From mbj@tail-f.com Fri Aug 28 01:45: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 B8C513A6D6F for ; Fri, 28 Aug 2009 01:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.120, 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 j2P8VKO0d1mh for ; Fri, 28 Aug 2009 01:45:10 -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 967F73A6C76 for ; Fri, 28 Aug 2009 01:45:10 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 117A0616001; Fri, 28 Aug 2009 10:45:17 +0200 (CEST) Date: Fri, 28 Aug 2009 10:45:20 +0200 (CEST) Message-Id: <20090828.104520.190612403.mbj@tail-f.com> To: cfinss@dial.pipex.com From: Martin Bjorklund In-Reply-To: <000801ca2748$8fd7e5e0$0601a8c0@allison> References: <20090827.102403.52519173.mbj@tail-f.com> <000801ca2748$8fd7e5e0$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] mandatory Re: meaning of config really 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: Fri, 28 Aug 2009 08:45:11 -0000 "tom.petch" wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, August 27, 2009 10:24 AM > Subject: Re: [netmod] meaning of config really was meaning of default > > > > WashamFan wrote: > > > > ..... > > > > Maybe my addition will just add confusion, although I beleive I agree > > > > with Andy and Juergen. (As a > > > > caveat, I use "means" below to indicate what I think the YANG text > > > > explicitly requires.) > > > > > > > > 1) Mandatory means that if a manager is writing that part of the > > > > tree, the manager MUST provide a > > > > value for that item. > > > > > > > > 2) Default means that if no manager has not set the item, the item > > > > will have the explicit value > > > > given in the default clause in the data model. > > > > ..... > > > > > > > > Neither one of these assertions is correct. > > > > Mandatory means the node MUST exist in a valid database, > > > > and says nothing about client vs. server created. > > > > > > But my impression is the majority talks about mandatory things based > > > on 1) above. > > > > I agree. This is what mandatory means. > > So we do not agree. > > Martin, Washam, I think you are saying that a writable leaf with mandatory > substatement > can only have a value set by a client, never by the > server/manufacturer side No, b/c I want to allow "pre-loaded" data, and other scenarios as well where the server-side creates data. What I mean might be easiest explained with an example: suppose the list 'foo' has a mandatory leaf 'bar'. Now, if the client creates a new foo entry, it MUST provide a value for 'bar' to make the config valid. If this is an edit-config towards running, 'bar' MUST be present in the same edit-config. If it was towards the shared candidate, *someone* MUST set 'bar' before commit. Now, if we had 'assigned-by-server', and a leaf 'baz' was marked with this, the client knows that it does not need to provide a value, since the server will pick one if necessary. If the server picked one, it will be present in the config data store, just as if the client set it. (If we introduce 'assigned-by-server', we can debate over whether the server MUST or MAY set a value...) > AND such a leaf need not exist in the data tree, Such a leaf absolutely exist in the data tree! > (Does it have to be NETCONF protocol or would CLI do? fudge that for the > moment) No it is important to get the words right here so we don't exclude e.g. CLI users. > this being the consensus arrived at recently but not yet in the I-D. And, what > the I-D does say, is that such a leaf cannot have a default substatement (and > yes there are also caveats about containers and case) This still applies of course. /martin From andy@netconfcentral.com Fri Aug 28 04:38: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 057DF3A6DFB for ; Fri, 28 Aug 2009 04:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 BlSsPfbcuQ4l for ; Fri, 28 Aug 2009 04:38:06 -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 3969428C19A for ; Fri, 28 Aug 2009 04:37:56 -0700 (PDT) Received: from [68.142.200.227] by n10.bullet.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 11:38:01 -0000 Received: from [68.142.201.253] by t8.bullet.mud.yahoo.com with NNFMP; 28 Aug 2009 11:38:01 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 11:38:01 -0000 X-Yahoo-Newman-Id: 637975.85494.bm@omp414.mail.mud.yahoo.com Received: (qmail 6129 invoked from network); 28 Aug 2009 11:38:01 -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; 28 Aug 2009 11:38:00 -0000 X-YMail-OSG: NwIMRR4VM1n.Ot.lA7Kb_LdHzGXY4EYgV1n6Xi9PmlTqDOJX6EHg29L4Q7pywfECBlI.eNd58qI3utZwBWjDePY5XHEf0kvXMAzVRr_yTPgcW2Z1aCBtXiaNrETI2W6_UswtP_OM7hvOHT5mbW2TL0rHDfkNZ1zXMuqDKcQ5gHqnHopS4Z8zIZdKl15Xc_1NTCSZC9rJ59EznCCTOh3U4ARopVRg2RTdfNrNr5gaf1gWcaTTmS0qF0LxTAvB3EbUki.Da5UEAe_c X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97C1A1.5010306@netconfcentral.com> Date: Fri, 28 Aug 2009 04:38:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> In-Reply-To: <20090828.102808.31895182.mbj@tail-f.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: Fri, 28 Aug 2009 11:38:07 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> The draft DOES support any notion of a default >>>> any server implementor thinks up. >>> Can you provide a reference? >>> >> no -- because there is no text in the draft that >> limits the server to filtering only leafs that >> contain the YANG default-stmt value. > > But a dynamic default means that it is a value that the server > operationally uses if the leaf *is not present in the config*. So > since it is not present in the config, the server will not return it > in a get-config. This does not mean that the server filters it out - > how can it filter out something that isn't even there? > There is no dynamic default in the YANG standard that I know about. Please point out which page that is defined. >> If that is how YANG is proposing to alter the NETCONF >> protocol, then I approve. > > YANG does not alter NETCONF. > BS >> But it isn't. The proposal is to be silent in the standard >> and let the server do whatever it wants. > Where is this specified in the standard. > Would it help if we add text that says that a server MUST send all > nodes that the client asks for, if he has access, except if the > 'default' statement is present on a leaf? yes > >> ******************************************************************* >> Re-work of a previous solution proposal: >> >> Let's make 'trim' (*) the default behavior, and force servers >> to implement an optional extension (with-defaults or 4741bis) >> in order to use 'explicit' or even mandatory 'report-all'. >> >> (*) == where 'trim' only applies to leafs containing >> the YANG default-stmt value >> ******************************************************************** > > The current text allows servers to do 'trim', 'explicit' or > 'report-all'. I do not want to change that. > No it does not. The draft defines a default in sec. 7.6. The draft says everything except this default is a node in the database (if config=true). There is no mention anywhere in the standard about anything related to server-created vs. client-created. Please point out which section in the draft specifies this behavior. >> The only leaf type that is safe to omit in all conforming >> implementations is one with a YANG default. >> >> If the server advertises ':with-defaults?basic=explicit', >> then I have no problem with keeping 'explicit', even though >> it is not multi-user friendly. At least a new client >> will be warned and an old client is no worse off than it was before. >> >> But allowing the server to pick some unspecified filtering scheme that >> the client cannot discover through the protocol >> violates even Phil's First Principles of protocol design. > > AFAIK, no one has suggested that we should allow servers to do unspecified > filtering mechanisms. > I claim that the only behavior included in the standard is that behavior actually specified in the standard. You claim YANG supports 'explicit' type defaults filtering, but there isn't any text in the draft to suggest this is true. > > /martin > Andy From andy@netconfcentral.com Fri Aug 28 05:16: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 BB1DC28C1C4 for ; Fri, 28 Aug 2009 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 GQ9PkY1CIT9N for ; Fri, 28 Aug 2009 05:16:40 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id D97BB28C346 for ; Fri, 28 Aug 2009 05:16:39 -0700 (PDT) Received: (qmail 29042 invoked from network); 28 Aug 2009 12:16:45 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2009 12:16:44 -0000 X-YMail-OSG: 24LAFW0VM1l7R_dHV_LQr1IllDyXQ8dhHZ5sL96Tt85n.mZJIBHJMz94.A4.vm4qX4I4oPHg.qY08pnRzjMdd6I_4LumOfjjwtmUvMKSm3Ln5Uk2raAm62O65eLblqZoO.nYWjr76PFBXeD4KNnUvGo10Ls_gcB_VjN5f1F7EmFrEzYIQNqxP0Fc2JmkMTvKw5lc73YmQbASlVBmqS.PaLCTMUZO_RkX4yWaPVie2WDzQsS.Jcyyzxi1NW3j6n.L9F3YseXI5AnYwbbafyNHGIqZwYLxhzoB0AVPp7YAvM4r13meYcfT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97CAB5.3010205@netconfcentral.com> Date: Fri, 28 Aug 2009 05:16:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <1251382425.3665.275.camel@missotis> <200908271623.n7RGNfad024764@idle.juniper.net> <20090828.100321.220069022.mbj@tail-f.com> In-Reply-To: <20090828.100321.220069022.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] identityref and XPath 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: Fri, 28 Aug 2009 12:16:40 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> Ladislav Lhotka writes: >>> Then it's YPath, not XPath. As long as YANG spec refers to XPath 1.0, it >>> must follow its semantics. Extension functions is a mechanism that is >>> supported by the (few) existing XPath processors I worked with, and made >>> official in XPath 2.0. >> This is way too narrow a line to draw. XSLT uses XPath 1.0 and >> manages to add new datatypes (RTF) and functions (even function-available()) >> without anyone trying to call it "XSLTPath". >> >> Standards are meant to be reused, and this means adapting them to >> their new environment. Defining a "qname" type, with a type-specific >> equality operator, does not mean we are severing our connection >> with XPath. > > Even if you are right, I think it would be a much bigger effort to > introduce a 'qname' type, than adding a new function. > > (and I don't believe you are right - the XPath spec clearly allows you > to define new functions, but it does not say anything about new types) > I think a new function is the best way to go, but Lada is correct that there are more types than just identityref that embed XML prefixes into literals. - instance-identifier - identityref - xpath1.0 (ietf-yang-types) - qname (unsupported) > > /martin Andy From andy@netconfcentral.com Fri Aug 28 05:25: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 C0A093A6E6A for ; Fri, 28 Aug 2009 05:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 oYLHLKqkxlhi for ; Fri, 28 Aug 2009 05:25:51 -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 DAB563A710F for ; Fri, 28 Aug 2009 05:25:50 -0700 (PDT) Received: (qmail 79727 invoked from network); 28 Aug 2009 12:25:55 -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; 28 Aug 2009 12:25:55 -0000 X-YMail-OSG: ps9rmW0VM1l1cjSeq1vTcityuphhIBKDj56oTdffpWLpfGhl8pqSNN9j8c.E.uxUFLEY7_LSRuJix3krKL8DYcLB0iDoQ9bXxwAZJHKCx.6Pd1nUqx4E01qPEZW17T9dFKXOcWf5VIw4Oah11HKTLquk1d_dwRa_pjrG3Fj5NfFZgl0sM0CN0x9fLHNT_2909QVuOfQxTG0TklM.g3V9u_Wvx9.sBWjJE1.w0P5Iv6aGateVHdz4HUP90ZuJu1qWdAp02ats2Qo2HHdU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97CCDB.6090400@netconfcentral.com> Date: Fri, 28 Aug 2009 05:26:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> In-Reply-To: <20090828.102808.31895182.mbj@tail-f.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: Fri, 28 Aug 2009 12:25:51 -0000 Martin Bjorklund wrote: I want to be precise: If the draft clearly defined exactly how an 'explicit' filter is identified in YANG, and exactly how it affects the NETCONF protocol, then it is not a problem because then it would be specified in the standard. The operators at the NM workshop were fairly clear about 3 types of data (config, state, and statistics), although these terms are never defined in RFC 3535. Our model has 2 states (config=true/false). Maybe the model needs more work. Andy From andy@netconfcentral.com Fri Aug 28 05:44:19 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 8777D3A6B30 for ; Fri, 28 Aug 2009 05:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 zTL1toGDf9AN for ; Fri, 28 Aug 2009 05:44:18 -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 C8B8C28C38D for ; Fri, 28 Aug 2009 05:43:42 -0700 (PDT) Received: (qmail 23603 invoked from network); 28 Aug 2009 12:43:44 -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; 28 Aug 2009 12:43:44 -0000 X-YMail-OSG: mECeYBoVM1lOuEYJgfjP6UbLh5OOCA53WLCnBe.nC3fFdcClfsrzrMalcYemagBHWIoRTi5lKZ0SX_hIGl0nqJeDDZdoPHu1tcl69PluMDawfkaCqs_uCybnRX8irDKi_MtL7HWSqsSj5vAYJTdFxEUwNu23s.jmTlfGbXO2lDSu_1_pf2Q2Y19V76FAua4ed_iCaKHRkPlANNc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97D108.8040206@netconfcentral.com> Date: Fri, 28 Aug 2009 05:43:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer , Martin Bjorklund , "netmod@ietf.org" References: <20090826125958.GA20572@elstar.local> <200908261656.n7QGuZcZ014750@idle.juniper.net> <20090828065531.GA21838@elstar.local> In-Reply-To: <20090828065531.GA21838@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 28 Aug 2009 12:44:19 -0000 Juergen Schoenwaelder wrote: > On Wed, Aug 26, 2009 at 06:56:35PM +0200, Phil Shafer wrote: >> Juergen Schoenwaelder writes: >>> But then server-assigned or assigned-by system is not telling the >>> truth since I can assign by client as well... No, I do not have a good >>> proposal (yet). >> "assigned-by system" means that the value for this leaf _can_ be >> assigned by the system, if one is not provided. If one is provided, >> the system will not assign one and the leaf will be treated like >> normal configuration data. > > I understand the intended semantics. My point was that the proposed > syntax can be easily misread. I don't think I understand all the intended semantics. When the modeling language clearly distinguishes and supports this list, then it will be ready for prime-time: - pure config, such as an ACL - combined config and state, such as if-mtu - combined config and state, such as static and learned routes - pure statistics, such as ifInOctets > > /js > Andy From mbj@tail-f.com Fri Aug 28 05:44: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 DD8D33A6DFB for ; Fri, 28 Aug 2009 05:44:27 -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 m-Ukj9Uw2UiX for ; Fri, 28 Aug 2009 05:44: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 02E473A6FCF for ; Fri, 28 Aug 2009 05:44:25 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BB045616001; Fri, 28 Aug 2009 14:44:30 +0200 (CEST) Date: Fri, 28 Aug 2009 14:44:30 +0200 (CEST) Message-Id: <20090828.144430.01066064.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A97C1A1.5010306@netconfcentral.com> References: <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97C1A1.5010306@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] 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: Fri, 28 Aug 2009 12:44:27 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> The draft DOES support any notion of a default > >>>> any server implementor thinks up. > >>> Can you provide a reference? > >>> > >> no -- because there is no text in the draft that > >> limits the server to filtering only leafs that > >> contain the YANG default-stmt value. > > > > But a dynamic default means that it is a value that the server > > operationally uses if the leaf *is not present in the config*. So > > since it is not present in the config, the server will not return it > > in a get-config. This does not mean that the server filters it out - > > how can it filter out something that isn't even there? > > > > There is no dynamic default in the YANG standard that I know about. > Please point out which page that is defined. This is leading nowhere. But see (*) below. > >> If that is how YANG is proposing to alter the NETCONF > >> protocol, then I approve. > > > > YANG does not alter NETCONF. > > > > BS If this really is what you believe, I suggest you start a new thread where you identify which portion of NETCONF that YANG alters, and how. > >> But it isn't. The proposal is to be silent in the standard > >> and let the server do whatever it wants. > > > > Where is this specified in the standard. Do you realize that you comment on your own statement? > > Would it help if we add text that says that a server MUST send all > > nodes that the client asks for, if he has access, except if the > > 'default' statement is present on a leaf? > > yes (*) Ok. If we add something like this, are there still any issues left (regarding defaults)? > >> ******************************************************************* > >> Re-work of a previous solution proposal: > >> > >> Let's make 'trim' (*) the default behavior, and force servers > >> to implement an optional extension (with-defaults or 4741bis) > >> in order to use 'explicit' or even mandatory 'report-all'. > >> > >> (*) == where 'trim' only applies to leafs containing > >> the YANG default-stmt value > >> ******************************************************************** > > > > The current text allows servers to do 'trim', 'explicit' or > > 'report-all'. I do not want to change that. > > > > > No it does not. Here is the proposed updated text on the leaf's default: 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. > You claim YANG supports 'explicit' type defaults filtering, > but there isn't any text in the draft to suggest this is true. The text above states that the default value is used if no value has been set. So 'explicit' is not filtering, since it just means that if no value has been set, nothing is returned. 'trim' is supported by the text in 7.6.5: A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. > There is no mention anywhere in the standard about > anything related to server-created vs. client-created. > Please point out which section in the draft specifies > this behavior. I have never said that the draft talks about server-created vs. client-created. Joel pointed out that we need to write text about it, or introduce something like assigned-by-system. /martin From mbj@tail-f.com Fri Aug 28 05:55: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 CE9083A7142 for ; Fri, 28 Aug 2009 05:55:38 -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 zpafoG06M3Ge for ; Fri, 28 Aug 2009 05:55:38 -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 1CCAE3A7139 for ; Fri, 28 Aug 2009 05:55: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 E284A616001; Fri, 28 Aug 2009 14:55:43 +0200 (CEST) Date: Fri, 28 Aug 2009 14:55:43 +0200 (CEST) Message-Id: <20090828.145543.230767018.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A97CAB5.3010205@netconfcentral.com> References: <200908271623.n7RGNfad024764@idle.juniper.net> <20090828.100321.220069022.mbj@tail-f.com> <4A97CAB5.3010205@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] identityref and XPath 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: Fri, 28 Aug 2009 12:55:38 -0000 Andy Bierman wrote: > I think a new function is the best way to go, > but Lada is correct that there are more types > than just identityref that embed XML prefixes into literals. > > - instance-identifier > - identityref It might make sense to be able to test these two types for equality, so maybe we should add: is-identity(node, str) is-instance-identifier(node, str) > - xpath1.0 (ietf-yang-types) Unless we have a mechanism for adding new XPath functions (hint, hint ;) then there will always be new types that cannot be compared properly with standard XPath. For this particular type, I don't think it is a problem that it cannot be compared. /martin From j.schoenwaelder@jacobs-university.de Fri Aug 28 06:19: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 5BB853A6A32 for ; Fri, 28 Aug 2009 06:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 i+Hv43uwmL9F for ; Fri, 28 Aug 2009 06:19:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E70383A6921 for ; Fri, 28 Aug 2009 06:17:48 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9914CC00DA; Fri, 28 Aug 2009 15:17:55 +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 H0srpxqPsH51; Fri, 28 Aug 2009 15:17:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 610EEC00C4; Fri, 28 Aug 2009 15:17:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E995CC81849; Fri, 28 Aug 2009 15:17:52 +0200 (CEST) Date: Fri, 28 Aug 2009 15:17:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090828131752.GB22962@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97CCDB.6090400@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A97CCDB.6090400@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 13:19:06 -0000 On Fri, Aug 28, 2009 at 02:26:03PM +0200, Andy Bierman wrote: > The operators at the NM workshop were fairly > clear about 3 types of data (config, state, > and statistics), although these terms are never defined in RFC 3535. > > Our model has 2 states (config=true/false). > > Maybe the model needs more work. This is what I believe. Since we do not really know how to relate operational state to config data, we are getting into trouble to deal with things like the MTU of an interface - which in most cases is really just operational state of an interface, but you can still configure it if there is a need (and in most cases you do not care). The same goes for the difference between /etc/sysctl.conf and sysctl -a. For debugging, I need sysctl -a and not so much sysctl.conf, which I like to keep short. (Sorry for those on Windows. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Fri Aug 28 06:54: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 2328528C349 for ; Fri, 28 Aug 2009 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.446, 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 GyRE0RqRQXuG for ; Fri, 28 Aug 2009 06:54:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0A10128C36A for ; Fri, 28 Aug 2009 06:52:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 459824301BF; Fri, 28 Aug 2009 06:53:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A58B44301B9; Fri, 28 Aug 2009 06:53:01 -0700 (PDT) Message-ID: <4A97E138.6090005@joelhalpern.com> Date: Fri, 28 Aug 2009 09:52:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> In-Reply-To: <20090828.102808.31895182.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Fri, 28 Aug 2009 13:54:07 -0000 (I am not sure how the text below from Martin relates to later notes from Martin, but I am sending my comments in case there is still an argument for non-instantiated dynamic defaults.) Assuming that the value (the dynamic default value) under discussion matters, defining a structure for the system in such a way that the managing application can not determine what the managed device is doing seems broken. There are multiple ways to define things that avoid such brokenness. We can define that the system just does not allow that (dynamic defaults). (I will admit that this seems unlike to be a good choice.) We can define that when the system uses such a value, it is effectively creating the node in the config. Given that the system inherently does know what value it is using, it can provide it. Or we can describe this "dynamic defaults" case, and say that it should be represented by having a pair of nodes, one config=true representing what has been configured and one config=false representing what the system has chosen to do. We can leave the relationship between these two to the description clause for new. Personally, it had never occurred to me that one would have invisible values in the controlling set of values. I was disagreeing with Andy about some things because I simply could not get my head around the description Martin provides below of a value that is set by the system, depending upon system situation / characteristics, but is not present in the observable set of information. Yours, Joel M. Halpern Martin Bjorklund wrote: ... > But a dynamic default means that it is a value that the server > operationally uses if the leaf *is not present in the config*. So > since it is not present in the config, the server will not return it > in a get-config. This does not mean that the server filters it out - > how can it filter out something that isn't even there? > ... From mbj@tail-f.com Fri Aug 28 07:05:14 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 4411D3A7153 for ; Fri, 28 Aug 2009 07:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 uo6Qzi1ayXuv for ; Fri, 28 Aug 2009 07:05:13 -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 2ED9328C3A8 for ; Fri, 28 Aug 2009 07:05:13 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2444D616001; Fri, 28 Aug 2009 16:05:19 +0200 (CEST) Date: Fri, 28 Aug 2009 16:05:18 +0200 (CEST) Message-Id: <20090828.160518.51777589.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A97E138.6090005@joelhalpern.com> References: <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97E138.6090005@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: [netmod] dynamic defaults (was: Configuration nodes) 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: Fri, 28 Aug 2009 14:05:14 -0000 Hi Joel, I think this is a good starting point for a discussion about dynamic defaults. As input to the discussion, consider this leaf from the IPFIX module: leaf sourceIpAddress { type inet:ip-address; must "../transportProtocol=udp"; description "Sets source IP address if UDP is transport protocol. If omitted, the IP address assigned to the outgoing interface is used."; } I think that this leaf matches my definition of dynamic default. Do we want to make this illegal in some way? Andy previously said that he did not want to make it illegal. If we look at Andy's 11 generic questions, in this particular case, they do not apply (it is not part of a must expression, no unique, and so on), so it does not seem harmful to have this leaf legal. /martin "Joel M. Halpern" wrote: > (I am not sure how the text below from Martin relates to later notes from > Martin, but I am sending my comments in case there is still an argument for > non-instantiated dynamic defaults.) > > Assuming that the value (the dynamic default value) under discussion matters, > defining a structure for the system in such a way that the managing application > can not determine what the managed device is doing seems broken. > > There are multiple ways to define things that avoid such brokenness. > > We can define that the system just does not allow that (dynamic defaults). (I > will admit that this seems unlike to be a good choice.) > > We can define that when the system uses such a value, it is effectively > creating the node in the config. Given that the system inherently does know > what value it is using, it can provide it. > > Or we can describe this "dynamic defaults" case, and say that it should be > represented by having a pair of nodes, one config=true representing what has > been configured and one config=false representing what the system has chosen to > do. We can leave the relationship between these two to the description clause > for new. > > Personally, it had never occurred to me that one would have invisible values in > the controlling set of values. I was disagreeing with Andy about some things > because I simply could not get my head around the description Martin provides > below of a value that is set by the system, depending upon system situation / > characteristics, but is not present in the observable set of information. > > Yours, > Joel M. Halpern > > Martin Bjorklund wrote: > ... > > But a dynamic default means that it is a value that the server > > operationally uses if the leaf *is not present in the config*. So > > since it is not present in the config, the server will not return it > > in a get-config. This does not mean that the server filters it out - > > how can it filter out something that isn't even there? > > > ... > From jmh@joelhalpern.com Fri Aug 28 07:20: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 BDFC63A6D1B for ; Fri, 28 Aug 2009 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=-0.441, 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 AYgKFEwlas5l for ; Fri, 28 Aug 2009 07:20:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D67FA3A6838 for ; Fri, 28 Aug 2009 07:20:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 193EF43020F; Fri, 28 Aug 2009 07:20:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 3E1144301FD; Fri, 28 Aug 2009 07:20:45 -0700 (PDT) Message-ID: <4A97E7B8.7000809@joelhalpern.com> Date: Fri, 28 Aug 2009 10:20:40 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97E138.6090005@joelhalpern.com> <20090828.160518.51777589.mbj@tail-f.com> In-Reply-To: <20090828.160518.51777589.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 14:20:39 -0000 The example you cite is crisply on the edge of the knife. I find the if_mtu example to be much clearer for understanding how to handle things. But, to use this example, I probably end up saying that it is permitted, but for a different reason than you want. I don't think that is actually a dynamic default at all. As far as I can tell, what that says is that when the packet is going to be sent, when the system finally decides what outgoing interface will be used, it will pick a source IP address that is suitable. The reason that that is not a dynamic default is that the semantics are such that I really can not ask the system "what value will you use for this" because the system really does not know. There is no "default" computed dynamically. There is an actual value used, when the time comes to use a value. To try to generalize this example, there probably are information items which conceptually have a value, and where the value can be set by an operator (a management application, a client), but where it is not meaningful to ask the system "what is the value for this" when one has not been set. That's fine. That means the system works without setting that value, and other parts of the system will do their job. (Heck, ping variants where the system is expected to pick a random value when it sends the message. I would not expect to be able to ask in advance "what random value will you pick?") In contrast, every interface really has to have an MTU. If one is not provided by the operator, then the system will have to pick one. Given that the system will pick one, the managing system has to be able to ask the question "what value did you pick." If the value is not being defined by a default clause, then when the system picks a value it MUST appear in the configuration or operational state data. Yours, Joel Martin Bjorklund wrote: > Hi Joel, > > I think this is a good starting point for a discussion about dynamic > defaults. > > As input to the discussion, consider this leaf from the IPFIX module: > > leaf sourceIpAddress { > type inet:ip-address; > must "../transportProtocol=udp"; > description "Sets source IP address if UDP is transport > protocol. If omitted, the IP address assigned to the > outgoing interface is used."; > } > > I think that this leaf matches my definition of dynamic default. Do > we want to make this illegal in some way? Andy previously said that > he did not want to make it illegal. > > If we look at Andy's 11 generic questions, in this particular case, > they do not apply (it is not part of a must expression, no unique, and > so on), so it does not seem harmful to have this leaf legal. > > > /martin > > > > "Joel M. Halpern" wrote: >> (I am not sure how the text below from Martin relates to later notes from >> Martin, but I am sending my comments in case there is still an argument for >> non-instantiated dynamic defaults.) >> >> Assuming that the value (the dynamic default value) under discussion matters, >> defining a structure for the system in such a way that the managing application >> can not determine what the managed device is doing seems broken. >> >> There are multiple ways to define things that avoid such brokenness. >> >> We can define that the system just does not allow that (dynamic defaults). (I >> will admit that this seems unlike to be a good choice.) >> >> We can define that when the system uses such a value, it is effectively >> creating the node in the config. Given that the system inherently does know >> what value it is using, it can provide it. >> >> Or we can describe this "dynamic defaults" case, and say that it should be >> represented by having a pair of nodes, one config=true representing what has >> been configured and one config=false representing what the system has chosen to >> do. We can leave the relationship between these two to the description clause >> for new. >> >> Personally, it had never occurred to me that one would have invisible values in >> the controlling set of values. I was disagreeing with Andy about some things >> because I simply could not get my head around the description Martin provides >> below of a value that is set by the system, depending upon system situation / >> characteristics, but is not present in the observable set of information. >> >> Yours, >> Joel M. Halpern >> >> Martin Bjorklund wrote: >> ... >>> But a dynamic default means that it is a value that the server >>> operationally uses if the leaf *is not present in the config*. So >>> since it is not present in the config, the server will not return it >>> in a get-config. This does not mean that the server filters it out - >>> how can it filter out something that isn't even there? >>> >> ... >> > From phil@juniper.net Fri Aug 28 07:29: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 EC4793A6B06 for ; Fri, 28 Aug 2009 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 G0tRWdbWQq9m for ; Fri, 28 Aug 2009 07:29:25 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id E8B643A6A39 for ; Fri, 28 Aug 2009 07:29:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSpfpxk4MP58Muh/PRfxd/AdaSYkEt3UH@postini.com; Fri, 28 Aug 2009 07:29:30 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; Fri, 28 Aug 2009 07:19: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); Fri, 28 Aug 2009 07:19:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:19:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:19: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 n7SEJcd62027; Fri, 28 Aug 2009 07:19: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 n7SE7beo034504; Fri, 28 Aug 2009 14:07:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908281407.n7SE7beo034504@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090828.100321.220069022.mbj@tail-f.com> Date: Fri, 28 Aug 2009 10:07:37 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 14:19:38.0574 (UTC) FILETIME=[939B4EE0:01CA27EA] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] identityref and XPath 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: Fri, 28 Aug 2009 14:29:26 -0000 Martin Bjorklund writes: >(and I don't believe you are right - the XPath spec clearly allows you >to define new functions, but it does not say anything about new types) XSLT defined the new type: http://www.w3.org/TR/xslt#section-Result-Tree-Fragments 11.1 Result Tree Fragments Variables introduce an additional data-type into the expression language. This additional data type is called result tree fragment. A variable may be bound to a result tree fragment instead of one of the four basic XPath data-types (string, number, boolean, node-set). A result tree fragment represents a fragment of the result tree. A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. .... I'm assuming that no one at w3c would contend that xslt is broken in it's use of xpath. I think this is a stable precedent that we can safely follow with risk of heresy. Thanks, Phil From phil@juniper.net Fri Aug 28 07:34: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 0436D3A6E24 for ; Fri, 28 Aug 2009 07:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 xsTJQbkUT+EM for ; Fri, 28 Aug 2009 07:34:23 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 506393A696B for ; Fri, 28 Aug 2009 07:34:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSpfq86tW0Vgx6ZXck9z+IqJzX8T8iI8e@postini.com; Fri, 28 Aug 2009 07:34:30 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; Fri, 28 Aug 2009 07:25:45 -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); Fri, 28 Aug 2009 07:25:45 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:25:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:25:44 -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 n7SEPhd64677; Fri, 28 Aug 2009 07:25:43 -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 n7SEDhUQ034548; Fri, 28 Aug 2009 14:13:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908281413.n7SEDhUQ034548@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A97CCDB.6090400@netconfcentral.com> Date: Fri, 28 Aug 2009 10:13:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 14:25:44.0196 (UTC) FILETIME=[6D88CC40:01CA27EB] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 14:34:24 -0000 Andy Bierman writes: >If the draft clearly defined exactly how an 'explicit' filter >is identified in YANG, and exactly how it affects the NETCONF >protocol, then it is not a problem because then it would be specified >in the standard. NETCONF does not have 'explicit' filters. YANG does not add them. What YANG says is: 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. This allows the server to either set leaf elements if the value is the default value (which the with-default draft calls explicit) or to choose not to send such elements (which the with-defaults draft calls trim). Thanks, Phil From saperia@jdscons.com Fri Aug 28 07:35: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 75A0128C1D5 for ; Fri, 28 Aug 2009 07:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 Scu+mDD5lNL4 for ; Fri, 28 Aug 2009 07:35:44 -0700 (PDT) Received: from rs40.luxsci.com (rs40.luxsci.com [65.61.166.82]) by core3.amsl.com (Postfix) with ESMTP id 74C1C3A6D1B for ; Fri, 28 Aug 2009 07:35:44 -0700 (PDT) Received: from [10.1.10.157] (75-150-72-14-NewEngland.hfc.comcastbusiness.net [75.150.72.14] (may be forged)) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id n7SEZn8o001920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 28 Aug 2009 09:35:49 -0500 Message-Id: From: Jon Saperia To: "Joel M. Halpern" In-Reply-To: <4A97E7B8.7000809@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 Aug 2009 10:35:49 -0400 References: <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97E138.6090005@joelhalpern.com> <20090828.160518.51777589.mbj@tail-f.com> <4A97E7B8.7000809@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 14:35:45 -0000 On Aug 28, 2009, at 10:20 AM, Joel M. Halpern wrote: > The example you cite is crisply on the edge of the knife. > I find the if_mtu example to be much clearer for understanding how > to handle things. > > But, to use this example, I probably end up saying that it is > permitted, but for a different reason than you want. I don't think > that is actually a dynamic default at all. > As far as I can tell, what that says is that when the packet is > going to be sent, when the system finally decides what outgoing > interface will be used, it will pick a source IP address that is > suitable. > The reason that that is not a dynamic default is that the semantics > are such that I really can not ask the system "what value will you > use for this" because the system really does not know. There is no > "default" computed dynamically. There is an actual value used, when > the time comes to use a value. > > To try to generalize this example, there probably are information > items which conceptually have a value, and where the value can be > set by an operator (a management application, a client), but where > it is not meaningful to ask the system "what is the value for this" > when one has not been set. That's fine. That means the system > works without setting that value, and other parts of the system will > do their job. (Heck, ping variants where the system is expected to > pick a random value when it sends the message. I would not expect > to be able to ask in advance "what random value will you pick?") > > In contrast, every interface really has to have an MTU. If one is > not provided by the operator, then the system will have to pick > one. Given that the system will pick one, the managing system has > to be able to ask the question "what value did you pick." If the > value is not being defined by a default clause, then when the system > picks a value it MUST appear in the configuration or operational > state data. Joel, this is an important part of what I was asking about. I am not sure how people would call it but it [the MTU in your example] must be retrievable from the system. /jon > > Yours, > Joel > > Martin Bjorklund wrote: >> Hi Joel, >> I think this is a good starting point for a discussion about dynamic >> defaults. As input to the discussion, consider this leaf from the >> IPFIX module: >> leaf sourceIpAddress { type inet:ip-address; must >> "../transportProtocol=udp"; >> description "Sets source IP address if UDP is >> transport protocol. If omitted, the IP address assigned to >> the >> outgoing interface is used."; >> } >> I think that this leaf matches my definition of dynamic default. Do >> we want to make this illegal in some way? Andy previously said that >> he did not want to make it illegal. >> If we look at Andy's 11 generic questions, in this particular case, >> they do not apply (it is not part of a must expression, no unique, >> and >> so on), so it does not seem harmful to have this leaf legal. >> /martin >> "Joel M. Halpern" wrote: >>> (I am not sure how the text below from Martin relates to later >>> notes from >>> Martin, but I am sending my comments in case there is still an >>> argument for >>> non-instantiated dynamic defaults.) >>> >>> Assuming that the value (the dynamic default value) under >>> discussion matters, >>> defining a structure for the system in such a way that the >>> managing application >>> can not determine what the managed device is doing seems broken. >>> >>> There are multiple ways to define things that avoid such brokenness. >>> >>> We can define that the system just does not allow that (dynamic >>> defaults). (I >>> will admit that this seems unlike to be a good choice.) >>> >>> We can define that when the system uses such a value, it is >>> effectively >>> creating the node in the config. Given that the system inherently >>> does know >>> what value it is using, it can provide it. >>> >>> Or we can describe this "dynamic defaults" case, and say that it >>> should be >>> represented by having a pair of nodes, one config=true >>> representing what has >>> been configured and one config=false representing what the system >>> has chosen to >>> do. We can leave the relationship between these two to the >>> description clause >>> for new. >>> >>> Personally, it had never occurred to me that one would have >>> invisible values in >>> the controlling set of values. I was disagreeing with Andy about >>> some things >>> because I simply could not get my head around the description >>> Martin provides >>> below of a value that is set by the system, depending upon system >>> situation / >>> characteristics, but is not present in the observable set of >>> information. >>> >>> Yours, >>> Joel M. Halpern >>> >>> Martin Bjorklund wrote: >>> ... >>>> But a dynamic default means that it is a value that the server >>>> operationally uses if the leaf *is not present in the config*. So >>>> since it is not present in the config, the server will not return >>>> it >>>> in a get-config. This does not mean that the server filters it >>>> out - >>>> how can it filter out something that isn't even there? >>>> >>> ... >>> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Fri Aug 28 07:46:17 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 7836C3A6AA1 for ; Fri, 28 Aug 2009 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.047, 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 oYuxHsvKJkXh for ; Fri, 28 Aug 2009 07:46: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 B4FAB3A6953 for ; Fri, 28 Aug 2009 07:46:16 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B6A2616001; Fri, 28 Aug 2009 16:46:23 +0200 (CEST) Date: Fri, 28 Aug 2009 16:46:23 +0200 (CEST) Message-Id: <20090828.164623.233098317.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A97E7B8.7000809@joelhalpern.com> References: <4A97E138.6090005@joelhalpern.com> <20090828.160518.51777589.mbj@tail-f.com> <4A97E7B8.7000809@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] dynamic defaults 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: Fri, 28 Aug 2009 14:46:17 -0000 Hi Joel, Here's another example that we have used before: leaf hold-time { mandatory true; type int32; } list group { key 'name'; leaf name { type string; } leaf hold-time { type int32; description "If not set, the value of ../../hold-time is used"; } } Would this (group/hold-time) be a dynamic default? Would it be legal? /martin From phil@juniper.net Fri Aug 28 08:01: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 EE39D28C3F9 for ; Fri, 28 Aug 2009 08:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, 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 bpRypOX+Zq9N for ; Fri, 28 Aug 2009 08:01:04 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 7990C28C3FF for ; Fri, 28 Aug 2009 08:01:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSpfxNBQ6s58oKy/W7YiVWEjhrawSuPyh@postini.com; Fri, 28 Aug 2009 08:01:11 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; Fri, 28 Aug 2009 07:56: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); Fri, 28 Aug 2009 07:56:38 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:56:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 07:56: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 n7SEuad78940; Fri, 28 Aug 2009 07:56: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 n7SEiY5D034906; Fri, 28 Aug 2009 14:44:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908281444.n7SEiY5D034906@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4A97E7B8.7000809@joelhalpern.com> Date: Fri, 28 Aug 2009 10:44:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 14:56:37.0294 (UTC) FILETIME=[BE111CE0:01CA27EF] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 15:01:05 -0000 "Joel M. Halpern" writes: >I would not expect to be able to ask in advance >"what random value will you pick?") Nor after ("what random value did you pick for my last ping?"). >In contrast, every interface really has to have an MTU. If one is not >provided by the operator, then the system will have to pick one. Given >that the system will pick one, the managing system has to be able to ask >the question "what value did you pick." If the value is not being >defined by a default clause, then when the system picks a value it MUST >appear in the configuration or operational state data. For MTU, the system chooses a value when the configuration does not specify one and no default in specified in the model. This value is not configuration data, since it doesn't persist and the hot plugging of a new interface may lead the system to choose a new value. So this "value in use" would clearly be operational data. We've traditionally said that operational data was the realm of the great and all-powerful operation, and left it at that. Currently, nothing is said about what returns or how it works except for the ominously all-powerful (and unwise) comment in NETCONF 7.7: Parameters: filter: This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is empty, all the device configuration and state information is returned. I hate to think of what such a operation would do to a fully-populated core router. But maybe it's time to start defining how works. Or to create a new (perhaps less contriversial) operation like that retrieves operational data for YANG modules. I would be against the "dual leaf" scheme, where "leaf mtu" requires a config=false twin "mtu-right-now", since this means twice the work with no relationship between the two leaves. On the other hand, the set of values supported by config and operational leafs may not be proper subsets. "auto" is a fine value for "duplex" for configuration data, but not for operational data. My question would be does this issue need sorted out now, or can we delay it and publish YANG as a solution for configuration data, since configuration data puts the CONF in NETCONF? Or are we required to boil all the oceans at once? Thanks, Phil From phil@juniper.net Fri Aug 28 08:10: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 55CD83A6E65 for ; Fri, 28 Aug 2009 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=-0.579, 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 lUo9YYnD5j7A for ; Fri, 28 Aug 2009 08:10:37 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id AEC8A3A6C81 for ; Fri, 28 Aug 2009 08:10:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSpfzcWxuttq2biYMyuDA8I158DU06o/i@postini.com; Fri, 28 Aug 2009 08:10:44 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; Fri, 28 Aug 2009 08:06:02 -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); Fri, 28 Aug 2009 08:06:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 08:06:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 08:06:01 -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 n7SF61d83437; Fri, 28 Aug 2009 08:06:01 -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 n7SEs14P035015; Fri, 28 Aug 2009 14:54:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908281454.n7SEs14P035015@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A978928.3070802@netconfcentral.com> Date: Fri, 28 Aug 2009 10:54:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 15:06:01.0962 (UTC) FILETIME=[0EA29CA0:01CA27F1] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 15:10:38 -0000 Andy Bierman writes: >then why do you think a node is config=false >if the server sets it but config=true if the >client set it? That is not specified >anywhere in the draft. Please let me know where I've said anything like this so I can correct myself. I have no recollection of saying anything to silly. >You want to take a huge step backward. No, I've developed something that people are actually using for automation in major ISPs every day. This is a huge step forward, and was not hindered at all by its CLI-like mechanism of handling defaults. This is the style that ISPs are used to. They like it and use it daily. I'm still trying to find a vendor that fully populates their user-visible configuration data with default values. I can't imagine operators sitting still for this. I work hard to make configuration data smaller, simpler, and better organized, so that users can see the important bits and are not distracted by the noise. A config populated with default values would be worthless. Hundreds of lines of stuff I don't care about? The first feature request will be to turn off default values. Thanks, Phil From andy@netconfcentral.com Fri Aug 28 08:14: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 643B43A6872 for ; Fri, 28 Aug 2009 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 zbfB5Rv4ymyD for ; Fri, 28 Aug 2009 08:14: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 844503A659C for ; Fri, 28 Aug 2009 08:14:07 -0700 (PDT) Received: (qmail 96788 invoked from network); 28 Aug 2009 15:14:12 -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; 28 Aug 2009 15:14:12 -0000 X-YMail-OSG: i8NSR8cVM1mSEqDArh2VUHBPSSkPBgN6tZjAzTcUiAbu3DOD0lyGo.9uimuLLJCLom70E4r0msVOPqB_A_csCWn2AysArO3CEIOFOB_zhoTmpSQeLNDdqzTRV9gfxl2mHw1QjZdq0O366Dih26eausiZNei4SrXYOCgISPGupQiNLBpmaaEBgCD7q_V6GOAZjjp5EcptNJ.ABaba4zIu.syZk1IEQ66wsXaekOQ_EM8rf0ubpNp30lEvCRzP3yZX3gfQ22iTmzWse5a7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97F44C.7040700@netconfcentral.com> Date: Fri, 28 Aug 2009 08:14:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908281413.n7SEDhUQ034548@idle.juniper.net> In-Reply-To: <200908281413.n7SEDhUQ034548@idle.juniper.net> 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: Fri, 28 Aug 2009 15:14:08 -0000 Phil Shafer wrote: > Andy Bierman writes: >> If the draft clearly defined exactly how an 'explicit' filter >> is identified in YANG, and exactly how it affects the NETCONF >> protocol, then it is not a problem because then it would be specified >> in the standard. > > NETCONF does not have 'explicit' filters. YANG does not add > them. What YANG says is: > > 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. > > This allows the server to either set leaf elements if the value is > the default value (which the with-default draft calls explicit) or > to choose not to send such elements (which the with-defaults draft > calls trim). I already agree that a server does not have to send a leaf when it is set to its default value. YANG defines that to be to value in the default-stmt. Now that we agree what YANG supports, we can move on right? The text you quoted supports MY case, not yours. The text above ONLY refers to the YANG default-stmt. Leafs that are equal to the YANG default-stmt are defaults. If we write YANG DEFAULT-STMT, will that be any clearer to you? > > Thanks, > Phil > Andy From lhotka@cesnet.cz Fri Aug 28 08:15: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 526143A6E10 for ; Fri, 28 Aug 2009 08:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=0.066, 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 3V5BxkT8wx+v for ; Fri, 28 Aug 2009 08:15:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 340FC3A6872 for ; Fri, 28 Aug 2009 08:15:49 -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 721FFD80096; Fri, 28 Aug 2009 17:15:55 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200908281407.n7SE7beo034504@idle.juniper.net> References: <200908281407.n7SE7beo034504@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 28 Aug 2009 17:15:53 +0200 Message-Id: <1251472553.26144.129.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] identityref and XPath 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: Fri, 28 Aug 2009 15:15:50 -0000 Phil Shafer píše v Pá 28. 08. 2009 v 10:07 -0400: > Martin Bjorklund writes: > >(and I don't believe you are right - the XPath spec clearly allows you > >to define new functions, but it does not say anything about new types) > > XSLT defined the new type: Well, you can assign a result tree fragment (RTF) to a XSLT variable. But if you want to use RTF in XPath expressions in a sensible way (i.e. not as a string), you have to use an extension function - for instance, exsl:node-set from EXSLT makes a nodeset out of RTF. BTW, result tree fragments are gone in XPath 2.0. But this is IMO not that important. We can of course extend and redefine XPath 1.0 in any way, provided the definition is sound and complete. This could serve well human readers of YANG modules that implement the constraints directly in their code. However, from the viewpoint of automated validation using off-the-shelf tools, there are three levels of compatibility: 1. YANG XPath expressions are directly usable, or after a transformation. This is what we have now and that's why the mapping to Schematron works out of the box (except for instance-identifier type, which also needs an extension function). 2. YANG XPath expressions use extension functions. Such extensions have to be implemented in every XPath processor we want to use. This is extra work but there is usually a well documented API. 3. Everything else requires substantial rewrite and the benefit of an off-the-shelf tool is essentially lost. Lada > > http://www.w3.org/TR/xslt#section-Result-Tree-Fragments > > 11.1 Result Tree Fragments > > Variables introduce an additional data-type into the expression > language. This additional data type is called result tree > fragment. A variable may be bound to a result tree fragment > instead of one of the four basic XPath data-types (string, > number, boolean, node-set). A result tree fragment represents > a fragment of the result tree. A result tree fragment is treated > equivalently to a node-set that contains just a single root > node. However, the operations permitted on a result tree fragment > are a subset of those permitted on a node-set. .... > > I'm assuming that no one at w3c would contend that xslt is broken > in it's use of xpath. I think this is a stable precedent that > we can safely follow with risk of heresy. > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Fri Aug 28 08:23: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 2ED273A6D2E for ; Fri, 28 Aug 2009 08:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 SQfWJuAoDBPG for ; Fri, 28 Aug 2009 08:23: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 EF0D13A6ABA for ; Fri, 28 Aug 2009 08:22:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C3F5430236; Fri, 28 Aug 2009 08:22:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7288643020D; Fri, 28 Aug 2009 08:22:47 -0700 (PDT) Message-ID: <4A97F642.2050704@joelhalpern.com> Date: Fri, 28 Aug 2009 11:22:42 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <4A97E138.6090005@joelhalpern.com> <20090828.160518.51777589.mbj@tail-f.com> <4A97E7B8.7000809@joelhalpern.com> <20090828.164623.233098317.mbj@tail-f.com> In-Reply-To: <20090828.164623.233098317.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 15:23:37 -0000 Yes it is legal. I would suggest calling the second hold-time "configured-hold-time", largely to avoid naming confusion for humans (but clearly that naming change is irrelevant to the question at hand.) There is an operational subtlety which affects what the model needs to represent. At t0 the hold-time mandatory leaf is 10. A group is created, an entry, with a name, and no hold time. So it uses 10 as its hold time. Now, if someone changes the mandatory leaf value to 20, does the hold time for the entry change? If yes, then what we have is an unrepresented semantic relationship, which is inevitable some of the time. If the answer is no, then we have different situation. If the hold time for a group element is actually set by the system when the entry is created, and is set to the then-current mandatory hold-time, and does not track the other value, then the system is really creating the hold-time in the group list. If so, when I get that entry later, it better come back with the actual value that the system is using for that entry. And I can not tell from your description clause which of the two cases you intend. Which relates to the problem that some folks will always write bad models, no matter what we tell them. But we have to give them enough information in the standard that they have a hope of writing good ones. Yes, I think we need to figure out what we mean, and say it clearly. Otherwise, the odds are that folks will do the wrong thing. It is unfortunate but absolutely inevitable that sometimes tool writers will have to look at the real semantics, not just the semantics represented by the YANG, and write code for that. We should not willfully create cases where that has to happen. But we should not pretend we can completely avoid it either. Yours, Joel Martin Bjorklund wrote: > Hi Joel, > > Here's another example that we have used before: > > leaf hold-time { > mandatory true; > type int32; > } > list group { > key 'name'; > leaf name { > type string; > } > leaf hold-time { > type int32; > description > "If not set, the value of ../../hold-time is used"; > } > } > > Would this (group/hold-time) be a dynamic default? Would it be legal? > > > /martin > From mbj@tail-f.com Fri Aug 28 08:32: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 E5FE428C3A2 for ; Fri, 28 Aug 2009 08:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.046, 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 Z+C0IovrV9Es for ; Fri, 28 Aug 2009 08:32:04 -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 EC57E28C374 for ; Fri, 28 Aug 2009 08:32:03 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A8896616001; Fri, 28 Aug 2009 17:32:09 +0200 (CEST) Date: Fri, 28 Aug 2009 17:32:09 +0200 (CEST) Message-Id: <20090828.173209.86493688.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A97F642.2050704@joelhalpern.com> References: <4A97E7B8.7000809@joelhalpern.com> <20090828.164623.233098317.mbj@tail-f.com> <4A97F642.2050704@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] dynamic defaults 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: Fri, 28 Aug 2009 15:32:05 -0000 "Joel M. Halpern" wrote: > Yes it is legal. > There is an operational subtlety which affects what the model needs to > represent. > At t0 the hold-time mandatory leaf is 10. > A group is created, an entry, with a name, and no hold time. > So it uses 10 as its hold time. > > Now, if someone changes the mandatory leaf value to 20, does the hold time for > the entry change? If yes, then what we have is an unrepresented semantic > relationship, which is inevitable some of the time. > If the answer is no, then we have different situation. If the hold time for a > group element is actually set by the system when the entry is created, and is > set to the then-current mandatory hold-time, and does not track the other > value, then the system is really creating the hold-time in the group list. If > so, when I get that entry later, it better come back with the actual value that > the system is using for that entry. > > And I can not tell from your description clause which of the two cases you > intend. I intended the first case. So would you call this a dynamic default? Could you provide an example of something that you would like to make illegal. I am trying to understand what sort of changes - if any - we need to do to the YANG draft. From you latest emails, it seems as if the problem is more on the designer of the data model. /martin From jmh@joelhalpern.com Fri Aug 28 08:45: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 0EAF73A6C25 for ; Fri, 28 Aug 2009 08:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 I99bpFutMO2U for ; Fri, 28 Aug 2009 08:45:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2A6233A6840 for ; Fri, 28 Aug 2009 08:45:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 69613430235; Fri, 28 Aug 2009 08:45:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B5ED643024C; Fri, 28 Aug 2009 08:45:32 -0700 (PDT) Message-ID: <4A97FB97.8030805@joelhalpern.com> Date: Fri, 28 Aug 2009 11:45:27 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <4A97E7B8.7000809@joelhalpern.com> <20090828.164623.233098317.mbj@tail-f.com> <4A97F642.2050704@joelhalpern.com> <20090828.173209.86493688.mbj@tail-f.com> In-Reply-To: <20090828.173209.86493688.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 15:45:27 -0000 The case I would make illegal is any case where the system uses a value for a node if one is not specified that value is not the default value for the node that value is not simply a dynamic reference to the current value of some other well defined node and that value can not be accessed by fetching the node itself. In other words, if the value is not set, and the system is using well defined value (not one generated at need and discarded), then there has to be a reasonable way to get that value. Reasonable ways include the default statement, and a tractable, even if defined in the description clause, reference to another node. Or getting that node itself. (If we want to complicate our life, we could define a default-reference statement which had a leafref to where that linked default comes from. But that is something we can consider for later.) So, the illegal list includes the second interpretation of your case. It also includes the if_mtu when the system sets an "appropriate" mtu if one is not provided. Yours, Joel Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> Yes it is legal. > >> There is an operational subtlety which affects what the model needs to >> represent. >> At t0 the hold-time mandatory leaf is 10. >> A group is created, an entry, with a name, and no hold time. >> So it uses 10 as its hold time. >> >> Now, if someone changes the mandatory leaf value to 20, does the hold time for >> the entry change? If yes, then what we have is an unrepresented semantic >> relationship, which is inevitable some of the time. >> If the answer is no, then we have different situation. If the hold time for a >> group element is actually set by the system when the entry is created, and is >> set to the then-current mandatory hold-time, and does not track the other >> value, then the system is really creating the hold-time in the group list. If >> so, when I get that entry later, it better come back with the actual value that >> the system is using for that entry. >> >> And I can not tell from your description clause which of the two cases you >> intend. > > I intended the first case. > > So would you call this a dynamic default? > > Could you provide an example of something that you would like to make > illegal. > > I am trying to understand what sort of changes - if any - we need to > do to the YANG draft. From you latest emails, it seems as if the > problem is more on the designer of the data model. > > > /martin > From andy@netconfcentral.com Fri Aug 28 08:45: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 802AB28C3B2 for ; Fri, 28 Aug 2009 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 5AhYWN0DH5YM for ; Fri, 28 Aug 2009 08:45:38 -0700 (PDT) Received: from n13a.bullet.mail.mud.yahoo.com (n13a.bullet.mail.mud.yahoo.com [68.142.207.51]) by core3.amsl.com (Postfix) with SMTP id 98CAF28C389 for ; Fri, 28 Aug 2009 08:45:38 -0700 (PDT) Received: from [209.191.108.96] by n13.bullet.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 15:45:43 -0000 Received: from [68.142.201.65] by t3.bullet.mud.yahoo.com with NNFMP; 28 Aug 2009 15:45:43 -0000 Received: from [127.0.0.1] by omp417.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 15:45:43 -0000 X-Yahoo-Newman-Id: 658982.52754.bm@omp417.mail.mud.yahoo.com Received: (qmail 30574 invoked from network); 28 Aug 2009 15:45:43 -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; 28 Aug 2009 15:45:43 -0000 X-YMail-OSG: AA.PWGsVM1kFWOB2tw1N45f2wSJN6TJ8ZIGJD0ajEDnecrXzCIbUpT8MR5MBjRywS5.V0V6pmI7Oww2sj_x65QaQvb7hNbFr.TZWfldWCH6MLkD4cKGJ0txZy08UzIR_Z9gA3fGQkaLq3gGFuq.fpazv45l9wp7Ufxdnd3r.MaqysggUiIy3J9Vmlkcd_KSrp2tzSfEOUfqU9p1ShBTwwvxHPQpa7zoMBD4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97FBAF.5080200@netconfcentral.com> Date: Fri, 28 Aug 2009 08:45:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97CCDB.6090400@netconfcentral.com> <20090828131752.GB22962@elstar.local> In-Reply-To: <20090828131752.GB22962@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 28 Aug 2009 15:45:39 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 28, 2009 at 02:26:03PM +0200, Andy Bierman wrote: > >> The operators at the NM workshop were fairly >> clear about 3 types of data (config, state, >> and statistics), although these terms are never defined in RFC 3535. >> >> Our model has 2 states (config=true/false). >> >> Maybe the model needs more work. > > This is what I believe. Since we do not really know how to relate > operational state to config data, we are getting into trouble to deal > with things like the MTU of an interface - which in most cases is > really just operational state of an interface, but you can still > configure it if there is a need (and in most cases you do not care). > The same goes for the difference between /etc/sysctl.conf and sysctl > -a. For debugging, I need sysctl -a and not so much sysctl.conf, which > I like to keep short. (Sorry for those on Windows. ;-) > There is no support in YANG for a node that changes back and forth between config=true and false. Since the get and get-config filters are tied to the YANG config-stmt, this would impact the protocol behavior. YANG has no concept of a node that never needs to be retrieved unless some client session in the past has already explicitly set the node (possibly to the same value it already had). I think Joel, myself and others are saying, "Ifa leaf instance has a value other than its YANG default-stmt value, then it MUST be retrievable." Working backwards a little bit, why do we want this new classification? What protocol operations are we trying to support? Is it just with-defaults=explicit (returning only the leafs already set by some client)? Because this violates the 'must-be-retrievable' requirement for leafs not equal to the YANG default-stmt value. What benefit does the YANG data modeler get out of a new classification? Same question for the operator? > /js > Andy From andy@netconfcentral.com Fri Aug 28 09:07: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 ED32F3A7122 for ; Fri, 28 Aug 2009 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 q9HfwCKNli8j for ; Fri, 28 Aug 2009 09:07:06 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 189043A700A for ; Fri, 28 Aug 2009 09:07:05 -0700 (PDT) Received: (qmail 38985 invoked from network); 28 Aug 2009 16:07:10 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2009 16:07:10 -0000 X-YMail-OSG: X1PfyZYVM1kreUFj5sD5lmQFKrYsLDy1l2tzepx5MResv7K7IFbhgNdghu9EO20HxkOeccWIHyffqIQVLW6uTwF9yU2tdcaiIVO6JQFMigpF2xay2ssO6r7s1dyyBx3L7xGLywZGxlNBXRtcv3.KnY3kCRn4SvkAKzFm2vfRUMCGWIQVecm9__ldS6jtc0oH5jrsv7cS.TNhRk8hdhW_5GJwKmn7_XJ_87XkZXePkXpiALtbiV.zDTkmDoF.FGWyvZIp0bSSpAZz4GcP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9800B7.1060408@netconfcentral.com> Date: Fri, 28 Aug 2009 09:07:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A97E7B8.7000809@joelhalpern.com> <20090828.164623.233098317.mbj@tail-f.com> <4A97F642.2050704@joelhalpern.com> <20090828.173209.86493688.mbj@tail-f.com> <4A97FB97.8030805@joelhalpern.com> In-Reply-To: <4A97FB97.8030805@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 16:07:07 -0000 Joel M. Halpern wrote: > The case I would make illegal is any case where > the system uses a value for a node if one is not specified > that value is not the default value for the node > that value is not simply a dynamic reference to the current value of > some other well defined node > and that value can not be accessed by fetching the node itself. > > In other words, if the value is not set, and the system is using well > defined value (not one generated at need and discarded), then there has > to be a reasonable way to get that value. Reasonable ways include the > default statement, and a tractable, even if defined in the description > clause, reference to another node. Or getting that node itself. > (If we want to complicate our life, we could define a default-reference > statement which had a leafref to where that linked default comes from. > But that is something we can consider for later.) > I find this to be much less operationally useful than the standards-value level we have already achieved with data retrieval through SNMP. There is no way to ever enforce the concept: 'defined in the description clause'. As somebody who has spent so many years authoring and reviewing MIB modules, I should be happy with all the trust and faith you people are showing in external out-of-band user documentation. In my experience of writing DESCRIPTION clauses and implementing SNMP agents, the description clause is rarely complete, and often plain wrong about some detail or another. It sounds like you want standards-based application programming programmers to stop relying on the operational data the program receives via protocol retrieval from the exact server instance that is being managed, and instead write software that parses and analyzes description clauses, written to cover every instance of every server implementation. Even though the documentation may be wrong, incomplete, and the server may have bugs as well. I am not as trusting as you. All non-trivial programs have bugs in them. All non-trivial user manuals have bugs in them. Just assuming this cannot happen is a non-starter. > So, the illegal list includes the second interpretation of your case. It > also includes the if_mtu when the system sets an "appropriate" mtu if > one is not provided. > > Yours, > Joel > Andy From andy@netconfcentral.com Fri Aug 28 09:28: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 1BC553A711A for ; Fri, 28 Aug 2009 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 4PBhqEAdWroC for ; Fri, 28 Aug 2009 09:28:44 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id DF61B3A714D for ; Fri, 28 Aug 2009 09:28:37 -0700 (PDT) Received: (qmail 40990 invoked from network); 28 Aug 2009 16:28:45 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2009 16:28:44 -0000 X-YMail-OSG: .8gEyUEVM1kcf3kK7LGJoYwAzS46bUVyspMx.WFt5nvU4J2y.CKXqoqxVp8KC3GMdP8lipbFHxUc6w1Io.j8dHfKU.dbkxR4ADVqgIAWJ9QQSePI2veX5qL0gDaCyLgdZcNSJivv2q4978O3W2eWlUlXEYFE.Dv6llCuqGzk1lFuH1IUl.V4BpAA2EVVXbWZngBuvqDP56D8_CVkRnzSdztBClSBgK6PHeRq72ZnFXM6O.wUyKlYLd6fN.eGMANMD7KArJbbsTRkzp9e X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9805C5.1010406@netconfcentral.com> Date: Fri, 28 Aug 2009 09:28:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4A97E7B8.7000809@joelhalpern.com> <20090828.164623.233098317.mbj@tail-f.com> <4A97F642.2050704@joelhalpern.com> <20090828.173209.86493688.mbj@tail-f.com> <4A97FB97.8030805@joelhalpern.com> In-Reply-To: <4A97FB97.8030805@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 16:28:45 -0000 Hi Joel, The most important reason that data retrieval within the protocol is so important is that server implementations will vary from the documentation in unpredictable ways, over time. Even for a vendor MIB, the longer a MIB module has been published, the more platforms have implemented it in slightly different ways. There may be valid reasons, such as more HW/system resources to consider than the generalized DESCRIPTION clause considers, or new HW/protocols/etc. that make the DESCRIPTION clause obsolete for that platform with that HW installed. Often, there is no valid reason, just lazy programming or an honest mistake. But the motive for the bug makes no difference to the client. Within no time at all, the DESCRIPTION clause is hopelessly incomplete, and it will stay that way. There is no reason to believe that NETCONF server implementations and YANG description statements will be any different. Andy From j.schoenwaelder@jacobs-university.de Fri Aug 28 09:30: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 70D733A6840 for ; Fri, 28 Aug 2009 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zodi7VbtKHlg for ; Fri, 28 Aug 2009 09:30:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E32E63A6F8E for ; Fri, 28 Aug 2009 09:30:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99886C00C4; Fri, 28 Aug 2009 18:30:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eyvyOWjOjzv0; Fri, 28 Aug 2009 18:30:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EB70C00DA; Fri, 28 Aug 2009 18:30:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A2C9AC81C1A; Fri, 28 Aug 2009 18:30:09 +0200 (CEST) Date: Fri, 28 Aug 2009 18:30:09 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090828163009.GB23097@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97CCDB.6090400@netconfcentral.com> <20090828131752.GB22962@elstar.local> <4A97FBAF.5080200@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A97FBAF.5080200@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:30:07 -0000 On Fri, Aug 28, 2009 at 05:45:51PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Aug 28, 2009 at 02:26:03PM +0200, Andy Bierman wrote: > > > >> The operators at the NM workshop were fairly > >> clear about 3 types of data (config, state, > >> and statistics), although these terms are never defined in RFC 3535. > >> > >> Our model has 2 states (config=true/false). > >> > >> Maybe the model needs more work. > > > > This is what I believe. Since we do not really know how to relate > > operational state to config data, we are getting into trouble to deal > > with things like the MTU of an interface - which in most cases is > > really just operational state of an interface, but you can still > > configure it if there is a need (and in most cases you do not care). > > The same goes for the difference between /etc/sysctl.conf and sysctl > > -a. For debugging, I need sysctl -a and not so much sysctl.conf, which > > I like to keep short. (Sorry for those on Windows. ;-) > > > > There is no support in YANG for a node that > changes back and forth between config=true and false. > Since the get and get-config filters are tied to > the YANG config-stmt, this would impact the protocol > behavior. Did I say this anywhere? I said "we do not really know how to relate operational state to config data". Some people believe this can be solved by making all "relevant" operational state data config data. I doubt this works. Think of IP routing tables that contain configured routes and OSPF routes - how does the data model for this look like? Think about 802.1 bridges with learned and statically configured forwarding base entries. We have this all over the place and right now we have no receipe how to deal with this. While we could duplicate all definitions (config=true and config=false), I doubt that this solution will scale well. > YANG has no concept of a node that never needs to be > retrieved unless some client session in the past has > already explicitly set the node (possibly to the same > value it already had). A config node that does not exist just does not exist. Still operational state can exist that determines the behaviour of a device. Why is it so complicated to see the difference? > Because this violates the 'must-be-retrievable' requirement > for leafs not equal to the YANG default-stmt value. > What benefit does the YANG data modeler get out of a > new classification? Same question for the operator? I find the if (value == default_value) skip; logic not convincing. I am clearly with Phil here. If a client configures a value, it is part of the config regardless of the value configured. But we are not making any progress here. /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 Fri Aug 28 09:57: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 D86DF3A6EF3 for ; Fri, 28 Aug 2009 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 b85K-XWKFM5P for ; Fri, 28 Aug 2009 09:57: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 ECCC03A6961 for ; Fri, 28 Aug 2009 09:56:59 -0700 (PDT) Received: (qmail 17624 invoked from network); 28 Aug 2009 16:57:05 -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; 28 Aug 2009 16:57:04 -0000 X-YMail-OSG: tb0bC54VM1mVlKYJD.liDfo3uJyElV4SR3jZS5ySutyECShPRZyhJrBBT4_gMcXDW8iCcMRFHHcAIKMxparXL2daqFTNWO23dF5S_Xa.BfFzIBsoZRupGoL4BnonEYeX1ggbdjzcwc7Gi6yg.QbeshyQy0TvQfmmdl632B.uP4hoOMuIYk3uI1Z5j3SJQRWWVxEePSzqEJ8hGobiTZtNKE8vm5c5VGoTjWJX__d4wzdTgaVg4LFKU7ndWU4pM9X88IjjLVdv6iOUUOpE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A980C69.4090702@netconfcentral.com> Date: Fri, 28 Aug 2009 09:57:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97CCDB.6090400@netconfcentral.com> <20090828131752.GB22962@elstar.local> <4A97FBAF.5080200@netconfcentral.com> <20090828163009.GB23097@elstar.local> In-Reply-To: <20090828163009.GB23097@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 28 Aug 2009 16:57:00 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 28, 2009 at 05:45:51PM +0200, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Aug 28, 2009 at 02:26:03PM +0200, Andy Bierman wrote: >>> >>>> The operators at the NM workshop were fairly >>>> clear about 3 types of data (config, state, >>>> and statistics), although these terms are never defined in RFC 3535. >>>> >>>> Our model has 2 states (config=true/false). >>>> >>>> Maybe the model needs more work. >>> This is what I believe. Since we do not really know how to relate >>> operational state to config data, we are getting into trouble to deal >>> with things like the MTU of an interface - which in most cases is >>> really just operational state of an interface, but you can still >>> configure it if there is a need (and in most cases you do not care). >>> The same goes for the difference between /etc/sysctl.conf and sysctl >>> -a. For debugging, I need sysctl -a and not so much sysctl.conf, which >>> I like to keep short. (Sorry for those on Windows. ;-) >>> >> There is no support in YANG for a node that >> changes back and forth between config=true and false. >> Since the get and get-config filters are tied to >> the YANG config-stmt, this would impact the protocol >> behavior. > > Did I say this anywhere? I said "we do not really know how to relate > operational state to config data". Some people believe this can be > solved by making all "relevant" operational state data config data. I > doubt this works. Think of IP routing tables that contain configured > routes and OSPF routes - how does the data model for this look like? > Think about 802.1 bridges with learned and statically configured > forwarding base entries. We have this all over the place and right now > we have no receipe how to deal with this. While we could duplicate all > definitions (config=true and config=false), I doubt that this solution > will scale well. > The oper/admin status or static/learned route semantics are done in pairs, to avoid the 3rd state you are trying to formulate. Or there is an ad-hoc boolean leaf in the data model to tell them apart. E.g., the static routes are clearly configuration, and can be mixed with the learned routes added by the server. The client and server know in an ad-hoc manner which will be saved in NV-storage and which will not. I think you are on the right track for a robust solution, which is to codify this in a database property somehow. IMO, this has to be a complete model, that does not contain any gaps. >> YANG has no concept of a node that never needs to be >> retrieved unless some client session in the past has >> already explicitly set the node (possibly to the same >> value it already had). > > A config node that does not exist just does not exist. Still > operational state can exist that determines the behaviour of a > device. Why is it so complicated to see the difference? > I agree with you, but I consider a configuration object to be a node in which a client can directly alter the value. An instance of a configuration object can be created by either the server or the client. But even if the server sets the leaf first, it is still config. I don't like the with-defaults=explicit at all, because it assumes the description statement is complete and correct. I also don't like any data retrieval filtering mechanism unless the client initiates and controls the filtering. >> Because this violates the 'must-be-retrievable' requirement >> for leafs not equal to the YANG default-stmt value. >> What benefit does the YANG data modeler get out of a >> new classification? Same question for the operator? > > I find the > > if (value == default_value) skip; > > logic not convincing. I am clearly with Phil here. If a client > configures a value, it is part of the config regardless of the value > configured. > > But we are not making any progress here. > > /js > Andy From phil@juniper.net Fri Aug 28 10:19: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 49BCB3A6BC7 for ; Fri, 28 Aug 2009 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_64=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 hHzqb2wxdaOq for ; Fri, 28 Aug 2009 10:19:17 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 535593A68F0 for ; Fri, 28 Aug 2009 10:19:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSpgRl+EbEKkCe5Kg3MA8AmhirrssNTl4@postini.com; Fri, 28 Aug 2009 10:19: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; Fri, 28 Aug 2009 10:12: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); Fri, 28 Aug 2009 10:12:24 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:12:24 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:12: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 n7SHCNd46169; Fri, 28 Aug 2009 10:12: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 n7SH0Moa036246; Fri, 28 Aug 2009 17:00:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908281700.n7SH0Moa036246@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A980C69.4090702@netconfcentral.com> Date: Fri, 28 Aug 2009 13:00:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 17:12:23.0539 (UTC) FILETIME=[B59B7430:01CA2802] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 17:19:18 -0000 Andy Bierman writes: >> On Fri, Aug 28, 2009 at 05:45:51PM +0200, Andy Bierman wrote: >>> There is no support in YANG for a node that >>> changes back and forth between config=true and false. >>> Since the get and get-config filters are tied to >>> the YANG config-stmt, this would impact the protocol >>> behavior. Joel pointed out that my words could have been confusing you. I in no way am talking about a leaf that "changes back and forth between config=true and false". Consider this example: the "mtu" leaf is configuration data. If it's set to a value, that value is part of the configuration data. If it is not set, the system will use a value for that leaf, but not set it in the configuration database. We currently lack a mechanism for retrieving this "mtu-right-now" value, but I am not proposing the the "mtu" leaf fade in and out of "config=true"-ness. >I don't like the with-defaults=explicit at all, >because it assumes the description statement is complete and correct. I don't follow this linkage at all. Keeping explicitly created values for configuration data is not linked with description statements. This can be implemented for modules that don't contain any description statements at all. Thanks, Phil From phil@juniper.net Fri Aug 28 10:24: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 D5C633A67E9 for ; Fri, 28 Aug 2009 10:24:31 -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 alqPsNhk6QLv for ; Fri, 28 Aug 2009 10:24:31 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 339823A6963 for ; Fri, 28 Aug 2009 10:24:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSpgS0y6bNNaE6b3TN6CqnEjTS/b164vN@postini.com; Fri, 28 Aug 2009 10:24:38 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; Fri, 28 Aug 2009 10:17:00 -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); Fri, 28 Aug 2009 10:17:00 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:17:00 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:16:59 -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 n7SHGwd48520; Fri, 28 Aug 2009 10:16: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 n7SH4wZX036296; Fri, 28 Aug 2009 17:04:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908281704.n7SH4wZX036296@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A97F44C.7040700@netconfcentral.com> Date: Fri, 28 Aug 2009 13:04:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 17:16:59.0527 (UTC) FILETIME=[5A1BE170:01CA2803] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 17:24:31 -0000 Andy Bierman writes: >Phil Shafer wrote: >> Andy Bierman writes: >>> If the draft clearly defined exactly how an 'explicit' filter >>> is identified in YANG, and exactly how it affects the NETCONF >>> protocol, then it is not a problem because then it would be specified >>> in the standard. >> >> NETCONF does not have 'explicit' filters. YANG does not add >> them. What YANG says is: >> >> 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. >> >> This allows the server to either set leaf elements if the value is >> the default value (which the with-default draft calls explicit) or >> to choose not to send such elements (which the with-defaults draft >> calls trim). > > >I already agree that a server does not have to send a leaf >when it is set to its default value. YANG defines that to >be to value in the default-stmt. But YANG also allows me to record that a leaf was set to a value and return that value even if it is the default value. If the default value is "3" and the user sets it to "3", then I will still have "3" in my configuration database and will return it if an app fetches my configuration data. If the value is not set explicitly, then I will return nothing. This behavior is permitted under the YANG spec. Thanks, Phil From andy@netconfcentral.com Fri Aug 28 10:39: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 4F49A3A6E29 for ; Fri, 28 Aug 2009 10:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 0UtGMYDBFc8B for ; Fri, 28 Aug 2009 10:39:49 -0700 (PDT) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by core3.amsl.com (Postfix) with SMTP id 67B163A6DE6 for ; Fri, 28 Aug 2009 10:39:49 -0700 (PDT) Received: from [68.142.200.224] by n13.bullet.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 17:39:54 -0000 Received: from [68.142.201.242] by t5.bullet.mud.yahoo.com with NNFMP; 28 Aug 2009 17:39:54 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 17:39:54 -0000 X-Yahoo-Newman-Id: 645084.41670.bm@omp403.mail.mud.yahoo.com Received: (qmail 81832 invoked from network); 28 Aug 2009 17:39:54 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 28 Aug 2009 17:39:53 -0000 X-YMail-OSG: t.Y8_dEVM1nU0AH12IRKyBehiH3frF2TDaAzp6RWAI.Za2dPkUV6M9LMo8MuDkyZM69UPGK9oOue6HIDx.TeORN9lS82xuP4nsxM82WOgnALlDYPSBD0OnwErWBMh9NQ6_O_KG88wmgqzhjClQ3Qk9GXL3HGn9xxV2ueBwvmto2lIZv0hTkE6nKXMIxFwhpW1ZA.QA75J9KHRgA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9815FA.9060306@netconfcentral.com> Date: Fri, 28 Aug 2009 10:38:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908281700.n7SH0Moa036246@idle.juniper.net> In-Reply-To: <200908281700.n7SH0Moa036246@idle.juniper.net> 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: Fri, 28 Aug 2009 17:39:50 -0000 Phil Shafer wrote: > Andy Bierman writes: >>> On Fri, Aug 28, 2009 at 05:45:51PM +0200, Andy Bierman wrote: >>>> There is no support in YANG for a node that >>>> changes back and forth between config=true and false. >>>> Since the get and get-config filters are tied to >>>> the YANG config-stmt, this would impact the protocol >>>> behavior. > > Joel pointed out that my words could have been confusing you. I > in no way am talking about a leaf that "changes back and forth > between config=true and false". > > Consider this example: the "mtu" leaf is configuration data. If > it's set to a value, that value is part of the configuration data. > If it is not set, the system will use a value for that leaf, but > not set it in the configuration database. We currently lack a > mechanism for retrieving this "mtu-right-now" value, but I am not > proposing the the "mtu" leaf fade in and out of "config=true"-ness. > You are just proposing that a node that is config=true can be ignored by the operation, even if the client has no way to know the server is going to do this. The reason that filter='trim' is OK is that it is transparent to the contract implied by the YANG module. This is a critical concept. In essence, omitting a leaf from a retrieval request that contains its YANG default-stmt value (which MUST be 1 exact valid value for the data type), is just a shorthand way of returning a leaf with its YANG default-stmt value. This is only possible because the YANG default-stmt is a MUST implement for servers. >> I don't like the with-defaults=explicit at all, >> because it assumes the description statement is complete and correct. > > I don't follow this linkage at all. Keeping explicitly created > values for configuration data is not linked with description > statements. This can be implemented for modules that don't > contain any description statements at all. > exactly -- even worse. 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. The client is still responsible for knowing all these values when it comes to editing the database and conforming to all the must/min/max/unique/create/delete constraints defined for the instances that are not retrievable. IMO, that's a big problem. > Thanks, > Phil > Andy From cfinss@dial.pipex.com Fri Aug 28 10:41: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 78BCE28C238 for ; Fri, 28 Aug 2009 10:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 AhA1diZeL78o for ; Fri, 28 Aug 2009 10:41:33 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 32EB33A6E65 for ; Fri, 28 Aug 2009 10:41:32 -0700 (PDT) X-Trace: 245143673/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.128/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.128 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: ApwEAAS0l0o+vGSA/2dsb2JhbACDLY15yVMJhBAF X-IronPort-AV: E=Sophos;i="4.44,292,1249254000"; d="scan'208";a="245143673" X-IP-Direction: IN Received: from 1cust128.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.128]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Aug 2009 18:41:37 +0100 Message-ID: <007001ca27fe$3dbf3cc0$0601a8c0@allison> From: "tom.petch" To: "WashamFan" References: <20090826.233259.182862400.mbj@tail-f.com> <4A95AC30.5090405@netconfcentral.com> <20090827.102403.52519173.mbj@tail-f.com> <000801ca2748$8fd7e5e0$0601a8c0@allison> Date: Fri, 28 Aug 2009 18:18:22 +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] mandatory Re: meaning of config really was meaning ofdefault 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: Fri, 28 Aug 2009 17:41:35 -0000 ---- Original Message ----- From: "WashamFan" Sent: Friday, August 28, 2009 8:35 AM > > Martin, Washam, I think you are saying that a writable leaf with mandatory > > substatement > > can only have a value set by a client, never by the > > server/manufacturer side > > AND such a leaf need not exist in the data tree, > > no, that is not I was saying, such a leaf DOES exist in the data tree. > > > (Does it have to be NETCONF protocol or would CLI do? fudge that for > > the moment) > > Except top-level mandatory leafs, all mandatory leafs should be set by > client via NETCONF. top-level mandatory leafs might be pre-loaded or > initialised via CLI. In this regard, the mandantory definition seems broken, > I admit. I see a further problem if, as I think you are saying, there will be leafs in the data tree with mandatory=true which only the client can set, to whit, a) Mandatory true means (at least for some leafs) that the application MUST supply the values b) Therefore the manufacturer cannot ship values for such a leaf in the initial configuration c) A device can only advertise, in 'hello', modules with valid values d) But the device cannot set values for a mandatory leaf and so a module with a mandatory leaf can never be valid at initial boot. e) Therefore the device can never advertise a module with a mandatory leaf in it, and the application can never know that the device supports it. f) Hence the application can never set a mandatory leaf. Um Tom Petch > > this being the consensus arrived at recently but not yet in the I-D. > > And, what > > the I-D does say, is that such a leaf cannot have a default > > substatement (and > > yes there are also caveats about containers and case) > > No default at all for mandatory leafs, they MUST be explicitly set whatever > server or client did it. > > washam > From andy@netconfcentral.com Fri Aug 28 10:59: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 8C5483A6BC7 for ; Fri, 28 Aug 2009 10:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 zpI30LPmIbt9 for ; Fri, 28 Aug 2009 10:59:12 -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 93A613A6EA7 for ; Fri, 28 Aug 2009 10:59:12 -0700 (PDT) Received: from [68.142.200.227] by n19.bullet.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 17:59:18 -0000 Received: from [68.142.201.250] by t8.bullet.mud.yahoo.com with NNFMP; 28 Aug 2009 17:59:17 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 17:59:17 -0000 X-Yahoo-Newman-Id: 923710.42381.bm@omp411.mail.mud.yahoo.com Received: (qmail 41202 invoked from network); 28 Aug 2009 17:59:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 28 Aug 2009 17:59:17 -0000 X-YMail-OSG: lGj.kewVM1kW2jOMn.yyVAKM1KDqXm9yDCHTROut844maIImsp529krX2Pcji_dbxd8euu3hyJMUj3LWnfpmUgmf4QghbmZq_fKgppkuBgJwadH.9STB.1mP47xYme0JVGi2XoTlt1gCqRKUEleK3m0TaexvSM02VW8wuX4Qs_EJDAu6oyrdELKTZiwymNVK7HJLgikZJXudGfM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A981AFE.1070208@netconfcentral.com> Date: Fri, 28 Aug 2009 10:59:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908281704.n7SH4wZX036296@idle.juniper.net> In-Reply-To: <200908281704.n7SH4wZX036296@idle.juniper.net> 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: Fri, 28 Aug 2009 17:59:13 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> If the draft clearly defined exactly how an 'explicit' filter >>>> is identified in YANG, and exactly how it affects the NETCONF >>>> protocol, then it is not a problem because then it would be specified >>>> in the standard. >>> NETCONF does not have 'explicit' filters. YANG does not add >>> them. What YANG says is: >>> >>> 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. >>> >>> This allows the server to either set leaf elements if the value is >>> the default value (which the with-default draft calls explicit) or >>> to choose not to send such elements (which the with-defaults draft >>> calls trim). >> >> I already agree that a server does not have to send a leaf >> when it is set to its default value. YANG defines that to >> be to value in the default-stmt. > > But YANG also allows me to record that a leaf was set to a value > and return that value even if it is the default value. > > If the default value is "3" and the user sets it to "3", then I > will still have "3" in my configuration database and will return > it if an app fetches my configuration data. If the value is not > set explicitly, then I will return nothing. This behavior is > permitted under the YANG spec. > so what. You don't have to use the shorthand if you don't want. IMO, the safest approach is to use report-all with good filters. It all comes down to how many assumptions the operator wants to make about network conditions. When everything is working great, then making lots of assumptions about the current state of the system is probably OK. But when reality starts conflicting with one or more assumptions, you can either choose to pretend the system is still functioning fine, or you can diagnose the problem, including verification of your assumptions. It doesn't matter if you run the HR dept. at a large corporation or you are the only sysadmin for your own little home network, this "systems rule" still applies. > Thanks, > Phil > Andy From jmh@joelhalpern.com Fri Aug 28 11:12: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 AD4D528C2C9 for ; Fri, 28 Aug 2009 11:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 yjiLzbcBvnBK for ; Fri, 28 Aug 2009 11:12:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 26D0E3A6F25 for ; Fri, 28 Aug 2009 11:12:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 61A41430283 for ; Fri, 28 Aug 2009 11:12:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9801043025B for ; Fri, 28 Aug 2009 11:12:29 -0700 (PDT) Message-ID: <4A981E08.6060308@joelhalpern.com> Date: Fri, 28 Aug 2009 14:12:24 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "netmod@ietf.org" References: <200908281700.n7SH0Moa036246@idle.juniper.net> <4A9815FA.9060306@netconfcentral.com> In-Reply-To: <4A9815FA.9060306@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 28 Aug 2009 18:12:23 -0000 Phil, I am missing something basic. Why, when the system fills in a value that is not the "default", do you think it is helpful and important that the value not appear as a node in the config tree? Is your concern that this will result in an overcrowded config tree? (I understand wanting a shorter tree that does not have explicit default values. I understand that such a tree is MUCH larger than desired.) Yours, Joel From phil@juniper.net Fri Aug 28 13:20: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 1AFF23A693F for ; Fri, 28 Aug 2009 13:20:33 -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 GbFkIb+KNQVP for ; Fri, 28 Aug 2009 13:20:32 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 4AE2F3A6A07 for ; Fri, 28 Aug 2009 13:20:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSpg8FQ0Ipr74tKgFobqr286vmjZ2m6Ot@postini.com; Fri, 28 Aug 2009 13:20:39 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; Fri, 28 Aug 2009 13:16:49 -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); Fri, 28 Aug 2009 13:16:50 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:16:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:16:48 -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 n7SKGmd39028; Fri, 28 Aug 2009 13:16:48 -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 n7SK4ls2037835; Fri, 28 Aug 2009 20:04:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908282004.n7SK4ls2037835@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4A981E08.6060308@joelhalpern.com> Date: Fri, 28 Aug 2009 16:04:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 20:16:48.0939 (UTC) FILETIME=[79197FB0:01CA281C] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 20:20:33 -0000 "Joel M. Halpern" writes: > Why, when the system fills in a value that is not the "default", do >you think it is helpful and important that the value not appear as a >node in the config tree? I want to make sure we're discussing the same issue, so let's separate the "defaults are not config data" issue from the "system fills in a value" issue. If the system creates configuration data, then that leaf/value is real configuration data, and it MUST be treated as such. It will exist in the configuration database until it is removed. For example, if my model for users has a uid leaf that the system will fill in when the application does not provide a value, then that value will persist and will be there for all clients to see. The following CLI snippet shows this behavior: [edit system login] phil@dent# set user mumble class super-user [edit system login] phil@dent# show user mumble class super-user; [edit system login] phil@dent# commit commit complete [edit system login] phil@dent# show user mumble uid 2002; class super-user; [edit system login] phil@dent# Note that the uid leaf is not present as configuration data. This is the behavior indicated by the non-standardized "assigned-by system" statement. In all of JUNOS's hundreds of knobs, only the uid field and an obscure IDP-related index number work this way. I think this is a "a-by system" is a rare corner case. YANG currently does not handle these cases, but there are other odd corner cases that YANG does not cover. While I'd be fine adding "assigned-by system", leaving it out is not too troubling. But if I had a default password field of "*" (preventing login), I do not create a 'password' leaf with a value of "*", because the code that fetches it from the database will know the default is "*" and uses that value if there is no password field in the database. The distinction between an account that does not yet have a password assigned, and an account that has been marked explicitly by a human user with a password of "*" (to prevent login) are preserved. Returning to the "mtu" example, if the mtu varies by the type of PIC installed in a particular slot, I don't want the default mtu value for that pic type to be added to my configuration for that interface. The default value should be used at run time (if no value were explicitly configured) and if I change to a different PIC, that PIC's default value for mtu should be used. Upgrading PIC should not require that I delete the previous PICs default values. >Is your concern that this will result in an >overcrowded config tree? (I understand wanting a shorter tree that does >not have explicit default values. I understand that such a tree is MUCH >larger than desired.) Config data is fairly sparse. Making it dense with default value increases the signal-to-noise ratio for anyone who deals with configuration. It makes it impossible to split "data that I care about" from "data that I'm uninterested in". I'm wondering if this is just a chasm between the SNMP world and the CLI world. SNMP/GDMO deal with "objects" and fields inside objects are populated with initial-values and default-values (even though the default-value for snmp is vague and weak). I can't make a C++ object without putting some value into each field. In constract, the CLI world (and the .conf file world) is more comfortable with defaults. There are no objects or structures, just data. If I don't provide a field, it defaults in a way that is very natural, at least to the users in this world. For example, if there's no "ssh_enable" variable in my /etc/rc.conf, it defaults to "no". If there's no "FallBackToRsh" in my .ssh/config, it defaults to "no". If "search" field in my /etc/resolv.conf, it defaults to the domain value. If I had to provide these default values for each field in these files, it would be a nightmare. I agree that there is an issue of learning the values in use "at the moment", but I think this issue is distinct from both the "default" issue and the "assigned-by system" one, in that I could have configured a value and that configured value may be different from the current operation value of the moment. For example, I could set "duplex" to "auto" and fetching it would give me no clue if the interface is current running at full or half duplex. This operational mode value may be derived from the configured (or default) value, but it should not interfer with the configuration settings. I hope this helps clear up any confusion. The important issue to me is that we talked about all this as far back as the interim meeting in DC, and decided to give servers the flexibility to suppress default values (as IOS and IOS clone systems do), express explicit configured values even if they are identical to the default value (as JUNOS and JUNOS clones systems do), or fully publish all default values no matter what (as Andy wants to do in his code). But this closed issue is being resurrected in a way that is trying to push all implementations to follow Andy's. I believe including defaults on every operation is a poor idea and pushing every implementation to implement this poor idea will damage YANG's chances of being accepted in the market place. I would like to keep the current wording in YANG, add any clarifying text, and move on. Thanks, Phil From mbj@tail-f.com Fri Aug 28 13:23: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 F164F3A63D3 for ; Fri, 28 Aug 2009 13:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.045, 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 kiOS48QILxgO for ; Fri, 28 Aug 2009 13:23:26 -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 2731E3A6943 for ; Fri, 28 Aug 2009 13:23:26 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EE14616001; Fri, 28 Aug 2009 22:23:32 +0200 (CEST) Date: Fri, 28 Aug 2009 22:23:31 +0200 (CEST) Message-Id: <20090828.222331.51907546.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A9815FA.9060306@netconfcentral.com> References: <200908281700.n7SH0Moa036246@idle.juniper.net> <4A9815FA.9060306@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] 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: Fri, 28 Aug 2009 20:23:27 -0000 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). /martin From phil@juniper.net Fri Aug 28 13:25: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 0E69D3A6C31 for ; Fri, 28 Aug 2009 13:25:04 -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 PVrYlWJ5DNr5 for ; Fri, 28 Aug 2009 13:25:03 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 5B6A63A6C2B for ; Fri, 28 Aug 2009 13:25:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSpg9I8KsvB04ki1sX/cMFcVY49TFtnKX@postini.com; Fri, 28 Aug 2009 13:25:10 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; Fri, 28 Aug 2009 13:20:52 -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); Fri, 28 Aug 2009 13:20:52 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:20:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:20:51 -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 n7SKKod40697; Fri, 28 Aug 2009 13:20:50 -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 n7SK8o1E037904; Fri, 28 Aug 2009 20:08:50 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908282008.n7SK8o1E037904@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A981AFE.1070208@netconfcentral.com> Date: Fri, 28 Aug 2009 16:08:49 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 20:20:51.0328 (UTC) FILETIME=[09932000:01CA281D] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 20:25:04 -0000 Andy Bierman writes: >IMO, the safest approach is to use report-all with good filters. That's your opinion, and you are free to implement this inside your source code. But it's not the WG opinion, which is reflected in the current YANG spec. YANG gives you the flexibility to take your own path, but it gives the rest of the world the flexibility to not follow you. Thanks, Phil From andy@netconfcentral.com Fri Aug 28 13:33: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 0E4FC3A6F82 for ; Fri, 28 Aug 2009 13:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ufzripJJaOOJ for ; Fri, 28 Aug 2009 13:33:53 -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 3271628C17B for ; Fri, 28 Aug 2009 13:32:45 -0700 (PDT) Received: (qmail 70138 invoked from network); 28 Aug 2009 20:32:50 -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; 28 Aug 2009 20:32:50 -0000 X-YMail-OSG: FX9R7jIVM1l8A5Vr6UXcsRZ22g4_KT4.xniTIfD0w2E5tA0y2pBkMd1Gj2953fbn37Bo8Uj_Vsq_ewncX.122VHVB97dxiUoLi4RtVMStYA3lX5gvUSrTeDuXFbEugOZhlPVveMUzu.y.WoYO.Ari1u6J7An9z0uCQxtOuGGhHJBoydhI8fCFZecdDAzceF6DWqcuJSw1stOkyCwRcZFB1LKZZ30dqcQHsjx_61PAMA99I8OEC0fWvrNaDGHvV3Be775khgDX1s8gQn8Jd_umJM5kFFDNezqU4iHKkfvARYtLpCDJC7OWHTWLMbz0eXlFJ.x5W8LvgWobA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A983E80.5090508@netconfcentral.com> Date: Fri, 28 Aug 2009 13:30:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200908281700.n7SH0Moa036246@idle.juniper.net> <4A9815FA.9060306@netconfcentral.com> <20090828.222331.51907546.mbj@tail-f.com> In-Reply-To: <20090828.222331.51907546.mbj@tail-f.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: Fri, 28 Aug 2009 20:33:54 -0000 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 assume 'explicitly set' means by the client or the startup file. If it included the server, it would be kind of pointless. A flag for 'set by gamma ray interference' ? > > /martin > Andy From jmh@joelhalpern.com Fri Aug 28 13:34: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 C6EBD3A6F82 for ; Fri, 28 Aug 2009 13:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 KaREvoOvKrEQ for ; Fri, 28 Aug 2009 13:34:03 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 38E2C3A6AF9 for ; Fri, 28 Aug 2009 13:34:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 539484302CC; Fri, 28 Aug 2009 13:34:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 54A134302C6; Fri, 28 Aug 2009 13:34:09 -0700 (PDT) Message-ID: <4A983F3C.40307@joelhalpern.com> Date: Fri, 28 Aug 2009 16:34:04 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200908282004.n7SK4ls2037835@idle.juniper.net> In-Reply-To: <200908282004.n7SK4ls2037835@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Fri, 28 Aug 2009 20:34:04 -0000 Where I get confused is with the distinction you have below. You are indicating that the situation where the system uses a value for something, that it crafts is not the same as the situation where the system assigns a value to the object. You use the UID example for the later, and the MTU example for the former. The only difference I can see is that the algorithmic rules for calculating the values happen to be different. Which leaves me very confused as to how the behavior required or expected by the standard can be different. Unless we simply make the standard so weak as to be usesless in this area. Yours, Joel Phil Shafer wrote: > "Joel M. Halpern" writes: >> Why, when the system fills in a value that is not the "default", do >> you think it is helpful and important that the value not appear as a >> node in the config tree? > > I want to make sure we're discussing the same issue, so let's > separate the "defaults are not config data" issue from the "system > fills in a value" issue. > > If the system creates configuration data, then that leaf/value is > real configuration data, and it MUST be treated as such. It will > exist in the configuration database until it is removed. > > For example, if my model for users has a uid leaf that the system > will fill in when the application does not provide a value, then > that value will persist and will be there for all clients to see. > The following CLI snippet shows this behavior: > > [edit system login] > phil@dent# set user mumble class super-user > > [edit system login] > phil@dent# show user mumble > class super-user; > > [edit system login] > phil@dent# commit > commit complete > > [edit system login] > phil@dent# show user mumble > uid 2002; > class super-user; > > [edit system login] > phil@dent# > > Note that the uid leaf is not present as configuration data. This > is the behavior indicated by the non-standardized "assigned-by > system" statement. In all of JUNOS's hundreds of knobs, only the > uid field and an obscure IDP-related index number work this way. > I think this is a "a-by system" is a rare corner case. YANG currently > does not handle these cases, but there are other odd corner cases > that YANG does not cover. While I'd be fine adding "assigned-by > system", leaving it out is not too troubling. > > But if I had a default password field of "*" (preventing login), I > do not create a 'password' leaf with a value of "*", because the > code that fetches it from the database will know the default is "*" > and uses that value if there is no password field in the database. > The distinction between an account that does not yet have a password > assigned, and an account that has been marked explicitly by a human > user with a password of "*" (to prevent login) are preserved. > > Returning to the "mtu" example, if the mtu varies by the type of > PIC installed in a particular slot, I don't want the default mtu > value for that pic type to be added to my configuration for that > interface. The default value should be used at run time (if no > value were explicitly configured) and if I change to a different > PIC, that PIC's default value for mtu should be used. Upgrading > PIC should not require that I delete the previous PICs default > values. > >> Is your concern that this will result in an >> overcrowded config tree? (I understand wanting a shorter tree that does >> not have explicit default values. I understand that such a tree is MUCH >> larger than desired.) > > Config data is fairly sparse. Making it dense with default value > increases the signal-to-noise ratio for anyone who deals with > configuration. It makes it impossible to split "data that I care > about" from "data that I'm uninterested in". > > I'm wondering if this is just a chasm between the SNMP world and > the CLI world. SNMP/GDMO deal with "objects" and fields inside > objects are populated with initial-values and default-values (even > though the default-value for snmp is vague and weak). I can't > make a C++ object without putting some value into each field. > > In constract, the CLI world (and the .conf file world) is more > comfortable with defaults. There are no objects or structures, > just data. If I don't provide a field, it defaults in a way that > is very natural, at least to the users in this world. > > For example, if there's no "ssh_enable" variable in my /etc/rc.conf, > it defaults to "no". If there's no "FallBackToRsh" in my .ssh/config, > it defaults to "no". If "search" field in my /etc/resolv.conf, it > defaults to the domain value. If I had to provide these default > values for each field in these files, it would be a nightmare. > > I agree that there is an issue of learning the values in use "at > the moment", but I think this issue is distinct from both the > "default" issue and the "assigned-by system" one, in that I could > have configured a value and that configured value may be different > from the current operation value of the moment. > > For example, I could set "duplex" to "auto" and fetching it would > give me no clue if the interface is current running at full or half > duplex. This operational mode value may be derived from the > configured (or default) value, but it should not interfer with the > configuration settings. > > I hope this helps clear up any confusion. > > The important issue to me is that we talked about all this as > far back as the interim meeting in DC, and decided to give > servers the flexibility to suppress default values (as IOS and > IOS clone systems do), express explicit configured values even > if they are identical to the default value (as JUNOS and JUNOS > clones systems do), or fully publish all default values no matter > what (as Andy wants to do in his code). > > But this closed issue is being resurrected in a way that is trying > to push all implementations to follow Andy's. I believe including > defaults on every operation is a poor idea and pushing every > implementation to implement this poor idea will damage YANG's chances > of being accepted in the market place. > > I would like to keep the current wording in YANG, add any clarifying > text, and move on. > > Thanks, > Phil > From mbj@tail-f.com Fri Aug 28 13:35: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 39D4228C24E for ; Fri, 28 Aug 2009 13:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.044, 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 1y7gJVw-ggfE for ; Fri, 28 Aug 2009 13:35:39 -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 641AE28C1E5 for ; Fri, 28 Aug 2009 13:35:39 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F42E616001; Fri, 28 Aug 2009 22:35:46 +0200 (CEST) Date: Fri, 28 Aug 2009 22:35:45 +0200 (CEST) Message-Id: <20090828.223545.89741879.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <4A97FB97.8030805@joelhalpern.com> References: <4A97F642.2050704@joelhalpern.com> <20090828.173209.86493688.mbj@tail-f.com> <4A97FB97.8030805@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] dynamic defaults 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: Fri, 28 Aug 2009 20:35:40 -0000 "Joel M. Halpern" wrote: > The case I would make illegal is any case where > the system uses a value for a node if one is not specified > that value is not the default value for the node > that value is not simply a dynamic reference to the current value of some other > well defined node > and that value can not be accessed by fetching the node itself. > > In other words, if the value is not set, and the system is using well defined > value (not one generated at need and discarded), then there has to be a > reasonable way to get that value. Reasonable ways include the default > statement, and a tractable, even if defined in the description clause, > reference to another node. Or getting that node itself. > (If we want to complicate our life, we could define a default-reference > statement which had a leafref to where that linked default comes from. But that > is something we can consider for later.) [The example I has earlier actually looked like this in its original form: leaf hold-time { type int32; tailf:default-ref '../../hold-time'; } We discussed adding default-ref to YANG (was it at the interim?) but we decided to not do it now. Since we had this functionality in our old proprietary dml, we added it as an extension. It is useful in a few places, but not very common.] > So, the illegal list includes the second interpretation of your case. It also > includes the if_mtu when the system sets an "appropriate" mtu if one is not > provided. But do you think that we can add words that describe this, and further that tools can actually verify this? Is it better to try to state this in the usage guidelines? /martin From mbj@tail-f.com Fri Aug 28 13:40: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 BB46F3A6B3A for ; Fri, 28 Aug 2009 13:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.044, 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 SXslWvJW4d9x for ; Fri, 28 Aug 2009 13:40:02 -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 E41723A6A5E for ; Fri, 28 Aug 2009 13:40:01 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9AA19616001; Fri, 28 Aug 2009 22:40:08 +0200 (CEST) Date: Fri, 28 Aug 2009 22:40:08 +0200 (CEST) Message-Id: <20090828.224008.212827189.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A983E80.5090508@netconfcentral.com> References: <4A9815FA.9060306@netconfcentral.com> <20090828.222331.51907546.mbj@tail-f.com> <4A983E80.5090508@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] 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: Fri, 28 Aug 2009 20:40:02 -0000 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. > I assume 'explicitly set' means by the > client or the startup file. If it included > the server, it would be kind of pointless. Yes. /martin From jmh@joelhalpern.com Fri Aug 28 13:44: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 958DE3A6A78 for ; Fri, 28 Aug 2009 13:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 xzMd1gZYvGes for ; Fri, 28 Aug 2009 13:44:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C97A83A6A33 for ; Fri, 28 Aug 2009 13:44:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1D8134302C2; Fri, 28 Aug 2009 13:44:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 79C0C4302CD; Fri, 28 Aug 2009 13:44:12 -0700 (PDT) Message-ID: <4A984197.2010509@joelhalpern.com> Date: Fri, 28 Aug 2009 16:44:07 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Bjorklund References: <4A97F642.2050704@joelhalpern.com> <20090828.173209.86493688.mbj@tail-f.com> <4A97FB97.8030805@joelhalpern.com> <20090828.223545.89741879.mbj@tail-f.com> In-Reply-To: <20090828.223545.89741879.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] dynamic defaults 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: Fri, 28 Aug 2009 20:44:06 -0000 Yes, I think the relevant distinction can be easily described. I think the alternative, if it can not be reasonably described, is that the config node gets set with the proper value. Yours, Joel Martin Bjorklund wrote: > "Joel M. Halpern" wrote: >> The case I would make illegal is any case where >> the system uses a value for a node if one is not specified >> that value is not the default value for the node >> that value is not simply a dynamic reference to the current value of some other >> well defined node >> and that value can not be accessed by fetching the node itself. >> >> In other words, if the value is not set, and the system is using well defined >> value (not one generated at need and discarded), then there has to be a >> reasonable way to get that value. Reasonable ways include the default >> statement, and a tractable, even if defined in the description clause, >> reference to another node. Or getting that node itself. >> (If we want to complicate our life, we could define a default-reference >> statement which had a leafref to where that linked default comes from. But that >> is something we can consider for later.) > > [The example I has earlier actually looked like this in its original > form: > > leaf hold-time { > type int32; > tailf:default-ref '../../hold-time'; > } > > We discussed adding default-ref to YANG (was it at the interim?) but > we decided to not do it now. Since we had this functionality in our > old proprietary dml, we added it as an extension. It is useful in a > few places, but not very common.] > >> So, the illegal list includes the second interpretation of your case. It also >> includes the if_mtu when the system sets an "appropriate" mtu if one is not >> provided. > > But do you think that we can add words that describe this, and further > that tools can actually verify this? Is it better to try to state > this in the usage guidelines? > > > /martin > From cfinss@dial.pipex.com Fri Aug 28 13:54: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 0BA6F28C148 for ; Fri, 28 Aug 2009 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 LeUifXTcJ9hQ for ; Fri, 28 Aug 2009 13:53:59 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 09F0128C199 for ; Fri, 28 Aug 2009 13:53:36 -0700 (PDT) X-Trace: 245166615/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.233/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.233 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: AgMFAIvgl0o+vGTp/2dsb2JhbACDLWGNG8hyCYQQBQ X-IronPort-AV: E=Sophos;i="4.44,292,1249254000"; d="scan'208";a="245166615" X-IP-Direction: IN Received: from 1cust233.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.233]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Aug 2009 21:53:41 +0100 Message-ID: <001101ca2819$126ff120$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" , "Martin Bjorklund" References: <1251118558.7051.81.camel@missotis><20090824130537.GA17038@elstar.local><1251120348.7051.100.camel@missotis><20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis> Date: Fri, 28 Aug 2009 21:45:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: [netmod] meaning of instance 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: Fri, 28 Aug 2009 20:54:00 -0000 ----- Original Message ----- From: "Ladislav Lhotka" Sent: Monday, August 24, 2009 5:14 PM > Does this follow from the statement in Sec. 7.6? > > If the leaf has a default value, the server MUST use this value > internally if no value is provided by the NETCONF client when the > instance is created. > > My interpretation is that the MUST only applies if the premise is > satisfied, i.e., if the NETCONF client creates the instance but does not > provide any value. > > BTW, the term "instance" is used quite often but AFAIK never defined in > the draft, is it the same as "data node"? Lada, I never saw a follow up to this. I think the answer no. A data node is part of the schema tree. I do not see a defined term for a something in the data tree, rather a reference to eg 'a node in the schema tree that can be instantiated in a data tree' so I take (most) references to instance to being such an instantiation (object classes, object instances, well not really:-) in a data tree. A lot of what we are discussing is about this something, when does it come into existence (something the I-D is very vague about), by what, and does it then form part of the configuration data tree as opposed to another data tree. (Andy's response to your post showed a different view to yours on these matters). One way forward would be to decouple this something from the value it takes so that we have the static structure in the data tree that XPath needs but can still say it has or has not got a value - as we already have 'not a number' in places - and where that value came from; application, device, ..... Tom Petch > Lada > > > > > > > /martin > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > From phil@juniper.net Fri Aug 28 13:59: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 6523528C13D for ; Fri, 28 Aug 2009 13:59:11 -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 Rk62HfJfwmyw for ; Fri, 28 Aug 2009 13:59:10 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 1AF383A6AF9 for ; Fri, 28 Aug 2009 13:59:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSphFJGm+z8XjKnJPjtwbnZ5YKJcIIwb0@postini.com; Fri, 28 Aug 2009 13:59:17 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; Fri, 28 Aug 2009 13:53:32 -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); Fri, 28 Aug 2009 13:51:40 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:51:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:51:39 -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 n7SKpcd54844; Fri, 28 Aug 2009 13:51: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 n7SKdcLA038419; Fri, 28 Aug 2009 20:39:38 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908282039.n7SKdcLA038419@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <4A983F3C.40307@joelhalpern.com> Date: Fri, 28 Aug 2009 16:39:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 20:51:39.0269 (UTC) FILETIME=[57088B50:01CA2821] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 20:59:11 -0000 "Joel M. Halpern" writes: >You are indicating that the situation where the system uses a value for >something, that it crafts is not the same as the situation where the >system assigns a value to the object. You use the UID example for the >later, and the MTU example for the former. > >The only difference I can see is that the algorithmic rules for >calculating the values happen to be different. >Which leaves me very confused as to how the behavior required or >expected by the standard can be different. >Unless we simply make the standard so weak as to be usesless in this area. The distinction is not algorithmic, but specified by the data modeler when they write the YANG module. It's about the nature of the leaf and how the modeler wants it used. In the case of the uid leaf, the key detail is that the uid leaf persists in the configuration database, so if I archive and restore, my users will have the same UIDs. This works because the uid is added to the configuration database as a leaf, so it follows the normal data handling rules. The mtu leaf will persist only if I set it, since the operational value for the mtu of an interface is not configuration data. Nor would the operational value for the mtu of an interface ever appear as the "mtu" leaf, since this leaf models the user configured value for the mtu, not the operational value of the mtu. This operational value will be derived from configuration data (if it exists), but will also use the PIC type (if it matters), platform details (perhaps), and perhaps a final static default. But it should not show up as the value for the "mtu" leaf in the configuration data. (This all assumes the modeler for mtu does not specify a default value for the mtu leaf in the YANG module.) Thanks, Phil From phil@juniper.net Fri Aug 28 14:02: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 EA63A28C347 for ; Fri, 28 Aug 2009 14:02:07 -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 jsD-ZkSki-dX for ; Fri, 28 Aug 2009 14:02:07 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 583C428C343 for ; Fri, 28 Aug 2009 14:02:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSphFyUjsh1TvQKwlmy8ZotJH5dyeorFp@postini.com; Fri, 28 Aug 2009 14:02:14 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; Fri, 28 Aug 2009 13:57:29 -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); Fri, 28 Aug 2009 13:57:29 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:57:29 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:57:28 -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 n7SKvRd57513; Fri, 28 Aug 2009 13:57:27 -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 n7SKjRaU038511; Fri, 28 Aug 2009 20:45:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908282045.n7SKjRaU038511@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A983E80.5090508@netconfcentral.com> Date: Fri, 28 Aug 2009 16:45:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 20:57:28.0657 (UTC) FILETIME=[2748EC10:01CA2822] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 21:02:08 -0000 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 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 phil@juniper.net Fri Aug 28 14:03: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 7EE733A6F1A for ; Fri, 28 Aug 2009 14:03:44 -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 7PztZvroFePh for ; Fri, 28 Aug 2009 14:03:43 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id DA9963A6BFE for ; Fri, 28 Aug 2009 14:03:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSphGNfuHADok+PtFb4k4W+rkH/SK9c8w@postini.com; Fri, 28 Aug 2009 14:03:51 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; Fri, 28 Aug 2009 13:59:46 -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); Fri, 28 Aug 2009 13:59:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:59:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:59:45 -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 n7SKxjd58095; Fri, 28 Aug 2009 13:59: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 n7SKljfJ038569; Fri, 28 Aug 2009 20:47:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200908282047.n7SKljfJ038569@idle.juniper.net> To: "Joel M. Halpern" In-Reply-To: <200908282004.n7SK4ls2037835@idle.juniper.net> Date: Fri, 28 Aug 2009 16:47:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2009 20:59:45.0969 (UTC) FILETIME=[79211210:01CA2822] MIME-Version: 1.0 Content-Type: text/plain 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: Fri, 28 Aug 2009 21:03:44 -0000 typo!! Phil Shafer writes: > [edit system login] > phil@dent# show user mumble > uid 2002; > class super-user; > > [edit system login] > phil@dent# > >Note that the uid leaf is not present as configuration data. s/not present/now present/ The "uid" leaf is now in the configuration database, since the system assigned a value to it (2002). Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Aug 28 14:19: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 213903A6E18 for ; Fri, 28 Aug 2009 14:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 t4R3wxMqi+B9 for ; Fri, 28 Aug 2009 14:19:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 121313A6E24 for ; Fri, 28 Aug 2009 14:19:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70263C00DA; Fri, 28 Aug 2009 23:19:10 +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 WRy+6ECyOr70; Fri, 28 Aug 2009 23:19: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 2B899C00DB; Fri, 28 Aug 2009 23:19:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA142C8214D; Fri, 28 Aug 2009 23:19:07 +0200 (CEST) Date: Fri, 28 Aug 2009 23:19:07 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090828211907.GA23399@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97CCDB.6090400@netconfcentral.com> <20090828131752.GB22962@elstar.local> <4A97FBAF.5080200@netconfcentral.com> <20090828163009.GB23097@elstar.local> <4A980C69.4090702@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A980C69.4090702@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 21:19:13 -0000 On Fri, Aug 28, 2009 at 06:57:13PM +0200, Andy Bierman wrote: > I think you are on the right track for a robust solution, > which is to codify this in a database property somehow. > IMO, this has to be a complete model, that does not > contain any gaps. I think our main difference is that I do make a clear distinction between config data and operational state data. You still seem to think in terms of "a database". > I agree with you, but I consider a configuration object > to be a node in which a client can directly alter the value. > An instance of a configuration object can be created by either > the server or the client. But even if the server sets the > leaf first, it is still config. The problem is that we can both agree on the text but still likely have read different things. For you, the MTU of my interface is a config object. For me, it is operational state until I explicitely configure it (which I never do on the systems I am responsible for; none of my config files messes around with the MTU because I trust the kernel to figure out a reasonable value - so I "configure" the system to not have config data for the MTU). > I don't like the with-defaults=explicit at all, because it assumes > the description statement is complete and correct. Repetition does not make this statement true. /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 Fri Aug 28 14:56:32 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 5D8533A69A4 for ; Fri, 28 Aug 2009 14:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 EilrdiM51U-V for ; Fri, 28 Aug 2009 14:56:31 -0700 (PDT) Received: from n22b.bullet.mail.mud.yahoo.com (n22b.bullet.mail.mud.yahoo.com [68.142.206.159]) by core3.amsl.com (Postfix) with SMTP id 66AE53A6A26 for ; Fri, 28 Aug 2009 14:56:31 -0700 (PDT) Received: from [68.142.200.221] by n22.bullet.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 21:56:36 -0000 Received: from [68.142.201.70] by t9.bullet.mud.yahoo.com with NNFMP; 28 Aug 2009 21:56:36 -0000 Received: from [127.0.0.1] by omp422.mail.mud.yahoo.com with NNFMP; 28 Aug 2009 21:56:36 -0000 X-Yahoo-Newman-Id: 472222.80841.bm@omp422.mail.mud.yahoo.com Received: (qmail 26632 invoked from network); 28 Aug 2009 21:56:36 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.231.134 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 28 Aug 2009 21:56:35 -0000 X-YMail-OSG: ZScSvy4VM1ms.RYrOGC3d0KR71wFcoxFchjTMQzbSOL4BcFHDaLdXMTqKn4PGeMSMiPIe9qC2S2zC1PK0XVy.BwGhVU88Bxy7MNZzXhq9U6Rk1D.9F9pZ8PscT0Xt2u.y89CaDB8Jb3.caRJ4u7rvYz4ON8MjluwvC4.yWKWMmGFTifXJHHL1wJSRS8U0FSqVBRD2tAoOkUpaTk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A985224.1070808@netconfcentral.com> Date: Fri, 28 Aug 2009 14:54:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <4A96B3E0.2050906@netconfcentral.com> <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97CCDB.6090400@netconfcentral.com> <20090828131752.GB22962@elstar.local> <4A97FBAF.5080200@netconfcentral.com> <20090828163009.GB23097@elstar.local> <4A980C69.4090702@netconfcentral.com> <20090828211907.GA23399@elstar.local> In-Reply-To: <20090828211907.GA23399@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 28 Aug 2009 21:56:32 -0000 Juergen Schoenwaelder wrote: > On Fri, Aug 28, 2009 at 06:57:13PM +0200, Andy Bierman wrote: > >> I think you are on the right track for a robust solution, >> which is to codify this in a database property somehow. >> IMO, this has to be a complete model, that does not >> contain any gaps. > > I think our main difference is that I do make a clear distinction > between config data and operational state data. You still seem to > think in terms of "a database". > Because the NETCONF protocol is written that way. I'm trying to limit the standard behavior to what is actually specified in the standard. The YANG draft says that config=true means it works on . So does 4741. The protocol already makes this distinction, not me. >> I agree with you, but I consider a configuration object >> to be a node in which a client can directly alter the value. >> An instance of a configuration object can be created by either >> the server or the client. But even if the server sets the >> leaf first, it is still config. > > The problem is that we can both agree on the text but still likely > have read different things. For you, the MTU of my interface is a > config object. For me, it is operational state until I explicitely > configure it (which I never do on the systems I am responsible for; > none of my config files messes around with the MTU because I trust the > kernel to figure out a reasonable value - so I "configure" the system > to not have config data for the MTU). > As long as your implementation follows the rules for config=true/false, then you can define your MTU leaf any way you want. If you want the or operations to have any affect on your leaf, you better make sure the config-stmt is set to true. >> I don't like the with-defaults=explicit at all, because it assumes >> the description statement is complete and correct. > > Repetition does not make this statement true. > Fine. In my experience, it is faster and less expensive to resolve debugging issues based on data, rather than assumptions about that data, but YMMY. > /js > Andy From andy@netconfcentral.com Fri Aug 28 15:41: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 DC9053A6BFF for ; Fri, 28 Aug 2009 15:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 5eHcg3o5TdIk for ; Fri, 28 Aug 2009 15:41:29 -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 C2B563A683A for ; Fri, 28 Aug 2009 15:41:29 -0700 (PDT) Received: (qmail 53802 invoked from network); 28 Aug 2009 22:41:35 -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; 28 Aug 2009 22:41:35 -0000 X-YMail-OSG: UodVguwVM1l_zclbG3H8wXm8hrcqTlox_yOlgEQXtELpcC_wA525AIEPwhPWFLJnKrHKYYaKeGH0hOKBI41hkZUElPL0OJOLLL5U0YtwdBl6jIUS.HXzD2mu9EDkqpi9hLcifib0xbl5QTcJnPIXIw2vdRYp7VHq.4iucUUA8Ev0wfO1sNnGqRL37TSsKJ63h2sS7bTB_iOrN38- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A985D28.4080400@netconfcentral.com> Date: Fri, 28 Aug 2009 15:41:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <200908282045.n7SKjRaU038511@idle.juniper.net> In-Reply-To: <200908282045.n7SKjRaU038511@idle.juniper.net> 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: Fri, 28 Aug 2009 22:41:31 -0000 Phil Shafer wrote: > 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 > > 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. > Precisely. Therefore, it has no relation at all to the model defined in the YANG draft, which is 'config + yang-defaults = entire database for validation purposes' In order for the server to provide the filtering behavior you are describing, the server MUST support the :with-defaults capability. The YANG spec allows either 'trim' or 'report-all' without the need to support the :with-defaults capability. As you pointed out, the server MAY suppress YANG-defaults, but it does not have to do that, so a NETCONF client MUST be able do deal with either of these modes at any time. If the :with-defaults capability is supported, then the server can choose basic=explicit, but it MUST also honor 'report-all' retrieval requests, if the client issues any. This is what the drafts support now. This is a very acceptable solution to me, because it allows all available data to be retrievable on all servers, and allows servers to use basic=explicit if they want, even though the YANG and NETCONF standards do not make any client vs. server distinction. I am a big fan of unix config files. I just wish there weren't so many different semi-structured variants of them. One more detail... Can we say that a server MUST (or SHOULD) store its NV-storage data using the defaults scheme advertised in its 'basic=xxx' capability? I think that is assumed, but it should be at least suggested. If no with-defaults support, then the server can choose 'report-all' or 'trim', and not be bound to either choice (mixed-mode). > Thanks, > Phil > Andy From Washam.Fan@huaweisymantec.com Fri Aug 28 20:14: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 E47013A6BCA for ; Fri, 28 Aug 2009 20:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.258 X-Spam-Level: X-Spam-Status: No, score=-0.258 tagged_above=-999 required=5 tests=[AWL=0.237, 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 XI4ELyeIkKaN for ; Fri, 28 Aug 2009 20:14:16 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 234753A6BFE for ; Fri, 28 Aug 2009 20:14:16 -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.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP40003KBN2FF10@hstga01-in.huaweisymantec.com> for netmod@ietf.org; Sat, 29 Aug 2009 11:13:50 +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 <0KP400A32BN2Y610@hstml01-in.huaweisymantec.com> for netmod@ietf.org; Sat, 29 Aug 2009 11:13:50 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 29 Aug 2009 11:13:50 +0800 From: WashamFan To: "tom.petch" Message-id: Date: Sat, 29 Aug 2009 11:13:50 +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: <007001ca27fe$3dbf3cc0$0601a8c0@allison> References: <20090826.233259.182862400.mbj@tail-f.com> <4A95AC30.5090405@netconfcentral.com> <20090827.102403.52519173.mbj@tail-f.com> <000801ca2748$8fd7e5e0$0601a8c0@allison> <007001ca27fe$3dbf3cc0$0601a8c0@allison> Cc: netmod@ietf.org Subject: Re: [netmod] mandatory Re: meaning of config really was meaning ofdefault 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: Sat, 29 Aug 2009 03:14:17 -0000 Hi, > > Except top-level mandatory leafs, all mandatory leafs should be set > by > > client via NETCONF. top-level mandatory leafs might be pre-loaded > or > > initialised via CLI. In this regard, the mandantory definition > seems broken, > > I admit. > > I see a further problem if, as I think you are saying, there will be > leafs > in the data tree with mandatory=true which only the client can set, > to whit, > > a) Mandatory true means (at least for some leafs) that the > application > MUST supply the values > > b) Therefore the manufacturer cannot ship values for such a leaf in > the initial configuration > > c) A device can only advertise, in 'hello', modules with valid values > > d) But the device cannot set values for a mandatory leaf and so > a module with a mandatory leaf can never be valid at initial boot. If a mandatory leaf without value can invalidate the config before a client can get a chance to set it via NETCONF, the leaf MUST be set by the server or via non-NETCONF and exists in data tree. This is how top-level mandatory leafs work. the mandatory leafs which MUST be set by a client is those ones whose values MUST be provided when the client issues . e.g., I to create a P container, then I MUST explicitly set any mandatory leafs underneath it, otherwise, the fails. (Of cource, that applied when you directly edit running, when you edit candidate, you can supply the values till .) So, My interpretation of mandatory seems, a client MUST supply the values of mandatory leafs unless he/she can't get a chance to do it via NETCONF. washam > e) Therefore the device can never advertise a module with a mandatory > leaf in it, and the application can never know that the device > supports it. > > f) Hence the application can never set a mandatory leaf. > > Um > > Tom Petch From andy@netconfcentral.com Fri Aug 28 20:56: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 91F6B3A68A6 for ; Fri, 28 Aug 2009 20:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 eiCC7cxY7V9f for ; Fri, 28 Aug 2009 20:56:26 -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 B2B393A6856 for ; Fri, 28 Aug 2009 20:56:26 -0700 (PDT) Received: (qmail 88044 invoked from network); 29 Aug 2009 03:56:32 -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; 29 Aug 2009 03:56:31 -0000 X-YMail-OSG: lMy9kf4VM1mwFr9wxPHVq35yrG5SEN5VvSe6T.vlIWZIAxW3fHCOBP1EAbA9.crobsMPQ8dz6mlBk_sferumCE5ByDYu3vDNX_3xz6U_OwnEZqA9yq.r3zuD0OZuVOLQAAOZTTgNzYu3.sPac2JXdoQD7WXKJ_R7Y_BhJ97Ovz46dCPhbVWC5_ROjZyMbA5qvkCtYpd3TAkPoTaTblcbRSb7csyhGC59VKaZuOd3g7cOOFcNCZV9wIHpczhjXacsqT6iYSZvBoifJCr0d3qJaKN75WDZtEw6J..ZJa1EtzXxwKM9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A98A680.4080206@netconfcentral.com> Date: Fri, 28 Aug 2009 20:54:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <20090826.233259.182862400.mbj@tail-f.com> <4A95AC30.5090405@netconfcentral.com> <20090827.102403.52519173.mbj@tail-f.com> <000801ca2748$8fd7e5e0$0601a8c0@allison> <007001ca27fe$3dbf3cc0$0601a8c0@allison> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] mandatory Re: meaning of config really was meaning ofdefault 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: Sat, 29 Aug 2009 03:56:27 -0000 WashamFan wrote: > Hi, > >> > Except top-level mandatory leafs, all mandatory leafs should be set >> by >> > client via NETCONF. top-level mandatory leafs might be pre-loaded >> or >> > initialised via CLI. In this regard, the mandantory definition >> seems broken, >> > I admit. >> >> I see a further problem if, as I think you are saying, there will be >> leafs >> in the data tree with mandatory=true which only the client can set, >> to whit, >> >> a) Mandatory true means (at least for some leafs) that the >> application >> MUST supply the values >> >> b) Therefore the manufacturer cannot ship values for such a leaf in >> the initial configuration >> >> c) A device can only advertise, in 'hello', modules with valid values >> >> d) But the device cannot set values for a mandatory leaf and so >> a module with a mandatory leaf can never be valid at initial boot. > > If a mandatory leaf without value can invalidate the config before a client > can get a chance to set it via NETCONF, the leaf MUST be set by the > server or via non-NETCONF and exists in data tree. This is how top-level > mandatory leafs work. > No -- this is why mandatory top-level nodes don't always work. The server MAY create a mandatory leaf. That is 2119-speak for "the client cannot rely on it". Most likely, a mandatory leaf is not going filled in the server, but there is no way to tell. > the mandatory leafs which MUST be set by a client is those ones whose > values MUST be provided when the client issues . e.g., I > to create a P container, then I MUST explicitly set any > mandatory leafs underneath it, otherwise, the fails. (Of > cource, that applied when you directly edit running, when you edit > candidate, you can supply the values till .) > > So, My interpretation of mandatory seems, a client MUST supply the values > of mandatory leafs unless he/she can't get a chance to do it via NETCONF. > > washam Andy > >> e) Therefore the device can never advertise a module with a mandatory >> leaf in it, and the application can never know that the device >> supports it. >> >> f) Hence the application can never set a mandatory leaf. >> >> Um >> >> Tom Petch > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Fri Aug 28 21:56: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 1698F3A6899 for ; Fri, 28 Aug 2009 21:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 KZoeXuvLve3h for ; Fri, 28 Aug 2009 21:55:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 33C8D3A6BBF for ; Fri, 28 Aug 2009 21:55:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65CBAC001F; Sat, 29 Aug 2009 06:56:05 +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 6YwKwcHL3B9X; Sat, 29 Aug 2009 06:56:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B2D8C00DD; Sat, 29 Aug 2009 06:56:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA91DC82347; Sat, 29 Aug 2009 06:56:02 +0200 (CEST) Date: Sat, 29 Aug 2009 06:56:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090829045602.GA23807@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20090827.191002.48739649.mbj@tail-f.com> <4A96C3FA.9010407@netconfcentral.com> <20090828.102808.31895182.mbj@tail-f.com> <4A97CCDB.6090400@netconfcentral.com> <20090828131752.GB22962@elstar.local> <4A97FBAF.5080200@netconfcentral.com> <20090828163009.GB23097@elstar.local> <4A980C69.4090702@netconfcentral.com> <20090828211907.GA23399@elstar.local> <4A985224.1070808@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A985224.1070808@netconfcentral.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 04:56:00 -0000 On Fri, Aug 28, 2009 at 11:54:44PM +0200, Andy Bierman wrote: > >> I don't like the with-defaults=explicit at all, because it assumes > >> the description statement is complete and correct. > > > > Repetition does not make this statement true. > > > > Fine. > In my experience, it is faster and less expensive to resolve debugging > issues based on data, rather than assumptions about that data, but YMMY. Debugging requires to look at the operational state (consider a routing problem when you run OSPF). If I do not understand what my kernel does, I type sysctl -a. If I conclude I need to change a setting, I edit /etc/sysctl.conf. And my /etc/sysctl.conf is rather short. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Fri Aug 28 21:58: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 251F43A6899 for ; Fri, 28 Aug 2009 21:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 FbapFJXfjqCF for ; Fri, 28 Aug 2009 21:58:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5AB2F3A6A89 for ; Fri, 28 Aug 2009 21:58:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B1535438012; Fri, 28 Aug 2009 21:58:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 1B576437E53; Fri, 28 Aug 2009 21:58:46 -0700 (PDT) Message-ID: <4A98B581.8080400@joelhalpern.com> Date: Sat, 29 Aug 2009 00:58:41 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200908282039.n7SKdcLA038419@idle.juniper.net> In-Reply-To: <200908282039.n7SKdcLA038419@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Sat, 29 Aug 2009 04:58:41 -0000 "Specified by the data modeler" where? Even the description clauses do not tell me which elements are created in the model by the system and which elements are filled in behind the scenes, and not recorded in the data model. Yours, Joel Phil Shafer wrote: > "Joel M. Halpern" writes: >> You are indicating that the situation where the system uses a value for >> something, that it crafts is not the same as the situation where the >> system assigns a value to the object. You use the UID example for the >> later, and the MTU example for the former. >> >> The only difference I can see is that the algorithmic rules for >> calculating the values happen to be different. >> Which leaves me very confused as to how the behavior required or >> expected by the standard can be different. >> Unless we simply make the standard so weak as to be usesless in this area. > > The distinction is not algorithmic, but specified by the data modeler > when they write the YANG module. It's about the nature of the leaf > and how the modeler wants it used. > > In the case of the uid leaf, the key detail is that the uid leaf > persists in the configuration database, so if I archive and restore, > my users will have the same UIDs. This works because the uid is > added to the configuration database as a leaf, so it follows the > normal data handling rules. > > The mtu leaf will persist only if I set it, since the operational > value for the mtu of an interface is not configuration data. Nor > would the operational value for the mtu of an interface ever appear > as the "mtu" leaf, since this leaf models the user configured value > for the mtu, not the operational value of the mtu. This operational > value will be derived from configuration data (if it exists), but > will also use the PIC type (if it matters), platform details > (perhaps), and perhaps a final static default. But it should not > show up as the value for the "mtu" leaf in the configuration data. > > (This all assumes the modeler for mtu does not specify a default > value for the mtu leaf in the YANG module.) > > Thanks, > Phil > From jmh@joelhalpern.com Fri Aug 28 22:04: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 265603A68F9 for ; Fri, 28 Aug 2009 22:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 AZuxA1vChZbB for ; Fri, 28 Aug 2009 22:04:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 380143A6862 for ; Fri, 28 Aug 2009 22:04:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 90E88438012; Fri, 28 Aug 2009 22:04:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id BB29E437E53; Fri, 28 Aug 2009 22:04:57 -0700 (PDT) Message-ID: <4A98B6F4.3090202@joelhalpern.com> Date: Sat, 29 Aug 2009 01:04:52 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phil Shafer References: <200908282004.n7SK4ls2037835@idle.juniper.net> In-Reply-To: <200908282004.n7SK4ls2037835@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Sat, 29 Aug 2009 05:04:52 -0000 On the question of why / whether this non-representation is important, if I am reading your text correctly, the difference is very much dependent upon who this is for. If the XML response is going to be read by a human being, then keeping it very sparse is quite helpful. On the other hand, if it is going to be read by an automaton, then being verbose is actually an advantage, as the odds of the machinery being able to work with the content is much higher. If we really need to allow this distinction as to whether the set values appear or not in normal responses (and I am not convinced we do), then I end up envisioning having a default statement that says "default by-system" and then it would not be returned when defaults are suppressed, but would be returned when defautls are delivered. Ugly. Given that in your model, these specific values do not appear when defaults are delivered, and do not appear when defaults are suppressed, it seems to me that this is a different issue from whether defaults must be delivered, or can be delivered, or must never be delivered, or are included to confuse everyone. I am not trying to push everyone to follow any particular implementation strategy. I am however trying to end up with something that I thing can be useful for management systems. Yours, Joel Phil Shafer wrote: > "Joel M. Halpern" writes: ... >> Is your concern that this will result in an >> overcrowded config tree? (I understand wanting a shorter tree that does >> not have explicit default values. I understand that such a tree is MUCH >> larger than desired.) > > Config data is fairly sparse. Making it dense with default value > increases the signal-to-noise ratio for anyone who deals with > configuration. It makes it impossible to split "data that I care > about" from "data that I'm uninterested in". > > I'm wondering if this is just a chasm between the SNMP world and > the CLI world. SNMP/GDMO deal with "objects" and fields inside > objects are populated with initial-values and default-values (even > though the default-value for snmp is vague and weak). I can't > make a C++ object without putting some value into each field. > > In constract, the CLI world (and the .conf file world) is more > comfortable with defaults. There are no objects or structures, > just data. If I don't provide a field, it defaults in a way that > is very natural, at least to the users in this world. > > For example, if there's no "ssh_enable" variable in my /etc/rc.conf, > it defaults to "no". If there's no "FallBackToRsh" in my .ssh/config, > it defaults to "no". If "search" field in my /etc/resolv.conf, it > defaults to the domain value. If I had to provide these default > values for each field in these files, it would be a nightmare. > > I agree that there is an issue of learning the values in use "at > the moment", but I think this issue is distinct from both the > "default" issue and the "assigned-by system" one, in that I could > have configured a value and that configured value may be different > from the current operation value of the moment. > > For example, I could set "duplex" to "auto" and fetching it would > give me no clue if the interface is current running at full or half > duplex. This operational mode value may be derived from the > configured (or default) value, but it should not interfer with the > configuration settings. > > I hope this helps clear up any confusion. > > The important issue to me is that we talked about all this as > far back as the interim meeting in DC, and decided to give > servers the flexibility to suppress default values (as IOS and > IOS clone systems do), express explicit configured values even > if they are identical to the default value (as JUNOS and JUNOS > clones systems do), or fully publish all default values no matter > what (as Andy wants to do in his code). > > But this closed issue is being resurrected in a way that is trying > to push all implementations to follow Andy's. I believe including > defaults on every operation is a poor idea and pushing every > implementation to implement this poor idea will damage YANG's chances > of being accepted in the market place. > > I would like to keep the current wording in YANG, add any clarifying > text, and move on. > > Thanks, > Phil > From lhotka@cesnet.cz Sat Aug 29 04:28: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 8A69B3A6A86 for ; Sat, 29 Aug 2009 04:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=0.065, 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 LC6VDw6lHfm5 for ; Sat, 29 Aug 2009 04:28:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 481803A6940 for ; Sat, 29 Aug 2009 04:27:40 -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 A9276D800E8; Sat, 29 Aug 2009 13:27:46 +0200 (CEST) From: Ladislav Lhotka To: "tom.petch" In-Reply-To: <001101ca2819$126ff120$0601a8c0@allison> References: <1251118558.7051.81.camel@missotis> <20090824130537.GA17038@elstar.local><1251120348.7051.100.camel@missotis> <20090824.160415.74934092.mbj@tail-f.com> <1251126841.7051.123.camel@missotis> <001101ca2819$126ff120$0601a8c0@allison> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 29 Aug 2009 13:27:44 +0200 Message-Id: <1251545264.5865.55.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] meaning of instance 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: Sat, 29 Aug 2009 11:28:35 -0000 tom.petch píše v Pá 28. 08. 2009 v 21:45 +0200: > > BTW, the term "instance" is used quite often but AFAIK never defined > in > > the draft, is it the same as "data node"? > > Lada, > > I never saw a follow up to this. I think the answer no. A data node > is part of > the schema tree. I do not see a defined term for a something in the > data tree, > rather a reference to eg 'a node in the schema tree that can be > instantiated in > a > data tree' so I take (most) references to instance to being such an > instantiation (object classes, object instances, well not really:-) in > a data > tree. Yes, we run into it quite often and this "dual life" of nodes also fuels the confusion. For example, last bullet in sec. 7.6.4 says o Otherwise, the leaf MUST exist if the ancestor node exists. but if fact it should read o Otherwise, the leaf MUST be instatiated if the ancestor is instantiated. which is quite awkward. In other schema languages, this distinction is is much clearer, XSD defines types ("element E is of type T") and RELAX NG defines patterns ("element E matches P"). Lada > > A lot of what we are discussing is about this something, when does it > come into > existence (something the I-D is very vague about), by what, and does > it then > form part of the configuration data tree as opposed to another data > tree. > (Andy's response to your post showed a different view to yours on > these > matters). > > One way forward would be to decouple this something from the value it > takes so > that we have the static structure in the data tree that XPath needs > but can > still say it has or has not got a value - as we already have 'not a > number' in > places - and where that value came from; application, device, ..... > Tom Petch -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From jmh@joelhalpern.com Sat Aug 29 11:32: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 14CA83A6B35; Sat, 29 Aug 2009 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 DYUFeB6ev8WZ; Sat, 29 Aug 2009 11:32:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5B2EB3A69D9; Sat, 29 Aug 2009 11:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C9073430593; Sat, 29 Aug 2009 11:32:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 359CB430590; Sat, 29 Aug 2009 11:32:37 -0700 (PDT) Message-ID: <4A99743F.8040902@joelhalpern.com> Date: Sat, 29 Aug 2009 14:32:31 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group References: <4A9563BF.7060908@netconfcentral.com> <4A9942D1.3030003@netconfcentral.com> <4A994C94.7020600@netconfcentral.com> <20090829155832.GA24264@elstar.local> <4A9954F1.3040204@joelhalpern.com> <20090829182017.GA24348@elstar.local> In-Reply-To: <20090829182017.GA24348@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] with-defaults terminology conflict 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: Sat, 29 Aug 2009 18:32:31 -0000 I have, in previous notes, said that representing the "currently used mtu" as operational data would be a reasonable approach. I can even live with the fact that the coupling between the configured value and the operational value is weak / description based. But, every time I have suggested that, Phil (who is the most vocal proponent of the view that such information should not appear in the config), has vehemently asserted that he does not want to represent it as operational data. I readily admit that there are multiple ways to solve the problem. What I am not prepared to admit is that "read the documentation and attempt to recreate the document device calculation in the manager" is even vaguely appropriate as a solution. Nor am I prepared to agree that there is not a problem. Yours, Joel PS: I copied netmod, because I thought that was where this was being discussed for the most part. It clearly crosses the boundaries between the two. Juergen Schoenwaelder wrote: > On Sat, Aug 29, 2009 at 06:18:57PM +0200, Joel M. Halpern wrote: > >> For other values, I can not see any justification for not representing >> them. They need to be accessible to the management system. > > Accessible yes, but they are not part of the configuration. > >> The length issue seems to turn on who is processing this >> information. Machinery can deal with the length we are discussing. > > Making operational state by default is broken. It is wrong in most > cases to treat the MTU as config since what you want is likely the > value the kernel figured out for the piece of hardware you are > currently using. We are caught in circles. > > /js > From andy@netconfcentral.com Sat Aug 29 16:05: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 B16FA3A6B11 for ; Sat, 29 Aug 2009 16:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, J_CHICKENPOX_101=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 Dcu9bjaRv5pw for ; Sat, 29 Aug 2009 16:05:29 -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 EEC623A6969 for ; Sat, 29 Aug 2009 16:05:28 -0700 (PDT) Received: (qmail 73629 invoked from network); 29 Aug 2009 23:05:31 -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; 29 Aug 2009 23:05:31 -0000 X-YMail-OSG: HM1tcbcVM1kHQEg0NKupX1NPG1SSNirzV0JJl_Kij8LIpjVpnsy6h8qvZyYVUBbcGQG4oSDFvHGxhlAzwhfgxQfK9aW2VRY3K9enRnANf36JWUTJrVS3dnvkusC36LXAj1lpmKIN9zGnN_BdEhJ_R4S2fV7X26254SPV3RVepJj16gzu0rN8uEULySUHkN3ly8P1bVTaU64Rp3kGLFKvYcnBMm6ACjzyuqlVQChbrvTpaCbnimHtDKZ7kHhdjJGzMl89TdFsnpOxKjntXwfXWT9qC88h5ecFqm023EPIsybGpGeuE4X3JGWpuMByGpXtOIcqD3TgqN.VIg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A99B3CB.5090107@netconfcentral.com> Date: Sat, 29 Aug 2009 16:03:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4A9815FA.9060306@netconfcentral.com> <20090828.222331.51907546.mbj@tail-f.com> <4A983E80.5090508@netconfcentral.com> <20090828.224008.212827189.mbj@tail-f.com> In-Reply-To: <20090828.224008.212827189.mbj@tail-f.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: Sat, 29 Aug 2009 23:05:34 -0000 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. > Yes, that is what I want to do: If the server advertises a YANG module capability URI for a particular portion of the configuration database, then the filtering is applied to any instances of any objects defined in that portion of the configuration database as follows: trim: leaf instances set to their YANG default-stmt value are omitted in the explicit: leaf instances that match the 'server-assigned data' definition are omitted in the report-all: no instances are omitted in the Also, the definition of a default in YANG may still too simplistic because it does not account for deviation statements: module X { leaf foo { type int32; default 10; } } module Y { import Y { prefix y; } deviation /Y:foo { deviate delete { default 10; } } } There is no 'default 10' for the /foo leaf on this server. Since the deviations for /foo can appear anywhere, the' deviations=Y' part of the module X capability URI becomes a critical piece of data for the client. For this leaf, on this server, the 'trim' mode does not omit the /foo leaf, because this server does not implement the default. There are many places where NETCONF protocol behavior is defined in terms of a YANG statement value. I am not sure it is clear that this really means the synthesis of the YANG statement plus any deviation statements that apply to the same statement within a specific YANG object definition. I hope so. >> I assume 'explicitly set' means by the >> client or the startup file. If it included >> the server, it would be kind of pointless. > > Yes. > > > /martin > Andy From andy@netconfcentral.com Sun Aug 30 00:43:21 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 034CF3A6879 for ; Sun, 30 Aug 2009 00:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 u7ccpUQQZ5U3 for ; Sun, 30 Aug 2009 00:43:20 -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 0AD553A63CB for ; Sun, 30 Aug 2009 00:43:16 -0700 (PDT) Received: (qmail 63326 invoked from network); 30 Aug 2009 07:43:23 -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; 30 Aug 2009 07:43:23 -0000 X-YMail-OSG: R6N1D3cVM1msxpQ0rC2y_F1n._9jfPnzHmZ0HcHioCptArnWs6O57dBUHjZz4JZgHzXuTlqjhr3pIRI4HbJngovYUPVbnTShVMxBHYtGtzz4ssLIb.ENHxk2p37iKU0eS.p6.Ke7iQBLrpSVHuPewYZMTDVWKrft.LIhzxqXITvM2MyHUq1jsY0gjdWkIi1BUxJ7msYMSwRUSDZJS9G8J8p5fQOKxxVMgtJIPDRTGVVNBqrkYqHijtA4Sw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9A2DA7.9020505@netconfcentral.com> Date: Sun, 30 Aug 2009 00:43:35 -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] 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: Sun, 30 Aug 2009 07:43:21 -0000 Hi, ops-nm: 2007-06-06 http://www.ietf.org/mail-archive/web/ops-nm/current/msg00105.html netconf: 2007-06-08 http://www.ietf.org/mail-archive/web/netconf/current/msg02591.html I guess I am irritable about this 'config/state' issue because I brought up this exact issue at least 2 years ago, and I was told I was wrong -- there are only 2 states. I brought up the issue again with the YANG design team and was told I was wrong again -- no, we only need a boolean. I had something called 'transient config' in NCX, long before YANG. IMO, it exactly describes the 3rd state (see 1st msg above). Instead of config=true/false, NCX had config=config/tconfig/state. Transient config can be set at any time by the client or the server, but it is never saved in NV-storage. Maybe the terminology needs work, but the mechanism exactly says what Juergen wants -- to edit ifMtu but not save it as part of the configuration. Andy From cfinss@dial.pipex.com Sun Aug 30 10:37: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 A6E9C3A6BAE for ; Sun, 30 Aug 2009 10:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_50=0.001] 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 H2ynXCe7hlqm for ; Sun, 30 Aug 2009 10:37:24 -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 954A73A6AC8 for ; Sun, 30 Aug 2009 10:37:24 -0700 (PDT) X-Trace: 134948422/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.74/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.74 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: ApwEABNWmko+vGRK/2dsb2JhbACDLY1+w14JhBEF X-IronPort-AV: E=Sophos;i="4.44,299,1249254000"; d="scan'208";a="134948422" X-IP-Direction: IN Received: from 1cust74.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.74]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Aug 2009 18:37:31 +0100 Message-ID: <00a401ca298f$fe348f40$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Phil Shafer" References: <200908282045.n7SKjRaU038511@idle.juniper.net> Date: Sun, 30 Aug 2009 18:35:35 +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: Sun, 30 Aug 2009 17:37:25 -0000 ----- 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. Tom Petch > 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 mbj@tail-f.com Sun Aug 30 11:35: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 8814728C125 for ; Sun, 30 Aug 2009 11:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.042, 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 RkmLF4xKdTBt for ; Sun, 30 Aug 2009 11:35:44 -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 B41E53A6BC2 for ; Sun, 30 Aug 2009 11:35:44 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E9D176C5A9; Sun, 30 Aug 2009 20:35:53 +0200 (CEST) Date: Sun, 30 Aug 2009 20:35:53 +0200 (CEST) Message-Id: <20090830.203553.171621683.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A9A2DA7.9020505@netconfcentral.com> References: <4A9A2DA7.9020505@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] 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: Sun, 30 Aug 2009 18:35:45 -0000 Andy Bierman wrote: > Hi, > > ops-nm: 2007-06-06 > http://www.ietf.org/mail-archive/web/ops-nm/current/msg00105.html > > > netconf: 2007-06-08 > http://www.ietf.org/mail-archive/web/netconf/current/msg02591.html > > > I guess I am irritable about this 'config/state' issue > because I brought up this exact issue at least 2 years > ago, and I was told I was wrong -- there are only 2 states. > > I brought up the issue again with the YANG design team and > was told I was wrong again -- no, we only need a boolean. > > I had something called 'transient config' in NCX, long before YANG. > IMO, it exactly describes the 3rd state (see 1st msg above). > > Instead of config=true/false, NCX had config=config/tconfig/state. > > Transient config can be set at any time by the client or the > server, but it is never saved in NV-storage. > > Maybe the terminology needs work, but the mechanism exactly > says what Juergen wants -- to edit ifMtu but not save it > as part of the configuration. I don't think this would solve the problem. In the ifMtu case, the problem is that even if no such leaf exists in the config, the device will still operationally choose a proper value. As another example, if the "duplex" leaf is configured to the value 'auto', the operationally choosen value might be 'half'. This is not transient config. /martin From andy@netconfcentral.com Sun Aug 30 13:49: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 ABF653A6D3C for ; Sun, 30 Aug 2009 13:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 1Yzzdi4BD6zl for ; Sun, 30 Aug 2009 13:49:10 -0700 (PDT) Received: from n11b.bullet.mail.mud.yahoo.com (n11b.bullet.mail.mud.yahoo.com [209.191.125.178]) by core3.amsl.com (Postfix) with SMTP id BFE633A6A84 for ; Sun, 30 Aug 2009 13:49:10 -0700 (PDT) Received: from [68.142.200.224] by n11.bullet.mail.mud.yahoo.com with NNFMP; 30 Aug 2009 20:49:17 -0000 Received: from [68.142.201.65] by t5.bullet.mud.yahoo.com with NNFMP; 30 Aug 2009 20:49:17 -0000 Received: from [127.0.0.1] by omp417.mail.mud.yahoo.com with NNFMP; 30 Aug 2009 20:49:17 -0000 X-Yahoo-Newman-Id: 536449.89478.bm@omp417.mail.mud.yahoo.com Received: (qmail 3744 invoked from network); 30 Aug 2009 20:49:17 -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; 30 Aug 2009 20:49:16 -0000 X-YMail-OSG: z8CjE9oVM1m1QhaC20hYCU4pmi1Oqt5KCLct313gEvxUgrlOSB.ojQyMQlDqqdot.BQtT3zB8nNx.kohitQI2VrilHve3QIj3ibTpU2DVC1WLoXjdmDTZKJY8JTYs07AbhD5P4pE9JAncyc17R03rkH2i1dwkyFaXswDkjqldhL7gUL38rkgq9GQmTq35IQ9tUL8O_JUoMwuARg6pCjjP9htyjqMoOCANLBcX3ZlLwsuGsvqxKs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9AE5D9.7020902@netconfcentral.com> Date: Sun, 30 Aug 2009 13:49:29 -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> In-Reply-To: <00a401ca298f$fe348f40$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: Sun, 30 Aug 2009 20:49:11 -0000 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). 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 mbj@tail-f.com Mon Aug 31 00: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 C12963A688D for ; Mon, 31 Aug 2009 00:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.112, 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 BlsjIhloAVC7 for ; Mon, 31 Aug 2009 00:40:53 -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 634EE3A682B for ; Mon, 31 Aug 2009 00:40:53 -0700 (PDT) Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 3D84076C5A8; Mon, 31 Aug 2009 09:41:02 +0200 (CEST) Date: Mon, 31 Aug 2009 09:41:01 +0200 (CEST) Message-Id: <20090831.094101.84226799.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A9AE5D9.7020902@netconfcentral.com> References: <200908282045.n7SKjRaU038511@idle.juniper.net> <00a401ca298f$fe348f40$0601a8c0@allison> <4A9AE5D9.7020902@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] 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: Mon, 31 Aug 2009 07:40:56 -0000 Andy Bierman wrote: > 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. I think it is much simpler than this. If there is a config leaf ifMTU, and it is not set, but the device operationally uses some value depending on hw, this does NOT mean that an instance of ifMTU was created by the server. It is a separate thing (which can be handled today by having a separate ifMTU-oper leaf, as has been said before). So "if an instance exists because the server created it" then it *is* config. The example we have used is the user's uid. If it is not provided, the server fills in a value, and this value is part of the config data store, just as if the client set the value in the first place. > So it MUST be retrievable, > in order to support applications (NETCONF was chartered > to get away from screen-scraping). > > 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 . But look at Phil's "duplex" example. If it is set to 'auto', it exists in the config, and this is the value that will be returned in a reply to or , even though the operational value is "half". To extend the example, suppose its default value is "auto", and it does not exist in the config. The operational value is "half", but the best you can get in a reply is still "auto". So I don't think that what you propose above actually solves the problem with operational data. /martin From andy@netconfcentral.com Mon Aug 31 01:18: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 DF1153A682B for ; Mon, 31 Aug 2009 01:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 mfrZPpyxnXAc for ; Mon, 31 Aug 2009 01:18:39 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id E72433A694D for ; Mon, 31 Aug 2009 01:18:38 -0700 (PDT) Received: from [68.142.194.243] by n17.bullet.mail.mud.yahoo.com with NNFMP; 31 Aug 2009 08:18:47 -0000 Received: from [68.142.201.242] by t1.bullet.mud.yahoo.com with NNFMP; 31 Aug 2009 08:18:47 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 31 Aug 2009 08:18:47 -0000 X-Yahoo-Newman-Id: 815193.39108.bm@omp403.mail.mud.yahoo.com Received: (qmail 86772 invoked from network); 31 Aug 2009 08:18:47 -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; 31 Aug 2009 08:18:47 -0000 X-YMail-OSG: Z3u9EhEVM1kKfHo9039FRSFcffDIDDwubU._sfvIEnfnGN6a.mNHf72YvQv_s5OkH3BTEF3Io3nd9My.MJpfY5icrn0FsMpRwIv.PtXhTfyr33oy1yrxk3.BVORnGJynMCq7wnEmQifZCIVi0uQd9qeIpRgbPWVKglOjBXP25ZEiIVZmHmeF.riMSUqDZqc4fGkTDLmd00Q5yG_qEt9LX8_Y6K25PlWOPE0fQXjg1hd6VDtVI9osaYkuhdxf1Hk7oGheBxuxDzMw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9B86FA.1040804@netconfcentral.com> Date: Mon, 31 Aug 2009 01:16:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <200908282045.n7SKjRaU038511@idle.juniper.net> <00a401ca298f$fe348f40$0601a8c0@allison> <4A9AE5D9.7020902@netconfcentral.com> <20090831.094101.84226799.mbj@tail-f.com> In-Reply-To: <20090831.094101.84226799.mbj@tail-f.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: Mon, 31 Aug 2009 08:18:40 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> 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. > > I think it is much simpler than this. If there is a config leaf > ifMTU, and it is not set, but the device operationally uses some value > depending on hw, this does NOT mean that an instance of ifMTU was > created by the server. It is a separate thing (which can be handled > today by having a separate ifMTU-oper leaf, as has been said before). > > So "if an instance exists because the server created it" then it *is* > config. The example we have used is the user's uid. If it is not > provided, the server fills in a value, and this value is part of the > config data store, just as if the client set the value in the first > place. > >> So it MUST be retrievable, >> in order to support applications (NETCONF was chartered >> to get away from screen-scraping). >> >> 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 . > > But look at Phil's "duplex" example. If it is set to 'auto', it > exists in the config, and this is the value that will be returned in a > reply to or , even though the operational value is > "half". > > To extend the example, suppose its default value is "auto", and it > does not exist in the config. The operational value is "half", but > the best you can get in a reply is still "auto". > this corner case is a red herring. One can always design the knob differently, or use an oper/admin pair. > So I don't think that what you propose above actually solves the > problem with operational data. > I am not suggesting that the email I referenced in any way represents a solution proposal. I am suggesting that config = 2 states is not complete, but it's what the standard has right now. I can live with that, as long as all servers stick to the YANG definition of a database. There will be corner cases in which the server will be forced to use 2 leafs (oper/admin) or forced to return server-assigned leaf instances because the server is actually using some value built into the code somehow. NETCONF/YANG is not useful enough for the client unless all the standard operations apply to all the YANG clauses in a tightly specified and deterministic manner. It doesn't really matter that much what the proprietary CLI world uses for humans to manage devices, because we need a standard that supports an application programmatic interface, and that is why NETCONF was chartered. > > /martin > Andy From david.partain@ericsson.com Mon Aug 31 02:26: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 5D3DF3A68EA for ; Mon, 31 Aug 2009 02:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, 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 GjwBeuUUgonE for ; Mon, 31 Aug 2009 02:26:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3A7983A6813 for ; Mon, 31 Aug 2009 02:26:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7bcbae000007452-e6-4a9b9745e5cc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id ED.98.29778.5479B9A4; Mon, 31 Aug 2009 11:26:29 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:26:17 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:26:17 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 31 Aug 2009 11:26:16 +0200 User-Agent: KMail/1.9.10 References: <200908241333.n7ODX6KL091523@idle.juniper.net> In-Reply-To: <200908241333.n7ODX6KL091523@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908311126.16613.david.partain@ericsson.com> X-OriginalArrivalTime: 31 Aug 2009 09:26:17.0509 (UTC) FILETIME=[17CB2D50:01CA2A1D] 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: Mon, 31 Aug 2009 09:26:38 -0000 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. David From lhotka@cesnet.cz Mon Aug 31 06: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 AFA643A69EF for ; Mon, 31 Aug 2009 06:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.064, 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 NP0-BkYtw2dR for ; Mon, 31 Aug 2009 06:35:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9D1AE28C26E for ; Mon, 31 Aug 2009 06:35:29 -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 551B8D800CE; Mon, 31 Aug 2009 15:35:35 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090830.203553.171621683.mbj@tail-f.com> References: <4A9A2DA7.9020505@netconfcentral.com> <20090830.203553.171621683.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 31 Aug 2009 15:35:33 +0200 Message-Id: <1251725733.12309.78.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org 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: Mon, 31 Aug 2009 13:35:30 -0000 Martin Bjorklund píše v Ne 30. 08. 2009 v 20:35 +0200: > Andy Bierman wrote: > > Hi, > > > > ops-nm: 2007-06-06 > > http://www.ietf.org/mail-archive/web/ops-nm/current/msg00105.html > > > > > > netconf: 2007-06-08 > > http://www.ietf.org/mail-archive/web/netconf/current/msg02591.html > > > > > > I guess I am irritable about this 'config/state' issue > > because I brought up this exact issue at least 2 years > > ago, and I was told I was wrong -- there are only 2 states. > > > > I brought up the issue again with the YANG design team and > > was told I was wrong again -- no, we only need a boolean. > > > > I had something called 'transient config' in NCX, long before YANG. > > IMO, it exactly describes the 3rd state (see 1st msg above). > > > > Instead of config=true/false, NCX had config=config/tconfig/state. > > > > Transient config can be set at any time by the client or the > > server, but it is never saved in NV-storage. > > > > Maybe the terminology needs work, but the mechanism exactly > > says what Juergen wants -- to edit ifMtu but not save it > > as part of the configuration. > > I don't think this would solve the problem. In the ifMtu case, the > problem is that even if no such leaf exists in the config, the device > will still operationally choose a proper value. As another example, This can still be understood in two different ways: either the server sets only the operational value and the config parameter remains unset, or it sets the config parameter and the operational one gets set to the same value as a result if this. The recent examples demonstrate various interactions between config and operational parameters, e.g. - IP address configured either manually (from a config item) or via DHCP - use global value if local is not set (hold-time example) - operational routing table is a union of static routes (config item) and routes obtained from routing protocols These relations between config and operational items seem to be quite important from the data modeling point of view - but can we express all possible variants? Lada > if the "duplex" leaf is configured to the value 'auto', the > operationally choosen value might be 'half'. This is not transient > config. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Aug 31 07:41: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 98C153A6E53 for ; Mon, 31 Aug 2009 07:41:05 -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 ScVw4JXYh6LD for ; Mon, 31 Aug 2009 07:41:04 -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 7758D3A6838 for ; Mon, 31 Aug 2009 07:41: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 3EAC476C59C; Mon, 31 Aug 2009 16:41:14 +0200 (CEST) Date: Mon, 31 Aug 2009 16:41:13 +0200 (CEST) Message-Id: <20090831.164113.51289808.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1251725733.12309.78.camel@missotis> References: <4A9A2DA7.9020505@netconfcentral.com> <20090830.203553.171621683.mbj@tail-f.com> <1251725733.12309.78.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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org 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: Mon, 31 Aug 2009 14:41:05 -0000 Ladislav Lhotka wrote: > This can still be understood in two different ways: either the server > sets only the operational value and the config parameter remains unset, > or it sets the config parameter and the operational one gets set to the > same value as a result if this. IMO the latter would be very confusing. You set 'duplex' to 'auto' and you do a get-config, maybe for archival purposes. If you get back anything but 'auto', it would be incorrect. > The recent examples demonstrate various interactions between config and > operational parameters, e.g. > > - IP address configured either manually (from a config item) or via DHCP > - use global value if local is not set (hold-time example) > - operational routing table is a union of static routes (config item) > and routes obtained from routing protocols > > These relations between config and operational items seem to be quite > important from the data modeling point of view - but can we express all > possible variants? It can be done today using standard techniques with duplicate objects (ifMTU and ifMTU-oper etc). 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 YANG 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. /martin From lhotka@cesnet.cz Mon Aug 31 08:56: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 A80F228C31D for ; Mon, 31 Aug 2009 08:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.064, 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 L9Hx83EeEgmn for ; Mon, 31 Aug 2009 08:56:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A51F928C24E for ; Mon, 31 Aug 2009 08:56:25 -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 958AED800CE; Mon, 31 Aug 2009 17:56:36 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090831.164113.51289808.mbj@tail-f.com> References: <4A9A2DA7.9020505@netconfcentral.com> <20090830.203553.171621683.mbj@tail-f.com> <1251725733.12309.78.camel@missotis> <20090831.164113.51289808.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 31 Aug 2009 17:56:34 +0200 Message-Id: <1251734194.12309.102.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org 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: Mon, 31 Aug 2009 15:56:26 -0000 Martin Bjorklund píše v Po 31. 08. 2009 v 16:41 +0200: > Ladislav Lhotka wrote: > > This can still be understood in two different ways: either the server > > sets only the operational value and the config parameter remains unset, > > or it sets the config parameter and the operational one gets set to the > > same value as a result if this. > > IMO the latter would be very confusing. You set 'duplex' to 'auto' > and you do a get-config, maybe for archival purposes. If you get back > anything but 'auto', it would be incorrect. Maybe in this case, in other cases it may be appropriate, e.g. for initial (static) IP address. > > > The recent examples demonstrate various interactions between config and > > operational parameters, e.g. > > > > - IP address configured either manually (from a config item) or via DHCP > > - use global value if local is not set (hold-time example) > > - operational routing table is a union of static routes (config item) > > and routes obtained from routing protocols > > > > These relations between config and operational items seem to be quite > > important from the data modeling point of view - but can we express all > > possible variants? > > It can be done today using standard techniques with duplicate objects > (ifMTU and ifMTU-oper etc). You can use leafref in YANG if they are directly coupled, but the more complex scenarios cannot be easily captured, except in descriptions - and I am not saying they should be, unless we have a really flexible way to do it. > > 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 YANG > 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. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Aug 31 09:45: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 1B19728C3B0 for ; Mon, 31 Aug 2009 09:45:23 -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 V4SibZSigCWi for ; Mon, 31 Aug 2009 09:45:21 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id AF1BC28C3AB for ; Mon, 31 Aug 2009 09:45:21 -0700 (PDT) Received: from [68.142.200.225] by n18.bullet.mail.mud.yahoo.com with NNFMP; 31 Aug 2009 16:45:31 -0000 Received: from [68.142.201.248] by t6.bullet.mud.yahoo.com with NNFMP; 31 Aug 2009 16:45:31 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 31 Aug 2009 16:45:31 -0000 X-Yahoo-Newman-Id: 83818.11903.bm@omp409.mail.mud.yahoo.com Received: (qmail 28337 invoked from network); 31 Aug 2009 16:45:30 -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; 31 Aug 2009 16:45:30 -0000 X-YMail-OSG: X2hbAm8VM1kd0.4DKsDGagPfk7E82KL7kTL4qq5kvfZTO0W3mOqDS_NB5347eHeTPagNuITBa2WP4ghh081QLkRX3mWxPlp9ZB_Sw1XPS6sKVzvOW5THgaduFUWFGRnJ5PMCThm6A0pqXRU0tTpkY07TuQ.bmt03.1f0CD6y8ZkZ.3Bd6EHt72x1veKr6mQ8ZUcaym2xeRxaNIgokLgP4UEEoO2DgwtcNXIQ6Ni8ZF.x5OaQaxjM7Y1qqUlIb8SiG0c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9BFE38.6000104@netconfcentral.com> Date: Mon, 31 Aug 2009 09:45:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A9A2DA7.9020505@netconfcentral.com> <20090830.203553.171621683.mbj@tail-f.com> <1251725733.12309.78.camel@missotis> <20090831.164113.51289808.mbj@tail-f.com> <1251734194.12309.102.camel@missotis> In-Reply-To: <1251734194.12309.102.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org 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: Mon, 31 Aug 2009 16:45:23 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Po 31. 08. 2009 v 16:41 +0200: >> Ladislav Lhotka wrote: >>> This can still be understood in two different ways: either the server >>> sets only the operational value and the config parameter remains unset, >>> or it sets the config parameter and the operational one gets set to the >>> same value as a result if this. >> IMO the latter would be very confusing. You set 'duplex' to 'auto' >> and you do a get-config, maybe for archival purposes. If you get back >> anything but 'auto', it would be incorrect. > > Maybe in this case, in other cases it may be appropriate, e.g. for > initial (static) IP address. > >>> The recent examples demonstrate various interactions between config and >>> operational parameters, e.g. >>> >>> - IP address configured either manually (from a config item) or via DHCP >>> - use global value if local is not set (hold-time example) >>> - operational routing table is a union of static routes (config item) >>> and routes obtained from routing protocols >>> >>> These relations between config and operational items seem to be quite >>> important from the data modeling point of view - but can we express all >>> possible variants? >> It can be done today using standard techniques with duplicate objects >> (ifMTU and ifMTU-oper etc). > > You can use leafref in YANG if they are directly coupled, but the more > complex scenarios cannot be easily captured, except in descriptions - > and I am not saying they should be, unless we have a really flexible way > to do it. > >> 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 YANG >> 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. 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 andy@netconfcentral.com Mon Aug 31 09:50: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 E243C3A6D59 for ; Mon, 31 Aug 2009 09:50:43 -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 6wJg-u2MtMB5 for ; Mon, 31 Aug 2009 09:50:43 -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 293FE3A6A0E for ; Mon, 31 Aug 2009 09:50:43 -0700 (PDT) Received: (qmail 92475 invoked from network); 31 Aug 2009 16:50:50 -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; 31 Aug 2009 16:50:50 -0000 X-YMail-OSG: 4m6R6EEVM1kGFHhkfcjm9JBEZTrjSuIeD8XPLzxk2l1hAueTsA__HflDKwxKawSjnw5QvXZk9Qp2S3vloN9zCXa_M4NZBkWQgDjyCKBoFNitjB_BCHh439FM.8G9B4ESXGXkkY8_QX2vWW2o3zUik190sPdbvRZ_D1UA4LkSdp.C6LZtf7Nq3kuSARSTc4oXobljcNM0B5w7h.dgGlmUuS5LgkSpvp.Mwt6btaGY9RimhbaMIITTCHiuTVeCbasIYra0SzOI69oj2Kk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9BFF78.4080507@netconfcentral.com> Date: Mon, 31 Aug 2009 09:51:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A9A2DA7.9020505@netconfcentral.com> <20090830.203553.171621683.mbj@tail-f.com> <1251725733.12309.78.camel@missotis> <20090831.164113.51289808.mbj@tail-f.com> <1251734194.12309.102.camel@missotis> <4A9BFE38.6000104@netconfcentral.com> In-Reply-To: <4A9BFE38.6000104@netconfcentral.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org 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: Mon, 31 Aug 2009 16:50:44 -0000 Hi, > > Asking the server to deduce the value of any current leaf instance ^^^^^^ > value is the only non-starter still floating around at this time. > oops -- I meant client (trying hard to avoid manager and agent!) > >> Lada >> >>> /martin > > Andy > From lhotka@cesnet.cz Mon Aug 31 11:34: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 0671928C48B for ; Mon, 31 Aug 2009 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=0.063, 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 ccOkNJ8mloAp for ; Mon, 31 Aug 2009 11:34:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2B76628C487 for ; Mon, 31 Aug 2009 11:34:40 -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 E5B91D800EE; Mon, 31 Aug 2009 20:34:50 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A9BFE38.6000104@netconfcentral.com> References: <4A9A2DA7.9020505@netconfcentral.com> <20090830.203553.171621683.mbj@tail-f.com> <1251725733.12309.78.camel@missotis> <20090831.164113.51289808.mbj@tail-f.com> <1251734194.12309.102.camel@missotis> <4A9BFE38.6000104@netconfcentral.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 31 Aug 2009 20:34:47 +0200 Message-Id: <1251743687.12309.107.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org 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: Mon, 31 Aug 2009 18:34:41 -0000 Andy Bierman píše 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 YANG > >> 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. Lada > > 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 > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Aug 31 12:54: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 594D028C486 for ; Mon, 31 Aug 2009 12:54:08 -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 4wyutLEIITB1 for ; Mon, 31 Aug 2009 12:54:07 -0700 (PDT) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id 57A7A28C439 for ; Mon, 31 Aug 2009 12:54:07 -0700 (PDT) Received: from [68.142.200.224] by n21.bullet.mail.mud.yahoo.com with NNFMP; 31 Aug 2009 19:54:16 -0000 Received: from [68.142.201.68] by t5.bullet.mud.yahoo.com with NNFMP; 31 Aug 2009 19:54:16 -0000 Received: from [127.0.0.1] by omp420.mail.mud.yahoo.com with NNFMP; 31 Aug 2009 19:54:16 -0000 X-Yahoo-Newman-Id: 204828.58705.bm@omp420.mail.mud.yahoo.com Received: (qmail 99540 invoked from network); 31 Aug 2009 19:54:15 -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; 31 Aug 2009 19:54:15 -0000 X-YMail-OSG: 22a77e0VM1mIAC3GKC2hD0iaZwFHDeGSo8pDlqV0LgXFtmaouhyfGkPrwdpcEQrWeCA4AzrOR7vhMpHfAh.mmFyyCLQTTBi9XxVg9MUl0QVc0YNsDeJPJO1CFEJsbGwM4uamBNO3xvaTeKrUBFxlL7M4C3GbOhqyWI5G4klbHycUP1jadA6Ur4TPJAccv6F.ErHqdbb272hNWx5kquqcrBQUHDX_jR8PJV0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9C29F9.6060901@netconfcentral.com> Date: Mon, 31 Aug 2009 12:52:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <4A9A2DA7.9020505@netconfcentral.com> <20090830.203553.171621683.mbj@tail-f.com> <1251725733.12309.78.camel@missotis> <20090831.164113.51289808.mbj@tail-f.com> <1251734194.12309.102.camel@missotis> <4A9BFE38.6000104@netconfcentral.com> <1251743687.12309.107.camel@missotis> In-Reply-To: <1251743687.12309.107.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org 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: Mon, 31 Aug 2009 19:54:08 -0000 Ladislav Lhotka wrote: > Andy Bierman píše 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 YANG >>>> 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 >>