From yang-bounces@ietf.org Thu Jan 03 13:44:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAV3L-0007dV-1r; Thu, 03 Jan 2008 13:44:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAV3I-0007Rf-Vq for yang-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 13:44:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAV3C-0007Dh-5z for yang@ietf.org; Thu, 03 Jan 2008 13:44:18 -0500 Received: from smtp121.sbc.mail.sp1.yahoo.com ([69.147.64.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAV3B-0004m7-Pf for yang@ietf.org; Thu, 03 Jan 2008 13:44:18 -0500 Received: (qmail 97585 invoked from network); 3 Jan 2008 18:44:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 3 Jan 2008 18:44:17 -0000 X-YMail-OSG: dBqix5gVM1k7Jv9wcADE3.rCpkcBnWorWRrXNcKNJi_i.0BIjG1NFYycnqyCpmIeneGr_F.HWHEu4bOjHejE64xK Message-ID: <477D2D00.2010108@andybierman.com> Date: Thu, 03 Jan 2008 10:44:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [YANG] so many naming scopes X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Sec. 6.2 lists several naming scopes for various YANG constructs. Most of it seems fine, except I am concerned about the confusion factor that can result: module foo { namespace "http://example.com/foo-ns"; prefix "foo"; description "do you have anything without foo in it?"; typedef foo { type int32; } grouping foo { leaf x { type foo; } } container foo { leaf a { type foo; } uses foo; choice b { case foo { leaf c { type foo; } } case b { container d { uses foo; } } } } } Is this much flexibility such a good idea? I don't think the lack of individual naming scopes for every type of identifier has been a big problem in the SNMP world. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 03 14:50:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAW57-0006Tr-03; Thu, 03 Jan 2008 14:50:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAW55-0006Tg-C8 for yang-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 14:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAW55-0006TY-2M for yang@ietf.org; Thu, 03 Jan 2008 14:50:19 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAW54-000626-MA for yang@ietf.org; Thu, 03 Jan 2008 14:50:19 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id AD2231B80CA; Thu, 3 Jan 2008 20:50:16 +0100 (CET) Date: Thu, 03 Jan 2008 20:49:50 +0100 (CET) Message-Id: <20080103.204950.147781910.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] so many naming scopes From: Martin Bjorklund In-Reply-To: <477D2D00.2010108@andybierman.com> References: <477D2D00.2010108@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > Sec. 6.2 lists several naming scopes for various YANG constructs. > Most of it seems fine, except I am concerned about the confusion factor > that can result: > > module foo { > namespace "http://example.com/foo-ns"; > prefix "foo"; > description "do you have anything without foo in it?"; > > typedef foo { > type int32; > } > > grouping foo { > leaf x { type foo; } > } > > container foo { > leaf a { type foo; } > uses foo; > choice b { > case foo { > leaf c { type foo; } > } > case b { > container d { > uses foo; > } > } > } > } > > } > > > Is this much flexibility such a good idea? Maybe not. > I don't think the lack of individual naming scopes for every > type of identifier has been a big problem in the SNMP world. No, but I don't think we should have a single flat namespace for identifiers like SNMP has. I can live with one namespace per nesting level though. Earlier we had a separate namespace for rpcs and a separate for notifications as well, but the drawback with that was that we couldn't use 'augment' to augment these, so we had to have separate statements 'augment-rpc' and 'augment-notification'. Having a single namespace actually made 'augment' more flexible. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 03 15:19:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAWX4-0006EN-5U; Thu, 03 Jan 2008 15:19:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAWX2-0006EH-RL for yang-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 15:19:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAWX2-0006E9-He for yang@ietf.org; Thu, 03 Jan 2008 15:19:12 -0500 Received: from smtp121.sbc.mail.sp1.yahoo.com ([69.147.64.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAWX0-0007VV-7X for yang@ietf.org; Thu, 03 Jan 2008 15:19:12 -0500 Received: (qmail 78137 invoked from network); 3 Jan 2008 20:19:09 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 3 Jan 2008 20:19:09 -0000 X-YMail-OSG: oER.1A4VM1lKWYyqRnHBiKGLBQaZu8a2QeyvpFckV1KItbfcp_VhLpfwjwrzaFdOZHBMWVP9wCkcwRcDWamMXmJp Message-ID: <477D433C.1000709@andybierman.com> Date: Thu, 03 Jan 2008 12:19:08 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] so many naming scopes References: <477D2D00.2010108@andybierman.com> <20080103.204950.147781910.mbj@tail-f.com> In-Reply-To: <20080103.204950.147781910.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Sec. 6.2 lists several naming scopes for various YANG constructs. >> Most of it seems fine, except I am concerned about the confusion factor >> that can result: >> >> module foo { >> namespace "http://example.com/foo-ns"; >> prefix "foo"; >> description "do you have anything without foo in it?"; >> >> typedef foo { >> type int32; >> } >> >> grouping foo { >> leaf x { type foo; } >> } >> >> container foo { >> leaf a { type foo; } >> uses foo; >> choice b { >> case foo { >> leaf c { type foo; } >> } >> case b { >> container d { >> uses foo; >> } >> } >> } >> } >> >> } >> >> >> Is this much flexibility such a good idea? > > Maybe not. > >> I don't think the lack of individual naming scopes for every >> type of identifier has been a big problem in the SNMP world. > > No, but I don't think we should have a single flat namespace for > identifiers like SNMP has. I can live with one namespace per nesting > level though. > Yes, of course one naming scope (the term namespace is taken) amongst siblings, except nested typedef and grouping names cannot mask similar definitions within an ancestor node, or globally within the same module. (This part already in the draft.) OK: container foo { container foo { ... } } Not OK: container foo { typedef foo { type int32; } container foo { typedef foo { type int32; } // invalid! masks previous typedef leaf foo { type foo; } } } Only the top level definitions can be exported to other modules. SMIv2 rules are too restrictive for XML naming, but the ability is lost to import nested leafs like 'ifIndex' in addition to top-level objects like 'ifTable'. The schema-nodeid Xpath form must be used to access such nodes (/if:ifTable/if:ifIndex). > Earlier we had a separate namespace for rpcs and a separate for > notifications as well, but the drawback with that was that we couldn't > use 'augment' to augment these, so we had to have separate statements > 'augment-rpc' and 'augment-notification'. Having a single namespace > actually made 'augment' more flexible. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 03 23:40:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAeMJ-0006Yk-9V; Thu, 03 Jan 2008 23:40:39 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAeMH-0006YN-DQ for yang-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 23:40:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAeMH-0006YF-19 for yang@ietf.org; Thu, 03 Jan 2008 23:40:37 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAeMG-0004vG-HB for yang@ietf.org; Thu, 03 Jan 2008 23:40:36 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 03 Jan 2008 20:40:27 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 20:39:48 -0800 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 m044dg952792; Thu, 3 Jan 2008 20:39:48 -0800 (PST) (envelope-from phil@idle.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 m044ZkPE068099; Fri, 4 Jan 2008 04:35:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801040435.m044ZkPE068099@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] so many naming scopes In-reply-to: <477D433C.1000709@andybierman.com> Date: Thu, 03 Jan 2008 23:35:46 -0500 From: Phil Shafer X-OriginalArrivalTime: 04 Jan 2008 04:39:48.0684 (UTC) FILETIME=[D689E0C0:01C84E8B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >Yes, of course one naming scope (the term namespace is taken) >amongst siblings, except nested typedef and grouping names >cannot mask similar definitions within an ancestor node, >or globally within the same module. (This part already in the draft.) Isn't this dancing on the line of CLR? Where's the logic of saying "don't do that" when there's really no ambiguity? If I say "leaf foo { .. } typedef foo { .. }", my use of "type foo" is clear. Is there a situation where isn't not clear to the compiler what is meant? Are we trying to get the compiler to enforce style rules when the language proper doesn't require them? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 04 02:31:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAh1g-0007aL-T0; Fri, 04 Jan 2008 02:31:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAh1f-0007Rq-M3 for yang-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 02:31:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAh1f-0007NY-A4 for yang@ietf.org; Fri, 04 Jan 2008 02:31:31 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAh1e-0008Ei-RF for yang@ietf.org; Fri, 04 Jan 2008 02:31:31 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id C66641B80C3; Fri, 4 Jan 2008 08:31:28 +0100 (CET) Date: Fri, 04 Jan 2008 08:32:08 +0100 (CET) Message-Id: <20080104.083208.86847805.mbj@tail-f.com> To: phil@juniper.net Subject: Re: [YANG] so many naming scopes From: Martin Bjorklund In-Reply-To: <200801040435.m044ZkPE068099@idle.juniper.net> References: <477D433C.1000709@andybierman.com> <200801040435.m044ZkPE068099@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >Yes, of course one naming scope (the term namespace is taken) > >amongst siblings, except nested typedef and grouping names > >cannot mask similar definitions within an ancestor node, > >or globally within the same module. (This part already in the draft.) > > Isn't this dancing on the line of CLR? Where's the logic of saying > "don't do that" when there's really no ambiguity? If I say "leaf > foo { .. } typedef foo { .. }", my use of "type foo" is clear. > Is there a situation where isn't not clear to the compiler > what is meant? Are we trying to get the compiler to enforce > style rules when the language proper doesn't require them? One reason is the augmentation of groupings that we discussed (I'm planning to write about this disussion to the list, RSN). If we allow augment of groupings, then the grouping identifiers must share the namespace with data-defs/rpc/notifs. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 04 04:50:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAjCb-0008GO-J3; Fri, 04 Jan 2008 04:50:57 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAjCa-000872-FA for yang-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 04:50:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAjCT-0007Kq-J5 for yang@ietf.org; Fri, 04 Jan 2008 04:50:49 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAjCS-0003N7-1u for yang@ietf.org; Fri, 04 Jan 2008 04:50:49 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0F788204A8; Fri, 4 Jan 2008 10:50:47 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-60-477e01761351 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A0EEE20DE2; Fri, 4 Jan 2008 10:50:46 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 10:50:46 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 10:50:46 +0100 Message-ID: <477E0175.7010500@ericsson.com> Date: Fri, 04 Jan 2008 10:50:45 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] so many naming scopes References: <200801040435.m044ZkPE068099@idle.juniper.net> In-Reply-To: <200801040435.m044ZkPE068099@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2008 09:50:46.0453 (UTC) FILETIME=[476F7E50:01C84EB7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org While the use of many naming-scopes is understandable for the compiler is it easy to understand for the reader ? IMHO no. I like Andy's proposal. Balazs Phil Shafer wrote: > Andy Bierman writes: >> Yes, of course one naming scope (the term namespace is taken) >> amongst siblings, except nested typedef and grouping names >> cannot mask similar definitions within an ancestor node, >> or globally within the same module. (This part already in the draft.) > > Isn't this dancing on the line of CLR? Where's the logic of saying > "don't do that" when there's really no ambiguity? If I say "leaf > foo { .. } typedef foo { .. }", my use of "type foo" is clear. > Is there a situation where isn't not clear to the compiler > what is meant? Are we trying to get the compiler to enforce > style rules when the language proper doesn't require them? > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 04 07:01:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAlFA-0007YK-V9; Fri, 04 Jan 2008 07:01:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAlF9-0007Y7-TE for yang-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 07:01:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAlF9-0007Xx-IX for yang@ietf.org; Fri, 04 Jan 2008 07:01:43 -0500 Received: from smtp109.sbc.mail.mud.yahoo.com ([68.142.198.208]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAlF9-0003KU-3Z for yang@ietf.org; Fri, 04 Jan 2008 07:01:43 -0500 Received: (qmail 81814 invoked from network); 4 Jan 2008 12:01:42 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 4 Jan 2008 12:01:41 -0000 X-YMail-OSG: vykQVsQVM1mBzUwDJy9nQomds3MsJxtV6fOOV5CWanlyPUzpQzjdru.6pd6le4fj5seEsQm9o9iEqNF9lWMyhQVM3g-- Message-ID: <477E2025.7020308@andybierman.com> Date: Fri, 04 Jan 2008 04:01:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Balazs Lengyel Subject: Re: [YANG] so many naming scopes References: <200801040435.m044ZkPE068099@idle.juniper.net> <477E0175.7010500@ericsson.com> In-Reply-To: <477E0175.7010500@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel wrote: > While the use of many naming-scopes is understandable for the compiler > is it easy to understand for the reader ? IMHO no. That is my concern as well. As in any engineering decision, we have to weigh the trade-offs. How much overall value is lost by forcing DM writers to maintain one set of identifiers (using up some of the 63 chars of minimum uniqueness), vs. the confusion of having the same identifier value mean many different things, even within the same file. > I like Andy's proposal. > Balazs Andy > > Phil Shafer wrote: >> Andy Bierman writes: >>> Yes, of course one naming scope (the term namespace is taken) >>> amongst siblings, except nested typedef and grouping names >>> cannot mask similar definitions within an ancestor node, >>> or globally within the same module. (This part already in the draft.) >> >> Isn't this dancing on the line of CLR? Where's the logic of saying >> "don't do that" when there's really no ambiguity? If I say "leaf foo >> { .. } typedef foo { .. }", my use of "type foo" is clear. >> Is there a situation where isn't not clear to the compiler >> what is meant? Are we trying to get the compiler to enforce >> style rules when the language proper doesn't require them? >> >> Thanks, >> Phil >> >> >> _______________________________________________ >> YANG mailing list >> YANG@ietf.org >> https://www1.ietf.org/mailman/listinfo/yang > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 04 07:08:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAlLM-0004ux-Ot; Fri, 04 Jan 2008 07:08:08 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAlLL-0004ui-5Y for yang-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 07:08:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAlLK-0004ua-Qt for yang@ietf.org; Fri, 04 Jan 2008 07:08:06 -0500 Received: from relay.versatel.net ([62.250.3.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAlLK-0003WI-7h for yang@ietf.org; Fri, 04 Jan 2008 07:08:06 -0500 Received: (qmail 54666 invoked from network); 4 Jan 2008 12:08:03 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jan 2008 12:08:03 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "Balazs Lengyel" Subject: RE: [YANG] so many naming scopes Date: Fri, 4 Jan 2008 13:08:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <477E2025.7020308@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org > Balazs Lengyel wrote: > > While the use of many naming-scopes is understandable for the compiler > > is it easy to understand for the reader ? IMHO no. > To which Andy responded: > That is my concern as well. > > As in any engineering decision, we have to weigh the trade-offs. > How much overall value is lost by forcing DM writers to > maintain one set of identifiers (using up some of the 63 chars > of minimum uniqueness), vs. the confusion of having the same > identifier value mean many different things, even within the same file. > If the language can accept and easily handle it, then maybe we should allow it to do so and not create CLRs. A good and smart data-model-developer would/should still do the right thing and make things as clear as possible for the user/reader of the data-model. That means that one uses a style of definitions that is obvious and clear and so would not cause confusion. It is similar to using all sorts of short abbreviations/acronyms in names of variables and such versus spelling out a longer name. The longer name will make it much more readable/understandable for the new person who read the module for the first time. That does not mean we must pre-scribe that short-names/acronyms are not allowed. > > > I like Andy's proposal. So I like the underlying reasons, but I am not sure we have to enforce it in the langauge. Bert > > Balazs > > Andy > > > > > > Phil Shafer wrote: > >> Andy Bierman writes: > >>> Yes, of course one naming scope (the term namespace is taken) > >>> amongst siblings, except nested typedef and grouping names > >>> cannot mask similar definitions within an ancestor node, > >>> or globally within the same module. (This part already in the draft.) > >> > >> Isn't this dancing on the line of CLR? Where's the logic of saying > >> "don't do that" when there's really no ambiguity? If I say "leaf foo > >> { .. } typedef foo { .. }", my use of "type foo" is clear. > >> Is there a situation where isn't not clear to the compiler > >> what is meant? Are we trying to get the compiler to enforce > >> style rules when the language proper doesn't require them? > >> > >> Thanks, > >> Phil > >> > >> > >> _______________________________________________ > >> YANG mailing list > >> YANG@ietf.org > >> https://www1.ietf.org/mailman/listinfo/yang > > > > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 04 07:46:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAlwb-0002Uk-AN; Fri, 04 Jan 2008 07:46:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAlwa-0002UP-6b for yang-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 07:46:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAlwZ-0002UH-TB for yang@ietf.org; Fri, 04 Jan 2008 07:46:35 -0500 Received: from smtp110.sbc.mail.mud.yahoo.com ([68.142.198.209]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAlwZ-0001U0-Aj for yang@ietf.org; Fri, 04 Jan 2008 07:46:35 -0500 Received: (qmail 29381 invoked from network); 4 Jan 2008 12:46:34 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 4 Jan 2008 12:46:34 -0000 X-YMail-OSG: xnuoaQgVM1kWUtdijJLUUJ29fMYlz.NZjuZksqy8yMDZ8_ya8wrsvVYHlSrf5PS37eDxC_ylfRSQhuqeNYAiNBxtOQ-- Message-ID: <477E2AA9.7080003@andybierman.com> Date: Fri, 04 Jan 2008 04:46:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bert Wijnen - IETF Subject: Re: [YANG] so many naming scopes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Bert Wijnen - IETF wrote: >> Balazs Lengyel wrote: >>> While the use of many naming-scopes is understandable for the compiler >>> is it easy to understand for the reader ? IMHO no. > To which Andy responded: > >> That is my concern as well. >> >> As in any engineering decision, we have to weigh the trade-offs. >> How much overall value is lost by forcing DM writers to >> maintain one set of identifiers (using up some of the 63 chars >> of minimum uniqueness), vs. the confusion of having the same >> identifier value mean many different things, even within the same file. >> > > If the language can accept and easily handle it, then maybe we should > allow it to do so and not create CLRs. > A good and smart data-model-developer would/should still do the right > thing and make things as clear as possible for the user/reader of the > data-model. That means that one uses a style of definitions that is > obvious and clear and so would not cause confusion. > > It is similar to using all sorts of short abbreviations/acronyms in names > of variables and such versus spelling out a longer name. The longer name > will make it much more readable/understandable for the new person who > read the module for the first time. That does not mean we must pre-scribe > that short-names/acronyms are not allowed. > >>> I like Andy's proposal. > > So I like the underlying reasons, but I am not sure we have to enforce it > in the langauge. I don't mind your suggestion at all, since I already coded it the way it's defined now. It is not much more work to keep typedefs, groupings, and objects (data/rpc/notification) separate. There is a sentence in sec. 6.2 about SHOULD not have names that are different just in case. There could be another sentence that says all identifiers (of these 3 types) SHOULD be unique. IMO, standard data models do not need to overload these identifiers. There are 63 chars, instead of 32 in SMI, and (for data) it is only sibling nodes, not every node. > > Bert Andy >>> Balazs >> Andy >> >> >>> Phil Shafer wrote: >>>> Andy Bierman writes: >>>>> Yes, of course one naming scope (the term namespace is taken) >>>>> amongst siblings, except nested typedef and grouping names >>>>> cannot mask similar definitions within an ancestor node, >>>>> or globally within the same module. (This part already in the draft.) >>>> Isn't this dancing on the line of CLR? Where's the logic of saying >>>> "don't do that" when there's really no ambiguity? If I say "leaf foo >>>> { .. } typedef foo { .. }", my use of "type foo" is clear. >>>> Is there a situation where isn't not clear to the compiler >>>> what is meant? Are we trying to get the compiler to enforce >>>> style rules when the language proper doesn't require them? >>>> >>>> Thanks, >>>> Phil >>>> >>>> >>>> _______________________________________________ >>>> YANG mailing list >>>> YANG@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/yang >> >> >> _______________________________________________ >> YANG mailing list >> YANG@ietf.org >> https://www1.ietf.org/mailman/listinfo/yang >> > > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 04 19:29:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwvF-0000hX-CL; Fri, 04 Jan 2008 19:29:57 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JAwvD-0000hP-Si for yang-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 19:29:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwvD-0000hH-Gl for yang@ietf.org; Fri, 04 Jan 2008 19:29:55 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAwvD-0007Th-0n for yang@ietf.org; Fri, 04 Jan 2008 19:29:55 -0500 Received: (qmail 44046 invoked from network); 5 Jan 2008 00:29:54 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 5 Jan 2008 00:29:53 -0000 X-YMail-OSG: l9ogkoYVM1lVb_bHfbZ4EHnWz30uiBKLxi0yDCjpJoD9ZKYg Message-ID: <477ECF81.1030702@andybierman.com> Date: Fri, 04 Jan 2008 16:29:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [YANG] combining sub-modules X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, What are the rules for duplicate definitions in different submodules? Assume main module 'foo' and 3 submodules. What if sub-module A includes C, and B also include C? module foo | | +---+---+ | | A B | | C C If C has top-level definitions, or if submodules A and B simply define the same top-level nodes, then there will be duplicates (in the C case, may be different in the other case). Is the 2nd 'include C' allowed? I think so. No rules broken, no loops. Sec. 5.1 is not very clear on combining submodules to form a single conceptual module. For example, the intent is that submodules must be self-compiling, and all definitions must be local, imported, or included in the submodule. Submodule C cannot include A or B, and must not reference any definitions from A or B. None of the submodules can reference any definitions from the main module foo. This is not very clear. So the compiler needs to ignore any 'duplicate object' errors that occur from the A-C, B-C scenario, but if A and B use the same top-level object name, it is a fatal error? Top-level definitions can be imported from foo, regardless of module or submodule location. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 07 03:02:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmwi-0005f7-P3; Mon, 07 Jan 2008 03:02:56 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JBmwh-0005f1-EY for yang-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 03:02:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmwb-0005dQ-0m for yang@ietf.org; Mon, 07 Jan 2008 03:02:49 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBmwa-0008QP-LH for yang@ietf.org; Mon, 07 Jan 2008 03:02:48 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6C138A239; Mon, 7 Jan 2008 09:02:46 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31623-08-17; Mon, 7 Jan 2008 09:02:42 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 992358A250; Mon, 7 Jan 2008 09:02:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 12272459F24; Mon, 7 Jan 2008 09:02:25 +0100 (CET) Date: Mon, 7 Jan 2008 09:02:24 +0100 From: Juergen Schoenwaelder To: Phil Shafer Subject: Re: [YANG] so many naming scopes Message-ID: <20080107080224.GA8646@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , yang@ietf.org References: <477D433C.1000709@andybierman.com> <200801040435.m044ZkPE068099@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801040435.m044ZkPE068099@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 03, 2008 at 11:35:46PM -0500, Phil Shafer wrote: > Andy Bierman writes: > >Yes, of course one naming scope (the term namespace is taken) > >amongst siblings, except nested typedef and grouping names > >cannot mask similar definitions within an ancestor node, > >or globally within the same module. (This part already in the draft.) > > Isn't this dancing on the line of CLR? Where's the logic of saying > "don't do that" when there's really no ambiguity? If I say "leaf > foo { .. } typedef foo { .. }", my use of "type foo" is clear. > Is there a situation where isn't not clear to the compiler > what is meant? Are we trying to get the compiler to enforce > style rules when the language proper doesn't require them? I agree - lets not make coding styles a part of the language design. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 07 09:50:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtJO-0006Fi-Ob; Mon, 07 Jan 2008 09:50:46 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JBtJN-0006AB-Be for yang-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 09:50:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtJN-00069u-07 for yang@ietf.org; Mon, 07 Jan 2008 09:50:45 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBtJM-0000mH-Bb for yang@ietf.org; Mon, 07 Jan 2008 09:50:44 -0500 Received: (qmail 34709 invoked from network); 7 Jan 2008 14:50:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 7 Jan 2008 14:50:43 -0000 X-YMail-OSG: iw3J9rYVM1mPmfgOuUfa9p3tToXhqew4fP4jVe9MQzUDY4gN Message-ID: <47823C44.5050703@andybierman.com> Date: Mon, 07 Jan 2008 06:50:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer , Andy Bierman , yang@ietf.org Subject: Re: [YANG] so many naming scopes References: <477D433C.1000709@andybierman.com> <200801040435.m044ZkPE068099@idle.juniper.net> <20080107080224.GA8646@elstar.local> In-Reply-To: <20080107080224.GA8646@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Jan 03, 2008 at 11:35:46PM -0500, Phil Shafer wrote: >> Andy Bierman writes: >>> Yes, of course one naming scope (the term namespace is taken) >>> amongst siblings, except nested typedef and grouping names >>> cannot mask similar definitions within an ancestor node, >>> or globally within the same module. (This part already in the draft.) >> Isn't this dancing on the line of CLR? Where's the logic of saying >> "don't do that" when there's really no ambiguity? If I say "leaf >> foo { .. } typedef foo { .. }", my use of "type foo" is clear. >> Is there a situation where isn't not clear to the compiler >> what is meant? Are we trying to get the compiler to enforce >> style rules when the language proper doesn't require them? > > I agree - lets not make coding styles a part of the language design. > Then let's change this sentence in sec 6.2: All identifiers defined in a namespace MUST be unique and SHOULD NOT only differ in case. Change to: All identifiers defined in a namespace MUST be unique. > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 07 12:49:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw6O-0004iz-2p; Mon, 07 Jan 2008 12:49:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JBw6N-0004ao-1W for yang-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 12:49:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw6M-0004YG-Mi for yang@ietf.org; Mon, 07 Jan 2008 12:49:30 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBw6M-00041l-8r for yang@ietf.org; Mon, 07 Jan 2008 12:49:30 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Jan 2008 09:49:25 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:49:19 -0800 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 m07HnJ926314; Mon, 7 Jan 2008 09:49:19 -0800 (PST) (envelope-from phil@idle.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 m07HjTOI085891; Mon, 7 Jan 2008 17:45:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801071745.m07HjTOI085891@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] combining sub-modules In-reply-to: <477ECF81.1030702@andybierman.com> Date: Mon, 07 Jan 2008 12:45:29 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Jan 2008 17:49:19.0685 (UTC) FILETIME=[A1183F50:01C85155] X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >So the compiler needs to ignore any 'duplicate object' errors >that occur from the A-C, B-C scenario, but if A and B use >the same top-level object name, it is a fatal error? >Top-level definitions can be imported from foo, regardless >of module or submodule location. The decision is up to the compiler, but my take is that the compiler should parse modules and submodules individually, keeping the data organized into modules and submodules. When it sees an import or include for something it's already parsed, it can reference the parsed data, not redo the work. So "ignore" in a sense, but not in the #once sense. If A and B both define the same top-level object name, it's an error, since they are in the same namespace. B can augment A's objects (and vice versa), but not redefine them. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 07 19:38:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC2UC-0000Tx-Ue; Mon, 07 Jan 2008 19:38:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JC2UB-0000Ts-QE for yang-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 19:38:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC2UB-0000Tk-1V for yang@ietf.org; Mon, 07 Jan 2008 19:38:31 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JC2UA-0003qT-Hg for yang@ietf.org; Mon, 07 Jan 2008 19:38:31 -0500 Received: (qmail 94323 invoked from network); 8 Jan 2008 00:38:30 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 8 Jan 2008 00:38:29 -0000 X-YMail-OSG: u76rpoUVM1l5fyA.dYAN.Ugl6R45iD2CpHRTVX0qp6U1DM3s Message-ID: <4782C606.5010109@andybierman.com> Date: Mon, 07 Jan 2008 16:38:30 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [YANG] key clause issues X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I have a few concerns with the key clause... From -00: 7.8.2. The list's key Statement The "key" statement, which MUST be present if the list represents configuration, and MAY be present otherwise, takes as an argument a string which specifies a space separated list of leaf identifiers of this list. A leaf identifier MUST NOT appear more than once in the key. Issue 1) From an interoperability perspective, the key needs to be defined any time there are multiple named instances of an element (i.e., every list). Config vs. read-only is irrelevant. Operators and manager applications need to know how list entries are indexed for interoperability. SNMP is mostly for monitoring. I can't imagine how operators and DM readers would be able to talk about tables and rows if all the INDEX clauses were removed from read-only tables. Issue 2) Why is the CLR about a leaf appearing more than once in the key needed? It should be up to the DM writer to decide if this makes sense or not: list addr-pairs { key "addr-type src-addr addr-type dest-addr"; leaf addr-type { type ietf:InetAddressType; } leaf src-addr { type ietf:InetAddress; } leaf dest-addr { type ietf:InetAddress; } // ... rest of list entry } Why is this illegal? It may be bad practice (according to RFC 4001), but should it be illegal? Issue 3) From the ABNF: key-stmt = key-keyword sep key-arg-str stmtend key-arg-str = < a string which matches the rule key-arg > key-arg = 1*(identifier sep) Why is the key statement limited to top-level sibling nodes within the list? The unique-stmt (and keyref) allows descendant-schema-nodeid instead of just identifier: unique "foo/item1 foo/bar/item2"; With this constraint on the key-stmt, YANG cannot support indexing using reusable containers. (There needs to be exactly one instance of the key component per list entry, so 'list' and 'choice' nodes cannot be used within a key.) There are many use-cases, such as reusable (addr-type, addr) or (addr, port) data types. The whole point of the container is that it provides the DM writer with an abstraction that represents a containerized set of objects, bound together for some reason. YANG has no support direct support for reusable complex types, but there is a workaround with grouping/uses: grouping addr-pair { leaf addr-type { type ietf:InetAddressType; } leaf addr { type ietf:InetAddress; } } list addr-pairs { key "src/addr-type src/addr dest/addr-type dest/addr"; container src { uses addr-pair; } container dest { uses addr-pair; } // ... rest of list entry } This sort of indexing is very useful and needs to be supported by YANG. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 05:29:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBiU-0002Vo-Rf; Tue, 08 Jan 2008 05:29:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCBiT-0002K4-5c for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 05:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBiL-0001Jt-CQ for yang@ietf.org; Tue, 08 Jan 2008 05:29:45 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCBiJ-0004e2-Gb for yang@ietf.org; Tue, 08 Jan 2008 05:29:45 -0500 X-Trace: 14620622/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAP7egkc+8aMG/2dsb2JhbACpIQ Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 08 Jan 2008 10:29:42 +0000 Received: from pc6 (1Cust147.tnt24.lnd4.gbr.da.uu.net [62.188.151.147]) by astro.systems.pipex.net (Postfix) with SMTP id 3917CE000089; Tue, 8 Jan 2008 10:29:23 +0000 (GMT) Message-ID: <011a01c851d8$cc8652c0$0601a8c0@pc6> From: "tom.petch" To: "Bert Wijnen - IETF" , "Andy Bierman" References: Subject: Re: [YANG] so many naming scopes Date: Tue, 8 Jan 2008 09:40:45 +0100 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 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org ----- Original Message ----- From: "Bert Wijnen - IETF" To: "Andy Bierman" ; "Balazs Lengyel" Cc: Sent: Friday, January 04, 2008 1:08 PM Subject: RE: [YANG] so many naming scopes > > Balazs Lengyel wrote: > > > While the use of many naming-scopes is understandable for the compiler > > > is it easy to understand for the reader ? IMHO no. > > > To which Andy responded: > > > That is my concern as well. > > > > As in any engineering decision, we have to weigh the trade-offs. > > How much overall value is lost by forcing DM writers to > > maintain one set of identifiers (using up some of the 63 chars > > of minimum uniqueness), vs. the confusion of having the same > > identifier value mean many different things, even within the same file. > > > > If the language can accept and easily handle it, then maybe we should > allow it to do so and not create CLRs. > A good and smart data-model-developer would/should still do the right > thing and make things as clear as possible for the user/reader of the > data-model. That means that one uses a style of definitions that is > obvious and clear and so would not cause confusion. > Agree absolutely, but, sadly, developers may not be either good or smart or both. And your definition of smart may not be mine, it may be someone who is so clever that they come up with something that is incomprehensible to the mere mortals who inherit what they have produced. A goodly part of my coding has been maintenance, having to reverse engineer the existing language before being able to change it; the best developers produce something that is so simple, so obvious that everything thinks 'I could have done that' - except that they couldn't. The worst developers - who are often very clever - produce something that needs a Ph D in Philosophy to unravel. There are languages where no word is reserved, where the same symbol(word) can be used for label, type, module etc. XML is arguable worse with the ability to start a fresh namespace on alternate lines. These belong in the bin. So, I think that having restraints is a good thing, for the benefit of the good and smart maintainers who have to put up with the output of diabolical developers. The number of discrete naming scopes that can appear in a 200-line module should be severely restricted. Tom Petch > It is similar to using all sorts of short abbreviations/acronyms in names > of variables and such versus spelling out a longer name. The longer name > will make it much more readable/understandable for the new person who > read the module for the first time. That does not mean we must pre-scribe > that short-names/acronyms are not allowed. > > > > > > I like Andy's proposal. > > So I like the underlying reasons, but I am not sure we have to enforce it > in the langauge. > > Bert > > > Balazs > > > > Andy > > > > > > > > > > Phil Shafer wrote: > > >> Andy Bierman writes: > > >>> Yes, of course one naming scope (the term namespace is taken) > > >>> amongst siblings, except nested typedef and grouping names > > >>> cannot mask similar definitions within an ancestor node, > > >>> or globally within the same module. (This part already in the draft.) > > >> > > >> Isn't this dancing on the line of CLR? Where's the logic of saying > > >> "don't do that" when there's really no ambiguity? If I say "leaf foo > > >> { .. } typedef foo { .. }", my use of "type foo" is clear. > > >> Is there a situation where isn't not clear to the compiler > > >> what is meant? Are we trying to get the compiler to enforce > > >> style rules when the language proper doesn't require them? > > >> > > >> Thanks, > > >> Phil > > >> > > >> > > >> _______________________________________________ > > >> YANG mailing list > > >> YANG@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/yang > > > > > > > > > > > _______________________________________________ > > YANG mailing list > > YANG@ietf.org > > https://www1.ietf.org/mailman/listinfo/yang > > > > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 05:30:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBix-0002xm-3x; Tue, 08 Jan 2008 05:30:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCBiv-0002xe-QH for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 05:30:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBiv-0002xW-Fx for yang@ietf.org; Tue, 08 Jan 2008 05:30:21 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCBiv-0006q7-3B for yang@ietf.org; Tue, 08 Jan 2008 05:30:21 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33B8F21896; Tue, 8 Jan 2008 11:29:14 +0100 (CET) X-AuditID: c1b4fb3e-afea1bb00000459d-7a-4783507ad099 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1D5FB2048F; Tue, 8 Jan 2008 11:29:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 11:29:14 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 11:29:13 +0100 Message-ID: <47835079.9000706@ericsson.com> Date: Tue, 08 Jan 2008 11:29:13 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman Subject: Re: [YANG] key clause issues References: <4782C606.5010109@andybierman.com> In-Reply-To: <4782C606.5010109@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2008 10:29:13.0987 (UTC) FILETIME=[507C3D30:01C851E1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org See below PS.: The reason for the existence of YANG is that it is more simple then XSD." quote from Balazs Andy Bierman wrote: > Hi, > > I have a few concerns with the key clause... ... > Issue 2) > > Why is the CLR about a leaf appearing more than once in the key needed? > It should be up to the DM writer to decide if this makes sense or not: > > list addr-pairs { > key "addr-type src-addr addr-type dest-addr"; > > leaf addr-type { type ietf:InetAddressType; } > leaf src-addr { type ietf:InetAddress; } > leaf dest-addr { type ietf:InetAddress; } > // ... rest of list entry > } > > Why is this illegal? > It may be bad practice (according to RFC 4001), but should it be > illegal? [BALAZS]: When the user/programmer uses this in an edit-config he might think that the two add-types are two distinct pieces of data, while they are actually the same. Would the user actually have to provide the addr-type twice in a netconf message? How do you handle if the two provided values in a netconf request are not the same? _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 06:12:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCCNl-0004Uh-8H; Tue, 08 Jan 2008 06:12:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCCNj-0004Ub-Q3 for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 06:12:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCCNj-0004UT-F8 for yang@ietf.org; Tue, 08 Jan 2008 06:12:31 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCCNi-00088s-P5 for yang@ietf.org; Tue, 08 Jan 2008 06:12:31 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id F14871B80DA; Tue, 8 Jan 2008 12:12:28 +0100 (CET) Date: Tue, 08 Jan 2008 12:11:47 +0100 (CET) Message-Id: <20080108.121147.221068658.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] key clause issues From: Martin Bjorklund In-Reply-To: <4782C606.5010109@andybierman.com> References: <4782C606.5010109@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Andy, Andy Bierman wrote: > Issue 1) > > From an interoperability perspective, the key needs to > be defined any time there are multiple named instances > of an element (i.e., every list). Exactly what will not be interoperable by not having keys for non-config data? (One problem might be how to define access control. W/o keys you might have to fall back to generic XPath, which we want to avoid...) > Config vs. read-only is irrelevant. > Operators and manager applications need to know how list entries > are indexed for interoperability. SNMP is mostly for monitoring. > I can't imagine how operators and DM readers would be able to talk about > tables and rows if all the INDEX clauses were removed from read-only tables. In SNMP, the INDEX is needed by the protocol. Not so in NETCONF for non-config data. > Issue 2) > > Why is the CLR about a leaf appearing more than once in the key needed? > It should be up to the DM writer to decide if this makes sense or not: > > list addr-pairs { > key "addr-type src-addr addr-type dest-addr"; What does this mean? What is the difference between this and: key "addr-type src-addr dest-addr"; What does an instance identifier for your example look like? > Issue 3) > Why is the key statement limited to top-level sibling nodes > within the list? Several reasons. Have you seen any CLIs with arbitrarly deep keys? (is it really needed?) What does this mean: list foo { key "a/b/c"; container a { container b { precense "..."; leaf c; } } Or this: list foo { key "a/b/c"; container a { list b { ... leaf c; } } Or this: list foo { key "a/b"; container a { choice x { leaf b; leaf c; } } Also, by allowing deep keys, you force an agent implementation to do buffering of - in the worst case - the entire configuration. You influence the protocol characteristics to the worse. W/o deep keys implementations _can_ do minimal buffering, and thus make the NETCONF protocol usable in smaller devices. I know at least three implementations that work this way today (and I know one that does buffering). > With this constraint on the key-stmt, YANG cannot support > indexing using reusable containers. (There needs to be > exactly one instance of the key component per list entry, > so 'list' and 'choice' nodes cannot be used within a key.) I can also argue that this is an CLR. Why don't you allow: list foo { key address; container address { choice type { leaf ipv4address; leaf ipv6address; leaf name; }; leaf port; } } /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 08:24:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCERg-0003Wu-4L; Tue, 08 Jan 2008 08:24:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCERe-0003Pw-RV for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 08:24:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCERe-0003PI-AN for yang@ietf.org; Tue, 08 Jan 2008 08:24:42 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCERd-0008GR-SW for yang@ietf.org; Tue, 08 Jan 2008 08:24:42 -0500 Received: (qmail 47671 invoked from network); 8 Jan 2008 13:24:41 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 8 Jan 2008 13:24:40 -0000 X-YMail-OSG: f.eDjjsVM1l_glSO_vwzUjRycCUA9FvsKn_bh6n6.r_S5BD8 Message-ID: <47837999.8090305@andybierman.com> Date: Tue, 08 Jan 2008 05:24:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Balazs Lengyel Subject: Re: [YANG] key clause issues References: <4782C606.5010109@andybierman.com> <47835079.9000706@ericsson.com> In-Reply-To: <47835079.9000706@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel wrote: > See below > > PS.: > The reason for the existence of YANG is that it is more simple then > XSD." quote from Balazs > > Andy Bierman wrote: >> Hi, >> >> I have a few concerns with the key clause... > ... > >> Issue 2) >> >> Why is the CLR about a leaf appearing more than once in the key needed? >> It should be up to the DM writer to decide if this makes sense or not: >> >> list addr-pairs { >> key "addr-type src-addr addr-type dest-addr"; >> >> leaf addr-type { type ietf:InetAddressType; } >> leaf src-addr { type ietf:InetAddress; } >> leaf dest-addr { type ietf:InetAddress; } >> // ... rest of list entry >> } >> >> Why is this illegal? >> It may be bad practice (according to RFC 4001), but should it be >> illegal? > [BALAZS]: When the user/programmer uses this in an edit-config he might > think that the two add-types are two distinct pieces of data, while they > are actually the same. > Why would they think that? The path to the node (/addr-pairs/addr-type) is the same. That is enough info for the manager to know they are the same object. > Would the user actually have to provide the addr-type twice in a netconf > message? no -- the key is conceptual -- not actually identifiable in any NETCONF PDU as a key. > How do you handle if the two provided values in a netconf request are > not the same? The point of this DM design would be that the addr-pairs are always the same addr-type so listed it twice is always redundant. If the addr-pairs could ever be different addr types for each addr, then a different table design would be used. We need to give the DM writer the tools to make good decisions. We do not need a ton of CLRs that assume the DM writer does not know what to do. CLRs should be used when the consensus is that more often than not, bad things will happen without the CLR. What bad things happen by not forbidding a key component from appearing more than once? > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 08:57:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCExF-00022p-Ct; Tue, 08 Jan 2008 08:57:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCExE-00022j-IL for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 08:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCExE-00022b-8f for yang@ietf.org; Tue, 08 Jan 2008 08:57:20 -0500 Received: from smtp101.sbc.mail.mud.yahoo.com ([68.142.198.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCExC-0000q7-B0 for yang@ietf.org; Tue, 08 Jan 2008 08:57:20 -0500 Received: (qmail 63273 invoked from network); 8 Jan 2008 13:57:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 8 Jan 2008 13:57:16 -0000 X-YMail-OSG: tO7APYgVM1lvFRAJynxZFVMTr8thUeY4YOfMAQx.BnfFdUoB Message-ID: <4783813D.5030104@andybierman.com> Date: Tue, 08 Jan 2008 05:57:17 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] key clause issues References: <4782C606.5010109@andybierman.com> <20080108.121147.221068658.mbj@tail-f.com> In-Reply-To: <20080108.121147.221068658.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Hi Andy, > > Andy Bierman wrote: >> Issue 1) >> >> From an interoperability perspective, the key needs to >> be defined any time there are multiple named instances >> of an element (i.e., every list). > > Exactly what will not be interoperable by not having keys for > non-config data? > The feature intent needs to be explained in the draft. If a list has no key defined, then that means that there is no distinction in the agent between any of the entries, other than their relative position (foo[1], foo[2], etc.) If this is true, and the manager knows that, then there is no problem leaving out the key. (Other DMLs call this multiple instances of a container, not a list though). But if the agent has some way of identifying list entries, other than their relative position, then a key MUST be specified. (Is this what the draft intends?) > (One problem might be how to define access control. W/o keys you > might have to fall back to generic XPath, which we want to avoid...) > >> Config vs. read-only is irrelevant. >> Operators and manager applications need to know how list entries >> are indexed for interoperability. SNMP is mostly for monitoring. >> I can't imagine how operators and DM readers would be able to talk about >> tables and rows if all the INDEX clauses were removed from read-only tables. > > In SNMP, the INDEX is needed by the protocol. Not so in NETCONF for > non-config data. Not true at all. If the agent is using named entries instead of position-identified entries, the manager needs to know. Consider any XML table like the ifTable counters. What if the agent has entries for interfaces 1, 2, and 3, but after awhile, interface 2 is deleted. If the agent knows about 'ifIndex', but not the manager, how well do you think the manager application will handle this common scenario? Config vs. non-config is irrelevant here. Identification via named keys or identification via node position is the issue. > > >> Issue 2) >> >> Why is the CLR about a leaf appearing more than once in the key needed? >> It should be up to the DM writer to decide if this makes sense or not: >> >> list addr-pairs { >> key "addr-type src-addr addr-type dest-addr"; > > What does this mean? What is the difference between this and: > > key "addr-type src-addr dest-addr"; > > What does an instance identifier for your example look like? > This table obviously cannot use the nested address. By design, it uses separated fields. > >> Issue 3) >> Why is the key statement limited to top-level sibling nodes >> within the list? > > Several reasons. Have you seen any CLIs with arbitrarly deep keys? > (is it really needed?) The CLR is simple -- just like the use-case. Only static container nodes can be listed as interior nodes in a key. All your fabricated cases below are invalid. The key indicates the mandatory naming components for the list entry. All key components MUST be present in every list entry. > > What does this mean: > > list foo { > key "a/b/c"; > container a { > container b { > precense "..."; > leaf c; > } > } > > Or this: > > list foo { > key "a/b/c"; > container a { > list b { > ... > leaf c; > } > } > > Or this: > > list foo { > key "a/b"; > container a { > choice x { > leaf b; > leaf c; > } > } > > > Also, by allowing deep keys, you force an agent implementation to do > buffering of - in the worst case - the entire configuration. You > influence the protocol characteristics to the worse. W/o deep keys > implementations _can_ do minimal buffering, and thus make the NETCONF > protocol usable in smaller devices. I know at least three > implementations that work this way today (and I know one that does > buffering). > This is really irrelevant in the context of standardization. In other implementations (like mine) the position of the key within the list element sub-tree is not a factor. BTW, there is no text in the draft that says that the key components must be defined first in the list. In order to optimize the DML design in favor of this implementation choice, the key components can never be in reusable groupings (like address/port) and they must always be the first leafs, defined in the same order as the key. SMIv2 never had any massive CLRs like this for tables. You can specify 'key' clauses in XSD for arbitrary nodes. There is so much complexity in YANG wrt/ Xpath, local typedefs/groupings, augments, that this hardly seems like an implementation burden worthy of such drastic restrictions on data model design. >> With this constraint on the key-stmt, YANG cannot support >> indexing using reusable containers. (There needs to be >> exactly one instance of the key component per list entry, >> so 'list' and 'choice' nodes cannot be used within a key.) > > I can also argue that this is an CLR. Why don't you allow: > > list foo { > key address; > container address { > choice type { > leaf ipv4address; > leaf ipv6address; > leaf name; > }; > leaf port; > } > } > We need to understand what a key is, and when it is used. A key identifies the static naming components so multiple instances of a list node can be distinguished by an application. I am not proposing that the key components be complex and/or non-static, like you are, with this straw-man example. It is not a CLR to specify that key components must be static leafs. This is how SMIv2 works, and it should be how YANG works as well. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 09:39:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFcC-0000VB-85; Tue, 08 Jan 2008 09:39:40 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCFcB-0000V6-Bc for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 09:39:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFcB-0000Uy-1r for yang@ietf.org; Tue, 08 Jan 2008 09:39:39 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCFc8-0001bJ-Tt for yang@ietf.org; Tue, 08 Jan 2008 09:39:39 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id D80311B80DA; Tue, 8 Jan 2008 15:39:35 +0100 (CET) Date: Tue, 08 Jan 2008 15:38:53 +0100 (CET) Message-Id: <20080108.153853.107509382.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] key clause issues From: Martin Bjorklund In-Reply-To: <4783813D.5030104@andybierman.com> References: <4782C606.5010109@andybierman.com> <20080108.121147.221068658.mbj@tail-f.com> <4783813D.5030104@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi Andy, > > > > Andy Bierman wrote: > >> Issue 1) > >> > >> From an interoperability perspective, the key needs to > >> be defined any time there are multiple named instances > >> of an element (i.e., every list). > > > > Exactly what will not be interoperable by not having keys for > > non-config data? > > > > The feature intent needs to be explained in the draft. > If a list has no key defined, then that means that > there is no distinction in the agent between any of > the entries, other than their relative position (foo[1], foo[2], etc.) > > If this is true, and the manager knows that, then there is no > problem leaving out the key. (Other DMLs call this multiple > instances of a container, not a list though). > > But if the agent has some way of identifying list entries, > other than their relative position, then a key MUST be specified. > (Is this what the draft intends?) I dont't follow. How does it matter to interoperability if the agent has some way of identifying list entries? Which protocol operation will suffer? > > (One problem might be how to define access control. W/o keys you > > might have to fall back to generic XPath, which we want to avoid...) > > > >> Config vs. read-only is irrelevant. > >> Operators and manager applications need to know how list entries > >> are indexed for interoperability. SNMP is mostly for monitoring. > >> I can't imagine how operators and DM readers would be able to talk about > >> tables and rows if all the INDEX clauses were removed from read-only tables. > > > > In SNMP, the INDEX is needed by the protocol. Not so in NETCONF for > > non-config data. > > Not true at all. If the agent is using named entries > instead of position-identified entries, the manager needs to know. > > Consider any XML table like the ifTable counters. > What if the agent has entries for interfaces 1, 2, and 3, > but after awhile, interface 2 is deleted. If the agent > knows about 'ifIndex', but not the manager, how well do > you think the manager application will handle this common scenario? ifIndex is a leaf that the manager knows about, and so does the agent. What will not work well? [I am playing the devil's advocate here. I would be perfectly happy with keys for non-config data as well.] Ah, now I remember the other reason. If I use a list in an rpc or notification, do I still need to have a key? > Config vs. non-config is irrelevant here. > Identification via named keys or identification via node position > is the issue. > > > > > > > >> Issue 2) > >> > >> Why is the CLR about a leaf appearing more than once in the key needed? > >> It should be up to the DM writer to decide if this makes sense or not: > >> > >> list addr-pairs { > >> key "addr-type src-addr addr-type dest-addr"; > > > > What does this mean? What is the difference between this and: > > > > key "addr-type src-addr dest-addr"; > > > > What does an instance identifier for your example look like? > > > > This table obviously cannot use the nested address. > By design, it uses separated fields. You lost me again. What does nested address have to do with the single-occurance of leaf in the key? I still don't understand what the key above actually is supposed to mean. > >> Issue 3) > >> Why is the key statement limited to top-level sibling nodes > >> within the list? [...] > > Also, by allowing deep keys, you force an agent implementation to do > > buffering of - in the worst case - the entire configuration. You > > influence the protocol characteristics to the worse. W/o deep keys > > implementations _can_ do minimal buffering, and thus make the NETCONF > > protocol usable in smaller devices. I know at least three > > implementations that work this way today (and I know one that does > > buffering). > > > > This is really irrelevant in the context of standardization. Is it? Even XSD puts restrictions on the XPath used in keys "In order to reduce the burden on implementers, in particular implementers of streaming processors" [http://www.w3.org/TR/xmlschema-1/#cIdentity-constraint_Definitions]. Wasn't one of the reasons for not doing XPath filtering only in NETCONF that it would require more resources on the device? If we get a YANG WG, I think it is very important the WG really understands the implementation/resource implications of constructs like this. > In other implementations (like mine) the position of the key > within the list element sub-tree is not a factor. > > BTW, there is no text in the draft that says that the key components > must be defined first in the list. In order to optimize the DML > design in favor of this implementation choice, the key components > can never be in reusable groupings (like address/port) and they > must always be the first leafs, defined in the same order as the key. The keys don't have to be defined first. They will be encoded first in the XML. > SMIv2 never had any massive CLRs like this for tables. Well, in SMI there were no deep structures. > You can specify 'key' clauses in XSD for arbitrary nodes. Right. Are you arguing that we should support the same flexibility of keys as XSD? > There is so much complexity in YANG wrt/ Xpath, local typedefs/groupings, > augments, that this hardly seems like an implementation burden > worthy of such drastic restrictions on data model design. First of all, YANG does not require an XPath engine on the device, for the same reason - to reduce the implementation burden on the device. Local typedefs / groupings might add complexity to the compiler, but not to the engine. And again, it is the resource consumption on the device that I'm worried about. By allowing this you essentially say that streaming processing is out of the question. > >> With this constraint on the key-stmt, YANG cannot support > >> indexing using reusable containers. (There needs to be > >> exactly one instance of the key component per list entry, > >> so 'list' and 'choice' nodes cannot be used within a key.) > > > > I can also argue that this is an CLR. Why don't you allow: > > > > list foo { > > key address; > > container address { > > choice type { > > leaf ipv4address; > > leaf ipv6address; > > leaf name; > > }; > > leaf port; > > } > > } > > > > > We need to understand what a key is, and when it is used. > A key identifies the static naming components so multiple > instances of a list node can be distinguished by an application. > > I am not proposing that the key components be complex and/or non-static, > like you are, with this straw-man example. It is not a CLR to > specify that key components must be static leafs. This is > how SMIv2 works, and it should be how YANG works as well. Again, SMI does not have deep structures in tables so I don't think the comparison helps. Out of curiosity - how do you handle deep keys in your CLI? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 11:07:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGyy-0008UJ-2L; Tue, 08 Jan 2008 11:07:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCGyw-0008Se-Uf for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 11:07:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGyw-0008SN-Kc for yang@ietf.org; Tue, 08 Jan 2008 11:07:14 -0500 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCGyv-0002pY-FW for yang@ietf.org; Tue, 08 Jan 2008 11:07:14 -0500 Received: (qmail 73895 invoked from network); 8 Jan 2008 16:07:10 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 8 Jan 2008 16:07:10 -0000 X-YMail-OSG: OSolL5AVM1kuJDW9qwNNOjF6p_kUhqHcx5n_VpvcYc6royNWWNp5z9ZZ.XpbU3ekZD2TV2BHcSunVEjFDoReoOQgDi_yeGf3cag- Message-ID: <47839FAF.40803@andybierman.com> Date: Tue, 08 Jan 2008 08:07:11 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] key clause issues References: <4782C606.5010109@andybierman.com> <20080108.121147.221068658.mbj@tail-f.com> <4783813D.5030104@andybierman.com> <20080108.153853.107509382.mbj@tail-f.com> In-Reply-To: <20080108.153853.107509382.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi Andy, >>> >>> Andy Bierman wrote: >>>> Issue 1) >>>> >>>> From an interoperability perspective, the key needs to >>>> be defined any time there are multiple named instances >>>> of an element (i.e., every list). >>> Exactly what will not be interoperable by not having keys for >>> non-config data? >>> >> The feature intent needs to be explained in the draft. >> If a list has no key defined, then that means that >> there is no distinction in the agent between any of >> the entries, other than their relative position (foo[1], foo[2], etc.) >> >> If this is true, and the manager knows that, then there is no >> problem leaving out the key. (Other DMLs call this multiple >> instances of a container, not a list though). >> >> But if the agent has some way of identifying list entries, >> other than their relative position, then a key MUST be specified. >> (Is this what the draft intends?) > > I dont't follow. How does it matter to interoperability if the agent > has some way of identifying list entries? Which protocol operation > will suffer? > See below > >>> (One problem might be how to define access control. W/o keys you >>> might have to fall back to generic XPath, which we want to avoid...) >>> >>>> Config vs. read-only is irrelevant. >>>> Operators and manager applications need to know how list entries >>>> are indexed for interoperability. SNMP is mostly for monitoring. >>>> I can't imagine how operators and DM readers would be able to talk about >>>> tables and rows if all the INDEX clauses were removed from read-only tables. >>> In SNMP, the INDEX is needed by the protocol. Not so in NETCONF for >>> non-config data. >> Not true at all. If the agent is using named entries >> instead of position-identified entries, the manager needs to know. >> >> Consider any XML table like the ifTable counters. >> What if the agent has entries for interfaces 1, 2, and 3, >> but after awhile, interface 2 is deleted. If the agent >> knows about 'ifIndex', but not the manager, how well do >> you think the manager application will handle this common scenario? > > ifIndex is a leaf that the manager knows about, and so does the > agent. What will not work well? Yes, the manager knows about all the leafs (ifIndex, ifInOctets, ifMtu, etc.) Without the magic text 'key ifIndex;', the manager has no idea what makes one blob called from another one. Without a key, the manager has to identify each list node by its position: 1 1500 ... 2 9600 ... 3 9600 ... Now, if the manager application has no idea that 'ifIndex' is the key, and the entire for entry '2' is deleted, then the manager has no idea it is collecting data for entries 1 and 3, not 1 and 2. > > [I am playing the devil's advocate here. I would be perfectly happy > with keys for non-config data as well.] > > Ah, now I remember the other reason. If I use a list in an rpc or > notification, do I still need to have a key? yes -- if there are named entries in the list no -- if the list has unnamed entries, just position tells them apart > >> Config vs. non-config is irrelevant here. >> Identification via named keys or identification via node position >> is the issue. >> >> >>> >>>> Issue 2) >>>> >>>> Why is the CLR about a leaf appearing more than once in the key needed? >>>> It should be up to the DM writer to decide if this makes sense or not: >>>> >>>> list addr-pairs { >>>> key "addr-type src-addr addr-type dest-addr"; >>> What does this mean? What is the difference between this and: >>> >>> key "addr-type src-addr dest-addr"; >>> >>> What does an instance identifier for your example look like? >>> >> This table obviously cannot use the nested address. >> By design, it uses separated fields. > > You lost me again. What does nested address have to do with the > single-occurance of leaf in the key? > > I still don't understand what the key above actually is supposed to > mean. Instance ID: /addr-pairs[addr-type='ipv4'][src-addr='192.168.0.1'][dest-addr='192.168.0.4'] > >>>> Issue 3) >>>> Why is the key statement limited to top-level sibling nodes >>>> within the list? > > [...] > >>> Also, by allowing deep keys, you force an agent implementation to do >>> buffering of - in the worst case - the entire configuration. You >>> influence the protocol characteristics to the worse. W/o deep keys >>> implementations _can_ do minimal buffering, and thus make the NETCONF >>> protocol usable in smaller devices. I know at least three >>> implementations that work this way today (and I know one that does >>> buffering). >>> >> This is really irrelevant in the context of standardization. > > Is it? Even XSD puts restrictions on the XPath used in keys "In order > to reduce the burden on implementers, in particular implementers of > streaming processors" > [http://www.w3.org/TR/xmlschema-1/#cIdentity-constraint_Definitions]. > > Wasn't one of the reasons for not doing XPath filtering only in > NETCONF that it would require more resources on the device? > > If we get a YANG WG, I think it is very important the WG really > understands the implementation/resource implications of constructs > like this. > I do not think buffering input is an implementation burden that should be a big factor. The size of the data models on the device is going to be relative to the device. WGs and vendors should certainly attempt to place the index leafs first instead of last, but should not be forced to do so. Most importantly though, WGs and vendors should not be forced to undo (cut-and-paste) data placed in containers, just so a list can use that data in the key. It must be up to the DM writer where to use containers for data, instead of spreading everything out in a flat table like SMIv2. Simple containers like (type, addr, port) are going to be reused, and going to be needed in list keys. SMIv2 never had any nesting. That is a bug, not a feature. XML DM writers need to be able to use nesting anywhere it makes sense for a particular data model. >> In other implementations (like mine) the position of the key >> within the list element sub-tree is not a factor. >> >> BTW, there is no text in the draft that says that the key components >> must be defined first in the list. In order to optimize the DML >> design in favor of this implementation choice, the key components >> can never be in reusable groupings (like address/port) and they >> must always be the first leafs, defined in the same order as the key. > > The keys don't have to be defined first. They will be encoded first > in the XML. > >> SMIv2 never had any massive CLRs like this for tables. > > Well, in SMI there were no deep structures. > >> You can specify 'key' clauses in XSD for arbitrary nodes. > > Right. Are you arguing that we should support the same flexibility of > keys as XSD? no. XSD allows the key to be outside the list. In YANG, the key components MUST be defined within the list, either directly, or via expansion of 'uses' statements. I am proposing: 1) The key leafs do no have to be first, or in any particular order within the list 2) leafs nested only within the 'container' construct may be used as key components > >> There is so much complexity in YANG wrt/ Xpath, local typedefs/groupings, >> augments, that this hardly seems like an implementation burden >> worthy of such drastic restrictions on data model design. > > First of all, YANG does not require an XPath engine on the device, for > the same reason - to reduce the implementation burden on the device. > > Local typedefs / groupings might add complexity to the compiler, but > not to the engine. > > And again, it is the resource consumption on the device that I'm > worried about. By allowing this you essentially say that streaming > processing is out of the question. > > >>>> With this constraint on the key-stmt, YANG cannot support >>>> indexing using reusable containers. (There needs to be >>>> exactly one instance of the key component per list entry, >>>> so 'list' and 'choice' nodes cannot be used within a key.) >>> I can also argue that this is an CLR. Why don't you allow: >>> >>> list foo { >>> key address; >>> container address { >>> choice type { >>> leaf ipv4address; >>> leaf ipv6address; >>> leaf name; >>> }; >>> leaf port; >>> } >>> } >>> >> >> We need to understand what a key is, and when it is used. >> A key identifies the static naming components so multiple >> instances of a list node can be distinguished by an application. >> >> I am not proposing that the key components be complex and/or non-static, >> like you are, with this straw-man example. It is not a CLR to >> specify that key components must be static leafs. This is >> how SMIv2 works, and it should be how YANG works as well. > > Again, SMI does not have deep structures in tables so I don't think > the comparison helps. > > > Out of curiosity - how do you handle deep keys in your CLI? Yet another implementation detail, but the CLI processing is different than NETCONF. For CLI, all the index components are listed first, like: ifEntry 1 { # ifIndex would not be listed since it is the index ifMtu 1500 ifName Ethernet0/0 } Since the 'ifIndex' node has a back-ptr to its index header, it can be skipped correctly no matter where it is located in the subtree. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 11:23:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHEs-0005jm-LA; Tue, 08 Jan 2008 11:23:42 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCHEp-0005b0-JT for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 11:23:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHEp-0005YJ-84 for yang@ietf.org; Tue, 08 Jan 2008 11:23:39 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCHEo-0003H6-FP for yang@ietf.org; Tue, 08 Jan 2008 11:23:39 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id C070D1B80DA; Tue, 8 Jan 2008 17:23:37 +0100 (CET) Date: Tue, 08 Jan 2008 17:22:55 +0100 (CET) Message-Id: <20080108.172255.160127267.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] key clause issues From: Martin Bjorklund In-Reply-To: <47839FAF.40803@andybierman.com> References: <4783813D.5030104@andybierman.com> <20080108.153853.107509382.mbj@tail-f.com> <47839FAF.40803@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Hi Andy, > >>> > >>> Andy Bierman wrote: > >>>> Issue 1) > >>>> > >>>> From an interoperability perspective, the key needs to > >>>> be defined any time there are multiple named instances > >>>> of an element (i.e., every list). > >>> Exactly what will not be interoperable by not having keys for > >>> non-config data? > >>> > >> The feature intent needs to be explained in the draft. > >> If a list has no key defined, then that means that > >> there is no distinction in the agent between any of > >> the entries, other than their relative position (foo[1], foo[2], etc.) > >> > >> If this is true, and the manager knows that, then there is no > >> problem leaving out the key. (Other DMLs call this multiple > >> instances of a container, not a list though). > >> > >> But if the agent has some way of identifying list entries, > >> other than their relative position, then a key MUST be specified. > >> (Is this what the draft intends?) > > > > I dont't follow. How does it matter to interoperability if the agent > > has some way of identifying list entries? Which protocol operation > > will suffer? > > > > See below > > > > >>> (One problem might be how to define access control. W/o keys you > >>> might have to fall back to generic XPath, which we want to avoid...) > >>> > >>>> Config vs. read-only is irrelevant. > >>>> Operators and manager applications need to know how list entries > >>>> are indexed for interoperability. SNMP is mostly for monitoring. > >>>> I can't imagine how operators and DM readers would be able to talk about > >>>> tables and rows if all the INDEX clauses were removed from read-only tables. > >>> In SNMP, the INDEX is needed by the protocol. Not so in NETCONF for > >>> non-config data. > >> Not true at all. If the agent is using named entries > >> instead of position-identified entries, the manager needs to know. > >> > >> Consider any XML table like the ifTable counters. > >> What if the agent has entries for interfaces 1, 2, and 3, > >> but after awhile, interface 2 is deleted. If the agent > >> knows about 'ifIndex', but not the manager, how well do > >> you think the manager application will handle this common scenario? > > > > ifIndex is a leaf that the manager knows about, and so does the > > agent. What will not work well? > > > Yes, the manager knows about all the leafs (ifIndex, ifInOctets, ifMtu, etc.) > Without the magic text 'key ifIndex;', the manager has no idea what > makes one blob called from another one. > > Without a key, the manager has to identify each list node > by its position: > > > 1 > 1500 > ... > > > 2 > 9600 > ... > > > 3 > 9600 > ... > > > Now, if the manager application has no idea that 'ifIndex' is the > key, and the entire for entry '2' is deleted, > then the manager has no idea it is collecting data > for entries 1 and 3, not 1 and 2. > > > > > > [I am playing the devil's advocate here. I would be perfectly happy > > with keys for non-config data as well.] > > > > Ah, now I remember the other reason. If I use a list in an rpc or > > notification, do I still need to have a key? > > > yes -- if there are named entries in the list > no -- if the list has unnamed entries, just position tells them apart Why don't the same rules apply to non-config data? In the ifIndex example above, by this rule you would specify a key. > >>>> Issue 2) > >>>> > >>>> Why is the CLR about a leaf appearing more than once in the key needed? > >>>> It should be up to the DM writer to decide if this makes sense or not: > >>>> > >>>> list addr-pairs { > >>>> key "addr-type src-addr addr-type dest-addr"; > >>> What does this mean? What is the difference between this and: > >>> > >>> key "addr-type src-addr dest-addr"; > >>> > >>> What does an instance identifier for your example look like? > >>> > >> This table obviously cannot use the nested address. > >> By design, it uses separated fields. > > > > You lost me again. What does nested address have to do with the > > single-occurance of leaf in the key? > > > > I still don't understand what the key above actually is supposed to > > mean. > > Instance ID: > > /addr-pairs[addr-type='ipv4'][src-addr='192.168.0.1'][dest-addr='192.168.0.4'] So the key statement above has addr-type twice, but in the IID it occurs just once? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 17:25:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMsW-0006VO-H9; Tue, 08 Jan 2008 17:25:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCMsV-0006VJ-L5 for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 17:24:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMsV-0006V7-8X for yang@ietf.org; Tue, 08 Jan 2008 17:24:59 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCMsU-00006Q-Im for yang@ietf.org; Tue, 08 Jan 2008 17:24:59 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Jan 2008 14:24:40 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jan 2008 14:24:35 -0800 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 m08MOZ904481; Tue, 8 Jan 2008 14:24:35 -0800 (PST) (envelope-from phil@idle.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 m08MKdqc095127; Tue, 8 Jan 2008 22:20:43 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801082220.m08MKdqc095127@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] key clause issues In-reply-to: <4783813D.5030104@andybierman.com> Date: Tue, 08 Jan 2008 17:20:39 -0500 From: Phil Shafer X-OriginalArrivalTime: 08 Jan 2008 22:24:35.0701 (UTC) FILETIME=[3FD20A50:01C85245] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >If a list has no key defined, then that means that >there is no distinction in the agent between any of >the entries, other than their relative position (foo[1], foo[2], etc.) This is exactly what it's there for. Some lists are position, and no key is available and we want to avoid having to create one for data that can't be manipulated individually. A simple example would be syslog entries (or any list of events), which consist of many non-unique leafs, having no unique key. >If this is true, and the manager knows that, then there is no >problem leaving out the key. Yup, exactly. >(Other DMLs call this multiple >instances of a container, not a list though). Isn't it cool that YANG got this right? ;^) >But if the agent has some way of identifying list entries, >other than their relative position, then a key MUST be specified. >(Is this what the draft intends?) MUST? It's the designer's data model. Are we going to MUST them? This is a CBAR. >Not true at all. If the agent is using named entries >instead of position-identified entries, the manager needs to know. Yup, and the lack of a key tells the manager that there's no key for this list. >Consider any XML table like the ifTable counters. >What if the agent has entries for interfaces 1, 2, and 3, >but after awhile, interface 2 is deleted. If the agent >knows about 'ifIndex', but not the manager, how well do >you think the manager application will handle this common scenario? So the modeler will say "Hey! I have a key" and use the in their data model. >Config vs. non-config is irrelevant here. Config vs. non-config is _very_ relevant because we explicitly do not allow lists in config data to be non-keyed. The need to manipulate the data overrides the modeler's need to avoid keys. >Identification via named keys or identification via node position >is the issue. The more important use case is where position (in the absolute) simply doesn't matter. Events in a syslog file may matter in relative terms, but never in absolute terms even those numbers are subject to change as files roll over and low priority events are discarded. >>> Issue 2) >>> Why is the CLR about a leaf appearing more than once in the key needed? >>> It should be up to the DM writer to decide if this makes sense or not: >>> key "addr-type src-addr addr-type dest-addr"; >> What does this mean? What is the difference between this and: >> key "addr-type src-addr dest-addr"; >> What does an instance identifier for your example look like? >This table obviously cannot use the nested address. >By design, it uses separated fields. I'm lost here. Why would you ever need to list the leaf more than once? >There is so much complexity in YANG wrt/ Xpath, local typedefs/groupings, >augments, that this hardly seems like an implementation burden >worthy of such drastic restrictions on data model design. It's funny which features trigger our individual "running with scissors" sensors, but this one (deep keys) fires off mine. I can see a couple of fairly weak use cases, but the number of potential abuses is overwhelming. Someone's guaranteed to put their eye out with deep keys. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 17:40:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCN7o-0004jQ-4i; Tue, 08 Jan 2008 17:40:48 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCN7m-0004jK-GB for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 17:40:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCN7m-0004jC-6X for yang@ietf.org; Tue, 08 Jan 2008 17:40:46 -0500 Received: from exprod7og109.obsmtp.com ([64.18.2.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCN7l-0001k8-Ps for yang@ietf.org; Tue, 08 Jan 2008 17:40:46 -0500 Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Jan 2008 14:40:30 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jan 2008 14:34:25 -0800 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 m08MYO907136; Tue, 8 Jan 2008 14:34:24 -0800 (PST) (envelope-from phil@idle.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 m08MUP3O095222; Tue, 8 Jan 2008 22:30:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801082230.m08MUP3O095222@idle.juniper.net> To: "tom.petch" Subject: Re: [YANG] so many naming scopes In-reply-to: <011a01c851d8$cc8652c0$0601a8c0@pc6> Date: Tue, 08 Jan 2008 17:30:25 -0500 From: Phil Shafer X-OriginalArrivalTime: 08 Jan 2008 22:34:25.0135 (UTC) FILETIME=[9F2687F0:01C85246] X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "tom.petch" writes: >There are languages where no word is reserved, where the same symbol(word) can >be used for label, type, module etc. XML is arguable worse with the ability to >start a fresh namespace on alternate lines. These belong in the bin. That's a very strong statement, given that the motivation for avoiding reserved words is typically future proofing. Don't paint it as a universally bad feature. For example, if I use "action" as a leaf in my model and the next version of YANG adds a feature that uses "action" as a keyword, my model is broken and needs repair. Many languages reserve unused keywords just on the odds they will need them in the future, but they are seldom right. By keeping the namespace of user-defined stuff out of the namespace of keywords, YANG avoids this issue entirely. As the number of modules defined in YANG approaches the number that are defined in SMI, this will be an important language feature. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 08 18:28:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCNrT-0007B2-N2; Tue, 08 Jan 2008 18:27:59 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCNrS-00079e-F2 for yang-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 18:27:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCNqm-0006Ih-PG for yang@ietf.org; Tue, 08 Jan 2008 18:27:16 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCNic-00020M-US for yang@ietf.org; Tue, 08 Jan 2008 18:18:51 -0500 Received: (qmail 67957 invoked from network); 8 Jan 2008 23:18:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.80.25 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 8 Jan 2008 23:18:49 -0000 X-YMail-OSG: tPqvAUoVM1lb5RmYoaaLvwWELmy15w7AFUVHk4HUfsgdTMCF Message-ID: <478404D8.1010007@andybierman.com> Date: Tue, 08 Jan 2008 15:18:48 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] key clause issues References: <200801082220.m08MKdqc095127@idle.juniper.net> In-Reply-To: <200801082220.m08MKdqc095127@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> If a list has no key defined, then that means that >> there is no distinction in the agent between any of >> the entries, other than their relative position (foo[1], foo[2], etc.) > > This is exactly what it's there for. Some lists are position, and > no key is available and we want to avoid having to create one for > data that can't be manipulated individually. > > A simple example would be syslog entries (or any list of events), > which consist of many non-unique leafs, having no unique key. > >> If this is true, and the manager knows that, then there is no >> problem leaving out the key. > > Yup, exactly. Then the concept is correct and the text is wrong. The intent is: All config lists must have named entries and therefore must a key. A non-config list must have a key if it has named entries, otherwise the non-config list has only position-identified entries. > >> (Other DMLs call this multiple >> instances of a container, not a list though). > > Isn't it cool that YANG got this right? ;^) > >> But if the agent has some way of identifying list entries, >> other than their relative position, then a key MUST be specified. >> (Is this what the draft intends?) > > MUST? It's the designer's data model. Are we going to MUST them? > This is a CBAR. I didn't mean the agent -- I meant the DM writer. > >> Not true at all. If the agent is using named entries >> instead of position-identified entries, the manager needs to know. > > Yup, and the lack of a key tells the manager that there's no key > for this list. > >> Consider any XML table like the ifTable counters. >> What if the agent has entries for interfaces 1, 2, and 3, >> but after awhile, interface 2 is deleted. If the agent >> knows about 'ifIndex', but not the manager, how well do >> you think the manager application will handle this common scenario? > > So the modeler will say "Hey! I have a key" and use the in their > data model. > Good -- we just need to make the text more clear >> Config vs. non-config is irrelevant here. > > Config vs. non-config is _very_ relevant because we explicitly do > not allow lists in config data to be non-keyed. The need to > manipulate the data overrides the modeler's need to avoid keys. > >> Identification via named keys or identification via node position >> is the issue. > > The more important use case is where position (in the absolute) > simply doesn't matter. Events in a syslog file may matter in > relative terms, but never in absolute terms even those numbers > are subject to change as files roll over and low priority events > are discarded. > >>>> Issue 2) >>>> Why is the CLR about a leaf appearing more than once in the key needed? >>>> It should be up to the DM writer to decide if this makes sense or not: >>>> key "addr-type src-addr addr-type dest-addr"; >>> What does this mean? What is the difference between this and: >>> key "addr-type src-addr dest-addr"; >>> What does an instance identifier for your example look like? >> This table obviously cannot use the nested address. >> By design, it uses separated fields. > > I'm lost here. Why would you ever need to list the leaf more than once? Fine -- leave this CLR in the draft. Just explain why it is needed. > >> There is so much complexity in YANG wrt/ Xpath, local typedefs/groupings, >> augments, that this hardly seems like an implementation burden >> worthy of such drastic restrictions on data model design. > > It's funny which features trigger our individual "running with > scissors" sensors, but this one (deep keys) fires off mine. I can > see a couple of fairly weak use cases, but the number of potential > abuses is overwhelming. Someone's guaranteed to put their eye out > with deep keys. IMO, the 'my implementation uses more memory' argument is really weak to justify huge CLRs that are more restrictive than SMIv2 tables. The draft does not force all the key components to be first. That means that an agent implementation has to buffer NETCONF PDUs that contain non-key nodes (deep or not) until all the key nodes are received anyway. What difference does it make if the static key is 'foo' or 'foo/bar' or '/foo/bar/baz'. I do not see the ability to index even 1 layer deep into a reusable container as a weak use case. Not every DM writer is going to want to place every leaf at the same sibling level. That is what SMIv2 has to offer, and it isn't good enough. > > Thanks, > Phil > > Abdy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 11:14:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCdZI-0007sJ-EQ; Wed, 09 Jan 2008 11:14:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCdZH-0007s7-6m for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 11:14:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCdZA-0007ru-Nh; Wed, 09 Jan 2008 11:14:08 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCdZA-0001PD-Fw; Wed, 09 Jan 2008 11:14:08 -0500 X-IronPort-AV: E=Sophos;i="4.24,263,1196658000"; d="scan'208";a="91180021" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 09 Jan 2008 11:14:05 -0500 X-IronPort-AV: E=Sophos;i="4.24,263,1196658000"; d="scan'208";a="148194835" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Jan 2008 11:14:04 -0500 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, 9 Jan 2008 17:14:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New NETCONF co-chairs Thread-Index: AchSFclRIymqLsxxRLm+TuHMvLvM8Q== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ngo@ietf.org, Ron Bonica , yang@ietf.org Subject: [YANG] New NETCONF co-chairs X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org We would like to inform you that we completed the process of choosing the new co-chairs for NETCONF and decided to nominate Bert Wijnen and Mehmet Ersue as co-chairs. It was not an easy choice as Ron and me had the privilege to make a selection from a pool of excellent candidates. We are sure that Bert and Mehmet bring the competence, experience and enthusiasm to continue the fine job that has been started by Andy and Simon. This working group has an ambitious but focused chartered to fulfill, while many of its participants are also involved in challenging discussions and work related to data modeling and other NETCONF-related features. We wish success to the new chairs and to the whole working group.=20 Regards, Ron and Dan =20 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 11:34:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCdsl-00041O-LB; Wed, 09 Jan 2008 11:34:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCdsk-00041I-J6 for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 11:34:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCdsk-000418-8W for yang@ietf.org; Wed, 09 Jan 2008 11:34:22 -0500 Received: from smtp122.sbc.mail.sp1.yahoo.com ([69.147.64.95]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCdsj-00024p-RJ for yang@ietf.org; Wed, 09 Jan 2008 11:34:22 -0500 Received: (qmail 31590 invoked from network); 9 Jan 2008 16:34:21 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.84.5 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 9 Jan 2008 16:34:20 -0000 X-YMail-OSG: 8OsvwXwVM1k2wuauWoxo_h34ItlNqoUaEbsnpRSMblSLrNbm Message-ID: <4784F78B.5040000@andybierman.com> Date: Wed, 09 Jan 2008 08:34:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [YANG] 7.1.5 import statement X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, This section does not say anything about whether it is an error to import a non-existent module, if it is not used. The pyang program reports this as a fatal error. This gets into implementation details a little. A well-formed import that never gets used should be a warning. Consider implementations that do not actually find and compile the module for an import clause until the first time the prefix is used. The text needs to be clarified either way. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 11:42:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCe0O-0003lB-9f; Wed, 09 Jan 2008 11:42:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCe0N-0003l5-9x for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 11:42:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCe0N-0003kx-0H for yang@ietf.org; Wed, 09 Jan 2008 11:42:15 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCe0L-000547-ET for yang@ietf.org; Wed, 09 Jan 2008 11:42:14 -0500 X-Trace: 15790713/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGmIhEc+8aMG/2dsb2JhbACqBA Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 09 Jan 2008 16:42:11 +0000 Received: from pc6 (1Cust78.tnt30.lnd3.gbr.da.uu.net [62.188.122.78]) by astro.systems.pipex.net (Postfix) with SMTP id 47E27E00009A; Wed, 9 Jan 2008 16:41:56 +0000 (GMT) Message-ID: <012701c852d5$ff6ffc60$0601a8c0@pc6> From: "tom.petch" To: "Phil Shafer" References: <200801082230.m08MUP3O095222@idle.juniper.net> Subject: Re: [YANG] so many naming scopes Date: Wed, 9 Jan 2008 16:22:21 +0100 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 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org ----- Original Message ----- From: "Phil Shafer" To: "tom.petch" Cc: "Bert Wijnen - IETF" ; "Andy Bierman" ; Sent: Tuesday, January 08, 2008 11:30 PM Subject: Re: [YANG] so many naming scopes > "tom.petch" writes: > >There are languages where no word is reserved, where the same symbol(word) can > >be used for label, type, module etc. XML is arguable worse with the ability to > >start a fresh namespace on alternate lines. These belong in the bin. > > That's a very strong statement, given that the motivation for > avoiding reserved words is typically future proofing. Don't paint > it as a universally bad feature. > > For example, if I use "action" as a leaf in my model and the next > version of YANG adds a feature that uses "action" as a keyword, my > model is broken and needs repair. > > Many languages reserve unused keywords just on the odds they will > need them in the future, but they are seldom right. By keeping the > namespace of user-defined stuff out of the namespace of keywords, > YANG avoids this issue entirely. As the number of modules defined > in YANG approaches the number that are defined in SMI, this will be > an important language feature. > Yes, I expressed myself strongly, perhaps as a result of spending time in 2007 with XML documents where there was widespread use of an element named as well as one named ; I wish that XML had reserved those words:-( I accept that it is a trade off, and devising a language without reserved words is an achievement; but I find it costs usability when eg you can have labels such as 'if' and 'then' and variables such as 'for' and 'case'. I mean, it is sort of obvious, you are writing this small simple program that will only ever have one case construct so it is natural to name the associated variable 'case'. If a language has concepts which are widely written about in English - perhaps container, leaf, index, key would qualify - then I would prefer those to be reserved, else someone someday will use them. Tom Petch > Thanks, > Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 11:57:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCeFV-0003Q6-D7; Wed, 09 Jan 2008 11:57:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCeFU-0003Q0-Jd for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 11:57:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCeFU-0003Ps-8H for yang@ietf.org; Wed, 09 Jan 2008 11:57:52 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCeFT-0002Zw-LE for yang@ietf.org; Wed, 09 Jan 2008 11:57:52 -0500 Received: (qmail 55580 invoked from network); 9 Jan 2008 16:57:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.84.5 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 9 Jan 2008 16:57:50 -0000 X-YMail-OSG: jrwdagIVM1lhZx1Sr9Iqqva4OF9VTHinOMnFfC_3DTyjAxwrhGq92HRCVJsxU5PYgURXMf0Lpcd_TlWOr02p_z6U6Gn6gBc004Q- Message-ID: <4784FD0D.6020103@andybierman.com> Date: Wed, 09 Jan 2008 08:57:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [YANG] so many naming scopes References: <200801082230.m08MUP3O095222@idle.juniper.net> <012701c852d5$ff6ffc60$0601a8c0@pc6> In-Reply-To: <012701c852d5$ff6ffc60$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org tom.petch wrote: > ----- Original Message ----- > From: "Phil Shafer" > To: "tom.petch" > Cc: "Bert Wijnen - IETF" ; "Andy Bierman" > ; > Sent: Tuesday, January 08, 2008 11:30 PM > Subject: Re: [YANG] so many naming scopes > > >> "tom.petch" writes: >>> There are languages where no word is reserved, where the same symbol(word) > can >>> be used for label, type, module etc. XML is arguable worse with the ability > to >>> start a fresh namespace on alternate lines. These belong in the bin. >> That's a very strong statement, given that the motivation for >> avoiding reserved words is typically future proofing. Don't paint >> it as a universally bad feature. >> >> For example, if I use "action" as a leaf in my model and the next >> version of YANG adds a feature that uses "action" as a keyword, my >> model is broken and needs repair. >> >> Many languages reserve unused keywords just on the odds they will >> need them in the future, but they are seldom right. By keeping the >> namespace of user-defined stuff out of the namespace of keywords, >> YANG avoids this issue entirely. As the number of modules defined >> in YANG approaches the number that are defined in SMI, this will be >> an important language feature. >> > Yes, I expressed myself strongly, perhaps as a result of spending time in 2007 > with XML documents where there was widespread use of an element named > as well as one named ; I wish that XML had reserved those words:-( I > accept that it is a trade off, and devising a language without reserved words is > an achievement; but I find it costs usability when eg you can have labels such > as 'if' and 'then' and variables such as 'for' and 'case'. I mean, it is sort > of obvious, you are writing this small simple program that will only ever have > one case construct so it is natural to name the associated variable 'case'. > > If a language has concepts which are widely written about in English - perhaps > container, leaf, index, key would qualify - then I would prefer those to be > reserved, else someone someday will use them. > My concern is that even though compilers and YANG experts are aware of the 6 different naming scopes defined in sec. 6.2, perhaps newbies would be confused by seeing data models that mix them all together. Now you bring up a new twist: typedef typedef { type string; } leaf leaf { type typedef; } IMO, there needs to be guidelines (in the form of SHOULD NOT text) that says not to use YANG keywords for identifiers and not to use the same values for typedefs, groupings, and object names, even though it is allowed. In IETF-speak, a 'SHOULD' means vendors can do what they want in their DMs, but WGs will have to justify any violations of the CLR to the IESG. > Tom Petch > >> Thanks, >> Phil > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 12:22:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCedB-00087y-P9; Wed, 09 Jan 2008 12:22:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCed9-00087b-I4 for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 12:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCed9-00087S-7o for yang@ietf.org; Wed, 09 Jan 2008 12:22:19 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCed8-0006SR-RR for yang@ietf.org; Wed, 09 Jan 2008 12:22:19 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D74C8A27F; Wed, 9 Jan 2008 18:22:18 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 17812-06-3; Wed, 9 Jan 2008 18:22:13 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D12818A267; Wed, 9 Jan 2008 18:22:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7EE0745FC55; Wed, 9 Jan 2008 18:22:01 +0100 (CET) Date: Wed, 9 Jan 2008 18:22:01 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] 7.1.5 import statement Message-ID: <20080109172201.GA5298@elstar.local> Mail-Followup-To: Andy Bierman , yang References: <4784F78B.5040000@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4784F78B.5040000@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 09, 2008 at 08:34:19AM -0800, Andy Bierman wrote: > This section does not say anything about whether it is an > error to import a non-existent module, if it is not used. > The pyang program reports this as a fatal error. > > This gets into implementation details a little. > A well-formed import that never gets used should be a warning. > Consider implementations that do not actually find and compile > the module for an import clause until the first time the prefix is used. I expect a compiler to complain if an import can not be found and I expect a compiler to generate a warning if there is an import that is not used. In general, we don't talk much about warnings so we might choose to leave the generation of a warning for unused imports also an implementation detail. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 12:33:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCenU-0002OD-Ay; Wed, 09 Jan 2008 12:33:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCenT-0002O5-35 for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 12:32:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCenS-0002Nx-Pf for yang@ietf.org; Wed, 09 Jan 2008 12:32:58 -0500 Received: from exprod7og105.obsmtp.com ([64.18.2.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCenQ-0006gd-EZ for yang@ietf.org; Wed, 09 Jan 2008 12:32:58 -0500 Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 09 Jan 2008 09:32:47 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 09:32:34 -0800 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 m09HWY980610; Wed, 9 Jan 2008 09:32:34 -0800 (PST) (envelope-from phil@idle.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 m09HSgCF000847; Wed, 9 Jan 2008 17:28:42 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801091728.m09HSgCF000847@idle.juniper.net> To: "tom.petch" Subject: Re: [YANG] so many naming scopes In-reply-to: <012701c852d5$ff6ffc60$0601a8c0@pc6> Date: Wed, 09 Jan 2008 12:28:41 -0500 From: Phil Shafer X-OriginalArrivalTime: 09 Jan 2008 17:32:34.0833 (UTC) FILETIME=[9EFB8010:01C852E5] X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "tom.petch" writes: >Yes, I expressed myself strongly, perhaps as a result of spending time in 2007 >with XML documents where there was widespread use of an element named >as well as one named ; I wish that XML had reserved those words:-( I That might sounds wise up until the moment when you need to define XML for chemical elements (helium) or character attributes (fluffy). Forcing folks to choose non-obvious words because the DML uses them is bad. key and index are two examples where the modeler should be able to use them if they are exactly the term they need. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 12:35:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCepj-0003VO-OJ; Wed, 09 Jan 2008 12:35:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCeph-0003VC-Oj for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 12:35:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCeph-0003V3-F3 for yang@ietf.org; Wed, 09 Jan 2008 12:35:17 -0500 Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCeph-0006kK-1b for yang@ietf.org; Wed, 09 Jan 2008 12:35:17 -0500 Received: (qmail 36194 invoked from network); 9 Jan 2008 17:35:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.84.5 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 9 Jan 2008 17:35:16 -0000 X-YMail-OSG: f1bieUUVM1m5hnOYLD4gOyZBtP2mYpTuWIuvigcR.h8Qnbjo Message-ID: <478505D3.1060405@andybierman.com> Date: Wed, 09 Jan 2008 09:35:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Subject: Re: [YANG] 7.1.5 import statement References: <4784F78B.5040000@andybierman.com> <20080109172201.GA5298@elstar.local> In-Reply-To: <20080109172201.GA5298@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Wed, Jan 09, 2008 at 08:34:19AM -0800, Andy Bierman wrote: > >> This section does not say anything about whether it is an >> error to import a non-existent module, if it is not used. >> The pyang program reports this as a fatal error. >> >> This gets into implementation details a little. >> A well-formed import that never gets used should be a warning. >> Consider implementations that do not actually find and compile >> the module for an import clause until the first time the prefix is used. > > I expect a compiler to complain if an import can not be found and I > expect a compiler to generate a warning if there is an import that is > not used. In general, we don't talk much about warnings so we might > choose to leave the generation of a warning for unused imports also an > implementation detail. > Fine. One compiler complains and continues, and another complains and exits. It would be nice if DM writers who invest time and money in YANG know what 'valid YANG' is, so they know what tools should accept or not. But we should not over-specify the DML, such as defining compiler warnings. > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 14:28:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgag-0000f7-Fb; Wed, 09 Jan 2008 14:27:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCgaf-0000f2-Pq for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 14:27:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgaf-0000eq-G2 for yang@ietf.org; Wed, 09 Jan 2008 14:27:53 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCgad-0000H1-7K for yang@ietf.org; Wed, 09 Jan 2008 14:27:53 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id AFD301B80C3; Wed, 9 Jan 2008 20:27:46 +0100 (CET) Date: Wed, 09 Jan 2008 20:27:00 +0100 (CET) Message-Id: <20080109.202700.57813514.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] 7.1.5 import statement From: Martin Bjorklund In-Reply-To: <478505D3.1060405@andybierman.com> References: <4784F78B.5040000@andybierman.com> <20080109172201.GA5298@elstar.local> <478505D3.1060405@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Fine. One compiler complains and continues, and another complains > and exits. > > It would be nice if DM writers who invest time and money in YANG > know what 'valid YANG' is, The problem is that in this case it depends on the environment (a file cannot be found). So when my tool exits it doesn't say that the module is invalid YANG. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 17:07:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCj58-0002pS-A8; Wed, 09 Jan 2008 17:07:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCj56-0002o3-U0 for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 17:07:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCj56-0002kg-Gp for yang@ietf.org; Wed, 09 Jan 2008 17:07:28 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCj56-0002VB-4p for yang@ietf.org; Wed, 09 Jan 2008 17:07:28 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE6978A386; Wed, 9 Jan 2008 23:07:26 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09064-05; Wed, 9 Jan 2008 23:07:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3C138A35F; Wed, 9 Jan 2008 23:07:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8839D45FF1B; Wed, 9 Jan 2008 23:07:20 +0100 (CET) Date: Wed, 9 Jan 2008 23:07:20 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] 7.1.5 import statement Message-ID: <20080109220720.GA5390@elstar.local> Mail-Followup-To: Martin Bjorklund , ietf@andybierman.com, yang@ietf.org References: <4784F78B.5040000@andybierman.com> <20080109172201.GA5298@elstar.local> <478505D3.1060405@andybierman.com> <20080109.202700.57813514.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080109.202700.57813514.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 09, 2008 at 08:27:00PM +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > Fine. One compiler complains and continues, and another complains > > and exits. > > > > It would be nice if DM writers who invest time and money in YANG > > know what 'valid YANG' is, > > The problem is that in this case it depends on the environment (a file > cannot be found). So when my tool exits it doesn't say that the > module is invalid YANG. I believe all listed imports must resolve to a valid YANG module in order to parse a given YANG module successfully. This should be part of the language definition. What actually happens if a parser hits an unresolvable import is implementation specific. Some implementations may choose to stop immediately when they hit an unresolvable import while others may choose to complain loudly and try to continue as far as they get. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 17:46:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjgz-0001F4-TI; Wed, 09 Jan 2008 17:46:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCjgy-0001Et-NA for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 17:46:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjgy-0001Ej-DO for yang@ietf.org; Wed, 09 Jan 2008 17:46:36 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCjgw-0003l1-6O for yang@ietf.org; Wed, 09 Jan 2008 17:46:36 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DFA98A24E; Wed, 9 Jan 2008 23:46:33 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11736-09; Wed, 9 Jan 2008 23:46:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DF868A39B; Wed, 9 Jan 2008 23:46:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7BD19460123; Wed, 9 Jan 2008 23:46:27 +0100 (CET) Date: Wed, 9 Jan 2008 23:46:27 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] so many naming scopes Message-ID: <20080109224627.GE5390@elstar.local> Mail-Followup-To: Andy Bierman , "tom.petch" , yang@ietf.org References: <200801082230.m08MUP3O095222@idle.juniper.net> <012701c852d5$ff6ffc60$0601a8c0@pc6> <4784FD0D.6020103@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4784FD0D.6020103@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 09, 2008 at 08:57:49AM -0800, Andy Bierman wrote: > Now you bring up a new twist: > > typedef typedef { > type string; > } > > leaf leaf { > type typedef; > } > > IMO, there needs to be guidelines (in the form of SHOULD NOT text) > that says not to use YANG keywords for identifiers and not > to use the same values for typedefs, groupings, and object names, > even though it is allowed. Usage guidelines and "coding styles" are valuable. But they should not be part of the language itself. The example above is not ambiguous and easy to parse for a machine - even though it might look stupid to most humans. I do remember the fun I had when C++ came along with the 'new' keyword. The namespaces we have in YANG help to avoid such problems so that we can add keywords to YANG without risking to break something. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 18:04:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjyb-0003vR-9w; Wed, 09 Jan 2008 18:04:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCjya-0003uw-Ad for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 18:04:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjya-0003uo-0s for yang@ietf.org; Wed, 09 Jan 2008 18:04:48 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCjyZ-0003yf-KQ for yang@ietf.org; Wed, 09 Jan 2008 18:04:48 -0500 Received: (qmail 36295 invoked from network); 9 Jan 2008 23:04:46 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.84.5 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 9 Jan 2008 23:04:46 -0000 X-YMail-OSG: LQUmBGcVM1kohn8eDOB0.ZdaBylPAi9zmRUbD79Zez47vA6A Message-ID: <4785530E.3080007@andybierman.com> Date: Wed, 09 Jan 2008 15:04:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andy Bierman , "tom.petch" , yang@ietf.org Subject: Re: [YANG] so many naming scopes References: <200801082230.m08MUP3O095222@idle.juniper.net> <012701c852d5$ff6ffc60$0601a8c0@pc6> <4784FD0D.6020103@andybierman.com> <20080109224627.GE5390@elstar.local> In-Reply-To: <20080109224627.GE5390@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Wed, Jan 09, 2008 at 08:57:49AM -0800, Andy Bierman wrote: > >> Now you bring up a new twist: >> >> typedef typedef { >> type string; >> } >> >> leaf leaf { >> type typedef; >> } >> >> IMO, there needs to be guidelines (in the form of SHOULD NOT text) >> that says not to use YANG keywords for identifiers and not >> to use the same values for typedefs, groupings, and object names, >> even though it is allowed. > > Usage guidelines and "coding styles" are valuable. But they should not > be part of the language itself. The example above is not ambiguous and > easy to parse for a machine - even though it might look stupid to most > humans. > > I do remember the fun I had when C++ came along with the 'new' > keyword. The namespaces we have in YANG help to avoid such problems so > that we can add keywords to YANG without risking to break something. > Except that YANG has embedded coding style text already, such as the sentence about SHOULD NOT differ only in case. Names such as foo and Foo and perfectly valid. There is no reason whatsoever to have this text, same as a CLR about not having grouping foo and typedef foo, other than to enforce a coding style. (My suggestion was SHOULD, not MUST.) Standards are full of non-binding text (SHOULD, MAY) because it can encourage interoperability. Some people think multi-vendor interoperability is more important for a standard than single-vendor flexibility. > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 18:24:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCkHl-0004cX-2J; Wed, 09 Jan 2008 18:24:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCkHk-0004cR-J0 for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 18:24:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCkHk-0004cJ-90 for yang@ietf.org; Wed, 09 Jan 2008 18:24:36 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCkHj-0004BI-QK for yang@ietf.org; Wed, 09 Jan 2008 18:24:36 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CA568A3A5; Thu, 10 Jan 2008 00:24:35 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14600-02; Thu, 10 Jan 2008 00:24:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00BFB8A390; Thu, 10 Jan 2008 00:24:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D6552460278; Thu, 10 Jan 2008 00:24:27 +0100 (CET) Date: Thu, 10 Jan 2008 00:24:27 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] so many naming scopes Message-ID: <20080109232427.GA5551@elstar.local> Mail-Followup-To: Andy Bierman , "tom.petch" , yang@ietf.org References: <200801082230.m08MUP3O095222@idle.juniper.net> <012701c852d5$ff6ffc60$0601a8c0@pc6> <4784FD0D.6020103@andybierman.com> <20080109224627.GE5390@elstar.local> <4785530E.3080007@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4785530E.3080007@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 09, 2008 at 03:04:46PM -0800, Andy Bierman wrote: > Except that YANG has embedded coding style text already, > such as the sentence about SHOULD NOT differ only in case. > Names such as foo and Foo and perfectly valid. There is > no reason whatsoever to have this text, same as a CLR > about not having grouping foo and typedef foo, other than > to enforce a coding style. (My suggestion was SHOULD, not MUST.) So lets remove this "SHOULD NOT differ only in case" rule from the language specification and lets start a guidelines document (or an appendix for simplicity) where we collect such guidelines. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 09 21:40:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCnLW-0000MK-PV; Wed, 09 Jan 2008 21:40:42 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCnLW-0000MF-Br for yang-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 21:40:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCnLW-0000Lw-0s for yang@ietf.org; Wed, 09 Jan 2008 21:40:42 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCnLV-0007Ve-If for yang@ietf.org; Wed, 09 Jan 2008 21:40:41 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 09 Jan 2008 18:40:27 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jan 2008 18:35:07 -0800 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 m0A2Z2934480; Wed, 9 Jan 2008 18:35:02 -0800 (PST) (envelope-from phil@idle.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 m0A2Yu3m009933; Thu, 10 Jan 2008 02:34:56 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801100234.m0A2Yu3m009933@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] so many naming scopes In-reply-to: <20080109232427.GA5551@elstar.local> Date: Wed, 09 Jan 2008 21:34:56 -0500 From: Phil Shafer X-OriginalArrivalTime: 10 Jan 2008 02:35:07.0656 (UTC) FILETIME=[69FA1880:01C85331] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder writes: >So lets remove this "SHOULD NOT differ only in case" rule from the >language specification and lets start a guidelines document (or an >appendix for simplicity) where we collect such guidelines. Sounds great. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 10 02:57:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsHl-000200-Mr; Thu, 10 Jan 2008 02:57:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCsHj-0001xg-K6 for yang-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 02:57:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsHc-0001vM-JA for yang@ietf.org; Thu, 10 Jan 2008 02:57:00 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCsHc-0001pG-73 for yang@ietf.org; Thu, 10 Jan 2008 02:57:00 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 887E62180F for ; Thu, 10 Jan 2008 08:56:59 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-80-4785cfcb2ed0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6B33B217BD for ; Thu, 10 Jan 2008 08:56:59 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 08:56:59 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 08:56:59 +0100 Message-ID: <4785CFCA.4000506@ericsson.com> Date: Thu, 10 Jan 2008 08:56:58 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: yang@ietf.org Subject: Re: [YANG] so many naming scopes References: <200801082230.m08MUP3O095222@idle.juniper.net> <012701c852d5$ff6ffc60$0601a8c0@pc6> <4784FD0D.6020103@andybierman.com> <20080109224627.GE5390@elstar.local> In-Reply-To: <20080109224627.GE5390@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2008 07:56:59.0140 (UTC) FILETIME=[6084B440:01C8535E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > Usage guidelines and "coding styles" are valuable. But they should not > be part of the language itself. The example above is not ambiguous and > easy to parse for a machine - even though it might look stupid to most > humans. > I think our yardstick should be whether the example is easy to understand for humans. "Easy for machine" is far from enough. Balazs _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 10 03:09:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsTX-0007ls-9c; Thu, 10 Jan 2008 03:09:19 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCsTW-0007ea-EJ for yang-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 03:09:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsTW-0007d6-0G for yang@ietf.org; Thu, 10 Jan 2008 03:09:18 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCsTV-0001yR-JZ for yang@ietf.org; Thu, 10 Jan 2008 03:09:17 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A7088A256; Thu, 10 Jan 2008 09:09:17 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14441-03; Thu, 10 Jan 2008 09:09:12 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B4888A24E; Thu, 10 Jan 2008 09:09:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5DA6546072C; Thu, 10 Jan 2008 09:09:11 +0100 (CET) Date: Thu, 10 Jan 2008 09:09:11 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Subject: Re: [YANG] so many naming scopes Message-ID: <20080110080911.GC5872@elstar.local> Mail-Followup-To: Balazs Lengyel , yang@ietf.org References: <200801082230.m08MUP3O095222@idle.juniper.net> <012701c852d5$ff6ffc60$0601a8c0@pc6> <4784FD0D.6020103@andybierman.com> <20080109224627.GE5390@elstar.local> <4785CFCA.4000506@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4785CFCA.4000506@ericsson.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 10, 2008 at 08:56:58AM +0100, Balazs Lengyel wrote: > > > Juergen Schoenwaelder wrote: >> Usage guidelines and "coding styles" are valuable. But they should not >> be part of the language itself. The example above is not ambiguous and >> easy to parse for a machine - even though it might look stupid to most >> humans. >> > I think our yardstick should be whether the example is easy to > understand for humans. "Easy for machine" is far from enough. Sorry, I fail to get your point. Do you want to have a rule in the language saying "people must not use stupid identifiers"? This is really what we are talking about here and my point is that trying to define what makes a stupid identifier is a waste of time for the language definition itself. A good language will deal with stupid and non-stupid identifiers the same way. /js PS: We really need an April 1st RFC defining a standard for good code so that by claiming compliance to this RFC, we will eliminate all bad smelling code from the world. ;-) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 10 04:18:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCtYH-0006Af-Al; Thu, 10 Jan 2008 04:18:17 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCtYG-00060O-1v for yang-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 04:18:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCtYF-0005zM-LV for yang@ietf.org; Thu, 10 Jan 2008 04:18:15 -0500 Received: from relay.versatel.net ([62.250.3.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCtYF-0005J9-4m for yang@ietf.org; Thu, 10 Jan 2008 04:18:15 -0500 Received: (qmail 35731 invoked from network); 10 Jan 2008 09:18:13 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 10 Jan 2008 09:18:13 -0000 From: "Bert Wijnen - IETF" To: "Phil Shafer" , Subject: RE: [YANG] so many naming scopes Date: Thu, 10 Jan 2008 10:18:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200801100234.m0A2Yu3m009933@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org I also like to move the "SHOULD, SHOULD NOT, MAY and similar style information to a guidelines document. Be aware though, that this guidelines document will become our CLR guide. Similar to how RFC4181 became our CLR document for MIB modules. I am not saying that is bad. I in fact like some rules for standardized Data Models such that we will see consistency. It will help make things easier to use and read. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Phil Shafer [mailto:phil@juniper.net] > Verzonden: donderdag 10 januari 2008 3:35 > Aan: j.schoenwaelder@jacobs-university.de > CC: yang@ietf.org > Onderwerp: Re: [YANG] so many naming scopes > > > Juergen Schoenwaelder writes: > >So lets remove this "SHOULD NOT differ only in case" rule from the > >language specification and lets start a guidelines document (or an > >appendix for simplicity) where we collect such guidelines. > > Sounds great. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 10 07:29:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCwXe-0003AV-6D; Thu, 10 Jan 2008 07:29:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCwXc-0003AQ-DT for yang-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 07:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCwXb-0003AI-Ae for yang@ietf.org; Thu, 10 Jan 2008 07:29:48 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCwXa-0005nz-UF for yang@ietf.org; Thu, 10 Jan 2008 07:29:47 -0500 Received: (qmail 25864 invoked from network); 10 Jan 2008 12:29:46 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.84.5 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 10 Jan 2008 12:29:46 -0000 X-YMail-OSG: .Bunax0VM1n5jTpqkR497iIw6qiV1SSqYcuNdbjQQAuP0aTG Message-ID: <47860FBA.6090600@andybierman.com> Date: Thu, 10 Jan 2008 04:29:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [YANG] 7.8.3 unique statement X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, There seem to be many details left out for the unique-stmt (within a list) that need to be in a standard: - what if not all the leafs listed in the unique-stmt are mandatory? - is the unique-stmt ignored? - Is NULL-value treated as one of the unique values? - what if some missing leafs have defaults (ensuring they will not be unique)? - where are the detailed specifications of the canonical formats for each YANG datatype (especially bits, anyxml, string) so that every implementation will come up with the same answer when evaluating uniqueness? - what is the exact behavior required for a NETCONF agent wrt/ processing and unique-stmt enforcement? - Is there any significance to the order of node identifiers? unique "addr port"; unique "port addr"; - Are the target nodes limited to direct definitions and expanded uses? (I.e., unique clauses that include leafs expanded from augment not allowed) Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 10 10:14:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCz7H-0007lq-Sz; Thu, 10 Jan 2008 10:14:47 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JCz7G-0007ll-RT for yang-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 10:14:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCz7G-0007ld-HU for yang@ietf.org; Thu, 10 Jan 2008 10:14:46 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCz7F-0000VD-VI for yang@ietf.org; Thu, 10 Jan 2008 10:14:46 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 760531B80C3; Thu, 10 Jan 2008 16:14:40 +0100 (CET) Date: Thu, 10 Jan 2008 16:15:34 +0100 (CET) Message-Id: <20080110.161534.170913919.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] 7.8.3 unique statement From: Martin Bjorklund In-Reply-To: <47860FBA.6090600@andybierman.com> References: <47860FBA.6090600@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > There seem to be many details left out for the unique-stmt (within a list) > that need to be in a standard: Ok. > - what if not all the leafs listed in the unique-stmt are mandatory? > - is the unique-stmt ignored? > - Is NULL-value treated as one of the unique values? One use case is that you have a single optional leaf in your unique stmt. That means that if the leaf exists, it's value has to be unique. Another case is that you have multiple optional leafs, and the combination must be unique. For example, the combination of 'name' and 'address' in a list of persons is unique. If you have to persons with the same name, but no address, that would violate the uniqueness. So, the set of existing leafs must be unique within all list entries (if the set is non-empty). We'll have to try to find the right wording. > - what if some missing leafs have defaults (ensuring they will not be unique)? I think we should say that the leaf MUST NOT have a default. > - where are the detailed specifications of the canonical formats > for each YANG datatype (especially bits, anyxml, string) so that > every implementation will come up with the same answer when evaluating > uniqueness? Do we need a specification of a canonical format for this? Do we need a specification of a canonical format also in order to handle edit-config delete? > - what is the exact behavior required for a NETCONF agent wrt/ > processing and unique-stmt enforcement? It is not checked during edit-config specifically. The text says that the unique constraints have to be met in a valid configuration. So you might have temporary violations of these constraints in the candidate e.g. > - Is there any significance to the order of node identifiers? > unique "addr port"; > unique "port addr"; No. > - Are the target nodes limited to direct definitions and expanded uses? > (I.e., unique clauses that include leafs expanded from augment not allowed) Yes. This follows from the general rule that each definition must be completely defined within itself. One more thing that we have talked about adding, is to allow 'unique' in an augment. For example: augment /interface { unique "ifName"; leaf ifName { ... } ... } /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 10:53:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMCN-000570-HR; Fri, 11 Jan 2008 10:53:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDMCM-00056u-Ef for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 10:53:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMCF-000556-GG for yang@ietf.org; Fri, 11 Jan 2008 10:53:27 -0500 Received: from smtp121.sbc.mail.sp1.yahoo.com ([69.147.64.94]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDMCF-0001tD-1Y for yang@ietf.org; Fri, 11 Jan 2008 10:53:27 -0500 Received: (qmail 88270 invoked from network); 11 Jan 2008 15:53:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 11 Jan 2008 15:53:25 -0000 X-YMail-OSG: Tw3JjosVM1mc5yiZOQvtsDzJ4Ne3Rl23K8UnB74pqs1P4xOF Message-ID: <478790F4.1050807@andybierman.com> Date: Fri, 11 Jan 2008 07:53:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [YANG] insert and key attributes X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, 1) sec. 7.8.6 mentions the 'key' attribute (great, another overloaded term ;-) but this is not formally defined anywhere. The terse definition of the 'insert' attribute is not a formal definition either. In general, all the new requirements that YANG places on NETCONF agents is scattered throughout the document, and not entirely obvious. 2) para 4 in 7.8.6 says if insert is missing, then it defaults to last. Even in a list indexed by an integer. This seems strange to me, to use an integral key and then ignore the actual base type, but I guess 'ordered-by-user' implies that the base type of the key has no meaning to the agent. 3) The last example in 7.8.7 is confusing. (There is a typo "to move a the new user 'barney'".) If 'barney' was already inserted after 'fred' (previous page) then the merge of 'barney' before 'fred' will fail in NETCONF. There is no move operation in NETCONF. You cannot edit the value of a key. The example would actually have no affect in NETCONF, since the field was already set to 'barney'. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 11:24:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMg9-0000it-Na; Fri, 11 Jan 2008 11:24:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDMg9-0000il-7b for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 11:24:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMg8-0000ia-Rb for yang@ietf.org; Fri, 11 Jan 2008 11:24:20 -0500 Received: from smtp110.sbc.mail.mud.yahoo.com ([68.142.198.209]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDMg8-0002Vx-6u for yang@ietf.org; Fri, 11 Jan 2008 11:24:20 -0500 Received: (qmail 80687 invoked from network); 11 Jan 2008 16:24:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 11 Jan 2008 16:24:19 -0000 X-YMail-OSG: wuPMCUQVM1myyqfb5uG0a08K.zCGlyX.H7IHtJKI96IrBEKd Message-ID: <47879832.8020201@andybierman.com> Date: Fri, 11 Jan 2008 08:24:18 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] 7.8.3 unique statement References: <47860FBA.6090600@andybierman.com> <20080110.161534.170913919.mbj@tail-f.com> In-Reply-To: <20080110.161534.170913919.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> There seem to be many details left out for the unique-stmt (within a list) >> that need to be in a standard: > > Ok. > >> - what if not all the leafs listed in the unique-stmt are mandatory? >> - is the unique-stmt ignored? >> - Is NULL-value treated as one of the unique values? > > One use case is that you have a single optional leaf in your unique > stmt. That means that if the leaf exists, it's value has to be > unique. > > Another case is that you have multiple optional leafs, and the > combination must be unique. For example, the combination of 'name' > and 'address' in a list of persons is unique. If you have to persons > with the same name, but no address, that would violate the uniqueness. > > So, the set of existing leafs must be unique within all list entries > (if the set is non-empty). > Whether a leaf is mandatory or optional is separate from the unique statement. So the fully specified tuple must be present, and be unique [a b c] If optional 'b' is missing [a c] then the agent ignores that entry when enforcing the uniqueness property. (?!?) > We'll have to try to find the right wording. > >> - what if some missing leafs have defaults (ensuring they will not be unique)? > > I think we should say that the leaf MUST NOT have a default. no, what if the leaf is from a 'uses' expansion? It is also OK to apply the default once. > >> - where are the detailed specifications of the canonical formats >> for each YANG datatype (especially bits, anyxml, string) so that >> every implementation will come up with the same answer when evaluating >> uniqueness? > > Do we need a specification of a canonical format for this? > yes. For UTF-8 and float* there are references, but empty, bits, anyxml, instance-identifier, keyref, and even numbers (17 or +17) need canonical representations in order to compare entries. > Do we need a specification of a canonical format also in order to > handle edit-config delete? > that is a side benefit (this is new NETCONF data modeling turf that has never been properly addressed) > >> - what is the exact behavior required for a NETCONF agent wrt/ >> processing and unique-stmt enforcement? > > It is not checked during edit-config specifically. The text says that > the unique constraints have to be met in a valid configuration. So > you might have temporary violations of these constraints in the > candidate e.g. good point (it is edit-config only if the target is ) > >> - Is there any significance to the order of node identifiers? >> unique "addr port"; >> unique "port addr"; > > No. > >> - Are the target nodes limited to direct definitions and expanded uses? >> (I.e., unique clauses that include leafs expanded from augment not allowed) > > Yes. This follows from the general rule that each definition must be > completely defined within itself. good > > > One more thing that we have talked about adding, is to allow 'unique' > in an augment. For example: > > augment /interface { > unique "ifName"; > leaf ifName { ... } > ... > } > I would rather not add this feature until the requirements for "augments" are better understood. One augments concern: what does it mean to declare conformance to a module? If module FOO-MIB includes X and Y, but the vendor also has module MY-FOO-MIB that adds a mandatory Z, does that vendor really conform to FOO-MIB? A manager that only knows about FOO-MIB and not MY-FOO-MIB will not work, so IMO the agent MUST NOT advertise that it supports FOO-MIB. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 11:43:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMyU-0002Um-74; Fri, 11 Jan 2008 11:43:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDMyS-0002MT-QA for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 11:43:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMyS-0002ML-GZ for yang@ietf.org; Fri, 11 Jan 2008 11:43:16 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDMyR-00082o-Vz for yang@ietf.org; Fri, 11 Jan 2008 11:43:16 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 0ED5F1B80D8; Fri, 11 Jan 2008 17:43:14 +0100 (CET) Date: Fri, 11 Jan 2008 17:44:10 +0100 (CET) Message-Id: <20080111.174410.174968555.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] 7.8.3 unique statement From: Martin Bjorklund In-Reply-To: <47879832.8020201@andybierman.com> References: <47860FBA.6090600@andybierman.com> <20080110.161534.170913919.mbj@tail-f.com> <47879832.8020201@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > So, the set of existing leafs must be unique within all list entries > > (if the set is non-empty). > > > > Whether a leaf is mandatory or optional is separate from the unique statement. > > So the fully specified tuple must be present, and be unique [a b c] > If optional 'b' is missing [a c] then the agent ignores that entry > when enforcing the uniqueness property. (?!?) Yes. > > We'll have to try to find the right wording. > > > >> - what if some missing leafs have defaults (ensuring they will not be unique)? > > > > I think we should say that the leaf MUST NOT have a default. > > > no, what if the leaf is from a 'uses' expansion? I don't understand. > It is also OK to apply the default once. So you would allow one instance with the default, and the rest has to have values set? > > One more thing that we have talked about adding, is to allow 'unique' > > in an augment. For example: > > > > augment /interface { > > unique "ifName"; > > leaf ifName { ... } > > ... > > } > > > > I would rather not add this feature until the requirements for "augments" > are better understood. Ok. > > One augments concern: what does it mean to declare conformance to a module? > If module FOO-MIB includes X and Y, but the vendor also has module > MY-FOO-MIB that adds a mandatory Z, does that vendor really conform to FOO-MIB? > A manager that only knows about FOO-MIB and not MY-FOO-MIB will not work, > so IMO the agent MUST NOT advertise that it supports FOO-MIB. > But that won't work. If I impplement FOO-MIB, how do I know that there is some other module somewhere that augments it? I think we have to restrict the augment to not augment with any mandatory nodes. This is be similar to the rules for versioning - you are not allowed to add mandatory nodes in a new revision of the module. And the reason in both these cases is the same - to make sure that clients that uses the old revision (or not using the module with the augment) still work. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 12:03:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNHs-0002CK-71; Fri, 11 Jan 2008 12:03:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDNHq-00021k-SZ for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 12:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNHq-0001zp-Hw for yang@ietf.org; Fri, 11 Jan 2008 12:03:18 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JDNHo-0000rn-E5 for yang@ietf.org; Fri, 11 Jan 2008 12:03:18 -0500 Received: (qmail 23018 invoked from network); 11 Jan 2008 17:03:15 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 11 Jan 2008 17:03:15 -0000 X-YMail-OSG: kLwUkmYVM1mP.H43nsAvGynBWh5dZpyEvl0p_tJuJVhCyE8s Message-ID: <4787A152.4030104@andybierman.com> Date: Fri, 11 Jan 2008 09:03:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] 7.8.3 unique statement References: <47860FBA.6090600@andybierman.com> <20080110.161534.170913919.mbj@tail-f.com> <47879832.8020201@andybierman.com> <20080111.174410.174968555.mbj@tail-f.com> In-Reply-To: <20080111.174410.174968555.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> So, the set of existing leafs must be unique within all list entries >>> (if the set is non-empty). >>> >> Whether a leaf is mandatory or optional is separate from the unique statement. >> >> So the fully specified tuple must be present, and be unique [a b c] >> If optional 'b' is missing [a c] then the agent ignores that entry >> when enforcing the uniqueness property. (?!?) > > Yes. > >>> We'll have to try to find the right wording. >>> >>>> - what if some missing leafs have defaults (ensuring they will not be unique)? >>> I think we should say that the leaf MUST NOT have a default. >> >> no, what if the leaf is from a 'uses' expansion? > > I don't understand. > If the leaf with the default is in a grouping, then that is because the DM writer wanted it that way, and if the grouping is used in other places (than this example) the default is OK. >> It is also OK to apply the default once. > > So you would allow one instance with the default, and the rest has to > have values set? > no -- the value specified by the default can be used once. If the leaf is not provided, and its value has not been used yet, then it is OK to apply the default and still be unique. >>> One more thing that we have talked about adding, is to allow 'unique' >>> in an augment. For example: >>> >>> augment /interface { >>> unique "ifName"; >>> leaf ifName { ... } >>> ... >>> } >>> >> I would rather not add this feature until the requirements for "augments" >> are better understood. > > Ok. > >> >> One augments concern: what does it mean to declare conformance to a module? >> If module FOO-MIB includes X and Y, but the vendor also has module >> MY-FOO-MIB that adds a mandatory Z, does that vendor really conform to FOO-MIB? >> A manager that only knows about FOO-MIB and not MY-FOO-MIB will not work, >> so IMO the agent MUST NOT advertise that it supports FOO-MIB. >> > > But that won't work. If I impplement FOO-MIB, how do I know that > there is some other module somewhere that augments it? I think we > have to restrict the augment to not augment with any mandatory nodes. > If the manager sees FOO-MIB in the schema-discovery or capabilities, then it will assume this MIB can be used. No other modules or capabilities can override the contract that is implied by the definitions in FOO-MIB. Period. So MY-FOO-MIB MUST NOT add anything that breaks the FOO-MIB contract, if the vendor wants to claim conformance to FOO-MIB. > This is be similar to the rules for versioning - you are not allowed > to add mandatory nodes in a new revision of the module. And the > reason in both these cases is the same - to make sure that clients > that uses the old revision (or not using the module with the augment) > still work. Standard data models require more than a language. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 12:12:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNQU-0002g1-Ss; Fri, 11 Jan 2008 12:12:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDNQS-0002fv-WB for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 12:12:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNQS-0002fk-Ll for yang@ietf.org; Fri, 11 Jan 2008 12:12:12 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDNQS-00060i-8M for yang@ietf.org; Fri, 11 Jan 2008 12:12:12 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 58C321B80D8; Fri, 11 Jan 2008 18:12:11 +0100 (CET) Date: Fri, 11 Jan 2008 18:13:07 +0100 (CET) Message-Id: <20080111.181307.139544515.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] 7.8.3 unique statement From: Martin Bjorklund In-Reply-To: <4787A152.4030104@andybierman.com> References: <47879832.8020201@andybierman.com> <20080111.174410.174968555.mbj@tail-f.com> <4787A152.4030104@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > >> It is also OK to apply the default once. > > > > So you would allow one instance with the default, and the rest has to > > have values set? > > > > no -- the value specified by the default can be used once. > If the leaf is not provided, and its value has not been used > yet, then it is OK to apply the default and still be unique. I think that this translates to treating a leaf that has its default the same way as a non-existing leaf (in the unique test). > >> > >> One augments concern: what does it mean to declare conformance to a module? > >> If module FOO-MIB includes X and Y, but the vendor also has module > >> MY-FOO-MIB that adds a mandatory Z, does that vendor really conform to FOO-MIB? > >> A manager that only knows about FOO-MIB and not MY-FOO-MIB will not work, > >> so IMO the agent MUST NOT advertise that it supports FOO-MIB. > >> > > > > But that won't work. If I impplement FOO-MIB, how do I know that > > there is some other module somewhere that augments it? I think we > > have to restrict the augment to not augment with any mandatory nodes. > > > > If the manager sees FOO-MIB in the schema-discovery or capabilities, > then it will assume this MIB can be used. No other modules or > capabilities can override the contract that is implied by the > definitions in FOO-MIB. Period. So MY-FOO-MIB MUST NOT > add anything that breaks the FOO-MIB contract, if the vendor > wants to claim conformance to FOO-MIB. Exactly. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 12:27:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNfE-0005Sh-2n; Fri, 11 Jan 2008 12:27:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDNfD-0005Sb-5W for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 12:27:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNfC-0005ST-SA for yang@ietf.org; Fri, 11 Jan 2008 12:27:26 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDNfC-0001Mu-Et for yang@ietf.org; Fri, 11 Jan 2008 12:27:26 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BF6F420845; Fri, 11 Jan 2008 18:27:25 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-8e-4787a6fdece5 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A063B20479; Fri, 11 Jan 2008 18:27:25 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 18:27:25 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 18:27:25 +0100 Message-ID: <4787B188.5010301@ericsson.com> Date: Fri, 11 Jan 2008 19:12:24 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] 7.8.3 unique statement References: <47879832.8020201@andybierman.com> <20080111.174410.174968555.mbj@tail-f.com> <4787A152.4030104@andybierman.com> <20080111.181307.139544515.mbj@tail-f.com> In-Reply-To: <20080111.181307.139544515.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2008 17:27:25.0147 (UTC) FILETIME=[3B38AAB0:01C85477] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>>> It is also OK to apply the default once. >>> So you would allow one instance with the default, and the rest has to >>> have values set? >>> >> no -- the value specified by the default can be used once. >> If the leaf is not provided, and its value has not been used >> yet, then it is OK to apply the default and still be unique. > > I think that this translates to treating a leaf that has its default > the same way as a non-existing leaf (in the unique test). > > I don't understand the difference between Martin's original proposal and Andy's. Can you give me an example please ? Can I create two such leafs without specifying the value i.e. using the default? That sounds a strange kind of unique to me. Balazs _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 15:40:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDQg2-0008B8-1q; Fri, 11 Jan 2008 15:40:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDQg1-0008B3-1V for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 15:40:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDQg0-0008Av-7V for yang@ietf.org; Fri, 11 Jan 2008 15:40:28 -0500 Received: from exprod7og102.obsmtp.com ([64.18.2.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDQfz-0004o8-R0 for yang@ietf.org; Fri, 11 Jan 2008 15:40:28 -0500 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Fri, 11 Jan 2008 12:40:15 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 12:39:26 -0800 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 m0BKdQ946977; Fri, 11 Jan 2008 12:39:26 -0800 (PST) (envelope-from phil@idle.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 m0BKdNDl037488; Fri, 11 Jan 2008 20:39:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801112039.m0BKdNDl037488@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] insert and key attributes In-reply-to: <478790F4.1050807@andybierman.com> Date: Fri, 11 Jan 2008 15:39:22 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Jan 2008 20:39:26.0284 (UTC) FILETIME=[0E5AA8C0:01C85492] X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >1) sec. 7.8.6 mentions the 'key' attribute (great, another > overloaded term ;-) but this is not formally defined anywhere. > The terse definition of the 'insert' attribute is not a formal > definition either. Yup, this needs some additional words. > In general, all the new requirements > that YANG places on NETCONF agents is scattered throughout > the document, and not entirely obvious. What are you envisioning? A section for NETCONF agent authors that don't want to read the entire document? >2) para 4 in 7.8.6 says if insert is missing, then it defaults > to last. Even in a list indexed by an integer. This seems > strange to me, to use an integral key and then ignore the actual > base type, but I guess 'ordered-by-user' implies that the base type > of the key has no meaning to the agent. Exactly. The key gives uniqueness but not order. >3) The last example in 7.8.7 is confusing. > (There is a typo "to move a the new user 'barney'".) > If 'barney' was already inserted after 'fred' (previous page) > then the merge of 'barney' before 'fred' will fail in NETCONF. > There is no move operation in NETCONF. You cannot edit the > value of a key. The example would actually have no affect > in NETCONF, since the field was already set to 'barney'. YANG uses "merge" w/ insert to move existing data, since not having a move operation is a bug. Do we need to define our own "yang:operation='move'" to achieve this? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 11 18:00:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDSr8-0001g4-GV; Fri, 11 Jan 2008 18:00:06 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDSr7-0001fz-OG for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 18:00:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDSr7-0001fr-Ec for yang@ietf.org; Fri, 11 Jan 2008 18:00:05 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JDSr7-0006nV-0b for yang@ietf.org; Fri, 11 Jan 2008 18:00:05 -0500 Received: (qmail 90849 invoked from network); 11 Jan 2008 23:00:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 11 Jan 2008 23:00:04 -0000 X-YMail-OSG: jHKUUmEVM1kYRKdXWGy631M2KFi9J6qhI8S6Q.TZGewsIRf8 Message-ID: <4787F4F4.6000503@andybierman.com> Date: Fri, 11 Jan 2008 15:00:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] insert and key attributes References: <200801112039.m0BKdNDl037488@idle.juniper.net> In-Reply-To: <200801112039.m0BKdNDl037488@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> 1) sec. 7.8.6 mentions the 'key' attribute (great, another >> overloaded term ;-) but this is not formally defined anywhere. >> The terse definition of the 'insert' attribute is not a formal >> definition either. > > Yup, this needs some additional words. > >> In general, all the new requirements >> that YANG places on NETCONF agents is scattered throughout >> the document, and not entirely obvious. > > What are you envisioning? A section for NETCONF agent authors that > don't want to read the entire document? > >> 2) para 4 in 7.8.6 says if insert is missing, then it defaults >> to last. Even in a list indexed by an integer. This seems >> strange to me, to use an integral key and then ignore the actual >> base type, but I guess 'ordered-by-user' implies that the base type >> of the key has no meaning to the agent. > > Exactly. The key gives uniqueness but not order. > >> 3) The last example in 7.8.7 is confusing. >> (There is a typo "to move a the new user 'barney'".) >> If 'barney' was already inserted after 'fred' (previous page) >> then the merge of 'barney' before 'fred' will fail in NETCONF. >> There is no move operation in NETCONF. You cannot edit the >> value of a key. The example would actually have no affect >> in NETCONF, since the field was already set to 'barney'. > > YANG uses "merge" w/ insert to move existing data, since not having > a move operation is a bug. Do we need to define our own > "yang:operation='move'" to achieve this? > I do not agree. The WG did not want a move operation. The set of operations is decided by consensus. Whatever DML is used for NETCONF, it needs to work with the protocol the way it is defined. I think the DML should be separate from the protocol. The YANG document should not be defining any protocol extensions or changes. > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 00:50:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDvjQ-0006qj-38; Sun, 13 Jan 2008 00:50:04 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDvjO-0006pU-7e for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 00:50:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDvjH-0006l0-I1 for yang@ietf.org; Sun, 13 Jan 2008 00:49:55 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDvjH-0002Wg-1O for yang@ietf.org; Sun, 13 Jan 2008 00:49:55 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Sat, 12 Jan 2008 21:49:53 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Jan 2008 21:49:42 -0800 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 m0D5nb964053; Sat, 12 Jan 2008 21:49:42 -0800 (PST) (envelope-from phil@idle.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 m0D5nSFR049573; Sun, 13 Jan 2008 05:49:33 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801130549.m0D5nSFR049573@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] insert and key attributes In-reply-to: <4787F4F4.6000503@andybierman.com> Date: Sun, 13 Jan 2008 00:49:28 -0500 From: Phil Shafer X-OriginalArrivalTime: 13 Jan 2008 05:49:42.0755 (UTC) FILETIME=[181E1330:01C855A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >The WG did not want a move operation. s/did not want/could not agree/ We pitched an lot of very useful features during the dark ages of netconf. >Whatever DML is used for NETCONF, it needs to work >with the protocol the way it is defined. YANG adds "insert" also, which NETCONF does not define. Are we to pitch that also? Assumably not, since YANG defines not only the data model, but how to manipulate that model in a non-stone age manner. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 08:30:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE2uy-0001Pj-Lp; Sun, 13 Jan 2008 08:30:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JDUDU-0001QA-1t for yang-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 19:27:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDUDT-0001Q2-Mj for yang@ietf.org; Fri, 11 Jan 2008 19:27:15 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDUDT-0007A8-7Z for yang@ietf.org; Fri, 11 Jan 2008 19:27:15 -0500 Received: (qmail 98928 invoked from network); 12 Jan 2008 00:27:14 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 12 Jan 2008 00:27:13 -0000 X-YMail-OSG: BvwfBzcVM1nR5SwjHQTprCbrlgszxaa5sHN.41m_PLTTPsEb Message-ID: <47880961.1030506@andybierman.com> Date: Fri, 11 Jan 2008 16:27:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Sun, 13 Jan 2008 08:30:26 -0500 Subject: [YANG] 7.6, default value for a type X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Sec 7.6, para 5 says: 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. The default value for each builtin type is not defined anywhere. This is a nice detail, and covers things like the agent creating a bunch of counter objects or ifOperStatus objects. It mandates that a specific value will be used, not random values. What are the specific values? - int8 to uint64: 0 - float32, float64: 0.0 - string, binary, instance-identifier: empty string - enumeration: ??? (!) [first value?] - boolean: false - bits: empty bitset - keyref: default for data type of 'path' Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 08:43:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE37c-0001RE-Lp; Sun, 13 Jan 2008 08:43:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JE37b-0001Dx-0C for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 08:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE37U-0000lD-3T for yang@ietf.org; Sun, 13 Jan 2008 08:43:24 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JE37S-00074Y-EB for yang@ietf.org; Sun, 13 Jan 2008 08:43:24 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 526B68A32E; Sun, 13 Jan 2008 14:43:21 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13935-07; Sun, 13 Jan 2008 14:43:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA1858A329; Sun, 13 Jan 2008 14:43:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 94CBF465D70; Sun, 13 Jan 2008 14:43:15 +0100 (CET) Date: Sun, 13 Jan 2008 14:43:15 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] 7.6, default value for a type Message-ID: <20080113134315.GA25434@elstar.local> Mail-Followup-To: Andy Bierman , yang References: <47880961.1030506@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47880961.1030506@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Jan 11, 2008 at 04:27:13PM -0800, Andy Bierman wrote: > Sec 7.6, para 5 says: > > 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. > > The default value for each builtin type is not defined anywhere. > This is a nice detail, and covers things like the agent creating > a bunch of counter objects or ifOperStatus objects. > > It mandates that a specific value will be used, not random values. > > What are the specific values? > > - int8 to uint64: 0 > - float32, float64: 0.0 > - string, binary, instance-identifier: empty string > - enumeration: ??? (!) [first value?] > - boolean: false > - bits: empty bitset > - keyref: default for data type of 'path' Why not leave it undefined? It is easy to define defaults: typedef int8-zero { type int8; default 0; } If we hard wire defaults, it will be a pain to define a type which does not have a default, e.g. for an SNMP counter. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 09:56:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE4GH-0001tv-MA; Sun, 13 Jan 2008 09:56:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JE4GG-0001tq-6B for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 09:56:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE4GF-0001ti-Sh for yang@ietf.org; Sun, 13 Jan 2008 09:56:31 -0500 Received: from smtp106.sbc.mail.re2.yahoo.com ([68.142.229.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JE4GD-0007yJ-NX for yang@ietf.org; Sun, 13 Jan 2008 09:56:31 -0500 Received: (qmail 72862 invoked from network); 13 Jan 2008 14:56:29 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp106.sbc.mail.re2.yahoo.com with SMTP; 13 Jan 2008 14:56:29 -0000 X-YMail-OSG: uPjCq.oVM1nsqRfM7e7CkhCby5W2x98Fm2fQkE98vLCLAo9F Message-ID: <478A2621.2060603@andybierman.com> Date: Sun, 13 Jan 2008 06:54:25 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] insert and key attributes References: <200801130549.m0D5nSFR049573@idle.juniper.net> In-Reply-To: <200801130549.m0D5nSFR049573@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The WG did not want a move operation. > > s/did not want/could not agree/ > > We pitched an lot of very useful features during the dark ages > of netconf. In your opinion they were useful. It takes WG consensus to make a standard -- that is my point. > >> Whatever DML is used for NETCONF, it needs to work >> with the protocol the way it is defined. > > YANG adds "insert" also, which NETCONF does not define. Are > we to pitch that also? Assumably not, since YANG defines > not only the data model, but how to manipulate that model > in a non-stone age manner. How is a manager supposed to know that the agent uses the "-00 YANG" version of the NETCONF protocol, vs. the "-01 YANG" version vs. "RFC 4741 NETCONF"? You can add these XML attributes to the waiting list of features for the NETCONF WG to consider in a future version of the standard, but since these additions directly assist configuration, don't expect the WG to ever get to it. > > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 11:36:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE5p4-0004SP-Vn; Sun, 13 Jan 2008 11:36:34 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JE5p3-0004SK-OA for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 11:36:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE5p3-0004SB-Do for yang@ietf.org; Sun, 13 Jan 2008 11:36:33 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE5p3-0002Jv-2j for yang@ietf.org; Sun, 13 Jan 2008 11:36:33 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id A689E1B80C4; Sun, 13 Jan 2008 17:36:31 +0100 (CET) Date: Sun, 13 Jan 2008 17:35:32 +0100 (CET) Message-Id: <20080113.173532.102915601.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] insert and key attributes From: Martin Bjorklund In-Reply-To: <478A2621.2060603@andybierman.com> References: <200801130549.m0D5nSFR049573@idle.juniper.net> <478A2621.2060603@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > How is a manager supposed to know that the agent uses the "-00 YANG" > version of the NETCONF protocol, vs. the "-01 YANG" version > vs. "RFC 4741 NETCONF"? If the manager knows the datamodel, then it knows how to manipulate an ordered-by user list; it also knows which element(s) are keys, how they are encoded to XML etc. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 12:45:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE6ty-0000Dn-FW; Sun, 13 Jan 2008 12:45:42 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JE6ty-0000Dh-07 for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 12:45:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE6tx-0000DY-Mi for yang@ietf.org; Sun, 13 Jan 2008 12:45:41 -0500 Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JE6tx-0002So-AU for yang@ietf.org; Sun, 13 Jan 2008 12:45:41 -0500 Received: (qmail 48448 invoked from network); 13 Jan 2008 17:45:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 13 Jan 2008 17:45:40 -0000 X-YMail-OSG: .ur3_p4VM1nAJk8vCAm3z256ieccUVjNhIQYD2EMFSxz0SlA Message-ID: <478A4DC7.1020705@andybierman.com> Date: Sun, 13 Jan 2008 09:43:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] insert and key attributes References: <200801130549.m0D5nSFR049573@idle.juniper.net> <478A2621.2060603@andybierman.com> <20080113.173532.102915601.mbj@tail-f.com> In-Reply-To: <20080113.173532.102915601.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> How is a manager supposed to know that the agent uses the "-00 YANG" >> version of the NETCONF protocol, vs. the "-01 YANG" version >> vs. "RFC 4741 NETCONF"? > > If the manager knows the datamodel, then it knows how to manipulate an > ordered-by user list; it also knows which element(s) are keys, how > they are encoded to XML etc. > IMO, it is important to separate the data modeling language from the protocol, and to keep the NETCONF protocol as DML-neutral as possible. It doesn't seem like a good idea for interoperability to have one flavor of NETCONF if the vendor uses YANG data models and another if the vendor uses XSD or RelaxNG. Even worse, what if the vendor publishes some modules as YANG, others as XSD, and there are different flavors of NETCONF within the same agent. Note that error-app-tag and error-message are not extensions to the protocol at all -- they simply specify values for fields already defined in . But the key and insert attributes change the behavior of the operation. It doesn't matter that they change it for the better, by adding support for user-ordered lists. What matters is that a standard protocol needs to be changed by a WG, and should be done in a way that is not specific to one particular DML. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 13:01:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE79A-0001Qe-TR; Sun, 13 Jan 2008 13:01:24 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JE799-0001QZ-6v for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 13:01:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE798-0001QQ-Rz for yang@ietf.org; Sun, 13 Jan 2008 13:01:22 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE798-0003l2-90 for yang@ietf.org; Sun, 13 Jan 2008 13:01:22 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAD818A2DA; Sun, 13 Jan 2008 19:01:20 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30989-08-5; Sun, 13 Jan 2008 19:01:15 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25AEE8A350; Sun, 13 Jan 2008 19:01:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D05F046661E; Sun, 13 Jan 2008 19:01:13 +0100 (CET) Date: Sun, 13 Jan 2008 19:01:13 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] insert and key attributes Message-ID: <20080113180113.GA26178@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , yang@ietf.org References: <200801130549.m0D5nSFR049573@idle.juniper.net> <478A2621.2060603@andybierman.com> <20080113.173532.102915601.mbj@tail-f.com> <478A4DC7.1020705@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478A4DC7.1020705@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Sun, Jan 13, 2008 at 09:43:35AM -0800, Andy Bierman wrote: > IMO, it is important to separate the data modeling language > from the protocol, and to keep the NETCONF protocol as DML-neutral > as possible. A protocol and its data modeling language go hand in hand. > It doesn't seem like a good idea for interoperability to > have one flavor of NETCONF if the vendor uses YANG data models > and another if the vendor uses XSD or RelaxNG. Even worse, > what if the vendor publishes some modules as YANG, others > as XSD, and there are different flavors of NETCONF within > the same agent. XSD and RelaxNG without extensions and restrictions won't be terrible useful for YANG. So if at all, we talk about XSD-+ and RelaxNG-+. > But the key and insert attributes change the behavior of the > operation. It doesn't matter that they change it for > the better, by adding support for user-ordered lists. What matters > is that a standard protocol needs to be changed by a WG, and should > be done in a way that is not specific to one particular DML. If there are things in YANG that really belong to the protocol, we should turn them into proper protocol extension proposals for the NETCONF working group to consider. The end goal is to make NETCONF a success and if there are things where the protocol needs improvement based on implementation experience, then lets work out the details and get the NETCONF WG to look at it. I think it would be good if the NETCONF WG would have a plan to revise the NETCONF spec - if alone to fix known bugs and ambiguities. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 16:39:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEAYf-0001xn-D5; Sun, 13 Jan 2008 16:39:57 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEAYd-0001tn-Iz for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 16:39:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEAYd-0001te-9F for yang@ietf.org; Sun, 13 Jan 2008 16:39:55 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEAYc-0005kd-UP for yang@ietf.org; Sun, 13 Jan 2008 16:39:55 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id A7E061B80C4; Sun, 13 Jan 2008 22:39:52 +0100 (CET) Date: Sun, 13 Jan 2008 22:38:52 +0100 (CET) Message-Id: <20080113.223852.227441890.mbj@tail-f.com> To: andy@andybierman.com Subject: Re: [YANG] 7.6, default value for a type From: Martin Bjorklund In-Reply-To: <47880961.1030506@andybierman.com> References: <47880961.1030506@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > Sec 7.6, para 5 says: > > 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. > > The default value for each builtin type is not defined anywhere. This is supposed to be a feature, not a bug. If every type has a default, you will never be able to define optional leafs. > This is a nice detail, and covers things like the agent creating > a bunch of counter objects or ifOperStatus objects. Yes. Define ifOperStatus with a default, or use a type with a default. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 18:28:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JECFM-0001B1-NH; Sun, 13 Jan 2008 18:28:08 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JECFL-00016y-Gu for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 18:28:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JECFK-00015S-V6 for yang@ietf.org; Sun, 13 Jan 2008 18:28:06 -0500 Received: from smtp113.sbc.mail.re2.yahoo.com ([68.142.229.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JECFK-0007qW-Js for yang@ietf.org; Sun, 13 Jan 2008 18:28:06 -0500 Received: (qmail 56520 invoked from network); 13 Jan 2008 23:28:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp113.sbc.mail.re2.yahoo.com with SMTP; 13 Jan 2008 23:28:05 -0000 X-YMail-OSG: ffI.LpAVM1k56COqZP.zx71kqvD8SjkRxZCPHY9E_BuGDKOgu5VVsCHbf0iq2BlE3MlTvzlTna9WnPHmtHAVxq2slVlYOza8BR5pBEUnC4YYXGWsfQ38 Message-ID: <478A9EB5.9060800@andybierman.com> Date: Sun, 13 Jan 2008 15:28:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] 7.6, default value for a type References: <47880961.1030506@andybierman.com> <20080113.223852.227441890.mbj@tail-f.com> In-Reply-To: <20080113.223852.227441890.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Sec 7.6, para 5 says: >> >> 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. >> >> The default value for each builtin type is not defined anywhere. > > This is supposed to be a feature, not a bug. If every type has a > default, you will never be able to define optional leafs. > The text is misleading. The builtin types do not have default values(good!) The order to check the default-stmt is 1) leaf 2) typedef >> This is a nice detail, and covers things like the agent creating >> a bunch of counter objects or ifOperStatus objects. > > Yes. Define ifOperStatus with a default, or use a type with a > default. > > > /martin > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 13 23:10:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEGf3-0006KK-55; Sun, 13 Jan 2008 23:10:57 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEGf2-0006Fc-CO for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 23:10:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEGf1-00068W-Hl for yang@ietf.org; Sun, 13 Jan 2008 23:10:55 -0500 Received: from exprod7og103.obsmtp.com ([64.18.2.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEGf1-0006ff-3V for yang@ietf.org; Sun, 13 Jan 2008 23:10:55 -0500 Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sun, 13 Jan 2008 20:10:27 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 13 Jan 2008 20:06:52 -0800 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 m0E46q957524; Sun, 13 Jan 2008 20:06:52 -0800 (PST) (envelope-from phil@idle.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 m0E46gCC053535; Mon, 14 Jan 2008 04:06:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801140406.m0E46gCC053535@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] insert and key attributes In-reply-to: <478A4DC7.1020705@andybierman.com> Date: Sun, 13 Jan 2008 23:06:41 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Jan 2008 04:06:52.0583 (UTC) FILETIME=[E4D24B70:01C85662] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >But the key and insert attributes change the behavior of >the operation. Are you trying to say that NETCONF limits the ability of the data model to use attributes to perform additional config operations within an ? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 00:58:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEIKp-0007Je-8m; Mon, 14 Jan 2008 00:58:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEIKn-0007Dj-RC for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 00:58:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEIKn-0007Bh-Fs for yang@ietf.org; Mon, 14 Jan 2008 00:58:09 -0500 Received: from smtp111.sbc.mail.mud.yahoo.com ([68.142.198.210]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JEIKn-0004bm-5V for yang@ietf.org; Mon, 14 Jan 2008 00:58:09 -0500 Received: (qmail 4100 invoked from network); 14 Jan 2008 05:58:08 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 14 Jan 2008 05:58:08 -0000 X-YMail-OSG: m5NzgX4VM1kFUeS2LB11uJS3hKimbn15xcgIkbne8s6hVROX Message-ID: <478AFA5A.5040505@andybierman.com> Date: Sun, 13 Jan 2008 21:59:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] insert and key attributes References: <200801140406.m0E46gCC053535@idle.juniper.net> In-Reply-To: <200801140406.m0E46gCC053535@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> But the key and insert attributes change the behavior of >> the operation. > > Are you trying to say that NETCONF limits the ability of the data > model to use attributes to perform additional config operations > within an ? > Conformance to RFC 4741 does not require any additional attributes for . If the same operation without the YANG attributes does not produce the same result, like the 'move barney' example, then the agent is not RFC 4741 compliant. You can redefine NETCONF all you want -- just don't claim conformance to RFC 4741. > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 03:43:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEKuW-00020C-CF; Mon, 14 Jan 2008 03:43:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEKuU-0001xa-KO for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 03:43:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEKuN-0001bK-Jm for yang@ietf.org; Mon, 14 Jan 2008 03:43:03 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEKuN-0002RC-7W for yang@ietf.org; Mon, 14 Jan 2008 03:43:03 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 7CF271B80C4; Mon, 14 Jan 2008 09:43:01 +0100 (CET) Date: Mon, 14 Jan 2008 09:44:03 +0100 (CET) Message-Id: <20080114.094403.17841730.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] insert and key attributes From: Martin Bjorklund In-Reply-To: <478AFA5A.5040505@andybierman.com> References: <200801140406.m0E46gCC053535@idle.juniper.net> <478AFA5A.5040505@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Conformance to RFC 4741 does not require any additional > attributes for . RFC4741 is pretty silent on the semantics of the edit-config operations... by design. > If the same operation > without the YANG attributes does not produce the same result, > like the 'move barney' example, then the agent is not RFC 4741 > compliant. I don't agree with this statement. Where in RFC4741 is this rule described? Are you saying that attributes are special, and that for any NETCONF compliant request, I should be able to remove all attributes and get the same result? (This would of course rule out any implementation that uses XML attributes for encoding of data, which rfc 4741 does not do.) If not, how am I supposed to know which attributes I can remove? Are you suggesting that we should remove 'ordered-by user' from YANG? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 04:27:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JELbf-0001c6-To; Mon, 14 Jan 2008 04:27:47 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JELbe-0001c0-Oc for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 04:27:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JELbe-0001bs-EJ for yang@ietf.org; Mon, 14 Jan 2008 04:27:46 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JELbe-0003lF-0U for yang@ietf.org; Mon, 14 Jan 2008 04:27:46 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E9BC793802C; Mon, 14 Jan 2008 10:27:44 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-d3-478b2b10c5b1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BAA9020AC5; Mon, 14 Jan 2008 10:27:44 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 10:27:44 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 10:27:44 +0100 Message-ID: <478B2B0F.9030101@ericsson.com> Date: Mon, 14 Jan 2008 10:27:43 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2008 09:27:44.0377 (UTC) FILETIME=[B7C8EE90:01C8568F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [YANG] tools info request X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello Martin, What is the search path of pyang? If you don't use the -p option, where does it search for files? Is it possible to specify multiple files on the command line? How do you install the emacs yang mode? My installation complains it is missing cc-fonts? Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 04:59:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEM6S-0006mt-Q5; Mon, 14 Jan 2008 04:59:36 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEM6R-0006ml-GO for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 04:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEM6R-0006md-6p for yang@ietf.org; Mon, 14 Jan 2008 04:59:35 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEM6Q-0007uW-Ni for yang@ietf.org; Mon, 14 Jan 2008 04:59:35 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 70BF81B80C4; Mon, 14 Jan 2008 10:59:33 +0100 (CET) Date: Mon, 14 Jan 2008 11:00:35 +0100 (CET) Message-Id: <20080114.110035.160475113.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <478B2B0F.9030101@ericsson.com> References: <478B2B0F.9030101@ericsson.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: yang@ietf.org Subject: [YANG] Re: tools info request X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel wrote: > Hello Martin, > What is the search path of pyang? If you don't use the -p option, > where does it search for files? Current directory only. > Is it possible to specify multiple files on the command line? Yes. I added a man page for pyang, see http://www.yang-central.org/twiki/pub/Main/YangTools. > How do you install the emacs yang mode? My installation complains it > is missing cc-fonts? Note that yang-mode.el requires cc-mode 5.30 or later. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 06:31:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENXm-0006Ar-D7; Mon, 14 Jan 2008 06:31:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JENXl-0006Al-DL for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 06:31:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENXl-0006Ad-1m for yang@ietf.org; Mon, 14 Jan 2008 06:31:53 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JENXi-0001IJ-Pu for yang@ietf.org; Mon, 14 Jan 2008 06:31:53 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 7E66E1B80EF; Mon, 14 Jan 2008 12:31:49 +0100 (CET) Date: Mon, 14 Jan 2008 12:32:51 +0100 (CET) Message-Id: <20080114.123251.147112585.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] 7.6, default value for a type From: Martin Bjorklund In-Reply-To: <478A9EB5.9060800@andybierman.com> References: <47880961.1030506@andybierman.com> <20080113.223852.227441890.mbj@tail-f.com> <478A9EB5.9060800@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> Sec 7.6, para 5 says: > >> > >> 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. > >> > >> The default value for each builtin type is not defined anywhere. > > > > This is supposed to be a feature, not a bug. If every type has a > > default, you will never be able to define optional leafs. > > > > > The text is misleading. > The builtin types do not have default values(good!) > The order to check the default-stmt is 1) leaf 2) typedef Ok, so it seems we all agree. How is the text misleading? Should it say: then the leaf's default value is set to the type's default value, if one exists. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 06:45:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENki-0001me-V3; Mon, 14 Jan 2008 06:45:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JENkh-0001Zc-Kd for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 06:45:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENkh-0001Tc-5t for yang@ietf.org; Mon, 14 Jan 2008 06:45:15 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JENkg-0006zQ-P2 for yang@ietf.org; Mon, 14 Jan 2008 06:45:15 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 9F6D71B80EF; Mon, 14 Jan 2008 12:45:13 +0100 (CET) Date: Mon, 14 Jan 2008 12:46:16 +0100 (CET) Message-Id: <20080114.124616.64479129.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] 7.6, default value for a type From: Martin Bjorklund In-Reply-To: <20080114.123251.147112585.mbj@tail-f.com> References: <20080113.223852.227441890.mbj@tail-f.com> <478A9EB5.9060800@andybierman.com> <20080114.123251.147112585.mbj@tail-f.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: > > Martin Bjorklund wrote: > > > Andy Bierman wrote: > > >> Hi, > > >> > > >> Sec 7.6, para 5 says: > > >> > > >> 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. > > >> > > >> The default value for each builtin type is not defined anywhere. > > > > > > This is supposed to be a feature, not a bug. If every type has a > > > default, you will never be able to define optional leafs. > > > > > > > > > The text is misleading. > > The builtin types do not have default values(good!) > > The order to check the default-stmt is 1) leaf 2) typedef > > Ok, so it seems we all agree. How is the text misleading? Should it > say: > > then the > leaf's default value is set to the type's default value, if one > exists. I realized that this case was already covered by the current text. Sorry for the noise. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 07:31:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOTe-0005L1-Tw; Mon, 14 Jan 2008 07:31:42 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEOTd-0005Ku-7M for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 07:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOTc-0005Km-Ti for yang@ietf.org; Mon, 14 Jan 2008 07:31:40 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEOTb-0002Ik-E9 for yang@ietf.org; Mon, 14 Jan 2008 07:31:40 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5ED8B20D53; Mon, 14 Jan 2008 13:31:15 +0100 (CET) X-AuditID: c1b4fb3c-b0f99bb0000030cf-35-478b561303af Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 38B3020D0D; Mon, 14 Jan 2008 13:31:15 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 13:31:08 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 13:31:08 +0100 Message-ID: <478B560C.5030105@ericsson.com> Date: Mon, 14 Jan 2008 13:31:08 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2008 12:31:08.0701 (UTC) FILETIME=[56DF84D0:01C856A9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [YANG] yin-element missing from pyang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello Martin, Why is the yin-element statement necessary? IMHO it should be up to the application/compiler how it handles extensions. On the other hand I see no reason not to translate extensions to YIN. It would kill our statement that YANG and YIN are functionally equivalent. By the way pyang doesn't accept yin-element just now. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 08:50:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPiA-0007Dd-Uz; Mon, 14 Jan 2008 08:50:47 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEPi9-0007C3-7S for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 08:50:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPi8-0007Br-Sg for yang@ietf.org; Mon, 14 Jan 2008 08:50:44 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEPi8-0001P7-AC for yang@ietf.org; Mon, 14 Jan 2008 08:50:44 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 14 Jan 2008 05:50:27 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 05:41:05 -0800 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 m0EDf5986365; Mon, 14 Jan 2008 05:41:05 -0800 (PST) (envelope-from phil@idle.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 m0EDetAJ056414; Mon, 14 Jan 2008 13:41:00 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801141341.m0EDetAJ056414@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] insert and key attributes In-reply-to: <478AFA5A.5040505@andybierman.com> Date: Mon, 14 Jan 2008 08:40:55 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Jan 2008 13:41:05.0737 (UTC) FILETIME=[1C806390:01C856B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >Conformance to RFC 4741 does not require any additional >attributes for . Nor does it prevent the use of additional attributes. >If the same operation >without the YANG attributes does not produce the same result, >like the 'move barney' example, then the agent is not RFC 4741 >compliant. Operations on NETCONF data models are defined by the data model. The data model is the contract between the agent and the manager, and if neither party understands this contract, operations are not possible. NETCONF doesn't define a generic data model that all parties must implement or understand. There is no requirement that I support the xc:operation attribute on every (or any) node in my data model. NETCONF gives lots of freedom to the data modelers. This is by design. If my data model defines additional operations, attributes, or elements, this doesn't invalidate any claim of RFC 4741 conformance. YANG is a means of defining data models which follow a particular set of rules. One of these rules is this move operation. In order to implement a YANG-based data model, an agent will need to support this operation. But this will not make that agent non-compliant with 4741. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 10:20:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JER6f-0002oB-Ab; Mon, 14 Jan 2008 10:20:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JER6e-0002o5-Ji for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 10:20:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JER6e-0002nx-7C for yang@ietf.org; Mon, 14 Jan 2008 10:20:08 -0500 Received: from smtp102.sbc.mail.mud.yahoo.com ([68.142.198.201]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JER6d-00045C-Pv for yang@ietf.org; Mon, 14 Jan 2008 10:20:08 -0500 Received: (qmail 51305 invoked from network); 14 Jan 2008 15:20:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 14 Jan 2008 15:20:06 -0000 X-YMail-OSG: edTQ1TEVM1nJX.ywPGBCpbPOk0OcgGmvsA.65qtsMNg7.Ans Message-ID: <478B7E1F.4040201@andybierman.com> Date: Mon, 14 Jan 2008 07:22:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] insert and key attributes References: <200801141341.m0EDetAJ056414@idle.juniper.net> In-Reply-To: <200801141341.m0EDetAJ056414@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Conformance to RFC 4741 does not require any additional >> attributes for . > > Nor does it prevent the use of additional attributes. > >> If the same operation >> without the YANG attributes does not produce the same result, >> like the 'move barney' example, then the agent is not RFC 4741 >> compliant. > > Operations on NETCONF data models are defined by the data model. > The data model is the contract between the agent and the manager, > and if neither party understands this contract, operations are not > possible. NETCONF doesn't define a generic data model that all > parties must implement or understand. > > There is no requirement that I support the xc:operation attribute > on every (or any) node in my data model. NETCONF gives lots of > freedom to the data modelers. This is by design. > > If my data model defines additional operations, attributes, or > elements, this doesn't invalidate any claim of RFC 4741 conformance. > > YANG is a means of defining data models which follow a particular > set of rules. One of these rules is this move operation. In order > to implement a YANG-based data model, an agent will need to support > this operation. But this will not make that agent non-compliant > with 4741. > This is your interpretation of RFC 4741. I think a WG should decide matters of standards conformance. I agree with Balazs that changes to protocol behavior belong in a different document, and should not be part of the data modeling language. I do not think it promotes multi-vendor interoperability to have each vendor come up with their own attribute extensions to NETCONF . The goal of the IETF should be to converge on a standard operation, not simply codify proprietary CLI with angle brackets. > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 12:11:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESqR-0007d8-J8; Mon, 14 Jan 2008 12:11:31 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JESqP-0007d1-Pe for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 12:11:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESqP-0007ct-Fm for yang@ietf.org; Mon, 14 Jan 2008 12:11:29 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JESqO-00088O-VX for yang@ietf.org; Mon, 14 Jan 2008 12:11:29 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 14 Jan 2008 09:10:34 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 09:10:34 -0800 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 m0EHAY958841; Mon, 14 Jan 2008 09:10:34 -0800 (PST) (envelope-from phil@idle.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 m0EHATX9058087; Mon, 14 Jan 2008 17:10:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801141710.m0EHATX9058087@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] insert and key attributes In-reply-to: <478B7E1F.4040201@andybierman.com> Date: Mon, 14 Jan 2008 12:10:28 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Jan 2008 17:10:34.0740 (UTC) FILETIME=[60360B40:01C856D0] X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >This is your interpretation of RFC 4741. Yup, and it's my memory of the WG's repetition of "that's up to the data modeler". >The goal of the IETF should be to >converge on a standard operation, not simply >codify proprietary CLI with angle brackets. RFC 4741 did neither of these extremes. We said explicitly: 5.2. Data Modeling Data modeling and content issues are outside the scope of the NETCONF protocol. An assumption is made that the device's data model is well-known to the application and that both parties are aware of issues such as the layout, containment, keying, lookup, replacement, and management of the data, as well as any other constraints imposed by the data model. NETCONF carries configuration data inside the element that is specific to device's data model. The protocol treats the contents of that element as opaque data. The device uses capabilities to announce the set of data models that the device implements. The capability definition details the operation and constraints imposed by data model. NETCONF gives all power to the data model. It's an open spec that allows expandability and evolution. The goal of the IETF is to deploy standards that people actually use, and past NM efforts that have taken this fascist content model have failed due to lack of flexibility and expressiveness. NETCONF works hard not to repeat those mistakes. The operations in 4741 were not meant to be an exhaustive list that limits what the DM can do, but to give a normal way to do the few things that the WG could agree on. There are many operations that can only be defined once the data model is known. YANG defines how keys are encoded, making it possible to do use "insert" to reorder lists. Without lists, keys, and the semantics behind them, you can't define that operation in any meaningful manner. (Yes, you can to the "here's a blob to tell you what to move" and "here's a blob to tell you where to move it", but even these need the data model to tell you what you can move and where you can move it). Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 12:31:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JET9h-0001fx-JM; Mon, 14 Jan 2008 12:31:25 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JET9g-0001ff-09 for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 12:31:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JET9f-0001fX-LP for yang@ietf.org; Mon, 14 Jan 2008 12:31:23 -0500 Received: from smtp102.sbc.mail.mud.yahoo.com ([68.142.198.201]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JET9f-0007iK-6B for yang@ietf.org; Mon, 14 Jan 2008 12:31:23 -0500 Received: (qmail 86777 invoked from network); 14 Jan 2008 17:31:22 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 14 Jan 2008 17:31:21 -0000 X-YMail-OSG: lR8kfVoVM1mqx9MO4bKrfi_8GGv1goaCMBUDO1Im5y4GBhE3 Message-ID: <478B9CE3.3010903@andybierman.com> Date: Mon, 14 Jan 2008 09:33:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] insert and key attributes References: <200801141710.m0EHATX9058087@idle.juniper.net> In-Reply-To: <200801141710.m0EHATX9058087@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> This is your interpretation of RFC 4741. > I think you are misunderstanding my concern. Extending the set of standard edit-config operations is fine. The document(s) specifying any new standard protocol operations should be independent of the data modeling language. This is done simply by specifying the XML content (e.g., operation attribute) instead of a particular DML representation of the XML. The NETCONF WG should agree on this sort of new NETCONF protocol feature, the same as any other. Andy > Yup, and it's my memory of the WG's repetition of "that's up > to the data modeler". > >> The goal of the IETF should be to >> converge on a standard operation, not simply >> codify proprietary CLI with angle brackets. > > RFC 4741 did neither of these extremes. We said explicitly: > > 5.2. Data Modeling > > Data modeling and content issues are outside the scope of the NETCONF > protocol. An assumption is made that the device's data model is > well-known to the application and that both parties are aware of > issues such as the layout, containment, keying, lookup, replacement, > and management of the data, as well as any other constraints imposed > by the data model. > > NETCONF carries configuration data inside the element that > is specific to device's data model. The protocol treats the contents > of that element as opaque data. The device uses capabilities to > announce the set of data models that the device implements. The > capability definition details the operation and constraints imposed > by data model. > > NETCONF gives all power to the data model. It's an open spec that > allows expandability and evolution. The goal of the IETF is to > deploy standards that people actually use, and past NM efforts that > have taken this fascist content model have failed due to lack of > flexibility and expressiveness. NETCONF works hard not to repeat > those mistakes. > > The operations in 4741 were not meant to be an exhaustive list that > limits what the DM can do, but to give a normal way to do the few > things that the WG could agree on. There are many operations that > can only be defined once the data model is known. YANG defines how > keys are encoded, making it possible to do use "insert" to reorder > lists. Without lists, keys, and the semantics behind them, you > can't define that operation in any meaningful manner. (Yes, you can > to the "here's a blob to tell you what to move" and "here's a blob > to tell you where to move it", but even these need the data model > to tell you what you can move and where you can move it). > > Thanks, > Phil > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 12:59:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JETbG-0000M8-W7; Mon, 14 Jan 2008 12:59:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JETbG-0000M3-J2 for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 12:59:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JETbG-0000Lv-8o for yang@ietf.org; Mon, 14 Jan 2008 12:59:54 -0500 Received: from smtp116.sbc.mail.sp1.yahoo.com ([69.147.64.89]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JETbF-0000T4-QV for yang@ietf.org; Mon, 14 Jan 2008 12:59:54 -0500 Received: (qmail 55320 invoked from network); 14 Jan 2008 17:59:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 14 Jan 2008 17:59:52 -0000 X-YMail-OSG: UJO9TdwVM1mxBQbPRrgcHpNajGtEuD_upTdQqsInulJnesmW Message-ID: <478BA392.5080204@andybierman.com> Date: Mon, 14 Jan 2008 10:01:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [YANG] more clarifications on unique-stmt X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Sec. 7.8.3 is not entirely clear wrt/ nested objects. It should be stated that the descendant-schema-nodeid sequence includes choice and case names, even though these nodes are not in the config, and are not used in Xpath expressions which refer to a config. This applies to augment as well. // problem 1: choices list a { unique "B/X/xx B/Y/yy"; choice B { mandatory true; case X { leaf xx {type int32; } } case Y { leaf yy {type string; } } } } Is this just a garbage-in/garbage-out scenario? Obviously, only xx or yy will be present, but never both. // problem 2: nested lists list c { config false; unique "d/b e"; list d { key a; leaf a { type string; } leaf b { type instance-identifier; } } leaf e { type uint8; } } This is legal? It means (within list c) every tuple of [d/b[a], e] must be unique, if 'e' exists, and all instances of 'c/d/b' do not have to be unique at all if E is not present? But within list d, b is not required to be unique at all, so this seems conflicting. IMO, deep keys, deep unique targets, deep augment targets, are all part of the same problem space, and one clean solution is needed for all of them. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 13:35:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEU9m-0005iO-IY; Mon, 14 Jan 2008 13:35:34 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEU9m-0005hK-0Z for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 13:35:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEU9l-0005hC-Mu for yang@ietf.org; Mon, 14 Jan 2008 13:35:33 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEU9h-00028A-MC for yang@ietf.org; Mon, 14 Jan 2008 13:35:33 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 14 Jan 2008 10:35:24 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 10:35:24 -0800 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 m0EIZN983295; Mon, 14 Jan 2008 10:35:23 -0800 (PST) (envelope-from phil@idle.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 m0EIZDWC058883; Mon, 14 Jan 2008 18:35:18 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801141835.m0EIZDWC058883@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] insert and key attributes In-reply-to: <478B9CE3.3010903@andybierman.com> Date: Mon, 14 Jan 2008 13:35:13 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Jan 2008 18:35:24.0118 (UTC) FILETIME=[39B77F60:01C856DC] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >The NETCONF WG should agree on this sort of new NETCONF protocol feature, >the same as any other. The feature relies on the data modeling rules of YANG. It will be a standard part of YANG-based models, but not a standard part of NETCONF. Other data modeling languages are free to define their own ordering schemes, which need not be compatible with what we have in YANG. The dependency would mean that spliting it into another document is just adding world. Leave it in the YANG draft. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 14 14:15:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEUmA-0004jp-LG; Mon, 14 Jan 2008 14:15:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEUmA-0004jk-1C for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 14:15:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEUm9-0004jc-NT for yang@ietf.org; Mon, 14 Jan 2008 14:15:13 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JEUm9-0002pg-8V for yang@ietf.org; Mon, 14 Jan 2008 14:15:13 -0500 Received: (qmail 94974 invoked from network); 14 Jan 2008 19:15:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 14 Jan 2008 19:15:12 -0000 X-YMail-OSG: XI9K_kUVM1kulh_.IgvA8p47Eodimub3.EgJZag0JFiEke2C Message-ID: <478BB4BA.70303@andybierman.com> Date: Mon, 14 Jan 2008 11:15:06 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] insert and key attributes References: <200801141835.m0EIZDWC058883@idle.juniper.net> In-Reply-To: <200801141835.m0EIZDWC058883@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The NETCONF WG should agree on this sort of new NETCONF protocol feature, >> the same as any other. > > The feature relies on the data modeling rules of YANG. It will be > a standard part of YANG-based models, but not a standard part of > NETCONF. Other data modeling languages are free to define their > own ordering schemes, which need not be compatible with what we > have in YANG. The dependency would mean that spliting it into > another document is just adding world. Leave it in the YANG draft. > I disagree that this is a good design approach for a standard protocol. There is nothing YANG-specific about user-ordered lists or the concept of inserting this entry before/after that one. If the WG agrees to add this sort of standard operation to the protocol, then DMLs like YANG can take advantage of it (ala error-app-tag). IMO, the NETCONF protocol should define a standard set of features that does not change depending on the DML used to define NETCONF content. > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 15 04:56:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEiXJ-0007gT-Vn; Tue, 15 Jan 2008 04:56:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEiXI-0007g9-TP for yang-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 04:56:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEiXB-0007fp-Oz; Tue, 15 Jan 2008 04:56:41 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEiXA-00069u-1M; Tue, 15 Jan 2008 04:56:41 -0500 X-IronPort-AV: E=Sophos;i="4.24,286,1196658000"; d="scan'208,217";a="92280703" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 15 Jan 2008 04:56:38 -0500 X-IronPort-AV: E=Sophos;i="4.24,286,1196658000"; d="scan'208,217";a="150062779" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jan 2008 04:56:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jan 2008 10:56:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Invitation: Joint XML Guidelines Discussion Thread-Index: AchXXOe8htGFo+fPR+ORIszbvgxaAg== From: "Romascanu, Dan (Dan)" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: Subject: [YANG] FW: Invitation: Joint XML Guidelines Discussion X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0280502188==" Errors-To: yang-bounces@ietf.org This is a multi-part message in MIME format. --===============0280502188== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8575C.E83DBC6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8575C.E83DBC6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This came to our attention through the ITU-T NGN Management Focus Group which I and Bert Wijnen are participating in.=20 =20 I believe it would be interesting to have somebody from the APPS area, maybe also from the XML Directorate and YANG team attending. If folks are interested please let me know, as there is still an open discussion about the date (either 2/4 or 2/5).=20 =20 Regards, =20 Dan =20 =20 =20 =20 ________________________________ From: Davis, Nigel (HAL02:QT10) [mailto:NIGELD@nortel.com]=20 Sent: Friday, January 11, 2008 2:13 PM To: Sidor, Dave (NC1:1A00); *Mak, Leen; *Toche, Christian; Divialle, Marie (CTF:ZZ00); *Johannessen, Knut; *Fujii, Nobuo; *Kurakova, Tatiana; *Burkett, Debbie; *Caruso, Francesco; *Garbanati, Linda; Frode Nergard; *Geipl, Michael; *Ronco, Enrico; *Caryer, Geoff; *Zoicas, Adrian; *Huang, Shuqiang; *Wang, Zhili; Amit Kleinmann; Magnet, Jerome (CAR:QT32) Subject: Invitation: Joint XML Guidelines Discussion Hi all,=20 Apologies for my delay in setting up this meeting (I fear this year has started as it means to go on!).=20 Firstly, Dave Sidor, I would be grateful if you could ensure that this gets sent to the appropriate distribution(s) to enable the NGNMFG community to participate in this activity appropriately, I have only sent this to those who were at the meeting that triggered the discussion and other parties who have expressed specific interest. Introduction=20 As discussed and agreed at the "Joint Conference Call on Methodology between ITU-T SG4, 3GPP SA5, TISPAN WG8, TMF mTOP and ATIS TMOC" held 2007-12-12, I am calling a meeting to discuss "XML guidelines" and to potentially initiate combined work (study etc) in the area of generation and refinement of XML guidelines and definitions for application to management system interfaces. Important Note=20 The meeting was originally planned for Tuesday 5th February and I am considering keeping to that date, however at this point I will have some difficulty holding the meeting on 5th February and would prefer to hold the meeting on Monday 4th February (at the same times as originally planned). If anyone who feels that they wish to attend can not attend on Monday 4th Feb I will maintain the original plan of 5th February. I would request that all interested parties please currently keep dates/times available and respond to me by end of day 18th January (by reply to this mail) with respect to your availability on 4th February. If anyone objects to 4th Feb I will stay with 5th Feb otherwise I will hold the meeting on 4th Feb. I would be grateful if all interested parties could respond so I can get an idea of numbers and representation etc. Agenda=20 * Introductions=20 * IPR declaration=20 * Brief overview of purpose=20 * Some initial considerations=20 * Next steps=20 * AOB=20 =09 Meeting Logistics=20 * Date:=20 * Either Monday 4th February or Tuesday 5th February (as discussed above)=20 * Time:=20 * 13:00 GMT - 15:00 GMT=20 * Local time conversion: http://www.timeanddate.com/worldclock/fixedtime.html?day=3D4&month=3D2&ye= ar=3D 2008&hour=3D13&min=3D0&sec=3D0&p1=3D0 =20 * Phone Access Details:=20 * Number:=20 * +1-972-684-5262 (US)=20 * +44-162-843-5262 (UK)=20 * +33-16-955-2262 (France)=20 * +49-696-697-1262 (Germany)=20 * +39-065-152-9162 (Italy)=20 * +34-91-709-4762 (Spain)=20 * +61-2-6279-7721 (Australia (Canberra))=20 * 6-427-5262 (Nortel)=20 * Access code: 59781#=20 * Webmeeting Access Details=20 * https://www.gotomeeting.com/join/146470527 =20 * Meeting ID: 146-470-527=20 =09 I may need to change the Webmeeting access but will inform you by mail before the meeting.=20 If you have any comments on the above please do not hesitate to contact me by return of mail or by phone (as below).=20 Thanks=20 Nigel Davis=20 Nortel=20 Desk/ip/vm : +44-1279-403978 (ESN 742-3978) Mobile/vm : +44-7740-670288 (ESN 748-0288) Fax : +44-1279-405904 (ESN 742-5904)=20 London Road Harlow, Essex CM17 9NA United Kingdom=20 Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. ------_=_NextPart_001_01C8575C.E83DBC6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Invitation: Joint XML Guidelines Discussion
This came to our attention through the = ITU-T NGN=20 Management Focus Group which I and Bert Wijnen are participating in.=20
 
I believe it would be interesting to have = somebody from=20 the APPS area, maybe also from the XML Directorate and YANG team = attending. If=20 folks are interested please let me know, as there is still an open = discussion=20 about the date (either 2/4 or 2/5).
 
Regards,
 
Dan
 
 
 
 

From: Davis, Nigel (HAL02:QT10)=20 [mailto:NIGELD@nortel.com]
Sent: Friday, January 11, 2008 = 2:13=20 PM
To: Sidor, Dave (NC1:1A00); *Mak, Leen; *Toche, Christian;=20 Divialle, Marie (CTF:ZZ00); *Johannessen, Knut; *Fujii, Nobuo; = *Kurakova,=20 Tatiana; *Burkett, Debbie; *Caruso, Francesco; *Garbanati, Linda; Frode = Nergard;=20 *Geipl, Michael; *Ronco, Enrico; *Caryer, Geoff; *Zoicas, Adrian; = *Huang,=20 Shuqiang; *Wang, Zhili; Amit Kleinmann; Magnet, Jerome=20 (CAR:QT32)
Subject: Invitation: Joint XML Guidelines=20 Discussion

Hi all, =

Apologies for my delay = in setting up=20 this meeting (I fear this year has started as it means to go on!).=20

Firstly, Dave Sidor, I = would be=20 grateful if you could ensure that this gets sent to the appropriate=20 distribution(s) to enable the NGNMFG community to participate in this = activity=20 appropriately, I have only sent this to those who were at the meeting = that=20 triggered the discussion and other parties who have expressed specific=20 interest.

Introduction=20
As discussed and = agreed at the=20 "Joint Conference Call on Methodology between ITU-T SG4, 3GPP SA5, = TISPAN WG8,=20 TMF mTOP and ATIS TMOC" held 2007-12-12,  I am calling a meeting to = discuss=20 "XML guidelines" and to potentially initiate combined work (study etc) = in the=20 area of generation and refinement of XML guidelines and definitions for=20 application to management system interfaces.

Important=20 Note
The meeting=20 was originally planned for Tuesday 5th February and I am considering = keeping to=20 that date, however at this point I will have some difficulty holding the = meeting=20 on 5th February and would prefer to hold the meeting on Monday 4th = February (at=20 the same times as originally planned). If anyone who feels that they = wish to=20 attend can not attend on Monday 4th Feb I will maintain the original = plan of 5th=20 February. I would request that all interested parties please currently = keep=20 dates/times available and respond to me by end of day 18th January (by = reply to=20 this mail) with respect to your availability on 4th February. If anyone = objects=20 to 4th Feb I will stay with 5th Feb otherwise I will hold the meeting on = 4th=20 Feb. I would be grateful if all interested parties could respond so I = can get an=20 idea of numbers and representation etc.

Agenda=20

  • Introductions=20
  • IPR = declaration=20
  • Brief overview of=20 purpose=20
  • Some initial=20 considerations=20
  • Next = steps=20
  • AOB =

Meeting=20 Logistics=20

  • Date: =
    • Either Monday 4th = February or=20 Tuesday 5th February (as discussed above)
  • Time: =
    • 13:00 GMT - 15:00 = GMT=20
    • Local time = conversion:=20 http://www.timeanddate.com/worldclock/fixedtime.html?day=3D4&= ;month=3D2&year=3D2008&hour=3D13&min=3D0&sec=3D0&p1=3D= 0
  • Phone Access=20 Details:=20
    • Number: =
      • +1-972-684-5262 = (US)=20
      • +44-162-843-5262=20 (UK)=20
      • +33-16-955-2262 = (France)=20
      • +49-696-697-1262=20 (Germany)=20
      • +39-065-152-9162=20 (Italy)=20
      • +34-91-709-4762 = (Spain)=20
      • +61-2-6279-7721 = (Australia=20 (Canberra))=20
      • 6-427-5262=20 (Nortel)
    • Access code: = 59781#=20
  • Webmeeting Access=20 Details=20
    • https://www.gotomeeting.com/join/146470527=
    • Meeting ID: = 146-470-527=20

I may need to change = the Webmeeting=20 access but will inform you by mail before the meeting. =

If you have any = comments on the=20 above please do not hesitate to contact me by return of mail or by phone = (as=20 below).

Thanks =

Nigel Davis =
Nortel
Desk/ip/vm : +44-1279-403978 = (ESN=20 742-3978)
Mobile/vm   : +44-7740-670288 (ESN = 748-0288)
Fax          &= nbsp;   =20 : +44-1279-405904 (ESN 742-5904)=20
London = Road
Harlow, = Essex
CM17 = 9NA
United = Kingdom
Confidentiality Notice: This message and any attachments may = contain=20 information that is privileged and confidential. If you have reason to = believe=20 that you are not the intended recipient or a person responsible for = delivering=20 this message to an intended recipient, you are hereby notified that any = review,=20 dissemination, distribution, or copying of this message is strictly = prohibited.=20 If you have reason to believe that you are not the intended recipient or = a=20 person responsible for delivering this message to an intended recipient, = please=20 contact the sender immediately by reply email and destroy all copies of = the=20 original message.



------_=_NextPart_001_01C8575C.E83DBC6C-- --===============0280502188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============0280502188==-- From yang-bounces@ietf.org Tue Jan 15 08:47:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEm8v-0005o4-Rs; Tue, 15 Jan 2008 08:47:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JEm8u-0005nh-BT for yang-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 08:47:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEm8t-0005nP-W7; Tue, 15 Jan 2008 08:47:51 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEm8t-0004h8-Ko; Tue, 15 Jan 2008 08:47:51 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Tue, 15 Jan 2008 05:47:09 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jan 2008 05:46:23 -0800 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 m0FDkM965071; Tue, 15 Jan 2008 05:46:22 -0800 (PST) (envelope-from phil@idle.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 m0FDkFK5064146; Tue, 15 Jan 2008 13:46:15 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801151346.m0FDkFK5064146@idle.juniper.net> To: "Romascanu, Dan (Dan)" Subject: Re: [YANG] FW: Invitation: Joint XML Guidelines Discussion In-reply-to: Date: Tue, 15 Jan 2008 08:46:15 -0500 From: Phil Shafer X-OriginalArrivalTime: 15 Jan 2008 13:46:23.0102 (UTC) FILETIME=[041431E0:01C8577D] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: yang@ietf.org, discuss@apps.ietf.org, xml-dir@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "Romascanu, Dan (Dan)" writes: >I believe it would be interesting to have somebody from the APPS area, >maybe also from the XML Directorate and YANG team attending. If folks >are interested please let me know, as there is still an open discussion >about the date (either 2/4 or 2/5). I'll be willing to call in. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 05:23:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5QR-0007Nk-4D; Wed, 16 Jan 2008 05:23:15 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF5QP-0007Nf-MP for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 05:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5QI-0007NR-9u for yang@ietf.org; Wed, 16 Jan 2008 05:23:06 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF5QG-0001r6-P0 for yang@ietf.org; Wed, 16 Jan 2008 05:23:06 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7FDABD800C1 for ; Wed, 16 Jan 2008 11:23:01 +0100 (CET) From: Ladislav Lhotka To: yang Content-Type: text/plain Organization: CESNET Date: Wed, 16 Jan 2008 11:23:01 +0100 Message-Id: <1200478981.7029.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [YANG] how to signal revision? X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, how can the server and client make sure they are both using the same revision of a given data model? Capabilities in NETCONF hello messages use URIs but YANG draft says in sec. 5.4 that different revisions of the same module should have the same namespace. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 05:32:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5Zg-0001nj-Ai; Wed, 16 Jan 2008 05:32:48 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF5Zf-0001nK-Ae for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 05:32:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5Ze-0001kR-Un for yang@ietf.org; Wed, 16 Jan 2008 05:32:46 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF5Ze-00022y-IG for yang@ietf.org; Wed, 16 Jan 2008 05:32:46 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4840620EAB; Wed, 16 Jan 2008 11:31:58 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-63-478ddd1e70b8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2B7F1209DC; Wed, 16 Jan 2008 11:31:58 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 11:31:57 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 11:31:57 +0100 Message-ID: <478DDD1D.2060605@ericsson.com> Date: Wed, 16 Jan 2008 11:31:57 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] how to signal revision? References: <1200478981.7029.27.camel@missotis> In-Reply-To: <1200478981.7029.27.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2008 10:31:57.0893 (UTC) FILETIME=[057C4F50:01C8582B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello Lada, As I understand it, the basic idea is that you have compatible and incompatible changes. Chapter 5.4 speaks about compatible changes. Even for these there could be a subversion indicator somewhere in the module. For incompatible changes, really anything major, the module will have a new name and URI. There is currently an empty chapter "9. Updating a Module" in the current draft that will describe this. Balazs Ladislav Lhotka wrote: > Hi, > > how can the server and client make sure they are both using the same > revision of a given data model? Capabilities in NETCONF hello messages > use URIs but YANG draft says in sec. 5.4 that different revisions of the > same module should have the same namespace. > > Lada > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 05:42:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5jI-0005dC-Tp; Wed, 16 Jan 2008 05:42:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF5jH-0005cr-Tn for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 05:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5jH-0005cj-Ix for yang@ietf.org; Wed, 16 Jan 2008 05:42:43 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF5jH-0002E4-7o for yang@ietf.org; Wed, 16 Jan 2008 05:42:43 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DC145D800C1 for ; Wed, 16 Jan 2008 11:42:42 +0100 (CET) Subject: Re: [YANG] how to signal revision? From: Ladislav Lhotka To: yang In-Reply-To: <478DDD1D.2060605@ericsson.com> References: <1200478981.7029.27.camel@missotis> <478DDD1D.2060605@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 11:42:42 +0100 Message-Id: <1200480162.7029.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel p=C3=AD=C5=A1e v St 16. 01. 2008 v 11:31 +0100: > Hello Lada, > As I understand it, the basic idea is that you have compatible and inco= mpatible changes.=20 > Chapter 5.4 speaks about compatible changes. Even for these there could= be a subversion=20 > indicator somewhere in the module. >=20 > For incompatible changes, really anything major, the module will have a= new name and URI. There=20 > is currently an empty chapter "9. Updating a Module" in the current dr= aft that will describe this. Hmm, what could be the compatible changes, apart from correcting typos in descriptions etc.? I guess even changing a single default value renders the data model incompatible. Lada=20 >=20 > Balazs >=20 > Ladislav Lhotka wrote: > > Hi, > >=20 > > how can the server and client make sure they are both using the same > > revision of a given data model? Capabilities in NETCONF hello message= s > > use URIs but YANG draft says in sec. 5.4 that different revisions of = the > > same module should have the same namespace. > >=20 > > Lada > >=20 >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 06:02:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF62s-0003MU-J7; Wed, 16 Jan 2008 06:02:58 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF62q-0003MF-GX for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:02:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF62q-0003M7-2p for yang@ietf.org; Wed, 16 Jan 2008 06:02:56 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF62p-0006kj-Ne for yang@ietf.org; Wed, 16 Jan 2008 06:02:55 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C508121223; Wed, 16 Jan 2008 12:02:12 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-73-478de434fb8a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8670320EFA; Wed, 16 Jan 2008 12:02:12 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:02:11 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:02:11 +0100 Message-ID: <478DE433.1080605@ericsson.com> Date: Wed, 16 Jan 2008 12:02:11 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] how to signal revision? References: <1200478981.7029.27.camel@missotis> <478DDD1D.2060605@ericsson.com> <1200480162.7029.32.camel@missotis> In-Reply-To: <1200480162.7029.32.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2008 11:02:11.0719 (UTC) FILETIME=[3E9C3170:01C8582F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Hmm, what could be the compatible changes, apart from correcting typos > in descriptions etc.? I guess even changing a single default value > renders the data model incompatible. [BALAZS]: I thought of the following examples - Extending the value range of a leaf - adding a new non-mandatory leaf - changing description in some cases - adding new cases to a choice Balazs _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 06:34:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6Xh-0003Yh-C9; Wed, 16 Jan 2008 06:34:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF6Xe-0003YE-Kr for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6Xe-0003Y3-7j for yang@ietf.org; Wed, 16 Jan 2008 06:34:46 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF6Xc-0003Cq-Gh for yang@ietf.org; Wed, 16 Jan 2008 06:34:46 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 33A781B80C3; Wed, 16 Jan 2008 12:34:43 +0100 (CET) Date: Wed, 16 Jan 2008 12:35:49 +0100 (CET) Message-Id: <20080116.123549.140000433.mbj@tail-f.com> To: lhotka@cesnet.cz Subject: Re: [YANG] how to signal revision? From: Martin Bjorklund In-Reply-To: <1200478981.7029.27.camel@missotis> References: <1200478981.7029.27.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > how can the server and client make sure they are both using the same > revision of a given data model? Capabilities in NETCONF hello messages > use URIs but YANG draft says in sec. 5.4 that different revisions of the > same module should have the same namespace. The idea is that we use the uri query argument to indicate the revision number (see 7.1.3): http://acme.example.com/system?2007-06-09 (I realize that the text should be clarified; probably move the discussion about the capability from 7.1.3 to 5.4). > Hmm, what could be the compatible changes, apart from correcting typos > in descriptions etc.? I guess even changing a single default value > renders the data model incompatible. Yes, changing defaults is incompatible. If you do that, you have to change the namespace. But there are many common compatible changes you can do, the simplest is to add new optional data. Note that the text describing this is not yet written in the draft. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 07:09:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF74l-0005B2-8e; Wed, 16 Jan 2008 07:08:59 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF74k-00054e-0Q for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 07:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF74j-00054W-Iq for yang@ietf.org; Wed, 16 Jan 2008 07:08:57 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF74j-0003v4-8N for yang@ietf.org; Wed, 16 Jan 2008 07:08:57 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id F3F15D80098 for ; Wed, 16 Jan 2008 13:08:56 +0100 (CET) Subject: Re: [YANG] how to signal revision? From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080116.123549.140000433.mbj@tail-f.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 13:08:57 +0100 Message-Id: <1200485337.7029.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Martin, Martin Bjorklund p=C3=AD=C5=A1e v St 16. 01. 2008 v 12:35 +0100: >=20 > The idea is that we use the uri query argument to indicate the > revision number (see 7.1.3): >=20 > http://acme.example.com/system?2007-06-09 This makes sense, but is the query argument allowed also in URNs? >=20 > (I realize that the text should be clarified; probably move the > discussion about the capability from 7.1.3 to 5.4). >=20 > > Hmm, what could be the compatible changes, apart from correcting typo= s > > in descriptions etc.? I guess even changing a single default value > > renders the data model incompatible. >=20 > Yes, changing defaults is incompatible. If you do that, you have to > change the namespace. >=20 > But there are many common compatible changes you can do, the simplest > is to add new optional data. This means that a client that uses a new revision could send data that the server doesn't know about. I don't think it's acceptable. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 07:34:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7T2-0005uQ-CH; Wed, 16 Jan 2008 07:34:04 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF7T0-0005uE-Nj for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 07:34:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7T0-0005u5-Dx for yang@ietf.org; Wed, 16 Jan 2008 07:34:02 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF7Sz-0004PA-0a for yang@ietf.org; Wed, 16 Jan 2008 07:34:02 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 54E7D208B1; Wed, 16 Jan 2008 13:33:58 +0100 (CET) X-AuditID: c1b4fb3c-ae794bb0000030cf-21-478df9b6ba1c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 32C16205F9; Wed, 16 Jan 2008 13:33:58 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 13:33:57 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 13:33:57 +0100 Message-ID: <478DF9B5.40006@ericsson.com> Date: Wed, 16 Jan 2008 13:33:57 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] how to signal revision? References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200485337.7029.43.camel@missotis> In-Reply-To: <1200485337.7029.43.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2008 12:33:57.0614 (UTC) FILETIME=[106118E0:01C8583C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org We should first define, what we mean with compatible. My definition is that a management system that knows only the old version can handle the node i.e. anything it writes into the node will work as in the previous version. An old management client will not send the new data. Balazs Ladislav Lhotka wrote: >> >>> Hmm, what could be the compatible changes, apart from correcting typos >>> in descriptions etc.? I guess even changing a single default value >>> renders the data model incompatible. >> Yes, changing defaults is incompatible. If you do that, you have to >> change the namespace. >> >> But there are many common compatible changes you can do, the simplest >> is to add new optional data. > > This means that a client that uses a new revision could send data that > the server doesn't know about. I don't think it's acceptable. > > Lada > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 07:35:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7U8-0001CH-TS; Wed, 16 Jan 2008 07:35:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF7U7-0001CC-3q for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 07:35:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7U6-0001C4-Po for yang@ietf.org; Wed, 16 Jan 2008 07:35:10 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF7U6-0000hU-DT for yang@ietf.org; Wed, 16 Jan 2008 07:35:10 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id C9E3D1B80C3; Wed, 16 Jan 2008 13:35:08 +0100 (CET) Date: Wed, 16 Jan 2008 13:36:15 +0100 (CET) Message-Id: <20080116.133615.104403392.mbj@tail-f.com> To: lhotka@cesnet.cz Subject: Re: [YANG] how to signal revision? From: Martin Bjorklund In-Reply-To: <1200485337.7029.43.camel@missotis> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200485337.7029.43.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1818684764==" Errors-To: yang-bounces@ietf.org --===============1818684764== Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSGkgTWFydGluLA0K PiANCj4gTWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxNi4gMDEuIDIwMDggdiAxMjozNSAr MDEwMDoNCj4gPiANCj4gPiBUaGUgaWRlYSBpcyB0aGF0IHdlIHVzZSB0aGUgdXJpIHF1ZXJ5IGFy Z3VtZW50IHRvIGluZGljYXRlIHRoZQ0KPiA+IHJldmlzaW9uIG51bWJlciAoc2VlIDcuMS4zKToN Cj4gPiANCj4gPiAgICA8Y2FwYWJpbGl0eT5odHRwOi8vYWNtZS5leGFtcGxlLmNvbS9zeXN0ZW0/ MjAwNy0wNi0wOTwvY2FwYWJpbGl0eT4NCj4gDQo+IFRoaXMgbWFrZXMgc2Vuc2UsIGJ1dCBpcyB0 aGUgcXVlcnkgYXJndW1lbnQgYWxsb3dlZCBhbHNvIGluIFVSTnM/DQoNClllcy4gIFdlIGFsc28g dXNlIHRoZW0gaW4gcmZjNDc0MToNCg0KICAgICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2Fw YWJpbGl0eTp1cmw6MS4wP3NjaGVtZT1odHRwLGZ0cCxmaWxlDQoNCj4gPiBCdXQgdGhlcmUgYXJl IG1hbnkgY29tbW9uIGNvbXBhdGlibGUgY2hhbmdlcyB5b3UgY2FuIGRvLCB0aGUgc2ltcGxlc3QN Cj4gPiBpcyB0byBhZGQgbmV3IG9wdGlvbmFsIGRhdGEuDQo+IA0KPiBUaGlzIG1lYW5zIHRoYXQg YSBjbGllbnQgdGhhdCB1c2VzIGEgbmV3IHJldmlzaW9uIGNvdWxkIHNlbmQgZGF0YSB0aGF0DQo+ IHRoZSBzZXJ2ZXIgZG9lc24ndCBrbm93IGFib3V0LiBJIGRvbid0IHRoaW5rIGl0J3MgYWNjZXB0 YWJsZS4NCg0KTm8sIHRoZSBjbGllbnQgaGFzIHRvIHVuZGVyc3RhbmQgdGhhdCBpdCBjYW5ub3Qg c2VuZCBkYXRhIHRoYXQgdGhlDQpzZXJ2ZXIgZG9lc24ndCBzdXBwb3J0LiAgV2Ugd2FudCB0byBh Y2hpdmUgdHdvIHRoaW5ncyBlc3NlbnRpYWxseSAtDQp0aGF0IHRoZSBzZXJ2ZXIgYWNjZXB0cyAi YW4gb2xkIGJhY2t1cCIgKGNvcHktY29uZmlnKSwgYW5kIHRoYXQgdGhlDQpzZXJ2ZXIgY2FuIHNl bmQgYWxsIGRhdGEgaXMgaGFzLCBhbmQgbGV0IHRoZSBjbGllbnQgd29ycnkgYWJvdXQNCmZpbHRl cmluZyBvdXQgdGhlIHN0dWZmIGl0IGRvZXNuJ3QgdW5kZXJzdGFuZC4NCg0KDQovbWFydGluDQo= --===============1818684764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1818684764==-- From yang-bounces@ietf.org Wed Jan 16 07:39:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7Y4-00072b-Bc; Wed, 16 Jan 2008 07:39:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF7Y3-00072R-2S for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 07:39:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7Y2-00072J-OS for yang@ietf.org; Wed, 16 Jan 2008 07:39:14 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF7Y2-0000nd-C6 for yang@ietf.org; Wed, 16 Jan 2008 07:39:14 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1D5FFD800C8 for ; Wed, 16 Jan 2008 13:39:13 +0100 (CET) From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080116.123549.140000433.mbj@tail-f.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> Content-Type: text/plain Organization: CESNET Date: Wed, 16 Jan 2008 13:39:13 +0100 Message-Id: <1200487153.7029.71.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [YANG] default values X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org > Yes, changing defaults is incompatible. If you do that, you have to > change the namespace. BTW, that's exactly why I am against the default values in typedef: they make the data model too specialised. The defaults could be easily handled as follows: 1. The standard that defines the type specifies in plain RFC-English that the default value MUST, SHOULD or MAY be something. 2. An implementor reflects this in a device, but is also required to fill the default (or another) value in the initial startup configuration. 3. The client needn't care about what the default is, it just queries the device to see the actual value, changes it if necessary etc. This approach would make the same data model reusable with other default value and, in addition, allow for honouring the semantics of MUST, SHOULD and MAY. The default in typedefs is only usable in the MUST case. So my suggestion is to remove the default statement form YANG. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 08:05:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7xD-00012V-0N; Wed, 16 Jan 2008 08:05:15 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF7xC-00012Q-2p for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:05:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7xB-00012I-Os for yang@ietf.org; Wed, 16 Jan 2008 08:05:13 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF7xB-0001RU-CY for yang@ietf.org; Wed, 16 Jan 2008 08:05:13 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2FEBED800C1 for ; Wed, 16 Jan 2008 14:05:13 +0100 (CET) Subject: Re: [YANG] how to signal revision? From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080116.133615.104403392.mbj@tail-f.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200485337.7029.43.camel@missotis> <20080116.133615.104403392.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 14:05:13 +0100 Message-Id: <1200488713.7029.87.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund p=C3=AD=C5=A1e v St 16. 01. 2008 v 13:36 +0100: > > > But there are many common compatible changes you can do, the simple= st > > > is to add new optional data. > >=20 > > This means that a client that uses a new revision could send data tha= t > > the server doesn't know about. I don't think it's acceptable. >=20 > No, the client has to understand that it cannot send data that the > server doesn't support. We want to achive two things essentially - In other words, the client has to understand that the schema it uses is not compatible with the one used by the server. Would it be a problem to require that e.g., with every change in the data model proper the major revision number must be increased and also the namespace URI changed? The minor revision number then could be used for indicating cosmetic changes in the YANG document not affecting the data model. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 08:18:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF89Y-0001eV-6U; Wed, 16 Jan 2008 08:18:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF89W-0001eQ-MQ for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:17:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF89W-0001eI-C7 for yang@ietf.org; Wed, 16 Jan 2008 08:17:58 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF89W-0001k0-0z for yang@ietf.org; Wed, 16 Jan 2008 08:17:58 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6E37FD800C1 for ; Wed, 16 Jan 2008 14:17:57 +0100 (CET) Subject: Re: [YANG] how to signal revision? From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <478DF9B5.40006@ericsson.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200485337.7029.43.camel@missotis> <478DF9B5.40006@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 14:17:57 +0100 Message-Id: <1200489477.7029.92.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel p=C3=AD=C5=A1e v St 16. 01. 2008 v 13:33 +0100: > We should first define, what we mean with compatible. My definition is = that a management system=20 > that knows only the old version can handle the node i.e. anything it wr= ites into the node will=20 > work as in the previous version. An old management client will not send= the new data. OK, so by compatibility you essentialy mean "compatible from server's viewpoint". Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 08:34:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8PJ-00009e-08; Wed, 16 Jan 2008 08:34:17 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF8PI-00009T-0o for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8PH-00009K-NP for yang@ietf.org; Wed, 16 Jan 2008 08:34:15 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF8PH-0005Wh-Ae for yang@ietf.org; Wed, 16 Jan 2008 08:34:15 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A29922139F; Wed, 16 Jan 2008 14:34:14 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-8b-478e07d63cf2 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 80D44215ED; Wed, 16 Jan 2008 14:34:14 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 14:34:14 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 14:34:14 +0100 Message-ID: <478E07D5.2090801@ericsson.com> Date: Wed, 16 Jan 2008 14:34:13 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] how to signal revision? References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200485337.7029.43.camel@missotis> <478DF9B5.40006@ericsson.com> <1200489477.7029.92.camel@missotis> In-Reply-To: <1200489477.7029.92.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 16 Jan 2008 13:34:14.0083 (UTC) FILETIME=[7BF67930:01C85844] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Yes. How would you like to define it? Balazs Ladislav Lhotka wrote: > Balazs Lengyel p=C3=AD=C5=A1e v St 16. 01. 2008 v 13:33 +0100: >> We should first define, what we mean with compatible. My definition is= that a management system=20 >> that knows only the old version can handle the node i.e. anything it w= rites into the node will=20 >> work as in the previous version. An old management client will not sen= d the new data. >=20 > OK, so by compatibility you essentialy mean "compatible from server's > viewpoint". >=20 > Lada >=20 --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 08:38:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8TO-00059z-Oi; Wed, 16 Jan 2008 08:38:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF8TN-00059s-IW for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:38:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8TN-00059k-8E for yang@ietf.org; Wed, 16 Jan 2008 08:38:29 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF8TM-0002CU-Qh for yang@ietf.org; Wed, 16 Jan 2008 08:38:29 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 504FB212A5; Wed, 16 Jan 2008 14:38:27 +0100 (CET) X-AuditID: c1b4fb3e-ae69ebb00000459d-0d-478e08d2e422 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DDB60210FC; Wed, 16 Jan 2008 14:38:26 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 14:38:21 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 14:38:20 +0100 Message-ID: <478E08CC.5040901@ericsson.com> Date: Wed, 16 Jan 2008 14:38:20 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] how to signal revision? References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200485337.7029.43.camel@missotis> <478DF9B5.40006@ericsson.com> <1200489477.7029.92.camel@missotis> In-Reply-To: <1200489477.7029.92.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 16 Jan 2008 13:38:21.0027 (UTC) FILETIME=[0F272330:01C85845] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org So we have two combinations 1) old manager new node (my case) 2) new manager old node Both are interesting questions. YANG's primary aim is to define what model the node provides, so I think = we should define here=20 what is a compatible change in the node's model. Balazs Ladislav Lhotka wrote: > Balazs Lengyel p=C3=AD=C5=A1e v St 16. 01. 2008 v 13:33 +0100: >> We should first define, what we mean with compatible. My definition is= that a management system=20 >> that knows only the old version can handle the node i.e. anything it w= rites into the node will=20 >> work as in the previous version. An old management client will not sen= d the new data. >=20 > OK, so by compatibility you essentialy mean "compatible from server's > viewpoint". >=20 > Lada >=20 --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 08:43:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8Xt-0001Pc-SA; Wed, 16 Jan 2008 08:43:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF8Xt-0001PW-97 for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8Xs-0001PO-Vo for yang@ietf.org; Wed, 16 Jan 2008 08:43:08 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF8Xs-0005gv-KO for yang@ietf.org; Wed, 16 Jan 2008 08:43:08 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id D9EA11B80CE; Wed, 16 Jan 2008 14:43:03 +0100 (CET) Date: Wed, 16 Jan 2008 14:44:10 +0100 (CET) Message-Id: <20080116.144410.247903053.mbj@tail-f.com> To: lhotka@cesnet.cz Subject: Re: [YANG] how to signal revision? From: Martin Bjorklund In-Reply-To: <1200488713.7029.87.camel@missotis> References: <1200485337.7029.43.camel@missotis> <20080116.133615.104403392.mbj@tail-f.com> <1200488713.7029.87.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > In other words, the client has to understand that the schema it uses is > not compatible with the one used by the server. Would it be a problem to > require that e.g., with every change in the data model proper the major > revision number must be increased and also the namespace URI changed? The problem is that it is unnecessarily restrictive - it means that an old client cannot do its job even though the new revision of a module just added one optional leaf (for example). Extrapolating from this, we can define a set of rules which must be followed in order for a module to be compatible. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 08:54:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8ib-00041P-Ss; Wed, 16 Jan 2008 08:54:13 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF8ia-0003xo-Mh for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:54:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8ia-0003xf-CF for yang@ietf.org; Wed, 16 Jan 2008 08:54:12 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF8iZ-0002XL-Ov for yang@ietf.org; Wed, 16 Jan 2008 08:54:12 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 53C33D80098 for ; Wed, 16 Jan 2008 14:54:11 +0100 (CET) Subject: Re: [YANG] how to signal revision? From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <478E08CC.5040901@ericsson.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200485337.7029.43.camel@missotis> <478DF9B5.40006@ericsson.com> <1200489477.7029.92.camel@missotis> <478E08CC.5040901@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 14:54:11 +0100 Message-Id: <1200491651.7029.106.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel p=C3=AD=C5=A1e v St 16. 01. 2008 v 14:38 +0100: > So we have two combinations > 1) old manager new node (my case) > 2) new manager old node Right, compatibility means a different thing in each case. =20 >=20 > Both are interesting questions. > YANG's primary aim is to define what model the node provides, so I thin= k we should define here=20 > what is a compatible change in the node's model. Yup, as Martin pointed out, one can assume the manager is more flexible and should be able to handle gracefully weird data received from the node, provided it knows the node uses a new data model that the manager doesn't support. Lada >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 08:58:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8mi-0007oD-5c; Wed, 16 Jan 2008 08:58:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF8mh-0007o8-AB for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:58:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8mh-0007nt-0C for yang@ietf.org; Wed, 16 Jan 2008 08:58:27 -0500 Received: from smtp116.sbc.mail.sp1.yahoo.com ([69.147.64.89]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JF8mg-0005yG-8I for yang@ietf.org; Wed, 16 Jan 2008 08:58:26 -0500 Received: (qmail 12689 invoked from network); 16 Jan 2008 13:58:24 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 16 Jan 2008 13:58:24 -0000 X-YMail-OSG: gljGIvYVM1kcFzRWV58OsqqvW95z8f8xD5k_TQUtH1haO4S_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <478E0D95.3040308@andybierman.com> Date: Wed, 16 Jan 2008 05:58:45 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] how to signal revision? References: <1200478981.7029.27.camel@missotis> In-Reply-To: <1200478981.7029.27.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > how can the server and client make sure they are both using the same > revision of a given data model? Capabilities in NETCONF hello messages > use URIs but YANG draft says in sec. 5.4 that different revisions of the > same module should have the same namespace. > The agent needs to implement the schema discovery data model that is being standardized in the NETCONF WG. Proprietary extensions to the element in the exchange are being used in the meantime. > Lada > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 09:08:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8wV-0004Tj-3h; Wed, 16 Jan 2008 09:08:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF8wT-0004Ta-Rw for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8wT-0004Sk-Hn for yang@ietf.org; Wed, 16 Jan 2008 09:08:33 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JF8w3-0006yT-4m for yang@ietf.org; Wed, 16 Jan 2008 09:08:33 -0500 Received: (qmail 36810 invoked from network); 16 Jan 2008 14:07:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 16 Jan 2008 14:07:51 -0000 X-YMail-OSG: YkkmKrYVM1l3SFErARDdq6z8kBkajW_vojPFgbHVXwBEcvDd X-Yahoo-Newman-Property: ymail-3 Message-ID: <478E0FCD.6080908@andybierman.com> Date: Wed, 16 Jan 2008 06:08:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] default values References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> In-Reply-To: <1200487153.7029.71.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: >> Yes, changing defaults is incompatible. If you do that, you have to >> change the namespace. > > BTW, that's exactly why I am against the default values in typedef: they > make the data model too specialised. The defaults could be easily > handled as follows: > > 1. The standard that defines the type specifies in plain RFC-English > that the default value MUST, SHOULD or MAY be something. > > 2. An implementor reflects this in a device, but is also required to > fill the default (or another) value in the initial startup > configuration. > > 3. The client needn't care about what the default is, it just queries > the device to see the actual value, changes it if necessary etc. > I disagree 100%. The management of agent-supplied defaults has always been a problem in NE devices. More machine-readable support is needed, not less. YANG has the "DEFVAL with teeth" that SMIv2 never had. In YANG the default MUST be supported by the agent. It is not just a suggestion. This means the manager can actually pay attention to the default defined in the data model, and change it only if needed. On large NE devices, it is common practice to keep the CLI config file as small as possible by only including non-default values. NETCONF needs to support this feature as well, and YANG leaf/typedef default does that. > This approach would make the same data model reusable with other default > value and, in addition, allow for honouring the semantics of MUST, > SHOULD and MAY. The default in typedefs is only usable in the MUST case. > > So my suggestion is to remove the default statement form YANG. > > Lada > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 09:14:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF924-0005eN-IM; Wed, 16 Jan 2008 09:14:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF923-0005eH-QQ for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF923-0005e7-Gn for yang@ietf.org; Wed, 16 Jan 2008 09:14:19 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF922-0007KM-SK for yang@ietf.org; Wed, 16 Jan 2008 09:14:19 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8D622D800C7 for ; Wed, 16 Jan 2008 15:14:14 +0100 (CET) Subject: Re: [YANG] how to signal revision? From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080116.144410.247903053.mbj@tail-f.com> References: <1200485337.7029.43.camel@missotis> <20080116.133615.104403392.mbj@tail-f.com> <1200488713.7029.87.camel@missotis> <20080116.144410.247903053.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 15:14:14 +0100 Message-Id: <1200492855.7029.121.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund p=C3=AD=C5=A1e v St 16. 01. 2008 v 14:44 +0100: > Ladislav Lhotka wrote: > > In other words, the client has to understand that the schema it uses = is > > not compatible with the one used by the server. Would it be a problem= to > > require that e.g., with every change in the data model proper the maj= or > > revision number must be increased and also the namespace URI changed? >=20 > The problem is that it is unnecessarily restrictive - it means that an > old client cannot do its job even though the new revision of a module > just added one optional leaf (for example). Extrapolating from this, > we can define a set of rules which must be followed in order for a > module to be compatible. Exactly, and this can also be (partly) inferred from the URIs. Depending on that definition, different URIs (as well as revisions) on the client and server side may or may not be a problem - some operations can be safe while other aren't. It's a tricky area though. Lada >=20 >=20 > /martin >=20 >=20 > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 09:31:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9IQ-0005dt-6m; Wed, 16 Jan 2008 09:31:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF9IO-0005dk-6I for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:31:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9IN-0005db-Sj for yang@ietf.org; Wed, 16 Jan 2008 09:31:11 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF9IN-0007oV-Hp for yang@ietf.org; Wed, 16 Jan 2008 09:31:11 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1B216D800C5 for ; Wed, 16 Jan 2008 15:31:11 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <478E0FCD.6080908@andybierman.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 15:31:11 +0100 Message-Id: <1200493871.7029.137.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v St 16. 01. 2008 v 06:08 -0800: > YANG has the "DEFVAL with teeth" that SMIv2 never had. > In YANG the default MUST be supported by the agent. > It is not just a suggestion. This means the manager can > actually pay attention to the default defined in the data model, > and change it only if needed. I understand this but, as a matter of fact, most defaults in protocol standards are of the SHOULD class at most. In a vendor-neutral environment, it would be much safer if each device fills all the blanks. >=20 > On large NE devices, it is common practice to keep the CLI config file > as small as possible by only including non-default values. NETCONF > needs to support this feature as well, and YANG leaf/typedef default do= es that. Yes, but this is only possible because the CLIs are vendor-specific. It is quite common that different vendors use different defaults. If you try to enforce a single default in the data model, the vendor that thinks otherwise will come up with an entirely new data model (namespace URI) which is IMO much worse for interoperability. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 10:12:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9wO-00089a-Ob; Wed, 16 Jan 2008 10:12:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JF9wO-00089V-5r for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:12:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9wN-00089K-S9 for yang@ietf.org; Wed, 16 Jan 2008 10:12:31 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JF9wN-0000Fy-9e for yang@ietf.org; Wed, 16 Jan 2008 10:12:31 -0500 Received: (qmail 41774 invoked from network); 16 Jan 2008 15:12:30 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 16 Jan 2008 15:12:30 -0000 X-YMail-OSG: EU1XQ5YVM1kgHx_dn2jerA9xgFmyMLkrX9UjQaxaXe117MX6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <478E1EF4.4050002@andybierman.com> Date: Wed, 16 Jan 2008 07:12:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] default values References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> In-Reply-To: <1200493871.7029.137.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Andy Bierman píše v St 16. 01. 2008 v 06:08 -0800: > >> YANG has the "DEFVAL with teeth" that SMIv2 never had. >> In YANG the default MUST be supported by the agent. >> It is not just a suggestion. This means the manager can >> actually pay attention to the default defined in the data model, >> and change it only if needed. > > I understand this but, as a matter of fact, most defaults in protocol > standards are of the SHOULD class at most. In a vendor-neutral > environment, it would be much safer if each device fills all the blanks. > >> On large NE devices, it is common practice to keep the CLI config file >> as small as possible by only including non-default values. NETCONF >> needs to support this feature as well, and YANG leaf/typedef default does that. > > Yes, but this is only possible because the CLIs are vendor-specific. It > is quite common that different vendors use different defaults. If you > try to enforce a single default in the data model, the vendor that > thinks otherwise will come up with an entirely new data model (namespace > URI) which is IMO much worse for interoperability. > You are entering a new topic zone -- why the IETF has never been successful in standardizing the configuration of any of its protocols. After 20 years and a pathetic handful of standard writable knobs, one has to ask if maybe there is some part of the problem space that has been overlooked. We will never have standard writable knobs until vendors understand the concept of a standard, and make an effort to define some standard knobs, which actually provide enough functionality to configure the device. It takes a lot of work to define the standard knob settings, and protocol WGs usually decide not to bother with any configuration at all. But we make all our hammers and all our nails by hand, so it is easy to get away with it. (Lewis and Clark burned down some forts along the way, to recover and reuse their precious handmade nails. We need to learn how to get machines to make the nails... ;-) > Lada > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 10:21:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA4l-0001Ov-99; Wed, 16 Jan 2008 10:21:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFA4k-0001Om-LV for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA4k-0001Oe-Bs for yang@ietf.org; Wed, 16 Jan 2008 10:21:10 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFA4j-0000Oy-Rh for yang@ietf.org; Wed, 16 Jan 2008 10:21:10 -0500 Received: from [192.168.50.14] ([209.19.56.4]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id m0GFKmV1030779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2008 09:20:49 -0600 In-Reply-To: <478E1EF4.4050002@andybierman.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Jon Saperia Subject: Re: [YANG] default values Date: Wed, 16 Jan 2008 10:20:47 -0500 To: Andy Bierman X-Mailer: Apple Mail (2.753) X-Spam-Score: -1.0 (-) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Jan 16, 2008, at 10:12 AM, Andy Bierman wrote: > Ladislav Lhotka wrote: >> Andy Bierman p=ED=9Ae v St 16. 01. 2008 v 06:08 -0800: >>> YANG has the "DEFVAL with teeth" that SMIv2 never had. >>> In YANG the default MUST be supported by the agent. >>> It is not just a suggestion. This means the manager can >>> actually pay attention to the default defined in the data model, >>> and change it only if needed. >> I understand this but, as a matter of fact, most defaults in protocol >> standards are of the SHOULD class at most. In a vendor-neutral >> environment, it would be much safer if each device fills all the =20 >> blanks. >>> On large NE devices, it is common practice to keep the CLI config =20= >>> file >>> as small as possible by only including non-default values. NETCONF >>> needs to support this feature as well, and YANG leaf/typedef =20 >>> default does that. >> Yes, but this is only possible because the CLIs are vendor-=20 >> specific. It >> is quite common that different vendors use different defaults. If you >> try to enforce a single default in the data model, the vendor that >> thinks otherwise will come up with an entirely new data model =20 >> (namespace >> URI) which is IMO much worse for interoperability. > > You are entering a new topic zone -- why the IETF has never been > successful in standardizing the configuration of any of its protocols. > After 20 years and a pathetic handful of standard writable knobs, > one has to ask if maybe there is some part of the problem space > that has been overlooked. > > We will never have standard writable knobs until vendors understand > the concept of a standard, and make an effort to define some > standard knobs, which actually provide enough functionality > to configure the device. And they believe it is in their best interest (beyond lip service and =20= Marketing) to have the standard. There are plenty of smart people at =20= vendors, they have the money to do it. If they really wanted it and =20 the customers really wanted to push it we would have them. It has =20 nothing to do with technology. /jon > > It takes a lot of work to define the standard knob settings, > and protocol WGs usually decide not to bother with any configuration > at all. But we make all our hammers and all our nails by hand, > so it is easy to get away with it. > > (Lewis and Clark burned down some forts along the way, to > recover and reuse their precious handmade nails. We need to > learn how to get machines to make the nails... ;-) > >> Lada > > Andy > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 11:32:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBBa-0005H9-BY; Wed, 16 Jan 2008 11:32:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFBBZ-0005Gs-Jy for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBBZ-0005Gj-9x for yang@ietf.org; Wed, 16 Jan 2008 11:32:17 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFBBX-0003im-1y for yang@ietf.org; Wed, 16 Jan 2008 11:32:17 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7AB00D800C1 for ; Wed, 16 Jan 2008 17:32:10 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 16 Jan 2008 17:32:11 +0100 Message-Id: <1200501131.7029.151.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Jon Saperia p=C3=AD=C5=A1e v St 16. 01. 2008 v 10:20 -0500: > > We will never have standard writable knobs until vendors understand > > the concept of a standard, and make an effort to define some > > standard knobs, which actually provide enough functionality > > to configure the device. >=20 > And they believe it is in their best interest (beyond lip service and =20 > Marketing) to have the standard. There are plenty of smart people at =20 > vendors, they have the money to do it. If they really wanted it and =20 > the customers really wanted to push it we would have them. It has =20 > nothing to do with technology. > /jon That's why I believe it won't help to specify the default in the data model. And it's not necessary - I can actually imagine a manager station that follows the standards and changes the wrong defaults in misbehaving devices - and showing the user only non-default values, but according to its own set of defaults, not necessarily the devices'. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 11:54:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBXL-0004NR-Hv; Wed, 16 Jan 2008 11:54:47 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFBXJ-0004AY-Iy for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 11:54:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBXJ-00048D-6E for yang@ietf.org; Wed, 16 Jan 2008 11:54:45 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFBXG-0004E5-AP for yang@ietf.org; Wed, 16 Jan 2008 11:54:45 -0500 Received: from [12.158.230.229] ([12.158.230.229]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id m0GGscWa008513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2008 10:54:39 -0600 In-Reply-To: <1200501131.7029.151.camel@missotis> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> Content-Transfer-Encoding: quoted-printable From: Jon Saperia Subject: Re: [YANG] default values Date: Wed, 16 Jan 2008 11:54:38 -0500 To: Ladislav Lhotka X-Mailer: Apple Mail (2.753) X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Jan 16, 2008, at 11:32 AM, Ladislav Lhotka wrote: > > Jon Saperia p=ED=9Ae v St 16. 01. 2008 v 10:20 -0500: >>> We will never have standard writable knobs until vendors understand >>> the concept of a standard, and make an effort to define some >>> standard knobs, which actually provide enough functionality >>> to configure the device. >> >> And they believe it is in their best interest (beyond lip service and >> Marketing) to have the standard. There are plenty of smart people at >> vendors, they have the money to do it. If they really wanted it and >> the customers really wanted to push it we would have them. It has >> nothing to do with technology. >> /jon > > That's why I believe it won't help to specify the default in the data > model. And it's not necessary - I can actually imagine a manager =20 > station > that follows the standards and changes the wrong defaults in =20 > misbehaving > devices - and showing the user only non-default values, but =20 > according to > its own set of defaults, not necessarily the devices'. > > Lada I understand your perspective but even though I said what I said, if =20= we were to go down this path, defaults can be helpful. Any manager =20 that attempts the configuration function will have to be pretty =20 sophisticated because of the variability (even with standards) that =20 will be sure to exist. That does not mean that they will not do bad =20 things from time to time, but the market has a way of fixing things. /jon= _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 12:02:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBem-00006Y-6X; Wed, 16 Jan 2008 12:02:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFBek-0008Ji-Ay for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 12:02:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBej-0008Fm-QL for yang@ietf.org; Wed, 16 Jan 2008 12:02:25 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFBej-0002Mj-AG for yang@ietf.org; Wed, 16 Jan 2008 12:02:25 -0500 Received: (qmail 65801 invoked from network); 16 Jan 2008 17:02:24 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 16 Jan 2008 17:02:24 -0000 X-YMail-OSG: eKfVea0VM1lINqRuMwV18jhRf1AFFtX_j6gD7nL8VtBhzZij X-Yahoo-Newman-Property: ymail-3 Message-ID: <478E38B6.2080208@andybierman.com> Date: Wed, 16 Jan 2008 09:02:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] default values References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> In-Reply-To: <1200501131.7029.151.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Jon Saperia píše v St 16. 01. 2008 v 10:20 -0500: >>> We will never have standard writable knobs until vendors understand >>> the concept of a standard, and make an effort to define some >>> standard knobs, which actually provide enough functionality >>> to configure the device. >> And they believe it is in their best interest (beyond lip service and >> Marketing) to have the standard. There are plenty of smart people at >> vendors, they have the money to do it. If they really wanted it and >> the customers really wanted to push it we would have them. It has >> nothing to do with technology. >> /jon > > That's why I believe it won't help to specify the default in the data > model. And it's not necessary - I can actually imagine a manager station > that follows the standards and changes the wrong defaults in misbehaving > devices - and showing the user only non-default values, but according to > its own set of defaults, not necessarily the devices'. > I disagree. If there is a agreed-upon default value (along with the rest of the agreed-upon properties), then it should be documented, and be both machine and human readable. Why should the manager assume the devices will be misbehaving or buggy? I think vendors try to implement the standards as they are written. There is no big conspiracy theory here -- just a lot of hard work that has been historically difficult to accomplish. If the shared mindset persists that all these NE boxes are proprietary by nature, and they have little or nothing in common that can be configured with standard data models, then we are wasting our time with NETCONF and YANG. I choose to believe that we are simply in the Stone Ages of network management, and it will take some time to evolve the protocols and tools beyond the hand-crafted, ad-hoc, poor excuse for a programmatic interface, we call The CLI. > Lada > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 14:09:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDdt-0002yl-TV; Wed, 16 Jan 2008 14:09:41 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFDds-0002sT-NS for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 14:09:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDds-0002nh-93 for yang@ietf.org; Wed, 16 Jan 2008 14:09:40 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFDdr-0006rq-Iv for yang@ietf.org; Wed, 16 Jan 2008 14:09:40 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Wed, 16 Jan 2008 11:09:26 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 11:09:00 -0800 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 m0GJ8x937394; Wed, 16 Jan 2008 11:09:00 -0800 (PST) (envelope-from phil@idle.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 m0GJ8mT8073099; Wed, 16 Jan 2008 19:08:52 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801161908.m0GJ8mT8073099@idle.juniper.net> To: Andy Bierman In-reply-to: <478E1EF4.4050002@andybierman.com> Date: Wed, 16 Jan 2008 14:08:47 -0500 From: Phil Shafer X-OriginalArrivalTime: 16 Jan 2008 19:09:00.0415 (UTC) FILETIME=[405980F0:01C85873] X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: yang@ietf.org, Ladislav Lhotka Subject: [YANG] Underestimating the problem ([was something else]) X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >We will never have standard writable knobs until vendors understand >the concept of a standard, and make an effort to define some >standard knobs, which actually provide enough functionality >to configure the device. If you are looking for a constant historical line of thought that explains the failure of standardized configuration, look no further than this line above. The "it's the vendor's fault" line has been a constant albatross around such efforts. We are better off admitting that the problem is not simple, and studying the factors that make it difficult. Configuration is not simple and underestimating the problem won't help standardization issues. In designing configuration for a complex device, you have a number of goals: (a) avoid human error -- design the config to make errors detectable in software, and observable in "show" output. (b) be flexible -- customer deployment scenarios exceed your vision when you design something. Allowing for these cases is both important and painful. (c) complexity reduction -- if it's complex to configure, it won't get deployed. And if it does get deployed, the support costs for both the customer and the vendor will be high. (d) details should be hidden where possible -- the user shouldn't need to fully grok hardware, software, or protocol issues to config them. (e) enhancement/future proofing -- this config needs to work on next year's hardware running next year's software, often running next year's protocols. (f) full feature support -- the config needs to fully represent the available features your hardware and software support. (g) got to be consistent -- make it fit inside the rules and conventions of your existing syntax (h) holistic view -- the config should look like a single description of a complete system, not a dog's breakfast of tokens. (i) I'm sure there's more..... In the fight for simplification, many of these goals cut against each other. For example, in trying to be flexible, I have to decide when an odd configuration is an error and when the user is just doing something clever (which may be an error, but is an intentional one). For standardization, the goals are often completely different. Expressiveness and accuracy win over simplicity. A single complex method of configuration wins over a dual "common" and "advanced" approach. The model for a standard must be something that can support all platforms, which leads to complexity, and the translation between the standard's complex model and the unique abilities of individual platforms is non-trivial. An example is packet filtering, where the device config is more often dictated by the hardware architecture and the layout of that hardware (in terms of where packets can be filtered, what can be filtered on, what can be done to them at that layer, and what resources are consumed) is often directly visible in the configuration in order for the customer to express their desired setup. But a standard needs an "uber" model, where any sort of filtering can be done at any place with any outcome without concern for resource impact. No vendor will implement this model, and the translation between the model and the device config requires a strong understanding of the performance .vs. resource utilization tradeoffs that the customer is willing to make. For example, some functionality may be available in hardware at wire rate; other in hardware at lower speed; other in dedicated CPUs; and still other in the main CPU. Choosing the proper filtering point is a matter of both the speed and abilities of that point, plus chip memory and other contention issues. And getting a correct assignment will still be wrong if it's not the assignment the customer wanted. This translation must be performed in a way that avoids letting small changes in the config from turning into large config changes on the device. It's not an easy problem, and to my mind it's the key to device- independent configuration. The fact that my bgp configuration doesn't look like the bgp mib shouldn't be surprising, since the two configurations serve two different masters. The lack of any automated translation between the two is the real killer. A key aspect of this translation is the ability to round-trip, turning MIBs into device config and back in a way that doesn't lose information. The problem isn't getting a few knobs to configure basic functionality, but getting a solution that's complete enough to give folks sufficient faith to move toward it. If it solved 20% of the problem, it's worthless. When it solves 80-90% of the problem, it's interesting. NETCONF gives us the ability to manipulate configuration in XML, which is a good first step. YANG gives us the ability to define that XML in a way that allows extensibility and the expression of device-specific content, which is a good second step. The next step will be a translation framework that allows robust translation between a standard view and a device specific view. So I think we are on the right road, although the pace of the journey is disheartening. But regressing to this "it's the vendor's fault" line is completely unproductive. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 14:47:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEEK-00011x-Ug; Wed, 16 Jan 2008 14:47:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFEEJ-00011S-Jw for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 14:47:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEEJ-00011K-9n for yang@ietf.org; Wed, 16 Jan 2008 14:47:19 -0500 Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFEEH-00083L-1E for yang@ietf.org; Wed, 16 Jan 2008 14:47:19 -0500 Received: (qmail 92444 invoked from network); 16 Jan 2008 19:47:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 16 Jan 2008 19:47:16 -0000 X-YMail-OSG: lRSvztoVM1nmh7Nsl_A1eAHIF1BozWQKgiF9YaoVK3MWLfUb X-Yahoo-Newman-Property: ymail-3 Message-ID: <478E5F42.4040404@andybierman.com> Date: Wed, 16 Jan 2008 11:47:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer References: <200801161908.m0GJ8mT8073099@idle.juniper.net> In-Reply-To: <200801161908.m0GJ8mT8073099@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: yang@ietf.org, Ladislav Lhotka Subject: [YANG] Re: Underestimating the problem ([was something else]) X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> We will never have standard writable knobs until vendors understand >> the concept of a standard, and make an effort to define some >> standard knobs, which actually provide enough functionality >> to configure the device. > > If you are looking for a constant historical line of thought that > explains the failure of standardized configuration, look no further > than this line above. The "it's the vendor's fault" line has been > a constant albatross around such efforts. We are better off admitting > that the problem is not simple, and studying the factors that make > it difficult. Configuration is not simple and underestimating the > problem won't help standardization issues. > I do not think it is all the vendors fault. The IETF process, the current state of data modeling tools used in NE development, and lack of relative priority among all customer requirements contribute greatly. (I hope the requirements spec captures all your text below.) Since we already know that getting 10 vendors together in a WG meeting room just to agree there is nothing in common to standardize doesn't work, we need to come up with a new plan. IMO, the IETF has been avoiding the real problems facing NETCONF. YANG does not address the real problems preventing standard data models for configuration either. I am hoping that in the end, the solution is something more elegant than a standard way to figure out which of the 47 ways a particular device implements a given data model. But if not, then maybe registry-based-indirection mechanisms would work instead. Andy > In designing configuration for a complex device, you have a > number of goals: > > (a) avoid human error -- design the config to make errors > detectable in software, and observable in "show" output. > (b) be flexible -- customer deployment scenarios exceed your > vision when you design something. Allowing for these > cases is both important and painful. > (c) complexity reduction -- if it's complex to configure, it > won't get deployed. And if it does get deployed, the > support costs for both the customer and the vendor will > be high. > (d) details should be hidden where possible -- the user shouldn't > need to fully grok hardware, software, or protocol issues to > config them. > (e) enhancement/future proofing -- this config needs to work on > next year's hardware running next year's software, often > running next year's protocols. > (f) full feature support -- the config needs to fully represent > the available features your hardware and software support. > (g) got to be consistent -- make it fit inside the rules and > conventions of your existing syntax > (h) holistic view -- the config should look like a single description > of a complete system, not a dog's breakfast of tokens. > (i) I'm sure there's more..... > > In the fight for simplification, many of these goals cut against > each other. For example, in trying to be flexible, I have to decide > when an odd configuration is an error and when the user is just > doing something clever (which may be an error, but is an intentional > one). > > For standardization, the goals are often completely different. > Expressiveness and accuracy win over simplicity. A single complex > method of configuration wins over a dual "common" and "advanced" > approach. The model for a standard must be something that can > support all platforms, which leads to complexity, and the translation > between the standard's complex model and the unique abilities of > individual platforms is non-trivial. > > An example is packet filtering, where the device config is more > often dictated by the hardware architecture and the layout of that > hardware (in terms of where packets can be filtered, what can be > filtered on, what can be done to them at that layer, and what > resources are consumed) is often directly visible in the configuration > in order for the customer to express their desired setup. > > But a standard needs an "uber" model, where any sort of filtering > can be done at any place with any outcome without concern for > resource impact. No vendor will implement this model, and the > translation between the model and the device config requires a > strong understanding of the performance .vs. resource utilization > tradeoffs that the customer is willing to make. > > For example, some functionality may be available in hardware at > wire rate; other in hardware at lower speed; other in dedicated > CPUs; and still other in the main CPU. Choosing the proper filtering > point is a matter of both the speed and abilities of that point, > plus chip memory and other contention issues. And getting a correct > assignment will still be wrong if it's not the assignment the > customer wanted. > > This translation must be performed in a way that avoids letting > small changes in the config from turning into large config changes > on the device. It's not an easy problem, and to my mind it's the > key to device- independent configuration. > > The fact that my bgp configuration doesn't look like the bgp > mib shouldn't be surprising, since the two configurations > serve two different masters. The lack of any automated > translation between the two is the real killer. > > A key aspect of this translation is the ability to round-trip, > turning MIBs into device config and back in a way that doesn't > lose information. > > The problem isn't getting a few knobs to configure basic functionality, > but getting a solution that's complete enough to give folks sufficient > faith to move toward it. If it solved 20% of the problem, it's > worthless. When it solves 80-90% of the problem, it's interesting. > > NETCONF gives us the ability to manipulate configuration in XML, > which is a good first step. YANG gives us the ability to define > that XML in a way that allows extensibility and the expression of > device-specific content, which is a good second step. The next > step will be a translation framework that allows robust translation > between a standard view and a device specific view. > > So I think we are on the right road, although the pace of the journey > is disheartening. But regressing to this "it's the vendor's fault" > line is completely unproductive. > > Thanks, > Phil > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 14:50:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEHb-0003mf-Sk; Wed, 16 Jan 2008 14:50:43 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFEHa-0003mB-Tx for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 14:50:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEHa-0003lz-HG for yang@ietf.org; Wed, 16 Jan 2008 14:50:42 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFEHZ-0006tD-P9 for yang@ietf.org; Wed, 16 Jan 2008 14:50:42 -0500 Received: from [12.158.230.229] ([12.158.230.229]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id m0GJoTZY024337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2008 13:50:29 -0600 In-Reply-To: <200801161908.m0GJ8mT8073099@idle.juniper.net> References: <200801161908.m0GJ8mT8073099@idle.juniper.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jon Saperia Subject: Re: [YANG] Underestimating the problem ([was something else]) Date: Wed, 16 Jan 2008 14:50:28 -0500 To: Phil Shafer X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org To underestimate other factors that have inhibited progress, whether from technical limitations, the vendors, standards organization, or user community, has been counter productive as well. Whatever is developed must allow for variability. /jon On Jan 16, 2008, at 2:08 PM, Phil Shafer wrote: > Andy Bierman writes: >> We will never have standard writable knobs until vendors understand >> the concept of a standard, and make an effort to define some >> standard knobs, which actually provide enough functionality >> to configure the device. > > If you are looking for a constant historical line of thought that > explains the failure of standardized configuration, look no further > than this line above. The "it's the vendor's fault" line has been > a constant albatross around such efforts. We are better off admitting > that the problem is not simple, and studying the factors that make > it difficult. Configuration is not simple and underestimating the > problem won't help standardization issues. > > In designing configuration for a complex device, you have a > number of goals: > > (a) avoid human error -- design the config to make errors > detectable in software, and observable in "show" output. > (b) be flexible -- customer deployment scenarios exceed your > vision when you design something. Allowing for these > cases is both important and painful. > (c) complexity reduction -- if it's complex to configure, it > won't get deployed. And if it does get deployed, the > support costs for both the customer and the vendor will > be high. > (d) details should be hidden where possible -- the user shouldn't > need to fully grok hardware, software, or protocol issues to > config them. > (e) enhancement/future proofing -- this config needs to work on > next year's hardware running next year's software, often > running next year's protocols. > (f) full feature support -- the config needs to fully represent > the available features your hardware and software support. > (g) got to be consistent -- make it fit inside the rules and > conventions of your existing syntax > (h) holistic view -- the config should look like a single description > of a complete system, not a dog's breakfast of tokens. > (i) I'm sure there's more..... > > In the fight for simplification, many of these goals cut against > each other. For example, in trying to be flexible, I have to decide > when an odd configuration is an error and when the user is just > doing something clever (which may be an error, but is an intentional > one). > > For standardization, the goals are often completely different. > Expressiveness and accuracy win over simplicity. A single complex > method of configuration wins over a dual "common" and "advanced" > approach. The model for a standard must be something that can > support all platforms, which leads to complexity, and the translation > between the standard's complex model and the unique abilities of > individual platforms is non-trivial. > > An example is packet filtering, where the device config is more > often dictated by the hardware architecture and the layout of that > hardware (in terms of where packets can be filtered, what can be > filtered on, what can be done to them at that layer, and what > resources are consumed) is often directly visible in the configuration > in order for the customer to express their desired setup. > > But a standard needs an "uber" model, where any sort of filtering > can be done at any place with any outcome without concern for > resource impact. No vendor will implement this model, and the > translation between the model and the device config requires a > strong understanding of the performance .vs. resource utilization > tradeoffs that the customer is willing to make. > > For example, some functionality may be available in hardware at > wire rate; other in hardware at lower speed; other in dedicated > CPUs; and still other in the main CPU. Choosing the proper filtering > point is a matter of both the speed and abilities of that point, > plus chip memory and other contention issues. And getting a correct > assignment will still be wrong if it's not the assignment the > customer wanted. > > This translation must be performed in a way that avoids letting > small changes in the config from turning into large config changes > on the device. It's not an easy problem, and to my mind it's the > key to device- independent configuration. > > The fact that my bgp configuration doesn't look like the bgp > mib shouldn't be surprising, since the two configurations > serve two different masters. The lack of any automated > translation between the two is the real killer. > > A key aspect of this translation is the ability to round-trip, > turning MIBs into device config and back in a way that doesn't > lose information. > > The problem isn't getting a few knobs to configure basic > functionality, > but getting a solution that's complete enough to give folks sufficient > faith to move toward it. If it solved 20% of the problem, it's > worthless. When it solves 80-90% of the problem, it's interesting. > > NETCONF gives us the ability to manipulate configuration in XML, > which is a good first step. YANG gives us the ability to define > that XML in a way that allows extensibility and the expression of > device-specific content, which is a good second step. The next > step will be a translation framework that allows robust translation > between a standard view and a device specific view. > > So I think we are on the right road, although the pace of the journey > is disheartening. But regressing to this "it's the vendor's fault" > line is completely unproductive. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 15:08:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEYf-0006TL-QO; Wed, 16 Jan 2008 15:08:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFEYe-0006T3-81 for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 15:08:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEKr-0000HA-Th for yang@ietf.org; Wed, 16 Jan 2008 14:54:07 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFEKi-0007UA-FV for yang@ietf.org; Wed, 16 Jan 2008 14:54:05 -0500 Received: from [12.158.230.229] ([12.158.230.229]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id m0GJrqxb028574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2008 13:53:52 -0600 In-Reply-To: <478E5F42.4040404@andybierman.com> References: <200801161908.m0GJ8mT8073099@idle.juniper.net> <478E5F42.4040404@andybierman.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CD0AFE6-0B4D-4492-8903-83BAAA275ACC@jdscons.com> Content-Transfer-Encoding: 7bit From: Jon Saperia Subject: Re: [YANG] Re: Underestimating the problem ([was something else]) Date: Wed, 16 Jan 2008 14:53:50 -0500 To: Andy Bierman X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Jan 16, 2008, at 2:47 PM, Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> We will never have standard writable knobs until vendors understand >>> the concept of a standard, and make an effort to define some >>> standard knobs, which actually provide enough functionality >>> to configure the device. >> If you are looking for a constant historical line of thought that >> explains the failure of standardized configuration, look no further >> than this line above. The "it's the vendor's fault" line has been >> a constant albatross around such efforts. We are better off >> admitting >> that the problem is not simple, and studying the factors that make >> it difficult. Configuration is not simple and underestimating the >> problem won't help standardization issues. > > I do not think it is all the vendors fault. > The IETF process, the current state of data modeling tools > used in NE development, and lack of relative priority among all > customer requirements contribute greatly. > > (I hope the requirements spec captures all your text below.) > > Since we already know that getting 10 vendors together > in a WG meeting room just to agree there is nothing in > common to standardize doesn't work, we need to come > up with a new plan. > > IMO, the IETF has been avoiding the real problems facing NETCONF. > YANG does not address the real problems preventing standard > data models for configuration either. > > I am hoping that in the end, the solution is something more > elegant than a standard way to figure out which of the 47 ways > a particular device implements a given data model. > But if not, then maybe registry-based-indirection mechanisms > would work instead. I think there is a lot of merit in a 'registry-based' mechanism approach. You would still need aspects of what has already been accomplished, and YANG, or something else for the broad solution desired. /jon > > Andy > > > >> In designing configuration for a complex device, you have a >> number of goals: >> (a) avoid human error -- design the config to make errors >> detectable in software, and observable in "show" output. >> (b) be flexible -- customer deployment scenarios exceed your >> vision when you design something. Allowing for these >> cases is both important and painful. >> (c) complexity reduction -- if it's complex to configure, it >> won't get deployed. And if it does get deployed, the >> support costs for both the customer and the vendor will >> be high. >> (d) details should be hidden where possible -- the user shouldn't >> need to fully grok hardware, software, or protocol issues to >> config them. >> (e) enhancement/future proofing -- this config needs to work on >> next year's hardware running next year's software, often >> running next year's protocols. >> (f) full feature support -- the config needs to fully represent >> the available features your hardware and software support. >> (g) got to be consistent -- make it fit inside the rules and >> conventions of your existing syntax >> (h) holistic view -- the config should look like a single description >> of a complete system, not a dog's breakfast of tokens. >> (i) I'm sure there's more..... >> In the fight for simplification, many of these goals cut against >> each other. For example, in trying to be flexible, I have to decide >> when an odd configuration is an error and when the user is just >> doing something clever (which may be an error, but is an intentional >> one). >> For standardization, the goals are often completely different. >> Expressiveness and accuracy win over simplicity. A single complex >> method of configuration wins over a dual "common" and "advanced" >> approach. The model for a standard must be something that can >> support all platforms, which leads to complexity, and the translation >> between the standard's complex model and the unique abilities of >> individual platforms is non-trivial. >> An example is packet filtering, where the device config is more >> often dictated by the hardware architecture and the layout of that >> hardware (in terms of where packets can be filtered, what can be >> filtered on, what can be done to them at that layer, and what >> resources are consumed) is often directly visible in the >> configuration >> in order for the customer to express their desired setup. >> But a standard needs an "uber" model, where any sort of filtering >> can be done at any place with any outcome without concern for >> resource impact. No vendor will implement this model, and the >> translation between the model and the device config requires a >> strong understanding of the performance .vs. resource utilization >> tradeoffs that the customer is willing to make. >> For example, some functionality may be available in hardware at >> wire rate; other in hardware at lower speed; other in dedicated >> CPUs; and still other in the main CPU. Choosing the proper filtering >> point is a matter of both the speed and abilities of that point, >> plus chip memory and other contention issues. And getting a correct >> assignment will still be wrong if it's not the assignment the >> customer wanted. >> This translation must be performed in a way that avoids letting >> small changes in the config from turning into large config changes >> on the device. It's not an easy problem, and to my mind it's the >> key to device- independent configuration. >> The fact that my bgp configuration doesn't look like the bgp >> mib shouldn't be surprising, since the two configurations >> serve two different masters. The lack of any automated >> translation between the two is the real killer. >> A key aspect of this translation is the ability to round-trip, >> turning MIBs into device config and back in a way that doesn't >> lose information. >> The problem isn't getting a few knobs to configure basic >> functionality, >> but getting a solution that's complete enough to give folks >> sufficient >> faith to move toward it. If it solved 20% of the problem, it's >> worthless. When it solves 80-90% of the problem, it's interesting. >> NETCONF gives us the ability to manipulate configuration in XML, >> which is a good first step. YANG gives us the ability to define >> that XML in a way that allows extensibility and the expression of >> device-specific content, which is a good second step. The next >> step will be a translation framework that allows robust translation >> between a standard view and a device specific view. >> So I think we are on the right road, although the pace of the journey >> is disheartening. But regressing to this "it's the vendor's fault" >> line is completely unproductive. >> Thanks, >> Phil > > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 15:11:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEbp-0008SR-EZ; Wed, 16 Jan 2008 15:11:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFEbo-0008SC-LT for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 15:11:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEbo-0008Ri-B3 for yang@ietf.org; Wed, 16 Jan 2008 15:11:36 -0500 Received: from exprod7og108.obsmtp.com ([64.18.2.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFEbn-00005M-Su for yang@ietf.org; Wed, 16 Jan 2008 15:11:36 -0500 Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 16 Jan 2008 12:11:27 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:11:11 -0800 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 m0GKBB956999; Wed, 16 Jan 2008 12:11:11 -0800 (PST) (envelope-from phil@idle.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 m0GKB3Gw073643; Wed, 16 Jan 2008 20:11:03 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801162011.m0GKB3Gw073643@idle.juniper.net> To: Andy Bierman In-reply-to: <478E5F42.4040404@andybierman.com> Date: Wed, 16 Jan 2008 15:11:03 -0500 From: Phil Shafer X-OriginalArrivalTime: 16 Jan 2008 20:11:11.0945 (UTC) FILETIME=[F083CB90:01C8587B] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang@ietf.org, Ladislav Lhotka Subject: [YANG] Re: Underestimating the problem ([was something else]) X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >YANG does not address the real problems preventing standard >data models for configuration either. Yup, it's just another step. My concern is that we don't spend seven years on this step. >But if not, then maybe registry-based-indirection mechanisms >would work instead. The translation framework needs to give flexibility not only to the expressiveness of the device configuration, but also to the ability of the provider to tailor the translation to their needs/networks/products/customers/etc. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 16 15:25:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEon-0001NA-PS; Wed, 16 Jan 2008 15:25:01 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFEon-0001N5-Br for yang-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 15:25:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEon-0001Mu-1y for yang@ietf.org; Wed, 16 Jan 2008 15:25:01 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFEom-0001cA-Fg for yang@ietf.org; Wed, 16 Jan 2008 15:25:01 -0500 Received: (qmail 68277 invoked from network); 16 Jan 2008 20:25:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 16 Jan 2008 20:24:59 -0000 X-YMail-OSG: bVFbVv8VM1kLiCAWSchXdzUnxnKj.5SVvm.jTJcjdHL4_6RH X-Yahoo-Newman-Property: ymail-3 Message-ID: <478E6819.9000206@andybierman.com> Date: Wed, 16 Jan 2008 12:24:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer References: <200801162011.m0GKB3Gw073643@idle.juniper.net> In-Reply-To: <200801162011.m0GKB3Gw073643@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org, Ladislav Lhotka Subject: [YANG] Re: Underestimating the problem ([was something else]) X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> YANG does not address the real problems preventing standard >> data models for configuration either. > > Yup, it's just another step. My concern is that we don't > spend seven years on this step. > Some of us will vote with our feet way before then ;-) >> But if not, then maybe registry-based-indirection mechanisms >> would work instead. > > The translation framework needs to give flexibility not only > to the expressiveness of the device configuration, but also > to the ability of the provider to tailor the translation to > their needs/networks/products/customers/etc. > I can remember (from my former life as an IOS SW developer), several bold attempts to provide this sort of translation in a closed, self-contained application -- and they all failed spectacularly. It is way too hard for 1 apps-dev team (or person!) to keep the database up to date or even tractable. But, if WEB apps existed that provided an easy-to-use Wikipedia kind of community-input approach, combined with structured use of NETCONF capabilities, YANG data models, and some new (very TBD) indirection mechanisms in YANG, then it might be possible to get 80% of a router configured auto-magically, and drastically simplify the other 20%. > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 02:57:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPcb-0007rT-8v; Thu, 17 Jan 2008 02:57:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFPca-0007qy-Es for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 02:57:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPcT-0007V6-9I for yang@ietf.org; Thu, 17 Jan 2008 02:57:01 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFPcS-0004xU-Sr for yang@ietf.org; Thu, 17 Jan 2008 02:57:01 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 39AE9D800C1; Thu, 17 Jan 2008 08:57:00 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: Jon Saperia In-Reply-To: <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 08:56:59 +0100 Message-Id: <1200556619.10666.16.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Jon Saperia p=C3=AD=C5=A1e v St 16. 01. 2008 v 11:54 -0500: > I understand your perspective but even though I said what I said, if =20 > we were to go down this path, defaults can be helpful. Any manager =20 > that attempts the configuration function will have to be pretty =20 > sophisticated because of the variability (even with standards) that =20 > will be sure to exist. That does not mean that they will not do bad =20 > things from time to time, but the market has a way of fixing things. I am not against specifying defaults (reasonably), I only don't like the fact that changing a default value implies a different data model. I understand the data model primarily as a means for checking whether a given document is valid or not and default values are irrelevant in this respect. It is already difficult to standardise the knobs and default values are yet another level. Lada >=20 > /jon --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 03:38:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQGE-0001g5-Vm; Thu, 17 Jan 2008 03:38:06 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFQGD-0001fv-2A for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 03:38:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQGC-0001fi-M6 for yang@ietf.org; Thu, 17 Jan 2008 03:38:04 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFQGA-0004P0-TF for yang@ietf.org; Thu, 17 Jan 2008 03:38:04 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2798CD800BD; Thu, 17 Jan 2008 09:37:58 +0100 (CET) From: Ladislav Lhotka To: David Partain In-Reply-To: <200801161746.52622.david.partain@ericsson.com> References: <200801161746.52622.david.partain@ericsson.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Thu, 17 Jan 2008 09:37:57 +0100 Message-Id: <1200559077.10666.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: yang Subject: [YANG] Re: Requirement question X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org David Partain p=C3=AD=C5=A1e v St 16. 01. 2008 v 17:46 +0100: > In Vancouver at the "ad hoc requirement meeting", you were a proponent = of the=20 > requirement that we need "deep keys" in the NETCONF data modeling langu= age. =20 > For the benefit of the design team working on the requirements, could y= ou=20 > describe what you mean by "deep keys"? An example would be very helpfu= l as=20 > well. >=20 YANG currently requires that list keys be direct children of the elements that are modelled as list items. In other words, the keys cannot appear inside containers under the list statement. The following example (borrowed from Phil Shafer) shows a natural use of deep keys:
10.1.2.4
22
10.1.2.5
22000 43210 ... YANG declaration (currently illegal): list flow { key "source/address source/port destination/address destination/port"; container source { use endpoint; } container destination { use endpoint; } leaf packet-count { type uint32; } } Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 03:46:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQOg-0005EM-1K; Thu, 17 Jan 2008 03:46:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFQOf-0005Bl-Gs for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 03:46:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQOf-00059Y-2P for yang@ietf.org; Thu, 17 Jan 2008 03:46:49 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFQOe-0004Wu-Oj for yang@ietf.org; Thu, 17 Jan 2008 03:46:49 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4D10AD800BD; Thu, 17 Jan 2008 09:46:48 +0100 (CET) From: Ladislav Lhotka To: David Partain In-Reply-To: <1200559077.10666.26.camel@missotis> References: <200801161746.52622.david.partain@ericsson.com> <1200559077.10666.26.camel@missotis> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 09:46:48 +0100 Message-Id: <1200559608.10666.30.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang Subject: [YANG] Re: Requirement question X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Sorry, I forgot to copy another chunk from Phils's example: Ladislav Lhotka p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 09:37 +0100: > YANG declaration (currently illegal): >=20 grouping endpoint { leaf address { type inet:address; } leaf port { type inet:port; } } > list flow { > key "source/address source/port > destination/address destination/port"; > container source { > use endpoint; > } > container destination { > use endpoint; > } > leaf packet-count { > type uint32; > } > } >=20 >=20 > Lada >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 03:54:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQVs-0004dr-SM; Thu, 17 Jan 2008 03:54:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFQVs-0004dl-E7 for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 03:54:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQVs-0004dd-46 for yang@ietf.org; Thu, 17 Jan 2008 03:54:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFQVq-0004dp-Cw for yang@ietf.org; Thu, 17 Jan 2008 03:54:16 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C172720FF1; Thu, 17 Jan 2008 09:54:13 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-df-478f17b5f056 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 92ED221330; Thu, 17 Jan 2008 09:54:13 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 09:54:13 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 09:54:13 +0100 Message-ID: <478F17B4.7060500@ericsson.com> Date: Thu, 17 Jan 2008 09:54:12 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] default values References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> In-Reply-To: <1200556619.10666.16.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 17 Jan 2008 08:54:13.0161 (UTC) FILETIME=[883EF990:01C858E6] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, I think you are arguing about different things. As I understand your comm= ents: Statement 1) says: defaults are important, so if we do have an agreed def= ault value, we should=20 document it in a proper, formal way. (I fully support this.) Statement 2) says: it is very difficult to agree on good default values s= o we should use=20 extreme caution specifying "mandatory" defaults in standards. I can agree= with that as well. We can still to define recommended-only defaults in the description state= ment if the default is=20 not obvious enough. The two statements do not contradict each other in my view. Also while it is difficult to define default values in standards, YANG an= d NETCONF will be used=20 a lot to define proprietary data models as well. It is much easier to def= ine defaults here, and=20 yes we do want a formal definition of these defaults (actually we already= have it in the=20 Ericsson-DML.) Balazs Ladislav Lhotka wrote: > Jon Saperia p=C3=AD=C5=A1e v St 16. 01. 2008 v 11:54 -0500: >=20 >> I understand your perspective but even though I said what I said, if = =20 >> we were to go down this path, defaults can be helpful. Any manager =20 >> that attempts the configuration function will have to be pretty =20 >> sophisticated because of the variability (even with standards) that =20 >> will be sure to exist. That does not mean that they will not do bad =20 >> things from time to time, but the market has a way of fixing things. >=20 > I am not against specifying defaults (reasonably), I only don't like th= e > fact that changing a default value implies a different data model. I > understand the data model primarily as a means for checking whether a > given document is valid or not and default values are irrelevant in thi= s > respect. It is already difficult to standardise the knobs and default > values are yet another level. >=20 > Lada >=20 >> /jon --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 04:48:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRLx-0007mu-LH; Thu, 17 Jan 2008 04:48:05 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFRLv-0007mk-U7 for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 04:48:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRLv-0007mY-HB for yang@ietf.org; Thu, 17 Jan 2008 04:48:03 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFRLu-0007fh-FC for yang@ietf.org; Thu, 17 Jan 2008 04:48:03 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F15CE20E77; Thu, 17 Jan 2008 10:48:00 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-8c-478f2450442c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B90F32104A; Thu, 17 Jan 2008 10:48:00 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 10:48:00 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 10:48:00 +0100 Message-ID: <478F244F.9020308@ericsson.com> Date: Thu, 17 Jan 2008 10:47:59 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] Underestimating the problem ([was something else]) References: <200801161908.m0GJ8mT8073099@idle.juniper.net> In-Reply-To: <200801161908.m0GJ8mT8073099@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2008 09:48:00.0396 (UTC) FILETIME=[0BD3F4C0:01C858EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, This is a VERY good mail about configuration management goals, thank you. I would like to add one point: - in my experience if the configuration is complex, the operator will make big mistakes in it, leading to system outage. So if it is too complex it is faulty even if it works. An operator (organization) can easily have 50 different types of nodes to handle, which might mean 2 completely different types per operator (person). For this reason he will often not be an expert in my specific node. According to a telecom industry survey about 50% of node downtime is attributable to operator errors. The node is too complex, so they make mistakes. And when I say too complex I am not just thinking about operators like Sprint or Uunet, but operators in Uganda and Laos. Balazs Phil Shafer wrote: > Andy Bierman writes: >> We will never have standard writable knobs until vendors understand >> the concept of a standard, and make an effort to define some >> standard knobs, which actually provide enough functionality >> to configure the device. > > If you are looking for a constant historical line of thought that > explains the failure of standardized configuration, look no further > than this line above. The "it's the vendor's fault" line has been > a constant albatross around such efforts. We are better off admitting > that the problem is not simple, and studying the factors that make > it difficult. Configuration is not simple and underestimating the > problem won't help standardization issues. > > In designing configuration for a complex device, you have a > number of goals: > > (a) avoid human error -- design the config to make errors > detectable in software, and observable in "show" output. > (b) be flexible -- customer deployment scenarios exceed your > vision when you design something. Allowing for these > cases is both important and painful. > (c) complexity reduction -- if it's complex to configure, it > won't get deployed. And if it does get deployed, the > support costs for both the customer and the vendor will > be high. > (d) details should be hidden where possible -- the user shouldn't > need to fully grok hardware, software, or protocol issues to > config them. > (e) enhancement/future proofing -- this config needs to work on > next year's hardware running next year's software, often > running next year's protocols. > (f) full feature support -- the config needs to fully represent > the available features your hardware and software support. > (g) got to be consistent -- make it fit inside the rules and > conventions of your existing syntax > (h) holistic view -- the config should look like a single description > of a complete system, not a dog's breakfast of tokens. > (i) I'm sure there's more..... > > In the fight for simplification, many of these goals cut against > each other. For example, in trying to be flexible, I have to decide > when an odd configuration is an error and when the user is just > doing something clever (which may be an error, but is an intentional > one). > > For standardization, the goals are often completely different. > Expressiveness and accuracy win over simplicity. A single complex > method of configuration wins over a dual "common" and "advanced" > approach. The model for a standard must be something that can > support all platforms, which leads to complexity, and the translation > between the standard's complex model and the unique abilities of > individual platforms is non-trivial. > > An example is packet filtering, where the device config is more > often dictated by the hardware architecture and the layout of that > hardware (in terms of where packets can be filtered, what can be > filtered on, what can be done to them at that layer, and what > resources are consumed) is often directly visible in the configuration > in order for the customer to express their desired setup. > > But a standard needs an "uber" model, where any sort of filtering > can be done at any place with any outcome without concern for > resource impact. No vendor will implement this model, and the > translation between the model and the device config requires a > strong understanding of the performance .vs. resource utilization > tradeoffs that the customer is willing to make. > > For example, some functionality may be available in hardware at > wire rate; other in hardware at lower speed; other in dedicated > CPUs; and still other in the main CPU. Choosing the proper filtering > point is a matter of both the speed and abilities of that point, > plus chip memory and other contention issues. And getting a correct > assignment will still be wrong if it's not the assignment the > customer wanted. > > This translation must be performed in a way that avoids letting > small changes in the config from turning into large config changes > on the device. It's not an easy problem, and to my mind it's the > key to device- independent configuration. > > The fact that my bgp configuration doesn't look like the bgp > mib shouldn't be surprising, since the two configurations > serve two different masters. The lack of any automated > translation between the two is the real killer. > > A key aspect of this translation is the ability to round-trip, > turning MIBs into device config and back in a way that doesn't > lose information. > > The problem isn't getting a few knobs to configure basic functionality, > but getting a solution that's complete enough to give folks sufficient > faith to move toward it. If it solved 20% of the problem, it's > worthless. When it solves 80-90% of the problem, it's interesting. > > NETCONF gives us the ability to manipulate configuration in XML, > which is a good first step. YANG gives us the ability to define > that XML in a way that allows extensibility and the expression of > device-specific content, which is a good second step. The next > step will be a translation framework that allows robust translation > between a standard view and a device specific view. > > So I think we are on the right road, although the pace of the journey > is disheartening. But regressing to this "it's the vendor's fault" > line is completely unproductive. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 05:29:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRzf-0008Gn-NR; Thu, 17 Jan 2008 05:29:07 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFRzd-0008GJ-Iw for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 05:29:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRzd-0008G4-6F for yang@ietf.org; Thu, 17 Jan 2008 05:29:05 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFRzc-0000Ug-Fd for yang@ietf.org; Thu, 17 Jan 2008 05:29:05 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 65ABCD800CC for ; Thu, 17 Jan 2008 11:29:03 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <478F17B4.7060500@ericsson.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 11:29:03 +0100 Message-Id: <1200565743.10666.64.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Balasz, in my view, the basic difference is this: Do we want to use (YANG or other) data models (i) for validating XML documents in the NETCONF context, or (ii) for specifying behaviour of network devices and/or management software? I am primarily interested in creating standard data models for (i) and concerned that pursuing (ii) might make the result unusable for (i). Note that the default statement makes sense only in (ii). Lada Balazs Lengyel p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 09:54 +0100: > Hello, > I think you are arguing about different things. As I understand your co= mments: > Statement 1) says: defaults are important, so if we do have an agreed d= efault value, we should=20 > document it in a proper, formal way. (I fully support this.) > Statement 2) says: it is very difficult to agree on good default values= so we should use=20 > extreme caution specifying "mandatory" defaults in standards. I can agr= ee with that as well. > We can still to define recommended-only defaults in the description sta= tement if the default is=20 > not obvious enough. >=20 > The two statements do not contradict each other in my view. >=20 > Also while it is difficult to define default values in standards, YANG = and NETCONF will be used=20 > a lot to define proprietary data models as well. It is much easier to d= efine defaults here, and=20 > yes we do want a formal definition of these defaults (actually we alrea= dy have it in the=20 > Ericsson-DML.) >=20 > Balazs >=20 >=20 > Ladislav Lhotka wrote: > > Jon Saperia p=C3=AD=C5=A1e v St 16. 01. 2008 v 11:54 -0500: > >=20 > >> I understand your perspective but even though I said what I said, i= f =20 > >> we were to go down this path, defaults can be helpful. Any manager = =20 > >> that attempts the configuration function will have to be pretty =20 > >> sophisticated because of the variability (even with standards) that = =20 > >> will be sure to exist. That does not mean that they will not do bad = =20 > >> things from time to time, but the market has a way of fixing things. > >=20 > > I am not against specifying defaults (reasonably), I only don't like = the > > fact that changing a default value implies a different data model. I > > understand the data model primarily as a means for checking whether a > > given document is valid or not and default values are irrelevant in t= his > > respect. It is already difficult to standardise the knobs and default > > values are yet another level. > >=20 > > Lada > >=20 > >> /jon >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 05:46:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFSGn-0006oz-5d; Thu, 17 Jan 2008 05:46:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFSGm-0006lL-1q for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 05:46:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFSGl-0006lB-Mw for yang@ietf.org; Thu, 17 Jan 2008 05:46:47 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFSGk-0001E2-W5 for yang@ietf.org; Thu, 17 Jan 2008 05:46:47 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CDA6121628; Thu, 17 Jan 2008 11:46:45 +0100 (CET) X-AuditID: c1b4fb3e-b16a4bb00000459d-76-478f321501e4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A43382156F; Thu, 17 Jan 2008 11:46:45 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 11:46:45 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 11:46:45 +0100 Message-ID: <478F3214.4070601@ericsson.com> Date: Thu, 17 Jan 2008 11:46:44 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] default values References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> In-Reply-To: <1200565743.10666.64.camel@missotis> Content-Type: text/plain; charset=utf-8; format=flowed X-OriginalArrivalTime: 17 Jan 2008 10:46:45.0423 (UTC) FILETIME=[40E863F0:01C858F6] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello Lada, I think (for Ericsson I know) we do NEED both i and ii; with all capital = letters really. E.g.=20 if we were just validating XML you could throw out - default - partly description - reference - revision - contact - organization maybe more. I don't see why the two aims are conflicting. Could you give me an exampl= e? Balazs However all this is needed Ladislav Lhotka wrote: > Hi Balasz, >=20 > in my view, the basic difference is this: >=20 > Do we want to use (YANG or other) data models > (i) for validating XML documents in the NETCONF context, or > (ii) for specifying behaviour of network devices and/or management > software? >=20 > I am primarily interested in creating standard data models for (i) and > concerned that pursuing (ii) might make the result unusable for (i). > Note that the default statement makes sense only in (ii). >=20 > Lada >=20 >=20 > Balazs Lengyel p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 09:54 +0100: >> Hello, >> I think you are arguing about different things. As I understand your c= omments: >> Statement 1) says: defaults are important, so if we do have an agreed = default value, we should=20 >> document it in a proper, formal way. (I fully support this.) >> Statement 2) says: it is very difficult to agree on good default value= s so we should use=20 >> extreme caution specifying "mandatory" defaults in standards. I can ag= ree with that as well. >> We can still to define recommended-only defaults in the description st= atement if the default is=20 >> not obvious enough. >> >> The two statements do not contradict each other in my view. >> >> Also while it is difficult to define default values in standards, YANG= and NETCONF will be used=20 >> a lot to define proprietary data models as well. It is much easier to = define defaults here, and=20 >> yes we do want a formal definition of these defaults (actually we alre= ady have it in the=20 >> Ericsson-DML.) >> >> Balazs >> >> >> Ladislav Lhotka wrote: >>> Jon Saperia p=C3=AD=C5=A1e v St 16. 01. 2008 v 11:54 -0500: >>> >>>> I understand your perspective but even though I said what I said, i= f =20 >>>> we were to go down this path, defaults can be helpful. Any manager = =20 >>>> that attempts the configuration function will have to be pretty =20 >>>> sophisticated because of the variability (even with standards) that = =20 >>>> will be sure to exist. That does not mean that they will not do bad = =20 >>>> things from time to time, but the market has a way of fixing things. >>> I am not against specifying defaults (reasonably), I only don't like = the >>> fact that changing a default value implies a different data model. I >>> understand the data model primarily as a means for checking whether a >>> given document is valid or not and default values are irrelevant in t= his >>> respect. It is already difficult to standardise the knobs and default >>> values are yet another level. >>> >>> Lada >>> >>>> /jon --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 06:27:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFSts-0007Ei-EY; Thu, 17 Jan 2008 06:27:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFStq-0007Eb-RH for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 06:27:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFStq-0007ET-Gm for yang@ietf.org; Thu, 17 Jan 2008 06:27:10 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFSto-00006Y-TG for yang@ietf.org; Thu, 17 Jan 2008 06:27:10 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7C268A3C8; Thu, 17 Jan 2008 12:27:07 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13709-06; Thu, 17 Jan 2008 12:27:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73AF38A38B; Thu, 17 Jan 2008 12:27:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D766F468CDC; Thu, 17 Jan 2008 12:27:02 +0100 (CET) Date: Thu, 17 Jan 2008 12:27:02 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] default values Message-ID: <20080117112702.GA29235@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1200565743.10666.64.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 17, 2008 at 11:29:03AM +0100, Ladislav Lhotka wrote: > Do we want to use (YANG or other) data models > (i) for validating XML documents in the NETCONF context, or > (ii) for specifying behaviour of network devices and/or management > software? I have no clue what you mean with "validating XML documents in the NETCONF context". I believe the real meat is in validating configurations, not so much the XML serialization of (fragments of) configurations exchanged in NETCONF messages. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 06:36:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFT2s-0008Ld-Tw; Thu, 17 Jan 2008 06:36:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFT2s-0008H7-1W for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 06:36:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFT2r-0008Gq-Km for yang@ietf.org; Thu, 17 Jan 2008 06:36:29 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFT2r-0002lM-4t for yang@ietf.org; Thu, 17 Jan 2008 06:36:29 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8227821777; Thu, 17 Jan 2008 12:35:12 +0100 (CET) X-AuditID: c1b4fb3e-aee9fbb00000459d-cc-478f3d702de4 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5A89921785; Thu, 17 Jan 2008 12:35:12 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 12:35:11 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 12:35:11 +0100 Message-ID: <478F3D6C.5010906@ericsson.com> Date: Thu, 17 Jan 2008 12:35:08 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka , yang Subject: Re: [YANG] default values References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <478F3214.4070601@ericsson.com> <1200567879.10666.79.camel@missotis> In-Reply-To: <1200567879.10666.79.camel@missotis> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2008 11:35:11.0607 (UTC) FILETIME=[0520E070:01C858FD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Assume there is a standard data model urn:ietf:X and a vendor that is > essentially happy with it, but in their device they want to change a > certain default value specified in the model. So they are forced to use > another model, say, urn:vendor:Y. A NETCONF manager that uses urn:ietf:X > should in principle be able to interoperate smoothly with the device but > refuses to establish a session because of unknown capability. > > If the model did not specify the behaviour of the device, the vendor > could use it directly. > > Lada This only means that the standard body for that particular protocol was not careful enough when choosing the default value. Maybe it should have chosen a "SHOULD" type of default that is not formally specified in the default statement just included in the description statement. YANG gives you the possibility to enforce a default. It just gives you this as an option, that you might or might not use. Balazs _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 07:07:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFTWo-0005n9-Gu; Thu, 17 Jan 2008 07:07:26 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFTWn-0005iE-Gt for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 07:07:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFTWn-0005i6-3w for yang@ietf.org; Thu, 17 Jan 2008 07:07:25 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFTWm-0003X3-Nm for yang@ietf.org; Thu, 17 Jan 2008 07:07:25 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 48817D800CB for ; Thu, 17 Jan 2008 13:07:24 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080117112702.GA29235@elstar.local> References: <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 13:07:24 +0100 Message-Id: <1200571644.10666.91.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 12:27 +0100= : > On Thu, Jan 17, 2008 at 11:29:03AM +0100, Ladislav Lhotka wrote: > =20 > > Do we want to use (YANG or other) data models > > (i) for validating XML documents in the NETCONF context, or > > (ii) for specifying behaviour of network devices and/or management > > software? >=20 > I have no clue what you mean with "validating XML documents in the > NETCONF context". The NETCONF messages exchanged between the server and client are serialised XML and validation means that the other side is able to tell whether the received data are legal. It's not so important whether you perform this check on the serialised XML, DOM tree or otherwise. YANG draft always speaks about XML representations and nothing else. >=20 > I believe the real meat is in validating configurations, not so much > the XML serialization of (fragments of) configurations exchanged in > NETCONF messages. I agree, yet even in this case the distinction between (i) and (ii) holds, after changing "XML documents" to "configuration data". Lada >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 07:16:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFTft-0007Kp-F5; Thu, 17 Jan 2008 07:16:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFTfs-0007Ki-HS for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 07:16:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFTfr-0007KV-Rs for yang@ietf.org; Thu, 17 Jan 2008 07:16:47 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFTfr-0003pV-Eo for yang@ietf.org; Thu, 17 Jan 2008 07:16:47 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 126C9D800BD for ; Thu, 17 Jan 2008 13:16:47 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <478F3D6C.5010906@ericsson.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <478F3214.4070601@ericsson.com> <1200567879.10666.79.camel@missotis> <478F3D6C.5010906@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 13:16:47 +0100 Message-Id: <1200572207.10666.94.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 12:35 +0100: >=20 > Ladislav Lhotka wrote: > > Assume there is a standard data model urn:ietf:X and a vendor that is > > essentially happy with it, but in their device they want to change a > > certain default value specified in the model. So they are forced to u= se > > another model, say, urn:vendor:Y. A NETCONF manager that uses urn:iet= f:X > > should in principle be able to interoperate smoothly with the device = but > > refuses to establish a session because of unknown capability. > >=20 > > If the model did not specify the behaviour of the device, the vendor > > could use it directly. > >=20 > > Lada > This only means that the standard body for that particular protocol was= not careful enough when=20 > choosing the default value. Maybe it should have chosen a "SHOULD" type= of default that is not=20 > formally specified in the default statement just included in the descri= ption statement. >=20 > YANG gives you the possibility to enforce a default. It just gives you = this as an option, that=20 > you might or might not use. Do you believe there is no politics involved in the standardisation process? I don't. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 07:42:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFU4a-0003kb-8N; Thu, 17 Jan 2008 07:42:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFU4Y-0003kW-Oi for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 07:42:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFU4Y-0003kO-Bo for yang@ietf.org; Thu, 17 Jan 2008 07:42:18 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFU4W-0001VZ-Q2 for yang@ietf.org; Thu, 17 Jan 2008 07:42:18 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B538FD800CA for ; Thu, 17 Jan 2008 13:42:13 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <478F3214.4070601@ericsson.com> References: <1200478981.7029.27.camel@missotis> <20080116.123549.140000433.mbj@tail-f.com> <1200487153.7029.71.camel@missotis> <478E0FCD.6080908@andybierman.com> <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <478F3214.4070601@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 13:42:13 +0100 Message-Id: <1200573734.10666.111.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 11:46 +0100: > Hello Lada, > I think (for Ericsson I know) we do NEED both i and ii; with all capita= l letters really. E.g. Fine, it could also be done in separate steps. The approach I use takes RELAX NG together with various extensions (in different namespaces) that serve the different purposes. Only the RELAX NG part together with a subset of the extensions are used for validating configuration data while other extensions specify behaviour of the device (including defaults), annotations etc. > if we were just validating XML you could throw out > - default Yes, I'd like to :-) > - partly description > - reference > - revision > - contact > - organization Well, not necessarily, I consider these items informational (the data model remains the same if they are changed). Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 08:58:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFVFQ-0001sq-2v; Thu, 17 Jan 2008 08:57:36 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFVFO-0001sW-Jp for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 08:57:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFVFO-0001rg-6p for yang@ietf.org; Thu, 17 Jan 2008 08:57:34 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFVFL-0006kU-FJ for yang@ietf.org; Thu, 17 Jan 2008 08:57:31 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B7578A270; Thu, 17 Jan 2008 14:57:30 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28441-09; Thu, 17 Jan 2008 14:57:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0B718A39A; Thu, 17 Jan 2008 14:57:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 29755468ED0; Thu, 17 Jan 2008 14:57:24 +0100 (CET) Date: Thu, 17 Jan 2008 14:57:24 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] default values Message-ID: <20080117135724.GC29301@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1200571644.10666.91.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 17, 2008 at 01:07:24PM +0100, Ladislav Lhotka wrote: > > I have no clue what you mean with "validating XML documents in the > > NETCONF context". > > The NETCONF messages exchanged between the server and client are > serialised XML and validation means that the other side is able to tell > whether the received data are legal. It's not so important whether you > perform this check on the serialised XML, DOM tree or otherwise. YANG > draft always speaks about XML representations and nothing else. No, you are missing an important piece. While an XML fragment shipped in a NETCONF message may be valid, it might not lead to a valid configuration. I don't think it is true that the YANG draft "always speaks about XML representations and nothing else". Regarding defaults, the question boils down to whether a NETCONF client can assume that specified defaults are used or whether to be on the safe side the client has to either set defaults itself or check what was set by the server. The alternative would be to have a mechanism allowing implementations to post the defaults they are going to use rather than hard wiring defaults in the specification. So a vendor can augment a standard with the defaults that the vendor's implementation is using. This surely adds some complexity. An even further reaching mechanism would be to make the defaults being used by an implementation itself writable, e.g. by introducing a template mechanism which adds defaults for stuff not defined explicitely by a NETCONF client. Our goal was to start with something simple, allowing us to add more powerful mechanism via extensions over time once we see that they are really needed (that is there is enough uptake of NETCONF / YANG). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 10:02:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWFk-0007kd-RH; Thu, 17 Jan 2008 10:02:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFWFk-0007kX-0D for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 10:02:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWFj-0007kP-M0 for yang@ietf.org; Thu, 17 Jan 2008 10:01:59 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFWFj-00037o-8l for yang@ietf.org; Thu, 17 Jan 2008 10:01:59 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 992B6D800D3 for ; Thu, 17 Jan 2008 16:01:58 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080117135724.GC29301@elstar.local> References: <1200493871.7029.137.camel@missotis> <478E1EF4.4050002@andybierman.com> <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 16:01:50 +0100 Message-Id: <1200582110.19372.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 14:57 +0100= : > Regarding defaults, the question boils down to whether a NETCONF > client can assume that specified defaults are used or whether to be on > the safe side the client has to either set defaults itself or check > what was set by the server. At the start of a NETCONF session, the values in the running/startup/whatever configuration may be different even if the server's factory defaults follow the standards. The client can't IMO safely avoid checking or setting all variables in server's configuration.=20 >=20 > The alternative would be to have a mechanism allowing implementations > to post the defaults they are going to use rather than hard wiring > defaults in the specification. So a vendor can augment a standard with > the defaults that the vendor's implementation is using. This surely > adds some complexity. An even further reaching mechanism would be to > make the defaults being used by an implementation itself writable, > e.g. by introducing a template mechanism which adds defaults for stuff > not defined explicitely by a NETCONF client. >=20 > Our goal was to start with something simple, allowing us to add more > powerful mechanism via extensions over time once we see that they are > really needed (that is there is enough uptake of NETCONF / YANG). I think this applies to the default statement, too. I am arguing it's not needed for NETCONF operation and may complicate things. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 10:22:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWZP-0002ou-Cc; Thu, 17 Jan 2008 10:22:19 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFWZO-0002op-4O for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 10:22:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWZN-0002oh-Qp for yang@ietf.org; Thu, 17 Jan 2008 10:22:17 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFWZL-0006O0-Ci for yang@ietf.org; Thu, 17 Jan 2008 10:22:17 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C14198A3C5; Thu, 17 Jan 2008 16:22:14 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04510-07-9; Thu, 17 Jan 2008 16:22:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F19D8A2DD; Thu, 17 Jan 2008 16:22:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0D0E4468FE9; Thu, 17 Jan 2008 16:22:01 +0100 (CET) Date: Thu, 17 Jan 2008 16:22:00 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] default values Message-ID: <20080117152200.GA29447@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1200582110.19372.43.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 17, 2008 at 04:01:50PM +0100, Ladislav Lhotka wrote: > At the start of a NETCONF session, the values in the > running/startup/whatever configuration may be different even if the > server's factory defaults follow the standards. The client can't IMO > safely avoid checking or setting all variables in server's > configuration. Sure. But when I create something new without specifying all defaults, do I know what I get? In SNMP, you don't. In YANG, you do. > > > > The alternative would be to have a mechanism allowing implementations > > to post the defaults they are going to use rather than hard wiring > > defaults in the specification. So a vendor can augment a standard with > > the defaults that the vendor's implementation is using. This surely > > adds some complexity. An even further reaching mechanism would be to > > make the defaults being used by an implementation itself writable, > > e.g. by introducing a template mechanism which adds defaults for stuff > > not defined explicitely by a NETCONF client. > > > > Our goal was to start with something simple, allowing us to add more > > powerful mechanism via extensions over time once we see that they are > > really needed (that is there is enough uptake of NETCONF / YANG). > > I think this applies to the default statement, too. I am arguing it's > not needed for NETCONF operation and may complicate things. So if I understand right, your proposal is to remove the default statement, not to change its semantics, correct? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 10:42:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWt7-00078m-UT; Thu, 17 Jan 2008 10:42:41 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFWt6-00078Y-FV for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 10:42:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWt6-00078Q-5l for yang@ietf.org; Thu, 17 Jan 2008 10:42:40 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFWt5-0006lg-Mi for yang@ietf.org; Thu, 17 Jan 2008 10:42:40 -0500 Received: (qmail 41571 invoked from network); 17 Jan 2008 15:42:39 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 17 Jan 2008 15:42:38 -0000 X-YMail-OSG: 04.MjakVM1k4FkcxNDKmkZSxJVsHcGfVSYl_ictyqjBhNluA X-Yahoo-Newman-Property: ymail-3 Message-ID: <478F7766.4080905@andybierman.com> Date: Thu, 17 Jan 2008 07:42:30 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ladislav Lhotka , yang@ietf.org Subject: Re: [YANG] default values References: <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis> <20080117152200.GA29447@elstar.local> In-Reply-To: <20080117152200.GA29447@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Jan 17, 2008 at 04:01:50PM +0100, Ladislav Lhotka wrote: > >> At the start of a NETCONF session, the values in the >> running/startup/whatever configuration may be different even if the >> server's factory defaults follow the standards. The client can't IMO >> safely avoid checking or setting all variables in server's >> configuration. > > Sure. But when I create something new without specifying all defaults, > do I know what I get? In SNMP, you don't. In YANG, you do. > >>> The alternative would be to have a mechanism allowing implementations >>> to post the defaults they are going to use rather than hard wiring >>> defaults in the specification. So a vendor can augment a standard with >>> the defaults that the vendor's implementation is using. This surely >>> adds some complexity. An even further reaching mechanism would be to >>> make the defaults being used by an implementation itself writable, >>> e.g. by introducing a template mechanism which adds defaults for stuff >>> not defined explicitely by a NETCONF client. >>> >>> Our goal was to start with something simple, allowing us to add more >>> powerful mechanism via extensions over time once we see that they are >>> really needed (that is there is enough uptake of NETCONF / YANG). >> I think this applies to the default statement, too. I am arguing it's >> not needed for NETCONF operation and may complicate things. > > So if I understand right, your proposal is to remove the default > statement, not to change its semantics, correct? > I strongly object to removing the default-stmt. As Balazs pointed out, if a WG does not agree on a suitable default value, they do not have to define one. This clause is needed to support NETCONF, not only to provide as much machine-readable info about the data model characteristics, but to simplify NETCONF tasks for operators and applications. There are likely to be many knobs in a real config file that are optional and have suitable agent-supplied default values. It is very useful for operators and applications to know this information. There are some cases where the agent implementation varies from the data model specification. This does not mean we should throw out 'default'. It means we need to address agent conformance and agent capabilities (Something YANG ignores completely right now.) > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 11:19:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXTA-0004IX-LM; Thu, 17 Jan 2008 11:19:56 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFXT9-0004IP-GW for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 11:19:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXT8-0004IC-T8 for yang@ietf.org; Thu, 17 Jan 2008 11:19:54 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFXT8-00054K-Gj for yang@ietf.org; Thu, 17 Jan 2008 11:19:54 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B3AEBD800BD; Thu, 17 Jan 2008 17:19:49 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080117152200.GA29447@elstar.local> References: <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis> <20080117152200.GA29447@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 17:19:50 +0100 Message-Id: <1200586790.19372.77.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 16:22 +0100= : > On Thu, Jan 17, 2008 at 04:01:50PM +0100, Ladislav Lhotka wrote: > =20 > > At the start of a NETCONF session, the values in the > > running/startup/whatever configuration may be different even if the > > server's factory defaults follow the standards. The client can't IMO > > safely avoid checking or setting all variables in server's > > configuration. >=20 > Sure. But when I create something new without specifying all defaults, > do I know what I get? In SNMP, you don't. In YANG, you do. It depends on what that something is: Manager front ends can certainly save the user from seeing/specifying configuration variables with default values (and these needn't be only "MUST" ones, see most CLIs) but in get-config and edit-config messages I'd prefer not to rely on the other end to interpret the missing values as defaults. If this is ensured, the server and client may use different sets of defaults without any risk of confusion.=20 =20 >=20 > So if I understand right, your proposal is to remove the default > statement, not to change its semantics, correct? Yes. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 11:57:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFY3D-0000i4-PK; Thu, 17 Jan 2008 11:57:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFY3C-0000hr-Du for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 11:57:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFY3C-0000hb-3a for yang@ietf.org; Thu, 17 Jan 2008 11:57:10 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFY3B-00066y-O4 for yang@ietf.org; Thu, 17 Jan 2008 11:57:10 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 50A39D800C5; Thu, 17 Jan 2008 17:57:09 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <478F7766.4080905@andybierman.com> References: <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis> <20080117152200.GA29447@elstar.local> <478F7766.4080905@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 17 Jan 2008 17:57:09 +0100 Message-Id: <1200589029.19372.100.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v =C4=8Ct 17. 01. 2008 v 07:42 -0800: > I strongly object to removing the default-stmt. > As Balazs pointed out, if a WG does not agree on a suitable > default value, they do not have to define one. This clause > is needed to support NETCONF, not only to provide as much > machine-readable info about the data model characteristics, > but to simplify NETCONF tasks for operators and applications. Operators should only be concerned with the defaults used by their front ends - and these would typically include much more than just the MUST defaults that YANG can handle. >=20 > There are likely to be many knobs in a real config file that are option= al > and have suitable agent-supplied default values. It is very useful How many of them could possibly be of the MUST sort? I don't know many. The default is a weak concept, it's not like a fixed constant. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 13:06:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFZ8h-0002ar-52; Thu, 17 Jan 2008 13:06:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFZ8g-0002XB-E3 for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 13:06:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFZ8g-0002TY-1k for yang@ietf.org; Thu, 17 Jan 2008 13:06:54 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFZ8d-00085V-Ij for yang@ietf.org; Thu, 17 Jan 2008 13:06:51 -0500 Received: (qmail 65707 invoked from network); 17 Jan 2008 18:06:50 -0000 Received: from unknown (HELO andrew-biermans-computer.local) (andybierman@att.net@67.126.240.103 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 17 Jan 2008 18:06:50 -0000 X-YMail-OSG: tCMGmaIVM1kPcC4umdI_FV5GiWhASRzZta9DYRGXxIecpPAn X-Yahoo-Newman-Property: ymail-3 Message-ID: <478F9A7D.2070704@andybierman.com> Date: Thu, 17 Jan 2008 10:12:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] default values References: <1200501131.7029.151.camel@missotis> <49B89097-B9C1-44FE-A59E-FA12B2D546F2@jdscons.com> <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis> <20080117152200.GA29447@elstar.local> <478F7766.4080905@andybierman.com> <1200589029.19372.100.camel@missotis> In-Reply-To: <1200589029.19372.100.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Andy Bierman píše v Čt 17. 01. 2008 v 07:42 -0800: > >> I strongly object to removing the default-stmt. >> As Balazs pointed out, if a WG does not agree on a suitable >> default value, they do not have to define one. This clause >> is needed to support NETCONF, not only to provide as much >> machine-readable info about the data model characteristics, >> but to simplify NETCONF tasks for operators and applications. >> > > Operators should only be concerned with the defaults used by their front > ends - and these would typically include much more than just the MUST > defaults that YANG can handle. > > Many operators want to know how to control the NE devices in their network without relying on any magic 'front-end' that always knows what values work on any given device. NETCONF is designed to work, even if all the operator has is 'ssh -s netconf -p 830' for access to the NETCONF agent. >> There are likely to be many knobs in a real config file that are optional >> and have suitable agent-supplied default values. It is very useful >> > > How many of them could possibly be of the MUST sort? I don't know many. > The default is a weak concept, it's not like a fixed constant. > > I disagree. First, it is up to the protocol WG defining the knob, not the YANG WG. Given that the protocol could define a range of compliant values for a standard knob, it is one extra step to pick 1 of the compliant values as the default. A trivial example is a boolean knob (or presence container in YANG) that represents some service or feature, and the WG agrees it is 'off' by default. > Lada > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 15:45:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbc9-00050O-Kr; Thu, 17 Jan 2008 15:45:29 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFbc7-0004rp-SH for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 15:45:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbc7-0004rh-Hp for yang@ietf.org; Thu, 17 Jan 2008 15:45:27 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFbc7-0005AO-1m for yang@ietf.org; Thu, 17 Jan 2008 15:45:27 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id AAA461B80C3; Thu, 17 Jan 2008 21:45:24 +0100 (CET) Date: Thu, 17 Jan 2008 21:44:11 +0100 (CET) Message-Id: <20080117.214411.158582244.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] default values From: Martin Bjorklund In-Reply-To: <478F9A7D.2070704@andybierman.com> References: <478F7766.4080905@andybierman.com> <1200589029.19372.100.camel@missotis> <478F9A7D.2070704@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Andy Bierman wrote: > A trivial example is a boolean knob (or presence container in YANG) > that represents some service or feature, and the WG agrees it is 'off' > by default. This is an interesting example, but currently YANG does not support this use case, i.e. marking a presence container as present by default. Is that something we should add? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 15:56:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbmw-00051P-81; Thu, 17 Jan 2008 15:56:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFbmu-00051J-Jy for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 15:56:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbmu-000513-9v for yang@ietf.org; Thu, 17 Jan 2008 15:56:36 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFbmt-00067y-Q9 for yang@ietf.org; Thu, 17 Jan 2008 15:56:36 -0500 Received: (qmail 23825 invoked from network); 17 Jan 2008 20:56:32 -0000 Received: from unknown (HELO andrew-biermans-computer.local) (andybierman@att.net@67.126.240.103 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 17 Jan 2008 20:56:31 -0000 X-YMail-OSG: NECVfmMVM1lHUUXLjh2awLZXi5c.4g_2XwLm0Tl4C2KWIFmj X-Yahoo-Newman-Property: ymail-3 Message-ID: <478FC242.2040204@andybierman.com> Date: Thu, 17 Jan 2008 13:01:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] default values References: <478F7766.4080905@andybierman.com> <1200589029.19372.100.camel@missotis> <478F9A7D.2070704@andybierman.com> <20080117.214411.158582244.mbj@tail-f.com> In-Reply-To: <20080117.214411.158582244.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > >> A trivial example is a boolean knob (or presence container in YANG) >> that represents some service or feature, and the WG agrees it is 'off' >> by default. >> > > This is an interesting example, but currently YANG does not support > this use case, i.e. marking a presence container as present by > default. Is that something we should add? > What does it mean wrt/ the child nodes of the container if the default present flag is set to true? Isn't the container created by default if it has any child nodes with defaults? If this flag=FALSE, does that change? This new feature would allow the container to be created even if it has no child nodes with defaults? Can this be turned on/off with a container refinement statement (in a uses-stmt)? > > /martin > > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 16:11:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFc12-0004nx-C6; Thu, 17 Jan 2008 16:11:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFc10-0004nP-FD for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 16:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFc10-0004nH-52 for yang@ietf.org; Thu, 17 Jan 2008 16:11:10 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFc0x-0006Py-7g for yang@ietf.org; Thu, 17 Jan 2008 16:11:09 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 850061B80C3; Thu, 17 Jan 2008 22:11:06 +0100 (CET) Date: Thu, 17 Jan 2008 22:09:53 +0100 (CET) Message-Id: <20080117.220953.230961711.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] default values From: Martin Bjorklund In-Reply-To: <478FC242.2040204@andybierman.com> References: <478F9A7D.2070704@andybierman.com> <20080117.214411.158582244.mbj@tail-f.com> <478FC242.2040204@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > > > >> A trivial example is a boolean knob (or presence container in YANG) > >> that represents some service or feature, and the WG agrees it is 'off' > >> by default. > >> > > > > This is an interesting example, but currently YANG does not support > > this use case, i.e. marking a presence container as present by > > default. Is that something we should add? > > > > What does it mean wrt/ the child nodes of the container > if the default present flag is set to true? ^^^^^^^^^^^^^^^^^^^^ What is that? > Isn't the container created by default if it has any child nodes with > defaults? If this flag=FALSE, does that change? A normal structural container (with no presence statement) behaves like that, except that it seems to be a meta-physical question whether the container really is created or not ;-) > This new feature would allow the container to be created even if > it has no child nodes with defaults? Currently, it cannot be defined in the data model if a presence container gets created by default or not. So if you do: container foo { presence "turns on the foo protocol"; leaf bar { type int32; default 42; } } Then it is not defined if foo exists or not (when it's parent gets created). If it exists, foo/bar has the value of 42 by default. At least we should clarify this in the draft, e.g. by saying that a presence container is not created by default. That means that the manager knows which behavior to expect. Or we could add a new statement to control this. > Can this be turned on/off with a container refinement statement (in a > uses-stmt)? If we add such a statement, yes I think it could be refined, just like defaults for leafs. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 17 22:01:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFhTz-0005Nv-9n; Thu, 17 Jan 2008 22:01:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFhTx-0005Nl-W1 for yang-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 22:01:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFhTx-0005Nd-K0 for yang@ietf.org; Thu, 17 Jan 2008 22:01:25 -0500 Received: from exprod7og105.obsmtp.com ([64.18.2.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFhTx-0004w0-5V for yang@ietf.org; Thu, 17 Jan 2008 22:01:25 -0500 Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 17 Jan 2008 19:00:27 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jan 2008 19:00:50 -0800 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 m0I30n929288; Thu, 17 Jan 2008 19:00:50 -0800 (PST) (envelope-from phil@idle.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 m0I30a7g007182; Fri, 18 Jan 2008 03:00:36 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801180300.m0I30a7g007182@idle.juniper.net> To: Martin Bjorklund Subject: Re: [YANG] default values In-reply-to: <20080117.214411.158582244.mbj@tail-f.com> Date: Thu, 17 Jan 2008 22:00:36 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Jan 2008 03:00:50.0724 (UTC) FILETIME=[55059640:01C8597E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund writes: >This is an interesting example, but currently YANG does not support >this use case, i.e. marking a presence container as present by >default. Is that something we should add? This would be confusing and probably broken. If it's "present" by default, why have it and how do you turn it off? You can't delete it, since it comes right back, so you can't turn it off. So what's the point of giving it a "presence"? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 04:22:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnQF-0003pa-QW; Fri, 18 Jan 2008 04:21:59 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFnQD-0003mS-Ry for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 04:21:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnQ7-0003gV-5y for yang@ietf.org; Fri, 18 Jan 2008 04:21:51 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFnQ5-0002PZ-JJ for yang@ietf.org; Fri, 18 Jan 2008 04:21:51 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CADB321021; Fri, 18 Jan 2008 10:21:48 +0100 (CET) X-AuditID: c1b4fb3e-abdeabb0000007e1-1e-47906facaa61 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B0DB4200FD; Fri, 18 Jan 2008 10:21:48 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:21:48 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:21:48 +0100 Message-ID: <47906FAB.2060505@ericsson.com> Date: Fri, 18 Jan 2008 10:21:47 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] default values References: <200801180300.m0I30a7g007182@idle.juniper.net> In-Reply-To: <200801180300.m0I30a7g007182@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2008 09:21:48.0096 (UTC) FILETIME=[8D13C400:01C859B3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, Why would the presence container come back automatically? There's today no text in the draft, that says presence containers are automatically removed or created. The draft says "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." Actually we failed to state what happens, if we later explicitly delete a leaf with a default value. In my view if the user wants to delete it then it should go away; no value present any more. One more thing I think is still missing from the draft, is whether must expressions consider default values or not? Balazs Phil Shafer wrote: > Martin Bjorklund writes: >> This is an interesting example, but currently YANG does not support >> this use case, i.e. marking a presence container as present by >> default. Is that something we should add? > > This would be confusing and probably broken. If it's "present" > by default, why have it and how do you turn it off? You can't > delete it, since it comes right back, so you can't turn it off. > So what's the point of giving it a "presence"? > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 04:45:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnmg-0002yi-OR; Fri, 18 Jan 2008 04:45:10 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFnmf-0002yc-0S for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 04:45:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnmd-0002yS-Sq for yang@ietf.org; Fri, 18 Jan 2008 04:45:08 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFnmc-0005uR-Ie for yang@ietf.org; Fri, 18 Jan 2008 04:45:07 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUU000UC31U0W@szxga01-in.huawei.com> for yang@ietf.org; Fri, 18 Jan 2008 17:44:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUU00GCA31SI4@szxga01-in.huawei.com> for yang@ietf.org; Fri, 18 Jan 2008 17:44:18 +0800 (CST) Received: from l48181 ([10.111.12.236]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUU000CG31RXQ@szxml03-in.huawei.com> for yang@ietf.org; Fri, 18 Jan 2008 17:44:16 +0800 (CST) Date: Fri, 18 Jan 2008 17:44:15 +0800 From: Li Yan To: 'yang' Message-id: <000001c859b6$b0626ee0$ec0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchZtq9XRXpTpeGMTK6EexQiTbVNhQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: c9f32637d681d0f0b9116f923e25825c Subject: [YANG] Questions about submodule X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1088315560==" Errors-To: yang-bounces@ietf.org This is a multi-part message in MIME format. --===============1088315560== Content-type: multipart/alternative; boundary="Boundary_(ID_rKfL11Fo/2KS7s9Dpw82EA)" This is a multi-part message in MIME format. --Boundary_(ID_rKfL11Fo/2KS7s9Dpw82EA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, o Sec 7.2.1 tells me that the "submodule" statement can contain the "include" statement. Does it imply that a submodule can be split further into multiple submodules, and the separation is recursive? I think splitting submodule would complicate the relationship between submodules, and is not useful. o A typo question The following examples are from sec 7.1.10 and 7.2.3 respectively. I am confused if the module/submodule name should be quoted. module acme-system { . include acme-types; //no quotes . } submodule acme-types { belongs-to "acme-system"; //in quotes . } Yan --Boundary_(ID_rKfL11Fo/2KS7s9Dpw82EA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

o Sec 7.2.1 tells me that the "submodule" statement can contain the “include” statement.

Does it imply that a submodule can be split further into multiple submodules, and the separation is recursive?

I think splitting submodule would complicate the relationship between submodules, and is not useful.

 

o A typo question

The following examples are from sec 7.1.10 and 7.2.3 respectively. I am confused if the module/submodule name should be quoted.

module acme-system {

    …

    include acme-types;  //no quotes

    …

}

submodule acme-types {

    belongs-to "acme-system";  //in quotes

…

}

 

Yan

--Boundary_(ID_rKfL11Fo/2KS7s9Dpw82EA)-- --===============1088315560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1088315560==-- From yang-bounces@ietf.org Fri Jan 18 05:13:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoEY-0007vi-Bh; Fri, 18 Jan 2008 05:13:59 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFoEX-0007vZ-3i for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 05:13:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoEW-0007vR-G2 for yang@ietf.org; Fri, 18 Jan 2008 05:13:56 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFoEW-0006rB-2S for yang@ietf.org; Fri, 18 Jan 2008 05:13:56 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id AC3B41B80C9; Fri, 18 Jan 2008 11:13:54 +0100 (CET) Date: Fri, 18 Jan 2008 11:15:05 +0100 (CET) Message-Id: <20080118.111505.89141499.mbj@tail-f.com> To: liyan_77@huawei.com Subject: Re: [YANG] Questions about submodule From: Martin Bjorklund In-Reply-To: <000001c859b6$b0626ee0$ec0c6f0a@china.huawei.com> References: <000001c859b6$b0626ee0$ec0c6f0a@china.huawei.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Yan, Li Yan wrote: > Hi, > > o Sec 7.2.1 tells me that the "submodule" statement can contain the > "include" statement. > > Does it imply that a submodule can be split further into multiple > submodules, and the separation is recursive? Yes. One use case for letting a submodule include another one is when you split a larger module into submodules, and you want a submodule with common types: main-module: includes sub-a, sub-b, sub-common-types sub-a: includes sub-common-types sub-b: includes sub-common-types > I think splitting submodule would complicate the relationship between > submodules, and is not useful. In larger projects, this might actually be useful. Instead of having one big centralized module, we allow people to split the task into submodules. If the submodule becomes big enough, it might be useful to split it into other submodules. Even though I cannot see that 100 levels are ever used, I don't think we should add a rule which says that you cannot nest more than 99 levels. > o A typo question > > The following examples are from sec 7.1.10 and 7.2.3 respectively. I am > confused if the module/submodule name should be quoted. > > module acme-system { > > . > > include acme-types; //no quotes > > . > > } > > submodule acme-types { > > belongs-to "acme-system"; //in quotes > > . > > } The argument to a statement is always a string. Quotes MUST be used if the string contains whitespaces etc, ane MAY be used otherwise (see 6.1.2 and 6.1.3). So the examples above are both correct. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 05:15:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoG0-0001fB-9D; Fri, 18 Jan 2008 05:15:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFoFz-0001f6-AU for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 05:15:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoFy-0001ey-Vc for yang@ietf.org; Fri, 18 Jan 2008 05:15:27 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFoFy-0006t8-C6 for yang@ietf.org; Fri, 18 Jan 2008 05:15:26 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE5A320472; Fri, 18 Jan 2008 11:15:25 +0100 (CET) X-AuditID: c1b4fb3e-ad5edbb0000007e1-ee-47907c3d8588 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ACDFE203E6; Fri, 18 Jan 2008 11:15:25 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 11:15:25 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 11:15:25 +0100 Message-ID: <47907C3C.1000309@ericsson.com> Date: Fri, 18 Jan 2008 11:15:24 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Li Yan Subject: Re: [YANG] Questions about submodule References: <000001c859b6$b0626ee0$ec0c6f0a@china.huawei.com> In-Reply-To: <000001c859b6$b0626ee0$ec0c6f0a@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 18 Jan 2008 10:15:25.0070 (UTC) FILETIME=[0A8B0AE0:01C859BB] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'yang' X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello Yan, See below! Li Yan wrote: > Hi, >=20 > o Sec 7.2.1 tells me that the "submodule" statement can contain the=20 > =93include=94 statement. >=20 > Does it imply that a submodule can be split further into multiple=20 > submodules, and the separation is recursive? [BALAZS]: Yes you can move parts of a sub-module into sub-sub-module. Cur= rently there is no=20 limit on the depth of such splitting. For big projects/module this is han= dy. I don't exactly=20 understand what you mean by recursive. >=20 > I think splitting submodule would complicate the relationship between=20 > submodules, and is not useful. >=20 > =20 >=20 > o A typo question >=20 > The following examples are from sec 7.1.10 and 7.2.3 respectively. I am= =20 > confused if the module/submodule name should be quoted. >=20 > module acme-system { >=20 > include acme-types; //no quotes >=20 > submodule acme-types { >=20 > belongs-to "acme-system"; //in quotes >=20 [BALAZS]: Quoting is not needed here, but allowed. From the draft: "If a string contains any whitespace characters, a semicolon (";"), curly= braces ("{ }"), or=20 comment sequences ("//", "/*", or "*/"), then it MUST be enclosed within = double or single quotes." regards Balazs --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 05:36:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoaN-0004bm-1w; Fri, 18 Jan 2008 05:36:31 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFoaK-0004Zv-QE for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 05:36:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoaK-0004Zn-G7 for yang@ietf.org; Fri, 18 Jan 2008 05:36:28 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFoaH-0004NG-85 for yang@ietf.org; Fri, 18 Jan 2008 05:36:28 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUU00DTO56LJJ@szxga02-in.huawei.com> for yang@ietf.org; Fri, 18 Jan 2008 18:30:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUU000HH56JOG@szxga02-in.huawei.com> for yang@ietf.org; Fri, 18 Jan 2008 18:30:21 +0800 (CST) Received: from l48181 ([10.111.12.236]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUU009HI56IF5@szxml04-in.huawei.com> for yang@ietf.org; Fri, 18 Jan 2008 18:30:19 +0800 (CST) Date: Fri, 18 Jan 2008 18:30:18 +0800 From: Li Yan To: 'yang' Message-id: <000b01c859bd$1f4fe5c0$ec0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchZvR8G6/OMzhQxR7KspjSzXEozHg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 962517628a679322096a16b4fad0d0cd Subject: [YANG] Choice and uses statement X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1675020415==" Errors-To: yang-bounces@ietf.org This is a multi-part message in MIME format. --===============1675020415== Content-type: multipart/alternative; boundary="Boundary_(ID_QvqrHFyVcY549bAkzMoAMA)" This is a multi-part message in MIME format. --Boundary_(ID_QvqrHFyVcY549bAkzMoAMA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Why the "uses" statement is not able to reference the "choice" definition? If it can, the "choice" definition would be allowed to be reused. I noticed that the "choice" statement can be contained immediately in the "module" and "submodule" statement. I wonder how to make use of this "choice" definition? Yan --Boundary_(ID_QvqrHFyVcY549bAkzMoAMA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Why the “uses” statement is not able to reference the "choice" definition? If it can, the "choice" definition would be allowed to be reused.

I noticed that the "choice" statement can be contained immediately in the “module” and “submodule” statement. I wonder how to make use of this "choice" definition?

 

Yan

--Boundary_(ID_QvqrHFyVcY549bAkzMoAMA)-- --===============1675020415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1675020415==-- From yang-bounces@ietf.org Fri Jan 18 06:38:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFpYX-0006S1-BF; Fri, 18 Jan 2008 06:38:41 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFpYW-0006Rw-Bn for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 06:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFpYW-0006Ro-0W for yang@ietf.org; Fri, 18 Jan 2008 06:38:40 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFpYU-0005j2-KI for yang@ietf.org; Fri, 18 Jan 2008 06:38:39 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 590621B80C9; Fri, 18 Jan 2008 12:38:36 +0100 (CET) Date: Fri, 18 Jan 2008 12:39:47 +0100 (CET) Message-Id: <20080118.123947.237218225.mbj@tail-f.com> To: liyan_77@huawei.com Subject: Re: [YANG] Choice and uses statement From: Martin Bjorklund In-Reply-To: <000b01c859bd$1f4fe5c0$ec0c6f0a@china.huawei.com> References: <000b01c859bd$1f4fe5c0$ec0c6f0a@china.huawei.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Li Yan wrote: > Hi, > > Why the "uses" statement is not able to reference the "choice" definition? > If it can, the "choice" definition would be allowed to be reused. uses always references a named grouping. The grouping can contain a choice, so you can do: grouping protocol-type { choice proto { case tcp { ... } case udp { ... } } } And then: uses protocol-type; > I noticed that the "choice" statement can be contained immediately in the > "module" and "submodule" statement. I wonder how to make use of this > "choice" definition? 'choice' is one of the "data-definition statements" in YANG. All data-definitions are allowed at the top-level. We didn't really see a reason to restrict these usages. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 08:29:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrI9-0008Lv-Qf; Fri, 18 Jan 2008 08:29:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFrI8-0008Lq-VQ for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 08:29:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrI8-0008Lh-Kf for yang@ietf.org; Fri, 18 Jan 2008 08:29:52 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFrI6-0007eR-Oz for yang@ietf.org; Fri, 18 Jan 2008 08:29:52 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF3888A436; Fri, 18 Jan 2008 14:29:49 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 21822-05; Fri, 18 Jan 2008 14:29:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00D658A419; Fri, 18 Jan 2008 14:29:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5E0C2469483; Fri, 18 Jan 2008 14:29:44 +0100 (CET) Date: Fri, 18 Jan 2008 14:29:44 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] default values Message-ID: <20080118132944.GA29709@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , yang@ietf.org References: <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis> <20080117152200.GA29447@elstar.local> <478F7766.4080905@andybierman.com> <1200589029.19372.100.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1200589029.19372.100.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 17, 2008 at 05:57:09PM +0100, Ladislav Lhotka wrote: > Andy Bierman p????e v ??t 17. 01. 2008 v 07:42 -0800: > > I strongly object to removing the default-stmt. > > As Balazs pointed out, if a WG does not agree on a suitable > > default value, they do not have to define one. This clause > > is needed to support NETCONF, not only to provide as much > > machine-readable info about the data model characteristics, > > but to simplify NETCONF tasks for operators and applications. > > Operators should only be concerned with the defaults used by their front > ends - and these would typically include much more than just the MUST > defaults that YANG can handle. I believe the assumption of the availability of a smart frontend won't work for all. For me, usefulness without a smart frontend is a requirement. If there are requirements folks here, please write this down. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 09:11:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrwF-0002yI-G9; Fri, 18 Jan 2008 09:11:19 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFrwD-0002qH-FV for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:11:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrwD-0002q9-5f for yang@ietf.org; Fri, 18 Jan 2008 09:11:17 -0500 Received: from exprod7og105.obsmtp.com ([64.18.2.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFrwC-00009X-O2 for yang@ietf.org; Fri, 18 Jan 2008 09:11:17 -0500 Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Fri, 18 Jan 2008 06:11:07 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jan 2008 06:10:05 -0800 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 m0IEA4986120; Fri, 18 Jan 2008 06:10:04 -0800 (PST) (envelope-from phil@idle.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 m0IE9tmK010151; Fri, 18 Jan 2008 14:09:55 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801181409.m0IE9tmK010151@idle.juniper.net> To: Balazs Lengyel Subject: Re: [YANG] default values In-reply-to: <47906FAB.2060505@ericsson.com> Date: Fri, 18 Jan 2008 09:09:55 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Jan 2008 14:10:05.0437 (UTC) FILETIME=[D3188AD0:01C859DB] X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel writes: >Why would the presence container come back automatically? There's today no text in the d >raft, >that says presence containers are automatically removed or created. "come back" in the virtual sense, so if the element isn't it the document, it implicitly is there. Isn't that what Martin meant by "present by default"? >Actually we failed to state what happens, if we later explicitly delete a leaf with a default >value. In my view if the user wants to delete it then it should go away; no value presen >t any more. If an element is deleted, the configuration should behave as if it never were present, meaning it should revert to the default. Otherwise there's a difference in behavior between not having an statement in the config and having it but deleting it. This difference won't be reflected in the "show" output, and reloading the config or rebooting the device will give different behavior. >One more thing I think is still missing from the draft, is whether must expressions cons >ider >default values or not? We discussed this at some point and decided that "must"s must see defaults, but there needs to be a helper function to allow one to detect unconfigured values. must "../mtu < 1500 or not(yang:is-set(../mtu))"; I don't think this is in the current spec. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 09:20:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFs5Z-0001sY-Oe; Fri, 18 Jan 2008 09:20:57 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFs5Y-0001sT-21 for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:20:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFs5X-0001sL-Nk for yang@ietf.org; Fri, 18 Jan 2008 09:20:55 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFs5X-0004jS-AC for yang@ietf.org; Fri, 18 Jan 2008 09:20:55 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1D635D800C1 for ; Fri, 18 Jan 2008 15:20:54 +0100 (CET) Subject: Re: [YANG] default values From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080118132944.GA29709@elstar.local> References: <1200556619.10666.16.camel@missotis> <478F17B4.7060500@ericsson.com> <1200565743.10666.64.camel@missotis> <20080117112702.GA29235@elstar.local> <1200571644.10666.91.camel@missotis> <20080117135724.GC29301@elstar.local> <1200582110.19372.43.camel@missotis> <20080117152200.GA29447@elstar.local> <478F7766.4080905@andybierman.com> <1200589029.19372.100.camel@missotis> <20080118132944.GA29709@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 18 Jan 2008 15:20:54 +0100 Message-Id: <1200666054.20903.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v P=C3=A1 18. 01. 2008 v 14:29 +0100= : > On Thu, Jan 17, 2008 at 05:57:09PM +0100, Ladislav Lhotka wrote: > > Andy Bierman p????e v ??t 17. 01. 2008 v 07:42 -0800: > > > I strongly object to removing the default-stmt. > > > As Balazs pointed out, if a WG does not agree on a suitable > > > default value, they do not have to define one. This clause > > > is needed to support NETCONF, not only to provide as much > > > machine-readable info about the data model characteristics, > > > but to simplify NETCONF tasks for operators and applications. > >=20 > > Operators should only be concerned with the defaults used by their fr= ont > > ends - and these would typically include much more than just the MUST > > defaults that YANG can handle. >=20 > I believe the assumption of the availability of a smart frontend=20 > won't work for all. For me, usefulness without a smart frontend is a > requirement. If there are requirements folks here, please write this > down. I didn't say "smart frontend". Even the standard input used for connecting server's ssh subsystem is a frontend (dumb, right). However, in this case no substitution of defaults happens at the client side and I would require the poor user to type in all elements&values he wants to change. In the default merge mode of edit-config it's not an issue anyway. Lada >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 09:34:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsIj-0004Kq-8y; Fri, 18 Jan 2008 09:34:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFsIg-00042G-Tw for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:34:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsIg-0003wg-8c for yang@ietf.org; Fri, 18 Jan 2008 09:34:30 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFsIf-0000bw-Pw for yang@ietf.org; Fri, 18 Jan 2008 09:34:30 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 5BCA01B80C9; Fri, 18 Jan 2008 15:34:28 +0100 (CET) Date: Fri, 18 Jan 2008 15:35:39 +0100 (CET) Message-Id: <20080118.153539.149287946.mbj@tail-f.com> To: phil@juniper.net Subject: Re: [YANG] default values From: Martin Bjorklund In-Reply-To: <200801181409.m0IE9tmK010151@idle.juniper.net> References: <47906FAB.2060505@ericsson.com> <200801181409.m0IE9tmK010151@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Balazs Lengyel writes: > >Why would the presence container come back automatically? There's today no text in the d > >raft, > >that says presence containers are automatically removed or created. > > "come back" in the virtual sense, so if the element isn't it the > document, it implicitly is there. Isn't that what Martin meant by > "present by default"? You're right, this won't work, or maybe we should say that it is different. It is more of an "initial-value" than default. The original use case was this: > Andy Bierman wrote: > >> A trivial example is a boolean knob (or presence container in YANG) >> that represents some service or feature, and the WG agrees it is 'off' >> by default. This cannot be done in current YANG. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 09:43:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsRr-0005qJ-13; Fri, 18 Jan 2008 09:43:59 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFsRp-0005q8-OQ for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:43:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsRp-0005q0-E4 for yang@ietf.org; Fri, 18 Jan 2008 09:43:57 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFsRp-0005Cn-0P for yang@ietf.org; Fri, 18 Jan 2008 09:43:57 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 18 Jan 2008 06:43:51 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 06:43:33 -0800 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 m0IEhW993516; Fri, 18 Jan 2008 06:43:32 -0800 (PST) (envelope-from phil@idle.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 m0IEhM9g010492; Fri, 18 Jan 2008 14:43:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801181443.m0IEhM9g010492@idle.juniper.net> To: Martin Bjorklund Subject: Re: [YANG] default values In-reply-to: <20080118.153539.149287946.mbj@tail-f.com> Date: Fri, 18 Jan 2008 09:43:22 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Jan 2008 14:43:33.0025 (UTC) FILETIME=[7FB62910:01C859E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund writes: >>> A trivial example is a boolean knob (or presence container in YANG) >>> that represents some service or feature, and the WG agrees it is 'off' >>> by default. >This cannot be done in current YANG. If it's off, then it doesn't appear in configs. When it appears, it's turned on. When it's removed, it's turned off. But I'm sure I'm missing something here.... Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 09:48:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsWO-0002JF-MG; Fri, 18 Jan 2008 09:48:40 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFsWN-0002J8-3e for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:48:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsWM-0002Iz-Q9 for yang@ietf.org; Fri, 18 Jan 2008 09:48:38 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFsWM-0000or-FV for yang@ietf.org; Fri, 18 Jan 2008 09:48:38 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id EB7691B80C9; Fri, 18 Jan 2008 15:48:37 +0100 (CET) Date: Fri, 18 Jan 2008 15:49:49 +0100 (CET) Message-Id: <20080118.154949.83008967.mbj@tail-f.com> To: phil@juniper.net Subject: Re: [YANG] default values From: Martin Bjorklund In-Reply-To: <200801181409.m0IE9tmK010151@idle.juniper.net> References: <47906FAB.2060505@ericsson.com> <200801181409.m0IE9tmK010151@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Balazs Lengyel writes: > >One more thing I think is still missing from the draft, is whether > >must expressions consider default values or not? > > We discussed this at some point and decided that "must"s must > see defaults, but there needs to be a helper function to allow > one to detect unconfigured values. > > must "../mtu < 1500 or not(yang:is-set(../mtu))"; > > I don't think this is in the current spec. It's on my TODO list. I was thinking the text should say that default values exist in the data tree, and then clarify the text about XML encoding of leafs to say that leafs which are set to their default values in the data tree do not have to be sent. The must description talks about the data tree, so by adding the defaults to the data tree, the must expressions are covered. One question is how the xpath function should behave: node set node set to node does to default other value not exist -------------------------------------------------------------- yang:has-default(node) true false false yang:is-set(node) false true false Maybe it's no big deal - if you want to check for existance, that's trivial in XPath. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 09:50:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsXy-00045e-Qt; Fri, 18 Jan 2008 09:50:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFsXx-00045Y-Ms for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:50:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsXx-00045Q-CY for yang@ietf.org; Fri, 18 Jan 2008 09:50:17 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFsXx-0005Kw-1T for yang@ietf.org; Fri, 18 Jan 2008 09:50:17 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 64E2C1B80C9; Fri, 18 Jan 2008 15:50:16 +0100 (CET) Date: Fri, 18 Jan 2008 15:51:28 +0100 (CET) Message-Id: <20080118.155128.68978705.mbj@tail-f.com> To: phil@juniper.net Subject: Re: [YANG] default values From: Martin Bjorklund In-Reply-To: <200801181443.m0IEhM9g010492@idle.juniper.net> References: <20080118.153539.149287946.mbj@tail-f.com> <200801181443.m0IEhM9g010492@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > >>> A trivial example is a boolean knob (or presence container in YANG) > >>> that represents some service or feature, and the WG agrees it is 'off' > >>> by default. > >This cannot be done in current YANG. > > If it's off, then it doesn't appear in configs. When it appears, > it's turned on. When it's removed, it's turned off. > > But I'm sure I'm missing something here.... I guess I mentally extrapolated from Andy's example... if the WG can agree that it's 'off' by default, I was thinking they could agree that it is 'on' by default as well. This cannot be done. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 10:48:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtSU-0006Kw-Fe; Fri, 18 Jan 2008 10:48:42 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFtST-0006KL-8v for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:48:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtSS-0006KD-Tb for yang@ietf.org; Fri, 18 Jan 2008 10:48:40 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtSS-0006qc-10 for yang@ietf.org; Fri, 18 Jan 2008 10:48:40 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 464568A432; Fri, 18 Jan 2008 16:48:38 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04109-03-13; Fri, 18 Jan 2008 16:48:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5241C8A445; Fri, 18 Jan 2008 16:46:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DF1E846971D; Fri, 18 Jan 2008 16:46:19 +0100 (CET) Date: Fri, 18 Jan 2008 16:46:19 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] Questions about submodule Message-ID: <20080118154619.GA29852@elstar.local> Mail-Followup-To: Martin Bjorklund , liyan_77@huawei.com, yang@ietf.org References: <000001c859b6$b0626ee0$ec0c6f0a@china.huawei.com> <20080118.111505.89141499.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080118.111505.89141499.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Jan 18, 2008 at 11:15:05AM +0100, Martin Bjorklund wrote: > In larger projects, this might actually be useful. Instead of having > one big centralized module, we allow people to split the task into > submodules. If the submodule becomes big enough, it might be useful > to split it into other submodules. Even though I cannot see that 100 > levels are ever used, I don't think we should add a rule which says > that you cannot nest more than 99 levels. I am not a big fan of introducing such arbitrary limits. A yang compiler is not something that you need at NETCONF run time so memory constraints etc. are not a big deal. We also have no limits for the number of identifiers a module may define, the max. nesting of containers and many other things. And I think this is goodness and we should stick to this. If people really want limits (I hope not), we should define minimums that must be supported to be compliant, but leave the maximum open. (Note that libsmi allocates everything dynamically so the limits are actually the available memory at run time; I would not like to move to a different implementation model just to be compliant to some rather arbitrarily choosen limits.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 10:56:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFta7-0002oa-Gm; Fri, 18 Jan 2008 10:56:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFta5-0002oN-SD for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:56:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFta5-0002oF-H9 for yang@ietf.org; Fri, 18 Jan 2008 10:56:33 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFta4-00072i-TN for yang@ietf.org; Fri, 18 Jan 2008 10:56:33 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4AD5A21079; Fri, 18 Jan 2008 16:56:32 +0100 (CET) X-AuditID: c1b4fb3c-ad31ebb0000007e0-df-4790cc30e342 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 380912103B; Fri, 18 Jan 2008 16:56:32 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:56:31 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:56:31 +0100 Message-ID: <4790F2DA.1030705@ericsson.com> Date: Fri, 18 Jan 2008 19:41:30 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] default values References: <47906FAB.2060505@ericsson.com> <200801181409.m0IE9tmK010151@idle.juniper.net> <20080118.154949.83008967.mbj@tail-f.com> In-Reply-To: <20080118.154949.83008967.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2008 15:56:31.0474 (UTC) FILETIME=[B1787520:01C859EA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org If we could agree that a leaf thats set automatically to it's default at least conceptually exists, that would make understanding how this works MUCH easier. However we have to describe how this effects non-presence containers Balazs Martin Bjorklund wrote: > Phil Shafer wrote: >> Balazs Lengyel writes: > >>> One more thing I think is still missing from the draft, is whether >>> must expressions consider default values or not? >> We discussed this at some point and decided that "must"s must >> see defaults, but there needs to be a helper function to allow >> one to detect unconfigured values. >> >> must "../mtu < 1500 or not(yang:is-set(../mtu))"; >> >> I don't think this is in the current spec. > > It's on my TODO list. > > I was thinking the text should say that default values exist in the > data tree, and then clarify the text about XML encoding of leafs to > say that leafs which are set to their default values in the data tree > do not have to be sent. The must description talks about the data > tree, so by adding the defaults to the data tree, the must expressions > are covered. > > One question is how the xpath function should behave: > > node set node set to node does > to default other value not exist > -------------------------------------------------------------- > yang:has-default(node) true false false > yang:is-set(node) false true false > > > Maybe it's no big deal - if you want to check for existance, that's > trivial in XPath. > > > /martin -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 11:18:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtuq-0005aG-Cn; Fri, 18 Jan 2008 11:18:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFtup-0005a9-HL for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:17:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtup-0005a1-7E for yang@ietf.org; Fri, 18 Jan 2008 11:17:59 -0500 Received: from smtp114.sbc.mail.mud.yahoo.com ([68.142.198.213]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFtuo-00039S-QJ for yang@ietf.org; Fri, 18 Jan 2008 11:17:59 -0500 Received: (qmail 38370 invoked from network); 18 Jan 2008 16:17:58 -0000 Received: from unknown (HELO andrew-biermans-computer.local) (andybierman@att.net@67.126.240.103 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 18 Jan 2008 16:17:57 -0000 X-YMail-OSG: qIsRDfMVM1mn6QauG3VxMzSgqq1FMGJhuqoPb9wRlN.5UH2f X-Yahoo-Newman-Property: ymail-3 Message-ID: <4790D279.3070804@andybierman.com> Date: Fri, 18 Jan 2008 08:23:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: yang@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [YANG] deep keys and unique statements X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I share Ladislav's concern that YANG requires all key components to be leafs at the very top-level within the list. IMO, there is no harm or massive complexity introduced if a key leaf is allowed to be nested within N containers. A key must be mandatory, and have only one instance per list entry, therefore nested lists or choices cannot contain key leafs. This 'container only' is not a CLR -- just the properties of a key. The implementation burden of buffering input does not seem that important, since key leafs can appear anywhere in list, and there may be a lot of XML-on-the-wire before the key leaf shows up. Key components do not have to be used in 'XML order' either, which also requires buffering to support. On the other hand, the unique-stmt allows arbitrary combinations of leaf instances anywhere within the list. The complexity built into the unique-stmt is extensive, as even a 2-d table shows: list foo { // all nodes except the key leafs (x, c, d) are optional config true; key x; unique "y bar/a baz/e baz/c"; list bar { config false; leaf a { type int32; } leaf b { type string; } } list baz { key "d c"; leaf c { type float32; } leaf d { type float64; } leaf e { type binary; } } leaf x { type instance-identifier; } leaf y { type keyref { path "baz/c"; } } } The agent has to check all the instances of all the leafs and only enforce uniqueness in the entries that are complete. One missing optional leaf, and the entire unique-stmt is ignored instead (for that entry). Besides this unbounded complexity, it seems very odd for the leafs within the nested lists (bar and baz) to have uniqueness constraints placed 'from above', since they are not required to be unique within the list that defines the leafs. It also seems broken that config and non-config leafs can be combined in the uniqueness test. The 'config' and 'unique' statements are not relevant in notification data, so is it an error or just no-op if they are entered for notification data-def-stmts? (Could be from uses expansion as well.) (Note that keyref adds an indirection twist to the complexity.) Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 12:03:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFucp-00027q-B7; Fri, 18 Jan 2008 12:03:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFuco-00027k-G2 for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 12:03:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuco-00027X-55 for yang@ietf.org; Fri, 18 Jan 2008 12:03:26 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFucn-0001K6-Ml for yang@ietf.org; Fri, 18 Jan 2008 12:03:26 -0500 Received: (qmail 29935 invoked from network); 18 Jan 2008 17:03:22 -0000 Received: from unknown (HELO andrew-biermans-computer.local) (andybierman@att.net@67.126.240.103 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 18 Jan 2008 17:03:22 -0000 X-YMail-OSG: IfUacqUVM1mYI7i8rmRUj66plHiAcnTMtFTm9aI70lRN6snr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4790DD1E.7090807@andybierman.com> Date: Fri, 18 Jan 2008 09:08:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: yang@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [YANG] new pyang errors X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I notice the new version of pyang says it is an error to have a mandatory leaf with a default. I don't agree with this interpretation. There is no other way to support an agent-supplied default. leaf foo { mandatory true; default 7; type int32; } leaf bar { mandatory false; default 7; type int32; } The leaf 'foo' is created by the agent with the value 7 if the manager tries to set the config without it. Mandatory means it must be present in a valid config, not that the manager must set some value. The leaf 'bar' has an irrelevant default clause that will never be used because the leaf is optional and the agent will not create it. I think the CLR is backwards, but none is really needed here at all. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 12:08:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuhy-00052N-Lm; Fri, 18 Jan 2008 12:08:46 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFuhx-0004x8-17 for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 12:08:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuhw-0004t3-FS for yang@ietf.org; Fri, 18 Jan 2008 12:08:44 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFuhu-0004hT-5M for yang@ietf.org; Fri, 18 Jan 2008 12:08:44 -0500 Received: (qmail 21058 invoked from network); 18 Jan 2008 17:08:41 -0000 Received: from unknown (HELO andrew-biermans-computer.local) (andybierman@att.net@67.126.240.103 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 18 Jan 2008 17:08:41 -0000 X-YMail-OSG: ueAxDPUVM1lA3hxR24uAp49IUBtMqEsNtmePvl_05p5vVfX7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4790DE5C.8020902@andybierman.com> Date: Fri, 18 Jan 2008 09:14:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: yang@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [YANG] new pyang errors X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I notice the new version of pyang says it is an error to have a mandatory leaf with a default. I don't agree with this interpretation. There is no other way to support an agent-supplied default. leaf foo { mandatory true; default 7; type int32; } leaf bar { mandatory false; default 7; type int32; } The leaf 'foo' is created by the agent with the value 7 if the manager tries to set the config without it. Mandatory means it must be present in a valid config, not that the manager must set some value. The leaf 'bar' has an irrelevant default clause that will never be used because the leaf is optional and the agent will not create it. I think the CLR is backwards, but none is really needed here at all. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 16:11:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFyUj-0000uo-22; Fri, 18 Jan 2008 16:11:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFyUh-0000kq-N5 for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 16:11:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFyUh-0000hL-87 for yang@ietf.org; Fri, 18 Jan 2008 16:11:19 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFyUg-0004Xs-Nk for yang@ietf.org; Fri, 18 Jan 2008 16:11:19 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 18 Jan 2008 13:11:11 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 13:08:38 -0800 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 m0IL8c900830; Fri, 18 Jan 2008 13:08:38 -0800 (PST) (envelope-from phil@idle.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 m0IL8M38012597; Fri, 18 Jan 2008 21:08:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801182108.m0IL8M38012597@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] new pyang errors In-reply-to: <4790DD1E.7090807@andybierman.com> Date: Fri, 18 Jan 2008 16:08:22 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Jan 2008 21:08:38.0917 (UTC) FILETIME=[4BE57B50:01C85A16] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >Mandatory means it must be present in a >valid config, not that the manager must set some value. That's certainly not the way I read mandatory. Mandatory means that it must be set, meaning that some{one,thing} must set it. If there were a reasonable default, you shouldn't need to make it mandatory. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 16:36:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFyt9-0006tf-G3; Fri, 18 Jan 2008 16:36:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JFyt8-0006qu-9V for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 16:36:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFyt7-0006nw-V4 for yang@ietf.org; Fri, 18 Jan 2008 16:36:33 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFyt5-0006zj-ND for yang@ietf.org; Fri, 18 Jan 2008 16:36:33 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 3B6FC1B80C9; Fri, 18 Jan 2008 22:36:28 +0100 (CET) Date: Fri, 18 Jan 2008 22:35:11 +0100 (CET) Message-Id: <20080118.223511.146519405.mbj@tail-f.com> To: phil@juniper.net Subject: Re: [YANG] new pyang errors From: Martin Bjorklund In-Reply-To: <200801182108.m0IL8M38012597@idle.juniper.net> References: <4790DD1E.7090807@andybierman.com> <200801182108.m0IL8M38012597@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang@ietf.org, andy@andybierman.com X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >Mandatory means it must be present in a > >valid config, not that the manager must set some value. > > That's certainly not the way I read mandatory. Mandatory > means that it must be set, meaning that some{one,thing} > must set it. If there were a reasonable default, you > shouldn't need to make it mandatory. This is one of the areas where we've had some discussions. If you classify leafs as 'mandatory' and 'optional', where does a leaf w/ a default fit in? IMO it doesn't really matter, it just have to be clear. In YANG we chose to define 'mandatory' as mandatory to set, and a leaf with a default is optional to set. Thus you cannot have mandatory and default on one leaf. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 18 20:04:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG28N-00082y-Ix; Fri, 18 Jan 2008 20:04:31 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JG28N-00080C-1U for yang-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 20:04:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG28M-0007w4-Fl for yang@ietf.org; Fri, 18 Jan 2008 20:04:30 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JG28M-0003TN-1e for yang@ietf.org; Fri, 18 Jan 2008 20:04:30 -0500 Received: (qmail 96506 invoked from network); 19 Jan 2008 01:04:29 -0000 Received: from unknown (HELO andrew-biermans-computer.local) (andybierman@att.net@67.126.240.103 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 19 Jan 2008 01:04:29 -0000 X-YMail-OSG: rCHhicMVM1lXKGNQ5NsiPJ6el2Rlu7rQcRaNIvRE.ULbhjR0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <47914C9D.2090909@andybierman.com> Date: Fri, 18 Jan 2008 17:04:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801182108.m0IL8M38012597@idle.juniper.net> In-Reply-To: <200801182108.m0IL8M38012597@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Mandatory means it must be present in a >> valid config, not that the manager must set some value. > > That's certainly not the way I read mandatory. Mandatory > means that it must be set, meaning that some{one,thing} > must set it. If there were a reasonable default, you > shouldn't need to make it mandatory. > I can only find 2 brief paragraphs of text on the mandatory-stmt: 7.6.4. The leaf's mandatory Statement The "mandatory" statement, which is optional, takes as an argument the string "true" or "false". If "mandatory" is "true", the node must exist in a valid configuration if its parent node exists. If not specified, the default is "false". 7.9.4. The choice's mandatory Statement The "mandatory" statement, which is optional, takes as an argument the string "true" or "false". If "mandatory" is "true", nodes from exactly one of the choice's case branches MUST exist in a valid configuration. If not specified, the default is "false". The current draft clearly says that 'mandatory true' refers to the configuration database, not to whether the manager must provide an explicit value. I agree with the interpretation in the current draft. YANG needs to be more consistent wrt/ mixing DM concepts too much. The data model object definitions (leaf, container, etc.) refer to the desired/expected state of the configuration database, not with individual PDUs. The reason that the data model MUST refer to the configuration is that schema validation of NETCONF PDUs is mostly meaningless. Since the PDUs are so flexible, every single element and attribute would need to be marked optional (minOccurs=0). > Thanks, > Phil > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Jan 19 12:39:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGHet-0005KG-JA; Sat, 19 Jan 2008 12:39:07 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGHer-0005KA-VU for yang-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 12:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGHel-0005K0-6D for yang@ietf.org; Sat, 19 Jan 2008 12:38:59 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGHek-0003IC-Pw for yang@ietf.org; Sat, 19 Jan 2008 12:38:59 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Sat, 19 Jan 2008 09:38:56 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Jan 2008 09:38:55 -0800 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 m0JHco930927; Sat, 19 Jan 2008 09:38:55 -0800 (PST) (envelope-from phil@idle.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 m0JHcUYi016993; Sat, 19 Jan 2008 17:38:35 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801191738.m0JHcUYi016993@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] new pyang errors In-reply-to: <47914C9D.2090909@andybierman.com> Date: Sat, 19 Jan 2008 12:38:30 -0500 From: Phil Shafer X-OriginalArrivalTime: 19 Jan 2008 17:38:55.0910 (UTC) FILETIME=[2A40BC60:01C85AC2] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >The current draft clearly says that 'mandatory true' refers to the >configuration database, not to whether the manager must provide >an explicit value. >I agree with the interpretation in the current draft. Well, you agree with your interpretation of the draft ;^) The issue isn't whether a leaf with a default has to appear in any particular PDU, but whether a leaf with a default "exists" until some{one,thing} creates it. If leafs (and non-presence containers) are automagically created "in the configuration database", then configurations become big and verbose, which is the opposite of what I want. So I don't want leafs with defaults to be considered "created". And when I read the draft with that prespective, it agrees with me. So the draft is underspecified. What outcome do we want and what do need to add to the draft to ensure there is only one possible reading of our spec? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Jan 19 13:39:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIbm-0002If-F7; Sat, 19 Jan 2008 13:39:58 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGIbk-0002IK-Tk for yang-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 13:39:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIbk-0002IA-Ih for yang@ietf.org; Sat, 19 Jan 2008 13:39:56 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGIbk-0001mH-36 for yang@ietf.org; Sat, 19 Jan 2008 13:39:56 -0500 Received: (qmail 57808 invoked from network); 19 Jan 2008 18:39:55 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 19 Jan 2008 18:39:54 -0000 X-YMail-OSG: lYBUtvQVM1kdG0EOhvNhehmTI_PIKr0m73KwX12z0COvq0sY X-Yahoo-Newman-Property: ymail-3 Message-ID: <479243FA.1010008@andybierman.com> Date: Sat, 19 Jan 2008 10:39:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801191738.m0JHcUYi016993@idle.juniper.net> In-Reply-To: <200801191738.m0JHcUYi016993@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The current draft clearly says that 'mandatory true' refers to the >> configuration database, not to whether the manager must provide >> an explicit value. >> I agree with the interpretation in the current draft. > > Well, you agree with your interpretation of the draft ;^) > > The issue isn't whether a leaf with a default has to appear > in any particular PDU, but whether a leaf with a default > "exists" until some{one,thing} creates it. If leafs (and > non-presence containers) are automagically created "in the > configuration database", then configurations become big > and verbose, which is the opposite of what I want. So > I don't want leafs with defaults to be considered "created". > > And when I read the draft with that prespective, it agrees > with me. So the draft is underspecified. What outcome do > we want and what do need to add to the draft to ensure there > is only one possible reading of our spec? > It is really up to the DM writer whether they want agent-created default leafs or not. I do not care about containers as much, although the principle is the same. There is no auto-magic. The logic is very simple when a leaf value is not provided by the manager: Q1: Is the leaf mandatory? No: processing is done, node is not instantiated in the agent Yes: Q2: Is there a default-stmt for the leaf, or if not, is there a default-stmt for the typedef used by the leaf? No: missing mandatory data error Yes: use the default value to instantiate the leaf node > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Jan 19 14:13:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGJ8d-000854-C1; Sat, 19 Jan 2008 14:13:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGJ8b-00084u-Fm for yang-confirm+ok@megatron.ietf.org; Sat, 19 Jan 2008 14:13:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGJ8b-00084m-5L for yang@ietf.org; Sat, 19 Jan 2008 14:13:53 -0500 Received: from smtp122.sbc.mail.sp1.yahoo.com ([69.147.64.95]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGJ8a-0002Va-Ly for yang@ietf.org; Sat, 19 Jan 2008 14:13:53 -0500 Received: (qmail 85867 invoked from network); 19 Jan 2008 19:13:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 19 Jan 2008 19:13:51 -0000 X-YMail-OSG: YST_UJwVM1lfmo0i1uL5jfAAwbzCBgZ.m5N0.zV5F.E9vLo7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <47924BEE.7040106@andybierman.com> Date: Sat, 19 Jan 2008 11:13:50 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801191738.m0JHcUYi016993@idle.juniper.net> <479243FA.1010008@andybierman.com> In-Reply-To: <479243FA.1010008@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: >... Perhaps you want to revive the debate on the NGO list about the 'with-defaults' extension? The consensus was that both views of the configuration database are useful, and the protocol should support both of them. Without the 'full' view, how is a manager supposed to know whether a leaf is really there with the default value, or not supported by the agent or supported but not used in this instance. How is a manager supposed to get a complete config diff from the agent, without analyzing all the schema files between N different software releases? A diff (with-defaults='true') will expose silent default value changes for agent-supplied optional knobs, or agents that are ignoring the schema and using a different default value. The solution to this supposed YANG problem is to add the with-defaults='false' extension to the NETCONF operations to filter out these nodes in get and copy operations. Currently, 'state' nodes are auto-filtered by get-config, but not "default true/false". It should not be a big deal to add this as a mandatory filter somehow. >> Thanks, >> Phil >> >> > > Andy > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 20 05:43:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGXe3-0000t0-UP; Sun, 20 Jan 2008 05:43:19 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGXe2-0000su-6M for yang-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 05:43:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGXdv-0000n6-8x for yang@ietf.org; Sun, 20 Jan 2008 05:43:11 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGXdu-00033X-Qc for yang@ietf.org; Sun, 20 Jan 2008 05:43:11 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 0FEB21B80C5; Sun, 20 Jan 2008 11:43:09 +0100 (CET) Date: Sun, 20 Jan 2008 11:41:45 +0100 (CET) Message-Id: <20080120.114145.15454894.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] new pyang errors From: Martin Bjorklund In-Reply-To: <47924BEE.7040106@andybierman.com> References: <200801191738.m0JHcUYi016993@idle.juniper.net> <479243FA.1010008@andybierman.com> <47924BEE.7040106@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Andy Bierman wrote: > > Phil Shafer wrote: > > > >... > > Perhaps you want to revive the debate on the NGO list > about the 'with-defaults' extension? > > The consensus was that both views of the configuration database > are useful, and the protocol should support both of them. The intention with the YANG solution is to support both these views, and also support systems that implements the with-default capability. > Without the 'full' view, how is a manager supposed to know > whether a leaf is really there with the default value, or > not supported by the agent or supported but not used in this instance. Now you're touching on the conformance / capabilities problem... Currently in YANG this is pretty coarse-grained, on the module level. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 20 11:51:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGdOI-00018v-3I; Sun, 20 Jan 2008 11:51:26 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGdOH-00018p-3A for yang-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 11:51:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGdOG-00018h-FS for yang@ietf.org; Sun, 20 Jan 2008 11:51:24 -0500 Received: from smtp116.sbc.mail.sp1.yahoo.com ([69.147.64.89]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JGdOG-000052-7P for yang@ietf.org; Sun, 20 Jan 2008 11:51:24 -0500 Received: (qmail 6023 invoked from network); 20 Jan 2008 16:51:23 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 20 Jan 2008 16:51:23 -0000 X-YMail-OSG: 2xmPljcVM1nblbhpoaJlAFJ1hN_Plkjgu0sUIoh_I4g2BZLE X-Yahoo-Newman-Property: ymail-3 Message-ID: <47937B90.7060708@andybierman.com> Date: Sun, 20 Jan 2008 08:49:20 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [YANG] mandatory-stmt for leaf X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I would like to change the text in sec. 7.6.4 to say the mandatory-stmt is ignored (if present) for a key leaf, because all key leafs MUST be present in a valid configuration. Right now all it says is: If not specified, the default is "false". Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 20 12:39:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGe93-0003fG-U3; Sun, 20 Jan 2008 12:39:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGe93-0003fB-5W for yang-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 12:39:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGe92-0003f2-RC for yang@ietf.org; Sun, 20 Jan 2008 12:39:44 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGe92-0004wy-BH for yang@ietf.org; Sun, 20 Jan 2008 12:39:44 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sun, 20 Jan 2008 09:39:40 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jan 2008 09:38:48 -0800 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 m0KHcl941739; Sun, 20 Jan 2008 09:38:47 -0800 (PST) (envelope-from phil@idle.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 m0KHcXNw001798; Sun, 20 Jan 2008 17:38:33 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801201738.m0KHcXNw001798@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] new pyang errors In-reply-to: <479243FA.1010008@andybierman.com> Date: Sun, 20 Jan 2008 12:38:33 -0500 From: Phil Shafer X-OriginalArrivalTime: 20 Jan 2008 17:38:48.0122 (UTC) FILETIME=[500621A0:01C85B8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >Q1: Is the leaf mandatory? > Yes: Q2: Is there a default-stmt for the leaf, or if not, is there > a default-stmt for the typedef used by the leaf? > No: missing mandatory data error > Yes: use the default value to instantiate the leaf node If there's a reasonable default for the node, why would you mark it as mandatory? If there's a default, no one needs to create the statement and is doesn't need to exist in the database. What you are doing here is trying to make the meaning of mandatory conditional based on the presence of a default. This is confusing. If something is mandatory, it must exist. If there's a default, it need not exist, since the default gives the value. Making the agent/manager/user/implementor ask your Q1 and Q2 is unnecessary. The question is simply "does it exist?". If it's mandatory and it doesn't exist, it's an error. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 20 13:04:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGeWe-0003KK-6v; Sun, 20 Jan 2008 13:04:08 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGeWc-0003KB-5G for yang-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 13:04:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGeWb-0003K3-Ro for yang@ietf.org; Sun, 20 Jan 2008 13:04:05 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JGeWZ-0001IW-Hr for yang@ietf.org; Sun, 20 Jan 2008 13:04:05 -0500 Received: (qmail 83541 invoked from network); 20 Jan 2008 18:04:02 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 20 Jan 2008 18:04:02 -0000 X-YMail-OSG: 5aXvvdcVM1lWCDWjP_zjtQjRrEykHIhSLkx_IjDorcwBhxnR X-Yahoo-Newman-Property: ymail-3 Message-ID: <47938C97.6060203@andybierman.com> Date: Sun, 20 Jan 2008 10:01:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801201738.m0KHcXNw001798@idle.juniper.net> In-Reply-To: <200801201738.m0KHcXNw001798@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Q1: Is the leaf mandatory? >> Yes: Q2: Is there a default-stmt for the leaf, or if not, is there >> a default-stmt for the typedef used by the leaf? >> No: missing mandatory data error >> Yes: use the default value to instantiate the leaf node > > If there's a reasonable default for the node, why would you mark it > as mandatory? If there's a default, no one needs to create the > statement and is doesn't need to exist in the database. > > What you are doing here is trying to make the meaning of mandatory > conditional based on the presence of a default. This is confusing. > > If something is mandatory, it must exist. If there's a default, > it need not exist, since the default gives the value. Making > the agent/manager/user/implementor ask your Q1 and Q2 is unnecessary. > The question is simply "does it exist?". If it's mandatory and it > doesn't exist, it's an error. > We disagree on which POV is confusing. IMO, it is important to be able to easily distinguish between some knob that the agent is not using at all (whatever that means is DM-specific) vs. a knob that is being used, but which has the DM-defined default value. > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 04:06:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGsbR-0004L0-LQ; Mon, 21 Jan 2008 04:06:01 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGsbQ-0004Ku-7H for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 04:06:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGsbG-0003mp-NE for yang@ietf.org; Mon, 21 Jan 2008 04:05:50 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGsbG-0007Id-2I for yang@ietf.org; Mon, 21 Jan 2008 04:05:50 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 52050D80098 for ; Mon, 21 Jan 2008 10:05:49 +0100 (CET) Subject: Re: [YANG] deep keys and unique statements From: Ladislav Lhotka To: yang In-Reply-To: <4790D279.3070804@andybierman.com> References: <4790D279.3070804@andybierman.com> Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Mon, 21 Jan 2008 10:05:48 +0100 Message-Id: <1200906348.6914.97.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v P=C3=A1 18. 01. 2008 v 08:23 -0800: > On the other hand, the unique-stmt allows arbitrary combinations > of leaf instances anywhere within the list. The complexity > built into the unique-stmt is extensive, as even a 2-d table shows: I am thinking about an alternative "upside-down" implementation of both key and unique properties, namely to declare these properties with the leaf. The semantics would be that these properties always pertain to the nearest ancestor list (if any, otherwise it is noop). Example: list aaa { container bbb { leaf c { type c-type; unique; } } } There are two advantages: 1. The scope of the property - nearest ancestor list - is always unique, so no XPath expressions are needed here. 2. At the time when the declaration is read the entire ancestor chain is known, i.e., no buffering is needed. If I remember correctly, the main objection against this implementation is that it would be difficult to declare keys a posteriori for standard groupings, but I think it could be handled by extending the augment statement, e.g, like this: module inet-extra { ... grouping endpoint { leaf address { type inet:address; } leaf port { type uint16; } } ... import inet-extra { prefix iex; } augment "/iex:endpoint/iex:address" { key; } Lada =20 >=20 >=20 > list foo { > // all nodes except the key leafs (x, c, d) are optional > config true; > key x; > unique "y bar/a baz/e baz/c"; >=20 > list bar { > config false; > leaf a { type int32; } > leaf b { type string; } > } >=20 > list baz { > key "d c"; > leaf c { type float32; } > leaf d { type float64; } > leaf e { type binary; } > } >=20 > leaf x { type instance-identifier; } > leaf y { type keyref { path "baz/c"; } } >=20 > } >=20 >=20 > The agent has to check all the instances of all the leafs and only > enforce uniqueness in the entries that are complete. One missing > optional leaf, and the entire unique-stmt is ignored instead (for that > entry). >=20 > Besides this unbounded complexity, it seems very odd for > the leafs within the nested lists (bar and baz) to have > uniqueness constraints placed 'from above', since they are > not required to be unique within the list that defines the leafs. >=20 > It also seems broken that config and non-config leafs can be > combined in the uniqueness test. The 'config' and 'unique' > statements are not relevant in notification data, so is it > an error or just no-op if they are entered for notification > data-def-stmts? (Could be from uses expansion as well.) > (Note that keyref adds an indirection twist to the complexity.) >=20 > Andy >=20 >=20 >=20 >=20 > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 04:16:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGslJ-0004DA-C1; Mon, 21 Jan 2008 04:16:13 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGslI-0004D5-5Q for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 04:16:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGslH-0004Cx-Qp for yang@ietf.org; Mon, 21 Jan 2008 04:16:11 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGslH-0007Xp-6T for yang@ietf.org; Mon, 21 Jan 2008 04:16:11 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 056D61B80C6; Mon, 21 Jan 2008 10:16:09 +0100 (CET) Date: Mon, 21 Jan 2008 10:17:27 +0100 (CET) Message-Id: <20080121.101727.102844599.mbj@tail-f.com> To: lhotka@cesnet.cz Subject: Re: [YANG] deep keys and unique statements From: Martin Bjorklund In-Reply-To: <1200906348.6914.97.camel@missotis> References: <4790D279.3070804@andybierman.com> <1200906348.6914.97.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1035548993==" Errors-To: yang-bounces@ietf.org --===============1035548993== Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IFDDoSAxOC4gMDEuIDIwMDggdiAwODoyMyAtMDgwMDoNCj4gPiBPbiB0aGUgb3Ro ZXIgaGFuZCwgdGhlIHVuaXF1ZS1zdG10IGFsbG93cyBhcmJpdHJhcnkgY29tYmluYXRpb25zDQo+ ID4gb2YgbGVhZiBpbnN0YW5jZXMgYW55d2hlcmUgd2l0aGluIHRoZSBsaXN0LiAgVGhlIGNvbXBs ZXhpdHkNCj4gPiBidWlsdCBpbnRvIHRoZSB1bmlxdWUtc3RtdCBpcyBleHRlbnNpdmUsIGFzIGV2 ZW4gYSAyLWQgdGFibGUgc2hvd3M6DQo+IA0KPiBJIGFtIHRoaW5raW5nIGFib3V0IGFuIGFsdGVy bmF0aXZlICJ1cHNpZGUtZG93biIgaW1wbGVtZW50YXRpb24gb2YgYm90aA0KPiBrZXkgYW5kIHVu aXF1ZSBwcm9wZXJ0aWVzLCBuYW1lbHkgdG8gZGVjbGFyZSB0aGVzZSBwcm9wZXJ0aWVzIHdpdGgg dGhlDQo+IGxlYWYuIFRoZSBzZW1hbnRpY3Mgd291bGQgYmUgdGhhdCB0aGVzZSBwcm9wZXJ0aWVz IGFsd2F5cyBwZXJ0YWluIHRvIHRoZQ0KPiBuZWFyZXN0IGFuY2VzdG9yIGxpc3QgKGlmIGFueSwg b3RoZXJ3aXNlIGl0IGlzIG5vb3ApLiBFeGFtcGxlOg0KPiANCj4gbGlzdCBhYWEgew0KPiAgIGNv bnRhaW5lciBiYmIgew0KPiAgICAgbGVhZiBjIHsNCj4gICAgICAgdHlwZSBjLXR5cGU7DQo+ICAg ICAgIHVuaXF1ZTsNCj4gICAgIH0NCj4gICB9DQo+IH0NCg0KVGhpcyBkb2Vzbid0IHdvcmsgaWYg aXQgaXMgdGhlIGNvbWJpbmF0aW9uIG9mIHR3byBsZWFmcyB0aGF0IGlzDQp1bmlxdWUuICBJbiB0 aGlzIGV4YW1wbGUsIHRoZSBuYW1lIGhhcyB0byBiZSB1bmlxdWUsIGFuZCBhbHNvIHRoZQ0KaXAv cG9ydCBjb21iaW5hdGlvbjoNCg0KICBsaXN0IHNlcnZlciB7DQogICAga2V5ICJpZHgiOw0KICAg IHVuaXF1ZSAiaXAgcG9ydCI7DQogICAgdW5pcXVlICJuYW1lIjsNCg0KICAgIGxlYWYgaWR4IHsg Li4uIH0NCiAgICBsZWFmIGlwIHsgLi4uIH0NCiAgICBsZWFmIHBvcnQgeyAuLi4gfQ0KICAgIGxl YWYgbmFtZSB7IC4uLiB9DQogIH0NCg0KW1NpZGUgbm90ZTogSW4gb3VyIGN1cnJlbnQgRE1MIHdl IHRvb2sgdGhlIGFwcHJvYWNoIHlvdSBkZXNjcmliZSwgYnV0DQppbiBvcmRlciB0byBoYW5kbGUg dGhlIGNvbWJpbmF0aW9ucywgdGhlIHVuaXF1ZSBzdGF0ZW1lbnQgdG9vayBhbg0KYXJndW1lbnQg d2hpY2ggd2FzIGEgdGFnLiAgQWxsIGxlYWZzIHdpdGggdGhlIHNhbWUgdGFnIHdvdWxkIGJlDQpj aGVja2VkIGluIGNvbWJpbmF0aW9uLiAgSSB0aGluayB0aGUgWUFORyBzdGF0ZW1lbnQgaXMgbW9y ZSBjbGVhci5dDQoNCj4gVGhlcmUgYXJlIHR3byBhZHZhbnRhZ2VzOg0KPiAxLiBUaGUgc2NvcGUg b2YgdGhlIHByb3BlcnR5IC0gbmVhcmVzdCBhbmNlc3RvciBsaXN0IC0gaXMgYWx3YXlzIHVuaXF1 ZSwNCj4gc28gbm8gWFBhdGggZXhwcmVzc2lvbnMgYXJlIG5lZWRlZCBoZXJlLg0KPiAyLiBBdCB0 aGUgdGltZSB3aGVuIHRoZSBkZWNsYXJhdGlvbiBpcyByZWFkIHRoZSBlbnRpcmUgYW5jZXN0b3Ig Y2hhaW4gaXMNCj4ga25vd24sIGkuZS4sIG5vIGJ1ZmZlcmluZyBpcyBuZWVkZWQuDQoNCkkgZG9u J3QgdW5kZXJzdGFuZCB0aGVzZSBhZHZhbnRhZ2VzLiAgQXJlIHlvdSB0YWxraW5nIGFib3V0IGJ1 ZmZlcmluZw0KaW4gdGhlIGNvbXBpbGVyPw0KDQoNCj4gDQo+IElmIEkgcmVtZW1iZXIgY29ycmVj dGx5LCB0aGUgbWFpbiBvYmplY3Rpb24gYWdhaW5zdCB0aGlzIGltcGxlbWVudGF0aW9uDQo+IGlz IHRoYXQgaXQgd291bGQgYmUgZGlmZmljdWx0IHRvIGRlY2xhcmUga2V5cyBhIHBvc3Rlcmlvcmkg Zm9yIHN0YW5kYXJkDQo+IGdyb3VwaW5ncywgYnV0IEkgdGhpbmsgaXQgY291bGQgYmUgaGFuZGxl ZCBieSBleHRlbmRpbmcgdGhlIGF1Z21lbnQNCj4gc3RhdGVtZW50LCBlLmcsIGxpa2UgdGhpczoN Cj4NCj4gbW9kdWxlIGluZXQtZXh0cmEgew0KPiAgIC4uLg0KPiAgIGdyb3VwaW5nIGVuZHBvaW50 IHsNCj4gICAgIGxlYWYgYWRkcmVzcyB7DQo+ICAgICAgIHR5cGUgaW5ldDphZGRyZXNzOw0KPiAg ICAgfQ0KPiAgICAgbGVhZiBwb3J0IHsNCj4gICAgICAgdHlwZSB1aW50MTY7DQo+ICAgICB9DQo+ ICAgfQ0KPiAgIC4uLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIHRoZSB1c2VzIHJlZmluZW1lbnQg dGhhdCB3b3VsZCBiZSB1c2VkIChub3QgYXVnbWVudCk6DQoNCiAgbGlzdCBmb28gew0KICAgIHVz ZXMgaWV4OmVuZHBvaW50IHsNCiAgICAgIGxlYWYgYWRkcmVzcyB7DQogICAgICAgIGtleSB0cnVl Ow0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQoNCi9tYXJ0aW4NCg== --===============1035548993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1035548993==-- From yang-bounces@ietf.org Mon Jan 21 04:38:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGt6V-0000hK-Av; Mon, 21 Jan 2008 04:38:07 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGt6T-0000gZ-Qm for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 04:38:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGt6T-0000gR-GW for yang@ietf.org; Mon, 21 Jan 2008 04:38:05 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGt6T-000839-35 for yang@ietf.org; Mon, 21 Jan 2008 04:38:05 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9570FD80098 for ; Mon, 21 Jan 2008 10:38:04 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <47938C97.6060203@andybierman.com> References: <200801201738.m0KHcXNw001798@idle.juniper.net> <47938C97.6060203@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 21 Jan 2008 10:38:04 +0100 Message-Id: <1200908284.6914.117.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v Ne 20. 01. 2008 v 10:01 -0800: > > If something is mandatory, it must exist. If there's a default, > > it need not exist, since the default gives the value. Making > > the agent/manager/user/implementor ask your Q1 and Q2 is unnecessary. > > The question is simply "does it exist?". If it's mandatory and it > > doesn't exist, it's an error. > >=20 >=20 > We disagree on which POV is confusing. > IMO, it is important to be able to easily distinguish between > some knob that the agent is not using at all (whatever that > means is DM-specific) vs. a knob that is being used, but which > has the DM-defined default value. More to this point: an agent saying "I have parameter X set to the default value but I won't tell you what it is." doesn't seem acceptable to me. Even if standard defaults were defined, I am sure there will be broken (optimised:-) implementations with other default values. It would be extremely hard to debug network problems if the manager cannot verify the actual values used by all agents. I'd thus allow both agents and managers to have their own defaults but always be explicit when exchanging the data. Relying on common universal defaults would make the system fragile. Lada >=20 >=20 > > Thanks, > > Phil > >=20 > >=20 >=20 > Andy >=20 >=20 > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 05:20:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGtlc-0000U1-5A; Mon, 21 Jan 2008 05:20:36 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGtla-0000Th-HP for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 05:20:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGtla-0000TV-3h for yang@ietf.org; Mon, 21 Jan 2008 05:20:34 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGtlW-0000gW-PC for yang@ietf.org; Mon, 21 Jan 2008 05:20:34 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AB279D80098 for ; Mon, 21 Jan 2008 11:20:27 +0100 (CET) Subject: Re: [YANG] deep keys and unique statements From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080121.101727.102844599.mbj@tail-f.com> References: <4790D279.3070804@andybierman.com> <1200906348.6914.97.camel@missotis> <20080121.101727.102844599.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 21 Jan 2008 11:20:27 +0100 Message-Id: <1200910827.6914.145.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund p=C3=AD=C5=A1e v Po 21. 01. 2008 v 10:17 +0100: > Ladislav Lhotka wrote: > > Andy Bierman p=C3=AD=C5=A1e v P=C3=A1 18. 01. 2008 v 08:23 -0800: > > > On the other hand, the unique-stmt allows arbitrary combinations > > > of leaf instances anywhere within the list. The complexity > > > built into the unique-stmt is extensive, as even a 2-d table shows: > >=20 > > I am thinking about an alternative "upside-down" implementation of bo= th > > key and unique properties, namely to declare these properties with th= e > > leaf. The semantics would be that these properties always pertain to = the > > nearest ancestor list (if any, otherwise it is noop). Example: > >=20 > > list aaa { > > container bbb { > > leaf c { > > type c-type; > > unique; > > } > > } > > } >=20 > This doesn't work if it is the combination of two leafs that is > unique. In this example, the name has to be unique, and also the > ip/port combination: In RELAX NG we enclose the two elements in a group pattern and attach the property to that group. Perhaps grouping statement could be used for this purpose in YANG? >=20 > list server { > key "idx"; > unique "ip port"; > unique "name"; >=20 > leaf idx { ... } > leaf ip { ... } > leaf port { ... } > leaf name { ... } > } >=20 > [Side note: In our current DML we took the approach you describe, but > in order to handle the combinations, the unique statement took an > argument which was a tag. All leafs with the same tag would be > checked in combination. I think the YANG statement is more clear.] >=20 > > There are two advantages: > > 1. The scope of the property - nearest ancestor list - is always uniq= ue, > > so no XPath expressions are needed here. > > 2. At the time when the declaration is read the entire ancestor chain= is > > known, i.e., no buffering is needed. >=20 > I don't understand these advantages. Are you talking about buffering > in the compiler? I mean this: If the validator is checking a configuration value and finds in the schema that it is declared as unique, it can immediately tell whether the value is unique within the configuration read so far. In a YANG-like implementation with deep keys, it would have to buffer all unique declarations as long as it is inside the list and determine first for each leaf instance in the configuration whether it was previously declared as unique. I assume the validator walks down the hierarchies of configuration data and the schema in parallel, it may not be an issue if you compile the schema into another representation. =20 >=20 >=20 > >=20 > > If I remember correctly, the main objection against this implementati= on > > is that it would be difficult to declare keys a posteriori for standa= rd > > groupings, but I think it could be handled by extending the augment > > statement, e.g, like this: > > > > module inet-extra { > > ... > > grouping endpoint { > > leaf address { > > type inet:address; > > } > > leaf port { > > type uint16; > > } > > } > > ... >=20 > I think it would be the uses refinement that would be used (not augment= ): >=20 > list foo { > uses iex:endpoint { > leaf address { > key true; > } > } > } >=20 Yes, this looks nice. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 08:22:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwbd-0004ZG-09; Mon, 21 Jan 2008 08:22:29 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGwbc-0004ZB-JL for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 08:22:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwbc-0004Z1-9B for yang@ietf.org; Mon, 21 Jan 2008 08:22:28 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGwba-00059W-Ol for yang@ietf.org; Mon, 21 Jan 2008 08:22:28 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E4742D800BD for ; Mon, 21 Jan 2008 14:22:25 +0100 (CET) From: Ladislav Lhotka To: yang Content-Type: text/plain Organization: CESNET Date: Mon, 21 Jan 2008 14:22:26 +0100 Message-Id: <1200921746.6914.176.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [YANG] relation to XML PDUs X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I understand that YANG data models describe entire configuration datasets, but do they also pose any restrictions to the NETCONF XML PDUs? For example: the order of children in a YANG model is fixed - does it mean that the corresponding XML elements in PDUs must appear in the same order? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 08:49:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGx1w-0002Du-Uv; Mon, 21 Jan 2008 08:49:40 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGx1v-0002Bn-8o for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 08:49:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGx1u-0002BZ-K9 for yang@ietf.org; Mon, 21 Jan 2008 08:49:38 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGx1u-0005sa-8p for yang@ietf.org; Mon, 21 Jan 2008 08:49:38 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 048A21B80C4; Mon, 21 Jan 2008 14:49:36 +0100 (CET) Date: Mon, 21 Jan 2008 14:50:54 +0100 (CET) Message-Id: <20080121.145054.158522565.mbj@tail-f.com> To: lhotka@cesnet.cz Subject: Re: [YANG] relation to XML PDUs From: Martin Bjorklund In-Reply-To: <1200921746.6914.176.camel@missotis> References: <1200921746.6914.176.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > I understand that YANG data models describe entire configuration > datasets, but do they also pose any restrictions to the NETCONF XML > PDUs? For example: the order of children in a YANG model is fixed - does > it mean that the corresponding XML elements in PDUs must appear in the > same order? Currently we do this, mainly b/c of the requirement to be XSD compatible, i.e. we want to be able to generate an XSD which can be used to validate the PDUs. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 11:21:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGzOl-0006jC-Ry; Mon, 21 Jan 2008 11:21:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JGzOl-0006al-2P for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 11:21:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGzOk-0006RG-B3 for yang@ietf.org; Mon, 21 Jan 2008 11:21:22 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGzOj-0004Z2-QC for yang@ietf.org; Mon, 21 Jan 2008 11:21:22 -0500 Received: (qmail 27234 invoked from network); 21 Jan 2008 16:21:20 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 21 Jan 2008 16:21:20 -0000 X-YMail-OSG: aJCydvQVM1kes14NOxjeZdN.UVS8e8rtFkDjtKTfi4if.GgNmOLZTlxtu1pui3FcnRwFojRzLtmUTcFX7a5AKYR8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4794C67F.1000303@andybierman.com> Date: Mon, 21 Jan 2008 08:21:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] relation to XML PDUs References: <1200921746.6914.176.camel@missotis> <20080121.145054.158522565.mbj@tail-f.com> In-Reply-To: <20080121.145054.158522565.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >> >> I understand that YANG data models describe entire configuration >> datasets, but do they also pose any restrictions to the NETCONF XML >> PDUs? For example: the order of children in a YANG model is fixed - does >> it mean that the corresponding XML elements in PDUs must appear in the >> same order? > > Currently we do this, mainly b/c of the requirement to be XSD > compatible, i.e. we want to be able to generate an XSD which can be > used to validate the PDUs. > Really? Where is that documented? Let's review the NETCONF PDUs so we can stop talking about schema validation in high altitude abstractions. I don't care about abstract requirements, I care about running code. There are 3 types of parameters for RPC operations: 1) XML represents RPC parameter abstractions (e.g., error-option) XSD can validate these RPCs fine. 2) XML represents subtree filter parameters XSD cannot do anything with this. There are no requirements except well formed XML. Unknown namespaces and elements are just 'no-match' conditions, not errors. 3) XML represents config database fragment XSD cannot do much with this unless minOccurs=0 is set for every element and the NETCONF operation attribute is added everywhere it is allowed. I have never seen an XSD that actually does this. Instead they all model the config-database representation, not any particular PDU. The and operations allow arbitrary subsets of config data to be sent in a given PDU, with an almost infinite number of permutations. A subset of those permutations will actually be valid for a given data model. Since YANG models the data, not the XML, the number of 'extra' permutations in a YANG schema can be reduced to almost zero. Andy > > /martin > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 12:02:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH02R-0006JH-Nl; Mon, 21 Jan 2008 12:02:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JH02N-0006IR-NX for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 12:02:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH02N-0006Gw-37 for yang@ietf.org; Mon, 21 Jan 2008 12:02:19 -0500 Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JH02L-0004T5-GB for yang@ietf.org; Mon, 21 Jan 2008 12:02:19 -0500 Received: (qmail 3198 invoked from network); 21 Jan 2008 17:02:14 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 21 Jan 2008 17:02:14 -0000 X-YMail-OSG: eGNJiS4VM1mtUYjrOaa2QNCKs4fOaFsqyOhzc9JLGyYOqn4jwsKarEBL4SxwOQXi10i_col5faAYCVxi3tXeCF87 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4794D016.10107@andybierman.com> Date: Mon, 21 Jan 2008 09:02:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [YANG] keyref X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, The keyref builtin type is confusing. It is not very clear why this needs to be a built-in type, or why all the various forms are needed. What do all these clauses within a leaf mean for a keyref? - units - must - default - config - mandatory What does it mean for a keyref leaf to have different values of these clauses than the leaf for the target of the 'path' statement? Does a keyref variable always contain the value of the variable it points to, or not? If not, when? Can a keyref be status current and the path reference a leaf that is deprecated or obsolete? What are writable keyrefs used for? Why are keyrefs needed within a configuration database? The notification use case in the example below makes sense, but that's it. I would rather have a mechanism within the notification clause to deal with this feature, not a built-in data type that can be used everywhere. --------- 4.2.10. Notification Definitions YANG allows the definition of notifications suitable for NETCONF. YANG data definition statements are used to model the content of the notification. YANG Example: notification link-failure { description "A link failure has been detected"; leaf if-index { type int32 { range "1 .. max"; } } leaf if-name { type keyref { path "/interfaces/interface/name"; } } } NETCONF XML Encoding: 2007-09-01T10:00:00Z so-1/2/3.0 Why is it sufficient to make the if-index leaf an int32 but the if-name needs to be a keyref to something inside the interfaces entry? Clearly, when the notification is generated, both of these values come from a particular interface. --------- From section 8.8.4: leaf mgmt-interface { type keyref { path "../interface/name"; } } The following keyrefs refer to an existing address of an interface: container default-address { leaf ifname { type keyref { path "../../interface/name"; } } leaf address { type keyref { path "../../interface[name = $this/../ifname]/address/ip"; } } } A corresponding XML snippet is e.g.: eth0
192.0.2.1
192.0.2.2
lo
127.0.0.1
eth0 192.0.2.2 IMO, this 2nd form is complicated, and I don't really see why WGs need it, or why they will use it. The simple absolute-schema-nodeid form makes sense to me, as a mechanism within notifications to reference config data that is copied into the notification. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 12:47:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH0k8-0006Ho-LK; Mon, 21 Jan 2008 12:47:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JH0k6-00065P-Nt for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 12:47:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH0k6-00065E-DO for yang@ietf.org; Mon, 21 Jan 2008 12:47:30 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH0k5-0000I2-Vn for yang@ietf.org; Mon, 21 Jan 2008 12:47:30 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id F06F31B80C5; Mon, 21 Jan 2008 18:47:27 +0100 (CET) Date: Mon, 21 Jan 2008 18:46:01 +0100 (CET) Message-Id: <20080121.184601.38475099.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] relation to XML PDUs From: Martin Bjorklund In-Reply-To: <4794C67F.1000303@andybierman.com> References: <1200921746.6914.176.camel@missotis> <20080121.145054.158522565.mbj@tail-f.com> <4794C67F.1000303@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > >> Hi, > >> > >> I understand that YANG data models describe entire configuration > >> datasets, but do they also pose any restrictions to the NETCONF XML > >> PDUs? For example: the order of children in a YANG model is fixed - does > >> it mean that the corresponding XML elements in PDUs must appear in the > >> same order? > > > > Currently we do this, mainly b/c of the requirement to be XSD > > compatible, i.e. we want to be able to generate an XSD which can be > > used to validate the PDUs. > > > > > Really? Where is that documented? In the XML Encoding Rules section of the container statetement (and same for list statement). > Let's review the NETCONF PDUs so we can stop talking about > schema validation in high altitude abstractions. [...] > 3) XML represents config database fragment > XSD cannot do much with this unless minOccurs=0 is set for > every element and the NETCONF operation attribute is added > everywhere it is allowed. I have never seen an XSD that > actually does this. Instead they all model the config-database > representation, not any particular PDU. I'm not protesting here. So if they do model the config-database representation, is the order important in this config-database? Is the NETCONF server supposed to keep an XML instance document representation of the config database, with all elements in order? This sounds like vendor-specific internals... /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 13:11:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH17j-00027j-OB; Mon, 21 Jan 2008 13:11:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JH17i-00027I-Dn for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 13:11:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH17i-00026c-1c for yang@ietf.org; Mon, 21 Jan 2008 13:11:54 -0500 Received: from smtp110.sbc.mail.re2.yahoo.com ([68.142.229.95]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JH17h-0007PV-N0 for yang@ietf.org; Mon, 21 Jan 2008 13:11:54 -0500 Received: (qmail 34986 invoked from network); 21 Jan 2008 18:11:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp110.sbc.mail.re2.yahoo.com with SMTP; 21 Jan 2008 18:11:53 -0000 X-YMail-OSG: MHooHBIVM1l1Dd5ZloWAYrHCnno_jOjtQZk3fJzHdy0kx6MnG6TyteyCS8vaCCQRfi30GhmAl69xtN6DQfwjwVjNVPyl5bgJhWllQmc4ZhF3ZWhsIJbu9Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4794E068.6000708@andybierman.com> Date: Mon, 21 Jan 2008 10:11:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] relation to XML PDUs References: <1200921746.6914.176.camel@missotis> <20080121.145054.158522565.mbj@tail-f.com> <4794C67F.1000303@andybierman.com> <20080121.184601.38475099.mbj@tail-f.com> In-Reply-To: <20080121.184601.38475099.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> I understand that YANG data models describe entire configuration >>>> datasets, but do they also pose any restrictions to the NETCONF XML >>>> PDUs? For example: the order of children in a YANG model is fixed - does >>>> it mean that the corresponding XML elements in PDUs must appear in the >>>> same order? >>> Currently we do this, mainly b/c of the requirement to be XSD >>> compatible, i.e. we want to be able to generate an XSD which can be >>> used to validate the PDUs. >>> >> >> Really? Where is that documented? > > In the XML Encoding Rules section of the container statetement (and > same for list statement). > >> Let's review the NETCONF PDUs so we can stop talking about >> schema validation in high altitude abstractions. > > [...] > >> 3) XML represents config database fragment >> XSD cannot do much with this unless minOccurs=0 is set for >> every element and the NETCONF operation attribute is added >> everywhere it is allowed. I have never seen an XSD that >> actually does this. Instead they all model the config-database >> representation, not any particular PDU. > > I'm not protesting here. So if they do model the config-database > representation, is the order important in this config-database? Is > the NETCONF server supposed to keep an XML instance document > representation of the config database, with all elements in order? > This sounds like vendor-specific internals... > OK -- IMO it is bad to force data model order in NETCONF PDUs. SNMP does not do this for varbinds. It is hard enough on applications just to get every node right, let alone the order of every node. This also goes for RPC methods. Since every RPC method parameter is clearly identified, and an is self-contained, there is no need to force any particular element order in an PDU. But there is still a canonical order (for diff purposes) that is defined as document order. For 'bits' elements, the canonical order of bit names in PDUs is also defined as document order, with all duplicates removed. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 17:06:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH4mG-00005I-UO; Mon, 21 Jan 2008 17:06:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JH4mF-0008MO-90 for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 17:05:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH4mE-0008EC-As for yang@ietf.org; Mon, 21 Jan 2008 17:05:58 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH4mD-0002en-Ii for yang@ietf.org; Mon, 21 Jan 2008 17:05:58 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 6CC0D1B80C5; Mon, 21 Jan 2008 23:05:56 +0100 (CET) Date: Mon, 21 Jan 2008 23:04:29 +0100 (CET) Message-Id: <20080121.230429.148337580.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <4794D016.10107@andybierman.com> References: <4794D016.10107@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Andy, Andy Bierman wrote: > Hi, > > The keyref builtin type is confusing. > It is not very clear why this needs to be a built-in type, It's a type b/c it works as all the other types; you can have a leaf or leaf-list of this type etc. > or why all the various forms are needed. > > What do all these clauses within a leaf mean for a keyref? > - units Not much I think. > - must Same as for other leafs. > - default Same as for other leafs, although it's pretty pointless. > - config Same as for other leafs, except that we don't want to allow a reference from config into non-config (not added to the draft yet). > - mandatory Same as for other leafs. > What does it mean for a keyref leaf to have different values of these clauses > than the leaf for the target of the 'path' statement? See below. > Does a keyref variable always contain the value of the variable > it points to, or not? If not, when? Note that in order to find "the variable it points to", you need the path from the schema, and the value of the keyref leaf. So I guess I don't understand your question. > Can a keyref be status current and the path reference > a leaf that is deprecated or obsolete? Good question. I think that the answer is yes, if the keyref is to another module (since if there is a keyref from module A to module B, and B gets updated, it cannot require A to be updated.) > What are writable keyrefs used for? An example is 'channelIfIndex' from the RMON-MIB. It could have been defined in YANG (ignoring some details about config/non-config) as: leaf channelIfIndex { type keyref { path "/if:interfaces/if:ifEntry/if:ifIndex"; } } The idea is that the keyref formalizes the stuff found in description clauses in mibs: The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object So, writable keyrefs are used to configure relationships. [...] > IMO, this 2nd form is complicated, and I don't really see why WGs > need it, or why they will use it. The simple absolute-schema-nodeid form > makes sense to me, as a mechanism within notifications to reference > config data that is copied into the notification. As soon as the list has more than one leaf as key, you will need this second form. This being said, if anyone can come up with a simpler solution to the problem of having references to multi-keyed lists, it will be more than welcome! /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 21 21:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH8Uw-0005tu-Qe; Mon, 21 Jan 2008 21:04:22 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JH8Uv-0005t5-VB for yang-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 21:04:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH8Uv-0005sx-JS for yang@ietf.org; Mon, 21 Jan 2008 21:04:21 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JH8Uu-0001C2-Tp for yang@ietf.org; Mon, 21 Jan 2008 21:04:21 -0500 Received: (qmail 14798 invoked from network); 22 Jan 2008 02:04:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 22 Jan 2008 02:04:19 -0000 X-YMail-OSG: .6sHVgAVM1nZEjNrliFWRL98L_h3gdywdyUGrBfGiBdSOwAs X-Yahoo-Newman-Property: ymail-3 Message-ID: <47954F24.905@andybierman.com> Date: Mon, 21 Jan 2008 18:04:20 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] keyref References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> In-Reply-To: <20080121.230429.148337580.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Hi Andy, > > Andy Bierman wrote: >> Hi, >> >> The keyref builtin type is confusing. >> It is not very clear why this needs to be a built-in type, > > It's a type b/c it works as all the other types; you can have a leaf > or leaf-list of this type etc. > Why does it work the same as other types. That's kind of a circular definition. I don't see the use case for writable keyrefs. When you read the object the first time, it has the value from the ptarh target, and when you set the keyref leaf, it has the new value and no longer is a reference to the key leaf. Then it changes back to a reference if the manager deletes the keyref leaf? IMO, this should be just another documentation clause, added to a leaf like the current 'description' and 'reference'. I don't understand why this is a data type. Andy >> or why all the various forms are needed. >> >> What do all these clauses within a leaf mean for a keyref? >> - units > > Not much I think. > >> - must > > Same as for other leafs. > >> - default > > Same as for other leafs, although it's pretty pointless. > >> - config > > Same as for other leafs, except that we don't want to allow a > reference from config into non-config (not added to the draft yet). > >> - mandatory > > Same as for other leafs. > >> What does it mean for a keyref leaf to have different values of these clauses >> than the leaf for the target of the 'path' statement? > > See below. > >> Does a keyref variable always contain the value of the variable >> it points to, or not? If not, when? > > Note that in order to find "the variable it points to", you need the > path from the schema, and the value of the keyref leaf. > > So I guess I don't understand your question. > > >> Can a keyref be status current and the path reference >> a leaf that is deprecated or obsolete? > > Good question. I think that the answer is yes, if the keyref is to > another module (since if there is a keyref from module A to module B, > and B gets updated, it cannot require A to be updated.) > >> What are writable keyrefs used for? > > An example is 'channelIfIndex' from the RMON-MIB. It could have been > defined in YANG (ignoring some details about config/non-config) as: > > leaf channelIfIndex { > type keyref { > path "/if:interfaces/if:ifEntry/if:ifIndex"; > } > } > > The idea is that the keyref formalizes the stuff found in description > clauses in mibs: > > The interface identified by a particular value > of this object is the same interface as identified by the > same value of the ifIndex object > > So, writable keyrefs are used to configure relationships. > > [...] > >> IMO, this 2nd form is complicated, and I don't really see why WGs >> need it, or why they will use it. The simple absolute-schema-nodeid form >> makes sense to me, as a mechanism within notifications to reference >> config data that is copied into the notification. > > As soon as the list has more than one leaf as key, you will need this > second form. > > This being said, if anyone can come up with a simpler solution to the > problem of having references to multi-keyed lists, it will be more > than welcome! > > > /martin > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 02:58:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHE1T-00071b-Oi; Tue, 22 Jan 2008 02:58:19 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHE1S-00071V-7s for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 02:58:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHE1K-0006qc-Rd for yang@ietf.org; Tue, 22 Jan 2008 02:58:10 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHE1J-0000b8-M8 for yang@ietf.org; Tue, 22 Jan 2008 02:58:10 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05F4C8A3E6; Tue, 22 Jan 2008 08:58:08 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14496-07; Tue, 22 Jan 2008 08:58:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9D548A37C; Tue, 22 Jan 2008 08:58:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4E70B477992; Tue, 22 Jan 2008 08:58:01 +0100 (CET) Date: Tue, 22 Jan 2008 08:58:01 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] keyref Message-ID: <20080122075801.GA5155@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , yang@ietf.org References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> <47954F24.905@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47954F24.905@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Mon, Jan 21, 2008 at 06:04:20PM -0800, Andy Bierman wrote: > I don't see the use case for writable keyrefs. > When you read the object the first time, it has the value > from the ptarh target, and when you set the keyref leaf, > it has the new value and no longer is a reference to the key leaf. > Then it changes back to a reference if the manager deletes the > keyref leaf? I don't think this is how a keyref works according to my understanding of this thing. > IMO, this should be just another documentation clause, added to a > leaf like the current 'description' and 'reference'. I don't > understand why this is a data type. My understanding is that a keyref type essentially says "this leaf contains a value that is consistent with the type and the semantics of the leaf identified by the attached expression". In SMIv2, we did not have such a mechanism and we used conventions to achieve the same, that is we ended up with TC such as InterfaceIndex that were then usually used for objects that contain values identifying and interface. The keyref mechanism (which I think should be a leafref or something like that since not only keys need to be referenced) allows to make it machine readable who refering to whom, which in the SMIv2 world is not machine readable and thus tools have to resort to heuristics to best guess this information. Of course, there are several aspects here to discuss. First of all, do we need to have machine readable information about who is refering to whom. If so, is a keyref^Hleafref type the correct approach or should this be handled by introducing say a leafref statement. The next question then is whether we want keyrefs^Hleafrefs to maintain consistency with the leaf they are pointing to. In some cases, this will be really useful, in other it might not. Taking the interface example, sometimes I really like to refer to interface #3 regardless how interface #3 is used while in other cases I really like to refer to an interface that has a certain purpose, regardless in which port it happens to be. So I think we would have to support multiple needed semantics - and sometimes these might actually be deployment specific and perhaps reach beyond what is needed in YANG 1.0. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 03:11:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEED-0005xI-Tp; Tue, 22 Jan 2008 03:11:29 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHEEC-0005xC-ME for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 03:11:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEEC-0005x4-BL for yang@ietf.org; Tue, 22 Jan 2008 03:11:28 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHEEB-0000xW-VZ for yang@ietf.org; Tue, 22 Jan 2008 03:11:28 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 8B6CC1B80C5; Tue, 22 Jan 2008 09:11:26 +0100 (CET) Date: Tue, 22 Jan 2008 09:12:46 +0100 (CET) Message-Id: <20080122.091246.105352306.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <47954F24.905@andybierman.com> References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> <47954F24.905@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Why does it work the same as other types. > That's kind of a circular definition. > > I don't see the use case for writable keyrefs. > When you read the object the first time, it has the value > from the ptarh target, and when you set the keyref leaf, > it has the new value and no longer is a reference to the key leaf. > Then it changes back to a reference if the manager deletes the > keyref leaf? That's not how it works. What part of the text supports this interpretation? The idea is that the value space of the keyref type is constrained to the set of values of the existing instances. This means that if you have a keyref to ifIndex, and the interface 1, 3, and 4 exists, the value space is {1, 3, 4}. When setting a leaf of this type, you must set it to one of 1, 3, and 4. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 03:18:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEL2-00079q-6A; Tue, 22 Jan 2008 03:18:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHEL0-00079l-NM for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 03:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEL0-00079d-Dk for yang@ietf.org; Tue, 22 Jan 2008 03:18:30 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHEKy-0002FT-NR for yang@ietf.org; Tue, 22 Jan 2008 03:18:30 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A99328A37C; Tue, 22 Jan 2008 09:18:27 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16178-09; Tue, 22 Jan 2008 09:18:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A91C8A1F5; Tue, 22 Jan 2008 09:18:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E3942477A33; Tue, 22 Jan 2008 09:18:21 +0100 (CET) Date: Tue, 22 Jan 2008 09:18:21 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] keyref Message-ID: <20080122081821.GA5210@elstar.local> Mail-Followup-To: Martin Bjorklund , ietf@andybierman.com, yang@ietf.org References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080122.091246.105352306.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Jan 22, 2008 at 09:12:46AM +0100, Martin Bjorklund wrote: > The idea is that the value space of the keyref type is constrained > to the set of values of the existing instances. But that is time varying. > This means that if you have a keyref to ifIndex, and the interface 1, > 3, and 4 exists, the value space is {1, 3, 4}. When setting a leaf of > this type, you must set it to one of 1, 3, and 4. So what happens if I choose 3 and interface 3 disappears? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 03:43:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEiv-000521-F2; Tue, 22 Jan 2008 03:43:13 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHEiu-00051w-Dy for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 03:43:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEiu-00051o-4P for yang@ietf.org; Tue, 22 Jan 2008 03:43:12 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHEit-0002bP-Px for yang@ietf.org; Tue, 22 Jan 2008 03:43:12 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id C7D1B1B80C5; Tue, 22 Jan 2008 09:43:10 +0100 (CET) Date: Tue, 22 Jan 2008 09:44:30 +0100 (CET) Message-Id: <20080122.094430.48542159.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <20080122081821.GA5210@elstar.local> References: <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> <20080122081821.GA5210@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jan 22, 2008 at 09:12:46AM +0100, Martin Bjorklund wrote: > > > The idea is that the value space of the keyref type is constrained > > to the set of values of the existing instances. > > But that is time varying. Yes. > > This means that if you have a keyref to ifIndex, and the interface 1, > > 3, and 4 exists, the value space is {1, 3, 4}. When setting a leaf of > > this type, you must set it to one of 1, 3, and 4. > > So what happens if I choose 3 and interface 3 disappears? That's why we don't want to allow keyrefs from config to non-config. Maybe this is a use case that we want to support as well. But I don't see the difference between such a ref and a InterfaceIndex type solution. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 03:59:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEyz-0006AE-PF; Tue, 22 Jan 2008 03:59:49 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHEyy-0006A1-Nl for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 03:59:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHEyy-00069s-DQ for yang@ietf.org; Tue, 22 Jan 2008 03:59:48 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHEyy-0001uW-1R for yang@ietf.org; Tue, 22 Jan 2008 03:59:48 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A3D58A413; Tue, 22 Jan 2008 09:59:47 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20857-03-12; Tue, 22 Jan 2008 09:59:42 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 173888A430; Tue, 22 Jan 2008 09:59:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BF414477B88; Tue, 22 Jan 2008 09:59:18 +0100 (CET) Date: Tue, 22 Jan 2008 09:59:18 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] keyref Message-ID: <20080122085918.GC5210@elstar.local> Mail-Followup-To: Martin Bjorklund , ietf@andybierman.com, yang@ietf.org References: <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> <20080122081821.GA5210@elstar.local> <20080122.094430.48542159.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080122.094430.48542159.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Jan 22, 2008 at 09:44:30AM +0100, Martin Bjorklund wrote: > That's why we don't want to allow keyrefs from config to non-config. > > Maybe this is a use case that we want to support as well. But I don't > see the difference between such a ref and a InterfaceIndex type > solution. Well, the InterfaceIndex type just says "the value identifies an interface" - no more no less. The keyref is much more ambitiuous. Despite the fact that it is only usable for keys, your aim is to bind things together such that value changes automatically propagate. This somehow sounds like you want to do several things at once with a single construct. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 04:07:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHF6t-00027n-Qj; Tue, 22 Jan 2008 04:07:59 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHF6r-0001wc-VT for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 04:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHF6r-0001wM-Lb for yang@ietf.org; Tue, 22 Jan 2008 04:07:57 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHF6r-00035W-9b for yang@ietf.org; Tue, 22 Jan 2008 04:07:57 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id AC1401B80C5; Tue, 22 Jan 2008 10:07:56 +0100 (CET) Date: Tue, 22 Jan 2008 10:09:16 +0100 (CET) Message-Id: <20080122.100916.85217348.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <20080122085918.GC5210@elstar.local> References: <20080122081821.GA5210@elstar.local> <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jan 22, 2008 at 09:44:30AM +0100, Martin Bjorklund wrote: > > > That's why we don't want to allow keyrefs from config to non-config. > > > > Maybe this is a use case that we want to support as well. But I don't > > see the difference between such a ref and a InterfaceIndex type > > solution. > > Well, the InterfaceIndex type just says "the value identifies an > interface" - no more no less. The keyref is much more ambitiuous. > Despite the fact that it is only usable for keys, your aim is to bind > things together such that value changes automatically propagate. No, no automatic propagation. See http://www.yang-central.org/twiki/bin/view/Main/YangExamplesExecdNtp for a YANG example. The idea in this example is that there is a list of keys and a list of servers. Each server uses exactly one key, and this is done through a keyref. When you try to set server/key, it will only accept the name of an existing key. If you try to remove the key, the config will not validate. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 04:13:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHFCK-0007cK-SX; Tue, 22 Jan 2008 04:13:36 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHFCK-0007cF-11 for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 04:13:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHFCJ-0007c7-NR for yang@ietf.org; Tue, 22 Jan 2008 04:13:35 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHFCJ-0003B0-4I for yang@ietf.org; Tue, 22 Jan 2008 04:13:35 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB82F8A3F9; Tue, 22 Jan 2008 10:13:34 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22481-01-14; Tue, 22 Jan 2008 10:13:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1077C8A3F2; Tue, 22 Jan 2008 10:13:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B7B24477C84; Tue, 22 Jan 2008 10:13:21 +0100 (CET) Date: Tue, 22 Jan 2008 10:13:21 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] keyref Message-ID: <20080122091321.GA5397@elstar.local> Mail-Followup-To: Martin Bjorklund , ietf@andybierman.com, yang@ietf.org References: <20080122081821.GA5210@elstar.local> <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local> <20080122.100916.85217348.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080122.100916.85217348.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Jan 22, 2008 at 10:09:16AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jan 22, 2008 at 09:44:30AM +0100, Martin Bjorklund wrote: > > > > > That's why we don't want to allow keyrefs from config to non-config. > > > > > > Maybe this is a use case that we want to support as well. But I don't > > > see the difference between such a ref and a InterfaceIndex type > > > solution. > > > > Well, the InterfaceIndex type just says "the value identifies an > > interface" - no more no less. The keyref is much more ambitiuous. > > Despite the fact that it is only usable for keys, your aim is to bind > > things together such that value changes automatically propagate. > > No, no automatic propagation. > > See > http://www.yang-central.org/twiki/bin/view/Main/YangExamplesExecdNtp > for a YANG example. The idea in this example is that there is a list > of keys and a list of servers. Each server uses exactly one key, and > this is done through a keyref. When you try to set server/key, it > will only accept the name of an existing key. If you try to remove > the key, the config will not validate. But if I change the value of key.name of a key referenced by say requestkey, does the value of requestkey change as well? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 04:17:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHFGU-00069U-0O; Tue, 22 Jan 2008 04:17:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHFGR-00069C-U1 for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 04:17:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHFGR-000694-Ga for yang@ietf.org; Tue, 22 Jan 2008 04:17:51 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHFGR-0002Pt-34 for yang@ietf.org; Tue, 22 Jan 2008 04:17:51 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id C5CF91B80D8; Tue, 22 Jan 2008 10:17:49 +0100 (CET) Date: Tue, 22 Jan 2008 10:19:09 +0100 (CET) Message-Id: <20080122.101909.02474480.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <20080122091321.GA5397@elstar.local> References: <20080122085918.GC5210@elstar.local> <20080122.100916.85217348.mbj@tail-f.com> <20080122091321.GA5397@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jan 22, 2008 at 10:09:16AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Jan 22, 2008 at 09:44:30AM +0100, Martin Bjorklund wrote: > > > > > > > That's why we don't want to allow keyrefs from config to non-config. > > > > > > > > Maybe this is a use case that we want to support as well. But I don't > > > > see the difference between such a ref and a InterfaceIndex type > > > > solution. > > > > > > Well, the InterfaceIndex type just says "the value identifies an > > > interface" - no more no less. The keyref is much more ambitiuous. > > > Despite the fact that it is only usable for keys, your aim is to bind > > > things together such that value changes automatically propagate. > > > > No, no automatic propagation. > > > > See > > http://www.yang-central.org/twiki/bin/view/Main/YangExamplesExecdNtp > > for a YANG example. The idea in this example is that there is a list > > of keys and a list of servers. Each server uses exactly one key, and > > this is done through a keyref. When you try to set server/key, it > > will only accept the name of an existing key. If you try to remove > > the key, the config will not validate. > > But if I change the value of key.name of a key referenced by say > requestkey, does the value of requestkey change as well? No. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 08:42:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHJOb-0007UW-Lb; Tue, 22 Jan 2008 08:42:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHJOb-0007Ss-8q for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 08:42:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHJOa-0007FX-J6 for yang@ietf.org; Tue, 22 Jan 2008 08:42:32 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHJOY-0001Nc-05 for yang@ietf.org; Tue, 22 Jan 2008 08:42:30 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F095020CEC; Tue, 22 Jan 2008 14:42:28 +0100 (CET) X-AuditID: c1b4fb3c-a92eabb0000007e0-86-4795f2c4415d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E4C36204D8; Tue, 22 Jan 2008 14:42:28 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 14:42:28 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 14:42:28 +0100 Message-ID: <4795F2C3.4080004@ericsson.com> Date: Tue, 22 Jan 2008 14:42:27 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] keyref References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> In-Reply-To: <20080122.091246.105352306.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2008 13:42:28.0149 (UTC) FILETIME=[A0ED7650:01C85CFC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org So if I have a keyref to ifIndex 3 and then I remove interface with ifIndex 3, that is I get a dangling reference that points into the void, will I have an invalid configuration? If you want to check at delete interface all the leafs that reference the interface, that might not be simple. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> Why does it work the same as other types. >> That's kind of a circular definition. >> >> I don't see the use case for writable keyrefs. >> When you read the object the first time, it has the value >> from the ptarh target, and when you set the keyref leaf, >> it has the new value and no longer is a reference to the key leaf. >> Then it changes back to a reference if the manager deletes the >> keyref leaf? > > That's not how it works. What part of the text supports this > interpretation? The idea is that the value space of the keyref type > is constrained to the set of values of the existing instances. > > This means that if you have a keyref to ifIndex, and the interface 1, > 3, and 4 exists, the value space is {1, 3, 4}. When setting a leaf of > this type, you must set it to one of 1, 3, and 4. > > > > /martin > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 08:50:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHJWY-0000KK-1x; Tue, 22 Jan 2008 08:50:46 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHJWW-0000KA-NX for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 08:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHJWW-0000JD-DQ for yang@ietf.org; Tue, 22 Jan 2008 08:50:44 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHJWO-0001yk-4R for yang@ietf.org; Tue, 22 Jan 2008 08:50:44 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59DDD20175; Tue, 22 Jan 2008 14:50:15 +0100 (CET) X-AuditID: c1b4fb3e-acdecbb0000007e1-52-4795f497eb3b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4B38921147; Tue, 22 Jan 2008 14:50:15 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 14:50:15 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 14:50:14 +0100 Message-ID: <4795F496.7040309@ericsson.com> Date: Tue, 22 Jan 2008 14:50:14 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] keyref References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> In-Reply-To: <20080121.230429.148337580.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2008 13:50:14.0929 (UTC) FILETIME=[B7267010:01C85CFD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org In the Ericsson DML we had something like leaf my-if-status> { type instance-identifier { refers-to /if:interfaces/if:ifEntry/adminStatus; } } and in the XML /if:interfaces/if:ifEntry["if:ifIndex=2"]/adminStatus This is quite simple, it works as a leafref as well, and works with multiple keys. refers-to restricts the kind of instance identifiers you can actually use. The actual XML value is somewhat more complicated, but I think the instance identifier format is quite intuitive even for people unfamiliar with XPATH. Balazs Martin Bjorklund wrote: > As soon as the list has more than one leaf as key, you will need this > second form. > > This being said, if anyone can come up with a simpler solution to the > problem of having references to multi-keyed lists, it will be more > than welcome! > > > /martin > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 09:26:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHK5G-0007mI-3C; Tue, 22 Jan 2008 09:26:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHK5F-0007mB-Fx for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 09:26:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHK5F-0007m3-5Z for yang@ietf.org; Tue, 22 Jan 2008 09:26:37 -0500 Received: from relay.versatel.net ([62.250.3.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHK5E-0004dv-Mm for yang@ietf.org; Tue, 22 Jan 2008 09:26:37 -0500 Received: (qmail 55338 invoked from network); 22 Jan 2008 14:26:34 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Jan 2008 14:26:34 -0000 From: "Bert Wijnen" To: "Balazs Lengyel" , "Martin Bjorklund" Subject: RE: [YANG] keyref Date: Tue, 22 Jan 2008 15:26:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4795F2C3.4080004@ericsson.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs writes: > So if I have a keyref to ifIndex 3 and then I remove interface > with ifIndex 3, that is I get a > dangling reference that points into the void, will I have an > invalid configuration? > > If you want to check at delete interface all the leafs that > reference the interface, that might not be simple. > Let me remind everyone that the referential integrity (specifically for ifIndex) was/is one of the big open issues in the MIB space. It would be good if we can solve it in the NETCONF DML space. Unfortunately, I have no solution to offer at this point. Sorry. > Balazs > Bert _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 09:35:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKDz-0002gg-Ed; Tue, 22 Jan 2008 09:35:39 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHKDx-0002gI-M5 for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 09:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKDx-0002gA-CN for yang@ietf.org; Tue, 22 Jan 2008 09:35:37 -0500 Received: from smtp116.sbc.mail.sp1.yahoo.com ([69.147.64.89]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHKDv-0003jI-0t for yang@ietf.org; Tue, 22 Jan 2008 09:35:37 -0500 Received: (qmail 49804 invoked from network); 22 Jan 2008 14:35:34 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 22 Jan 2008 14:35:33 -0000 X-YMail-OSG: qVhgilwVM1kskm43P1_NLbT8O1hh9zEzQx_3YgHH3QgjbIkW X-Yahoo-Newman-Property: ymail-3 Message-ID: <4795FECC.4090803@andybierman.com> Date: Tue, 22 Jan 2008 06:33:48 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund , ietf@andybierman.com, yang@ietf.org Subject: Re: [YANG] keyref References: <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> <20080122081821.GA5210@elstar.local> <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local> In-Reply-To: <20080122085918.GC5210@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jan 22, 2008 at 09:44:30AM +0100, Martin Bjorklund wrote: > >> That's why we don't want to allow keyrefs from config to non-config. >> >> Maybe this is a use case that we want to support as well. But I don't >> see the difference between such a ref and a InterfaceIndex type >> solution. > IMO, it is not clear what problem is being solved by keyref. There seems to be some assumption that the purpose of all this complexity is justified because of all the value it provides. The InterfaceIndex approach is well-established and simple. leaf mgmt-interface { type keyref { path "/if:interfaces/if:interface/if:ifIndex"; } } leaf mgmt-interface { type if:InterfaceIndex; } Not only is the TC approach simpler, but keyref does not support the ability to hold a 'not-set' value, such as InterfaceIndexOrZero. YANG is also missing the ability to use key leafs from different tables, like SMIv2. This is where keyref/leafref (as a documentation clause) would help: list myIfTable { key myIfIndex; leaf myIfIndex { type if:InterfaceIndex; leafref "/if:interfaces/if:interface/if:ifIndex"; } leaf myInOctets { type smi:Counter32; leafref "/if:interfaces/if:interface/if:ifInOctets"; } } > Well, the InterfaceIndex type just says "the value identifies an > interface" - no more no less. The keyref is much more ambitiuous. > Despite the fact that it is only usable for keys, your aim is to bind > things together such that value changes automatically propagate. This > somehow sounds like you want to do several things at once with a > single construct. > > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 09:44:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKMD-00025f-1j; Tue, 22 Jan 2008 09:44:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHKMC-00025Z-4j for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 09:44:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKMB-00025R-R4 for yang@ietf.org; Tue, 22 Jan 2008 09:44:07 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHKMB-0003uP-Cb for yang@ietf.org; Tue, 22 Jan 2008 09:44:07 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id B6F051B80C5; Tue, 22 Jan 2008 15:44:05 +0100 (CET) Date: Tue, 22 Jan 2008 15:45:25 +0100 (CET) Message-Id: <20080122.154525.119689047.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <4795FECC.4090803@andybierman.com> References: <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local> <4795FECC.4090803@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Not only is the TC approach simpler As Juergen pointed out, there is no formalism to help tools. Also, it becomes awkward to reference mulit-level and/or multi-key instances. > but keyref does not support > the ability to hold a 'not-set' value, such as InterfaceIndexOrZero. Mark it as optional instead - why set to some in-band invalid value? leaf mgmt-interface { mandatory false; type keyref { path "/if:interfaces/if:interface/if:ifIndex"; } } If it is set, it has to point to an existing interface. > YANG is also missing the ability to use key leafs from different > tables, like SMIv2. No: list myIfTable { key myIfIndex; leaf myIfIndex { type keyref { path "/if:interfaces/if:interface/if:ifIndex"; } } } covers this case. > leaf myInOctets { > type smi:Counter32; > leafref "/if:interfaces/if:interface/if:ifInOctets"; > } > } This is a very good example. How can you tell which ifEntry's ifInOctets this myInOctets actually refer to?? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 10:13:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKoh-0001Hp-SG; Tue, 22 Jan 2008 10:13:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHKog-0001HV-QI for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 10:13:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKog-0001HG-GA for yang@ietf.org; Tue, 22 Jan 2008 10:13:34 -0500 Received: from smtp121.sbc.mail.sp1.yahoo.com ([69.147.64.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHKog-00053t-0Y for yang@ietf.org; Tue, 22 Jan 2008 10:13:34 -0500 Received: (qmail 13937 invoked from network); 22 Jan 2008 15:13:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 22 Jan 2008 15:13:33 -0000 X-YMail-OSG: gd5kVi0VM1nKT.WQyzYwtVxiRmDzRH1U6.sooq2B0do8yRzX X-Yahoo-Newman-Property: ymail-3 Message-ID: <479607AD.2040205@andybierman.com> Date: Tue, 22 Jan 2008 07:11:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] keyref References: <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local> <4795FECC.4090803@andybierman.com> <20080122.154525.119689047.mbj@tail-f.com> In-Reply-To: <20080122.154525.119689047.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Not only is the TC approach simpler > > As Juergen pointed out, there is no formalism to help tools. Also, it > becomes awkward to reference mulit-level and/or multi-key instances. > >> but keyref does not support >> the ability to hold a 'not-set' value, such as InterfaceIndexOrZero. > > Mark it as optional instead - why set to some in-band invalid value? > > leaf mgmt-interface { > mandatory false; > type keyref { > path "/if:interfaces/if:interface/if:ifIndex"; > } > } > > If it is set, it has to point to an existing interface. > >> YANG is also missing the ability to use key leafs from different >> tables, like SMIv2. > > No: > > list myIfTable { > key myIfIndex; > leaf myIfIndex { > type keyref { > path "/if:interfaces/if:interface/if:ifIndex"; > } > } > } > > covers this case. > This is basically the same construct, except you have no idea the data type is really InterfaceIndex. IMO, leafref as a documentation clause does the same thing but way simpler. The DM reader should not have to be an expert in Xpath, and need to hunt down the relevant documentation, just to find out a leaf's data type. > >> leaf myInOctets { >> type smi:Counter32; >> leafref "/if:interfaces/if:interface/if:ifInOctets"; >> } >> } > > This is a very good example. How can you tell which ifEntry's > ifInOctets this myInOctets actually refer to?? > You could use any keyref 'path' expression in the leafref argument. IMO, the whole issue of relationships between config database nodes is larger than this keyref clause. The requirements for machine readable object constraint languages and object/entity relationships needs to be documented in detail and agreed upon. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 10:32:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHL6Y-0005M2-Dz; Tue, 22 Jan 2008 10:32:02 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHL6W-0005Er-To for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 10:32:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHL6W-0005Cg-HF for yang@ietf.org; Tue, 22 Jan 2008 10:32:00 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHL6W-000665-36 for yang@ietf.org; Tue, 22 Jan 2008 10:32:00 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8D22320569; Tue, 22 Jan 2008 16:31:59 +0100 (CET) X-AuditID: c1b4fb3e-ab5e9bb0000007e1-00-47960c6fb251 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6D86A20455; Tue, 22 Jan 2008 16:31:59 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 16:31:59 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 16:31:58 +0100 Message-ID: <47960C6E.5060804@ericsson.com> Date: Tue, 22 Jan 2008 16:31:58 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman Subject: Re: [YANG] keyref References: <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> <20080122081821.GA5210@elstar.local> <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local> <4795FECC.4090803@andybierman.com> In-Reply-To: <4795FECC.4090803@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2008 15:31:59.0020 (UTC) FILETIME=[ED78CEC0:01C85D0B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, We are trying to define a formal way to specify relationships between config database nodes. The this problem has many facets - reference to multi-keyed items - reference to leafs versus keys - constraining references to certain items or having free pointers - reference integrity The problem we try to solve is how to define these relations in a way that allows automatic checking. We need some solution, even if we do not solve the complete problem. E.g. I think referential integrity is a too high goal. Balazs Andy Bierman wrote: > IMO, it is not clear what problem is being solved by keyref. > There seems to be some assumption that the purpose of all this > complexity is justified because of all the value it provides. > > The InterfaceIndex approach is well-established and simple. > > leaf mgmt-interface { > type keyref { > path "/if:interfaces/if:interface/if:ifIndex"; > } > } > > leaf mgmt-interface { > type if:InterfaceIndex; > } > > Not only is the TC approach simpler, but keyref does not support > the ability to hold a 'not-set' value, such as InterfaceIndexOrZero. _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 12:02:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHMWV-0002IL-E2; Tue, 22 Jan 2008 12:02:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHMWT-00026B-ML for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 12:02:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHMWT-00023o-Bo for yang@ietf.org; Tue, 22 Jan 2008 12:02:53 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHMWR-0000ir-Nd for yang@ietf.org; Tue, 22 Jan 2008 12:02:53 -0500 Received: (qmail 70421 invoked from network); 22 Jan 2008 17:02:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 22 Jan 2008 17:02:50 -0000 X-YMail-OSG: wg9uuSUVM1lU76EBScNMAll1Oo9_4oHHM6LuxLGN3YbQO2J0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4796213F.5050703@andybierman.com> Date: Tue, 22 Jan 2008 09:00:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Balazs Lengyel Subject: Re: [YANG] keyref References: <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> <20080122081821.GA5210@elstar.local> <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local> <4795FECC.4090803@andybierman.com> <47960C6E.5060804@ericsson.com> In-Reply-To: <47960C6E.5060804@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel wrote: > Hello, > We are trying to define a formal way to specify relationships between > config database nodes. The this problem has many facets > - reference to multi-keyed items > - reference to leafs versus keys > - constraining references to certain items or having free pointers > - reference integrity > > The problem we try to solve is how to define these relations in a way > that allows automatic checking. We need some solution, even if we do not > solve the complete problem. E.g. I think referential integrity is a too > high goal. > Human usability is the highest priority. That has to be balanced with machine readability. Ex 1) become an expert in Xpath first, then hunt around the draft to find out the real data type for 'address' leaf address { type keyref { path "../../interface[name = $this/../ifname]/address/ip"; } } Ex 2) data type for 'address' is in the leaf clause leaf address { type yang:ip-address; leafref "../../interface[name = $this/../ifname]/address/ip"; } Win-win scenario: works for humans, and works for tools. ---- One reason I was confused -- a bug in the example on p. 94-95: container default-address { leaf ifname { type keyref { path "../../interface/name"; } } leaf address { type keyref { path "../../interface[name = $this/../ifname]/address/ip"; } } } OLD: eth0 192.0.2.2 NEW: eth0
192.0.2.2
 > Balazs Andy > > Andy Bierman wrote: >> IMO, it is not clear what problem is being solved by keyref. >> There seems to be some assumption that the purpose of all this >> complexity is justified because of all the value it provides. >> >> The InterfaceIndex approach is well-established and simple. >> >> leaf mgmt-interface { >> type keyref { >> path "/if:interfaces/if:interface/if:ifIndex"; >> } >> } >> >> leaf mgmt-interface { >> type if:InterfaceIndex; >> } >> >> Not only is the TC approach simpler, but keyref does not support >> the ability to hold a 'not-set' value, such as InterfaceIndexOrZero. > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 16:24:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQc2-00086G-6C; Tue, 22 Jan 2008 16:24:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHQc0-00086A-Km for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 16:24:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQc0-000862-3Y for yang@ietf.org; Tue, 22 Jan 2008 16:24:52 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHQbz-0003R5-NI for yang@ietf.org; Tue, 22 Jan 2008 16:24:51 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 65B001B80C5; Tue, 22 Jan 2008 22:24:49 +0100 (CET) Date: Tue, 22 Jan 2008 22:23:18 +0100 (CET) Message-Id: <20080122.222318.78771144.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <4796213F.5050703@andybierman.com> References: <4795FECC.4090803@andybierman.com> <47960C6E.5060804@ericsson.com> <4796213F.5050703@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Ex 2) data type for 'address' is in the leaf clause > > leaf address { > type yang:ip-address; > leafref "../../interface[name = $this/../ifname]/address/ip"; > } > > Win-win scenario: works for humans, and works for tools. Do you want this new 'leafref' statement to have the same semantics as the keyref type? > One reason I was confused -- a bug in the example on p. 94-95: Ok, fixed. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 16:55:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHR5e-0002Xp-Ib; Tue, 22 Jan 2008 16:55:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHR5e-0002Xk-4c for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 16:55:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHR5d-0002Xc-Pb for yang@ietf.org; Tue, 22 Jan 2008 16:55:29 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHR5d-0004YO-8R for yang@ietf.org; Tue, 22 Jan 2008 16:55:29 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C77888A238; Tue, 22 Jan 2008 22:55:27 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00842-08; Tue, 22 Jan 2008 22:55:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CB648A2E0; Tue, 22 Jan 2008 22:55:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D5D9F479031; Tue, 22 Jan 2008 22:55:20 +0100 (CET) Date: Tue, 22 Jan 2008 22:55:20 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Subject: Re: [YANG] keyref Message-ID: <20080122215520.GA6901@elstar.local> Mail-Followup-To: Balazs Lengyel , Martin Bjorklund , yang@ietf.org References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> <4795F496.7040309@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4795F496.7040309@ericsson.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Jan 22, 2008 at 02:50:14PM +0100, Balazs Lengyel wrote: > In the Ericsson DML we had something like > > leaf my-if-status> { > type instance-identifier { > refers-to /if:interfaces/if:ifEntry/adminStatus; > } > } > > and in the XML > > /if:interfaces/if:ifEntry["if:ifIndex=2"]/adminStatus > > This is quite simple, it works as a leafref as well, and works with > multiple keys. refers-to restricts the kind of instance identifiers you can > actually use. The actual XML value is somewhat more complicated, but I > think the instance identifier format is quite intuitive even for people > unfamiliar with XPATH. It is actually unclear to me what the example does. I get back an xpath expression that points to some other object to consult? I believe this is not really the same as the current keyref and this also raises questions related to referential integrity or what if the expression actually refers to a node set with more than 1 node and similar things. I am also not sure management applications and humans like to extrace the ifIndex value 2 out of the expression. And then there is the question why to ship redundant information at run time if it is already hard wired in the scheme? What happens if the expression is not consistent with refers-to? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 17:15:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHROZ-0001Mb-Cg; Tue, 22 Jan 2008 17:15:03 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHROY-0001ML-BI for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 17:15:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHROX-0001KN-Q5 for yang@ietf.org; Tue, 22 Jan 2008 17:15:02 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHROX-00055u-6v for yang@ietf.org; Tue, 22 Jan 2008 17:15:01 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB3C88A24E; Tue, 22 Jan 2008 23:15:00 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02201-06; Tue, 22 Jan 2008 23:14:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F9B88A24A; Tue, 22 Jan 2008 23:14:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9446D47909D; Tue, 22 Jan 2008 23:14:51 +0100 (CET) Date: Tue, 22 Jan 2008 23:14:51 +0100 From: Juergen Schoenwaelder To: Bert Wijnen Subject: Re: [YANG] keyref Message-ID: <20080122221451.GB6901@elstar.local> Mail-Followup-To: Bert Wijnen , Balazs Lengyel , Martin Bjorklund , yang@ietf.org References: <4795F2C3.4080004@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Jan 22, 2008 at 03:26:34PM +0100, Bert Wijnen wrote: > Let me remind everyone that the referential integrity (specifically > for ifIndex) was/is one of the big open issues in the MIB space. > > It would be good if we can solve it in the NETCONF DML space. > > Unfortunately, I have no solution to offer at this point. Sorry. Whether you want to have the config for your wlan card move with the wlan card or be statically bound to the slot you insert your wlan card into is a configuration decision to be taken by the owner of the device. We should not invent DML mechanisms to enforce a specific behaviour in the data model - this will be a failure. Instead, we have to ensure that people can write configurations that are flexible in terms of what is being used to refer to something. The IF-MIB says "here is ifIndex to refer to an interface" (and often the ifIndex is related to physical ports - but it does not have to be this way; it is just common on routers and switches). But we have heard many times that operators really like to refer to an interface name (which on some OSes is a logical interface mapping to a physical interface in some way) or an interface alias (which is something a human has configured to identify the interface connected to a certain customer, whatever physical port is used). I assume that a decent solution will carry some weight and bring us close to configuration templates or other advanced configuration language features (variables and such things) which I assume to be way too ambitious for the IETF to deliver anything useful within this decade. We should instead concentrate on doing basic YANG 1.0 in a timely manner; let early adoptors experiment with advanced features so we have good input based on real world experience for YANG 2.0 if that ever happens. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 19:14:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTFo-0002aA-Hc; Tue, 22 Jan 2008 19:14:08 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHTFn-0002Y4-FS for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 19:14:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTFn-0002Xw-34 for yang@ietf.org; Tue, 22 Jan 2008 19:14:07 -0500 Received: from smtp116.sbc.mail.sp1.yahoo.com ([69.147.64.89]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHTFm-0004Ef-Ly for yang@ietf.org; Tue, 22 Jan 2008 19:14:07 -0500 Received: (qmail 37284 invoked from network); 23 Jan 2008 00:14:05 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 23 Jan 2008 00:14:05 -0000 X-YMail-OSG: jQwyADQVM1l4GvMC4n_GLXiJAX5VPTfZeUJvpKqqaCArZ6_e X-Yahoo-Newman-Property: ymail-3 Message-ID: <47968652.1010600@andybierman.com> Date: Tue, 22 Jan 2008 16:12:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] keyref References: <4795FECC.4090803@andybierman.com> <47960C6E.5060804@ericsson.com> <4796213F.5050703@andybierman.com> <20080122.222318.78771144.mbj@tail-f.com> In-Reply-To: <20080122.222318.78771144.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Ex 2) data type for 'address' is in the leaf clause >> >> leaf address { >> type yang:ip-address; >> leafref "../../interface[name = $this/../ifname]/address/ip"; >> } >> >> Win-win scenario: works for humans, and works for tools. > > Do you want this new 'leafref' statement to have the same semantics as > the keyref type? > > I'm not 100% sure what the semantics are. I do not agree that the set of instances needs to be limited to the current values in use in the leafref target. There are 2 important corner-cases (2 sides of the same one): 1) pre-provisioning creating an entry that points to an instance that represents HW that has not been installed yet. The config sits harmlessly, waiting until the hardware is installed to become active. 2) hot-swap cards As Juergen pointed out with the old SNMP "interface to Chicago" problem, the DM writer does not know if the config for a board that was just removed should be saved or deleted -- only the operator knows that. I want the 'real' type to be used in the type field and the optional leafref-stmt is available to describe whatever relationship the DM writer wants. The description clause SHOULD identify this relationship in plain text as well. >> One reason I was confused -- a bug in the example on p. 94-95: > > Ok, fixed. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 23:00:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHWma-00032s-00; Tue, 22 Jan 2008 23:00:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHWmY-00032j-91 for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 23:00:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHWmX-00031h-TG for yang@ietf.org; Tue, 22 Jan 2008 23:00:09 -0500 Received: from exprod7og105.obsmtp.com ([64.18.2.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHWmV-0000aH-Fa for yang@ietf.org; Tue, 22 Jan 2008 23:00:09 -0500 Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jan 2008 19:59:59 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 19:59:02 -0800 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 m0N3wu975957; Tue, 22 Jan 2008 19:59:02 -0800 (PST) (envelope-from phil@idle.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 m0N3wsub017849; Wed, 23 Jan 2008 03:58:54 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801230358.m0N3wsub017849@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] keyref In-reply-to: <479607AD.2040205@andybierman.com> Date: Tue, 22 Jan 2008 22:58:54 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 03:59:02.0684 (UTC) FILETIME=[4A7525C0:01C85D74] X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >IMO, leafref as a documentation clause does the same thing >but way simpler. The DM reader should not have to be an expert >in Xpath, and need to hunt down the relevant documentation, >just to find out a leaf's data type. Are you saying you prefer this relationship to be defined in English words instead of a formal language? The "description" statement for the leaf can provide the words, but we hope to provide something that a generic manager implementation can use to process module contents. >IMO, the whole issue of relationships between config database nodes is larger >than this keyref clause. The requirements for machine readable >object constraint languages and object/entity relationships needs to >be documented in detail and agreed upon. So you want this issue pushed onto the Requirements Team? Or do you want a distinct requirements effort for this? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Jan 22 23:29:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXEV-0007qe-Go; Tue, 22 Jan 2008 23:29:03 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHXET-0007jm-O2 for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 23:29:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXET-0007je-D0 for yang@ietf.org; Tue, 22 Jan 2008 23:29:01 -0500 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHXES-0001T1-Un for yang@ietf.org; Tue, 22 Jan 2008 23:29:01 -0500 Received: (qmail 12930 invoked from network); 23 Jan 2008 04:29:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 23 Jan 2008 04:29:00 -0000 X-YMail-OSG: fzq66FgVM1lZZ77Rn5EcXKONveMdtvrzHikYyepdcgVTeVqR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4796C299.7010706@andybierman.com> Date: Tue, 22 Jan 2008 20:29:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] keyref References: <200801230358.m0N3wsub017849@idle.juniper.net> In-Reply-To: <200801230358.m0N3wsub017849@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> IMO, leafref as a documentation clause does the same thing >> but way simpler. The DM reader should not have to be an expert >> in Xpath, and need to hunt down the relevant documentation, >> just to find out a leaf's data type. > > Are you saying you prefer this relationship to be defined in English > words instead of a formal language? The "description" statement > for the leaf can provide the words, but we hope to provide something > that a generic manager implementation can use to process module > contents. > I already made a proposal -- instead of a builtin type called keyref there would be an optional clause for a leaf of leaf-list called leafref that has the path-stmt from the keyref as its argument. As a separate matter, it is also good practice to document the leafref in the description clause. >> IMO, the whole issue of relationships between config database nodes is larger >> than this keyref clause. The requirements for machine readable >> object constraint languages and object/entity relationships needs to >> be documented in detail and agreed upon. > > So you want this issue pushed onto the Requirements Team? Or do > you want a distinct requirements effort for this? > I expect the requirements team to write the initial draft. I don't know what the RFC will look like yet. > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 00:10:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXsD-0003jj-7r; Wed, 23 Jan 2008 00:10:05 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHXsC-0003gn-P6 for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 00:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXsC-0003dk-BC for yang@ietf.org; Wed, 23 Jan 2008 00:10:04 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHXsB-00029Y-Nm for yang@ietf.org; Wed, 23 Jan 2008 00:10:04 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tQlR+Ypi/lmcbayRGIdtNeCQQ5n4P6ne2NYXW2zhzTCqAwzOuAdVOw/HEin7Xvva; 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 [69.3.145.174] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JHXrk-00042o-VR for yang@ietf.org; Wed, 23 Jan 2008 00:09:47 -0500 Message-ID: <000801c85d7e$54217380$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200801230358.m0N3wsub017849@idle.juniper.net> Subject: Re: [YANG] keyref Date: Tue, 22 Jan 2008 21:10:26 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117baac027a51f661b534a7cb208a9be2d5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.174 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: > Sent: Tuesday, January 22, 2008 7:58 PM > Subject: Re: [YANG] keyref ... > >IMO, the whole issue of relationships between config database nodes is larger > >than this keyref clause. The requirements for machine readable > >object constraint languages and object/entity relationships needs to > >be documented in detail and agreed upon. > > So you want this issue pushed onto the Requirements Team? Or do > you want a distinct requirements effort for this? ... Would you consider ITU Recommendation X.725 to be a reasonable starting point? (Even if it is a dozen years old, and is based on even older work...) Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 00:13:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXvq-0001BG-O6; Wed, 23 Jan 2008 00:13:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHXvq-0001BA-4a for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 00:13:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXvp-0001Az-QP for yang@ietf.org; Wed, 23 Jan 2008 00:13:49 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHXvp-0007Jw-Ha for yang@ietf.org; Wed, 23 Jan 2008 00:13:49 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WFDMVQ8+7MOZ9JVfecn5qsRC9VtxtOOwHo9GccHAz+U3R4lr/p4We5ViYXn66rTn; 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 [69.3.145.174] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JHXvf-0002iF-KA for yang@ietf.org; Wed, 23 Jan 2008 00:13:40 -0500 Message-ID: <000b01c85d7e$f2291420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200801230358.m0N3wsub017849@idle.juniper.net> <4796C299.7010706@andybierman.com> Subject: Re: [YANG] keyref Date: Tue, 22 Jan 2008 21:15:13 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117e7fe3d0679a24513576202cba5d0d210350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.174 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Tuesday, January 22, 2008 8:29 PM > Subject: Re: [YANG] keyref ... > I expect the requirements team to write the initial draft. > I don't know what the RFC will look like yet. ... Don't hold your breath. We're only putting together an I-D with our view of potential requirements in order to facilitate progress at a BOF. I have no expectation that the work will be all-encompassing, and encourage others to document any requirements they see as important. In any case, I see no point in turning it into an RFC effort. Doing so would only delay progress on the real work even more. Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 00:21:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHY3f-0002jH-Ky; Wed, 23 Jan 2008 00:21:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHY3d-0002er-OS for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 00:21:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHY3d-0002ej-EU for yang@ietf.org; Wed, 23 Jan 2008 00:21:53 -0500 Received: from exprod7og108.obsmtp.com ([64.18.2.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHY3d-0002MX-1k for yang@ietf.org; Wed, 23 Jan 2008 00:21:53 -0500 Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jan 2008 21:21:07 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jan 2008 21:21:18 -0800 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 m0N5LH996232; Tue, 22 Jan 2008 21:21:17 -0800 (PST) (envelope-from phil@idle.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 m0N5LFGR019757; Wed, 23 Jan 2008 05:21:15 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801230521.m0N5LFGR019757@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] keyref In-reply-to: <4796C299.7010706@andybierman.com> Date: Wed, 23 Jan 2008 00:21:15 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 05:21:18.0097 (UTC) FILETIME=[C8316810:01C85D7F] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >Phil Shafer wrote: >> Andy Bierman writes: >>> IMO, leafref as a documentation clause does the same thing >>> but way simpler. The DM reader should not have to be an expert >>> in Xpath, and need to hunt down the relevant documentation, >>> just to find out a leaf's data type. >> >> Are you saying you prefer this relationship to be defined in English >> words instead of a formal language? The "description" statement >> for the leaf can provide the words, but we hope to provide something >> that a generic manager implementation can use to process module >> contents. > >I already made a proposal -- instead of a builtin type called keyref >there would be an optional clause for a leaf of leaf-list called >leafref that has the path-stmt from the keyref as its argument. Your proposal called this a "documentation clause", which implies something targeted to humans and not usable by software. This would be bad, but I would live with a distinct statement for the ref target that is a formal target. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 00:32:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYE3-00064v-4S; Wed, 23 Jan 2008 00:32:39 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHYE2-000619-GD for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 00:32:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYE2-00060x-5g for yang@ietf.org; Wed, 23 Jan 2008 00:32:38 -0500 Received: from exprod7og109.obsmtp.com ([64.18.2.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHYE1-000802-LQ for yang@ietf.org; Wed, 23 Jan 2008 00:32:38 -0500 Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jan 2008 21:29:43 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jan 2008 21:32:15 -0800 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 m0N5WE999827; Tue, 22 Jan 2008 21:32:14 -0800 (PST) (envelope-from phil@idle.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 m0N5W7Tt019859; Wed, 23 Jan 2008 05:32:12 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801230532.m0N5W7Tt019859@idle.juniper.net> To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors In-reply-to: <1200908284.6914.117.camel@missotis> Date: Wed, 23 Jan 2008 00:32:07 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 05:32:15.0514 (UTC) FILETIME=[500B47A0:01C85D81] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka writes: >Relying on common universal >defaults would make the system fragile. As will shipping voluminous defaults. Visibility into defaults is a distinct issue from carrying the defaults in the configuration database. If I have an object with 50 fields where only 2 or 3 are set on each instance, carting around fully-fleshed configs will be incredibly annoying. My view of configuration is that if you set it, it should be there. If you didn't set it, it shouldn't be there. If you want extra information, ask for it. But the normal view of configuration should be restricted to only what the user or application expressed configured. This leads directly to my interpretation of "mandatory". A mandatory config statement is one that some user or application must expressly configure. If the configuration is valid without the statement, then it's not mandatory. The "mandatory"-ness describes the interaction between the device and applications configuring it. If the application must create the statement, then the statement is mandatory. The "mandatory plus default" interpretation Andy's using is more of a description of the interaction between the on-box management software and the other on-box software components. IMHO this is less interesting and more internals that YANG should be describing. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 00:39:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYKS-0004Wt-Js; Wed, 23 Jan 2008 00:39:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHYKR-0004WY-DI for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 00:39:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYKR-0004WQ-3c for yang@ietf.org; Wed, 23 Jan 2008 00:39:15 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHYKO-0002ym-Qu for yang@ietf.org; Wed, 23 Jan 2008 00:39:15 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jan 2008 21:36:12 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jan 2008 21:38:32 -0800 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 m0N5cV901387; Tue, 22 Jan 2008 21:38:32 -0800 (PST) (envelope-from phil@idle.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 m0N5cTT8019908; Wed, 23 Jan 2008 05:38:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801230538.m0N5cTT8019908@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] new pyang errors In-reply-to: <47938C97.6060203@andybierman.com> Date: Wed, 23 Jan 2008 00:38:29 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 05:38:32.0675 (UTC) FILETIME=[30D97B30:01C85D82] X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >IMO, it is important to be able to easily distinguish between >some knob that the agent is not using at all (whatever that >means is DM-specific) vs. a knob that is being used, but which >has the DM-defined default value. Why is this the important distinction? "used" by who? IMHO the important distinction is the one between the application and the device that tell the application what statements the device requires and what it takes to create a valid config. If the config statement is mandatory, the application must provide it for the config to be valid. The application knows that it must get that value, assumably beating it out of the user, and create the mandatory config before committing the configuration. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 00:40:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYLt-0004gf-5s; Wed, 23 Jan 2008 00:40:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHYLs-0004gX-74 for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 00:40:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYLr-0004gP-T0 for yang@ietf.org; Wed, 23 Jan 2008 00:40:43 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHYLr-0008Km-JO for yang@ietf.org; Wed, 23 Jan 2008 00:40:43 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gnaQfrfRkUZQiF0Y7x99D1rnULP5xaZ/QXITQcLZEpC6sXMHkqi+IJS9TJWiTHeI; 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 [69.3.145.174] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JHYLq-0008Re-Rk for yang@ietf.org; Wed, 23 Jan 2008 00:40:43 -0500 Message-ID: <000401c85d82$c082fa40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200801230532.m0N5W7Tt019859@idle.juniper.net> Subject: Re: [YANG] new pyang errors Date: Tue, 22 Jan 2008 21:42:32 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911704f1fca974f0955c33c3634babadca13350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.174 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Ladislav Lhotka" > Cc: > Sent: Tuesday, January 22, 2008 9:32 PM > Subject: Re: [YANG] new pyang errors ... > My view of configuration is that if you set it, it should be there. > If you didn't set it, it shouldn't be there. If you want extra > information, ask for it. But the normal view of configuration > should be restricted to only what the user or application expressed > configured. Strongly disagree. Operationally, one needs to be able to determine what the configuration actually *is*, regardless of whether it was ever expressed by a user or application. > This leads directly to my interpretation of "mandatory". A mandatory > config statement is one that some user or application must expressly > configure. If the configuration is valid without the statement, > then it's not mandatory. ... This is sufficient to configure a device, but it's not configuration management. Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 01:00:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYef-0004MY-8f; Wed, 23 Jan 2008 01:00:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHYee-0004JA-Fp for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:00:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYee-0004IS-5e for yang@ietf.org; Wed, 23 Jan 2008 01:00:08 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHYed-0003KV-Pe for yang@ietf.org; Wed, 23 Jan 2008 01:00:08 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jan 2008 21:59:45 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jan 2008 21:59:53 -0800 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 m0N5xr906306; Tue, 22 Jan 2008 21:59:53 -0800 (PST) (envelope-from phil@idle.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 m0N5xoXf020086; Wed, 23 Jan 2008 05:59:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801230559.m0N5xoXf020086@idle.juniper.net> To: "Randy Presuhn" Subject: Re: [YANG] new pyang errors In-reply-to: <000401c85d82$c082fa40$6801a8c0@oemcomputer> Date: Wed, 23 Jan 2008 00:59:50 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 05:59:53.0891 (UTC) FILETIME=[2C838730:01C85D85] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "Randy Presuhn" writes: >Strongly disagree. Operationally, one needs to be able to >determine what the configuration actually *is*, regardless of >whether it was ever expressed by a user or application. One can use alternative views ("with-defaults") or external information (YANG modules) to acquire this information. The main target of configuration remains (and will remain for some time) the human users. Verbose configurations breed confusion and most of my efforts in my day job are targeted to simplifying configurations and reducing the volume of data human users need to look at. >This is sufficient to configure a device, but it's not >configuration management. I don't follow you here. Please explain how the alternative interpretation of "mandatory" aids in configuration management. Is the "with-defaults" view key to a good solution? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 01:10:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYou-0007iT-G6; Wed, 23 Jan 2008 01:10:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHYot-0007iL-EJ for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:10:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYos-0007hr-7O for yang@ietf.org; Wed, 23 Jan 2008 01:10:42 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHYor-0003UU-Dd for yang@ietf.org; Wed, 23 Jan 2008 01:10:41 -0500 Received: (qmail 33475 invoked from network); 23 Jan 2008 06:10:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 23 Jan 2008 06:10:40 -0000 X-YMail-OSG: j1Br06MVM1nOrg5_96wVtD.3PPmyy7FAc_JguR3gM93k26oU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4796DA75.7090106@andybierman.com> Date: Tue, 22 Jan 2008 22:11:01 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] keyref References: <200801230521.m0N5LFGR019757@idle.juniper.net> In-Reply-To: <200801230521.m0N5LFGR019757@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> IMO, leafref as a documentation clause does the same thing >>>> but way simpler. The DM reader should not have to be an expert >>>> in Xpath, and need to hunt down the relevant documentation, >>>> just to find out a leaf's data type. >>> Are you saying you prefer this relationship to be defined in English >>> words instead of a formal language? The "description" statement >>> for the leaf can provide the words, but we hope to provide something >>> that a generic manager implementation can use to process module >>> contents. >> I already made a proposal -- instead of a builtin type called keyref >> there would be an optional clause for a leaf of leaf-list called >> leafref that has the path-stmt from the keyref as its argument. > > Your proposal called this a "documentation clause", which implies > something targeted to humans and not usable by software. This > would be bad, but I would live with a distinct statement for the > ref target that is a formal target. Yes -- only used like like an optional documentation clause, but the argument would be the same path-stmt from keyref-stmt. > > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 01:21:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYzY-0007AI-7u; Wed, 23 Jan 2008 01:21:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHYzW-0007A2-TU for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:21:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHYzW-00079u-6d for yang@ietf.org; Wed, 23 Jan 2008 01:21:42 -0500 Received: from smtp122.sbc.mail.sp1.yahoo.com ([69.147.64.95]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHYzV-0000oD-IJ for yang@ietf.org; Wed, 23 Jan 2008 01:21:42 -0500 Received: (qmail 46962 invoked from network); 23 Jan 2008 06:21:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 23 Jan 2008 06:21:40 -0000 X-YMail-OSG: cAlJxDMVM1nTVhdr7rHLoZXxoJdRPcWjqvKQRCExkCuwH1S9Xow4oGC1vJoB78Lj7zH5d4CcgQRNpGAcK6OPnGpa X-Yahoo-Newman-Property: ymail-3 Message-ID: <4796DD12.1@andybierman.com> Date: Tue, 22 Jan 2008 22:22:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801230532.m0N5W7Tt019859@idle.juniper.net> In-Reply-To: <200801230532.m0N5W7Tt019859@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> Relying on common universal >> defaults would make the system fragile. > > As will shipping voluminous defaults. huh -- it uses up an extra second of bandwidth so the system is fragile? > > Visibility into defaults is a distinct issue from carrying the > defaults in the configuration database. If I have an object with > 50 fields where only 2 or 3 are set on each instance, carting around > fully-fleshed configs will be incredibly annoying. > > My view of configuration is that if you set it, it should be there. > If you didn't set it, it shouldn't be there. If you want extra > information, ask for it. But the normal view of configuration > should be restricted to only what the user or application expressed > configured. > There are lots of scenarios that cause an operator or application to need to full configuration, not just the values that do not have the default value. Many people (including me) do not view this scenario as the same as the node is not present: 1) relying on external documentation is too costly on the operator and fragile. Only direct response from the agent is sufficient. Looking up answer X to question Y at server Z to find out what agent A will answer when asked question Y is full of problems. 2) augment 'when' clauses could make it confusing as too whether a missing node is because it isn't there or because it has a default value 3) more complex agent conformance and variance mechanisms than the current ones (i.e., none) could make it unclear whether an object is missing due to non-applicability or due to non-conformance. 4) A buggy agent may report all kinds of capabilities and conformance and still set a default to a different value than the document. Andy > This leads directly to my interpretation of "mandatory". A mandatory > config statement is one that some user or application must expressly > configure. If the configuration is valid without the statement, > then it's not mandatory. > > The "mandatory"-ness describes the interaction between the device and > applications configuring it. If the application must create the statement, > then the statement is mandatory. The "mandatory plus default" interpretation > Andy's using is more of a description of the interaction between the on-box > management software and the other on-box software components. IMHO this is > less interesting and more internals that YANG should be describing. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 01:30:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHZ80-0001Ru-Qz; Wed, 23 Jan 2008 01:30:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHZ7z-0001OJ-Rn for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 01:30:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHZ7z-0001LM-Dg for yang@ietf.org; Wed, 23 Jan 2008 01:30:27 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHZ7z-00013d-3D for yang@ietf.org; Wed, 23 Jan 2008 01:30:27 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=U/V1WYdTZwpold6OisfIX/5U29QJwaWWuTsemA7TQFX94Ih+m4PRcISLNxgUINLf; 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 [69.3.145.174] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JHZ7w-000456-HS for yang@ietf.org; Wed, 23 Jan 2008 01:30:24 -0500 Message-ID: <000c01c85d89$b114eb20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200801230559.m0N5xoXf020086@idle.juniper.net> Subject: Re: [YANG] new pyang errors Date: Tue, 22 Jan 2008 22:32:13 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117070de0e6435fc93a1c4a7541bf1e31c8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.174 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, January 22, 2008 9:59 PM > Subject: Re: [YANG] new pyang errors ... > >This is sufficient to configure a device, but it's not > >configuration management. > > I don't follow you here. Please explain how the alternative > interpretation of "mandatory" aids in configuration management. > Is the "with-defaults" view key to a good solution? For real configuration management, I count among the essentials: - the ability to bring a device to a known configuration state - the ability to determine exactly what a device's configuration state is - the ability to store and version this configuration information - the ability to create (provision) this information in advance of deployment - the ability to determine whether a device's actual configuration is the same as its desired configuration The "with-defaults" view sounds like it would help, particulary if a default-ed value isn't known a priori. Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 02:25:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHZyq-00053f-CF; Wed, 23 Jan 2008 02:25:04 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHZyp-00053X-PN for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 02:25:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHZyp-00053K-Af for yang@ietf.org; Wed, 23 Jan 2008 02:25:03 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHZyn-0005fN-CA for yang@ietf.org; Wed, 23 Jan 2008 02:25:02 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 55D75D800C7 for ; Wed, 23 Jan 2008 08:24:58 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <200801230532.m0N5W7Tt019859@idle.juniper.net> References: <200801230532.m0N5W7Tt019859@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 08:24:57 +0100 Message-Id: <1201073097.17304.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v St 23. 01. 2008 v 00:32 -0500: > Ladislav Lhotka writes: > >Relying on common universal > >defaults would make the system fragile. >=20 > As will shipping voluminous defaults. >=20 > Visibility into defaults is a distinct issue from carrying the > defaults in the configuration database. If I have an object with > 50 fields where only 2 or 3 are set on each instance, carting around > fully-fleshed configs will be incredibly annoying. It would be sufficient if managers get the full configuration at the start of each session so that they can be sure what the actual data are. Then edit-configs etc. can include just the necessary parts. And by full configuration I mean exactly this, with no hidden assumptions. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 02:33:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHa7I-00036B-2n; Wed, 23 Jan 2008 02:33:48 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHa7G-00035z-VX for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 02:33:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHa7G-00035p-L2 for yang@ietf.org; Wed, 23 Jan 2008 02:33:46 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHa7E-00065S-RH for yang@ietf.org; Wed, 23 Jan 2008 02:33:46 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD5AE8A3E0; Wed, 23 Jan 2008 08:33:43 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14334-02-2; Wed, 23 Jan 2008 08:33:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DEB98A3DC; Wed, 23 Jan 2008 08:33:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ABED747944C; Wed, 23 Jan 2008 08:33:37 +0100 (CET) Date: Wed, 23 Jan 2008 08:33:37 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [YANG] new pyang errors Message-ID: <20080123073337.GC7105@elstar.local> Mail-Followup-To: Randy Presuhn , yang@ietf.org References: <200801230532.m0N5W7Tt019859@idle.juniper.net> <000401c85d82$c082fa40$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c85d82$c082fa40$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Tue, Jan 22, 2008 at 09:42:32PM -0800, Randy Presuhn wrote: > ... > > My view of configuration is that if you set it, it should be there. > > If you didn't set it, it shouldn't be there. If you want extra > > information, ask for it. But the normal view of configuration > > should be restricted to only what the user or application expressed > > configured. > > Strongly disagree. Operationally, one needs to be able to > determine what the configuration actually *is*, regardless of > whether it was ever expressed by a user or application. I actually don't see the conflict in your statements. Phils agrees to give you the value of all configuration knobs if you ask for it. And yes, from experience with several boxes, I can confirm that getting just the configuration values that were really touched is indeed a nice feature once you are familiar with a device. And many network devices support this in their native CLI - so we might be well adviced to support this compact view as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 02:37:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaAP-0007YT-Nl; Wed, 23 Jan 2008 02:37:01 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHaAO-0007YN-Cj for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 02:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaAN-0007Vn-J5 for yang@ietf.org; Wed, 23 Jan 2008 02:36:59 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHaAN-0006Be-8M for yang@ietf.org; Wed, 23 Jan 2008 02:36:59 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCC098A3E0; Wed, 23 Jan 2008 08:36:58 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14659-01; Wed, 23 Jan 2008 08:36:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 315B08A3DC; Wed, 23 Jan 2008 08:36:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 938234794A6; Wed, 23 Jan 2008 08:36:52 +0100 (CET) Date: Wed, 23 Jan 2008 08:36:52 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080123073652.GD7105@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801230532.m0N5W7Tt019859@idle.juniper.net> <1201073097.17304.22.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201073097.17304.22.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 23, 2008 at 08:24:57AM +0100, Ladislav Lhotka wrote: > It would be sufficient if managers get the full configuration at the > start of each session so that they can be sure what the actual data are. > Then edit-configs etc. can include just the necessary parts. And by full > configuration I mean exactly this, with no hidden assumptions. I disagree. I like to get the full configuration whenever I want it - it should not matter whether this is at the start, the middle, or the end of the session. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 02:40:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaE9-0004B9-9F; Wed, 23 Jan 2008 02:40:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHaE8-0004B2-Kn for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 02:40:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaE8-0004At-B7 for yang@ietf.org; Wed, 23 Jan 2008 02:40:52 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHaE8-0006HY-0L for yang@ietf.org; Wed, 23 Jan 2008 02:40:52 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9A5BAD800C5 for ; Wed, 23 Jan 2008 08:40:51 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <200801230559.m0N5xoXf020086@idle.juniper.net> References: <200801230559.m0N5xoXf020086@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 08:40:51 +0100 Message-Id: <1201074051.17304.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v St 23. 01. 2008 v 00:59 -0500: > "Randy Presuhn" writes: > >Strongly disagree. Operationally, one needs to be able to > >determine what the configuration actually *is*, regardless of > >whether it was ever expressed by a user or application. >=20 > One can use alternative views ("with-defaults") or external information > (YANG modules) to acquire this information. The main target of > configuration remains (and will remain for some time) the human > users. Verbose configurations breed confusion and most of my efforts > in my day job are targeted to simplifying configurations and reducing > the volume of data human users need to look at. >=20 I agree, but im my view of the NETCONF world this (optional) filtering can and should be done at the user's side, by the management application. The size/complexity of the data is not an issue for machine-machine exchange. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 02:44:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaHu-0007y5-Dv; Wed, 23 Jan 2008 02:44:46 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHaHs-0007xy-Kj for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 02:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaHl-0007x1-3N for yang@ietf.org; Wed, 23 Jan 2008 02:44:37 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHaHk-0006Tx-Oj for yang@ietf.org; Wed, 23 Jan 2008 02:44:37 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 411848A3E6; Wed, 23 Jan 2008 08:44:36 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14823-09; Wed, 23 Jan 2008 08:44:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 457B58A3FA; Wed, 23 Jan 2008 08:44:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B7CB0479582; Wed, 23 Jan 2008 08:44:27 +0100 (CET) Date: Wed, 23 Jan 2008 08:44:27 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080123074427.GE7105@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201074051.17304.35.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 23, 2008 at 08:40:51AM +0100, Ladislav Lhotka wrote: > I agree, but im my view of the NETCONF world this (optional) filtering > can and should be done at the user's side, by the management > application. The size/complexity of the data is not an issue for > machine-machine exchange. a) ssh is not going to do that for me anytime soon b) only the device really knows what has been touched c) configuration will always be to some extend proprietary; so your app needs to understand all the proprietary stuff of all your devices d) SNMP failed badly in this space, partly because of b) and c) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 02:48:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaLl-0000nZ-Dk; Wed, 23 Jan 2008 02:48:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHaLk-0000md-Ci for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 02:48:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaLj-0000mQ-Ij for yang@ietf.org; Wed, 23 Jan 2008 02:48:43 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHaLj-00041H-6I for yang@ietf.org; Wed, 23 Jan 2008 02:48:43 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7CEB4D800C5 for ; Wed, 23 Jan 2008 08:48:42 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080123073652.GD7105@elstar.local> References: <200801230532.m0N5W7Tt019859@idle.juniper.net> <1201073097.17304.22.camel@missotis> <20080123073652.GD7105@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 08:48:41 +0100 Message-Id: <1201074521.17304.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v St 23. 01. 2008 v 08:36 +0100: > On Wed, Jan 23, 2008 at 08:24:57AM +0100, Ladislav Lhotka wrote: > =20 > > It would be sufficient if managers get the full configuration at the > > start of each session so that they can be sure what the actual data a= re. > > Then edit-configs etc. can include just the necessary parts. And by f= ull > > configuration I mean exactly this, with no hidden assumptions. >=20 > I disagree. I like to get the full configuration whenever I want it - > it should not matter whether this is at the start, the middle, or the > end of the session. Of course you could get it whenever you want. My point is that it is sufficient to get it from the device once so that no "carting around" takes place. Lada >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 03:26:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHavo-0003VI-No; Wed, 23 Jan 2008 03:26:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHavm-0003VA-DT for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 03:25:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHavl-0003V1-Pj for yang@ietf.org; Wed, 23 Jan 2008 03:25:57 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHavl-0005LU-Cx for yang@ietf.org; Wed, 23 Jan 2008 03:25:57 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9FC33D800C5 for ; Wed, 23 Jan 2008 09:25:56 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080123074427.GE7105@elstar.local> References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 09:25:56 +0100 Message-Id: <1201076756.17304.62.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v St 23. 01. 2008 v 08:44 +0100: > On Wed, Jan 23, 2008 at 08:40:51AM +0100, Ladislav Lhotka wrote: >=20 > > I agree, but im my view of the NETCONF world this (optional) filterin= g > > can and should be done at the user's side, by the management > > application. The size/complexity of the data is not an issue for > > machine-machine exchange. >=20 > a) ssh is not going to do that for me anytime soon It's important that raw ssh works in principle but let's face it - reading and typing NETCONF XML stuff via stdin/stdout is only for masochists. =20 > b) only the device really knows what has been touched I'd like to make sure that my configurations work - as much as possible - even after the device has been replaced by another brand. > c) configuration will always be to some extend proprietary; so your > app needs to understand all the proprietary stuff of all your device= s I don't agree - the whole NETCONF then wouldn't make much sense. That "some extent" must be rather minor IMO. > d) SNMP failed badly in this space, partly because of b) and c) Avoiding hidden assumptions cannot make the situation worse, only better. Lada >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 03:38:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHb7q-0000ul-6K; Wed, 23 Jan 2008 03:38:26 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHb7o-0000u7-Ph for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 03:38:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHb7o-0000s0-BW for yang@ietf.org; Wed, 23 Jan 2008 03:38:24 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHb7n-00080N-MV for yang@ietf.org; Wed, 23 Jan 2008 03:38:24 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F3DEB21420; Wed, 23 Jan 2008 09:38:22 +0100 (CET) X-AuditID: c1b4fb3e-abdeabb0000007e1-59-4796fcfecfdb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E082C2134E; Wed, 23 Jan 2008 09:38:22 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 09:38:22 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 09:38:22 +0100 Message-ID: <4796FCFD.5000102@ericsson.com> Date: Wed, 23 Jan 2008 09:38:21 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> In-Reply-To: <1201076756.17304.62.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 23 Jan 2008 08:38:22.0372 (UTC) FILETIME=[50029640:01C85D9B] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka wrote: > Juergen Schoenwaelder p=C3=AD=C5=A1e v St 23. 01. 2008 v 08:44 +0100: >> On Wed, Jan 23, 2008 at 08:40:51AM +0100, Ladislav Lhotka wrote: >> >>> I agree, but im my view of the NETCONF world this (optional) filterin= g >>> can and should be done at the user's side, by the management >>> application. The size/complexity of the data is not an issue for >>> machine-machine exchange. >> a) ssh is not going to do that for me anytime soon >=20 > It's important that raw ssh works in principle but let's face it - > reading and typing NETCONF XML stuff via stdin/stdout is only for > masochists. > =20 Our testers very often write the NETCONF requests/replies in a file, and = send that over SSH. So while Netconf is not a CLI, we do use raw SSH. I also think operators = stated they like to=20 understand raw output. Balazs _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 03:41:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbAw-0005VI-18; Wed, 23 Jan 2008 03:41:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHbAu-0005VA-OA for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 03:41:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbAu-0005V1-8R for yang@ietf.org; Wed, 23 Jan 2008 03:41:36 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHbAt-0005qG-LH for yang@ietf.org; Wed, 23 Jan 2008 03:41:36 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 419C48A400; Wed, 23 Jan 2008 09:41:34 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19875-06; Wed, 23 Jan 2008 09:41:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 302138A40B; Wed, 23 Jan 2008 09:41:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A0D4447973C; Wed, 23 Jan 2008 09:41:23 +0100 (CET) Date: Wed, 23 Jan 2008 09:41:23 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080123084123.GB7227@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201076756.17304.62.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 23, 2008 at 09:25:56AM +0100, Ladislav Lhotka wrote: > > a) ssh is not going to do that for me anytime soon > > It's important that raw ssh works in principle but let's face it - > reading and typing NETCONF XML stuff via stdin/stdout is only for > masochists. Perhaps real operators are masochists. Seriously, the amount of existing scripting code using CLI interfaces is huge. This is not going to go away. > > b) only the device really knows what has been touched > > I'd like to make sure that my configurations work - as much as possible > - even after the device has been replaced by another brand. There is no contradiction between these two statements so I guess you agree with my statement. ;-) > > c) configuration will always be to some extend proprietary; so your > > app needs to understand all the proprietary stuff of all your devices > > I don't agree - the whole NETCONF then wouldn't make much sense. That > "some extent" must be rather minor IMO. It is an illusion to believe that all router vendors will ship exactly the same feature set. Whether the proprietary configuration knobs will be 1% or 100% we don't know - but it will exist. > > d) SNMP failed badly in this space, partly because of b) and c) > > Avoiding hidden assumptions cannot make the situation worse, only > better. I am not sure which hidden assumptions you have in mind. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 04:01:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbTq-0007gk-Ci; Wed, 23 Jan 2008 04:01:10 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHbTp-0007bE-Gs for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbTp-0007YF-4y for yang@ietf.org; Wed, 23 Jan 2008 04:01:09 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHbTo-000081-NS for yang@ietf.org; Wed, 23 Jan 2008 04:01:09 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9CE9220E2E; Wed, 23 Jan 2008 10:00:53 +0100 (CET) X-AuditID: c1b4fb3c-a92eabb0000007e0-57-47970245737c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5353720E29; Wed, 23 Jan 2008 10:00:53 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 10:00:50 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 10:00:50 +0100 Message-ID: <47970242.1040406@ericsson.com> Date: Wed, 23 Jan 2008 10:00:50 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [YANG] new pyang errors References: <200801230559.m0N5xoXf020086@idle.juniper.net> <000c01c85d89$b114eb20$6801a8c0@oemcomputer> In-Reply-To: <000c01c85d89$b114eb20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2008 09:00:50.0623 (UTC) FILETIME=[73A15CF0:01C85D9E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Randy Presuhn wrote: > The "with-defaults" view sounds like it would help, particulary > if a default-ed value isn't known a priori. Let's not forget that the handling of defaults effect much more then the result of the get-config. IMHO the basic question is simply "does a leaf set only due to it's default exist?" (in the conceptual database). This effects the following: 1) Does it exist? 2) How does edit-config create/delete work on it? E.g. can you create a leaf that already exists(?) due to a default value? 3) If you later explicitly delete a leaf with a default value what happens. Will it cease to exist? Will it automatically pop-up with the default value again? 4) Is there any difference between a leaf set by the default and a leaf explicitly (edit-config replace) set to the same value? I really hope not. 5) Will get-config return such a leaf? It may or may not depending on the implementation or the with-defaults option 6) Will a non-presence container exist if it has leafs set by default? This will effect how edit-config none is handled. 7) Does a "must" statement consider such leafs to exist. I assume yes. Balazs _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 04:03:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbWJ-0003WB-9P; Wed, 23 Jan 2008 04:03:43 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHbWI-0003O9-0b for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:03:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbWH-0003Kd-HW for yang@ietf.org; Wed, 23 Jan 2008 04:03:41 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHbWH-0006b6-22 for yang@ietf.org; Wed, 23 Jan 2008 04:03:41 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 60F2B1B80C6; Wed, 23 Jan 2008 10:03:39 +0100 (CET) Date: Wed, 23 Jan 2008 10:05:01 +0100 (CET) Message-Id: <20080123.100501.15118771.mbj@tail-f.com> To: phil@juniper.net Subject: Re: [YANG] keyref From: Martin Bjorklund In-Reply-To: <200801230521.m0N5LFGR019757@idle.juniper.net> References: <4796C299.7010706@andybierman.com> <200801230521.m0N5LFGR019757@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > >I already made a proposal -- instead of a builtin type called keyref > >there would be an optional clause for a leaf of leaf-list called > >leafref that has the path-stmt from the keyref as its argument. > > Your proposal called this a "documentation clause", which implies > something targeted to humans and not usable by software. This > would be bad, but I would live with a distinct statement for the > ref target that is a formal target. Why is formal redundancy good? If you're using a leafref, the type is well known; it is the type if the target node. But you still have to specify it again. I assume that it would be an error to say that the leaf is of type int32, but the leafref points to a string leaf. This also brings up the question when two types are considered to be equal. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 04:09:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbcM-0003lX-Bg; Wed, 23 Jan 2008 04:09:58 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHbcI-0003l6-Ep for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:09:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbcH-0003kr-Ts for yang@ietf.org; Wed, 23 Jan 2008 04:09:53 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHbcH-0006sY-8D for yang@ietf.org; Wed, 23 Jan 2008 04:09:53 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D261720483; Wed, 23 Jan 2008 10:09:51 +0100 (CET) X-AuditID: c1b4fb3e-afe1dbb0000007e1-71-4797045f531a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE7A52171C; Wed, 23 Jan 2008 10:09:51 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 10:09:51 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 10:09:51 +0100 Message-ID: <4797045E.6010608@ericsson.com> Date: Wed, 23 Jan 2008 10:09:50 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [YANG] new pyang errors References: <200801230559.m0N5xoXf020086@idle.juniper.net> <000c01c85d89$b114eb20$6801a8c0@oemcomputer> <47970242.1040406@ericsson.com> In-Reply-To: <47970242.1040406@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2008 09:09:51.0357 (UTC) FILETIME=[B5EED2D0:01C85D9F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Actually I am much more afraid that we will get complex, non-intuitive answers to these questions then what the answers really are. I (Ericsson) personally live in a simple world. If you put something there it exists, if no it does not. So a default value exists as part of the config, it has effects. For us if a leaf does not exist in the config it has no effect whatsoever. We only use the default at creation time. I hope whatever solution we settle on will not be much more complicated then that for any of the below 7 questions. As I see it with-defaults solves 1 problem from the below 7 that is 14%. Balazs Balazs Lengyel wrote: > > Randy Presuhn wrote: >> The "with-defaults" view sounds like it would help, particularly >> if a default-ed value isn't known a priori. > > Let's not forget that the handling of defaults effect much more then the > result of the get-config. IMHO the basic question is simply "does a leaf > set only due to it's default exist?" (in the conceptual database). > > This effects the following: > 1) Does it exist? > > 2) How does edit-config create/delete work on it? E.g. can you create a > leaf that already exists(?) due to a default value? > > 3) If you later explicitly delete a leaf with a default value what > happens. Will it cease to exist? Will it automatically pop-up with the > default value again? > > 4) Is there any difference between a leaf set by the default and a leaf > explicitly (edit-config replace) set to the same value? > I really hope not. > > 5) Will get-config return such a leaf? > It may or may not depending on the implementation or the with-defaults > option > > 6) Will a non-presence container exist if it has leafs set by default? > This will effect how edit-config none is handled. > > 7) Does a "must" statement consider such leafs to exist. > I assume yes. > > Balazs > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 04:19:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHblv-0002BX-2v; Wed, 23 Jan 2008 04:19:51 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHblu-0002BS-CV for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:19:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHblu-0002BK-2s for yang@ietf.org; Wed, 23 Jan 2008 04:19:50 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHblr-0000tl-LW for yang@ietf.org; Wed, 23 Jan 2008 04:19:50 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 07361D800C5 for ; Wed, 23 Jan 2008 10:19:45 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080123084123.GB7227@elstar.local> References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <20080123084123.GB7227@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 10:19:44 +0100 Message-Id: <1201079984.17304.85.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v St 23. 01. 2008 v 09:41 +0100: > On Wed, Jan 23, 2008 at 09:25:56AM +0100, Ladislav Lhotka wrote: >=20 > > > a) ssh is not going to do that for me anytime soon > >=20 > > It's important that raw ssh works in principle but let's face it - > > reading and typing NETCONF XML stuff via stdin/stdout is only for > > masochists. >=20 > Perhaps real operators are masochists. Seriously, the amount of > existing scripting code using CLI interfaces is huge. This is not > going to go away. Yes, but scripts connected via stdin to ssh are something different. You can then set up a pipeline with a filter that suppresses (or fills in in the opposite direction) the default values - but these could be your default values that needn't necessarily be the same defaults the device uses. =20 >=20 > > > b) only the device really knows what has been touched > >=20 > > I'd like to make sure that my configurations work - as much as possib= le > > - even after the device has been replaced by another brand. >=20 > There is no contradiction between these two statements so I guess you > agree with my statement. ;-) Well, if you only have a diff against factory default configuration of device A and device B has a different one ... >=20 > > > c) configuration will always be to some extend proprietary; so your > > > app needs to understand all the proprietary stuff of all your de= vices > >=20 > > I don't agree - the whole NETCONF then wouldn't make much sense. That > > "some extent" must be rather minor IMO. >=20 > It is an illusion to believe that all router vendors will ship exactly > the same feature set. Whether the proprietary configuration knobs will > be 1% or 100% we don't know - but it will exist. If two devices advertise the same DM then I can assume they both have the knobs that are present in the DM - perhaps others as well. The simpler the DM is, the more likely it is that different vendors accept it. That's why I'd like to remove all constraints that can be handled in a different way, even if it means more data on the wire. >=20 > > > d) SNMP failed badly in this space, partly because of b) and c) > >=20 > > Avoiding hidden assumptions cannot make the situation worse, only > > better. >=20 > I am not sure which hidden assumptions you have in mind. That configuration parameters in the device have certain values even though you haven't seen them. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 04:29:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbvH-00063J-Ed; Wed, 23 Jan 2008 04:29:31 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHbvG-0005xZ-E9 for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:29:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbvF-0005xR-UA for yang@ietf.org; Wed, 23 Jan 2008 04:29:29 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHbvF-0001A2-7v for yang@ietf.org; Wed, 23 Jan 2008 04:29:29 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAD208A3B2; Wed, 23 Jan 2008 10:29:28 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24541-06-15; Wed, 23 Jan 2008 10:29:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05D708A3F9; Wed, 23 Jan 2008 10:28:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 681B2479894; Wed, 23 Jan 2008 10:28:32 +0100 (CET) Date: Wed, 23 Jan 2008 10:28:32 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080123092832.GD7227@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <20080123084123.GB7227@elstar.local> <1201079984.17304.85.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201079984.17304.85.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 23, 2008 at 10:19:44AM +0100, Ladislav Lhotka wrote: [...] Lets just agree to disagree. I count myself in the camp of those operators who believe that 100% portable device configurations are an ideal that will never ever happen. For me, the mission is to find agreement on a standard protocol to exchange configuration data, a standard data modeling language for standard and proprietary configuration data models and with some luck a few widely adopted standard configuration data models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 04:32:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbyA-0001xa-Vy; Wed, 23 Jan 2008 04:32:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHbyA-0001v8-2V for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:32:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHby9-0001uz-ON for yang@ietf.org; Wed, 23 Jan 2008 04:32:29 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHby9-0007c5-Aw for yang@ietf.org; Wed, 23 Jan 2008 04:32:29 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C3B5CD80098 for ; Wed, 23 Jan 2008 10:32:28 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <4796FCFD.5000102@ericsson.com> References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <4796FCFD.5000102@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 10:32:28 +0100 Message-Id: <1201080748.17304.98.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel p=C3=AD=C5=A1e v St 23. 01. 2008 v 09:38 +0100: >=20 > Ladislav Lhotka wrote: > > Juergen Schoenwaelder p=C3=AD=C5=A1e v St 23. 01. 2008 v 08:44 +0100: > >> On Wed, Jan 23, 2008 at 08:40:51AM +0100, Ladislav Lhotka wrote: > >> > >>> I agree, but im my view of the NETCONF world this (optional) filter= ing > >>> can and should be done at the user's side, by the management > >>> application. The size/complexity of the data is not an issue for > >>> machine-machine exchange. > >> a) ssh is not going to do that for me anytime soon > >=20 > > It's important that raw ssh works in principle but let's face it - > > reading and typing NETCONF XML stuff via stdin/stdout is only for > > masochists. > > =20 > Our testers very often write the NETCONF requests/replies in a file, an= d send that over SSH. > So while Netconf is not a CLI, we do use raw SSH. I also think operator= s stated they like to=20 > understand raw output. Of course, developers and testers must sometimes do such awkward things with other network protocols, too. But for production use, the minimum requirement for me is that end users (humans) use a decent readable syntax, which XML generated by a machine isn't. So some processing on the client side will IMO always be necessary. Lada > Balazs >=20 >=20 > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 04:39:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHc4z-0000OQ-14; Wed, 23 Jan 2008 04:39:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHc4x-0000Ih-Cj for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:39:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHc4x-0000Hv-24 for yang@ietf.org; Wed, 23 Jan 2008 04:39:31 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHc4w-0007nA-NQ for yang@ietf.org; Wed, 23 Jan 2008 04:39:30 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5B921D80098 for ; Wed, 23 Jan 2008 10:39:30 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080123092832.GD7227@elstar.local> References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <20080123084123.GB7227@elstar.local> <1201079984.17304.85.camel@missotis> <20080123092832.GD7227@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 10:39:30 +0100 Message-Id: <1201081170.17304.104.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v St 23. 01. 2008 v 10:28 +0100: > Lets just agree to disagree. I count myself in the camp of those > operators who believe that 100% portable device configurations are an > ideal that will never ever happen. Absolutely, but we have to do what we can to allow the portable part to be big as possible, even if it makes life harder to developers, testers and masochists.=20 Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 05:07:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHcW2-00039A-On; Wed, 23 Jan 2008 05:07:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHcW2-000394-2C for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 05:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHcW1-00038w-Od for yang@ietf.org; Wed, 23 Jan 2008 05:07:29 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHcW1-000210-CN for yang@ietf.org; Wed, 23 Jan 2008 05:07:29 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A84E8A336; Wed, 23 Jan 2008 11:07:28 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28925-05-39; Wed, 23 Jan 2008 11:07:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F2C48A435; Wed, 23 Jan 2008 11:06:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 770D2479A03; Wed, 23 Jan 2008 11:06:40 +0100 (CET) Date: Wed, 23 Jan 2008 11:06:40 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080123100640.GA7700@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <20080123084123.GB7227@elstar.local> <1201079984.17304.85.camel@missotis> <20080123092832.GD7227@elstar.local> <1201081170.17304.104.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201081170.17304.104.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 23, 2008 at 10:39:30AM +0100, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v St 23. 01. 2008 v 10:28 +0100: > > > Lets just agree to disagree. I count myself in the camp of those > > operators who believe that 100% portable device configurations are an > > ideal that will never ever happen. > > Absolutely, but we have to do what we can to allow the portable part to > be big as possible, even if it makes life harder to developers, testers > and masochists. But we seem to have fundamental differences about the split of work: - I want the NETCONF server to be authoritative to tell the client what the configuration is, with and without defaults expanded. - You seem to assume some magic processing exists on the manager side which takes what the device reports and modifies it e.g. by patching in defaults yielding a complete config. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 05:08:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHcWo-0004iV-Rj; Wed, 23 Jan 2008 05:08:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHcWn-0004iP-FG for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 05:08:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHcWn-0004iH-4G for yang@ietf.org; Wed, 23 Jan 2008 05:08:17 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHcWm-00006U-Cm for yang@ietf.org; Wed, 23 Jan 2008 05:08:17 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C067721461; Wed, 23 Jan 2008 11:08:15 +0100 (CET) X-AuditID: c1b4fb3e-ad5edbb0000007e1-06-4797120ff6f8 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A690121108; Wed, 23 Jan 2008 11:08:15 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 11:08:15 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 11:08:15 +0100 Message-ID: <4797120E.9020902@ericsson.com> Date: Wed, 23 Jan 2008 11:08:14 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , Martin Bjorklund , yang@ietf.org Subject: Re: [YANG] keyref References: <4794D016.10107@andybierman.com> <20080121.230429.148337580.mbj@tail-f.com> <4795F496.7040309@ericsson.com> <20080122215520.GA6901@elstar.local> In-Reply-To: <20080122215520.GA6901@elstar.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2008 10:08:15.0413 (UTC) FILETIME=[DE835650:01C85DA7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jan 22, 2008 at 02:50:14PM +0100, Balazs Lengyel wrote: >> In the Ericsson DML we had something like >> >> leaf my-if-status> { >> type instance-identifier { >> refers-to /if:interfaces/if:ifEntry/adminStatus; >> } >> } >> >> and in the XML >> >> /if:interfaces/if:ifEntry["if:ifIndex=2"]/adminStatus >> >> This is quite simple, it works as a leafref as well, and works with >> multiple keys. refers-to restricts the kind of instance identifiers you can >> actually use. The actual XML value is somewhat more complicated, but I >> think the instance identifier format is quite intuitive even for people >> unfamiliar with XPATH. > > It is actually unclear to me what the example does. I get back an > xpath expression that points to some other object to consult? [BALAZS]: It gives you a pointer to an object that you should use for whatever reason you need it. E.g. points to a Diameter based server for accounting that a specific subscriber should use. Or points to a status to check before you start a process. > I > believe this is not really the same as the current keyref [BALAZS]: Not exactly. It gives you more freedom, which you might decide to restrict with refers-to. In some case you will not restrict it, but rather use the freedom. > and this > also raises questions related to referential integrity or what if the > expression actually refers to a node set with more than 1 node and > similar things. [BALAZS]: I don't see why this has bigger problems with referential integrity here then keyref. If you only store an ifIndex value and not the full path, the specific interface might still get deleted while you refer to it. In the on-the-wire XML full XPath is not allowed, only identifier syntax, so that should take care of node sets with multiple nodes. It is the same kind of expression we use for augment. That also must point to one specific object; otherwise you get an error. > I am also not sure management applications and humans > like to extrace the ifIndex value 2 out of the expression. And then > there is the question why to ship redundant information at run time if > it is already hard wired in the scheme? [BALAZS]: Yes the specific value in XML is longer, although I don't see it as much more complicated. Anyway humans will usually be aided to write it (GUI, Wizard, tab-extension). > What happens if the expression > is not consistent with refers-to? [BALAZS]: that's an ERROR > > /js [BALAZS]: On the plus side, - it gives you more freedom when you want; you can point anywhere if you don't restrict it with refers-to. - it allows you to refer to leaves - the construct is much easier to understand for the complicated cases then keyref Compare the two examples for a list with two keys: container default-address { leaf ifname { // this is actually not needed as a standalone leaf, only as an auxiliary type keyref { path "../../interface/name"; } } leaf address { type keyref { path "../../interface[name = $this/../ifname]/address/ip"; } } } eth0
192.0.2.2
 ----------------------------------------------------------------------------- leaf default-address { type instance-identifier { refers-to ../../interface/address/ip; } } ../../interface[ifname="eth0"][address="192.0.2.2"]/address/ip -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 07:02:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHeJa-0006Ed-Gz; Wed, 23 Jan 2008 07:02:46 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHeJY-00066G-W9 for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 07:02:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHeJY-00064s-Iy for yang@ietf.org; Wed, 23 Jan 2008 07:02:44 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHeJY-0004RL-5r for yang@ietf.org; Wed, 23 Jan 2008 07:02:44 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A9734D800C7 for ; Wed, 23 Jan 2008 13:02:43 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080123100640.GA7700@elstar.local> References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <20080123084123.GB7227@elstar.local> <1201079984.17304.85.camel@missotis> <20080123092832.GD7227@elstar.local> <1201081170.17304.104.camel@missotis> <20080123100640.GA7700@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 13:02:43 +0100 Message-Id: <1201089763.17304.126.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v St 23. 01. 2008 v 11:06 +0100: >=20 > But we seem to have fundamental differences about the split of work: >=20 > - I want the NETCONF server to be authoritative to tell the client what > the configuration is, with and without defaults expanded. A simpler protocol is better. If you allow this choice, you also have to: 1. extend the NETCONF protocol so that it is able to distinguish=20 between the two cases, 2. carefully specify the semantics of concepts like default values,=20 mandatory versus optional etc. >=20 > - You seem to assume some magic processing exists on the manager side > which takes what the device reports and modifies it e.g. by patching > in defaults yielding a complete config. Why do you call it magic? It's perfectly deterministic and local processing from client's point of view - the application has all information and just does what the user wants. And the user can always check what's going on without caring about what "magic" happened at the remote end. It can efficiently work even with different devices - the factory defaults are not relevant here. It does imply slightly more complexity than raw ssh on the manager side, but for the managed device it is actually simpler - it needn't care about which values in its config datastore differ from factory defaults. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 07:13:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHeTu-00032M-PI; Wed, 23 Jan 2008 07:13:26 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHeTs-00032H-VL for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 07:13:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHeTs-00031R-Jw for yang@ietf.org; Wed, 23 Jan 2008 07:13:24 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHeTs-0004rR-1V for yang@ietf.org; Wed, 23 Jan 2008 07:13:24 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74DA58A24E; Wed, 23 Jan 2008 13:13:23 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09701-07-19; Wed, 23 Jan 2008 13:13:18 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F2578A419; Wed, 23 Jan 2008 13:11:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 05704479CC2; Wed, 23 Jan 2008 13:11:08 +0100 (CET) Date: Wed, 23 Jan 2008 13:11:08 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080123121108.GC7700@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <20080123084123.GB7227@elstar.local> <1201079984.17304.85.camel@missotis> <20080123092832.GD7227@elstar.local> <1201081170.17304.104.camel@missotis> <20080123100640.GA7700@elstar.local> <1201089763.17304.126.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201089763.17304.126.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 23, 2008 at 01:02:43PM +0100, Ladislav Lhotka wrote: > > But we seem to have fundamental differences about the split of work: > > > > - I want the NETCONF server to be authoritative to tell the client what > > the configuration is, with and without defaults expanded. > > A simpler protocol is better. If you allow this choice, you also have > to: > 1. extend the NETCONF protocol so that it is able to distinguish > between the two cases, > 2. carefully specify the semantics of concepts like default values, > mandatory versus optional etc. I think this is why we are discussing these questions here. > > - You seem to assume some magic processing exists on the manager side > > which takes what the device reports and modifies it e.g. by patching > > in defaults yielding a complete config. > > Why do you call it magic? It's perfectly deterministic and local > processing from client's point of view - the application has all > information and just does what the user wants. And the user can always > check what's going on without caring about what "magic" happened at the > remote end. It can efficiently work even with different devices - the > factory defaults are not relevant here. The point is that the application does not really kow whether it has all the information and it is a pain for the user to check this. > It does imply slightly more complexity than raw ssh on the manager side, > but for the managed device it is actually simpler - it needn't care > about which values in its config datastore differ from factory defaults. Lets agree to disagree on this. We won't convince each other. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 07:58:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHfBM-0004Op-9d; Wed, 23 Jan 2008 07:58:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHfBL-0004OZ-7J for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 07:58:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHfBK-0004OR-Sz for yang@ietf.org; Wed, 23 Jan 2008 07:58:18 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHfBK-00064r-Hj for yang@ietf.org; Wed, 23 Jan 2008 07:58:18 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 056F4D800CA for ; Wed, 23 Jan 2008 13:58:18 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <200801230532.m0N5W7Tt019859@idle.juniper.net> References: <200801230532.m0N5W7Tt019859@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Wed, 23 Jan 2008 13:58:18 +0100 Message-Id: <1201093098.17304.156.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v St 23. 01. 2008 v 00:32 -0500: > This leads directly to my interpretation of "mandatory". A mandatory > config statement is one that some user or application must expressly > configure. If the configuration is valid without the statement, > then it's not mandatory. My definition of mandatory: mandatory configuration parameters are those that are essential for device or protocol operation. It doesn't matter whether they are set by the user/application, supplied from non-volatile memory or perhaps even hardwired. A (full) configuration is valid only if it contains all values that are declared as mandatory in the DM.=20 Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 09:17:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgQ5-0003Sx-KP; Wed, 23 Jan 2008 09:17:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHgQ4-0003Sg-Bs for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 09:17:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgQ3-0003SQ-2U for yang@ietf.org; Wed, 23 Jan 2008 09:17:35 -0500 Received: from smtp112.sbc.mail.re2.yahoo.com ([68.142.229.93]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHgQ2-0008El-KM for yang@ietf.org; Wed, 23 Jan 2008 09:17:34 -0500 Received: (qmail 10057 invoked from network); 23 Jan 2008 14:17:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.83.75 with plain) by smtp112.sbc.mail.re2.yahoo.com with SMTP; 23 Jan 2008 14:17:33 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <47974CE3.6050509@andybierman.com> Date: Wed, 23 Jan 2008 06:19:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] keyref References: <4796C299.7010706@andybierman.com> <200801230521.m0N5LFGR019757@idle.juniper.net> <20080123.100501.15118771.mbj@tail-f.com> In-Reply-To: <20080123.100501.15118771.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Phil Shafer wrote: >>> I already made a proposal -- instead of a builtin type called keyref >>> there would be an optional clause for a leaf of leaf-list called >>> leafref that has the path-stmt from the keyref as its argument. >> Your proposal called this a "documentation clause", which implies >> something targeted to humans and not usable by software. This >> would be bad, but I would live with a distinct statement for the >> ref target that is a formal target. > > Why is formal redundancy good? If you're using a leafref, the type is > well known; it is the type if the target node. But you still have to > specify it again. I assume that it would be an error to say that the > leaf is of type int32, but the leafref points to a string leaf. This > also brings up the question when two types are considered to be equal. > The type is not 'well known'. There is a cryptic Xpath expression that contains many prefixes and names. The DM reader first has to understand the Xpath to pick the right one, then go to the top of the file and scan all the import statements to find the module for that prefix, then find that module, then find the correct leaf object within it. If the desired leaf came from a uses expansion, then the object will not be where the Xpath says it is, so all the groupings for all the uses-stmts need to be tracked down and checked. (If the nested leaf is called 'name', or something else generic, good luck finding it with grep.) After all this detective work, the leaf is found, and the DM writer finds the name of the data type for the original leaf. Or the type field in the original leaf could specify this data type and an additional leafref clause can be used by a machine to track down the additional details. IMO this is not formal redundancy from the POV of the DM reader. Maybe it is to a YANG compiler, but the DM reader is top of the food chain here. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 09:46:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgrj-0003Tv-Nj; Wed, 23 Jan 2008 09:46:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHgri-0003Sb-N7 for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 09:46:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgri-0003ST-DT for yang@ietf.org; Wed, 23 Jan 2008 09:46:10 -0500 Received: from smtp107.sbc.mail.mud.yahoo.com ([68.142.198.206]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JHgri-0000nu-1u for yang@ietf.org; Wed, 23 Jan 2008 09:46:10 -0500 Received: (qmail 96739 invoked from network); 23 Jan 2008 14:46:09 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.83.75 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 23 Jan 2008 14:46:08 -0000 X-YMail-OSG: 9uw51TgVM1kxzbPM5_gIdsFwsdCPhWKYENiC267qegGbL82O X-Yahoo-Newman-Property: ymail-3 Message-ID: <4797539A.6060709@andybierman.com> Date: Wed, 23 Jan 2008 06:47:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ladislav Lhotka , yang@ietf.org Subject: Re: [YANG] new pyang errors References: <200801230559.m0N5xoXf020086@idle.juniper.net> <1201074051.17304.35.camel@missotis> <20080123074427.GE7105@elstar.local> <1201076756.17304.62.camel@missotis> <20080123084123.GB7227@elstar.local> <1201079984.17304.85.camel@missotis> <20080123092832.GD7227@elstar.local> <1201081170.17304.104.camel@missotis> <20080123100640.GA7700@elstar.local> In-Reply-To: <20080123100640.GA7700@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Wed, Jan 23, 2008 at 10:39:30AM +0100, Ladislav Lhotka wrote: >> Juergen Schoenwaelder p????e v St 23. 01. 2008 v 10:28 +0100: >> >>> Lets just agree to disagree. I count myself in the camp of those >>> operators who believe that 100% portable device configurations are an >>> ideal that will never ever happen. >> Absolutely, but we have to do what we can to allow the portable part to >> be big as possible, even if it makes life harder to developers, testers >> and masochists. > > But we seem to have fundamental differences about the split of work: > > - I want the NETCONF server to be authoritative to tell the client what > the configuration is, with and without defaults expanded. > > - You seem to assume some magic processing exists on the manager side > which takes what the device reports and modifies it e.g. by patching > in defaults yielding a complete config. > I agree with Juergen, but I don't see what standard vs. vendor knobs has anything to do with the problem. I thought there was resolution on this way back when the with-defaults extension was discussed on the NETCONF/NGO lists. Most of the time it is okay to get the most terse view of the config possible (with-defaults=false), but once in awhile, like when a new device or a new SW version is installed, it is important to get the entire config, with defaults, for verification purposes. Both views need to be supported by a NETCONF agent. > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 15:38:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmLo-00089v-2p; Wed, 23 Jan 2008 15:37:36 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHmLl-00089c-QA for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 15:37:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmLl-00089Q-BF for yang@ietf.org; Wed, 23 Jan 2008 15:37:33 -0500 Received: from exprod7og108.obsmtp.com ([64.18.2.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHmLc-00061M-0U for yang@ietf.org; Wed, 23 Jan 2008 15:37:33 -0500 Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jan 2008 12:36:22 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 12:35:44 -0800 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 m0NKZh904878; Wed, 23 Jan 2008 12:35:43 -0800 (PST) (envelope-from phil@idle.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 m0NKZamr024518; Wed, 23 Jan 2008 20:35:36 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801232035.m0NKZamr024518@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] new pyang errors In-reply-to: <4796DD12.1@andybierman.com> Date: Wed, 23 Jan 2008 15:35:35 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 20:35:44.0078 (UTC) FILETIME=[86DDB6E0:01C85DFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >huh -- it uses up an extra second of bandwidth so the system is fragile? No, the human element is fragile. Having a config file littered with values that the user didn't ask for and doesn't need it a great way to help them ignore the parts of the config that they did ask for and do need. >There are lots of scenarios that cause an operator or application >to need to full configuration, not just the values that do not have >the default value. If you see a value in this, make it an option to . It should not be the default behaviour. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 15:43:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmRW-0002w4-UR; Wed, 23 Jan 2008 15:43:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHmRV-0002vY-SI for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 15:43:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmRV-0002tz-HA for yang@ietf.org; Wed, 23 Jan 2008 15:43:29 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmRV-0000x4-58 for yang@ietf.org; Wed, 23 Jan 2008 15:43:29 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6B098A33A; Wed, 23 Jan 2008 21:43:27 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31177-03; Wed, 23 Jan 2008 21:43:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E2C58A343; Wed, 23 Jan 2008 21:43:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CA964488139; Wed, 23 Jan 2008 21:43:16 +0100 (CET) Date: Wed, 23 Jan 2008 21:43:16 +0100 From: Juergen Schoenwaelder To: Phil Shafer Subject: Re: [YANG] new pyang errors Message-ID: <20080123204316.GB13869@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , yang@ietf.org, Ladislav Lhotka References: <4796DD12.1@andybierman.com> <200801232035.m0NKZamr024518@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801232035.m0NKZamr024518@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Jan 23, 2008 at 03:35:35PM -0500, Phil Shafer wrote: > >There are lots of scenarios that cause an operator or application > >to need to full configuration, not just the values that do not have > >the default value. > > If you see a value in this, make it an option to . > It should not be the default behaviour. Yes, an option for would be the clean solution. It would be nice if the IETF process would allow us to do good engineering and not get us in the way. I think this is not the first time we run into something that really should be "updated" in the NETCONF protocol itself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 15:53:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmbK-0004tZ-Vl; Wed, 23 Jan 2008 15:53:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHmbK-0004tT-0B for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 15:53:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmbJ-0004tL-Mk for yang@ietf.org; Wed, 23 Jan 2008 15:53:37 -0500 Received: from exprod7og108.obsmtp.com ([64.18.2.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHmbJ-0006ib-7A for yang@ietf.org; Wed, 23 Jan 2008 15:53:37 -0500 Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jan 2008 12:52:44 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jan 2008 12:47:58 -0800 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 m0NKlw910558; Wed, 23 Jan 2008 12:47:58 -0800 (PST) (envelope-from phil@idle.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 m0NKlsgC024661; Wed, 23 Jan 2008 20:47:55 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801232047.m0NKlsgC024661@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] new pyang errors In-reply-to: <20080123204316.GB13869@elstar.local> Date: Wed, 23 Jan 2008 15:47:54 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 20:47:58.0652 (UTC) FILETIME=[3CB4CFC0:01C85E01] X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder writes: >Yes, an option for would be the clean solution. > >It would be nice if the IETF process would allow us to do good >engineering and not get us in the way. I think this is not the first >time we run into something that really should be "updated" in the >NETCONF protocol itself. So let's create an internet draft that defines a NETCONF capability which adds an element to called that tells the NETCONF server to include default values in the reply, and to tag them with the "wd:default" attribute set to a value of "true". This should be a simple draft that we can get thru the NETCONF WG in less than two years ;^) Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 15:58:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmfm-0004Rg-BJ; Wed, 23 Jan 2008 15:58:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHmfk-0004RJ-9W for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 15:58:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmfh-0004Pr-TG for yang@ietf.org; Wed, 23 Jan 2008 15:58:11 -0500 Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmfh-0001O2-Df for yang@ietf.org; Wed, 23 Jan 2008 15:58:09 -0500 Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jan 2008 12:57:41 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jan 2008 12:58:04 -0800 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 m0NKw4914920; Wed, 23 Jan 2008 12:58:04 -0800 (PST) (envelope-from phil@idle.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 m0NKw1MF024713; Wed, 23 Jan 2008 20:58:01 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801232058.m0NKw1MF024713@idle.juniper.net> To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors In-reply-to: <1201093098.17304.156.camel@missotis> Date: Wed, 23 Jan 2008 15:58:00 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 20:58:04.0492 (UTC) FILETIME=[A5D0A8C0:01C85E02] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka writes: >My definition of mandatory: mandatory configuration parameters are those >that are essential for device or protocol operation. It doesn't matter >whether they are set by the user/application, supplied from non-volatile >memory or perhaps even hardwired. Why would you need or want to mark is as mandatory if the value is hardwired? What are you trying to say by calling a parameter "mandatory" and who are you trying to say it to? If the application need do nothing with such hardwired parameters, why does it need to distinquish them? If the device need to nothing ? YANG defines constraints on the XML that passes between the client and server. Nearly every statement in a YANG module defines a rule which that XML must follow, both during protocol operations and the valid configuration being built. Mandatory is such a constraint, and should be an indication to the NETCONF client application that it needs to do something explicit to satisfy this constraint. If the mandatory parameter isn't set, the configuration isn't valid. If we allow this mandatory constraint to be satisfied via mechanisms that do not involve the client and server, why have it? How is the application to discern the difference between a real constraint and a parameter that the fairy god mother daemon fills in? >A (full) configuration is valid only >if it contains all values that are declared as mandatory in the DM. This is a definition that both sides of the debate can love, which is a problem. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 15:58:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmfs-0004Uq-JV; Wed, 23 Jan 2008 15:58:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHmfr-0004Uh-Sp for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 15:58:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmfr-0004UY-Hf for yang@ietf.org; Wed, 23 Jan 2008 15:58:19 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmfr-0001Ob-6C for yang@ietf.org; Wed, 23 Jan 2008 15:58:19 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 6A6991B80C3; Wed, 23 Jan 2008 21:58:17 +0100 (CET) Date: Wed, 23 Jan 2008 21:56:43 +0100 (CET) Message-Id: <20080123.215643.45475544.mbj@tail-f.com> To: phil@juniper.net Subject: Re: [YANG] new pyang errors From: Martin Bjorklund In-Reply-To: <200801232047.m0NKlsgC024661@idle.juniper.net> References: <20080123204316.GB13869@elstar.local> <200801232047.m0NKlsgC024661@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > So let's create an internet draft that defines a NETCONF capability > which adds an element to called that > tells the NETCONF server to include default values in the > reply, and to tag them with the "wd:default" attribute set to a > value of "true". This should be a simple draft that we can get > thru the NETCONF WG in less than two years ;^) Andy has already defined such a capability in one of his drafts (I forgot which one...). FWIW it's already implemented by >=2 implementations. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Wed Jan 23 16:18:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmz8-0002Qo-N9; Wed, 23 Jan 2008 16:18:14 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHmz7-0002Qj-4v for yang-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 16:18:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmz6-0002Qb-Qr for yang@ietf.org; Wed, 23 Jan 2008 16:18:12 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmz6-0002Em-9b for yang@ietf.org; Wed, 23 Jan 2008 16:18:12 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jan 2008 13:11:46 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jan 2008 13:16:30 -0800 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 m0NLGT923137; Wed, 23 Jan 2008 13:16:29 -0800 (PST) (envelope-from phil@idle.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 m0NLGQNp024913; Wed, 23 Jan 2008 21:16:26 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801232116.m0NLGQNp024913@idle.juniper.net> To: Martin Bjorklund Subject: Re: [YANG] new pyang errors In-reply-to: <20080123.215643.45475544.mbj@tail-f.com> Date: Wed, 23 Jan 2008 16:16:26 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Jan 2008 21:16:30.0159 (UTC) FILETIME=[38D80DF0:01C85E05] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: yang@ietf.org, lhotka@cesnet.cz X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund writes: >Andy has already defined such a capability in one of his drafts (I >forgot which one...). http://www3.ietf.org/internet-drafts/draft-bierman-ncx-ext-00.txt This defines a set of protocol extensions: 2.1. test-only Enumeration . . . . . . . . . . . . . . . . . . 5 2.2. with-defaults Attribute . . . . . . . . . . . . . . . . . 7 2.3. with-metadata Attribute . . . . . . . . . . . . . . . . . 9 2.4. last-modified Attribute . . . . . . . . . . . . . . . . . 11 IMHO these should be distinct capabilities, since this is the way NETCONF allows for such extensions. One odd line (on first read) is: The 'with-defaults' attribute is defined in the namespace specified as the 'targetNamespace' in Section 3. However, an agent should accept it even if no namespace is used. This seems to play fast and loose with XML namespaces, which isn't a good idea. Another issue is that the draft puts these as attributes on the , instead of putting them inside the proper operations: If the 'with-defaults' attribute is present in the element, for any of the protocol operations which return the contents of a configuration database, the agent will use the 'with-defaults' value to control default suppression. I'm also missing where the metadata returned with with-metadata is defined. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 03:32:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHxVr-0001id-J2; Thu, 24 Jan 2008 03:32:43 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHxVq-0001iS-Cp for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 03:32:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHxVi-0001iC-Jg for yang@ietf.org; Thu, 24 Jan 2008 03:32:34 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHxVh-00036T-Uv for yang@ietf.org; Thu, 24 Jan 2008 03:32:34 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BB034D800C4 for ; Thu, 24 Jan 2008 09:32:28 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <200801232058.m0NKw1MF024713@idle.juniper.net> References: <200801232058.m0NKw1MF024713@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 24 Jan 2008 09:32:28 +0100 Message-Id: <1201163548.20662.71.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v St 23. 01. 2008 v 15:58 -0500: > Ladislav Lhotka writes: > >My definition of mandatory: mandatory configuration parameters are tho= se > >that are essential for device or protocol operation. It doesn't matter > >whether they are set by the user/application, supplied from non-volati= le > >memory or perhaps even hardwired. >=20 > Why would you need or want to mark is as mandatory if the value > is hardwired? What are you trying to say by calling a parameter > "mandatory" and who are you trying to say it to? Example: there are many devices out there that have fixed Ethernet MTU value (1500). Such a device can certainly use a DM that specifies MTU as mandatory. It will just fill in this slot with the hardwired value and report a run-time error if a client tries to change it. =20 >=20 > If the application need do nothing with such hardwired parameters, > why does it need to distinquish them? The application needs to know what the value is (as in the case of MTU). I don't want to rely on out-of-band resources. We also have get-config, not only edit-config. >=20 > If the device need to nothing ? >=20 > YANG defines constraints on the XML that passes between the client and > server. Nearly every statement in a YANG module defines a rule which > that XML must follow, both during protocol operations and the valid > configuration being built. I don't agree. YANG models mostly define constraints on the entire content of the config datastore, less so on the XML PDUs. >=20 > Mandatory is such a constraint, and should be an indication to the > NETCONF client application that it needs to do something explicit > to satisfy this constraint. If the mandatory parameter isn't set, > the configuration isn't valid. I disagree again: this would mean you cannot change the factory default configuration part by part. Should the factory default configuration be marked invalid until the client application touches all mandatory values? >=20 > If we allow this mandatory constraint to be satisfied via mechanisms > that do not involve the client and server, why have it? How is the > application to discern the difference between a real constraint and > a parameter that the fairy god mother daemon fills in? The mandatory/optional property should be specified by the data modeller and not depend on the way how it is implemented in different devices. Example: in an authentication database DM, the login, uid and password are mandatory while full-name is optional. IMO this DM is perfectly usable also by devices that either (i) don't implement the full-name slot, or even (ii) allow only one user - so, login=3Dadmin and uid=3D0 are effectively hardwired. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 03:48:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHxlX-0006QL-HD; Thu, 24 Jan 2008 03:48:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHxlV-0006QA-8J for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 03:48:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHxlU-0006Q1-RL for yang@ietf.org; Thu, 24 Jan 2008 03:48:52 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHxlU-0003WJ-EL for yang@ietf.org; Thu, 24 Jan 2008 03:48:52 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6B49520D63; Thu, 24 Jan 2008 09:48:51 +0100 (CET) X-AuditID: c1b4fb3c-aa2ecbb0000007e0-81-479850f3b412 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4F8F7209F2; Thu, 24 Jan 2008 09:48:51 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:48:51 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:48:50 +0100 Message-ID: <479850F2.8090106@ericsson.com> Date: Thu, 24 Jan 2008 09:48:50 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801232035.m0NKZamr024518@idle.juniper.net> In-Reply-To: <200801232035.m0NKZamr024518@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2008 08:48:50.0802 (UTC) FILETIME=[F0FF2520:01C85E65] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org For us the default would be: give me the full config with all defaults; and the option, without-defaults. But I agree that both solutions have value. Balazs Phil Shafer wrote: > Andy Bierman writes: >> huh -- it uses up an extra second of bandwidth so the system is fragile? > > No, the human element is fragile. Having a config file littered > with values that the user didn't ask for and doesn't need it a > great way to help them ignore the parts of the config that they > did ask for and do need. > >> There are lots of scenarios that cause an operator or application >> to need to full configuration, not just the values that do not have >> the default value. > > If you see a value in this, make it an option to . > It should not be the default behaviour. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 04:08:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHy4D-0007gp-PU; Thu, 24 Jan 2008 04:08:13 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JHy4C-0007gh-47 for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 04:08:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHy4B-0007gZ-Nk for yang@ietf.org; Thu, 24 Jan 2008 04:08:11 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHy4B-00049J-1z for yang@ietf.org; Thu, 24 Jan 2008 04:08:11 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 79B0B215C7; Thu, 24 Jan 2008 10:08:10 +0100 (CET) X-AuditID: c1b4fb3e-acdecbb0000007e1-ec-4798557aea09 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5BE05215BD; Thu, 24 Jan 2008 10:08:10 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 10:08:10 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 10:08:10 +0100 Message-ID: <47985579.8000409@ericsson.com> Date: Thu, 24 Jan 2008 10:08:09 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801232058.m0NKw1MF024713@idle.juniper.net> In-Reply-To: <200801232058.m0NKw1MF024713@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2008 09:08:10.0050 (UTC) FILETIME=[A3F65A20:01C85E68] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Just to give you example of the need for fixed values: Due to our need to map YANG data to LDAP, we need a key on all encapsulating objects. So we have to use lists instead of containers, even where we know there will only be one list entry. Often the key for such single entry lists is fixed, but still needed. So this key is config , mandatory, and fixed. Balazs Phil Shafer wrote: > Why would you need or want to mark is as mandatory if the value > is hardwired? What are you trying to say by calling a parameter > "mandatory" and who are you trying to say it to? > > If the application need do nothing with such hardwired parameters, > why does it need to distinquish them? > > If the device need to nothing ? > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 09:37:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3Cu-0001yv-QZ; Thu, 24 Jan 2008 09:37:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI3Cu-0001yq-At for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 09:37:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3Ct-0001yi-4v for yang@ietf.org; Thu, 24 Jan 2008 09:37:31 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI3Cs-0005zQ-L2 for yang@ietf.org; Thu, 24 Jan 2008 09:37:31 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id A0F4C1B80DA for ; Thu, 24 Jan 2008 15:37:28 +0100 (CET) Date: Thu, 24 Jan 2008 15:38:53 +0100 (CET) Message-Id: <20080124.153853.210376606.mbj@tail-f.com> To: yang@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [YANG] errors X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, We have been talking about adding two new statements related to error generation to YANG. The first statement is 'error'. It is used to define a named error. The second statement is 'raise-error'. For example: error no-matches { error-tag operation-failed; description "Generated if the filters return an empty node set."; } rpc partial-lock { input { ... } output { ... } raise-error no-matches; } XML: application operation-failed error no-matches The idea is that the error statement is used to define DM-specfic error messages. An error is identified by its error-app-tag. All errors are defined on the top-level in the module. The raise-error statement is used to reference an error, either local in the same module, or imported from some other module. It will replace the current error-app-tag/error-message statements in YANG (can be specified for must, range, length, and pattern). It can also be used in the rpc statement, as shown above. error bad-ethernet-mtu { error-tag invalid-value; error-message "An ethernet MTU must be 1500"; } must "ifType != ethernet or " + "(ifType == ethernet and ifMTU == 1500)" { raise-error bad-ethernet-mtu; } The errors defined for an rpc would be in addition to the standard errors defined in rfc4741. Grammar: error-stmt = error-keyword sep error-app-tag-str optsep "{" ; error-app-tag-str is an identifier error-tag-stmt stmtsep [error-message-stmt stmtsep] [error-severity-stmt stmtsep] ; default is error [description-stmt stmtsep] [reference-stmt stmtsep] "}" raise-error error-app-tag-ref-str stmtsep Comments? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 10:15:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3nh-0007E5-D7; Thu, 24 Jan 2008 10:15:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI3ng-0007E0-Mh for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:15:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3ng-0007Do-4w for yang@ietf.org; Thu, 24 Jan 2008 10:15:32 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI3nd-0006gN-Rw for yang@ietf.org; Thu, 24 Jan 2008 10:15:32 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 07:15:05 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jan 2008 07:15:08 -0800 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 m0OFF8929766; Thu, 24 Jan 2008 07:15:08 -0800 (PST) (envelope-from phil@idle.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 m0OFF2IF029687; Thu, 24 Jan 2008 15:15:02 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801241515.m0OFF2IF029687@idle.juniper.net> To: Balazs Lengyel Subject: Re: [YANG] new pyang errors In-reply-to: <47985579.8000409@ericsson.com> Date: Thu, 24 Jan 2008 10:15:01 -0500 From: Phil Shafer X-OriginalArrivalTime: 24 Jan 2008 15:15:08.0835 (UTC) FILETIME=[E82E4F30:01C85E9B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel writes: >So this key is config , mandatory, and fixed. Keys are always mandatory in YANG, and have no default. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 10:31:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI42w-0001lJ-07; Thu, 24 Jan 2008 10:31:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI42u-0001kx-Nl for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:31:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI42u-0001kN-77 for yang@ietf.org; Thu, 24 Jan 2008 10:31:16 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI42t-00085e-TP for yang@ietf.org; Thu, 24 Jan 2008 10:31:16 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 684B28A359; Thu, 24 Jan 2008 16:31:14 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 32730-01-25; Thu, 24 Jan 2008 16:31:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 700438A32F; Thu, 24 Jan 2008 16:30:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8D96E489B63; Thu, 24 Jan 2008 16:30:38 +0100 (CET) Date: Thu, 24 Jan 2008 16:30:38 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] errors Message-ID: <20080124153038.GD15941@elstar.local> Mail-Followup-To: Martin Bjorklund , yang@ietf.org References: <20080124.153853.210376606.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080124.153853.210376606.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 24, 2008 at 03:38:53PM +0100, Martin Bjorklund wrote: > We have been talking about adding two new statements related to > error generation to YANG. [...] > Comments? I like it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 10:50:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4LD-0004G2-Vh; Thu, 24 Jan 2008 10:50:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI4LC-00045n-AE for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4LB-00043G-VZ for yang@ietf.org; Thu, 24 Jan 2008 10:50:09 -0500 Received: from exprod7og102.obsmtp.com ([64.18.2.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI4LB-00082Y-8V for yang@ietf.org; Thu, 24 Jan 2008 10:50:09 -0500 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 07:50:00 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 07:49:56 -0800 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 m0OFnu940565; Thu, 24 Jan 2008 07:49:56 -0800 (PST) (envelope-from phil@idle.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 m0OFnqLn029930; Thu, 24 Jan 2008 15:49:52 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801241549.m0OFnqLn029930@idle.juniper.net> To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors In-reply-to: <1201163548.20662.71.camel@missotis> Date: Thu, 24 Jan 2008 10:49:52 -0500 From: Phil Shafer X-OriginalArrivalTime: 24 Jan 2008 15:49:56.0608 (UTC) FILETIME=[C4973000:01C85EA0] X-Spam-Score: -4.0 (----) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka writes: >Example: there are many devices out there that have fixed Ethernet MTU >value (1500). Such a device can certainly use a DM that specifies MTU as >mandatory. It will just fill in this slot with the hardwired value and >report a run-time error if a client tries to change it. We're crosstalking on the meaning of mandatory again. My question is what's the difference between: leaf mtu { type uint; default 1500; mandatory false; } and: leaf mtu { type uint; default 1500; mandatory true; } What am I adding by having mandatory set to true? What is the mandatory flag adding? In my view of "mandatory", the mandatory flag means the client must set this, but the server has a default which should be used for this, so I'm not seeing why the client should be forced to send the server information the server already knows. >The application needs to know what the value is (as in the case of MTU). >I don't want to rely on out-of-band resources. We also have get-config, >not only edit-config. The application _has_ to rely on meta data to find the value for leafs in objects that don't exist. Even with the :with-defaults capability, you won't see defaults for stuff that doesn't exist. A YANG module defines a data model. The client and server agree to abide by the constraints and meanings defined in that data model. Applications can read this model and understand the data that is being manipulated. The YANG module is by definition out-of-band, since it's metadata. If you don't want out-of-band resources, what's your interest in YANG? How do you see this helping you? >> YANG defines constraints on the XML that passes between the client and >> server. Nearly every statement in a YANG module defines a rule which >> that XML must follow, both during protocol operations and the valid >> configuration being built. > >I don't agree. YANG models mostly define constraints on the entire >content of the config datastore, less so on the XML PDUs. In defining what's valid in the datastore, we implicitly define what's valid in the XML. If the model says: leaf mtu { type uint { range 576..8192; } } then you cannot send xml that looks like: hot-dog 10 infinitiy minus 3 not >> Mandatory is such a constraint, and should be an indication to the >> NETCONF client application that it needs to do something explicit >> to satisfy this constraint. If the mandatory parameter isn't set, >> the configuration isn't valid. > >I disagree again: this would mean you cannot change the factory default >configuration part by part. Should the factory default configuration be >marked invalid until the client application touches all mandatory >values? I don't follow your argument here. If the factory default config for a box doesn't follow the rules defined in the data models supported by that box, then there's a bug somewhere. The data model defines what's valid config, so if you don't follow the rules, you don't have valid config. If a parameter is tagged as mandatory in the model, it must appear in the factory-shipped config. >> If we allow this mandatory constraint to be satisfied via mechanisms >> that do not involve the client and server, why have it? How is the >> application to discern the difference between a real constraint and >> a parameter that the fairy god mother daemon fills in? > >The mandatory/optional property should be specified by the data modeller >and not depend on the way how it is implemented in different devices. Completely agree with you, but I don't see a conflict between your point and mine. >Example: in an authentication database DM, the login, uid and password >are mandatory while full-name is optional. IMO this DM is perfectly >usable also by devices that either >(i) don't implement the full-name slot, or even Here I completely and strongly disagree. A data model defines how data works. If you tell a client that your support this data model and you don't implement "full-name", your telling a fib. Customers will catch you and bludgeon you about the head and shoulders. A data model is a contract. A client application should have faith that you are abiding by that contract. YANG doesn't have a compliance mechanism to allow you to avoid parts of the contract, but does have "augment" to allow you to extend the contract with additional information if required. But if your box doesn't have a place to put "full-name", it shouldn't be advertising the capability for that data model. We're looking to build strong and binding underpinning for future data models and the applications that rely on them. If a box doesn't abide by a data model that it advertises, it's a bug. >(ii) allow only one user - so, login=admin and uid=0 are effectively >hardwired. Then your factory default config should look like: system { login { user admin { uid 0; } } } We should note that YANG does not cover factory-default configs. But factory-default configs should follow the rules in the YANG data model. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 11:10:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4ew-0007XP-2K; Thu, 24 Jan 2008 11:10:34 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI4et-0007KL-SQ for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 11:10:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4et-0007Fv-Bi for yang@ietf.org; Thu, 24 Jan 2008 11:10:31 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI4es-000182-Ul for yang@ietf.org; Thu, 24 Jan 2008 11:10:31 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 08:10:28 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 08:09:16 -0800 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 m0OG9F946807; Thu, 24 Jan 2008 08:09:16 -0800 (PST) (envelope-from phil@idle.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 m0OG98ZF030241; Thu, 24 Jan 2008 16:09:12 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801241609.m0OG98ZF030241@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] errors In-reply-to: <20080124153038.GD15941@elstar.local> Date: Thu, 24 Jan 2008 11:09:07 -0500 From: Phil Shafer X-OriginalArrivalTime: 24 Jan 2008 16:09:16.0531 (UTC) FILETIME=[77F56430:01C85EA3] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder writes: >I like it. Same here. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 11:11:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4gD-00039K-BB; Thu, 24 Jan 2008 11:11:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI4gC-000398-31 for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 11:11:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4gB-00038p-4U for yang@ietf.org; Thu, 24 Jan 2008 11:11:51 -0500 Received: from smtp109.sbc.mail.mud.yahoo.com ([68.142.198.208]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JI4gA-00023P-8o for yang@ietf.org; Thu, 24 Jan 2008 11:11:51 -0500 Received: (qmail 86128 invoked from network); 24 Jan 2008 16:11:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.83.75 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 24 Jan 2008 16:11:48 -0000 X-YMail-OSG: TnT0mTAVM1nL9nZJJrz.eZ3AhT1i1IyCIE4uorsMW7nrQ4RO1dVHYwdb.PJr69fMElC4FMd9Lrjfwv92ZtbLKM1y0g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4798B8C3.6020902@andybierman.com> Date: Thu, 24 Jan 2008 08:11:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] new pyang errors References: <200801241549.m0OFnqLn029930@idle.juniper.net> In-Reply-To: <200801241549.m0OFnqLn029930@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> Example: there are many devices out there that have fixed Ethernet MTU >> value (1500). Such a device can certainly use a DM that specifies MTU as >> mandatory. It will just fill in this slot with the hardwired value and >> report a run-time error if a client tries to change it. > > We're crosstalking on the meaning of mandatory again. My question > is what's the difference between: > > leaf mtu { > type uint; > default 1500; > mandatory false; > } > > and: > > leaf mtu { > type uint; > default 1500; > mandatory true; > } > > What am I adding by having mandatory set to true? What > is the mandatory flag adding? In my view of "mandatory", the > mandatory flag means the client must set this, but the server > has a default which should be used for this, so I'm not seeing > why the client should be forced to send the server information > the server already knows. > IMO this overlap between 'default' and 'mandatory' is not relevant. If mandatory=false, then the default is ignored in the agent. In your interpretation, mandatory=true causes the agent to ignore the default. Your view of mandatory is inconsistent with the rest of YANG, which (correctly) focuses on the description of valid NETCONF configuration databases, not the PDUs. When focusing on the config, what difference does it make if the manager explicitly sets the mtu to 1500, or if the agent sets it to 1500 by default? The data model should describe what a valid mtu leaf looks like in the config, and nothing more. Andy >> The application needs to know what the value is (as in the case of MTU). >> I don't want to rely on out-of-band resources. We also have get-config, >> not only edit-config. > > The application _has_ to rely on meta data to find the value > for leafs in objects that don't exist. Even with the :with-defaults > capability, you won't see defaults for stuff that doesn't exist. > > A YANG module defines a data model. The client and server agree to > abide by the constraints and meanings defined in that data model. > Applications can read this model and understand the data that is > being manipulated. The YANG module is by definition out-of-band, > since it's metadata. > > If you don't want out-of-band resources, what's your interest in > YANG? How do you see this helping you? > > >>> YANG defines constraints on the XML that passes between the client and >>> server. Nearly every statement in a YANG module defines a rule which >>> that XML must follow, both during protocol operations and the valid >>> configuration being built. >> I don't agree. YANG models mostly define constraints on the entire >> content of the config datastore, less so on the XML PDUs. > > In defining what's valid in the datastore, we implicitly define > what's valid in the XML. If the model says: > > leaf mtu { > type uint { > range 576..8192; > } > } > > then you cannot send xml that looks like: > > > hot-dog > 10 > infinitiy minus 3 > not > >>> Mandatory is such a constraint, and should be an indication to the >>> NETCONF client application that it needs to do something explicit >>> to satisfy this constraint. If the mandatory parameter isn't set, >>> the configuration isn't valid. >> I disagree again: this would mean you cannot change the factory default >> configuration part by part. Should the factory default configuration be >> marked invalid until the client application touches all mandatory >> values? > > I don't follow your argument here. If the factory default config > for a box doesn't follow the rules defined in the data models > supported by that box, then there's a bug somewhere. The data model > defines what's valid config, so if you don't follow the rules, you > don't have valid config. If a parameter is tagged as mandatory > in the model, it must appear in the factory-shipped config. > >>> If we allow this mandatory constraint to be satisfied via mechanisms >>> that do not involve the client and server, why have it? How is the >>> application to discern the difference between a real constraint and >>> a parameter that the fairy god mother daemon fills in? >> The mandatory/optional property should be specified by the data modeller >> and not depend on the way how it is implemented in different devices. > > Completely agree with you, but I don't see a conflict between your > point and mine. > >> Example: in an authentication database DM, the login, uid and password >> are mandatory while full-name is optional. IMO this DM is perfectly >> usable also by devices that either >> (i) don't implement the full-name slot, or even > > Here I completely and strongly disagree. A data model defines how > data works. If you tell a client that your support this data model > and you don't implement "full-name", your telling a fib. Customers > will catch you and bludgeon you about the head and shoulders. > > A data model is a contract. A client application should have faith > that you are abiding by that contract. YANG doesn't have a compliance > mechanism to allow you to avoid parts of the contract, but does > have "augment" to allow you to extend the contract with additional > information if required. But if your box doesn't have a place to > put "full-name", it shouldn't be advertising the capability for > that data model. > > We're looking to build strong and binding underpinning for future > data models and the applications that rely on them. If a box > doesn't abide by a data model that it advertises, it's a bug. > >> (ii) allow only one user - so, login=admin and uid=0 are effectively >> hardwired. > > Then your factory default config should look like: > > system { > login { > user admin { > uid 0; > } > } > } > > We should note that YANG does not cover factory-default configs. But > factory-default configs should follow the rules in the YANG data model. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 11:33:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI50l-0004No-3l; Thu, 24 Jan 2008 11:33:07 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI50k-0004Ng-4U for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 11:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI50j-0004NY-Qn for yang@ietf.org; Thu, 24 Jan 2008 11:33:05 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI50j-0002Is-AW for yang@ietf.org; Thu, 24 Jan 2008 11:33:05 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 08:32:36 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 08:29:26 -0800 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 m0OGTQ953020; Thu, 24 Jan 2008 08:29:26 -0800 (PST) (envelope-from phil@idle.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 m0OGTMe5030462; Thu, 24 Jan 2008 16:29:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801241629.m0OGTMe5030462@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] new pyang errors In-reply-to: <4798B8C3.6020902@andybierman.com> Date: Thu, 24 Jan 2008 11:29:22 -0500 From: Phil Shafer X-OriginalArrivalTime: 24 Jan 2008 16:29:26.0844 (UTC) FILETIME=[495C7FC0:01C85EA6] X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >IMO this overlap between 'default' and 'mandatory' is not relevant. Well, the issue we started with was what happens when there's a default with mandatory true, but let's move on.... >If mandatory=false, then the default is ignored in the agent. "ignored"? No, it's used internally as the default when the leaf doesn't exist. >In your interpretation, mandatory=true causes the agent to >ignore the default. Same comment. >Your view of mandatory is inconsistent with the rest of YANG, >which (correctly) focuses on the description of valid NETCONF configuration >databases, not the PDUs. I don't agree. YANG defines a data model, which consists in part of a set of constraints on the data that appears inside valid databases for that model. Out of these constraints flow (fairly easily) constraints on the NETCONF operations used to manipulate the data in that database, which leads to constraints on those PDUs. I don't see this at at odds with the rest of YANG. >When focusing on the config, what >difference does it make if the manager explicitly sets the mtu to 1500, >or if the agent sets it to 1500 by default? The data model should describe >what a valid mtu leaf looks like in the config, and nothing more. Why do we model data? What are we trying to get out of the data model? My goal is to provide a formal description between the device and client applications to allow those client applications to manipulate data on the devices with a strong understanding of what the data means and a rich set of operations for manipulating that data. We develop a contract between the client and server so both sides agree that what an "mtu" means and what the valid values are, when it needs to be set and what it means if it is not set. So thing of the data model from that device/application point of view and hopefully you'll understand why the term mandatory should describe the requirement that something external must set this value. Think of what "required" means on a web page. It means that you the user need to fill in a value. If the web server knows an appropriate default, it can fill it in and you don't need to do anything. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 11:41:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI59F-0003tm-TQ; Thu, 24 Jan 2008 11:41:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI59E-0003tS-FR for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 11:41:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI59E-0003tK-5l for yang@ietf.org; Thu, 24 Jan 2008 11:41:52 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JI59D-0002U9-KY for yang@ietf.org; Thu, 24 Jan 2008 11:41:52 -0500 Received: (qmail 32015 invoked from network); 24 Jan 2008 16:41:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.83.75 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 24 Jan 2008 16:41:50 -0000 X-YMail-OSG: RAB9uRQVM1meAYk.mVhZxZpX51yoaOFUCZgNZhzUqFGjOpGm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4798BFCD.3000706@andybierman.com> Date: Thu, 24 Jan 2008 08:41:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] errors References: <20080124.153853.210376606.mbj@tail-f.com> In-Reply-To: <20080124.153853.210376606.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > We have been talking about adding two new statements related to > error generation to YANG. > > The first statement is 'error'. It is used to define a named error. > The second statement is 'raise-error'. >.... > The errors defined for an rpc would be in addition to the standard > errors defined in rfc4741. > The phrase 'in addition' concerns me. I think you mean that an error MUST use one of the existing error-tag values from RFC 4741, but the other fields specified in error-stmt will be used in an generated for the particular error condition. IMO, this is too flexible. There is a balance between multi-vendor interoperability and single-vendor-flexibility that must be carefully considered when developing a standard. IMO, it would drastically harm interoperability if the mechanism turned into just another proprietary hack (I mean 'vendor-specific content' ;-) within NETCONF. What does it mean for interoperability if vendors override an error defined in RFC 4741 or the Notifications RFC, with different error-severity, or error-message? What if they ignore some/all of the standard errors, and use their own proprietary set (because it's better of course ;-) IMO, the structured error return codes in NETCONF represent an important advancement away from screen-scraping CLI. It is important that this is not compromised. A vendor is not compliant with RFC 4741 unless all the errors are generated exactly as specified in the spec, regardless of what the YANG draft says. I think it needs to be clear in the draft that the fields defined by standard errors cannot be changed, and behavior defined in the standard cannot be changed (e.g., send the acme-lock-denied error *instead* of the standard lock-denied error, which uses a different error-tag value, or does not include the error-info). > Grammar: > > error-stmt = error-keyword sep error-app-tag-str optsep "{" > ; error-app-tag-str is an identifier > error-tag-stmt stmtsep > [error-message-stmt stmtsep] > [error-severity-stmt stmtsep] ; default is error > [description-stmt stmtsep] > [reference-stmt stmtsep] > "}" > > raise-error error-app-tag-ref-str stmtsep > What if the DM writer wants to raise an existing standard error? Does there need to be a standard module for the NETCONF errors, added as an appendix? Notably missing from the error-stmt is definition of any error-info data. An open issue is whether there is some simple mechanism for defining error-info, other than full-blown data-def-stmt, to define error leafs. (E.g., lock-denied has the of the current lock owner.) If not, then I would rather leave it out. > > Comments? > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 12:51:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6Ey-0004Tn-JQ; Thu, 24 Jan 2008 12:51:52 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI6Ex-0004Tc-Qm for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 12:51:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6Ex-0004TP-1o for yang@ietf.org; Thu, 24 Jan 2008 12:51:51 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI6Ew-0005mB-Dk for yang@ietf.org; Thu, 24 Jan 2008 12:51:50 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 398F01B80D7; Thu, 24 Jan 2008 18:51:49 +0100 (CET) Date: Thu, 24 Jan 2008 18:50:12 +0100 (CET) Message-Id: <20080124.185012.212081588.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <4798BFCD.3000706@andybierman.com> References: <20080124.153853.210376606.mbj@tail-f.com> <4798BFCD.3000706@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > We have been talking about adding two new statements related to > > error generation to YANG. > > > > The first statement is 'error'. It is used to define a named error. > > The second statement is 'raise-error'. > >.... > > The errors defined for an rpc would be in addition to the standard > > errors defined in rfc4741. > > > > The phrase 'in addition' concerns me. I meant that if an rpc has one raise-error clause, it doesn't mean that the standard error messages cannot be generated. It just means that in addition to the normal error messages (e.g. missing-element), these DM-specific errors can also occur. > I think you mean that an error MUST use one of the existing > error-tag values from RFC 4741 Yes that was the idea, although I forgot to mention it. > but the other fields specified > in error-stmt will be used in an generated for the > particular error condition. IMO, this is too flexible. > > There is a balance between multi-vendor interoperability > and single-vendor-flexibility that must be carefully considered > when developing a standard. IMO, it would drastically harm > interoperability if the mechanism turned into > just another proprietary hack (I mean 'vendor-specific content' ;-) > within NETCONF. > > What does it mean for interoperability if vendors override an error defined > in RFC 4741 or the Notifications RFC, with different error-severity, > or error-message? You are right. [checking rfc4741...] Hmm. An rpc-error MUST include error-tag. The list of error-tags is defined in rfc4741. For each such tag, the corresponding error-severity is defined. All tags have error-severity 'error'. Conclusion: error-severity 'warning' can never be generated. !!?!?! One other thing. The error-message is not defined by rfc4741, so it should be ok for a DM to define one. > What if they ignore some/all of the standard errors, > and use their own proprietary set (because it's better of course ;-) > > IMO, the structured error return codes in NETCONF represent an important > advancement away from screen-scraping CLI. It is important that this > is not compromised. A vendor is not compliant with RFC 4741 > unless all the errors are generated exactly as specified in the spec, > regardless of what the YANG draft says. > > I think it needs to be clear in the draft that the fields defined > by standard errors cannot be changed, and behavior > defined in the standard cannot be changed (e.g., send the > acme-lock-denied error *instead* of the standard lock-denied error, > which uses a different error-tag value, or does not include the > error-info). Agreed. The idea is to provide more, specific, info, in addition to the standard messages. The idea is not to change the standard messages. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 13:05:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6SP-0000Dm-Kc; Thu, 24 Jan 2008 13:05:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI6SO-0000Dc-AF for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 13:05:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6SO-0000DU-0K for yang@ietf.org; Thu, 24 Jan 2008 13:05:44 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI6SL-0004jU-Jb for yang@ietf.org; Thu, 24 Jan 2008 13:05:43 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E8777D800C4 for ; Thu, 24 Jan 2008 19:05:38 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <200801241549.m0OFnqLn029930@idle.juniper.net> References: <200801241549.m0OFnqLn029930@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 24 Jan 2008 19:05:39 +0100 Message-Id: <1201197939.20662.194.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v =C4=8Ct 24. 01. 2008 v 10:49 -0500: > Ladislav Lhotka writes: > >Example: there are many devices out there that have fixed Ethernet MTU > >value (1500). Such a device can certainly use a DM that specifies MTU = as > >mandatory. It will just fill in this slot with the hardwired value and > >report a run-time error if a client tries to change it. =20 >=20 > We're crosstalking on the meaning of mandatory again. My question > is what's the difference between: >=20 > leaf mtu { > type uint; > default 1500; > mandatory false; > } An implementation may include this leaf or not. In the latter case it doesn't exist at all, no default is defined. Hence the device must be able to live without any MTU value available (this is of course impossible for Ethernet). If the mtu leaf exists in an implementation, it has to start with the default value of 1500, unless and until a client changes it (which may or may not be possible). >=20 > and: >=20 > leaf mtu { > type uint; > default 1500; > mandatory true; > } Here every implementation conformant to this data model must have this leaf. The interpretation of the default statement is as above. In my interpretation the mandatory/optional and default concepts are orthogonal. The former relates to the structure (leaf must or needn't exist) whereas the latter to the value. >=20 > What am I adding by having mandatory set to true? What > is the mandatory flag adding? In my view of "mandatory", the > mandatory flag means the client must set this, but the server > has a default which should be used for this, so I'm not seeing > why the client should be forced to send the server information > the server already knows. I understand what you are saying but I don't like it because it introduces yet another meaning of validity with respect to a YANG data model. We already had three: 1. validity of NETCONF PDUs 2. validity of entire configurations 3. managed device behaviour (e.g., must set the defaults) Your view of mandatory brings another one: 4. client behaviour (must set mandatory parameters) Each of these views differs in some aspects from the others. I would myself prefer to concentrate on 2 and try to infer what it means for 1. > =20 > >The application needs to know what the value is (as in the case of MTU= ). > >I don't want to rely on out-of-band resources. We also have get-config= , > >not only edit-config. >=20 > The application _has_ to rely on meta data to find the value > for leafs in objects that don't exist. Even with the :with-defaults > capability, you won't see defaults for stuff that doesn't exist. If it doesn't exist because the data modeller decided the leaf is optional, I have to be able to live without it. If it is mandatory, then I must be able to get it from the device via get-config (modulo :with-defaults). >=20 > A YANG module defines a data model. The client and server agree to > abide by the constraints and meanings defined in that data model. > Applications can read this model and understand the data that is > being manipulated. The YANG module is by definition out-of-band, > since it's metadata. >=20 > If you don't want out-of-band resources, what's your interest in > YANG? How do you see this helping you? I'd be happy with items 2 and 1 above. =20 >=20 >=20 > >> YANG defines constraints on the XML that passes between the client a= nd > >> server. Nearly every statement in a YANG module defines a rule whic= h > >> that XML must follow, both during protocol operations and the valid > >> configuration being built. > > > >I don't agree. YANG models mostly define constraints on the entire > >content of the config datastore, less so on the XML PDUs. >=20 > In defining what's valid in the datastore, we implicitly define > what's valid in the XML. If the model says: In some cases this mapping is automatic, some cases are defined in the YANG draft and some are not clear yet (to me at least). >=20 > leaf mtu { > type uint { > range 576..8192; > } > } >=20 > then you cannot send xml that looks like: >=20 > > hot-dog > 10 > infinitiy minus 3 > not >=20 > >> Mandatory is such a constraint, and should be an indication to the > >> NETCONF client application that it needs to do something explicit > >> to satisfy this constraint. If the mandatory parameter isn't set, > >> the configuration isn't valid. > > > >I disagree again: this would mean you cannot change the factory defaul= t > >configuration part by part. Should the factory default configuration b= e > >marked invalid until the client application touches all mandatory > >values? >=20 > I don't follow your argument here. If the factory default config > for a box doesn't follow the rules defined in the data models > supported by that box, then there's a bug somewhere. The data model > defines what's valid config, so if you don't follow the rules, you > don't have valid config. If a parameter is tagged as mandatory > in the model, it must appear in the factory-shipped config. In my view of mandatory the factory default configuration must be (and is) valid. In your view, if I understand it correctly, it is not valid till the client sets the mandatory parameters. >=20 > >> If we allow this mandatory constraint to be satisfied via mechanisms > >> that do not involve the client and server, why have it? How is the > >> application to discern the difference between a real constraint and > >> a parameter that the fairy god mother daemon fills in? > > > >The mandatory/optional property should be specified by the data modell= er > >and not depend on the way how it is implemented in different devices. >=20 > Completely agree with you, but I don't see a conflict between your > point and mine. >=20 > >Example: in an authentication database DM, the login, uid and password > >are mandatory while full-name is optional. IMO this DM is perfectly > >usable also by devices that either > >(i) don't implement the full-name slot, or even >=20 > Here I completely and strongly disagree. A data model defines how > data works. If you tell a client that your support this data model > and you don't implement "full-name", your telling a fib. Customers > will catch you and bludgeon you about the head and shoulders. No, since it's optional (but of course lada:optional !=3D phil:optional). Both the device and manager can live without full names being in the database. >=20 > A data model is a contract. A client application should have faith > that you are abiding by that contract. YANG doesn't have a compliance > mechanism to allow you to avoid parts of the contract, but does > have "augment" to allow you to extend the contract with additional > information if required. But if your box doesn't have a place to > put "full-name", it shouldn't be advertising the capability for > that data model. Again, my model: if a parameter is optional then the client cannot be surprised if it is not in the configuration obtained by get-config and attempts to set it are ignored or return a warning. >=20 > We're looking to build strong and binding underpinning for future > data models and the applications that rely on them. If a box > doesn't abide by a data model that it advertises, it's a bug. I fully agree, we only differ in the interpretation of a YANG statement. The confusion is due to an interplay between mandatory/optional and defaults. As I said, I treat them as orthogonal and actually don't need the defaults at all. I'd also say my interpretation is in accord with section 7.6.4 of the YANG draft. >=20 > >(ii) allow only one user - so, login=3Dadmin and uid=3D0 are effective= ly > >hardwired. >=20 > Then your factory default config should look like: >=20 > system { > login { > user admin { > uid 0; > } > } > } Actually I had this in mind, but it doesn't matter: users { user { login admin; uid 0; } } The point is that both admin and uid values are read-only. >=20 > We should note that YANG does not cover factory-default configs. But > factory-default configs should follow the rules in the YANG data model. Yes, factory default config should be valid. Cheers, Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 14:39:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI7uw-0004tt-3O; Thu, 24 Jan 2008 14:39:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI7uu-0004to-FB for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 14:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI7uu-0004tg-51 for yang@ietf.org; Thu, 24 Jan 2008 14:39:16 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI7us-0007M8-Bb for yang@ietf.org; Thu, 24 Jan 2008 14:39:16 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57B698A32D; Thu, 24 Jan 2008 20:39:13 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23984-01; Thu, 24 Jan 2008 20:39:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92ADF8A31C; Thu, 24 Jan 2008 20:39:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6B6B148A069; Thu, 24 Jan 2008 20:39:06 +0100 (CET) Date: Thu, 24 Jan 2008 20:39:06 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] errors Message-ID: <20080124193906.GB16515@elstar.local> Mail-Followup-To: Martin Bjorklund , ietf@andybierman.com, yang@ietf.org References: <20080124.153853.210376606.mbj@tail-f.com> <4798BFCD.3000706@andybierman.com> <20080124.185012.212081588.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080124.185012.212081588.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 24, 2008 at 06:50:12PM +0100, Martin Bjorklund wrote: > You are right. [checking rfc4741...] Hmm. An rpc-error MUST include > error-tag. The list of error-tags is defined in rfc4741. For each > such tag, the corresponding error-severity is defined. All tags have > error-severity 'error'. Conclusion: error-severity 'warning' can > never be generated. !!?!?! I mentioned this before. I agree error-severity as it is is useless and I think we consider to remove it from NETCONF when the specs are revised. Did I mention that it would be nice to have a NETCONF maintenance activity? Even if it is just a web page to keep track of the issues until the IETF gets to it? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 14:41:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI7xP-0005gJ-O0; Thu, 24 Jan 2008 14:41:51 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI7xP-0005fs-Cu for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 14:41:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI7xP-0005fk-1s for yang@ietf.org; Thu, 24 Jan 2008 14:41:51 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI7xO-00018T-Lx for yang@ietf.org; Thu, 24 Jan 2008 14:41:50 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11DC68A330; Thu, 24 Jan 2008 20:41:50 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23945-07; Thu, 24 Jan 2008 20:41:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E0028A32D; Thu, 24 Jan 2008 20:41:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6406648A0A4; Thu, 24 Jan 2008 20:41:43 +0100 (CET) Date: Thu, 24 Jan 2008 20:41:43 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] errors Message-ID: <20080124194143.GC16515@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , yang@ietf.org References: <20080124.153853.210376606.mbj@tail-f.com> <4798BFCD.3000706@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4798BFCD.3000706@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote: > What if the DM writer wants to raise an existing standard error? > Does there need to be a standard module for the NETCONF errors, > added as an appendix? Yes. And I think it would be also nice if standard NETCONF operations could be defined in YANG itself; would be a nice proof of concept. (I know the unfortunate attribute usage in edit-config - so this might be the only thing we need to handle in the DESCRIPTION clause.) > Notably missing from the error-stmt is definition of any error-info data. > An open issue is whether there is some simple mechanism for defining > error-info, other than full-blown data-def-stmt, to define error leafs. > (E.g., lock-denied has the of the current lock owner.) > If not, then I would rather leave it out. Correct, this is needed. I think error-info is actually not much different from in and out parameters where we also use standard YANG constructs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 15:28:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8gW-0008Ke-US; Thu, 24 Jan 2008 15:28:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI8gV-0008KS-G3 for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 15:28:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8gV-0008KK-5h for yang@ietf.org; Thu, 24 Jan 2008 15:28:27 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI8gU-0002U6-Pq for yang@ietf.org; Thu, 24 Jan 2008 15:28:27 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 406471B80D7; Thu, 24 Jan 2008 21:28:25 +0100 (CET) Date: Thu, 24 Jan 2008 21:28:22 +0100 (CET) Message-Id: <20080124.212822.254714100.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <20080124194143.GC16515@elstar.local> References: <20080124.153853.210376606.mbj@tail-f.com> <4798BFCD.3000706@andybierman.com> <20080124194143.GC16515@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote: > > > What if the DM writer wants to raise an existing standard error? That's what I meant when I wrote that the raise-error is in addition to the standard errors. I.e. nothing needs to be done in the DM for this scenario. > > Does there need to be a standard module for the NETCONF errors, > > added as an appendix? > > Yes. No, that's not possible with the way the error statement is done, since the identifier is error-app-tag. > > Notably missing from the error-stmt is definition of any error-info data. > > An open issue is whether there is some simple mechanism for defining > > error-info, other than full-blown data-def-stmt, to define error > > leafs. Why can't the normal data-def stmts be used? That would be the obvious choice if we want to do error-info. > > (E.g., lock-denied has the of the current lock owner.) > > If not, then I would rather leave it out. > > Correct, this is needed. I think error-info is actually not much > different from in and out parameters where we also use standard YANG > constructs. I agree. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 15:40:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8sX-0005iQ-EC; Thu, 24 Jan 2008 15:40:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI8sV-0005iF-Uy for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 15:40:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8sV-0005i0-Ji for yang@ietf.org; Thu, 24 Jan 2008 15:40:51 -0500 Received: from smtp113.sbc.mail.mud.yahoo.com ([68.142.198.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JI8sT-0000C4-JD for yang@ietf.org; Thu, 24 Jan 2008 15:40:51 -0500 Received: (qmail 32458 invoked from network); 24 Jan 2008 20:40:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.83.75 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 24 Jan 2008 20:40:48 -0000 X-YMail-OSG: XXAnjOQVM1lJWAH094CyqulP8Ih8QisgPbtJU5zpRq9h5gdA X-Yahoo-Newman-Property: ymail-3 Message-ID: <4798F7CF.3010203@andybierman.com> Date: Thu, 24 Jan 2008 12:40:47 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] errors References: <20080124.153853.210376606.mbj@tail-f.com> <4798BFCD.3000706@andybierman.com> <20080124194143.GC16515@elstar.local> <20080124.212822.254714100.mbj@tail-f.com> In-Reply-To: <20080124.212822.254714100.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote: >> >>> What if the DM writer wants to raise an existing standard error? > > That's what I meant when I wrote that the raise-error is in addition > to the standard errors. I.e. nothing needs to be done in the DM for > this scenario. > except there has to be a CLR that no error-app-tag value can be one of the standard error-tag values. If the standard error-tag values grow over time, this creating potential naming conflicts with previously released error-app-tag values. >>> Does there need to be a standard module for the NETCONF errors, >>> added as an appendix? >> Yes. > > No, that's not possible with the way the error statement is done, > since the identifier is error-app-tag. > >>> Notably missing from the error-stmt is definition of any error-info data. >>> An open issue is whether there is some simple mechanism for defining >>> error-info, other than full-blown data-def-stmt, to define error >>> leafs. > > Why can't the normal data-def stmts be used? That would be the > obvious choice if we want to do error-info. > IMO, the document needs lots of work in the area of specifying how all the data-def-stmt clauses apply to rpc/input, rpc/output, and notification. Now add error-info to that list. The document has to specify exactly what every clause and sub-clause means for each of these data definition types. >>> (E.g., lock-denied has the of the current lock owner.) >>> If not, then I would rather leave it out. >> Correct, this is needed. I think error-info is actually not much >> different from in and out parameters where we also use standard YANG >> constructs. > > I agree. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 15:42:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8uD-00064T-Nc; Thu, 24 Jan 2008 15:42:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI8uC-00064N-7L for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 15:42:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8uB-00064F-TN for yang@ietf.org; Thu, 24 Jan 2008 15:42:35 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI8uB-0002nG-J0 for yang@ietf.org; Thu, 24 Jan 2008 15:42:35 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 0C1091B80D7; Thu, 24 Jan 2008 21:42:35 +0100 (CET) Date: Thu, 24 Jan 2008 21:42:32 +0100 (CET) Message-Id: <20080124.214232.175587160.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <4798F7CF.3010203@andybierman.com> References: <20080124194143.GC16515@elstar.local> <20080124.212822.254714100.mbj@tail-f.com> <4798F7CF.3010203@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote: > >> > >>> What if the DM writer wants to raise an existing standard error? > > > > That's what I meant when I wrote that the raise-error is in addition > > to the standard errors. I.e. nothing needs to be done in the DM for > > this scenario. > > > > except there has to be a CLR that no error-app-tag value can be > one of the standard error-tag values. Why? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 16:01:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9CZ-0001XA-Ga; Thu, 24 Jan 2008 16:01:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI9CX-0001Ok-Ra for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 16:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9CX-0001Mb-HC for yang@ietf.org; Thu, 24 Jan 2008 16:01:33 -0500 Received: from smtp121.sbc.mail.sp1.yahoo.com ([69.147.64.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JI9CV-0000cP-5P for yang@ietf.org; Thu, 24 Jan 2008 16:01:33 -0500 Received: (qmail 93926 invoked from network); 24 Jan 2008 21:01:30 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.83.75 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 24 Jan 2008 21:01:29 -0000 X-YMail-OSG: 4rmDmA4VM1kYN6eY3uium26UNPGt5GSQFZTQH8stdhBqc67n X-Yahoo-Newman-Property: ymail-3 Message-ID: <4798FCA9.60500@andybierman.com> Date: Thu, 24 Jan 2008 13:01:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] errors References: <20080124194143.GC16515@elstar.local> <20080124.212822.254714100.mbj@tail-f.com> <4798F7CF.3010203@andybierman.com> <20080124.214232.175587160.mbj@tail-f.com> In-Reply-To: <20080124.214232.175587160.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote: >>>> >>>>> What if the DM writer wants to raise an existing standard error? >>> That's what I meant when I wrote that the raise-error is in addition >>> to the standard errors. I.e. nothing needs to be done in the DM for >>> this scenario. >>> >> except there has to be a CLR that no error-app-tag value can be >> one of the standard error-tag values. > > Why? > > error lock-denied { error-tag operation-failed; } ... raise-error lock-denied; Is this raise-error for the standard lock-denied or for the vendor error called lock-denied, defined in the same module? > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 16:07:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9Ig-0003It-7D; Thu, 24 Jan 2008 16:07:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI9If-0003Io-KR for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 16:07:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9If-0003If-0B for yang@ietf.org; Thu, 24 Jan 2008 16:07:53 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI9Ie-0003Qd-Js for yang@ietf.org; Thu, 24 Jan 2008 16:07:52 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id EDAB91B80D7; Thu, 24 Jan 2008 22:07:51 +0100 (CET) Date: Thu, 24 Jan 2008 22:07:49 +0100 (CET) Message-Id: <20080124.220749.135318331.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <4798FCA9.60500@andybierman.com> References: <4798F7CF.3010203@andybierman.com> <20080124.214232.175587160.mbj@tail-f.com> <4798FCA9.60500@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Juergen Schoenwaelder wrote: > >>>> On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote: > >>>> > >>>>> What if the DM writer wants to raise an existing standard error? > >>> That's what I meant when I wrote that the raise-error is in addition > >>> to the standard errors. I.e. nothing needs to be done in the DM for > >>> this scenario. > >>> > >> except there has to be a CLR that no error-app-tag value can be > >> one of the standard error-tag values. > > > > Why? > > > > > > error lock-denied { > error-tag operation-failed; > } > > ... > raise-error lock-denied; > > > Is this raise-error for the standard lock-denied or for the > vendor error called lock-denied, defined in the same module? The idea was (I think it came from you :) that the identifier for the error clause is error-app-tag. So the above would be in XML: operation-failed lock-denied Thus, no name clash. Side note: the error-app-tag is defined as a string in rfc4741, but IMO is should have been a QName. If it was, all error-app-tags would be local per namespace, so the above would be: foo:lock-denied /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 16:35:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9jO-0008FE-14; Thu, 24 Jan 2008 16:35:30 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JI9jN-0008Er-Kz for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 16:35:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9jN-0008Ej-A1 for yang@ietf.org; Thu, 24 Jan 2008 16:35:29 -0500 Received: from smtp112.sbc.mail.mud.yahoo.com ([68.142.198.211]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JI9jM-0004Fx-Tu for yang@ietf.org; Thu, 24 Jan 2008 16:35:29 -0500 Received: (qmail 11376 invoked from network); 24 Jan 2008 21:35:27 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.83.75 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 24 Jan 2008 21:35:27 -0000 X-YMail-OSG: USkFhrIVM1kMypd99qix5IIjO3x3dZY8Dna506w_jKNXEn.d X-Yahoo-Newman-Property: ymail-3 Message-ID: <4799049F.4030400@andybierman.com> Date: Thu, 24 Jan 2008 13:35:27 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] errors References: <4798F7CF.3010203@andybierman.com> <20080124.214232.175587160.mbj@tail-f.com> <4798FCA9.60500@andybierman.com> <20080124.220749.135318331.mbj@tail-f.com> In-Reply-To: <20080124.220749.135318331.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Juergen Schoenwaelder wrote: >>>>>> On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote: >>>>>> >>>>>>> What if the DM writer wants to raise an existing standard error? >>>>> That's what I meant when I wrote that the raise-error is in addition >>>>> to the standard errors. I.e. nothing needs to be done in the DM for >>>>> this scenario. >>>>> >>>> except there has to be a CLR that no error-app-tag value can be >>>> one of the standard error-tag values. >>> Why? >>> >>> >> error lock-denied { >> error-tag operation-failed; >> } >> >> ... >> raise-error lock-denied; >> >> >> Is this raise-error for the standard lock-denied or for the >> vendor error called lock-denied, defined in the same module? > > The idea was (I think it came from you :) that the identifier for the > error clause is error-app-tag. So the above would be in XML: > > > operation-failed > lock-denied > > > Thus, no name clash. > huh? then how do you specify a 'raise-error' for the lock-denied in RFC 4741? > Side note: the error-app-tag is defined as a string in rfc4741, but > IMO is should have been a QName. If it was, all error-app-tags would > be local per namespace, so the above would be: > > foo:lock-denied > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 17:10:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIAHU-0004fC-JA; Thu, 24 Jan 2008 17:10:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIAHS-0004f3-Qm for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 17:10:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIAHR-0004eq-LA for yang@ietf.org; Thu, 24 Jan 2008 17:10:41 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIAHR-00058K-4T for yang@ietf.org; Thu, 24 Jan 2008 17:10:41 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 8BF2C1B80C9; Thu, 24 Jan 2008 23:10:39 +0100 (CET) Date: Thu, 24 Jan 2008 23:10:36 +0100 (CET) Message-Id: <20080124.231036.37087164.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <4799049F.4030400@andybierman.com> References: <4798FCA9.60500@andybierman.com> <20080124.220749.135318331.mbj@tail-f.com> <4799049F.4030400@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > > The idea was (I think it came from you :) that the identifier for the > > error clause is error-app-tag. So the above would be in XML: > > > > > > operation-failed > > lock-denied > > > > > > Thus, no name clash. > > > > huh? > > then how do you specify a 'raise-error' for the lock-denied in RFC 4741? You don't. Unless you also have an error-app-tag: error my-extra-lock-denied { error-tag lock-denied; } The idea was that really do not want to list all std errors that can occur: rpc my-rpc { ... raise-error missing-element; raise-error bad-namespace; ... } These std errors can always occur. No need to specify them again. ----- We also disucssed an alternative way to do this, which is slightly more flexible. In this variant, the error is identified with an identifier, which has no meaning on the wire. It's just a local identifier like a typedef or grouping identifier. Then within the error, you have the statement 'error-app-tag' in addition to the other stmts: error my-error { error-tag invalid-value; error-app-tag bad-mtu; } /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 19:10:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIC9d-0006Ut-7C; Thu, 24 Jan 2008 19:10:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIC9c-0006Ug-6I for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 19:10:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIC9b-0006TX-QD for yang@ietf.org; Thu, 24 Jan 2008 19:10:43 -0500 Received: from smtp122.sbc.mail.sp1.yahoo.com ([69.147.64.95]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIC8u-0000ZA-O8 for yang@ietf.org; Thu, 24 Jan 2008 19:10:01 -0500 Received: (qmail 30648 invoked from network); 25 Jan 2008 00:10:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.97.95 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2008 00:09:59 -0000 X-YMail-OSG: K2mEuRQVM1n2GS74xSV5R4kT8AEwHHg0kfRNZGrTVPGo_Rr2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <479928D7.1070706@andybierman.com> Date: Thu, 24 Jan 2008 16:09:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] errors References: <4798FCA9.60500@andybierman.com> <20080124.220749.135318331.mbj@tail-f.com> <4799049F.4030400@andybierman.com> <20080124.231036.37087164.mbj@tail-f.com> In-Reply-To: <20080124.231036.37087164.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>> The idea was (I think it came from you :) that the identifier for the >>> error clause is error-app-tag. So the above would be in XML: >>> >>> >>> operation-failed >>> lock-denied >>> >>> >>> Thus, no name clash. >>> >> huh? >> >> then how do you specify a 'raise-error' for the lock-denied in RFC 4741? > > You don't. Unless you also have an error-app-tag: > > error my-extra-lock-denied { > error-tag lock-denied; > } > > The idea was that really do not want to list all std errors that can > occur: > > rpc my-rpc { > ... > raise-error missing-element; > raise-error bad-namespace; > ... > } > > These std errors can always occur. No need to specify them again. > okay, that's fine. > ----- > > We also disucssed an alternative way to do this, which is slightly > more flexible. In this variant, the error is identified with an > identifier, which has no meaning on the wire. It's just a local > identifier like a typedef or grouping identifier. Then within the > error, you have the statement 'error-app-tag' in addition to the other > stmts: > > error my-error { > error-tag invalid-value; > error-app-tag bad-mtu; > } > > I like the current design better because the key into the error dictionary has meaning, but there is a problem... There is still at least one open issue, which is that error-app-tag is defined in RFC 4741 as a string and it should really be a QName. Each error definition will only be unique within its module, so error-app-tag is not globally unique as it should be (according to the RFC). IMO, this should be solved by calling it a bug in the RFC (along with the bad-namespace element, which is a QName and MUST be an Xpath string, not a QName at all), and encoding the error-app-tag as a QName. The module namespace URI identifies the prefix in an XML instance document. Your 'raise-error' examples always show a local identifier reference (i.e., no prefix), but the real syntax is an identifier-ref-string (called a node-identifier in -00), so the error does not have to be in the same module as the raise-error statement. > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 22:12:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIEzU-0007Pp-Dh; Thu, 24 Jan 2008 22:12:28 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIEzT-0007LP-QN for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 22:12:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIEzT-0007HA-CE for yang@ietf.org; Thu, 24 Jan 2008 22:12:27 -0500 Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIEzS-0005iX-MJ for yang@ietf.org; Thu, 24 Jan 2008 22:12:27 -0500 Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 19:12:22 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 19:11:48 -0800 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 m0P3Blq01302; Thu, 24 Jan 2008 19:11:47 -0800 (PST) (envelope-from phil@idle.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 m0P3Bhbo036061; Fri, 25 Jan 2008 03:11:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801250311.m0P3Bhbo036061@idle.juniper.net> To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors In-reply-to: <1201197939.20662.194.camel@missotis> Date: Thu, 24 Jan 2008 22:11:43 -0500 From: Phil Shafer X-OriginalArrivalTime: 25 Jan 2008 03:11:48.0332 (UTC) FILETIME=[05E0DAC0:01C85F00] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Ladislav Lhotka writes: >In my interpretation the mandatory/optional and default concepts are >orthogonal. The former relates to the structure (leaf must or needn't >exist) whereas the latter to the value. They aren't orthogonal. Your intepretation leads to the logic Andy laid out earlier: Q1: Is it mandatory? true --> Q2: Does it have a default? false --> A: Then the leaf must be explicitly set true --> A: Then the agent must implicitly create it w/ the default false --> A: no one does anything I want to see the question as: Q1: Is it mandatory? true --> A: Then the agent must implicitly create it w/ the default false --> A: no one does anything Internally, when the subcomponent fetches data from the database, you may have logic like: value = isconfig(x) ? value(x) : default(x); So if I don't make an mtu leaf, the software that asks for the mtu can get the default value without forcing this into the config. >Your view of mandatory brings another one: >4. client behaviour (must set mandatory parameters) >Each of these views differs in some aspects from the others. I would >myself prefer to concentrate on 2 and try to infer what it means for 1. I'm not adding this aspect. The client must know what parameters it needs to set. I'm just wanting the answer to this aspect to be simple. If it's mandatory, the client will need to set it. If it's mandatory and not present, the server will fail the config. >In some cases this mapping is automatic, some cases are defined in the >YANG draft and some are not clear yet (to me at least). Please let me know where it isn't clear and we can fix the draft. >> Here I completely and strongly disagree. A data model defines how >> data works. If you tell a client that your support this data model >> and you don't implement "full-name", your telling a fib. Customers >> will catch you and bludgeon you about the head and shoulders. > >No, since it's optional (but of course lada:optional != phil:optional). >Both the device and manager can live without full names being in the >database. How? If I give the user a form to fill in with the full name (which I assume I should since the data model says it's there), and the user gives me one, I'll send it to the device. Will the device throw it away? This will lead to much weeping and gnashing of teeth. >Again, my model: if a parameter is optional then the client cannot be >surprised if it is not in the configuration obtained by get-config and >attempts to set it are ignored or return a warning. This would be disasterous and would render the entire effort of data modeling moot. The data model is supposed to move us out of the Wild West and into a more civilized world. If the locals can ignore parts of the law, then there is no law. If you can't even find out what parts of the law are being ignored, you're lost. >I fully agree, we only differ in the interpretation of a YANG statement. It seems we disagree on much more than that. Should we step back and think about what problem we're trying to solve? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Jan 24 23:15:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIFyb-0004ea-UI; Thu, 24 Jan 2008 23:15:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIFya-0004Uw-EP for yang-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 23:15:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIFya-0004S5-2j for yang@ietf.org; Thu, 24 Jan 2008 23:15:36 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIFyZ-0007cX-Pe for yang@ietf.org; Thu, 24 Jan 2008 23:15:35 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kuQrKQY0xul4dw88AggyXBZ9Dgo7KO97gn/m171QuZj3YR0CNnyZjH44obPep8Vl; 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 [68.164.82.180] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JIFyW-0002VP-KN for yang@ietf.org; Thu, 24 Jan 2008 23:15:33 -0500 Message-ID: <000601c85f09$2fbe3c80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200801250311.m0P3Bhbo036061@idle.juniper.net> Subject: Re: [YANG] new pyang errors Date: Thu, 24 Jan 2008 20:17:21 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911766dc236590f0226b6fbf755886c6ab36350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.82.180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Ladislav Lhotka" > Cc: > Sent: Thursday, January 24, 2008 7:11 PM > Subject: Re: [YANG] new pyang errors ... > >Again, my model: if a parameter is optional then the client cannot be > >surprised if it is not in the configuration obtained by get-config and > >attempts to set it are ignored or return a warning. > > This would be disasterous and would render the entire effort of > data modeling moot. The data model is supposed to move us out > of the Wild West and into a more civilized world. If the locals > can ignore parts of the law, then there is no law. If you can't > even find out what parts of the law are being ignored, you're lost. ... In the SNMP/SMI worlds, the "optionality" Ladislav refers to is handled by conformance statements, rather than the model per se. In the CMIP/GDMO world, attributes are only optional to the extent that they are associated with conditional packages, which normally reflect varying conformance requirements, and whose presence will be listed in the packages attribute. Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 01:14:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIHpd-0004xK-Hp; Fri, 25 Jan 2008 01:14:29 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIHpb-0004x9-Mx for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 01:14:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIHpb-0004wz-AB for yang@ietf.org; Fri, 25 Jan 2008 01:14:27 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIHpa-0004ow-E8 for yang@ietf.org; Fri, 25 Jan 2008 01:14:26 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jan 2008 22:14:15 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 22:14:23 -0800 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 m0P6ENq43297; Thu, 24 Jan 2008 22:14:23 -0800 (PST) (envelope-from phil@idle.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 m0P6EJwJ036835; Fri, 25 Jan 2008 06:14:19 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801250614.m0P6EJwJ036835@idle.juniper.net> To: "Randy Presuhn" Subject: Re: [YANG] new pyang errors In-reply-to: <000601c85f09$2fbe3c80$6801a8c0@oemcomputer> Date: Fri, 25 Jan 2008 01:14:19 -0500 From: Phil Shafer X-OriginalArrivalTime: 25 Jan 2008 06:14:23.0863 (UTC) FILETIME=[87E23870:01C85F19] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "Randy Presuhn" writes: >In the SNMP/SMI worlds, the "optionality" Ladislav refers to is >handled by conformance statements, rather than the model per se. Ah so maybe the confusion is "mandatory to implement" versus "mandatory to configure". YANG's mandatory statement is the latter. YANG has no conformance mechanism. Whether it appears in YANG-2.0, I can't predict, but I'm hoping we can make base models that devices can implement, with augmentations for additional config. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 04:20:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKjI-0004ey-LH; Fri, 25 Jan 2008 04:20:08 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIKjH-0004er-D0 for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 04:20:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKj9-0004e4-LA for yang@ietf.org; Fri, 25 Jan 2008 04:19:59 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIKj8-0000MZ-1n for yang@ietf.org; Fri, 25 Jan 2008 04:19:59 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 117EC8A2DF; Fri, 25 Jan 2008 10:19:57 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22728-04-5; Fri, 25 Jan 2008 10:19:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F34A5AD24; Fri, 25 Jan 2008 10:19:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1484348AAB9; Fri, 25 Jan 2008 10:19:47 +0100 (CET) Date: Fri, 25 Jan 2008 10:19:46 +0100 From: Juergen Schoenwaelder To: yang@ietf.org, netconf@ops.ietf.org Subject: Re: [YANG] errors Message-ID: <20080125091946.GA17440@elstar.local> Mail-Followup-To: yang@ietf.org, netconf@ops.ietf.org References: <20080124.153853.210376606.mbj@tail-f.com> <4798BFCD.3000706@andybierman.com> <20080124.185012.212081588.mbj@tail-f.com> <20080124193906.GB16515@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080124193906.GB16515@elstar.local> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netconf@ops.ietf.org List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Thu, Jan 24, 2008 at 08:39:06PM +0100, Juergen Schoenwaelder wrote: > Did I mention that it would be nice to have a NETCONF maintenance > activity? Even if it is just a web page to keep track of the issues > until the IETF gets to it? I started a wiki page to track NETCONF RFC 4741 issues. http://cnds.eecs.jacobs-university.de/wiki/NETCONF It is currently in its infancy so please send me your favourite bugs and I will happily add them to the wiki page. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 04:59:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILLn-0006le-D0; Fri, 25 Jan 2008 04:59:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILLm-0006lZ-KZ for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 04:59:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILLm-0006lO-A7 for yang@ietf.org; Fri, 25 Jan 2008 04:59:54 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JILLl-00082b-VZ for yang@ietf.org; Fri, 25 Jan 2008 04:59:54 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id BD3D71B80D7; Fri, 25 Jan 2008 10:59:52 +0100 (CET) Date: Fri, 25 Jan 2008 11:01:19 +0100 (CET) Message-Id: <20080125.110119.211713651.mbj@tail-f.com> To: netconf@ops.ietf.org, j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <20080125091946.GA17440@elstar.local> References: <20080124.185012.212081588.mbj@tail-f.com> <20080124193906.GB16515@elstar.local> <20080125091946.GA17440@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Juergen, Juergen Schoenwaelder wrote: > I started a wiki page to track NETCONF RFC 4741 issues. > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF There's also: http://www3.tools.ietf.org/wg/netconf/trac/report/1 Do we need both? /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 05:02:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILNx-0008EZ-4A; Fri, 25 Jan 2008 05:02:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILNw-0008EI-41 for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:02:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILNv-0008E2-QN for yang@ietf.org; Fri, 25 Jan 2008 05:02:07 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILNt-0001I6-UQ for yang@ietf.org; Fri, 25 Jan 2008 05:02:07 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7A668D800BD for ; Fri, 25 Jan 2008 11:02:05 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <200801250311.m0P3Bhbo036061@idle.juniper.net> References: <200801250311.m0P3Bhbo036061@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 11:02:05 +0100 Message-Id: <1201255325.24635.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v =C4=8Ct 24. 01. 2008 v 22:11 -0500: > Ladislav Lhotka writes: > >In my interpretation the mandatory/optional and default concepts are > >orthogonal. The former relates to the structure (leaf must or needn't > >exist) whereas the latter to the value. >=20 > They aren't orthogonal. Your intepretation leads to the logic Andy > laid out earlier: >=20 > Q1: Is it mandatory? > true --> > Q2: Does it have a default? > false --> > A: Then the leaf must be explicitly set I guess I differ from Andy here: in my view the agent will fill here a value that satisfies the DM, even though it is not a default specified in the DM (i.e, it is vendor's internal default). For example, if IP address is mandatory on an interface but no default is defined in the DM, the device could set it to 0.0.0.0. From the viewpoint of validating the configuration (my item 2), it is valid - the mandatory element exists and its value (presumably) conforms to inet:ip-address. True, the interface is not fully operational, but this has nothing to do with validity of the configuration wrt the DM. > true --> > A: Then the agent must implicitly create it w/ the defaul= t > false --> > A: no one does anything >=20 >=20 > How? If I give the user a form to fill in with the full name (which > I assume I should since the data model says it's there), and the user > gives me one, I'll send it to the device. Will the device throw it > away? This will lead to much weeping and gnashing of teeth. In most cases a warning would be appropriate. I think though such situations are hardly avoidable. I take your example: leaf mtu { type uint { range 576..8192; } } What if a device supports only a subset of this range and the user tries to set it to a value outside of this subset? Or should the range statement in fact mean that this data model requires each implementation to support the entire range? >=20 > >Again, my model: if a parameter is optional then the client cannot be > >surprised if it is not in the configuration obtained by get-config and > >attempts to set it are ignored or return a warning. >=20 > This would be disasterous and would render the entire effort of > data modeling moot. The data model is supposed to move us out > of the Wild West and into a more civilized world. If the locals > can ignore parts of the law, then there is no law. If you can't > even find out what parts of the law are being ignored, you're lost. If the law says something is optional, I can assume it's possible not to have it. >=20 > >I fully agree, we only differ in the interpretation of a YANG statemen= t. >=20 > It seems we disagree on much more than that. Should we step back > and think about what problem we're trying to solve? >=20 Okay, what I am trying to solve: I'd like to have first rather generic data models that can be used by a broad range of devices. This is IMO possible only if the data models are relatively liberal. The first important step for me is to be able to decide whether an entire configuration is valid (in a static XML-like sense) and what it means for the NETCONF PDUs. This would already be a big boon - the knobs would be standardised. I am not saying the other aspects of validity (behaviour of the devices and managers) are unimportant but these are separate problems that should be addressed separately. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 05:05:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILRB-0007Ws-4B; Fri, 25 Jan 2008 05:05:29 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILRA-0007Wi-I8 for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:05:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILRA-0007WX-7a for yang@ietf.org; Fri, 25 Jan 2008 05:05:28 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JILR9-0000Bl-S6 for yang@ietf.org; Fri, 25 Jan 2008 05:05:28 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B9788A1A3; Fri, 25 Jan 2008 11:05:26 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26953-02-8; Fri, 25 Jan 2008 11:05:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 601B08A2DF; Fri, 25 Jan 2008 11:04:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 475CB48AB90; Fri, 25 Jan 2008 11:04:35 +0100 (CET) Date: Fri, 25 Jan 2008 11:04:35 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] errors Message-ID: <20080125100435.GA17475@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ops.ietf.org, yang@ietf.org References: <20080124.185012.212081588.mbj@tail-f.com> <20080124193906.GB16515@elstar.local> <20080125091946.GA17440@elstar.local> <20080125.110119.211713651.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080125.110119.211713651.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: yang@ietf.org, netconf@ops.ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Jan 25, 2008 at 11:01:19AM +0100, Martin Bjorklund wrote: > Hi Juergen, > > Juergen Schoenwaelder wrote: > > I started a wiki page to track NETCONF RFC 4741 issues. > > > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF > > There's also: > > http://www3.tools.ietf.org/wg/netconf/trac/report/1 > > Do we need both? No, I did not know that this exists. Who is putting stuff on there? I am happy to kill my page on favour of this one... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 05:07:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILTX-0008Og-0G; Fri, 25 Jan 2008 05:07:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILTV-0008OZ-Qb for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:07:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILTU-0008Np-I1 for yang@ietf.org; Fri, 25 Jan 2008 05:07:52 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JILTU-0000L4-5G for yang@ietf.org; Fri, 25 Jan 2008 05:07:52 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A86568A0EA; Fri, 25 Jan 2008 11:07:51 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27868-02-4; Fri, 25 Jan 2008 11:07:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64E028A189; Fri, 25 Jan 2008 11:07:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 56FB748ABCC; Fri, 25 Jan 2008 11:07:44 +0100 (CET) Date: Fri, 25 Jan 2008 11:07:44 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080125100744.GB17475@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801250311.m0P3Bhbo036061@idle.juniper.net> <1201255325.24635.70.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201255325.24635.70.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Jan 25, 2008 at 11:02:05AM +0100, Ladislav Lhotka wrote: > I guess I differ from Andy here: in my view the agent will fill here a > value that satisfies the DM, even though it is not a default specified > in the DM (i.e, it is vendor's internal default). For example, if IP > address is mandatory on an interface but no default is defined in the > DM, the device could set it to 0.0.0.0. From the viewpoint of validating > the configuration (my item 2), it is valid - the mandatory element > exists and its value (presumably) conforms to inet:ip-address. True, the > interface is not fully operational, but this has nothing to do with > validity of the configuration wrt the DM. I guess part of the problem we have in this discussion is that we do not properly distinguish between configuration data and operational state data. While a device may choose to assign automatically an operational state of 0.0.0.0 for an unconfigured IPv4 address, this particular address may still not be configuration state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 05:10:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILWB-00021A-Ue; Fri, 25 Jan 2008 05:10:39 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILWA-0001xO-MN for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILWA-0001uo-9O for yang@ietf.org; Fri, 25 Jan 2008 05:10:38 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILW9-0001tZ-Ug for yang@ietf.org; Fri, 25 Jan 2008 05:10:38 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 57BD81B80D7; Fri, 25 Jan 2008 11:10:37 +0100 (CET) Date: Fri, 25 Jan 2008 11:12:03 +0100 (CET) Message-Id: <20080125.111203.133760488.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <20080125100435.GA17475@elstar.local> References: <20080125091946.GA17440@elstar.local> <20080125.110119.211713651.mbj@tail-f.com> <20080125100435.GA17475@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: yang@ietf.org, netconf@ops.ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Jan 25, 2008 at 11:01:19AM +0100, Martin Bjorklund wrote: > > Hi Juergen, > > > > Juergen Schoenwaelder wrote: > > > I started a wiki page to track NETCONF RFC 4741 issues. > > > > > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF > > > > There's also: > > > > http://www3.tools.ietf.org/wg/netconf/trac/report/1 > > > > Do we need both? > > No, I did not know that this exists. Who is putting stuff on there? You! Me! You just have to register. But as you can see, all tickets were created last summer, and since then not much has happend. I just added a ticket for the error-severity problem. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 05:20:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILfN-0004LG-RX; Fri, 25 Jan 2008 05:20:09 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILfN-0004L8-1G for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:20:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILfM-0004L0-ND for yang@ietf.org; Fri, 25 Jan 2008 05:20:08 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JILfM-0000p0-AJ for yang@ietf.org; Fri, 25 Jan 2008 05:20:08 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4B1D8D800C5 for ; Fri, 25 Jan 2008 11:20:07 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <200801250614.m0P6EJwJ036835@idle.juniper.net> References: <200801250614.m0P6EJwJ036835@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 11:20:06 +0100 Message-Id: <1201256406.24635.82.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 01:14 -0500: > "Randy Presuhn" writes: > >In the SNMP/SMI worlds, the "optionality" Ladislav refers to is > >handled by conformance statements, rather than the model per se. >=20 > Ah so maybe the confusion is "mandatory to implement" versus > "mandatory to configure". YANG's mandatory statement is the latter. Oh yes, this is the Pudels Kern :-) I am sorry I wasn't able to express myself so concisely. However, I still think Sec. 7.6.4 in the YANG draft can be understood as "mandatory to implement": >>If "mandatory" is "true", the node must exist in a valid configuration if its parent node exists.<< I guess it's again due to the different meanings of validity. Lada >=20 > YANG has no conformance mechanism. Whether it appears in YANG-2.0, > I can't predict, but I'm hoping we can make base models that devices > can implement, with augmentations for additional config. >=20 > Thanks, > Phil >=20 >=20 > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 05:23:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILiz-0007Al-2s; Fri, 25 Jan 2008 05:23:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILiy-0007Ag-BU for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:23:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILiy-0007AY-1B for yang@ietf.org; Fri, 25 Jan 2008 05:23:52 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JILix-0000yI-KQ for yang@ietf.org; Fri, 25 Jan 2008 05:23:51 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2550CD800C5 for ; Fri, 25 Jan 2008 11:23:51 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080125100744.GB17475@elstar.local> References: <200801250311.m0P3Bhbo036061@idle.juniper.net> <1201255325.24635.70.camel@missotis> <20080125100744.GB17475@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 11:23:50 +0100 Message-Id: <1201256631.24635.84.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 11:07 +0100= : > On Fri, Jan 25, 2008 at 11:02:05AM +0100, Ladislav Lhotka wrote: > =20 > > I guess I differ from Andy here: in my view the agent will fill here = a > > value that satisfies the DM, even though it is not a default specifie= d > > in the DM (i.e, it is vendor's internal default). For example, if IP > > address is mandatory on an interface but no default is defined in the > > DM, the device could set it to 0.0.0.0. From the viewpoint of validat= ing > > the configuration (my item 2), it is valid - the mandatory element > > exists and its value (presumably) conforms to inet:ip-address. True, = the > > interface is not fully operational, but this has nothing to do with > > validity of the configuration wrt the DM. >=20 > I guess part of the problem we have in this discussion is that we do > not properly distinguish between configuration data and operational > state data. While a device may choose to assign automatically an > operational state of 0.0.0.0 for an unconfigured IPv4 address, this > particular address may still not be configuration state. Would it be a problem if it were a factory default configuration state as well? Lada >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 05:30:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILpD-0001QQ-UU; Fri, 25 Jan 2008 05:30:19 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JILpD-0001Ew-2L for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 05:30:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILpC-0001Aw-LR for yang@ietf.org; Fri, 25 Jan 2008 05:30:18 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILpB-0002KZ-7m for yang@ietf.org; Fri, 25 Jan 2008 05:30:18 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBCD28A0EA; Fri, 25 Jan 2008 11:30:16 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30187-04-2; Fri, 25 Jan 2008 11:30:12 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A0248A1DE; Fri, 25 Jan 2008 11:30:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2BE3E48AD21; Fri, 25 Jan 2008 11:30:10 +0100 (CET) Date: Fri, 25 Jan 2008 11:30:10 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080125103010.GD17475@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801250311.m0P3Bhbo036061@idle.juniper.net> <1201255325.24635.70.camel@missotis> <20080125100744.GB17475@elstar.local> <1201256631.24635.84.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201256631.24635.84.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Jan 25, 2008 at 11:23:50AM +0100, Ladislav Lhotka wrote: > Would it be a problem if it were a factory default configuration > state as well? If I as a user configure a box, I usually do not want to see the millions of knobs that exists in the box which I have never touched and are mostly irrelevant, especially for things like e.g. interfaces that not configured by me. As someone who has to configure boxes once in a while, I do agree with Phil's plea to keep the configuration really down to the minimum that I have really configured and to exclude noise about all the things I could potentially configure as much as possible. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 06:18:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMZO-0008BR-3r; Fri, 25 Jan 2008 06:18:02 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIMZM-00080j-KX for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 06:18:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMZM-0007zC-8t for yang@ietf.org; Fri, 25 Jan 2008 06:18:00 -0500 Received: from web27803.mail.ukl.yahoo.com ([217.146.182.8]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIMZK-0002Aa-QN for yang@ietf.org; Fri, 25 Jan 2008 06:17:59 -0500 Received: (qmail 8044 invoked by uid 60001); 25 Jan 2008 11:17:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=a5OohzT3+1+NgR+/Oj4dxp0OEga7i23o7mU9G1yJ+IY+cae9oOCpXGD283ofGgZQ1SaX9YUWLOtuxUYnkX2ugm2kr21fslaR14MFEUi/k7HIp23mAtZWhLlqTowyGXtoF//kmkmBBQi+YVXralIVzLlK9wssXKlHR/eTCyqjmCc=; X-YMail-OSG: CsVQz98VM1kMIv1LMqmQmHTLCV0YZk94ijeq6wpyi.bpNR90NPlXKMNWFpFjDr5pHtdDMIIjEFvMsRfWG5H2RTrNrShfFuOjw7RibBAaNiVjpuuH2dBSngeHB7A- Received: from [217.115.75.231] by web27803.mail.ukl.yahoo.com via HTTP; Fri, 25 Jan 2008 11:17:55 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.160 Date: Fri, 25 Jan 2008 11:17:55 +0000 (GMT) From: Mehmet Ersue Subject: Netconf issue tracker WAS: Re: [YANG] errors To: j.schoenwaelder@jacobs-university.de, Martin MIME-Version: 1.0 Message-ID: <851758.5155.qm@web27803.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: yang@ietf.org, NETCONF X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mehmet Ersue List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1961699578==" Errors-To: yang-bounces@ietf.org --===============1961699578== Content-Type: multipart/alternative; boundary="0-1683349822-1201259875=:5155" --0-1683349822-1201259875=:5155 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi Juergen, All,=0A=0AI think it's a good idea to have the issues on a c= entral place and=0Ato use the existing page on Netconf Wiki. We are going t= o clean =0Ait up soon.=0A=0AIn parallel the additional Netconf page will be= moved from =0Ahttp://www.ops.ietf.org/netconf/ to http://www3.tools.ietf.o= rg/wg/netconf/trac/wiki.=0A=0ACheers, =0AMehmet =0A =0A=0A> -----Original M= essage-----=0A> From: ext Juergen Schoenwaelder =0A> [mailto:j.schoenwaelde= r@jacobs-university.de] =0A> Sent: Friday, January 25, 2008 11:05 AM=0A> To= : Martin Bjorklund=0A> Cc: yang@ietf.org; netconf@ops.ietf.org=0A> Subject:= Re: [YANG]=0A errors=0A> =0A> On Fri, Jan 25, 2008 at 11:01:19AM +0100, Ma= rtin Bjorklund wrote:=0A> > Hi Juergen,=0A> > =0A> > Juergen Schoenwaelder = wrote:=0A> > > I started a wiki page= to track NETCONF RFC 4741 issues. =0A> > > =0A> > > http://cnds.eecs.jacob= s-university.de/wiki/NETCONF=0A> > =0A> > There's also:=0A> > =0A> > http:/= /www3.tools.ietf.org/wg/netconf/trac/report/1=0A> > =0A> > Do we need both?= =0A> =0A> No, I did not know that this exists. Who is putting stuff on ther= e? I=0A> am happy to kill my page on favour of this one...=0A> =0A> /js=0A>= =0A> -- =0A> Juergen=0A Schoenwaelder Jacobs University Bremen g= GmbH=0A> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germa= ny=0A> Fax: +49 421 200 3103 = =0A> =0A> =0A> _______________________________________________=0A> YANG mai= ling list=0A> YANG@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/yang= =0A> =0A=0A=0A=0A=0A=0A __________________________________ Ihr erstes= Fernweh? Wo gibt es den sch=C3=B6nsten Strand? www.yahoo.de/clever --0-1683349822-1201259875=:5155 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Juergen, All,

I think it's a good idea to have the issu= es on a central place and
to use the existing page on Netconf Wiki. We a= re going to clean
it up soon.

In parallel the additional Netconf= page will be moved from
http://www.ops.ietf.org/netconf/ to http://www3.tools.ietf.org/wg/netconf/trac/wiki.

Cheers,
Mehmet


> -----Original Message= -----
> From: ext Juergen Schoenwaelder
> [mailto:j.schoenwael= der@jacobs-university.de]
> Sent: Friday, January 25, 2008 11:05 AM<= br>> To: Martin Bjorklund
> Cc: yang@ietf.org; netconf@ops.ietf.org
> S= ubject: Re: [YANG]=0A errors
>
> On Fri, Jan 25, 2008 at 11:01= :19AM +0100, Martin Bjorklund wrote:
> > Hi Juergen,
> > =
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.d= e> wrote:
> > > I started a wiki page to track NETCONF RFC 4= 741 issues.
> > >
> > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF
> &= gt;
> > There's also:
> >
> > http://www3.tools.ietf.org/wg/netconf/trac/report/1
> >
> > Do we need both?
>
> No, I did no= t know that this exists. Who is putting stuff on there? I
> am happy = to kill my page on favour of this one...
>
> /js
>
&= gt; --
> Juergen=0A Schoenwaelder      = ;     Jacobs University Bremen gGmbH
> Phone: +49= 421 200 3587         Campus Ring 1= , 28759 Bremen, Germany
> Fax:   +49 421 200 3103&nbs= p;        <http://www.jacobs-uni= versity.de/>
>
>
> ______________________= _________________________
> YANG mailing list
> YANG@ietf.org> https://www1.ietf.org/mailman/listinfo/yang
>

=0A=0A=0A=0A
H= eute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie=C2= =B4s mit dem =0Aneuen Yahoo! Mail. =0A<= /body> --0-1683349822-1201259875=:5155-- --===============1961699578== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1961699578==-- From yang-bounces@ietf.org Fri Jan 25 06:19:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMaj-0001lN-Tx; Fri, 25 Jan 2008 06:19:25 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIMaj-0001kW-6i for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 06:19:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMai-0001hx-Rb for yang@ietf.org; Fri, 25 Jan 2008 06:19:24 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIMai-00039N-6R for yang@ietf.org; Fri, 25 Jan 2008 06:19:24 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6397A21482; Fri, 25 Jan 2008 12:19:23 +0100 (CET) X-AuditID: c1b4fb3e-afe1dbb0000007e1-a8-4799c5bbe905 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 56A8421325; Fri, 25 Jan 2008 12:19:23 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:19:23 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:19:22 +0100 Message-ID: <4799C5BA.5020606@ericsson.com> Date: Fri, 25 Jan 2008 12:19:22 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors References: <200801250614.m0P6EJwJ036835@idle.juniper.net> <1201256406.24635.82.camel@missotis> In-Reply-To: <1201256406.24635.82.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 25 Jan 2008 11:19:22.0719 (UTC) FILETIME=[22DA0EF0:01C85F44] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Mandatory in YANG means mandatory to configure. Today YANG considers all mandatory and optional elements mandatory to imp= lement. Later we will probably define a conformance mechanism, then YANG will be = able to say: module foo defines 100 leafs and these 85 are mandatory to implement and = the rest is optional. We consider this conformance mechanism to belong to step to in the DML. A= FAIK it is not really=20 used in SNMP either. (We could start using mustImplement or something sim= ilar as a term for=20 mandatory to implement.) Balazs Ladislav Lhotka wrote: > Phil Shafer p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 01:14 -0500: >> "Randy Presuhn" writes: >>> In the SNMP/SMI worlds, the "optionality" Ladislav refers to is >>> handled by conformance statements, rather than the model per se. >> Ah so maybe the confusion is "mandatory to implement" versus >> "mandatory to configure". YANG's mandatory statement is the latter. >=20 > Oh yes, this is the Pudels Kern :-) I am sorry I wasn't able to express > myself so concisely. However, I still think Sec. 7.6.4 in the YANG draf= t > can be understood as "mandatory to implement": >>If "mandatory" is > "true", the node must exist in a valid configuration if its parent node > exists.<< I guess it's again due to the different meanings of validity. >=20 > Lada >=20 >> YANG has no conformance mechanism. Whether it appears in YANG-2.0, >> I can't predict, but I'm hoping we can make base models that devices >> can implement, with augmentations for additional config. >> >> Thanks, >> Phil >> >> >> _______________________________________________ >> YANG mailing list >> YANG@ietf.org >> https://www1.ietf.org/mailman/listinfo/yang --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 06:47:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIN24-0002oc-DE; Fri, 25 Jan 2008 06:47:40 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIN23-0002oV-Pj for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 06:47:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIN23-0002mb-F0 for yang@ietf.org; Fri, 25 Jan 2008 06:47:39 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIN23-0003hc-1N for yang@ietf.org; Fri, 25 Jan 2008 06:47:39 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9D582D800C4 for ; Fri, 25 Jan 2008 12:47:36 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080125103010.GD17475@elstar.local> References: <200801250311.m0P3Bhbo036061@idle.juniper.net> <1201255325.24635.70.camel@missotis> <20080125100744.GB17475@elstar.local> <1201256631.24635.84.camel@missotis> <20080125103010.GD17475@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 12:47:36 +0100 Message-Id: <1201261656.24635.117.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 11:30 +0100= : > On Fri, Jan 25, 2008 at 11:23:50AM +0100, Ladislav Lhotka wrote: > =20 > > Would it be a problem if it were a factory default configuration > > state as well? >=20 > If I as a user configure a box, I usually do not want to see the > millions of knobs that exists in the box which I have never touched > and are mostly irrelevant, especially for things like e.g. interfaces > that not configured by me. As someone who has to configure boxes once > in a while, I do agree with Phil's plea to keep the configuration > really down to the minimum that I have really configured and to > exclude noise about all the things I could potentially configure as > much as possible. I see, so we essentially come back to the fact that I would leave the task of reducing complexity on the client side whereas you want to have it on the server side. Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 06:55:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIN9K-0003t5-6B; Fri, 25 Jan 2008 06:55:10 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIN9J-0003sq-HC for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 06:55:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIN9J-0003si-7a for yang@ietf.org; Fri, 25 Jan 2008 06:55:09 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIN9I-0003pC-M8 for yang@ietf.org; Fri, 25 Jan 2008 06:55:09 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6BE10D800C4; Fri, 25 Jan 2008 12:55:08 +0100 (CET) Subject: Re: [YANG] new pyang errors From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <4799C5BA.5020606@ericsson.com> References: <200801250614.m0P6EJwJ036835@idle.juniper.net> <1201256406.24635.82.camel@missotis> <4799C5BA.5020606@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 12:55:08 +0100 Message-Id: <1201262108.24635.124.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Balasz, Balazs Lengyel p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 12:19 +0100: > Mandatory in YANG means mandatory to configure. > Today YANG considers all mandatory and optional elements mandatory to i= mplement. >=20 > Later we will probably define a conformance mechanism, then YANG will b= e able to say: >=20 > module foo defines 100 leafs and these 85 are mandatory to implement an= d the rest is optional. >=20 > We consider this conformance mechanism to belong to step to in the DML.= AFAIK it is not really=20 > used in SNMP either. (We could start using mustImplement or something s= imilar as a term for=20 > mandatory to implement.) I guess it's actually one of the differences between the SNMP and XML worlds. Validity of an XML document means conformance to a schema. Lada >=20 > Balazs >=20 > Ladislav Lhotka wrote: > > Phil Shafer p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 01:14 -0500: > >> "Randy Presuhn" writes: > >>> In the SNMP/SMI worlds, the "optionality" Ladislav refers to is > >>> handled by conformance statements, rather than the model per se. > >> Ah so maybe the confusion is "mandatory to implement" versus > >> "mandatory to configure". YANG's mandatory statement is the latter. > >=20 > > Oh yes, this is the Pudels Kern :-) I am sorry I wasn't able to expre= ss > > myself so concisely. However, I still think Sec. 7.6.4 in the YANG dr= aft > > can be understood as "mandatory to implement": >>If "mandatory" is > > "true", the node must exist in a valid configuration if its parent no= de > > exists.<< I guess it's again due to the different meanings of validit= y. > >=20 > > Lada > >=20 > >> YANG has no conformance mechanism. Whether it appears in YANG-2.0, > >> I can't predict, but I'm hoping we can make base models that devices > >> can implement, with augmentations for additional config. > >> > >> Thanks, > >> Phil > >> > >> > >> _______________________________________________ > >> YANG mailing list > >> YANG@ietf.org > >> https://www1.ietf.org/mailman/listinfo/yang >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 06:57:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINB7-0001px-VX; Fri, 25 Jan 2008 06:57:01 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JINB6-0001pK-TR for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 06:57:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINB6-0001p5-J1 for yang@ietf.org; Fri, 25 Jan 2008 06:57:00 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JINB6-0003HH-6c for yang@ietf.org; Fri, 25 Jan 2008 06:57:00 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 008F5D800BD for ; Fri, 25 Jan 2008 12:56:59 +0100 (CET) From: Ladislav Lhotka To: yang In-Reply-To: <200801250311.m0P3Bhbo036061@idle.juniper.net> References: <200801250311.m0P3Bhbo036061@idle.juniper.net> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 12:56:59 +0100 Message-Id: <1201262219.24635.125.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [YANG] meaning of unique in PDUs X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer p=C3=AD=C5=A1e v =C4=8Ct 24. 01. 2008 v 22:11 -0500: > >In some cases this mapping is automatic, some cases are defined in the > >YANG draft and some are not clear yet (to me at least). >=20 > Please let me know where it isn't clear and we can fix the draft. >=20 Here is one: what's the interpretation (if any) of the unique statement for PDUs? Example: list aaa { key "k"; unique "b c"; leaf k { ... } leaf b { ... } leaf c { ... } and assume the existing configuration contains two list items: k1 b1 c1 k2 b2 c2 =20 1. Is it possible to send the following fragment in an edit-config (merge mode)? k1 b3 k2 b3 That is, after merging the resulting configuration will still satisfy the statement 'unique "b c"' (values of c are different) but the PDU doeasn't. 2. Does "unique" and also "key" statements assume any space normalisation? For example, are the following keys different? k1 k1 Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 07:05:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINIs-000510-3Y; Fri, 25 Jan 2008 07:05:02 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JINIr-00050m-4o for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 07:05:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINIq-00050c-Px for yang@ietf.org; Fri, 25 Jan 2008 07:05:00 -0500 Received: from relay.versatel.net ([62.250.3.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JINIq-0004Hm-2d for yang@ietf.org; Fri, 25 Jan 2008 07:05:00 -0500 Received: (qmail 11005 invoked from network); 25 Jan 2008 12:04:57 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 12:04:57 -0000 From: "Bert Wijnen" To: "Balazs Lengyel" , "Ladislav Lhotka" Subject: RE: [YANG] new pyang errors Date: Fri, 25 Jan 2008 13:05:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4799C5BA.5020606@ericsson.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Inline Bert Wijnen=20 > -----Oorspronkelijk bericht----- > Van: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Verzonden: vrijdag 25 januari 2008 12:19 > Aan: Ladislav Lhotka > CC: yang@ietf.org > Onderwerp: Re: [YANG] new pyang errors >=20 >=20 > Mandatory in YANG means mandatory to configure. > Today YANG considers all mandatory and optional elements=20 > mandatory to implement. >=20 OK, I like that. Can you make that statement explicit in the draft, so everyone understands the intention. > Later we will probably define a conformance mechanism, then YANG=20 > will be able to say: >=20 > module foo defines 100 leafs and these 85 are mandatory to=20 > implement and the rest is optional. >=20 > We consider this conformance mechanism to belong to step to in=20 > the DML. AFAIK it is not really used in SNMP either. In some MIB modules we actually have pretty good MODULE-COMPLIANCE statements that try to make it clear which objects must be implemented and what their minimum implementation needs to support. Such MIB modules often have multiple such module-compliance statements if that makes sense for different environments.=20 Other MIB modules just have one big MODULE-COMPLIANCE statement that - requires to implement all objects - but leaves it open to the implementation to implement them read-only or read-write.=20 Supposedly that can be reported by the agent via a AGENT-CAPABILITIES, (in which one can also report deviations) which results in an OID=20 that one can store in the sysOrTable and so a manager can pick up the=20 compliance that an agent claims and then supposedly can read the AGENT-CAPABILITIES statement and so it can determine (in machine readable form) what exactly is supported by the agent. Well, at least that was/is the theory. But other than during early SNMP interoperability tests in the mid-1990s I have never seen it used much (if at all).=20 So we should learn from this and think hard before we fall into the same trap of designing mechanisms that no-one uses. Bert > (We could start using mustImplement or=20 > something similar as a term for=20 > mandatory to implement.) >=20 > Balazs >=20 > Ladislav Lhotka wrote: > > Phil Shafer p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 01:14 -0500: > >> "Randy Presuhn" writes: > >>> In the SNMP/SMI worlds, the "optionality" Ladislav refers to is > >>> handled by conformance statements, rather than the model per se. > >> Ah so maybe the confusion is "mandatory to implement" versus > >> "mandatory to configure". YANG's mandatory statement is the = latter. > >=20 > > Oh yes, this is the Pudels Kern :-) I am sorry I wasn't able to = express > > myself so concisely. However, I still think Sec. 7.6.4 in the YANG = draft > > can be understood as "mandatory to implement": >>If "mandatory" is > > "true", the node must exist in a valid configuration if its parent = node > > exists.<< I guess it's again due to the different meanings of = validity. > >=20 > > Lada > >=20 > >> YANG has no conformance mechanism. Whether it appears in YANG-2.0, > >> I can't predict, but I'm hoping we can make base models that = devices > >> can implement, with augmentations for additional config. > >> > >> Thanks, > >> Phil > >> > >> > >> _______________________________________________ > >> YANG mailing list > >> YANG@ietf.org > >> https://www1.ietf.org/mailman/listinfo/yang >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >=20 >=20 > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang >=20 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 07:42:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINtW-0000XM-5F; Fri, 25 Jan 2008 07:42:54 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JINtU-0000XG-If for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 07:42:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINtU-0000X8-7m for yang@ietf.org; Fri, 25 Jan 2008 07:42:52 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JINtT-0005CT-LQ for yang@ietf.org; Fri, 25 Jan 2008 07:42:52 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 55F821B80CC; Fri, 25 Jan 2008 13:42:50 +0100 (CET) Date: Fri, 25 Jan 2008 13:44:17 +0100 (CET) Message-Id: <20080125.134417.43491219.mbj@tail-f.com> To: lhotka@cesnet.cz Subject: Re: [YANG] meaning of unique in PDUs From: Martin Bjorklund In-Reply-To: <1201262219.24635.125.camel@missotis> References: <200801250311.m0P3Bhbo036061@idle.juniper.net> <1201262219.24635.125.camel@missotis> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2090693356==" Errors-To: yang-bounces@ietf.org --===============2090693356== Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gUGhpbCBTaGFmZXIg cMOtxaFlIHYgxIx0IDI0LiAwMS4gMjAwOCB2IDIyOjExIC0wNTAwOg0KPiA+ID5JbiBzb21lIGNh c2VzIHRoaXMgbWFwcGluZyBpcyBhdXRvbWF0aWMsIHNvbWUgY2FzZXMgYXJlIGRlZmluZWQgaW4g dGhlDQo+ID4gPllBTkcgZHJhZnQgYW5kIHNvbWUgYXJlIG5vdCBjbGVhciB5ZXQgKHRvIG1lIGF0 IGxlYXN0KS4NCj4gPiANCj4gPiBQbGVhc2UgbGV0IG1lIGtub3cgd2hlcmUgaXQgaXNuJ3QgY2xl YXIgYW5kIHdlIGNhbiBmaXggdGhlIGRyYWZ0Lg0KPiA+IA0KPiBIZXJlIGlzIG9uZTogd2hhdCdz IHRoZSBpbnRlcnByZXRhdGlvbiAoaWYgYW55KSBvZiB0aGUgdW5pcXVlIHN0YXRlbWVudA0KPiBm b3IgUERVcz8NCg0KVGhlIGRyYWZ0IHNheXM6DQoNCiAgVGhlICJ1bmlxdWUiIHN0YXRlbWVudCBp cyB1c2VkIHRvIHB1dCBjb25zdHJhaW50cyBvbiB2YWxpZA0KICBjb25maWd1cmF0aW9ucy4gWy4u Ll0NCg0KICBJbiBhIHZhbGlkIGNvbmZpZ3VyYXRpb24sIHRoZSBjb21iaW5lZCB2YWx1ZXMgb2Yg YWxsIHRoZSBsZWFmDQogIGluc3RhbmNlcyBzcGVjaWZpZWQgaW4gdGhlIHN0cmluZyBNVVNUIGJl IHVuaXF1ZSB3aXRoaW4gYWxsIGxpc3QNCiAgZW50cnkgaW5zdGFuY2VzLg0KDQpNYXliZSB3ZSBz aG91bGQgYmUgbW9yZSBjbGVhciB3aGF0IHdlIG1lYW4gd2l0aCAidmFsaWQgY29uZmlndXJhdGlv biI/DQoNCj4gRXhhbXBsZToNCj4gDQo+IGxpc3QgYWFhIHsNCj4gICBrZXkgImsiOw0KPiAgIHVu aXF1ZSAiYiBjIjsNCj4gICBsZWFmIGsgeyAuLi4gfQ0KPiAgIGxlYWYgYiB7IC4uLiB9DQo+ICAg bGVhZiBjIHsgLi4uIH0NCj4gDQo+IGFuZCBhc3N1bWUgdGhlIGV4aXN0aW5nIGNvbmZpZ3VyYXRp b24gY29udGFpbnMgdHdvIGxpc3QgaXRlbXM6DQo+IA0KPiA8YWFhPg0KPiAgIDxrPmsxPC9rPiA8 Yj5iMTwvYj4gPGM+YzE8L2M+DQo+IDwvYWFhPg0KPiA8YWFhPg0KPiAgIDxrPmsyPC9rPiA8Yj5i MjwvYj4gPGM+YzI8L2M+DQo+IDwvYWFhPiAgDQo+IA0KPiAxLiBJcyBpdCBwb3NzaWJsZSB0byBz ZW5kIHRoZSBmb2xsb3dpbmcgZnJhZ21lbnQgaW4gYW4gZWRpdC1jb25maWcNCj4gKG1lcmdlIG1v ZGUpPw0KPiANCj4gPGFhYT4NCj4gICA8az5rMTwvaz4gPGI+YjM8L2I+DQo+IDxhYWE+DQo+IDxh YWE+DQo+ICAgPGs+azI8L2s+IDxiPmIzPC9iPg0KPiA8YWFhPg0KPiANCj4gVGhhdCBpcywgYWZ0 ZXIgbWVyZ2luZyB0aGUgcmVzdWx0aW5nIGNvbmZpZ3VyYXRpb24gd2lsbCBzdGlsbCBzYXRpc2Z5 DQo+IHRoZSBzdGF0ZW1lbnQgJ3VuaXF1ZSAiYiBjIicgKHZhbHVlcyBvZiBjIGFyZSBkaWZmZXJl bnQpIGJ1dCB0aGUgUERVDQo+IGRvZWFzbid0Lg0KDQpBYnNvbHV0ZWx5LiAgQWxzbyBub3RlIHRo YXQgaWYgeW91J3JlIG1vZGlmeWluZyB0aGUgY2FuZGlkYXRlLCBpdA0KaXMgYWxzbyBvayB0byBz ZW5kOg0KDQogPGFhYT4NCiAgIDxrPmsxPC9rPiA8Yj5iMzwvYj4gPGM+YzM8L2M+DQogPGFhYT4N CiA8YWFhPg0KICAgPGs+azI8L2s+IDxiPmIzPC9iPiA8Yz5jMzwvYz4NCiA8YWFhPg0KDQpXaGVu IHlvdSA8dmFsaWRhdGUvPiB0aGUgY2FuZGlkYXRlLCBpdCB3aWxsIGZhaWwuICBJdCB3aWxsIGFs c28gZmFpbA0KdG8gPGNvbW1pdC8+Lg0KDQo+IDIuIERvZXMgInVuaXF1ZSIgYW5kIGFsc28gImtl eSIgc3RhdGVtZW50cyBhc3N1bWUgYW55IHNwYWNlDQo+IG5vcm1hbGlzYXRpb24/IEZvciBleGFt cGxlLCBhcmUgdGhlIGZvbGxvd2luZyBrZXlzIGRpZmZlcmVudD8NCj4gDQo+IDxrPmsxPC9rPg0K PiANCj4gPGs+DQo+ICAgazENCj4gPC9rPg0KDQpUaGlzIGlzbid0IHJlYWxseSBhICJ1bmlxdWUi IG9yICJrZXkiIHF1ZXN0aW9uOyBpdCBpcyBhIGRhdGF0eXBlDQplcXVlc3Rpb24uICBJbiB0aGlz IGNhc2UsIHRoZSBZQU5HIGJ1aWx0LWluIHR5cGUgInN0cmluZyIgYmVoYXZlcyBhcw0KInhzOnN0 cmluZyIsIHNvIG5vIHdoaXRlc3BhY2Ugbm9ybWFsaXphdGlvbiBpcyBkb25lLg0KDQoNCi9tYXJ0 aW4NCg== --===============2090693356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============2090693356==-- From yang-bounces@ietf.org Fri Jan 25 08:29:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIOcP-0002Pv-NJ; Fri, 25 Jan 2008 08:29:17 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIOcP-0002Pq-3W for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 08:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIOcO-0002Pi-Ok for yang@ietf.org; Fri, 25 Jan 2008 08:29:16 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIOcN-0006Ui-I3 for yang@ietf.org; Fri, 25 Jan 2008 08:29:16 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2C738A2EB; Fri, 25 Jan 2008 14:29:14 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16355-04-51; Fri, 25 Jan 2008 14:29:10 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2724D8A1BE; Fri, 25 Jan 2008 14:28:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 169F148B0E4; Fri, 25 Jan 2008 14:28:20 +0100 (CET) Date: Fri, 25 Jan 2008 14:28:20 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] new pyang errors Message-ID: <20080125132820.GA17758@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801250311.m0P3Bhbo036061@idle.juniper.net> <1201255325.24635.70.camel@missotis> <20080125100744.GB17475@elstar.local> <1201256631.24635.84.camel@missotis> <20080125103010.GD17475@elstar.local> <1201261656.24635.117.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201261656.24635.117.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Jan 25, 2008 at 12:47:36PM +0100, Ladislav Lhotka wrote: > I see, so we essentially come back to the fact that I would leave the > task of reducing complexity on the client side whereas you want to have > it on the server side. Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 08:33:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIOgm-0006EP-D4; Fri, 25 Jan 2008 08:33:48 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIOgh-00061e-M0 for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 08:33:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIOgh-0005x9-8Y for yang@ietf.org; Fri, 25 Jan 2008 08:33:43 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIOgg-0006ac-SG for yang@ietf.org; Fri, 25 Jan 2008 08:33:43 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 420A08A1FE; Fri, 25 Jan 2008 14:33:42 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 17243-04; Fri, 25 Jan 2008 14:33:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01A538A1F0; Fri, 25 Jan 2008 14:33:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B1AB348B14F; Fri, 25 Jan 2008 14:33:34 +0100 (CET) Date: Fri, 25 Jan 2008 14:33:34 +0100 From: Juergen Schoenwaelder To: Bert Wijnen Subject: Re: [YANG] new pyang errors Message-ID: <20080125133334.GB17758@elstar.local> Mail-Followup-To: Bert Wijnen , Balazs Lengyel , Ladislav Lhotka , yang@ietf.org References: <4799C5BA.5020606@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: yang@ietf.org, Ladislav Lhotka X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Jan 25, 2008 at 01:05:00PM +0100, Bert Wijnen wrote: > > We consider this conformance mechanism to belong to step to in > > the DML. AFAIK it is not really used in SNMP either. [...] > But other than during early SNMP interoperability tests in the mid-1990s > I have never seen it used much (if at all). > So we should learn from this and think hard before we fall into the > same trap of designing mechanisms that no-one uses. Perhaps a clarification: We are not saying conformance mechanisms are not useful. We just like to postpone them to the second phase of YANG since conformance mechanisms are not needed to get started and we like to keep the YANG effort reasonably scoped so that we have a chance to complete what we started in reasonable amounts of time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 09:03:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIP9b-0004Cw-U3; Fri, 25 Jan 2008 09:03:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIP9b-0004Cd-44 for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 09:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIP9a-0004CR-Py for yang@ietf.org; Fri, 25 Jan 2008 09:03:34 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIP9Z-0007Cd-4L for yang@ietf.org; Fri, 25 Jan 2008 09:03:34 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8C69FD800C4 for ; Fri, 25 Jan 2008 15:03:32 +0100 (CET) Subject: Re: [YANG] meaning of unique in PDUs From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080125.134417.43491219.mbj@tail-f.com> References: <200801250311.m0P3Bhbo036061@idle.juniper.net> <1201262219.24635.125.camel@missotis> <20080125.134417.43491219.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 15:03:32 +0100 Message-Id: <1201269812.24635.181.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 13:44 +0100: > Ladislav Lhotka wrote: > > Phil Shafer p=C3=AD=C5=A1e v =C4=8Ct 24. 01. 2008 v 22:11 -0500: > > > >In some cases this mapping is automatic, some cases are defined in= the > > > >YANG draft and some are not clear yet (to me at least). > > >=20 > > > Please let me know where it isn't clear and we can fix the draft. > > >=20 > > Here is one: what's the interpretation (if any) of the unique stateme= nt > > for PDUs? >=20 > The draft says: >=20 > The "unique" statement is used to put constraints on valid > configurations. [...] Yup, but Phil claimed: YANG defines constraints on the XML that passes between the client and server. >=20 > In a valid configuration, the combined values of all the leaf > instances specified in the string MUST be unique within all list > entry instances. >=20 > Maybe we should be more clear what we mean with "valid configuration"? Yes, there seem to be at least four different meanings. > This isn't really a "unique" or "key" question; it is a datatype > equestion. In this case, the YANG built-in type "string" behaves as Sure, but here it is quite crucial. Shouldn't YANG perhaps include a built-in type equivalent to xs:token for these purposes? > "xs:string", so no whitespace normalization is done. >=20 Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 09:18:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIPO7-0001jE-MN; Fri, 25 Jan 2008 09:18:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIPO6-0001j8-Vc for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 09:18:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIPO6-0001j0-L4 for yang@ietf.org; Fri, 25 Jan 2008 09:18:34 -0500 Received: from relay.versatel.net ([62.250.3.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIPO6-0007qD-4H for yang@ietf.org; Fri, 25 Jan 2008 09:18:34 -0500 Received: (qmail 34302 invoked from network); 25 Jan 2008 14:18:31 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 14:18:31 -0000 From: "Bert Wijnen" To: Subject: RE: [YANG] new pyang errors Date: Fri, 25 Jan 2008 15:18:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080125133334.GB17758@elstar.local> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen responded to me: > > On Fri, Jan 25, 2008 at 01:05:00PM +0100, Bert Wijnen wrote: > > > > We consider this conformance mechanism to belong to step to in > > > the DML. AFAIK it is not really used in SNMP either. > > [...] > > > But other than during early SNMP interoperability tests in the mid-1990s > > I have never seen it used much (if at all). > > So we should learn from this and think hard before we fall into the > > same trap of designing mechanisms that no-one uses. > > Perhaps a clarification: We are not saying conformance mechanisms are > not useful. We just like to postpone them to the second phase of YANG > since conformance mechanisms are not needed to get started and we like > to keep the YANG effort reasonably scoped so that we have a chance to > complete what we started in reasonable amounts of time. > I understood that. And I am OK with postponing such work to a possible 2nd phase. Appology if I gave the impression that I wanted it to be addressed now. On the contrary, I was asking for reflection first and to not quickly design such a feature without first understanding why the mechanism we developed for MIB modules did not work (or did not get deployed). Bert > /js _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 10:19:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQL5-0003f9-OP; Fri, 25 Jan 2008 10:19:31 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIQL4-0003ca-Om for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 10:19:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQL4-0003bT-3d for yang@ietf.org; Fri, 25 Jan 2008 10:19:30 -0500 Received: from smtp110.sbc.mail.mud.yahoo.com ([68.142.198.209]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIQL3-0000z2-MW for yang@ietf.org; Fri, 25 Jan 2008 10:19:30 -0500 Received: (qmail 42796 invoked from network); 25 Jan 2008 15:19:28 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.97.95 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 25 Jan 2008 15:19:28 -0000 X-YMail-OSG: xu.uspYVM1maf_EJkXBGKk34_XGHBSo6JuCUcsPzfL4vhkdR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4799FD8F.1090402@andybierman.com> Date: Fri, 25 Jan 2008 07:17:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [YANG] mandatory & default X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, I don't think every vendor deals with agent-created defaults in the same way, and there is zero chance every implementation will converge on one interpretation. The important thing to consider is: what is important for standards-based configuration? Here is the bottom line: - RFC 4741 requires that *all* config database objects be returned in a without any filters - All data nodes that exist in the configuration have some value (consider the value for 'empty' to be present/not-present) - An extension is needed (e.g., with-defaults=false) to change the behavior of RFC 4741 wrt/ returning a subset of all nodes without any filter defined Phil seems to be arguing that nodes that contain the agent-specified default value are not really there. Yet, if the manager sets a node explicitly to the default value, it is there. IMO, this is rather confusing, and broken. The idea of tracking down stacks of offline vendor documentation to determine the theoretical values of these 'default nodes', instead of simply asking the agent for the real values, is a non-starter. That may be good enough for CLI, but not standards based configuration. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 10:29:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQUz-0004fW-BH; Fri, 25 Jan 2008 10:29:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIQUx-0004fO-Q8 for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 10:29:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQUx-0004fG-Ds for yang@ietf.org; Fri, 25 Jan 2008 10:29:43 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIQUw-0001Er-87 for yang@ietf.org; Fri, 25 Jan 2008 10:29:43 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7CE9C213D2; Fri, 25 Jan 2008 16:28:49 +0100 (CET) X-AuditID: c1b4fb3c-ad31ebb0000007e0-33-479a00312673 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6288E213C7; Fri, 25 Jan 2008 16:28:49 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 16:28:47 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 16:28:46 +0100 Message-ID: <479A002E.3070708@ericsson.com> Date: Fri, 25 Jan 2008 16:28:46 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman Subject: Re: [YANG] mandatory & default References: <4799FD8F.1090402@andybierman.com> In-Reply-To: <4799FD8F.1090402@andybierman.com> Content-Type: multipart/mixed; boundary="------------030103050403080701070401" X-OriginalArrivalTime: 25 Jan 2008 15:28:46.0956 (UTC) FILETIME=[FA3B6AC0:01C85F66] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org This is a multi-part message in MIME format. --------------030103050403080701070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I agree with Andy that a leaf either exists or not. I don't like half existing defaults. Please also consider that defaults effect much more then just the get-config results. (See attachment. I attached a file about an alternative (and I hope very understandable) solution. Please start to tell me why it is bad :-) Balazs PS.Sorry if my proposal is long. Andy Bierman wrote: > Hi, > > I don't think every vendor deals with agent-created defaults in the > same way, and there is zero chance every implementation will converge > on one interpretation. > > The important thing to consider is: > what is important for standards-based configuration? > > Here is the bottom line: > > - RFC 4741 requires that *all* config database objects be returned > in a without any filters > > - All data nodes that exist in the configuration have some value > (consider the value for 'empty' to be present/not-present) > > - An extension is needed (e.g., with-defaults=false) to change the > behavior of RFC 4741 wrt/ returning a subset of all nodes without > any filter defined > > Phil seems to be arguing that nodes that contain the agent-specified > default value are not really there. Yet, if the manager > sets a node explicitly to the default value, it is there. > IMO, this is rather confusing, and broken. > > The idea of tracking down stacks of offline vendor documentation > to determine the theoretical values of these 'default nodes', instead of > simply asking the agent for the real values, is a non-starter. > That may be good enough for CLI, but not standards based configuration. > > > Andy > > > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com --------------030103050403080701070401 Content-Type: text/plain; name="initialDefaultProposal.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="initialDefaultProposal.txt" I think we try to cram too many different properties into just 2 YANG statements (mandatory and default). I think we should explicitly state these. Things I see missing - default value(effect the full life cycle) or initial value(only effect creation) - mandatory at creation or mandatory in the datastore - is the leaf's value seen in get-config Also we risk muddying our concepts just to solve the default problem which I consider a VERY bad thing. Concept's we are endagering are: - Do we specify the data-store or the XML on the wire. If we specify the datastore, we better state whether a default leaf exists or not. - Do the default leafs exist or not. I hate half-existing leafs. I fear unclear concepts even more then the feature-creep. So I tried to think of an alternative notation: Yang statements: - mandatory: means it must be present in the datastore if the parent exists - initial-value: Will be used at creation of the parent if no value for the leaf is specified. Anything that was created with an initial value will really exist in the configuration. Later it does not matter if it was created explicitly or with an initial value. - default-value: means if the leaf does not exist, the server will use this value internally, but the leaf really does not exist. Can not be used with mandatory. "Must" statements consider the leaf not-existing but we introduce a special hasDefault() function. Or alternatively as a CLR "must" considers the leaf existing.) Netconf options: - with-defaults true/false. True means that get-config will return leafs that do not exist, but have a default. False means that only existing leafs are returned. (Leafs created with initial value included.) So answer to the below questions are: Q1) initials yes, defaults no Q2) Derived fron Q1 (depens on whether they exist.) Q3) Derived fron Q1. Leaves set with initial are just normal leaves. You cant delete a default, it does not exist. Q4) No difference for intials, there is a difference for defaults Q5) Yes for initials, see with-defaults for defaults Q6) Derived from Q1 (the existence of a leaf), yes for initials, no for defaults Q7) Derived from Q1, yes for initials, no for defaults but hasDefault() function added DT1) mandatory, noinitial, nodefault DT2) mandatory, noinitial, nodefault DT3) nomandatory, noinitial, default DT4) same as DT3 with defaultref or dynamicDefault DT5) nomandatory, initial, nodefault DT6) same as DT5 with initialref or dynamicInitial DT7) createOnly is a separate issue, but it could be createOnly, mandatory, noinitial, nodefault DT8) forget it =============================================================================================================================== Questions about default values: Let's not forget that the handling of defaults effect much more then the result of the get-config. IMHO the basic question is simply "does a leaf set only due to it's default exist?" (in the conceptual database). This effects the following: Q1) Does it exist? Q2) How does edit-config create/delete work on it? E.g. can you create a leaf that already exists(?) due to a default value? Q3) If you later explicitly delete a leaf with a default value what happens. Will it cease to exist? Will it automatically pop-up with the default value again? Q4) Is there any difference between a leaf set by the default and a leaf explicitly (edit-config replace) set to the same value? I really hope not. Q5) Will get-config return such a leaf? It may or may not depending on the implementation or the with-defaults option Q6) Will a non-presence container exist if it has leafs set by default? This will effect how edit-config none is handled. Q7) Does a "must" statement consider such leafs to exist. I assume yes. =============================================================================================================================== Different types of defaults: There seems to be quite a few ways to view the value of a single leaf. I have listed some of them below, and how YANG supports them. It would be really good if YANG could support all these cases with simple extensions. What How? (in YANG) ---- -------------- DT1) client must set mandatory = true DT2) client may set, if not mandatory = false set it means something. if not set, the server internally knows it's not there DT3) client may set, if not set default there is a static default. if not set, the default is used internally by the server. DT4) client may set, if not set no formal support there is another object whose extension will work, value is used (dynamic default or with no default and defaultref) mandatory = false if not set, the other value is used internally by the server. DT5) client may set, if not set no formal support, the server creates it with some extension will work, static value with no default and mandatory = false [is this really true??] DT6) client may set, if not set the server creates it with some dynamic value DT7) client MUST set at creation time, no formal support, but must not modify later. extension will work, with mandtory = true (assuming that a client is able to handle errors...) DT8) client MUST NOT set at creation, no formal support, but may modify later extension will work, [is there a use case for this?] with mandatory = false (assuming that a client is able to handle errors...) /martin --------------030103050403080701070401 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --------------030103050403080701070401-- From yang-bounces@ietf.org Fri Jan 25 11:00:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQz9-0004JK-UU; Fri, 25 Jan 2008 11:00:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIQz9-0004EX-3I for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 11:00:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQz8-0004AZ-MD for yang@ietf.org; Fri, 25 Jan 2008 11:00:54 -0500 Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JIQz8-0001I0-80 for yang@ietf.org; Fri, 25 Jan 2008 11:00:54 -0500 Received: (qmail 71691 invoked from network); 25 Jan 2008 16:00:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.97.95 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2008 16:00:53 -0000 X-YMail-OSG: ccmp6rkVM1lpaUst0S5xTkmtr_wdiAW094zo7InDY_UZN1n2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <479A073D.2070309@andybierman.com> Date: Fri, 25 Jan 2008 07:58:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [YANG] capability-stmt X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, IMO, the concept of capability-based features is one of the important components of NETCONF, but 2 new standard mechanisms are needed to make it better: A) definition of a NETCONF capability in YANG B) standard data model containing the agent capabilities (for ) A) capability-stmt (allowed at top-level only, like error-stmt) capability identifier-str { [description-stmt] [reference-stmt] [status-stmt] uri-stmt } capability uri { description "The NETCONF peer has the ability to accept the 'url' element in 'source' and 'target' parameters. The capability is further identified by URL arguments indicating the URL schemes supported."; reference "RFC 4741"; status current; uri "urn:ietf:params:netconf:capability:url:1.0"; } The capability statement serves as a documentation mechanism to describe any capabilities associated with the data model or NETCONF protocol. The agent is required to advertise the capability if it is supported (per RFC 4741) and also required to support the agent-capabilities data model for retrieval. B) agent-capabilities DM This data model (whatever it is called) is already under development in the NETCONF WG within the NETCONF Monitoring data model. This object must be supported by the agent (NETCONF 1.1?) Comments? _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 12:17:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISB2-0006Se-IS; Fri, 25 Jan 2008 12:17:16 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JISB1-0006RV-7a for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 12:17:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISB0-0006RM-Ru for yang@ietf.org; Fri, 25 Jan 2008 12:17:14 -0500 Received: from smtp118.sbc.mail.sp1.yahoo.com ([69.147.64.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JISB0-00043V-9t for yang@ietf.org; Fri, 25 Jan 2008 12:17:14 -0500 Received: (qmail 4847 invoked from network); 25 Jan 2008 17:17:08 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.97.95 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2008 17:17:08 -0000 X-YMail-OSG: mF0EX4wVM1nGqfZxJTUGSaikdt4UImtqrviRe3QX7aVkaCfo X-Yahoo-Newman-Property: ymail-3 Message-ID: <479A1918.2040203@andybierman.com> Date: Fri, 25 Jan 2008 09:15:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Balazs Lengyel Subject: Re: [YANG] mandatory & default References: <4799FD8F.1090402@andybierman.com> <479A002E.3070708@ericsson.com> In-Reply-To: <479A002E.3070708@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Balazs Lengyel wrote: > Hello, > I agree with Andy that a leaf either exists or not. I don't like half > existing defaults. > Please also consider that defaults effect much more then just the > get-config results. (See attachment. > I attached a file about an alternative (and I hope very understandable) > solution. Please start to tell me why it is bad :-) > Balazs > > PS.Sorry if my proposal is long. > Here is just a snippet to discuss: Yang statements: - mandatory: means it must be present in the datastore if the parent exists - initial-value: Will be used at creation of the parent if no value for the leaf is specified. Anything that was created with an initial value will really exist in the configuration. Later it does not matter if it was created explicitly or with an initial value. - default-value: means if the leaf does not exist, the server will use this value internally, but the leaf really does not exist. Can not be used with mandatory. "Must" statements consider the leaf not-existing but we introduce a special hasDefault() function. Or alternatively as a CLR "must" considers the leaf existing.) ------ IMO, this 'default-value' is unacceptable. A manager application may need to retrieve all the nodes that exist in the database. Requiring complex analysis of multiple external documents to determine the value of some of the nodes seems like a huge burden on application developers. How does the manager application know for sure whether an implementation actually supports a node or not? If some nodes are inaccessible under all conditions, but they really exist with some value, then how can a manager application know for sure if the agent really is using the specified default? If the value of the default changes over time, or varies between products or vendors, then how can a manager application know for sure what exact version of the default value is being used by the agent? I know of many operator horror stories in years past, caused by silent, undocumented default value changes between releases, and different code bases across product platforms. A full diff of the config files before and after the upgrade would have instantly revealed the source of the problem, but of course, since nobody needs to see these CLI defaults, that was not an option. Assumption is the mother of all foul-ups, to paraphrase the B movie... Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 14:30:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIUFx-0007tL-AY; Fri, 25 Jan 2008 14:30:29 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIUFv-0007mY-SW for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 14:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIUFv-0007jC-Gc for yang@ietf.org; Fri, 25 Jan 2008 14:30:27 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIUFt-0000iW-VP for yang@ietf.org; Fri, 25 Jan 2008 14:30:27 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 12422D800DA for ; Fri, 25 Jan 2008 20:30:21 +0100 (CET) Subject: Re: [YANG] mandatory & default From: Ladislav Lhotka To: yang In-Reply-To: <479A2827.1070703@andybierman.com> References: <4799FD8F.1090402@andybierman.com> <1201282558.24635.209.camel@missotis> <479A2827.1070703@andybierman.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 25 Jan 2008 20:30:22 +0100 Message-Id: <1201289422.24635.233.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 10:19 -0800: > I am not objecting to anything a manager application wants > to do with data it receives from NETCONF PDUs. I do not > think the IETF should standardize manager internals or agent internals, > or assume a hierarchical manager architecture, or any architecture > other than the peer-to-peer, session-based, connection-based, etc. > requirements stated in RFC 4741. I wouldn't object either if the server-side handling of defaults (with-defaults=3Dtrue) were an optional capability and the standard behaviour at the level of the NETCONF protocol (RFC 4741) stays as it is (send everything, no hidden parameters, no notion of default values). Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 17:40:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIXDX-0000jp-8n; Fri, 25 Jan 2008 17:40:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIXDW-0000jh-4x for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 17:40:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIXDV-0000jZ-PR for yang@ietf.org; Fri, 25 Jan 2008 17:40:09 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIXDT-0007Me-F4 for yang@ietf.org; Fri, 25 Jan 2008 17:40:09 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 4DDEA1B80CB; Fri, 25 Jan 2008 23:40:05 +0100 (CET) Date: Fri, 25 Jan 2008 23:38:24 +0100 (CET) Message-Id: <20080125.233824.88508964.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] mandatory & default From: Martin Bjorklund In-Reply-To: <4799FD8F.1090402@andybierman.com> References: <4799FD8F.1090402@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > I don't think every vendor deals with agent-created defaults in the > same way, and there is zero chance every implementation will converge > on one interpretation. Don't you think that we must have one, clear definition of how to handle this? How can anything else ever be interoperable? > The important thing to consider is: > what is important for standards-based configuration? > > Here is the bottom line: > > - RFC 4741 requires that *all* config database objects be returned > in a without any filters Ok. > - All data nodes that exist in the configuration have some value > (consider the value for 'empty' to be present/not-present) Ok. > - An extension is needed (e.g., with-defaults=false) to change the > behavior of RFC 4741 wrt/ returning a subset of all nodes without > any filter defined Or, if you, for a moment, try to view thing from the other side, you need an extension with-defaults=true to actually get the default values, since they are not stored in the configuration data store. > Phil seems to be arguing that nodes that contain the agent-specified > default value are not really there. Right, since they are not there in his implementation. Why would you store stuff that's not even needed to store? That's just a waste of resources. > Yet, if the manager > sets a node explicitly to the default value, it is there. > IMO, this is rather confusing, and broken. I think it makes perfect sense. If you set it, it's there. IMO it's more confusing if you set it and it's sometimes _not_ there (b/c it happened to be the default). NOTE: I'm NOT saying that this is the *only* way to do defaults, I'm just saying that this defintion is consistent. > The idea of tracking down stacks of offline vendor documentation > to determine the theoretical values of these 'default nodes', Did anyone suggest that? The default value is part of the data model, and you should be able to get the data model through schema discovery. There are lots of other information you need from the data model that's not in the instance document, like type, config true/false, relationships etc. > instead of > simply asking the agent for the real values, is a non-starter. I don't agree. I do agree that being able to get defaults from the box is useful, that's why the with-defaults extension is good. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 18:14:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIXks-0007u5-LF; Fri, 25 Jan 2008 18:14:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIXkr-0007oV-JL for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 18:14:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIXkr-0007oN-9Q for yang@ietf.org; Fri, 25 Jan 2008 18:14:37 -0500 Received: from smtp116.sbc.mail.sp1.yahoo.com ([69.147.64.89]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JIXkp-0008FW-Jv for yang@ietf.org; Fri, 25 Jan 2008 18:14:37 -0500 Received: (qmail 17142 invoked from network); 25 Jan 2008 23:14:35 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.129.159 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2008 23:14:34 -0000 X-YMail-OSG: B.cwguQVM1lYVNx8B.GxsrSwXh2ppSTZ7GK9zOH17_sTz3hg X-Yahoo-Newman-Property: ymail-3 Message-ID: <479A6CDF.5030304@andybierman.com> Date: Fri, 25 Jan 2008 15:12:31 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] mandatory & default References: <4799FD8F.1090402@andybierman.com> <20080125.233824.88508964.mbj@tail-f.com> In-Reply-To: <20080125.233824.88508964.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I don't think every vendor deals with agent-created defaults in the >> same way, and there is zero chance every implementation will converge >> on one interpretation. > > Don't you think that we must have one, clear definition of how to > handle this? How can anything else ever be interoperable? > >> The important thing to consider is: >> what is important for standards-based configuration? >> >> Here is the bottom line: >> >> - RFC 4741 requires that *all* config database objects be returned >> in a without any filters > > Ok. > >> - All data nodes that exist in the configuration have some value >> (consider the value for 'empty' to be present/not-present) > > Ok. > >> - An extension is needed (e.g., with-defaults=false) to change the >> behavior of RFC 4741 wrt/ returning a subset of all nodes without >> any filter defined > > Or, if you, for a moment, try to view thing from the other side, you > need an extension with-defaults=true to actually get the default > values, since they are not stored in the configuration data store. > I disagree. If I invoke an and set the leaf to this default value, it is still not there? If I invoke an and set the leaf to a non-default value, it is clearly there. Whether the manager or the agent sets the leaf to the default, it is there from a NETCONF protocol PoV. >> Phil seems to be arguing that nodes that contain the agent-specified >> default value are not really there. > > Right, since they are not there in his implementation. Why would you > store stuff that's not even needed to store? That's just a waste of > resources. Nobody said anything about storing the value. It is an implementation-specific matter as to how an agent generates a reply to a request. The defaults do not have to be stored -- they can be generated on the fly. > >> Yet, if the manager >> sets a node explicitly to the default value, it is there. >> IMO, this is rather confusing, and broken. > > I think it makes perfect sense. If you set it, it's there. IMO it's > more confusing if you set it and it's sometimes _not_ there (b/c it > happened to be the default). NOTE: I'm NOT saying that this is the > *only* way to do defaults, I'm just saying that this defintion is > consistent. > >> The idea of tracking down stacks of offline vendor documentation >> to determine the theoretical values of these 'default nodes', > > Did anyone suggest that? The default value is part of the data model, > and you should be able to get the data model through schema discovery. > There are lots of other information you need from the data model > that's not in the instance document, like type, config true/false, > relationships etc. > >> instead of >> simply asking the agent for the real values, is a non-starter. > > I don't agree. I do agree that being able to get defaults from the > box is useful, that's why the with-defaults extension is good. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 18:28:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIXxr-0005vK-1Y; Fri, 25 Jan 2008 18:28:03 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIXxp-0005ou-FJ for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 18:28:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIXxp-0005m1-4Y for yang@ietf.org; Fri, 25 Jan 2008 18:28:01 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIXxo-0008WB-M2 for yang@ietf.org; Fri, 25 Jan 2008 18:28:01 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id E64A81B80CB; Sat, 26 Jan 2008 00:27:59 +0100 (CET) Date: Sat, 26 Jan 2008 00:26:18 +0100 (CET) Message-Id: <20080126.002618.144263975.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] mandatory & default From: Martin Bjorklund In-Reply-To: <479A6CDF.5030304@andybierman.com> References: <4799FD8F.1090402@andybierman.com> <20080125.233824.88508964.mbj@tail-f.com> <479A6CDF.5030304@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > > Or, if you, for a moment, try to view thing from the other side, you > > need an extension with-defaults=true to actually get the default > > values, since they are not stored in the configuration data store. > > > > I disagree. > > If I invoke an and set the leaf to this > default value, it is still not there? Yes it's there. > If I invoke an and set the leaf to a > non-default value, it is clearly there. Yes it's there. > Whether the manager or the agent sets the leaf to the default, > it is there from a NETCONF protocol PoV. The crucial point is that - in this way of seeing things - the agent does not set the leaf to the default. Again, I do understand that there are other ways to define how defaults work. I'm just trying to explain the rationale for this one. > >> Phil seems to be arguing that nodes that contain the agent-specified > >> default value are not really there. > > > > Right, since they are not there in his implementation. Why would you > > store stuff that's not even needed to store? That's just a waste of > > resources. > > > Nobody said anything about storing the value. I just tried to explain why "nodes that contain the agent-specified default value are not really there". > It is an implementation-specific matter as to how > an agent generates a reply to a request. > The defaults do not have to be stored -- they can > be generated on the fly. Agreed. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Jan 25 19:09:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIYbU-0000KU-NM; Fri, 25 Jan 2008 19:09:00 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIYbT-0000KP-EC for yang-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 19:08:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIYbS-0000KH-N2 for yang@ietf.org; Fri, 25 Jan 2008 19:08:59 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIYbS-0004hY-38 for yang@ietf.org; Fri, 25 Jan 2008 19:08:58 -0500 Received: (qmail 81998 invoked from network); 26 Jan 2008 00:08:57 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.129.159 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2008 00:08:56 -0000 X-YMail-OSG: q4LzjTsVM1lL0E_cyGkxcP02loxMAwA4yIMSb52YeZn8B5Ip X-Yahoo-Newman-Property: ymail-3 Message-ID: <479A799D.1060003@andybierman.com> Date: Fri, 25 Jan 2008 16:06:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] mandatory & default References: <4799FD8F.1090402@andybierman.com> <20080125.233824.88508964.mbj@tail-f.com> <479A6CDF.5030304@andybierman.com> <20080126.002618.144263975.mbj@tail-f.com> In-Reply-To: <20080126.002618.144263975.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>> Or, if you, for a moment, try to view thing from the other side, you >>> need an extension with-defaults=true to actually get the default >>> values, since they are not stored in the configuration data store. >>> >> I disagree. >> >> If I invoke an and set the leaf to this >> default value, it is still not there? > > Yes it's there. > >> If I invoke an and set the leaf to a >> non-default value, it is clearly there. > > Yes it's there. > Therefore this approach is broken. container interfaces { list interface { key name; leaf name { type InterfaceName; } leaf mtu { type uint32; default 1500; } } } I start out with a get-config, and mtu is not there: eth0 1600 eth1 Does /interfaces/interface[name=eth1]/mtu exist or not? If not, then I can do an edit-config to create it: eth1 1500 Does this succeed? NETCONF says it should, because the leaf did not get returned in the previous . Now I do a get-config again and get back: eth0 1600 eth1 1500 The leaf never really changed value, but you would never know that from the NETCONF PDU responses. After a system reboot, does the agent 'remember' that mtu was set to 1500 by the manager, so the initial config from NV-storage after the next reboot has an mtu leaf for eth1? Andy >> Whether the manager or the agent sets the leaf to the default, >> it is there from a NETCONF protocol PoV. > > The crucial point is that - in this way of seeing things - the agent > does not set the leaf to the default. Again, I do understand that > there are other ways to define how defaults work. I'm just trying to > explain the rationale for this one. > > >>>> Phil seems to be arguing that nodes that contain the agent-specified >>>> default value are not really there. >>> Right, since they are not there in his implementation. Why would you >>> store stuff that's not even needed to store? That's just a waste of >>> resources. >> >> Nobody said anything about storing the value. > > I just tried to explain why "nodes that contain the agent-specified > default value are not really there". > >> It is an implementation-specific matter as to how >> an agent generates a reply to a request. >> The defaults do not have to be stored -- they can >> be generated on the fly. > > Agreed. > > > /martin > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Jan 26 05:22:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIiBN-0002wN-7u; Sat, 26 Jan 2008 05:22:41 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JIiBM-0002kv-Dn for yang-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 05:22:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIiBE-00027P-Fs for yang@ietf.org; Sat, 26 Jan 2008 05:22:32 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIiBD-00060A-VL for yang@ietf.org; Sat, 26 Jan 2008 05:22:32 -0500 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 3CDD01B80CB; Sat, 26 Jan 2008 11:22:29 +0100 (CET) Date: Sat, 26 Jan 2008 11:20:45 +0100 (CET) Message-Id: <20080126.112045.214588980.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] mandatory & default From: Martin Bjorklund In-Reply-To: <479A799D.1060003@andybierman.com> References: <479A6CDF.5030304@andybierman.com> <20080126.002618.144263975.mbj@tail-f.com> <479A799D.1060003@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, Andy Bierman wrote: > > container interfaces { > list interface { > key name; > > leaf name { type InterfaceName; } > > leaf mtu { > type uint32; > default 1500; > } > } > } > > I start out with a get-config, and mtu is not there: > > > > eth0 > 1600 > > > eth1 > > > > Does /interfaces/interface[name=eth1]/mtu exist or not? Not in the config datastore, no. > If not, then I can do an edit-config to create it: > > > > > eth1 > 1500 > > > > > Does this succeed? Yes. > NETCONF says it should, because the > leaf did not get returned in the previous . > > Now I do a get-config again and get back: > > > > eth0 > 1600 > > > eth1 > 1500 > > > > The leaf never really changed value, but you would never know > that from the NETCONF PDU responses. > > After a system reboot, does the agent 'remember' that mtu > was set to 1500 by the manager, so the initial > config from NV-storage after the next reboot has an mtu leaf > for eth1? The value is stored in NV-storage, just like all other values set by the manager. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Jan 26 10:00:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JImVw-0001MT-Dc; Sat, 26 Jan 2008 10:00:12 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JImVu-0001ML-WE for yang-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 10:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JImVu-0001MD-L5 for yang@ietf.org; Sat, 26 Jan 2008 10:00:10 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JImVu-00053m-4K for yang@ietf.org; Sat, 26 Jan 2008 10:00:10 -0500 Received: (qmail 37708 invoked from network); 26 Jan 2008 15:00:09 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.131.12 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2008 15:00:09 -0000 X-YMail-OSG: Vd8fT5sVM1kHUQJPybHJCBnHAmFYA5egv9EYsYNkZ8eMWIpN X-Yahoo-Newman-Property: ymail-3 Message-ID: <479B4B65.90104@andybierman.com> Date: Sat, 26 Jan 2008 07:01:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] mandatory & default References: <479A6CDF.5030304@andybierman.com> <20080126.002618.144263975.mbj@tail-f.com> <479A799D.1060003@andybierman.com> <20080126.112045.214588980.mbj@tail-f.com> In-Reply-To: <20080126.112045.214588980.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > > Andy Bierman wrote: >> container interfaces { >> list interface { >> key name; >> >> leaf name { type InterfaceName; } >> >> leaf mtu { >> type uint32; >> default 1500; >> } >> } >> } >> >> I start out with a get-config, and mtu is not there: >> >> >> >> eth0 >> 1600 >> >> >> eth1 >> >> >> >> Does /interfaces/interface[name=eth1]/mtu exist or not? > > Not in the config datastore, no. > But here is where this CLI-based design is broken. If a manager sends jumbo packets on eth1, they will not be accepted. There is a maximum transmission unit size in effect on eth1, but the manager is told there is none in the . The response "oh no, there is an MTU value in effect, just not in the config" is really broken. It's not state data, and it's not config data, but if the manager does not know the value, it cannot reliably configure other devices that send packets to 'eth1' on this agent. IMO, the mtu is clearly config data, and clearly in effect at all times eth1 is accepting packets. The config returned in NETCONF PDUs should match. Filtering out these defaults is a separate issue from whether they exist or not. Andy >> If not, then I can do an edit-config to create it: >> >> >> >> >> eth1 >> 1500 >> >> >> >> >> Does this succeed? > > Yes. > >> NETCONF says it should, because the >> leaf did not get returned in the previous . >> >> Now I do a get-config again and get back: >> >> >> >> eth0 >> 1600 >> >> >> eth1 >> 1500 >> >> >> >> The leaf never really changed value, but you would never know >> that from the NETCONF PDU responses. >> >> After a system reboot, does the agent 'remember' that mtu >> was set to 1500 by the manager, so the initial >> config from NV-storage after the next reboot has an mtu leaf >> for eth1? > > The value is stored in NV-storage, just like all other values set by > the manager. > > > /martin > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 27 22:32:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJKjh-0006an-Be; Sun, 27 Jan 2008 22:32:41 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJKjg-0006Ys-0k for yang-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 22:32:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJKjf-0006Uh-Jh for yang@ietf.org; Sun, 27 Jan 2008 22:32:39 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJKje-0006Oj-Iu for yang@ietf.org; Sun, 27 Jan 2008 22:32:39 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sun, 27 Jan 2008 19:31:50 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Jan 2008 19:23:01 -0800 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 m0S3Mxq95439; Sun, 27 Jan 2008 19:22:59 -0800 (PST) (envelope-from phil@idle.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 m0S3Mqhi051945; Mon, 28 Jan 2008 03:22:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801280322.m0S3Mqhi051945@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] mandatory & default In-reply-to: <479A6CDF.5030304@andybierman.com> Date: Sun, 27 Jan 2008 22:22:52 -0500 From: Phil Shafer X-OriginalArrivalTime: 28 Jan 2008 03:23:01.0245 (UTC) FILETIME=[16347AD0:01C8615D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org [replying to multiple Andy-grams] Andy Bierman writes: >Whether the manager or the agent sets the leaf to the default, >it is there from a NETCONF protocol PoV. NETCONF leaves all this to the data model, so there's no single NETCONF POV on this issue. This is designed to support existing views of configuration issues, including defaults. >It is an implementation-specific matter as to how >an agent generates a reply to a request. >The defaults do not have to be stored -- they can >be generated on the fly. If I'm using NETCONF to archive configurations, I don't want them littered with defaults. Similar for if I'm viewing them in the equivalent of a mib browser. I want to see the statements that someone has explicitly configured, not volumes of uninteresting defaults. Part of putting these values into YANG modules is to allow interested parties (applications, developers) to know these values as they are helping the user create new instances. To my mind, the "with-defaults" is useless for this scenario, since I want to know the defaults _before_ I make the config, not after. The KISS view of config is used for CLIs because is keeps the noise to a minimum. This need doesn't disappear when the config moves into the application/automation world. >Message-ID: <479A799D.1060003@andybierman.com> >Date: Fri, 25 Jan 2008 16:06:53 -0800 >From: Andy Bierman > >After a system reboot, does the agent 'remember' that mtu >was set to 1500 by the manager, so the initial >config from NV-storage after the next reboot has an mtu leaf >for eth1? No, the system records as the configuration only those fields which are interesting. For example in JUNOS, we define "interesting" as anything the user told us to do. In IOS, they define "interesting" as any non-default values. IMHO, you're trying to define interesting to include some very boring defaults. >Message-ID: <479B4B65.90104@andybierman.com> >Date: Sat, 26 Jan 2008 07:01:57 -0800 >From: Andy Bierman > >But here is where this CLI-based design is broken. >If a manager sends jumbo packets on eth1, they will not be accepted. >There is a maximum transmission unit size in effect on eth1, >but the manager is told there is none in the . The application can find all the information about "mtu", including its default value, in the metadata. The application can show this default value to the user as they create a new interface, and the application can know that if there's an in the interface, its there because someone wanted it, and that's it's not noise. >The response "oh no, there is an MTU value in effect, just not in the config" >is really broken. It's not state data, and it's not config data, but if >the manager does not know the value, it cannot reliably configure other >devices that send packets to 'eth1' on this agent. Nope, it's not config data. It's a default value. The device doesn't need it to perform the job of configuration, which is defined in the NETCONF spec as: Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. Default values aren't required in config data. Or wanted. If I've got 64,000 interfaces, I don't need to see this default value for each interface, let alone the hundred other knobs for each interface that have perfect reasonable and completely uninteresting default values. >IMO, the mtu is clearly config data, and clearly in effect at >all times eth1 is accepting packets. The config returned >in NETCONF PDUs should match. Filtering out these defaults >is a separate issue from whether they exist or not. The issue isn't filtering them out. The issue is are defaults part of the configuration? I understand the need for a mechanism for discovering them, both inline and in metadata, but I don't see any win in considering such noise as part of the configuration of a device. We are working hard to make devices _more_ managable. Adding a couple of orders of magnitude of noise into the configuration means: - performance issues (as my 1m config turns into 100m) - upgrade/downgrade issues (as defaults for unused features break on software that doesn't support them, even if they are completely unimportant) - readability issues (as adding noise makes the config less readable and the purpose of using xml was human readability for debugging and monitoring) Inline defaults is broken, to lift your words, since it takes a complex problem and makes it more complex. We should be simplifying, reducing, and giving better visibility into the important parts of configuration, not polluting them with noise. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 27 23:10:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJLKN-0001OC-GI; Sun, 27 Jan 2008 23:10:35 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJLKL-0001O5-WE for yang-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 23:10:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJLKL-0001Ns-K9 for yang@ietf.org; Sun, 27 Jan 2008 23:10:33 -0500 Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJLKK-00078l-Qm for yang@ietf.org; Sun, 27 Jan 2008 23:10:33 -0500 Received: (qmail 94729 invoked from network); 28 Jan 2008 04:10:32 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.121.104.118 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 28 Jan 2008 04:10:31 -0000 X-YMail-OSG: 70n5FtwVM1kssjIJV04_CcyNeP_mihMaMRuOQmMUJ2P.FyXE X-Yahoo-Newman-Property: ymail-3 Message-ID: <479D55B9.8010300@andybierman.com> Date: Sun, 27 Jan 2008 20:10:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] mandatory & default References: <200801280322.m0S3Mqhi051945@idle.juniper.net> In-Reply-To: <200801280322.m0S3Mqhi051945@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > [replying to multiple Andy-grams] > We strongly disagree on the interpretation of RFC 4741 and whether a node with a default value really exists or not. It is very fragile SW design to assume the agent is using the exact default that was tracked down in the documentation. It is up to the operator whether knowing that a node is actually supported, and knowing the exact value set by the agent, is a waste of space or important debugging information. Andy > Andy Bierman writes: >> Whether the manager or the agent sets the leaf to the default, >> it is there from a NETCONF protocol PoV. > > NETCONF leaves all this to the data model, so there's no single > NETCONF POV on this issue. This is designed to support existing > views of configuration issues, including defaults. > >> It is an implementation-specific matter as to how >> an agent generates a reply to a request. >> The defaults do not have to be stored -- they can >> be generated on the fly. > > If I'm using NETCONF to archive configurations, I don't > want them littered with defaults. Similar for if I'm > viewing them in the equivalent of a mib browser. I want > to see the statements that someone has explicitly configured, > not volumes of uninteresting defaults. > > Part of putting these values into YANG modules is to allow > interested parties (applications, developers) to know these values > as they are helping the user create new instances. To my mind, the > "with-defaults" is useless for this scenario, since I want to know > the defaults _before_ I make the config, not after. > > The KISS view of config is used for CLIs because is keeps the > noise to a minimum. This need doesn't disappear when the > config moves into the application/automation world. > > >> Message-ID: <479A799D.1060003@andybierman.com> >> Date: Fri, 25 Jan 2008 16:06:53 -0800 >> From: Andy Bierman >> >> After a system reboot, does the agent 'remember' that mtu >> was set to 1500 by the manager, so the initial >> config from NV-storage after the next reboot has an mtu leaf >> for eth1? > > No, the system records as the configuration only those fields which > are interesting. For example in JUNOS, we define "interesting" as > anything the user told us to do. In IOS, they define "interesting" > as any non-default values. IMHO, you're trying to define interesting > to include some very boring defaults. > > >> Message-ID: <479B4B65.90104@andybierman.com> >> Date: Sat, 26 Jan 2008 07:01:57 -0800 >> From: Andy Bierman >> >> But here is where this CLI-based design is broken. >> If a manager sends jumbo packets on eth1, they will not be accepted. >> There is a maximum transmission unit size in effect on eth1, >> but the manager is told there is none in the . > > The application can find all the information about "mtu", including > its default value, in the metadata. The application can show this > default value to the user as they create a new interface, and the > application can know that if there's an in the interface, its > there because someone wanted it, and that's it's not noise. > >> The response "oh no, there is an MTU value in effect, just not in the config" >> is really broken. It's not state data, and it's not config data, but if >> the manager does not know the value, it cannot reliably configure other >> devices that send packets to 'eth1' on this agent. > > Nope, it's not config data. It's a default value. The device > doesn't need it to perform the job of configuration, which is > defined in the NETCONF spec as: > > Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state. > > Default values aren't required in config data. Or wanted. > > If I've got 64,000 interfaces, I don't need to see this default > value for each interface, let alone the hundred other knobs for > each interface that have perfect reasonable and completely > uninteresting default values. > >> IMO, the mtu is clearly config data, and clearly in effect at >> all times eth1 is accepting packets. The config returned >> in NETCONF PDUs should match. Filtering out these defaults >> is a separate issue from whether they exist or not. > > The issue isn't filtering them out. The issue is are defaults part > of the configuration? I understand the need for a mechanism for > discovering them, both inline and in metadata, but I don't see any > win in considering such noise as part of the configuration of a > device. > > We are working hard to make devices _more_ managable. Adding a > couple of orders of magnitude of noise into the configuration > means: > - performance issues (as my 1m config turns into 100m) > - upgrade/downgrade issues (as defaults for unused features break > on software that doesn't support them, even if they are completely > unimportant) > - readability issues (as adding noise makes the config less readable > and the purpose of using xml was human readability for debugging > and monitoring) > > Inline defaults is broken, to lift your words, since it takes a > complex problem and makes it more complex. We should be simplifying, > reducing, and giving better visibility into the important parts of > configuration, not polluting them with noise. > > Thanks, > Phil > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Jan 27 23:55:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJM1N-0005qa-18; Sun, 27 Jan 2008 23:55:01 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJM1M-0005qM-5G for yang-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 23:55:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJM1L-0005pR-Qy for yang@ietf.org; Sun, 27 Jan 2008 23:54:59 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJM1L-0007uI-FP for yang@ietf.org; Sun, 27 Jan 2008 23:54:59 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AIrYq/Xp0VAKo8rytxht78oY+1b0of5B3z2pj831iU1AsgPoVLFX6HeKLs4fuxbf; 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 [68.166.38.34] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JJM1I-0007vQ-Ik for yang@ietf.org; Sun, 27 Jan 2008 23:54:56 -0500 Message-ID: <000a01c86169$eb717200$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200801280322.m0S3Mqhi051945@idle.juniper.net> Subject: Re: [YANG] mandatory & default Date: Sun, 27 Jan 2008 20:54:51 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117625e425a6198b370564ba4729c3ba521350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: > Sent: Sunday, January 27, 2008 7:22 PM > Subject: Re: [YANG] mandatory & default ... > If I'm using NETCONF to archive configurations, I don't > want them littered with defaults. ... If I'm archiving a configuration, I want to know *exactly* what it is. One of the reasons for archiving configurations is so that if a box fails, a replacement can be quickly made to function in its place. If there is even a remote chance that a default value might change between releases or on different versions of a hardware platform, that value needs to be included in an archive of the configuration. Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 01:56:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJNua-0003ME-U5; Mon, 28 Jan 2008 01:56:08 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJNuZ-0003Ko-5a for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 01:56:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJNuY-0003Kd-Pj for yang@ietf.org; Mon, 28 Jan 2008 01:56:06 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJNuY-0001ta-8C for yang@ietf.org; Mon, 28 Jan 2008 01:56:06 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sun, 27 Jan 2008 22:51:07 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jan 2008 22:50:21 -0800 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 m0S6oKq38587; Sun, 27 Jan 2008 22:50:20 -0800 (PST) (envelope-from phil@idle.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 m0S6o9wi052898; Mon, 28 Jan 2008 06:50:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801280650.m0S6o9wi052898@idle.juniper.net> To: "Randy Presuhn" Subject: Re: [YANG] mandatory & default In-reply-to: <000a01c86169$eb717200$6801a8c0@oemcomputer> Date: Mon, 28 Jan 2008 01:50:09 -0500 From: Phil Shafer X-OriginalArrivalTime: 28 Jan 2008 06:50:21.0324 (UTC) FILETIME=[0D11E4C0:01C8617A] X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "Randy Presuhn" writes: >One of the reasons for archiving configurations >is so that if a box fails, a replacement can be quickly made >to function in its place. Loading the saved file with defaults won't make this any saner, safer, or stronger. It increases the fragility, but incorporating into the saved file tons of stuff about which you don't care. It something fails on these values that you don't care about, you are broken. >If there is even a remote chance >that a default value might change between releases or on >different versions of a hardware platform, that value needs >to be included in an archive of the configuration. The chance of a change in defaults (which annoy customers to no end) is minor compared to the change of adding features (which customers insist on) and the need to support downgrading (which customers insist on). Consider this example from JUNOS-land. We have a set of foo-options containers that are used to hold media-specific options under the [interfaces] statement. These options are numerous, verbose, and rarely used. If I add a new statement in release 9.0 and start emitting a boring default value for it, I can no longer load that config in any release predating 9.0. In avoiding a rare bug (changing defaults), you'll break real operational usage. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 02:09:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJO7F-0005xg-1S; Mon, 28 Jan 2008 02:09:13 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJO7D-0005pF-VN for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 02:09:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJO7D-0005o9-Ki for yang@ietf.org; Mon, 28 Jan 2008 02:09:11 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJO7D-0002MK-3l for yang@ietf.org; Mon, 28 Jan 2008 02:09:11 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sun, 27 Jan 2008 23:08:40 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Jan 2008 23:08:05 -0800 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 m0S783q42841; Sun, 27 Jan 2008 23:08:03 -0800 (PST) (envelope-from phil@idle.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 m0S77qhW053014; Mon, 28 Jan 2008 07:07:56 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200801280707.m0S77qhW053014@idle.juniper.net> To: Andy Bierman Subject: Re: [YANG] mandatory & default In-reply-to: <479D55B9.8010300@andybierman.com> Date: Mon, 28 Jan 2008 02:07:52 -0500 From: Phil Shafer X-OriginalArrivalTime: 28 Jan 2008 07:08:05.0034 (UTC) FILETIME=[871728A0:01C8617C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman writes: >We strongly disagree on the interpretation of RFC 4741 >and whether a node with a default value really exists or not. Are you saying that 4741 forces defaults to be emitted in ? >It is very fragile SW design to assume the agent is using the exact default >that was tracked down in the documentation. Here we strongly disagree. Adding noise to configs makes them more fragile, not less so. In using the term "tracked down", are you missing that putting these values in the YANG module (or any metadata/schema) makes them more than just documentation? An application should be able to move from a node in the data tree to the YANG definition of this node with ease. Finding the default value (and the data type, range, and all the other constraints on the data values) should be no problem for the client application. >It is up to the operator whether knowing that a node >is actually supported, and knowing the exact value set by the agent, >is a waste of space or important debugging information. You should publish the with-defaults capability as a draft. I do see this as having value, but disagree with making it the default behavior. If there's a way to turn it on, operators that want it on can turn it on in their client software. Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 03:02:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJOwk-0005r3-WB; Mon, 28 Jan 2008 03:02:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJOwf-0005od-O5 for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 03:02:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJOwG-0005Yo-PR; Mon, 28 Jan 2008 03:01:56 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJOwG-0000s5-8p; Mon, 28 Jan 2008 03:01:56 -0500 X-IronPort-AV: E=Sophos;i="4.25,258,1199682000"; d="url'?txt'208?scan'208,208";a="89114573" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Jan 2008 03:01:52 -0500 X-IronPort-AV: E=Sophos;i="4.25,258,1199682000"; d="url'?txt'208?scan'208,208";a="154817338" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2008 02:52:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C86182.C341B565" Date: Mon, 28 Jan 2008 08:52:41 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-presuhn-rcdml-00.txt Thread-Index: AchheP5QjeH2JlF8T+OAGKHG4CnAIQACVruw From: "Romascanu, Dan (Dan)" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Subject: [YANG] FW: I-D Action:draft-presuhn-rcdml-00.txt X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C86182.C341B565 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I apologize for cross-posting, but I think it is justified in this case. I suggest yang@ietf.org as prefered space for comments.=20 Dan =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, January 28, 2008 8:40 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-presuhn-rcdml-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for a Configuration Data Modeling Language Author(s) : R. Presuhn Filename : draft-presuhn-rcdml-00.txt Pages : 22 Date : 2008-01-28 This memo contains a compilation of requirements for a Configuration Data Modeling Language. Although focusing on the needs of the NETCONF Protocol, these requirements potentially have broader applicability. Comments should be sent to ngo@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-presuhn-rcdml-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-presuhn-rcdml-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-presuhn-rcdml-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. This email was protected during delivery to Avaya with TLS encryption ------_=_NextPart_001_01C86182.C341B565 Content-Type: application/octet-stream; name="ATT856200.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT856200.TXT Content-Disposition: attachment; filename="ATT856200.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwOC0wMS0yODAxMzA1OC5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wcmVzdWhuLXJjZG1sLTAw LnR4dA0K ------_=_NextPart_001_01C86182.C341B565 Content-Type: application/octet-stream; name="draft-presuhn-rcdml-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-presuhn-rcdml-00.URL Content-Disposition: attachment; filename="draft-presuhn-rcdml-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1wcmVzdWhuLXJjZG1sLTAwLnR4dA0K ------_=_NextPart_001_01C86182.C341B565 Content-Type: text/plain; name="ATT856201.txt" Content-Transfer-Encoding: base64 Content-Description: ATT856201.txt Content-Disposition: attachment; filename="ATT856201.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQoNClRoaXMgZW1haWwgd2FzIHBy b3RlY3RlZCBkdXJpbmcgZGVsaXZlcnkgdG8gQXZheWEgd2l0aCBUTFMgZW5jcnlwdGlvbg0K ------_=_NextPart_001_01C86182.C341B565 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang ------_=_NextPart_001_01C86182.C341B565-- From yang-bounces@ietf.org Mon Jan 28 03:18:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPCF-00045u-LM; Mon, 28 Jan 2008 03:18:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJPCE-00043i-0F for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 03:18:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPCD-00040y-Da for yang@ietf.org; Mon, 28 Jan 2008 03:18:25 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJPCB-00019b-5k for yang@ietf.org; Mon, 28 Jan 2008 03:18:25 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 17011D800BD for ; Mon, 28 Jan 2008 09:18:18 +0100 (CET) Subject: Re: [YANG] mandatory & default From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080125.233824.88508964.mbj@tail-f.com> References: <4799FD8F.1090402@andybierman.com> <20080125.233824.88508964.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 28 Jan 2008 09:18:17 +0100 Message-Id: <1201508297.30693.63.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund p=C3=AD=C5=A1e v P=C3=A1 25. 01. 2008 v 23:38 +0100: > > - An extension is needed (e.g., with-defaults=3Dfalse) to change th= e > > behavior of RFC 4741 wrt/ returning a subset of all nodes without > > any filter defined >=20 > Or, if you, for a moment, try to view thing from the other side, you > need an extension with-defaults=3Dtrue to actually get the default > values, since they are not stored in the configuration data store. The important point is whether they are defined in the data model. If they are mandatory, then the device must tell their value - unless instructed otherwise (either by a filter or by a default-handling extension). And I don't want to have a special data model for each device that implements a particular subset of permitted mtu values. >=20 > > Phil seems to be arguing that nodes that contain the agent-specified > > default value are not really there. >=20 > Right, since they are not there in his implementation. Why would you > store stuff that's not even needed to store? That's just a waste of > resources. Well, if the devices can be potentially asked (under any circumstances) what the value is, it must be able to return it - it doesn't matter whether it is physically stored, computed on the fly or whatever. I think the confusion again stems from different interpretations of validity. IMO the most straightforward one is that I take a concrete full configuration (e.g., as an XML document) and compare it to the data model it is supposed to comply to. In particular, if an element is mandatory in the DM, I must see it in the configuration. Note that no context or other info is needed for this validation, like whether the configuration comes from the device or from the manager etc.=20 Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 03:24:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPIK-0004ER-VB; Mon, 28 Jan 2008 03:24:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJPIJ-0004EK-Ic for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 03:24:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPII-0004EB-UI for yang@ietf.org; Mon, 28 Jan 2008 03:24:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJPIH-0001HL-HY for yang@ietf.org; Mon, 28 Jan 2008 03:24:42 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E56E42148D; Mon, 28 Jan 2008 09:24:40 +0100 (CET) X-AuditID: c1b4fb3e-abdeabb0000007e1-53-479d9148b074 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D457221461; Mon, 28 Jan 2008 09:24:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 09:24:40 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 09:24:40 +0100 Message-ID: <479D9148.1090905@ericsson.com> Date: Mon, 28 Jan 2008 09:24:40 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman Subject: Re: [YANG] mandatory & default References: <4799FD8F.1090402@andybierman.com> <479A002E.3070708@ericsson.com> <479A1918.2040203@andybierman.com> In-Reply-To: <479A1918.2040203@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2008 08:24:40.0403 (UTC) FILETIME=[3A24D230:01C86187] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: yang X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org See below! Andy Bierman wrote: > - default-value: means if the leaf does not exist, the server will use > this value internally, but the leaf really does not exist. Can not be > used with mandatory. "Must" statements consider the leaf not-existing but > we introduce a special hasDefault() function. Or alternatively as a > CLR "must" considers the leaf existing.) > > ------ > [BALAZS]: Using the with-defaults statement you will get back the non-existing default even though the leaf "set" only by the default value does not exist. Balazs > IMO, this 'default-value' is unacceptable. > A manager application may need to retrieve all the nodes that > exist in the database. _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 03:46:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPdf-0001CK-4p; Mon, 28 Jan 2008 03:46:47 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJPdd-00019M-Lh for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 03:46:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPdd-00018l-9F for yang@ietf.org; Mon, 28 Jan 2008 03:46:45 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJPdc-0004u7-Go for yang@ietf.org; Mon, 28 Jan 2008 03:46:44 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6DE48A27B; Mon, 28 Jan 2008 09:46:43 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12590-01; Mon, 28 Jan 2008 09:46:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F3EE8A25D; Mon, 28 Jan 2008 09:46:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 719B548CB42; Mon, 28 Jan 2008 09:46:36 +0100 (CET) Date: Mon, 28 Jan 2008 09:46:36 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [YANG] mandatory & default Message-ID: <20080128084636.GA19843@elstar.local> Mail-Followup-To: Randy Presuhn , yang@ietf.org References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <000a01c86169$eb717200$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01c86169$eb717200$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Sun, Jan 27, 2008 at 08:54:51PM -0800, Randy Presuhn wrote: > If I'm archiving a configuration, I want to know *exactly* > what it is. One of the reasons for archiving configurations > is so that if a box fails, a replacement can be quickly made > to function in its place. If there is even a remote chance > that a default value might change between releases or on > different versions of a hardware platform, that value needs > to be included in an archive of the configuration. If your replacement is using the exact same hardware configuration and the exact same firmware version, you do not need to worry about the defaults. If your replacement is not using the exact same hardware configuration and the exact same firmware version, there is a chance that things won't work as expected, with and without saved defaults. If things fail, you need to have a human to figure out what is the configuration and what is saved default noise. So the bottom line of my thinking is that you like to have both - the explicitly set config and the full configuration state including the defaults. Only if you have both, you can reasonably debug configuration playback errors on replacement hardware. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 04:02:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPsf-0007ab-3W; Mon, 28 Jan 2008 04:02:17 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJPsd-0007aQ-PX for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 04:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPsd-0007aH-FJ for yang@ietf.org; Mon, 28 Jan 2008 04:02:15 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJPsd-00028s-0V for yang@ietf.org; Mon, 28 Jan 2008 04:02:15 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D488CD800C1 for ; Mon, 28 Jan 2008 10:02:13 +0100 (CET) Subject: Re: [YANG] mandatory & default From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080128084636.GA19843@elstar.local> References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <000a01c86169$eb717200$6801a8c0@oemcomputer> <20080128084636.GA19843@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 28 Jan 2008 10:02:13 +0100 Message-Id: <1201510933.30693.81.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v Po 28. 01. 2008 v 09:46 +0100: > On Sun, Jan 27, 2008 at 08:54:51PM -0800, Randy Presuhn wrote: > =20 > > If I'm archiving a configuration, I want to know *exactly* > > what it is. One of the reasons for archiving configurations > > is so that if a box fails, a replacement can be quickly made > > to function in its place. If there is even a remote chance > > that a default value might change between releases or on > > different versions of a hardware platform, that value needs > > to be included in an archive of the configuration. >=20 > If your replacement is using the exact same hardware configuration and > the exact same firmware version, you do not need to worry about the > defaults. >=20 > If your replacement is not using the exact same hardware configuration > and the exact same firmware version, there is a chance that things > won't work as expected, with and without saved defaults. >=20 > If things fail, you need to have a human to figure out what is the Here is the problem with changed defaults: things will not fail, they will just work differently from what you expect. Lada > configuration and what is saved default noise. So the bottom line of > my thinking is that you like to have both - the explicitly set config > and the full configuration state including the defaults. Only if you > have both, you can reasonably debug configuration playback errors on > replacement hardware. >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 04:47:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJQaE-0006xd-Ls; Mon, 28 Jan 2008 04:47:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJQaC-0006oQ-Ib for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 04:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJQaB-0006kQ-Ri for yang@ietf.org; Mon, 28 Jan 2008 04:47:15 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJQa9-0003AP-SM for yang@ietf.org; Mon, 28 Jan 2008 04:47:15 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDED88A323; Mon, 28 Jan 2008 10:47:12 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18336-03; Mon, 28 Jan 2008 10:47:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B2898A331; Mon, 28 Jan 2008 10:47:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6D2B248CCB4; Mon, 28 Jan 2008 10:47:03 +0100 (CET) Date: Mon, 28 Jan 2008 10:47:03 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] mandatory & default Message-ID: <20080128094703.GA20045@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <000a01c86169$eb717200$6801a8c0@oemcomputer> <20080128084636.GA19843@elstar.local> <1201510933.30693.81.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201510933.30693.81.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Mon, Jan 28, 2008 at 10:02:13AM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v Po 28. 01. 2008 v 09:46 +0100: > > On Sun, Jan 27, 2008 at 08:54:51PM -0800, Randy Presuhn wrote: > > > > > If I'm archiving a configuration, I want to know *exactly* > > > what it is. One of the reasons for archiving configurations > > > is so that if a box fails, a replacement can be quickly made > > > to function in its place. If there is even a remote chance > > > that a default value might change between releases or on > > > different versions of a hardware platform, that value needs > > > to be included in an archive of the configuration. > > > > If your replacement is using the exact same hardware configuration and > > the exact same firmware version, you do not need to worry about the > > defaults. > > > > If your replacement is not using the exact same hardware configuration > > and the exact same firmware version, there is a chance that things > > won't work as expected, with and without saved defaults. > > > > If things fail, you need to have a human to figure out what is the > > Here is the problem with changed defaults: things will not fail, they > will just work differently from what you expect. Well, applying a default from an old firmware release to a newer hardware firmware combination can as well lead to something that does not fail but work differently from what you expect. My point is you need to be able to (a) get all configuration settings of a box and (b) the subset that was explicitely configured. It is then the operator's choice what to use where and when. Trying to rule out (a) over (b) or (b) over (a) is wasting time and bandwidth. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 05:10:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJQwR-0002tg-8A; Mon, 28 Jan 2008 05:10:15 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJQwQ-0002tJ-1I for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 05:10:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJQwP-0002tB-N6 for yang@ietf.org; Mon, 28 Jan 2008 05:10:13 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJQwP-0003VK-8a for yang@ietf.org; Mon, 28 Jan 2008 05:10:13 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id CD8C3D80098 for ; Mon, 28 Jan 2008 11:10:12 +0100 (CET) Subject: Re: [YANG] mandatory & default From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080128094703.GA20045@elstar.local> References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <000a01c86169$eb717200$6801a8c0@oemcomputer> <20080128084636.GA19843@elstar.local> <1201510933.30693.81.camel@missotis> <20080128094703.GA20045@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 28 Jan 2008 11:10:12 +0100 Message-Id: <1201515012.30693.101.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v Po 28. 01. 2008 v 10:47 +0100: >=20 > My point is you need to be able to (a) get all configuration settings > of a box and (b) the subset that was explicitely configured. It is > then the operator's choice what to use where and when. Trying to rule > out (a) over (b) or (b) over (a) is wasting time and bandwidth. I don't intend to rule anything out, I just don't wan't to have (b) as a mandatory function in all devices. It should be an optional capability. On the other hand, (a) is by all means essential. Lada >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 05:41:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRQR-00010f-T2; Mon, 28 Jan 2008 05:41:15 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJRQR-00010a-0f for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 05:41:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRQQ-00010S-N6 for yang@ietf.org; Mon, 28 Jan 2008 05:41:14 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJRQQ-0003xW-93 for yang@ietf.org; Mon, 28 Jan 2008 05:41:14 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7F408A175; Mon, 28 Jan 2008 11:41:13 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24513-03; Mon, 28 Jan 2008 11:41:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 359EA8A24C; Mon, 28 Jan 2008 11:41:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AF94348CF32; Mon, 28 Jan 2008 11:41:02 +0100 (CET) Date: Mon, 28 Jan 2008 11:41:02 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Subject: Re: [YANG] mandatory & default Message-ID: <20080128104102.GA20123@elstar.local> Mail-Followup-To: Ladislav Lhotka , yang@ietf.org References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <000a01c86169$eb717200$6801a8c0@oemcomputer> <20080128084636.GA19843@elstar.local> <1201510933.30693.81.camel@missotis> <20080128094703.GA20045@elstar.local> <1201515012.30693.101.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201515012.30693.101.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Mon, Jan 28, 2008 at 11:10:12AM +0100, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v Po 28. 01. 2008 v 10:47 +0100: > > > > > My point is you need to be able to (a) get all configuration settings > > of a box and (b) the subset that was explicitely configured. It is > > then the operator's choice what to use where and when. Trying to rule > > out (a) over (b) or (b) over (a) is wasting time and bandwidth. > > I don't intend to rule anything out, I just don't wan't to have (b) as a > mandatory function in all devices. It should be an optional capability. > On the other hand, (a) is by all means essential. Our problem is that others believe (b) is by all means essential and (a) should be an optional capability. This is our dilemma. Why is it not OK to have (a) and (b)? Why do you not want to have (b) as a mandatory function in all devices? Do you think it is too costly to maintain this additional bit per explicitely configured knob or are there other reasons? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 05:49:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRYp-0001KX-9B; Mon, 28 Jan 2008 05:49:55 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJRYo-0001KQ-5C for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 05:49:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRYn-0001KH-Rf for yang@ietf.org; Mon, 28 Jan 2008 05:49:53 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJRYm-0004RM-ND for yang@ietf.org; Mon, 28 Jan 2008 05:49:53 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3263D2074C; Mon, 28 Jan 2008 11:49:52 +0100 (CET) X-AuditID: c1b4fb3c-aaaedbb0000007e0-bb-479db350b110 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 12C9320509; Mon, 28 Jan 2008 11:49:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 11:49:51 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 11:49:51 +0100 Message-ID: <479DB34F.10103@ericsson.com> Date: Mon, 28 Jan 2008 11:49:51 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] mandatory & default References: <200801280322.m0S3Mqhi051945@idle.juniper.net> In-Reply-To: <200801280322.m0S3Mqhi051945@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2008 10:49:51.0501 (UTC) FILETIME=[825CE3D0:01C8619B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hello, Some basic statements for me: 1) the get-config results can or can not contain defaults based on the with-defaults parameter, so the content of get-config is not a deciding factor between the different "default" alternatives. 2) Storing the default values is an internal issue for the implementation, which is independent from the existence (or not) of a leaf in the conceptual database. Balazs Phil Shafer wrote: > [replying to multiple Andy-grams] > > Andy Bierman writes: >> Whether the manager or the agent sets the leaf to the default, >> it is there from a NETCONF protocol PoV. > > NETCONF leaves all this to the data model, so there's no single > NETCONF POV on this issue. This is designed to support existing > views of configuration issues, including defaults. > >> It is an implementation-specific matter as to how >> an agent generates a reply to a request. >> The defaults do not have to be stored -- they can >> be generated on the fly. > > If I'm using NETCONF to archive configurations, I don't > want them littered with defaults. Similar for if I'm > viewing them in the equivalent of a mib browser. I want > to see the statements that someone has explicitly configured, > not volumes of uninteresting defaults. > > Part of putting these values into YANG modules is to allow > interested parties (applications, developers) to know these values > as they are helping the user create new instances. To my mind, the > "with-defaults" is useless for this scenario, since I want to know > the defaults _before_ I make the config, not after. > > The KISS view of config is used for CLIs because is keeps the > noise to a minimum. This need doesn't disappear when the > config moves into the application/automation world. > > >> Message-ID: <479A799D.1060003@andybierman.com> >> Date: Fri, 25 Jan 2008 16:06:53 -0800 >> From: Andy Bierman >> >> After a system reboot, does the agent 'remember' that mtu >> was set to 1500 by the manager, so the initial >> config from NV-storage after the next reboot has an mtu leaf >> for eth1? > > No, the system records as the configuration only those fields which > are interesting. For example in JUNOS, we define "interesting" as > anything the user told us to do. In IOS, they define "interesting" > as any non-default values. IMHO, you're trying to define interesting > to include some very boring defaults. > > >> Message-ID: <479B4B65.90104@andybierman.com> >> Date: Sat, 26 Jan 2008 07:01:57 -0800 >> From: Andy Bierman >> >> But here is where this CLI-based design is broken. >> If a manager sends jumbo packets on eth1, they will not be accepted. >> There is a maximum transmission unit size in effect on eth1, >> but the manager is told there is none in the . > > The application can find all the information about "mtu", including > its default value, in the metadata. The application can show this > default value to the user as they create a new interface, and the > application can know that if there's an in the interface, its > there because someone wanted it, and that's it's not noise. > >> The response "oh no, there is an MTU value in effect, just not in the config" >> is really broken. It's not state data, and it's not config data, but if >> the manager does not know the value, it cannot reliably configure other >> devices that send packets to 'eth1' on this agent. > > Nope, it's not config data. It's a default value. The device > doesn't need it to perform the job of configuration, which is > defined in the NETCONF spec as: > > Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state. > > Default values aren't required in config data. Or wanted. > > If I've got 64,000 interfaces, I don't need to see this default > value for each interface, let alone the hundred other knobs for > each interface that have perfect reasonable and completely > uninteresting default values. > >> IMO, the mtu is clearly config data, and clearly in effect at >> all times eth1 is accepting packets. The config returned >> in NETCONF PDUs should match. Filtering out these defaults >> is a separate issue from whether they exist or not. > > The issue isn't filtering them out. The issue is are defaults part > of the configuration? I understand the need for a mechanism for > discovering them, both inline and in metadata, but I don't see any > win in considering such noise as part of the configuration of a > device. > > We are working hard to make devices _more_ managable. Adding a > couple of orders of magnitude of noise into the configuration > means: > - performance issues (as my 1m config turns into 100m) > - upgrade/downgrade issues (as defaults for unused features break > on software that doesn't support them, even if they are completely > unimportant) > - readability issues (as adding noise makes the config less readable > and the purpose of using xml was human readability for debugging > and monitoring) > > Inline defaults is broken, to lift your words, since it takes a > complex problem and makes it more complex. We should be simplifying, > reducing, and giving better visibility into the important parts of > configuration, not polluting them with noise. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 06:29:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSAh-0002xU-4e; Mon, 28 Jan 2008 06:29:03 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJSAf-0002xB-JI for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 06:29:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSAf-0002w4-7Q for yang@ietf.org; Mon, 28 Jan 2008 06:29:01 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JJSAe-0005VD-Ni for yang@ietf.org; Mon, 28 Jan 2008 06:29:01 -0500 Received: (qmail 68022 invoked from network); 28 Jan 2008 11:29:00 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.121.104.118 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 28 Jan 2008 11:28:59 -0000 X-YMail-OSG: HaESxf0VM1kAXn4ZabOX3jXylEpKlbWvxH6BlV082ilqdvzECYnu3SYTCjUd9D7EOcN1UmLNBt3jqNbOCMqhyZDe X-Yahoo-Newman-Property: ymail-3 Message-ID: <479DBC89.5010503@andybierman.com> Date: Mon, 28 Jan 2008 03:29:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer Subject: Re: [YANG] mandatory & default References: <200801280650.m0S6o9wi052898@idle.juniper.net> In-Reply-To: <200801280650.m0S6o9wi052898@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > "Randy Presuhn" writes: >> One of the reasons for archiving configurations >> is so that if a box fails, a replacement can be quickly made >> to function in its place. > > Loading the saved file with defaults won't make this > any saner, safer, or stronger. It increases the fragility, > but incorporating into the saved file tons of stuff about > which you don't care. It something fails on these values > that you don't care about, you are broken. > this is not correct. If you load a config with the full set of values, then agent is forced to accept the value or issue an error. This is not fragile. This is debugging. Fragile is when the new software image sees that no value is given for the foo-knob, so it assigns a *different* default value than the last SW image, and does not complain at all. Andy >> If there is even a remote chance >> that a default value might change between releases or on >> different versions of a hardware platform, that value needs >> to be included in an archive of the configuration. > > The chance of a change in defaults (which annoy customers to > no end) is minor compared to the change of adding features (which > customers insist on) and the need to support downgrading (which > customers insist on). > > Consider this example from JUNOS-land. We have a set of foo-options > containers that are used to hold media-specific options under > the [interfaces] statement. These options are numerous, verbose, > and rarely used. If I add a new statement in release 9.0 and > start emitting a boring default value for it, I can no longer > load that config in any release predating 9.0. > > In avoiding a rare bug (changing defaults), you'll break real > operational usage. > > Thanks, > Phil > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 07:02:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJShI-0002qQ-0P; Mon, 28 Jan 2008 07:02:44 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJShG-0002kR-LA for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 07:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJShF-0002hX-4p; Mon, 28 Jan 2008 07:02:41 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJShC-00062q-Tc; Mon, 28 Jan 2008 07:02:41 -0500 X-IronPort-AV: E=Sophos;i="4.25,259,1199682000"; d="scan'208";a="89150316" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Jan 2008 07:02:37 -0500 X-IronPort-AV: E=Sophos;i="4.25,259,1199682000"; d="scan'208";a="147642913" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Jan 2008 07:02:31 -0500 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: Mon, 28 Jan 2008 13:02:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-presuhn-rcdml-00.txt Thread-Index: AchheP5QjeH2JlF8T+OAGKHG4CnAIQACVruwAAjMMeA= From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [YANG] RE: I-D Action:draft-presuhn-rcdml-00.txt X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Sorry, comments better be addressed to ngo@ietf.org. This is what the I-D says and it's better to let the yang folks focus on yang work.=20 Dan =20 =20 > -----Original Message----- > From: Romascanu, Dan (Dan)=20 > Sent: Monday, January 28, 2008 9:53 AM > To: netconf@ops.ietf.org; 'yang@ietf.org';=20 > 'ops-area@ietf.org'; ngo@ietf.org > Subject: FW: I-D Action:draft-presuhn-rcdml-00.txt=20 >=20 > I apologize for cross-posting, but I think it is justified in=20 > this case. I suggest yang@ietf.org as prefered space for comments.=20 >=20 > Dan >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, January 28, 2008 8:40 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-presuhn-rcdml-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Requirements for a Configuration Data=20 > Modeling Language > Author(s) : R. Presuhn > Filename : draft-presuhn-rcdml-00.txt > Pages : 22 > Date : 2008-01-28 >=20 > This memo contains a compilation of requirements for a=20 > Configuration Data Modeling Language. Although focusing on=20 > the needs of the NETCONF Protocol, these requirements=20 > potentially have broader applicability. Comments should be=20 > sent to ngo@ietf.org. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-presuhn-rcdml-00.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-presuhn-rcdml-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-presuhn-rcdml-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 > This email was protected during delivery to Avaya with TLS encryption >=20 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 07:08:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSml-0007Zu-Or; Mon, 28 Jan 2008 07:08:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJSmk-0007ZC-QZ for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 07:08:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSmk-0007XM-EX for yang@ietf.org; Mon, 28 Jan 2008 07:08:22 -0500 Received: from office2.cesnet.cz ([195.113.144.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJSmj-0001gY-Q7 for yang@ietf.org; Mon, 28 Jan 2008 07:08:22 -0500 Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6535CD80098 for ; Mon, 28 Jan 2008 13:08:21 +0100 (CET) Subject: Re: [YANG] mandatory & default From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080128104102.GA20123@elstar.local> References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <000a01c86169$eb717200$6801a8c0@oemcomputer> <20080128084636.GA19843@elstar.local> <1201510933.30693.81.camel@missotis> <20080128094703.GA20045@elstar.local> <1201515012.30693.101.camel@missotis> <20080128104102.GA20123@elstar.local> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 28 Jan 2008 13:08:21 +0100 Message-Id: <1201522101.30693.140.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder p=C3=AD=C5=A1e v Po 28. 01. 2008 v 11:41 +0100: > On Mon, Jan 28, 2008 at 11:10:12AM +0100, Ladislav Lhotka wrote: > >=20 > > Juergen Schoenwaelder p????e v Po 28. 01. 2008 v 10:47 +0100: > >=20 > > >=20 > > > My point is you need to be able to (a) get all configuration settin= gs > > > of a box and (b) the subset that was explicitely configured. It is > > > then the operator's choice what to use where and when. Trying to ru= le > > > out (a) over (b) or (b) over (a) is wasting time and bandwidth. > >=20 > > I don't intend to rule anything out, I just don't wan't to have (b) a= s a > > mandatory function in all devices. It should be an optional capabilit= y. > > On the other hand, (a) is by all means essential. >=20 > Our problem is that others believe (b) is by all means essential and > (a) should be an optional capability. This is our dilemma. >=20 > Why is it not OK to have (a) and (b)? Why do you not want to have (b) > as a mandatory function in all devices? Do you think it is too costly > to maintain this additional bit per explicitely configured knob or are > there other reasons? I guess it is probably because two different implementations are around: 1. The device has an internal "database" of operational parameters (perhaps as registers, variables and structures in its firmware and software) but its configuration is something else, for example only the stuff that the user specified. For this implementation it is an extra burden to retrieve the parameters from the operational structures and write them to the configuration. 2. The operational values are explicitly represented in a configuration database and the internal operational values are either taken directly from it or synchronised with it (e.g., via ioctl for firmware). This implementation can simply dump the entire database while it is an extra burden to keep the information about whether a parameter has been changed or not. I understand that JUNOS, IOS and some Unix daemons like GateD use 1 while we use 2 in our devices, but it doesn't matter. The question really is: Is it OK if we allow a device to keep part of the essential operational parameters for itself? If the answer is NO, then implementation 1 must be able to do the homework and collect all the values for the manager. So, for me (a) is a necessity. On the other hand, approach 2 doesn't hide anything, it only poses technical difficulties to the manager by sending the entire operational configuration. However, I claim it is possible to protect the human user from being overwhelmed by other means outside the device, i.e., (b) is not a necessity. Lada >=20 > /js >=20 --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 11:18:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWgv-0007Bo-Up; Mon, 28 Jan 2008 11:18:37 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJWgu-0007BX-U1 for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 11:18:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWgu-0007At-IX for yang@ietf.org; Mon, 28 Jan 2008 11:18:36 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWgt-0003Xo-En for yang@ietf.org; Mon, 28 Jan 2008 11:18:36 -0500 X-Trace: 28391295/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.31 X-SBRS: None X-RemoteIP: 62.241.162.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI2OnUc+8aIf/2dsb2JhbACKUaED X-IP-Direction: IN Received: from galaxy.systems.pipex.net ([62.241.162.31]) by smtp.pipex.tiscali.co.uk with ESMTP; 28 Jan 2008 16:18:32 +0000 Received: from pc6 (1Cust155.tnt7.lnd4.gbr.da.uu.net [62.188.136.155]) by galaxy.systems.pipex.net (Postfix) with SMTP id D385DE0000B0; Mon, 28 Jan 2008 16:18:27 +0000 (GMT) Message-ID: <040d01c861c0$c7d06e80$0601a8c0@pc6> From: "tom.petch" To: "Andy Bierman" , "Phil Shafer" References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <479D55B9.8010300@andybierman.com> Subject: Re: [YANG] mandatory & default Date: Mon, 28 Jan 2008 16:16:26 +0100 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 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org ----- Original Message ----- From: "Andy Bierman" To: "Phil Shafer" Cc: Sent: Monday, January 28, 2008 5:10 AM Subject: Re: [YANG] mandatory & default > Phil Shafer wrote: > > [replying to multiple Andy-grams] > > > > We strongly disagree on the interpretation of RFC 4741 > and whether a node with a default value really exists or not. > > It is very fragile SW design to assume the agent is using the exact default > that was tracked down in the documentation. > > It is up to the operator whether knowing that a node > is actually supported, and knowing the exact value set by the agent, > is a waste of space or important debugging information. > I am very much with Andy (and Randy) on this one. Knowing all the parameters that affect how a box functions is vital; it may be the only way to work out why it is not working as the operator thinks it should be. I would say that having access to both the full and the specified configuration is a MUST. If forced to choose which had to be implemented, I would go for the full configuration every time. Computers can simply and reliably remove the extra information, they cannot (as) reliably insert the supposed defaults as known on the device. Tom Petch > > Andy > > > > Andy Bierman writes: > >> Whether the manager or the agent sets the leaf to the default, > >> it is there from a NETCONF protocol PoV. > > > > NETCONF leaves all this to the data model, so there's no single > > NETCONF POV on this issue. This is designed to support existing > > views of configuration issues, including defaults. > > > >> It is an implementation-specific matter as to how > >> an agent generates a reply to a request. > >> The defaults do not have to be stored -- they can > >> be generated on the fly. > > > > If I'm using NETCONF to archive configurations, I don't > > want them littered with defaults. Similar for if I'm > > viewing them in the equivalent of a mib browser. I want > > to see the statements that someone has explicitly configured, > > not volumes of uninteresting defaults. > > > > Part of putting these values into YANG modules is to allow > > interested parties (applications, developers) to know these values > > as they are helping the user create new instances. To my mind, the > > "with-defaults" is useless for this scenario, since I want to know > > the defaults _before_ I make the config, not after. > > > > The KISS view of config is used for CLIs because is keeps the > > noise to a minimum. This need doesn't disappear when the > > config moves into the application/automation world. > > > > > >> Message-ID: <479A799D.1060003@andybierman.com> > >> Date: Fri, 25 Jan 2008 16:06:53 -0800 > >> From: Andy Bierman > >> > >> After a system reboot, does the agent 'remember' that mtu > >> was set to 1500 by the manager, so the initial > >> config from NV-storage after the next reboot has an mtu leaf > >> for eth1? > > > > No, the system records as the configuration only those fields which > > are interesting. For example in JUNOS, we define "interesting" as > > anything the user told us to do. In IOS, they define "interesting" > > as any non-default values. IMHO, you're trying to define interesting > > to include some very boring defaults. > > > > > >> Message-ID: <479B4B65.90104@andybierman.com> > >> Date: Sat, 26 Jan 2008 07:01:57 -0800 > >> From: Andy Bierman > >> > >> But here is where this CLI-based design is broken. > >> If a manager sends jumbo packets on eth1, they will not be accepted. > >> There is a maximum transmission unit size in effect on eth1, > >> but the manager is told there is none in the . > > > > The application can find all the information about "mtu", including > > its default value, in the metadata. The application can show this > > default value to the user as they create a new interface, and the > > application can know that if there's an in the interface, its > > there because someone wanted it, and that's it's not noise. > > > >> The response "oh no, there is an MTU value in effect, just not in the config" > >> is really broken. It's not state data, and it's not config data, but if > >> the manager does not know the value, it cannot reliably configure other > >> devices that send packets to 'eth1' on this agent. > > > > Nope, it's not config data. It's a default value. The device > > doesn't need it to perform the job of configuration, which is > > defined in the NETCONF spec as: > > > > Configuration data is the set of writable data that is required to > > transform a system from its initial default state into its current > > state. > > > > Default values aren't required in config data. Or wanted. > > > > If I've got 64,000 interfaces, I don't need to see this default > > value for each interface, let alone the hundred other knobs for > > each interface that have perfect reasonable and completely > > uninteresting default values. > > > >> IMO, the mtu is clearly config data, and clearly in effect at > >> all times eth1 is accepting packets. The config returned > >> in NETCONF PDUs should match. Filtering out these defaults > >> is a separate issue from whether they exist or not. > > > > The issue isn't filtering them out. The issue is are defaults part > > of the configuration? I understand the need for a mechanism for > > discovering them, both inline and in metadata, but I don't see any > > win in considering such noise as part of the configuration of a > > device. > > > > We are working hard to make devices _more_ managable. Adding a > > couple of orders of magnitude of noise into the configuration > > means: > > - performance issues (as my 1m config turns into 100m) > > - upgrade/downgrade issues (as defaults for unused features break > > on software that doesn't support them, even if they are completely > > unimportant) > > - readability issues (as adding noise makes the config less readable > > and the purpose of using xml was human readability for debugging > > and monitoring) > > > > Inline defaults is broken, to lift your words, since it takes a > > complex problem and makes it more complex. We should be simplifying, > > reducing, and giving better visibility into the important parts of > > configuration, not polluting them with noise. > > > > Thanks, > > Phil > > > > > > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Jan 28 12:10:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXV5-0002aC-Ee; Mon, 28 Jan 2008 12:10:27 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JJXV1-0002TO-RW for yang-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 12:10:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXV1-0002T4-Fy for yang@ietf.org; Mon, 28 Jan 2008 12:10:23 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JJXV0-0005SZ-V8 for yang@ietf.org; Mon, 28 Jan 2008 12:10:23 -0500 Received: (qmail 49707 invoked from network); 28 Jan 2008 17:10:22 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.121.104.118 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 28 Jan 2008 17:10:22 -0000 X-YMail-OSG: fX3p2DMVM1lfJJdOnKKTFQXpKYuPBa7JbjKo0LCSH_qZa.OxC3ItdOVecco6.O9PuXZF2KLSWm_ecoN2Dt4Dq23Z X-Yahoo-Newman-Property: ymail-3 Message-ID: <479E0C93.8000700@andybierman.com> Date: Mon, 28 Jan 2008 09:10:43 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [YANG] mandatory & default References: <200801280322.m0S3Mqhi051945@idle.juniper.net> <479D55B9.8010300@andybierman.com> <040d01c861c0$c7d06e80$0601a8c0@pc6> In-Reply-To: <040d01c861c0$c7d06e80$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org tom.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Monday, January 28, 2008 5:10 AM > Subject: Re: [YANG] mandatory & default > > >> Phil Shafer wrote: >>> [replying to multiple Andy-grams] >>> >> We strongly disagree on the interpretation of RFC 4741 >> and whether a node with a default value really exists or not. >> >> It is very fragile SW design to assume the agent is using the exact default >> that was tracked down in the documentation. >> >> It is up to the operator whether knowing that a node >> is actually supported, and knowing the exact value set by the agent, >> is a waste of space or important debugging information. >> > > I am very much with Andy (and Randy) on this one. Knowing all the parameters > that affect how a box functions is vital; it may be the only way to work out why > it is not working as the operator thinks it should be. > > I would say that having access to both the full and the specified configuration > is a MUST. If forced to choose which had to be implemented, I would go for the > full configuration every time. Computers can simply and reliably remove the > extra information, they cannot (as) reliably insert the supposed defaults as > known on the device. > I think Juergen also agrees that access to all the parameters is sometimes needed to debug a broken network. I think there is some consensus that a mechanism is needed to retrieve just the non-defaults, or retrieve everything. I have already published the 'with-defaults' mechanism: http://www.ietf.org/internet-drafts/draft-bierman-ncx-ext-00.txt There is no capability URI defined to advertise this extension. I have also implemented 'per-session' parameters (ala set term) to set the session default for the per-PDU 'with-defaults', to simplify manager access. At a minimum, there should also be a read-only leaf added to the NETCONF Monitoring DM to indicate the agent-wide default for the 'with-defaults' flag. (Per session control is extra credit ;-) An agent can leave out the defaults as the normal case if this global flag is set to false. However, the 'with-defaults=true' flag must be honored when added to a get* or copy-config PDU. > Tom Petch > >> Andy Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang