From netmod-bounces@ietf.org Fri Aug 1 03:28:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420EF28C21C; Fri, 1 Aug 2008 03:28:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985BB28C3F0 for ; Fri, 1 Aug 2008 03:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMB954FY7B2r for ; Fri, 1 Aug 2008 03:28:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8FF5128C3EE for ; Fri, 1 Aug 2008 03:28:55 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7D4AC0007 for ; Fri, 1 Aug 2008 12:28:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8li9kT3IKV1P; Fri, 1 Aug 2008 12:28:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13E68C0009; Fri, 1 Aug 2008 12:28:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D55E2680CE3; Fri, 1 Aug 2008 12:28:24 +0200 (CEST) Date: Fri, 1 Aug 2008 12:28:24 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20080801102824.GA4873@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I have looked up the XSD specifications and they clearly state that multiple pattern are ORed together: http://www.w3.org/TR/xmlschema-2/#src-multiple-patterns So in YANG words, pattern A; pattern B; is equivalent to pattern A|B; and this is why the YANG team initially decided to not support multiple patterns. With this insight, it becomes clear that the example discussed in the thread "range/length and pattern statements" is not solvable unless we handle pattern different than XSD (which means confusion of readers and real complexity of translators that would have to AND the YANG pattern into XSD pattern). So my conclusion is to keep what YANG does today (only one pattern) and to document why we do not follow XSD here (or that XSD does not provide more value here). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 1 04:20:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB693A6782; Fri, 1 Aug 2008 04:20:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB473A6904 for ; Fri, 1 Aug 2008 04:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1ETK-T26cjO for ; Fri, 1 Aug 2008 04:20:02 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 2B9383A6782 for ; Fri, 1 Aug 2008 04:20:02 -0700 (PDT) Received: (qmail 30268 invoked from network); 1 Aug 2008 11:20:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 1 Aug 2008 11:20:20 -0000 X-YMail-OSG: zlbYxMQVM1m1tqgMIQIzNUNMAhlY.glvkpgt.kb5fjlZDxCnA8KfdGfvpDVTlR4x7O5g_GWoFjj4gLwZehQI6sS4_B4KoPsRMBgrh46jXlSx4EExRQYwcUI5IBeLvCU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4892F172.7060006@netconfcentral.com> Date: Fri, 01 Aug 2008 04:20:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: netmod@ietf.org References: <20080801102824.GA4873@elstar.local> In-Reply-To: <20080801102824.GA4873@elstar.local> Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > Hi, > > I have looked up the XSD specifications and they clearly state that > multiple pattern are ORed together: > > http://www.w3.org/TR/xmlschema-2/#src-multiple-patterns > thanks for taking my action item :-) This is the section I remember. > So in YANG words, > > pattern A; > pattern B; > > is equivalent to > > pattern A|B; > > and this is why the YANG team initially decided to not support > multiple patterns. With this insight, it becomes clear that the > example discussed in the thread "range/length and pattern statements" > is not solvable unless we handle pattern different than XSD (which > means confusion of readers and real complexity of translators that > would have to AND the YANG pattern into XSD pattern). > > So my conclusion is to keep what YANG does today (only one pattern) > and to document why we do not follow XSD here (or that XSD does not > provide more value here). > I want to remain compatible with XSD. YANG has quoted string concatenation, so why not just add an OR expression to the pattern that is already there? YANG still supports ANDed patterns: typedef A { type string { pattern '...'; } } typedef B { type A { pattern '...'; } } (BTW, it is good practice to use single quoted strings because some pattern escape sequences get processed by the YANG string rules, and break the pattern. SQ strings never get altered by the complier. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 1 09:40:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D713A6AAF; Fri, 1 Aug 2008 09:40:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FCB3A6ACC for ; Fri, 1 Aug 2008 09:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dii+0b+gLEaa for ; Fri, 1 Aug 2008 09:40:14 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 8AFFA3A6AAF for ; Fri, 1 Aug 2008 09:40:14 -0700 (PDT) Received: (qmail 65833 invoked from network); 1 Aug 2008 16:40:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 1 Aug 2008 16:40:33 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48933C80.1060300@netconfcentral.com> Date: Fri, 01 Aug 2008 09:40:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, It seems to me there isn't much agreement on a common framework for NETMOD, in areas such as builtin data types, SMI integration, version identification, version management, OO vs. procedural, 80/20 rule vs. machine-readable-everything, and on and on. One example, namespace URIs: I am with the camp that sets this field once for a module, and never changes it -- ever. (BTW, is there a need to mark an entire module namespace as deprecated or obsolete?) Instead, the revision-stmt is rigorously used to provide an incrementing version field for every module. Another example, yang-types: I do not understand why I need ZeroBasedCounter32 from smidump -f yang, zero-based-counter32 from yang-types, and I can't use this type at all in SMI-to-XSD. I strongly suggest gaining control of the data type landscape sooner rather than later. I hope Juergen's plan of documenting all the differences in yang-types is good enough. I agree that encodings should favor XML tools, not legacy SMI tools, but what do the DM readers really gain by having duplicates of Counter32? I understand the need to get data types in use before NETMOD is done. I suggest that the highly integrated approach in smidump be followed. For immediate standards purposes, that simply means use the correct names and modules. Instead of importing counter32 from yang-types, I would rather import Counter32 from SNMPv2-SMI. Types that are different than the SMIv2 versions should remain in yang-types.yang. Types that are exactly the same as the SMIv2 types should use the SMIv2 name and module location. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 1 19:42:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D413A6821; Fri, 1 Aug 2008 19:42:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3BD3A6B73 for ; Fri, 1 Aug 2008 19:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIWzZM1tZkDJ for ; Fri, 1 Aug 2008 19:41:57 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id DDA4C3A6B79 for ; Fri, 1 Aug 2008 19:41:57 -0700 (PDT) Received: (qmail 38760 invoked from network); 2 Aug 2008 02:42:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Aug 2008 02:42:13 -0000 X-YMail-OSG: Ijx.CAYVM1kaEfm.XwWkaG.JMv2vINqzvPRWn_UZLfSSygRsSrBEsCvqiLxY4PRAFCHK.Q5Oo72.VZVSGNaVDHn_FROx1D5648OM2K5S.A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4893C984.2020400@netconfcentral.com> Date: Fri, 01 Aug 2008 19:42:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] module revision and source X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, 1) module revision I did not hear if revision-stmt is now mandatory or not. IMO, this is a good idea. The description within it is optional, so the burden on the writer is just: revision yyyy-mm-dd; 2) module source Juergen mentioned that the revision description clause is good for finding the source document that the module was extracted from. I agree. I think the module reference field should be utilized for this purpose: module yang-types { ... description "..."; reference "draft-schoenw-netmod-yang-types-01.txt"; ... } IMO, a module description and reference should be required for all IETF YANG modules. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 11:43:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5663A6A9B; Sat, 2 Aug 2008 11:43:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666243A6AA4 for ; Sat, 2 Aug 2008 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWf8EF1c5a2d for ; Sat, 2 Aug 2008 11:43:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8431B3A6AA6 for ; Sat, 2 Aug 2008 11:43:24 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 535F1D80098 for ; Sat, 2 Aug 2008 20:43:47 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080801102824.GA4873@elstar.local> References: <20080801102824.GA4873@elstar.local> Organization: CESNET Date: Sat, 02 Aug 2008 20:43:46 +0200 Message-Id: <1217702626.9157.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGksCgppbiBSRUxBWCBORywgbXVsdGlwbGUgcGF0dGVybnMgYXJlIEFORGVkOgoKaHR0cDovL3d3 dy5yZWxheG5nLm9yZy94c2QtMjAwMTA5MDcuaHRtbCNJREFNRFlSCgpUaGlzIHdhcyBhY2NlcHRl ZCBpbiBvcmRlciB0byBoYXZlIHRoZSBmdW5jdGlvbmFsaXR5IGF2YWlsYWJsZSBpbiBYU0QsCnNl ZQpodHRwOi8vbGlzdHMub2FzaXMtb3Blbi5vcmcvYXJjaGl2ZXMvcmVsYXgtbmcvMjAwMTA1L21z ZzAwMjExLmh0bWwKCkkgZ3Vlc3MgdGhlIGlzc3VlIGZvciBZQU5HIGlzOiBJcyB0aGVyZSBhIHdh eSBmb3IgQU5EaW5nIHBhdHRlcm5zPyBJZgpub3QsIEknZCBzdWdnZXN0IHRvIGZvbGxvdyB0aGUg UkVMQVggTkcgd2F5LgoKTGFkYQoKSnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFDDoSAw MS4gMDguIDIwMDggdiAxMjoyOCArMDIwMDoKPiBIaSwKPiAKPiBJIGhhdmUgbG9va2VkIHVwIHRo ZSBYU0Qgc3BlY2lmaWNhdGlvbnMgYW5kIHRoZXkgY2xlYXJseSBzdGF0ZSB0aGF0Cj4gbXVsdGlw bGUgcGF0dGVybiBhcmUgT1JlZCB0b2dldGhlcjoKPiAKPiBodHRwOi8vd3d3LnczLm9yZy9UUi94 bWxzY2hlbWEtMi8jc3JjLW11bHRpcGxlLXBhdHRlcm5zCj4gCj4gU28gaW4gWUFORyB3b3JkcywK PiAKPiAgICBwYXR0ZXJuIEE7Cj4gICAgcGF0dGVybiBCOwo+IAo+IGlzIGVxdWl2YWxlbnQgdG8K PiAKPiAgICBwYXR0ZXJuIEF8QjsKPiAKPiBhbmQgdGhpcyBpcyB3aHkgdGhlIFlBTkcgdGVhbSBp bml0aWFsbHkgZGVjaWRlZCB0byBub3Qgc3VwcG9ydAo+IG11bHRpcGxlIHBhdHRlcm5zLiBXaXRo IHRoaXMgaW5zaWdodCwgaXQgYmVjb21lcyBjbGVhciB0aGF0IHRoZQo+IGV4YW1wbGUgZGlzY3Vz c2VkIGluIHRoZSB0aHJlYWQgInJhbmdlL2xlbmd0aCBhbmQgcGF0dGVybiBzdGF0ZW1lbnRzIgo+ IGlzIG5vdCBzb2x2YWJsZSB1bmxlc3Mgd2UgaGFuZGxlIHBhdHRlcm4gZGlmZmVyZW50IHRoYW4g WFNEICh3aGljaAo+IG1lYW5zIGNvbmZ1c2lvbiBvZiByZWFkZXJzIGFuZCByZWFsIGNvbXBsZXhp dHkgb2YgdHJhbnNsYXRvcnMgdGhhdAo+IHdvdWxkIGhhdmUgdG8gQU5EIHRoZSBZQU5HIHBhdHRl cm4gaW50byBYU0QgcGF0dGVybikuCj4gCj4gU28gbXkgY29uY2x1c2lvbiBpcyB0byBrZWVwIHdo YXQgWUFORyBkb2VzIHRvZGF5IChvbmx5IG9uZSBwYXR0ZXJuKQo+IGFuZCB0byBkb2N1bWVudCB3 aHkgd2UgZG8gbm90IGZvbGxvdyBYU0QgaGVyZSAob3IgdGhhdCBYU0QgZG9lcyBub3QKPiBwcm92 aWRlIG1vcmUgdmFsdWUgaGVyZSkuCj4gCj4gL2pzCj4gCi0tIApMYWRpc2xhdiBMaG90a2EsIENF U05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sat Aug 2 11:57:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F373A689B; Sat, 2 Aug 2008 11:57:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879003A698C for ; Sat, 2 Aug 2008 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzVoPS6Mt-HP for ; Sat, 2 Aug 2008 11:57:42 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 1FD073A68C5 for ; Sat, 2 Aug 2008 11:57:42 -0700 (PDT) Received: (qmail 85478 invoked from network); 2 Aug 2008 18:58:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 2 Aug 2008 18:58:03 -0000 X-YMail-OSG: uibpAG4VM1mEB8.nDT7EGnwb06mpTpo5f4QOQQ5zgyDCnH2HcB0yQph3Z2r7FVEqBuAFqXozS.oy70t9U8Mca6oIHn3BOAeZzFBELrlOyy2JI9eQXrFkDxCfnL_QXNg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4894AE39.5010001@netconfcentral.com> Date: Sat, 02 Aug 2008 11:58:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <20080801102824.GA4873@elstar.local> <1217702626.9157.21.camel@missotis> In-Reply-To: <1217702626.9157.21.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > in RELAX NG, multiple patterns are ANDed: > > http://www.relaxng.org/xsd-20010907.html#IDAMDYR > > This was accepted in order to have the functionality available in XSD, > see > http://lists.oasis-open.org/archives/relax-ng/200105/msg00211.html > > I guess the issue for YANG is: Is there a way for ANDing patterns? If > not, I'd suggest to follow the RELAX NG way. > Yes there already is a way to AND patterns with multiple typedefs. You can also split up pattern strings into as many lines and fragments as you want. I do not support any plan to become incompatible with XSD, without a really compelling use-case. This is redundant functionality, and therefore does not qualify. > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 12:06:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FACE3A6A5F; Sat, 2 Aug 2008 12:06:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D003A6A9B for ; Sat, 2 Aug 2008 12:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.072 X-Spam-Level: X-Spam-Status: No, score=-0.072 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqiWTMQzOwCx for ; Sat, 2 Aug 2008 12:06:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BE13D3A65A5 for ; Sat, 2 Aug 2008 12:06:52 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D3487D800C0; Sat, 2 Aug 2008 21:07:08 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4894AE39.5010001@netconfcentral.com> References: <20080801102824.GA4873@elstar.local> <1217702626.9157.21.camel@missotis> <4894AE39.5010001@netconfcentral.com> Organization: CESNET Date: Sat, 02 Aug 2008 21:07:08 +0200 Message-Id: <1217704028.9157.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFNvIDAyLiAwOC4gMjAwOCB2IDExOjU4IC0wNzAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IEhpLAo+ID4gCj4gPiBpbiBSRUxBWCBORywgbXVsdGlw bGUgcGF0dGVybnMgYXJlIEFORGVkOgo+ID4gCj4gPiBodHRwOi8vd3d3LnJlbGF4bmcub3JnL3hz ZC0yMDAxMDkwNy5odG1sI0lEQU1EWVIKPiA+IAo+ID4gVGhpcyB3YXMgYWNjZXB0ZWQgaW4gb3Jk ZXIgdG8gaGF2ZSB0aGUgZnVuY3Rpb25hbGl0eSBhdmFpbGFibGUgaW4gWFNELAo+ID4gc2VlCj4g PiBodHRwOi8vbGlzdHMub2FzaXMtb3Blbi5vcmcvYXJjaGl2ZXMvcmVsYXgtbmcvMjAwMTA1L21z ZzAwMjExLmh0bWwKPiA+IAo+ID4gSSBndWVzcyB0aGUgaXNzdWUgZm9yIFlBTkcgaXM6IElzIHRo ZXJlIGEgd2F5IGZvciBBTkRpbmcgcGF0dGVybnM/IElmCj4gPiBub3QsIEknZCBzdWdnZXN0IHRv IGZvbGxvdyB0aGUgUkVMQVggTkcgd2F5Lgo+ID4KPiAKPiBZZXMgdGhlcmUgYWxyZWFkeSBpcyBh IHdheSB0byBBTkQgcGF0dGVybnMgd2l0aCBtdWx0aXBsZQo+IHR5cGVkZWZzLiAgWW91IGNhbiBh bHNvIHNwbGl0IHVwIHBhdHRlcm4gc3RyaW5ncyBpbnRvCgpGaW5lLCB0aGVuIEkgYWdyZWUgdG8g bGVhdmUgaXQgYXMgaXQgaXMgbm93LgoKPiBhcyBtYW55IGxpbmVzIGFuZCBmcmFnbWVudHMgYXMg eW91IHdhbnQuCgpEbyB5b3UgbWVhbiB1c2luZyB0aGUgc3RhbmRhcmQgWUFORyBjb25jYXRlbmF0 aW9uIG9mIHN0cmluZ3MKJy4uLicgKyAnLi4uJyA/CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGth LCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Sat Aug 2 12:09:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779693A65A5; Sat, 2 Aug 2008 12:09:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347903A65A5 for ; Sat, 2 Aug 2008 12:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.561 X-Spam-Level: X-Spam-Status: No, score=0.561 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5EInQMueRtk for ; Sat, 2 Aug 2008 12:09:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6EA673A6A0F for ; Sat, 2 Aug 2008 12:09:02 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C880CD800C0 for ; Sat, 2 Aug 2008 21:09:17 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080801102824.GA4873@elstar.local> References: <20080801102824.GA4873@elstar.local> Organization: CESNET Date: Sat, 02 Aug 2008 21:09:17 +0200 Message-Id: <1217704157.9157.29.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFDDoSAwMS4gMDguIDIwMDggdiAxMjoyOCAr MDIwMDoKCj4gYW5kIHRoaXMgaXMgd2h5IHRoZSBZQU5HIHRlYW0gaW5pdGlhbGx5IGRlY2lkZWQg dG8gbm90IHN1cHBvcnQKPiBtdWx0aXBsZSBwYXR0ZXJucy4gV2l0aCB0aGlzIGluc2lnaHQsIGl0 IGJlY29tZXMgY2xlYXIgdGhhdCB0aGUKPiBleGFtcGxlIGRpc2N1c3NlZCBpbiB0aGUgdGhyZWFk ICJyYW5nZS9sZW5ndGggYW5kIHBhdHRlcm4gc3RhdGVtZW50cyIKPiBpcyBub3Qgc29sdmFibGUg dW5sZXNzIHdlIGhhbmRsZSBwYXR0ZXJuIGRpZmZlcmVudCB0aGFuIFhTRCAod2hpY2gKCkl0IHNo b3VsZCB0aGVuIGJlIHNvbHZhYmxlIHZpYSB0aGUgbmVzdGVkIHR5cGVkZWZzLgoKTGFkYQoKLS0g CkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0 Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZAo= From netmod-bounces@ietf.org Sat Aug 2 12:21:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F703A6A95; Sat, 2 Aug 2008 12:21:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F213A6AE2 for ; Sat, 2 Aug 2008 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl-vWaZ-b+gs for ; Sat, 2 Aug 2008 12:21:38 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id A25853A6ADA for ; Sat, 2 Aug 2008 12:21:38 -0700 (PDT) Received: (qmail 65319 invoked from network); 2 Aug 2008 19:21:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2008 19:21:45 -0000 X-YMail-OSG: 5f8Uc7kVM1lUQvJEI3qlGEMy2QOD2eIqyzN7Ag82IJTgshYvoV8h.iWnH8c5ZGc5qRZ3bdrj.jS1hCL5wptnvpaXo3.1OckanFcbuK0nAAyzWpRMtRQ4tBV9HreY9D8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4894B3C7.1000706@netconfcentral.com> Date: Sat, 02 Aug 2008 12:21:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <20080801102824.GA4873@elstar.local> <1217702626.9157.21.camel@missotis> <4894AE39.5010001@netconfcentral.com> <1217704028.9157.26.camel@missotis> In-Reply-To: <1217704028.9157.26.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTbyAwMi4gMDgu IDIwMDggdiAxMTo1OCAtMDcwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pj4gSGksCj4+ Pgo+Pj4gaW4gUkVMQVggTkcsIG11bHRpcGxlIHBhdHRlcm5zIGFyZSBBTkRlZDoKPj4+Cj4+PiBo dHRwOi8vd3d3LnJlbGF4bmcub3JnL3hzZC0yMDAxMDkwNy5odG1sI0lEQU1EWVIKPj4+Cj4+PiBU aGlzIHdhcyBhY2NlcHRlZCBpbiBvcmRlciB0byBoYXZlIHRoZSBmdW5jdGlvbmFsaXR5IGF2YWls YWJsZSBpbiBYU0QsCj4+PiBzZWUKPj4+IGh0dHA6Ly9saXN0cy5vYXNpcy1vcGVuLm9yZy9hcmNo aXZlcy9yZWxheC1uZy8yMDAxMDUvbXNnMDAyMTEuaHRtbAo+Pj4KPj4+IEkgZ3Vlc3MgdGhlIGlz c3VlIGZvciBZQU5HIGlzOiBJcyB0aGVyZSBhIHdheSBmb3IgQU5EaW5nIHBhdHRlcm5zPyBJZgo+ Pj4gbm90LCBJJ2Qgc3VnZ2VzdCB0byBmb2xsb3cgdGhlIFJFTEFYIE5HIHdheS4KPj4+Cj4+IFll cyB0aGVyZSBhbHJlYWR5IGlzIGEgd2F5IHRvIEFORCBwYXR0ZXJucyB3aXRoIG11bHRpcGxlCj4+ IHR5cGVkZWZzLiAgWW91IGNhbiBhbHNvIHNwbGl0IHVwIHBhdHRlcm4gc3RyaW5ncyBpbnRvCj4g Cj4gRmluZSwgdGhlbiBJIGFncmVlIHRvIGxlYXZlIGl0IGFzIGl0IGlzIG5vdy4KPiAKCm1lIHRv byAtLSBpdCBpcyBjb21wYXRpYmxlIHdpdGggYm90aCBYU0QgYW5kIFJORyBhcy1pcy4KCj4+IGFz IG1hbnkgbGluZXMgYW5kIGZyYWdtZW50cyBhcyB5b3Ugd2FudC4KPiAKPiBEbyB5b3UgbWVhbiB1 c2luZyB0aGUgc3RhbmRhcmQgWUFORyBjb25jYXRlbmF0aW9uIG9mIHN0cmluZ3MKPiAnLi4uJyAr ICcuLi4nID8KPiAKCnllcyAtLSB5b3UgY2FuIGV2ZW4gcHV0IGNvbW1lbnRzIGJldHdlZW4gdGhl IHBpZWNlcy4KSU1PLCB0aGlzIGlzIGdvb2QgZW5vdWdoLiAgTXVsdGlwbGUgZXJyb3JzLCBkZXNj cmlwdGlvbnMsCmFuZCByZWZlcmVuY2VzIGZvciBvbmUgcGF0dGVybiBzZWVtcyBleGNlc3NpdmUu CkRvZXMgdGhlIGFwcC1kZXZlbG9wZXIgcmVhbGx5IG5lZWQgdG8ga25vdyB3aGljaAphcmJpdHJh cnkgcGF0dGVybiBmcmFnbWVudCBjYXVzZWQgdGhlIGVycm9yPwoKCj4gTGFkYQo+IAoKQW5keQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1h aWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sat Aug 2 12:52:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6BF3A67FE; Sat, 2 Aug 2008 12:52:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19473A67FE for ; Sat, 2 Aug 2008 12:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yla3dxt-aUv for ; Sat, 2 Aug 2008 12:52:29 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id EECC83A659B for ; Sat, 2 Aug 2008 12:52:28 -0700 (PDT) Received: (qmail 80974 invoked from network); 2 Aug 2008 19:52:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2008 19:52:51 -0000 X-YMail-OSG: MW7QrHYVM1n.IhmGFDiXrNpkZ.ogQnl6_1hkaZEzdZW6spLEyajP0LQ9C7Iy_HV1tCiDPlwNarx1tE0DoFTCAU_ewm23SLUo7IE26eHDFw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4894BB11.5000409@netconfcentral.com> Date: Sat, 02 Aug 2008 12:52:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] NETMOD Life-cycle document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The WG keeps mentioning that there is a need to define the YANG change control rules, but so far, not much. IMO, this is a fairly critical document for the usefulness of YANG as a standard. It also seems that the needs of interoperability and the needs of vendors to 'be flexible' are moving towards a head-on collision at some point. One way to deal with that is a separate document defining how YANG modules are used in IETF documents. The entire module life-cycle needs to be addressed for IETF purposes. For example, how will interoperability be measured for the purposes of standards track advancement? What is allowed to change over time? What is considered a change? (e.g., extension usage change ignored?) What clauses MUST and SHOULD be present? Are there any data modeling BCPs that should be followed? Is there a need for this document, and if so, when is it needed? IMO, some of the assumptions about import-by-revision may be wrong, based on this document, so sooner would be better than later. The language itself does not really need to define how modules are allowed to change over time. Proprietary modules might change in arbitrary ways, but that is up to the vendor. It may be faster to reach consensus on the YANG draft if it does not contain all the change control rules. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 13:45:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD6F3A6862; Sat, 2 Aug 2008 13:45:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492533A68FF for ; Sat, 2 Aug 2008 13:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8PXdIAaG11d for ; Sat, 2 Aug 2008 13:45:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7A2A63A6862 for ; Sat, 2 Aug 2008 13:45:44 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id B813176C252; Sat, 2 Aug 2008 22:46:06 +0200 (CEST) Date: Sat, 02 Aug 2008 22:46:00 +0200 (CEST) Message-Id: <20080802.224600.68135201.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4893C984.2020400@netconfcentral.com> References: <4893C984.2020400@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] module revision and source X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > 1) module revision > > I did not hear if revision-stmt is now mandatory or not. My take on this is that it's obvious that regardless of what the YANG spec says, IETF will require a revision for IETF modules. I think it should be mandatory in YANG only if it is necessary - for example if we do import by revision. So I would rather not decide on this particular issue stand-alone. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 13:58:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF9B3A67EB; Sat, 2 Aug 2008 13:58:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B333A6957 for ; Sat, 2 Aug 2008 13:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhLD9j0eXqLZ for ; Sat, 2 Aug 2008 13:58:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 340C83A67EB for ; Sat, 2 Aug 2008 13:58:44 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B48276C252; Sat, 2 Aug 2008 22:59:07 +0200 (CEST) Date: Sat, 02 Aug 2008 22:59:07 +0200 (CEST) Message-Id: <20080802.225907.84658836.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48933C80.1060300@netconfcentral.com> References: <48933C80.1060300@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > One example, namespace URIs: > I am with the camp that sets this field once for a module, > and never changes it -- ever. This has always been the intention. But since we don't have the change control rules written down in the spec yet, it's not obvious. So I guess I agree with you that the change control rules are really needed. > Another example, yang-types: > I do not understand why I need ZeroBasedCounter32 from > smidump -f yang, zero-based-counter32 from yang-types, > and I can't use this type at all in SMI-to-XSD. I strongly > suggest gaining control of the data type landscape > sooner rather than later. I hope Juergen's plan > of documenting all the differences in yang-types is good > enough. I agree that encodings should favor XML tools, > not legacy SMI tools, but what do the DM readers really > gain by having duplicates of Counter32? > > I understand the need to get data types in use before > NETMOD is done. I suggest that the highly integrated > approach in smidump be followed. For immediate standards > purposes, that simply means use the correct names and > modules. > > Instead of importing counter32 from yang-types, I would > rather import Counter32 from SNMPv2-SMI. Do you suggest that we should write a standards track document that specifies how SMIv2 is translated into YANG? If we don't have such a standard translation I don't see how a standard YANG module can import SNMPv2-SMI (or any other module). > I hope Juergen's plan > of documenting all the differences in yang-types is good > enough. That's my hope as well. Then when we eventually do write SMIv2->YANG rules, Counter32 can be translated into yang:counter23. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 14:09:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622053A688A; Sat, 2 Aug 2008 14:09:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5823A6A51 for ; Sat, 2 Aug 2008 14:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRMTg02P+ncF for ; Sat, 2 Aug 2008 14:09:22 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id A52403A688A for ; Sat, 2 Aug 2008 14:09:22 -0700 (PDT) Received: (qmail 97641 invoked from network); 2 Aug 2008 21:09:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2008 21:09:44 -0000 X-YMail-OSG: hJDBZRYVM1lfYmQ3X4oopDVP58hbKy0t4gzHIi_dm1FrlbCF9pGGmdMBOyHaF2Oge2J.IHgvOLDYpZa3CfnChXXr4JAS2iEfy_wbNbhaMQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4894CD16.7090802@netconfcentral.com> Date: Sat, 02 Aug 2008 14:09:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48933C80.1060300@netconfcentral.com> <20080802.225907.84658836.mbj@tail-f.com> In-Reply-To: <20080802.225907.84658836.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> One example, namespace URIs: >> I am with the camp that sets this field once for a module, >> and never changes it -- ever. > > This has always been the intention. But since we don't have the > change control rules written down in the spec yet, it's not obvious. > So I guess I agree with you that the change control rules are really > needed. > > >> Another example, yang-types: >> I do not understand why I need ZeroBasedCounter32 from >> smidump -f yang, zero-based-counter32 from yang-types, >> and I can't use this type at all in SMI-to-XSD. I strongly >> suggest gaining control of the data type landscape >> sooner rather than later. I hope Juergen's plan >> of documenting all the differences in yang-types is good >> enough. I agree that encodings should favor XML tools, >> not legacy SMI tools, but what do the DM readers really >> gain by having duplicates of Counter32? >> >> I understand the need to get data types in use before >> NETMOD is done. I suggest that the highly integrated >> approach in smidump be followed. For immediate standards >> purposes, that simply means use the correct names and >> modules. >> >> Instead of importing counter32 from yang-types, I would >> rather import Counter32 from SNMPv2-SMI. > > Do you suggest that we should write a standards track document that > specifies how SMIv2 is translated into YANG? If we don't have such a > standard translation I don't see how a standard YANG module can import > SNMPv2-SMI (or any other module). > No. I am suggesting that the selected SMI data types be translated to YANG in modules that mimic their SMI location, instead of lumping them in a new namespace and a new module. >> I hope Juergen's plan >> of documenting all the differences in yang-types is good >> enough. > > That's my hope as well. Then when we eventually do write SMIv2->YANG > rules, Counter32 can be translated into yang:counter23. > I do not see the need to rename Counter32 to counter32, etc. There could be a SNMPv2-SMI.yang that was faithful to the SMIv2 base types in semantics and syntax, and used the SMIv2 names. The types that are different than SMIv2 for whatever reason would stay in yang-types, inet-types, etc. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 14:26:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD7A3A6905; Sat, 2 Aug 2008 14:26:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E482928B56A for ; Sat, 2 Aug 2008 14:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOCBKqMN4-uX for ; Sat, 2 Aug 2008 14:26:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2A2D53A6A50 for ; Sat, 2 Aug 2008 14:25:23 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 92A6676C252; Sat, 2 Aug 2008 23:25:46 +0200 (CEST) Date: Sat, 02 Aug 2008 23:25:41 +0200 (CEST) Message-Id: <20080802.232541.258237546.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4894BB11.5000409@netconfcentral.com> References: <4894BB11.5000409@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD Life-cycle document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > It also seems that the needs of interoperability and > the needs of vendors to 'be flexible' are moving > towards a head-on collision at some point. > One way to deal with that is a separate document > defining how YANG modules are used in IETF documents. I like this approach. But I will have to think some more. We all know that regardless of which upgrade rules we add, some vendors will break them for their vendor-specific modules. That happens with SNMP modules all the time. SomeMost vendors want to be be good citizens, but they can follow the IETF rules. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 17:13:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677843A6A07; Sat, 2 Aug 2008 17:13:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC82A3A68D8 for ; Sat, 2 Aug 2008 17:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLIv9w6FklIw for ; Sat, 2 Aug 2008 17:13:29 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 2E6A43A6A07 for ; Sat, 2 Aug 2008 17:13:28 -0700 (PDT) Received: (qmail 5863 invoked from network); 3 Aug 2008 00:13:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 3 Aug 2008 00:13:50 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4894F83D.4020107@netconfcentral.com> Date: Sat, 02 Aug 2008 17:13:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <4894BB11.5000409@netconfcentral.com> <20080802.232541.258237546.mbj@tail-f.com> In-Reply-To: <20080802.232541.258237546.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD Life-cycle document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> It also seems that the needs of interoperability and >> the needs of vendors to 'be flexible' are moving >> towards a head-on collision at some point. >> One way to deal with that is a separate document >> defining how YANG modules are used in IETF documents. > > I like this approach. But I will have to think some more. We all > know that regardless of which upgrade rules we add, some vendors will > break them for their vendor-specific modules. That happens with SNMP > modules all the time. > > SomeMost vendors want to be be good citizens, but they can > follow the IETF rules. > That is why I think keeping as many CLRs out of the official language specification is a good idea. It also divides complexity and allows the language spec to remain more stable during the early years when the change control rules for YANG are not as well understood as the basic constructs themselves. I came up with a lot of specifics while writing yangdiff, but I'll save the details for later. Sometimes, simply recognizing semantic equivalence is not so easy. > > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 2 18:38:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA0D3A67DD; Sat, 2 Aug 2008 18:38:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6284C3A6A20 for ; Sat, 2 Aug 2008 18:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2sTA0adG5il for ; Sat, 2 Aug 2008 18:38:29 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 875C93A688B for ; Sat, 2 Aug 2008 18:38:29 -0700 (PDT) Received: (qmail 6200 invoked from network); 3 Aug 2008 01:38:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 3 Aug 2008 01:38:51 -0000 X-YMail-OSG: .XzDG8UVM1m3C6Q_VBfFpwSjJMKgCoL9Cyjtq76OXJhGoWd.Li4.flhj0PkE0s9HujZi_pf2BPotvxYSSVQWaqD6igLTKlokXiNDtrYelQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48950C29.8030402@netconfcentral.com> Date: Sat, 02 Aug 2008 18:38:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <4893C984.2020400@netconfcentral.com> <20080802.224600.68135201.mbj@tail-f.com> In-Reply-To: <20080802.224600.68135201.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] module revision and source X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> 1) module revision >> >> I did not hear if revision-stmt is now mandatory or not. > > My take on this is that it's obvious that regardless of what the YANG > spec says, IETF will require a revision for IETF modules. I think it > should be mandatory in YANG only if it is necessary - for example if > we do import by revision. So I would rather not decide on this > particular issue stand-alone. > > There are several categories of Clever Little Rules that one can define for NETMOD (not a complete list obviously): 1) needed for the language to work: - set of prefixes used within a module must be unique - set of module names to be unique 2) needed for the mapping to XML to work: - set of namespace URIs used within an agent needs to be unique - YANG names must be legal XML element names - set of sibling nodes within the same namespace must be unique 3) needed for multi-vendor interoperability: - unique (within the module), ascending revision ID for each module release - data-def-stmt description clauses required - reference clauses whenever relevant - as many machine-readable clauses as relevant 4) needed for the mapping to XSD and DSDL to work: - pattern matching rules - default namespace in XPath 1.0 5) desired for the mapping to XML to favor simpler implementation: - key leaf nodes encoded first in list elements - no deep keys allowed - no XSD list data type - no XML attributes allowed 6) desired for better SMIv2 compatibility: - data type and TEXTUAL-CONVENTION reuse - OBJECT-TYPE and NOTIFICATION-TYPE reuse 7) desired for better security features: - standard instance naming with XPath 8) desired for 'safer' vendor extensibility: - augment guidelines (cannot break the contract, etc.)? - use capabilities to identify a group of extensions defining some feature set > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 3 05:58:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318A63A69D2; Sun, 3 Aug 2008 05:58:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D6F3A69E3 for ; Sun, 3 Aug 2008 05:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0GFzgi8OvjU for ; Sun, 3 Aug 2008 05:58:08 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 36DE03A69D2 for ; Sun, 3 Aug 2008 05:58:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,301,1215403200"; d="scan'208";a="137964962" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 03 Aug 2008 08:58:17 -0400 X-IronPort-AV: E=Sophos;i="4.31,301,1215403200"; d="scan'208";a="242807661" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Aug 2008 08:58:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Aug 2008 14:58:21 +0200 Message-ID: In-Reply-To: <20080802.224600.68135201.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] module revision and source Thread-Index: Acj04M2fonWGVwEXQJaNXrhHz155swAhsE/Q References: <4893C984.2020400@netconfcentral.com> <20080802.224600.68135201.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" , Cc: netmod@ietf.org Subject: Re: [netmod] module revision and source X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Saturday, August 02, 2008 11:46 PM > To: andy@netconfcentral.com > Cc: netmod@ietf.org > Subject: Re: [netmod] module revision and source > > Andy Bierman wrote: > > Hi, > > > > 1) module revision > > > > I did not hear if revision-stmt is now mandatory or not. > > My take on this is that it's obvious that regardless of what > the YANG spec says, IETF will require a revision for IETF > modules. I think it should be mandatory in YANG only if it > is necessary - for example if we do import by revision. So > I would rather not decide on this particular issue stand-alone. > > > /martin This was one of the instances where I was surprised by the arguments in the discussions last Friday. I hope that all participants in the NETMOD effort are aware about the discussions about SMIv2->XSD translations vs. SMIv2->YANG->XSD translations and such. Even if REVISION clauses do not directly generate XML, it is obvious that we need to define a revision-stmt to be mandatory, even if it was only for compatibility of translation and comparison of versioning. As a more general statement I would suggest that without entering in limitations where it makes no sense, design decisions take SMIv2 compatibility as one of the principal objectives in YANG. Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 3 10:28:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECD43A69B3; Sun, 3 Aug 2008 10:28:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332B43A6AD1 for ; Sun, 3 Aug 2008 10:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JwkXESrqNmU for ; Sun, 3 Aug 2008 10:28:57 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 6D8013A6999 for ; Sun, 3 Aug 2008 10:28:57 -0700 (PDT) Received: (qmail 64834 invoked from network); 3 Aug 2008 17:29:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 3 Aug 2008 17:29:21 -0000 X-YMail-OSG: _gYTcZIVM1llQZ1zY2w_h_iHKdimbzbpRhQRj9NpgK2Db4rz0SzAxbc_H_9ZvAJyNqPJt_9WMC6q8eddMduqz5b0yjIGHFeEcbR3VxCDVA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4895EAF0.8070709@netconfcentral.com> Date: Sun, 03 Aug 2008 10:29:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4893C984.2020400@netconfcentral.com> <20080802.224600.68135201.mbj@tail-f.com> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] module revision and source X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund >> Sent: Saturday, August 02, 2008 11:46 PM >> To: andy@netconfcentral.com >> Cc: netmod@ietf.org >> Subject: Re: [netmod] module revision and source >> >> Andy Bierman wrote: >>> Hi, >>> >>> 1) module revision >>> >>> I did not hear if revision-stmt is now mandatory or not. >> My take on this is that it's obvious that regardless of what >> the YANG spec says, IETF will require a revision for IETF >> modules. I think it should be mandatory in YANG only if it >> is necessary - for example if we do import by revision. So >> I would rather not decide on this particular issue stand-alone. >> >> >> /martin > > This was one of the instances where I was surprised by the arguments in > the discussions last Friday. I hope that all participants in the NETMOD > effort are aware about the discussions about SMIv2->XSD translations > vs. SMIv2->YANG->XSD translations and such. Even if REVISION clauses do > not directly generate XML, it is obvious that we need to define a > revision-stmt to be mandatory, even if it was only for compatibility of > translation and comparison of versioning. > > As a more general statement I would suggest that without entering in > limitations where it makes no sense, design decisions take SMIv2 > compatibility as one of the principal objectives in YANG. > One limitation: There will no attempt whatsoever to provide for YANG to SMIv2 translation. This is a 1-way bus ride. I am concerned about the long-term coexistence, but mostly at the data type and 'leaf object' level for now. It's not as if this XML data type situation jumped up overnight. XSD and SMIv2 have both existed for a long time. Why is there such urgency now to create a very partial, sub-optimal solution, instead of working on a real solution? Consider the possibility that a multi-protocol application will need to reconcile data from SMIv2 over SNMP, SMIv2 over NETCONF, SMIv2-like over NETCONF, and SMIv2-like2-over-XML. Do you really think this solution approach is going to work in the long-run? Is there any shared vision whatsoever of what the multi-protocol network management end-state even looks like? > Dan > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 3 23:44:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373263A67CC; Sun, 3 Aug 2008 23:44:34 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592423A6817 for ; Sun, 3 Aug 2008 23:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNQET8siFWMk for ; Sun, 3 Aug 2008 23:44:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 915F13A67CC for ; Sun, 3 Aug 2008 23:44:32 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 30321D800BD for ; Mon, 4 Aug 2008 08:44:59 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080802.225907.84658836.mbj@tail-f.com> References: <48933C80.1060300@netconfcentral.com> <20080802.225907.84658836.mbj@tail-f.com> Organization: CESNET Date: Mon, 04 Aug 2008 08:44:58 +0200 Message-Id: <1217832298.6212.14.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTbyAwMi4gMDguIDIwMDggdiAyMjo1OSArMDIwMDoK PiBBbmR5IEJpZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPiB3cm90ZToKPiA+IE9uZSBl eGFtcGxlLCBuYW1lc3BhY2UgVVJJczoKPiA+IEkgYW0gd2l0aCB0aGUgY2FtcCB0aGF0IHNldHMg dGhpcyBmaWVsZCBvbmNlIGZvciBhIG1vZHVsZSwKPiA+IGFuZCBuZXZlciBjaGFuZ2VzIGl0IC0t IGV2ZXIuCj4gCj4gVGhpcyBoYXMgYWx3YXlzIGJlZW4gdGhlIGludGVudGlvbi4gIEJ1dCBzaW5j ZSB3ZSBkb24ndCBoYXZlIHRoZQoKVGhpcyBhcHByb2FjaCBoYXMgdHdvIHJlbGF0ZWQgZHJhd2Jh Y2tzOgoKMS4gTkVUQ09ORiBoZWxsbyBtZXNzYWdlIGNhcnJpZXMgVVJJcywgc28gaWYgYSBVUkkg dW5pcXVlbHkgaWRlbnRpZmllcwp0aGUgZGF0YSBtb2RlbCwgdGhpcyBpcyBhbGwgd2hhdCdzIG5l ZWRlZC4gQW5vdGhlciBtZXRob2Qgd2lsbCBoYXZlIHRvCmJlIGludmVudGVkIGluIG9yZGVyIHRv IGNvbW11bmljYXRlIHRoZSByZXZpc2lvbiBiZXR3ZWVuIHRoZSBhZ2VudCBhbmQKbWFuYWdlci4K CjIuIFRoZSBuYW1lc3BhY2UgVVJJIHdpbGwgYmUgcHJlc2VudCBpbiBhbGwgaW5zdGFuY2UgWE1M IGRvY3VtZW50cyBzdWNoCmFzIE5FVENPTkYgUERVIHdoZXJlYXMgdGhlIHJldmlzaW9uIHN0cmlu ZyBjdXJyZW50bHkgbmVlZG4ndCBiZS4KCldoeSBpcyBpdCBhIHByb2JsZW0gdG8gaGF2ZSB0aGUg bmFtZXNwYWNlIFVSSSBhcyB0aGUgb25seSBvbmUgaWRlbnRpZmllcgpvZiB0aGUgZGF0YSBtb2Rl bCwgaW5jbHVkaW5nIGl0cyB2ZXJzaW9uPwoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VT TkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Aug 4 03:26:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E373A6AE0; Mon, 4 Aug 2008 03:26:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B363A6BEF for ; Mon, 4 Aug 2008 03:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5GjQ7UgR5jb for ; Mon, 4 Aug 2008 03:26:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 496743A6AE0 for ; Mon, 4 Aug 2008 03:26:27 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7FA40D800BD for ; Mon, 4 Aug 2008 12:26:54 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Mon, 04 Aug 2008 12:26:54 +0200 Message-Id: <1217845614.6212.57.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, here is the relevant text from Section 2.3 of XPath 1.0 recommendation (http://www.w3.org/TR/xpath#node-tests): "if the QName does not have a prefix, then the namespace URI is null" The YANG draft says: "The null namespace is defined to be the namespace of the current module". I understand this was an attempt to avoid the XPath requirement to write explicit namespace prefixes but IMO it is not acceptable. It is the same like defining empty set to contain something. Null namespace means NO namespace. >From the practical POV, the XPath expressions found in must statements will never work (unmodified) in validation tools such as XSLT processors. Therefore, I think it is absolutely necessary to follow the XPath spec and remove the redefinition of null namespace. This means that node names in must expressions will always have to have a NS prefix. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 06:54:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC91E28C2A1; Mon, 4 Aug 2008 06:54:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6B128C2A6 for ; Mon, 4 Aug 2008 06:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrV+bwbcwEBd for ; Mon, 4 Aug 2008 06:54:01 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 356B528C2A1 for ; Mon, 4 Aug 2008 06:54:00 -0700 (PDT) Received: (qmail 18514 invoked from network); 4 Aug 2008 13:54:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2008 13:54:23 -0000 X-YMail-OSG: JCSTgyIVM1nvVeo5ynumQK9lBOZLi0R0r9bP62mWrwJRjpHwFgJ3gGvCmQq5xej_9cnyXDTtx7Q6uPyI8Fi.1Zn4ttfKqeycC1DB9JxQgf5JJaZTKiRYhG9hcbZ9HYFVh2u53b1exW.jKlpRkA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48970A0D.20702@netconfcentral.com> Date: Mon, 04 Aug 2008 06:54:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <1217845614.6212.57.camel@missotis> In-Reply-To: <1217845614.6212.57.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > here is the relevant text from Section 2.3 of XPath 1.0 recommendation > (http://www.w3.org/TR/xpath#node-tests): > > "if the QName does not have a prefix, then the namespace URI is null" > > The YANG draft says: > > "The null namespace is defined to be the namespace of the current > module". > > I understand this was an attempt to avoid the XPath requirement to write > explicit namespace prefixes but IMO it is not acceptable. It is the same > like defining empty set to contain something. Null namespace means NO > namespace. > >>From the practical POV, the XPath expressions found in must statements > will never work (unmodified) in validation tools such as XSLT > processors. > > Therefore, I think it is absolutely necessary to follow the XPath spec > and remove the redefinition of null namespace. This means that node > names in must expressions will always have to have a NS prefix. > Phil suggested that the YANG compiler can add the missing prefix back into the expression, before processing it with XSLT. Since XSLT cannot possibly process a 'raw' YANG file at all, this seems reasonable. I'm not sure you understand the purpose of the human-friendly language form. We either teach one tool how to adapt to human needs, or we teach all the humans how to adapt to the the tool's needs. > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 06:59:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356163A6CAD; Mon, 4 Aug 2008 06:59:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9320F3A6C9D for ; Mon, 4 Aug 2008 06:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRm2wHoDjClK for ; Mon, 4 Aug 2008 06:59:00 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CED403A6CBD for ; Mon, 4 Aug 2008 06:58:59 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m74DxPhq008351 for ; Mon, 4 Aug 2008 08:59:26 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 16:59:03 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 16:58:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 16:58:53 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Representation of instance identifiers Thread-Index: Acj2OjrRpZt0ynLeSLy/kf7oIxTqIg== From: To: X-OriginalArrivalTime: 04 Aug 2008 13:58:53.0980 (UTC) FILETIME=[3B1495C0:01C8F63A] X-Nokia-AV: Clean Subject: [netmod] Representation of instance identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Everybody, in the NETMOD session last Thursday when Martin B. gave an overview about YANG features, I'll also touched the issue of the XML representation of an instance identifier and was suggesting a different, XML element based representation, which I'm going to describe here. In the YANG spec it is currently stated that the instance identifier is encoded as XPath expression: "The syntax for an instance-identifier is a subset of the XPath syntax, which is used to uniquely identify a node in the data tree. It is an absolute XPath location path in abbreviated syntax, where axes are not permitted, and predicates are used only for specifying the values for the key nodes for list entries, or a value of a leaf- list. Each predicate consists of one equality test per key. Each key MUST have a corresponding predicate. Imho, this way of encoding an instance identifier is a bit to much biased in direction of readability but makes creating and parsing instance identifiers harder as actually needed (see below). Therefore I would like to suggest another approach of encoding an instance identifier, which uses an XML elements. - For every node in the location path an XML element with that node name is created in the containing XML element (lead-(list) element) - In case the node in the location path is a list - a sub-element for every key is created - that contains the key value as text For example the path "/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']" (YANG spec example) would be represented as 192.0.2.1 80 The XPath notation is of course shorter and more easy to read for humans. But this XPath expressions do not appear in the model but in NETCONF payload. And this is (mostly) processed by machines. * So for a NETCONF agent or manager to make use out of an XPath expression it has to first parse it. That means the agent / manager has to have an XPath expression scanner / parser available that does this job - which could mean extra implementation respectively integration effort. E.g. in the Java 5 platform you have built-in functionality for executing Xpath expression on an XML Input source. But that does help too much when the referred instance is currently only represented in a internal (non-XML) representation (as the referred entity might not be part of the XML payload of the actual NETCONF PDU) * Also encoding instance reference relying on key values in form of XPath expressions could be sometimes a bit of a challenge as the quotation mechanism of XPath is a bit limited afaics (see XPath http://www.w3.org/TR/xpath#strings, 3.7 [29]. Consider an e-mail address like "John O'Conner"@example.ie This is unusual but valid (see RFC 3696). Assuming that a node in a list of subscribers where the e-mail address is the key must be identified by that value. How do you quote it as part of an XPath expression? Neither the single-quote form nor the double-quote form work in that example. Having the identifier location path encoded in form of XML elements as suggested above means - that the job of encoding is simple and can be done by only using the XML node tree creation API that is anyway used - the job of correctly encoding / quoting key values is done by the XML processor - the job of parsing the elements of the instance identifier locating path is done by the XML parser that is anyway used - the job of decoding key values is done by the XML parser - no need to implement / embed a XPath expression parser for this purpose As this is even the only place where XPath expressions are used in the NETCONG payload afaics, or...? So what do you think, wouldn't be an XML element based representation of instance identifiers be the easier, simpler solution? Best wishes, Bernd _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 07:27:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CF228C2B9; Mon, 4 Aug 2008 07:27:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6ED28C2B9 for ; Mon, 4 Aug 2008 07:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDpfnkEuA7rP for ; Mon, 4 Aug 2008 07:27:26 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id DDB0D28C2B4 for ; Mon, 4 Aug 2008 07:27:26 -0700 (PDT) Received: (qmail 90333 invoked from network); 4 Aug 2008 14:27:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 4 Aug 2008 14:27:53 -0000 X-YMail-OSG: 5DIakVgVM1kxiXwICEdECP.6uqc1zVnTU1rUtnISq8Veqlq6g_B2WTFqdZfjwSdcY2j_F2ZeJKFJinbL_j5SjhsVXBouThUThynJyffd0Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489711E8.4050608@netconfcentral.com> Date: Mon, 04 Aug 2008 07:27:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <48933C80.1060300@netconfcentral.com> <20080802.225907.84658836.mbj@tail-f.com> <1217832298.6212.14.camel@missotis> In-Reply-To: <1217832298.6212.14.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IE1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgU28gMDIu IDA4LiAyMDA4IHYgMjI6NTkgKzAyMDA6Cj4+IEFuZHkgQmllcm1hbiA8YW5keUBuZXRjb25mY2Vu dHJhbC5jb20+IHdyb3RlOgo+Pj4gT25lIGV4YW1wbGUsIG5hbWVzcGFjZSBVUklzOgo+Pj4gSSBh bSB3aXRoIHRoZSBjYW1wIHRoYXQgc2V0cyB0aGlzIGZpZWxkIG9uY2UgZm9yIGEgbW9kdWxlLAo+ Pj4gYW5kIG5ldmVyIGNoYW5nZXMgaXQgLS0gZXZlci4KPj4gVGhpcyBoYXMgYWx3YXlzIGJlZW4g dGhlIGludGVudGlvbi4gIEJ1dCBzaW5jZSB3ZSBkb24ndCBoYXZlIHRoZQo+IAo+IFRoaXMgYXBw cm9hY2ggaGFzIHR3byByZWxhdGVkIGRyYXdiYWNrczoKPiAKPiAxLiBORVRDT05GIGhlbGxvIG1l c3NhZ2UgY2FycmllcyBVUklzLCBzbyBpZiBhIFVSSSB1bmlxdWVseSBpZGVudGlmaWVzCj4gdGhl IGRhdGEgbW9kZWwsIHRoaXMgaXMgYWxsIHdoYXQncyBuZWVkZWQuIEFub3RoZXIgbWV0aG9kIHdp bGwgaGF2ZSB0bwo+IGJlIGludmVudGVkIGluIG9yZGVyIHRvIGNvbW11bmljYXRlIHRoZSByZXZp c2lvbiBiZXR3ZWVuIHRoZSBhZ2VudCBhbmQKPiBtYW5hZ2VyLgo+IAo+IDIuIFRoZSBuYW1lc3Bh Y2UgVVJJIHdpbGwgYmUgcHJlc2VudCBpbiBhbGwgaW5zdGFuY2UgWE1MIGRvY3VtZW50cyBzdWNo Cj4gYXMgTkVUQ09ORiBQRFUgd2hlcmVhcyB0aGUgcmV2aXNpb24gc3RyaW5nIGN1cnJlbnRseSBu ZWVkbid0IGJlLgo+IAo+IFdoeSBpcyBpdCBhIHByb2JsZW0gdG8gaGF2ZSB0aGUgbmFtZXNwYWNl IFVSSSBhcyB0aGUgb25seSBvbmUgaWRlbnRpZmllcgo+IG9mIHRoZSBkYXRhIG1vZGVsLCBpbmNs dWRpbmcgaXRzIHZlcnNpb24/Cj4gCgpCZWNhdXNlIHdlIGRvbid0IHdhbnQgdG8gbWFuYWdlIDEw WCBtb3JlIG5hbWVzcGFjZXMgdGhhbgp3ZSByZWFsbHkgbmVlZCwgYW5kIGJlY2F1c2UgdGhlIHJl dmlzaW9uIGRhdGUgaXMgYSBzZXBhcmF0ZQpmaWVsZCB3aXRoIGl0cyBvd24gc2VtYW50aWNzLiAg SSBwcmVmZXIgdXNpbmcgMiBkaXN0aW5jdCBmaWVsZHMKcmF0aGVyIHRoYW4gY3JlYXRlIGEgc3Rh bmRhcmQgZm9ybWF0IGZvciBzdHVmZmluZyBleHRyYSBkYXRhCmludG8gdGhlIG5hbWVzcGFjZSBV UkkuICBTdGFuZGFyZCBtb2R1bGVzIHVzZSBhIFVSTiBmb3JtYXQsIHdoaWxlCnZlbmRvcnMgYXJl IGV4cGVjdGVkIHRvIHVzZSBhIFVSTCBmb3JtYXQuICBUaGUgbmFtZXNwYWNlCmZpZWxkIGlzIG5v dCB1bmlmb3JtbHkgc3RydWN0dXJlZCwgd2hpY2ggaXMgaW50ZW5kZWQgYXMgYSBmZWF0dXJlLgoK PiBMYWRhCj4gCgpBbmR5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Aug 4 07:35:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269E83A6AAC; Mon, 4 Aug 2008 07:35:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54F43A6CCB for ; Mon, 4 Aug 2008 07:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdrupSU7WeQP for ; Mon, 4 Aug 2008 07:34:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 893F33A6C31 for ; Mon, 4 Aug 2008 07:34:33 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 49B58D800C0; Mon, 4 Aug 2008 16:35:01 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48970A0D.20702@netconfcentral.com> References: <1217845614.6212.57.camel@missotis> <48970A0D.20702@netconfcentral.com> Organization: CESNET Date: Mon, 04 Aug 2008 16:35:01 +0200 Message-Id: <1217860502.6212.82.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDA0LiAwOC4gMjAwOCB2IDA2OjU0IC0wNzAwOgo+IAo+ IFBoaWwgc3VnZ2VzdGVkIHRoYXQgdGhlIFlBTkcgY29tcGlsZXIgY2FuIGFkZCB0aGUgbWlzc2lu ZyBwcmVmaXgKPiBiYWNrIGludG8gdGhlIGV4cHJlc3Npb24sIGJlZm9yZSBwcm9jZXNzaW5nIGl0 IHdpdGggWFNMVC4KPiBTaW5jZSBYU0xUIGNhbm5vdCBwb3NzaWJseSBwcm9jZXNzIGEgJ3Jhdycg WUFORyBmaWxlIGF0IGFsbCwKPiB0aGlzIHNlZW1zIHJlYXNvbmFibGUuCgpZZXMsIEkgc3VnZ2Vz dGVkIHRoYXQgdG9vLCBidXQgcGFyc2luZyBsb2dpYyBmb3IgWFBhdGggZXhwcmVzc2lvbnMgd291 bGQKYmUgYW5vdGhlciBjb21wbGV4aXR5IHRvIGJlIGFkZGVkIHRvIHRoZSBZQU5HIHBhcnNlci4K Cj4gCj4gSSdtIG5vdCBzdXJlIHlvdSB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoZQo+IGh1 bWFuLWZyaWVuZGx5IGxhbmd1YWdlIGZvcm0uICBXZSBlaXRoZXIgdGVhY2ggb25lIHRvb2wKPiBo b3cgdG8gYWRhcHQgdG8gaHVtYW4gbmVlZHMsIG9yIHdlIHRlYWNoIGFsbCB0aGUgaHVtYW5zCj4g aG93IHRvIGFkYXB0IHRvIHRoZSB0aGUgdG9vbCdzIG5lZWRzLgoKSSB1bmRlcnN0YW5kIGl0IHZl cnkgd2VsbC4gSG93ZXZlciwgaWYgdGhlIFlBTkcgZHJhZnQgcmVmZXJzIHRvIFhQYXRoLAp0aGVu IGl0IGhhcyB0byBiZSBYUGF0aCAtIGFuZCBwYXJ0IG9mIGl0cyAxLjAgc3RhbmRhcmQgaXMgdGhp cyBoYW5kbGluZwpvZiBuYW1lc3BhY2VzLCB3aGV0aGVyIHlvdSBsaWtlIGl0IG9yIG5vdC4gVGhl IG90aGVyIG9wdGlvbiBpcyB0byBkZWZpbmUKdGhlIHN5bnRheCBvZiBtdXN0IGV4cHJlc3Npb25z IGluIHRoZSBZQU5HIGRyYWZ0IGFuZCBjYWxsIGl0IHNvbWV0aGluZwplbHNlLgoKU28gbXkgcG9p bnQgaXMgdGhhbiBpdCdzIGEgcHJvYmxlbSBmb3IgWUFORyBzcGVjaWZpY2F0aW9uIGFzIHdlbGwu CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBt YWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 4 07:38:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B463A6CC8; Mon, 4 Aug 2008 07:38:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B04C3A6CC8 for ; Mon, 4 Aug 2008 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+GMEOJTzS34 for ; Mon, 4 Aug 2008 07:38:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3B00A3A6CC6 for ; Mon, 4 Aug 2008 07:38:15 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m74Ecg1J028047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 16:38:42 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m74EcgCT021068; Mon, 4 Aug 2008 16:38:42 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 16:38:42 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 16:38:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 17:37:31 +0300 Message-ID: <210412A63D60154898B7CDC3C7172BDE31269D@FIESEXC007.nsn-intra.net> In-Reply-To: <48970A0D.20702@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] XPath expressions in must Thread-Index: Acj2OaT4CsAvAT1aTkWPh46p15d7BAAAFYWQ References: <1217845614.6212.57.camel@missotis> <48970A0D.20702@netconfcentral.com> From: "Lahdensivu, Mikko (NSN - FI/Tampere)" To: "ext Andy Bierman" X-OriginalArrivalTime: 04 Aug 2008 14:38:29.0500 (UTC) FILETIME=[C3002BC0:01C8F63F] Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, >> Therefore, I think it is absolutely necessary to follow the >XPath spec >> and remove the redefinition of null namespace. This means that node >> names in must expressions will always have to have a NS prefix. >> > >Phil suggested that the YANG compiler can add the missing >prefix back into the expression, before processing it with XSLT. >Since XSLT cannot possibly process a 'raw' YANG file at all, >this seems reasonable. > >I'm not sure you understand the purpose of the human-friendly >language form. We either teach one tool how to adapt to human >needs, or we teach all the humans how to adapt to the the tool's needs. > >> Lada >> > >Andy > part of the "human-friendliness" of a language is also about how close it is to existing languages. If it is close, it is easy for reader to get confused about small, distinct behaviour. Integrating an existing language, and modifying its rules slightly, can be worse than a language that is more clearly distinct from other languages. I would consider that if you change the sub-language (xpath) trying to optimize it for the main language (yang), you are requesting people to actually adapt more to the language, than if you would do by keeping the sub-language as it is. The most important aspect of human-friendliness of a language is that people understand it correctly. Also, I hope that by "one tool" you mean just the language itself, not that there wouldn't be multiple independent sets of tools around Yang, which have to, like the people, adapt to the language. Mikko _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 07:44:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4151628C27F; Mon, 4 Aug 2008 07:44:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E945A28C292 for ; Mon, 4 Aug 2008 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+wQnpljOyou for ; Mon, 4 Aug 2008 07:44:49 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C371328C263 for ; Mon, 4 Aug 2008 07:44:48 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C907B20794; Mon, 4 Aug 2008 16:45:12 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-dd-489715f846d6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A54D820854; Mon, 4 Aug 2008 16:45:12 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 16:45:12 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 16:45:12 +0200 Message-ID: <48970177.1010005@ericsson.com> Date: Mon, 04 Aug 2008 15:17:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <1217845614.6212.57.camel@missotis> <48970A0D.20702@netconfcentral.com> In-Reply-To: <48970A0D.20702@netconfcentral.com> X-OriginalArrivalTime: 04 Aug 2008 14:45:12.0203 (UTC) FILETIME=[B307C5B0:01C8F640] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I vote for Andy's interpretation. Balazs Andy Bierman wrote: > Ladislav Lhotka wrote: >> Hi, >> >> here is the relevant text from Section 2.3 of XPath 1.0 recommendation >> (http://www.w3.org/TR/xpath#node-tests): >> >> "if the QName does not have a prefix, then the namespace URI is null" >> >> The YANG draft says: >> >> "The null namespace is defined to be the namespace of the current >> module". >> >> I understand this was an attempt to avoid the XPath requirement to write >> explicit namespace prefixes but IMO it is not acceptable. It is the same >> like defining empty set to contain something. Null namespace means NO >> namespace. >> >>> From the practical POV, the XPath expressions found in must statements >> will never work (unmodified) in validation tools such as XSLT >> processors. >> >> Therefore, I think it is absolutely necessary to follow the XPath spec >> and remove the redefinition of null namespace. This means that node >> names in must expressions will always have to have a NS prefix. >> > > Phil suggested that the YANG compiler can add the missing prefix > back into the expression, before processing it with XSLT. > Since XSLT cannot possibly process a 'raw' YANG file at all, > this seems reasonable. > > I'm not sure you understand the purpose of the > human-friendly language form. We either teach one tool > how to adapt to human needs, or we teach all the humans > how to adapt to the the tool's needs. > >> Lada >> > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 07:51:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3945728C2BD; Mon, 4 Aug 2008 07:51:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7526B28C2CA for ; Mon, 4 Aug 2008 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuU4VS-bAZD5 for ; Mon, 4 Aug 2008 07:51:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9FDCD28C2BD for ; Mon, 4 Aug 2008 07:51:54 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DD0DED800C0 for ; Mon, 4 Aug 2008 16:52:17 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <489711E8.4050608@netconfcentral.com> References: <48933C80.1060300@netconfcentral.com> <20080802.225907.84658836.mbj@tail-f.com> <1217832298.6212.14.camel@missotis> <489711E8.4050608@netconfcentral.com> Organization: CESNET Date: Mon, 04 Aug 2008 16:52:18 +0200 Message-Id: <1217861538.6212.91.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDA0LiAwOC4gMjAwOCB2IDA3OjI3IC0wNzAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IE1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgU28gMDIu IDA4LiAyMDA4IHYgMjI6NTkgKzAyMDA6Cj4gPj4gQW5keSBCaWVybWFuIDxhbmR5QG5ldGNvbmZj ZW50cmFsLmNvbT4gd3JvdGU6Cj4gPj4+IE9uZSBleGFtcGxlLCBuYW1lc3BhY2UgVVJJczoKPiA+ Pj4gSSBhbSB3aXRoIHRoZSBjYW1wIHRoYXQgc2V0cyB0aGlzIGZpZWxkIG9uY2UgZm9yIGEgbW9k dWxlLAo+ID4+PiBhbmQgbmV2ZXIgY2hhbmdlcyBpdCAtLSBldmVyLgo+ID4+IFRoaXMgaGFzIGFs d2F5cyBiZWVuIHRoZSBpbnRlbnRpb24uICBCdXQgc2luY2Ugd2UgZG9uJ3QgaGF2ZSB0aGUKPiA+ IAo+ID4gVGhpcyBhcHByb2FjaCBoYXMgdHdvIHJlbGF0ZWQgZHJhd2JhY2tzOgo+ID4gCj4gPiAx LiBORVRDT05GIGhlbGxvIG1lc3NhZ2UgY2FycmllcyBVUklzLCBzbyBpZiBhIFVSSSB1bmlxdWVs eSBpZGVudGlmaWVzCj4gPiB0aGUgZGF0YSBtb2RlbCwgdGhpcyBpcyBhbGwgd2hhdCdzIG5lZWRl ZC4gQW5vdGhlciBtZXRob2Qgd2lsbCBoYXZlIHRvCj4gPiBiZSBpbnZlbnRlZCBpbiBvcmRlciB0 byBjb21tdW5pY2F0ZSB0aGUgcmV2aXNpb24gYmV0d2VlbiB0aGUgYWdlbnQgYW5kCj4gPiBtYW5h Z2VyLgo+ID4gCj4gPiAyLiBUaGUgbmFtZXNwYWNlIFVSSSB3aWxsIGJlIHByZXNlbnQgaW4gYWxs IGluc3RhbmNlIFhNTCBkb2N1bWVudHMgc3VjaAo+ID4gYXMgTkVUQ09ORiBQRFUgd2hlcmVhcyB0 aGUgcmV2aXNpb24gc3RyaW5nIGN1cnJlbnRseSBuZWVkbid0IGJlLgo+ID4gCj4gPiBXaHkgaXMg aXQgYSBwcm9ibGVtIHRvIGhhdmUgdGhlIG5hbWVzcGFjZSBVUkkgYXMgdGhlIG9ubHkgb25lIGlk ZW50aWZpZXIKPiA+IG9mIHRoZSBkYXRhIG1vZGVsLCBpbmNsdWRpbmcgaXRzIHZlcnNpb24/Cj4g PiAKPiAKPiBCZWNhdXNlIHdlIGRvbid0IHdhbnQgdG8gbWFuYWdlIDEwWCBtb3JlIG5hbWVzcGFj ZXMgdGhhbgo+IHdlIHJlYWxseSBuZWVkLCBhbmQgYmVjYXVzZSB0aGUgcmV2aXNpb24gZGF0ZSBp cyBhIHNlcGFyYXRlCj4gZmllbGQgd2l0aCBpdHMgb3duIHNlbWFudGljcy4gIEkgcHJlZmVyIHVz aW5nIDIgZGlzdGluY3QgZmllbGRzCj4gcmF0aGVyIHRoYW4gY3JlYXRlIGEgc3RhbmRhcmQgZm9y bWF0IGZvciBzdHVmZmluZyBleHRyYSBkYXRhCj4gaW50byB0aGUgbmFtZXNwYWNlIFVSSS4gIFN0 YW5kYXJkIG1vZHVsZXMgdXNlIGEgVVJOIGZvcm1hdCwgd2hpbGUKClNvIHdoYXQncyB5b3VyIHBy b3Bvc2FsIGZvciBzb2x2aW5nIHRoZSBwcm9ibGVtcyAxIGFuZCAyIGFib3ZlPwoKPiB2ZW5kb3Jz IGFyZSBleHBlY3RlZCB0byB1c2UgYSBVUkwgZm9ybWF0LiAgVGhlIG5hbWVzcGFjZQo+IGZpZWxk IGlzIG5vdCB1bmlmb3JtbHkgc3RydWN0dXJlZCwgd2hpY2ggaXMgaW50ZW5kZWQgYXMgYSBmZWF0 dXJlLgoKWUFORyBvciBvdGhlciBORVRNT0QgZHJhZnQgY2FuIGRlZmluZSBhIHJlY29tbWVuZGVk IHN0cnVjdHVyZSBvZiBib3RoClVSTnMgYW5kIFVSTHMsIG5vIGJpZyBkZWFsLiBBbmQgaWYgYSBz aWxseSB2ZW5kb3IgZGVjaWRlcyB0byB1c2UgYW5vdGhlcgpmb3JtYXQsIHRoZSBtYW5hZ2VyIHdp bGwgYXQgbGVhc3QgYmUgYWJsZSB0byBkZWNpZGUgd2hldGhlciB0aGUgZGF0YQptb2RlbCBpcyBl eGFjdGx5IHRoZSBzYW1lIG9uIGJvdGggc2lkZXMgb3Igbm90LCBiYXNlZCBvbiBzdHJpbmcKZXF1 YWxpdHkuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0 RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5l dG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 4 07:54:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD653A6936; Mon, 4 Aug 2008 07:54:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A5D28C2CF for ; Mon, 4 Aug 2008 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MANGLED_VISIT=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDpLXz36iteJ for ; Mon, 4 Aug 2008 07:54:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7FDC03A6936 for ; Mon, 4 Aug 2008 07:54:11 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C563AD800BD; Mon, 4 Aug 2008 16:54:39 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <48970177.1010005@ericsson.com> References: <1217845614.6212.57.camel@missotis> <48970A0D.20702@netconfcentral.com> <48970177.1010005@ericsson.com> Organization: CESNET Date: Mon, 04 Aug 2008 16:54:40 +0200 Message-Id: <1217861680.6212.94.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgUG8gMDQuIDA4LiAyMDA4IHYgMTU6MTcgKzAyMDA6Cj4g SSB2b3RlIGZvciBBbmR5J3MgaW50ZXJwcmV0YXRpb24uCgpNaWtrbyB0b2xkIGl0IGFsbC4KCkNo ZWVycywgTGFkYQoKPiBCYWxhenMKPiAKPiBBbmR5IEJpZXJtYW4gd3JvdGU6Cj4gPiBMYWRpc2xh diBMaG90a2Egd3JvdGU6Cj4gPj4gSGksCj4gPj4KPiA+PiBoZXJlIGlzIHRoZSByZWxldmFudCB0 ZXh0IGZyb20gU2VjdGlvbiAyLjMgb2YgWFBhdGggMS4wIHJlY29tbWVuZGF0aW9uCj4gPj4gKGh0 dHA6Ly93d3cudzMub3JnL1RSL3hwYXRoI25vZGUtdGVzdHMpOgo+ID4+Cj4gPj4gImlmIHRoZSBR TmFtZSBkb2VzIG5vdCBoYXZlIGEgcHJlZml4LCB0aGVuIHRoZSBuYW1lc3BhY2UgVVJJIGlzIG51 bGwiCj4gPj4KPiA+PiBUaGUgWUFORyBkcmFmdCBzYXlzOgo+ID4+Cj4gPj4gIlRoZSBudWxsIG5h bWVzcGFjZSBpcyBkZWZpbmVkIHRvIGJlIHRoZSBuYW1lc3BhY2Ugb2YgdGhlIGN1cnJlbnQKPiA+ PiBtb2R1bGUiLgo+ID4+Cj4gPj4gSSB1bmRlcnN0YW5kIHRoaXMgd2FzIGFuIGF0dGVtcHQgdG8g YXZvaWQgdGhlIFhQYXRoIHJlcXVpcmVtZW50IHRvIHdyaXRlCj4gPj4gZXhwbGljaXQgbmFtZXNw YWNlIHByZWZpeGVzIGJ1dCBJTU8gaXQgaXMgbm90IGFjY2VwdGFibGUuIEl0IGlzIHRoZSBzYW1l Cj4gPj4gbGlrZSBkZWZpbmluZyBlbXB0eSBzZXQgdG8gY29udGFpbiBzb21ldGhpbmcuIE51bGwg bmFtZXNwYWNlIG1lYW5zIE5PCj4gPj4gbmFtZXNwYWNlLgo+ID4+Cj4gPj4+IEZyb20gdGhlIHBy YWN0aWNhbCBQT1YsIHRoZSBYUGF0aCBleHByZXNzaW9ucyBmb3VuZCBpbiBtdXN0IHN0YXRlbWVu dHMKPiA+PiB3aWxsIG5ldmVyIHdvcmsgKHVubW9kaWZpZWQpIGluIHZhbGlkYXRpb24gdG9vbHMg c3VjaCBhcyBYU0xUCj4gPj4gcHJvY2Vzc29ycy4KPiA+Pgo+ID4+IFRoZXJlZm9yZSwgSSB0aGlu ayBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSB0byBmb2xsb3cgdGhlIFhQYXRoIHNwZWMKPiA+ PiBhbmQgcmVtb3ZlIHRoZSByZWRlZmluaXRpb24gb2YgbnVsbCBuYW1lc3BhY2UuIFRoaXMgbWVh bnMgdGhhdCBub2RlCj4gPj4gbmFtZXMgaW4gbXVzdCBleHByZXNzaW9ucyB3aWxsIGFsd2F5cyBo YXZlIHRvIGhhdmUgYSBOUyBwcmVmaXguCj4gPj4KPiA+IAo+ID4gUGhpbCBzdWdnZXN0ZWQgdGhh dCB0aGUgWUFORyBjb21waWxlciBjYW4gYWRkIHRoZSBtaXNzaW5nIHByZWZpeAo+ID4gYmFjayBp bnRvIHRoZSBleHByZXNzaW9uLCBiZWZvcmUgcHJvY2Vzc2luZyBpdCB3aXRoIFhTTFQuCj4gPiBT aW5jZSBYU0xUIGNhbm5vdCBwb3NzaWJseSBwcm9jZXNzIGEgJ3JhdycgWUFORyBmaWxlIGF0IGFs bCwKPiA+IHRoaXMgc2VlbXMgcmVhc29uYWJsZS4KPiA+IAo+ID4gSSdtIG5vdCBzdXJlIHlvdSB1 bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoZQo+ID4gaHVtYW4tZnJpZW5kbHkgbGFuZ3VhZ2Ug Zm9ybS4gIFdlIGVpdGhlciB0ZWFjaCBvbmUgdG9vbAo+ID4gaG93IHRvIGFkYXB0IHRvIGh1bWFu IG5lZWRzLCBvciB3ZSB0ZWFjaCBhbGwgdGhlIGh1bWFucwo+ID4gaG93IHRvIGFkYXB0IHRvIHRo ZSB0aGUgdG9vbCdzIG5lZWRzLgo+ID4gCj4gPj4gTGFkYQo+ID4+Cj4gPiAKPiA+IEFuZHkKPiA+ IAo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdAo+ID4gbmV0bW9kQGlldGYub3JnCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+IAotLSAKTGFkaXNsYXYgTGhv dGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 4 07:54:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB7B3A6936; Mon, 4 Aug 2008 07:54:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867723A6CAB for ; Mon, 4 Aug 2008 07:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06-IlRIk6gQo for ; Mon, 4 Aug 2008 07:54:41 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id AA8943A6936 for ; Mon, 4 Aug 2008 07:54:41 -0700 (PDT) Received: (qmail 59947 invoked from network); 4 Aug 2008 14:55:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2008 14:55:06 -0000 X-YMail-OSG: 8_EJNPwVM1kbzUxFLSeQ8eblEFDQSuSM4ZpLlYRVyK4jU8CYM8O6ALHmI_e0LKl61yL6qu0_P6Aj6N40_JS3LLbtM14bAf8r76LFXMtSGw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48971848.7040408@netconfcentral.com> Date: Mon, 04 Aug 2008 07:55:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <1217845614.6212.57.camel@missotis> <48970A0D.20702@netconfcentral.com> <1217860502.6212.82.camel@missotis> In-Reply-To: <1217860502.6212.82.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAwNC4gMDgu IDIwMDggdiAwNjo1NCAtMDcwMDoKPj4gUGhpbCBzdWdnZXN0ZWQgdGhhdCB0aGUgWUFORyBjb21w aWxlciBjYW4gYWRkIHRoZSBtaXNzaW5nIHByZWZpeAo+PiBiYWNrIGludG8gdGhlIGV4cHJlc3Np b24sIGJlZm9yZSBwcm9jZXNzaW5nIGl0IHdpdGggWFNMVC4KPj4gU2luY2UgWFNMVCBjYW5ub3Qg cG9zc2libHkgcHJvY2VzcyBhICdyYXcnIFlBTkcgZmlsZSBhdCBhbGwsCj4+IHRoaXMgc2VlbXMg cmVhc29uYWJsZS4KPiAKPiBZZXMsIEkgc3VnZ2VzdGVkIHRoYXQgdG9vLCBidXQgcGFyc2luZyBs b2dpYyBmb3IgWFBhdGggZXhwcmVzc2lvbnMgd291bGQKPiBiZSBhbm90aGVyIGNvbXBsZXhpdHkg dG8gYmUgYWRkZWQgdG8gdGhlIFlBTkcgcGFyc2VyLgo+IAo+PiBJJ20gbm90IHN1cmUgeW91IHVu ZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhlCj4+IGh1bWFuLWZyaWVuZGx5IGxhbmd1YWdlIGZv cm0uICBXZSBlaXRoZXIgdGVhY2ggb25lIHRvb2wKPj4gaG93IHRvIGFkYXB0IHRvIGh1bWFuIG5l ZWRzLCBvciB3ZSB0ZWFjaCBhbGwgdGhlIGh1bWFucwo+PiBob3cgdG8gYWRhcHQgdG8gdGhlIHRo ZSB0b29sJ3MgbmVlZHMuCj4gCj4gSSB1bmRlcnN0YW5kIGl0IHZlcnkgd2VsbC4gSG93ZXZlciwg aWYgdGhlIFlBTkcgZHJhZnQgcmVmZXJzIHRvIFhQYXRoLAo+IHRoZW4gaXQgaGFzIHRvIGJlIFhQ YXRoIC0gYW5kIHBhcnQgb2YgaXRzIDEuMCBzdGFuZGFyZCBpcyB0aGlzIGhhbmRsaW5nCj4gb2Yg bmFtZXNwYWNlcywgd2hldGhlciB5b3UgbGlrZSBpdCBvciBub3QuIFRoZSBvdGhlciBvcHRpb24g aXMgdG8gZGVmaW5lCj4gdGhlIHN5bnRheCBvZiBtdXN0IGV4cHJlc3Npb25zIGluIHRoZSBZQU5H IGRyYWZ0IGFuZCBjYWxsIGl0IHNvbWV0aGluZwo+IGVsc2UuCj4gCj4gU28gbXkgcG9pbnQgaXMg dGhhbiBpdCdzIGEgcHJvYmxlbSBmb3IgWUFORyBzcGVjaWZpY2F0aW9uIGFzIHdlbGwuCj4gCgpJ dCBhbHJlYWR5IGlzIHNvbWV0aGluZyBlbHNlLgpZQU5HIFhQYXRoIGhhcyAnZXh0cmEgZmVhdHVy ZXMnIHJpZ2h0PwoKQnVyaWVkIGluIHRoZSBBQk5GOgoKICAgIHRoaXMtdmFyaWFibGUta2V5d29y ZCAgPSAnJHRoaXMnCgpUaGVyZSBpcyBubyBub3JtYXRpdmUgdGV4dCBhbnl3aGVyZSBmb3IgJyR0 aGlzJy4KCiBGcm9tIDcuNS4yOgoKICAgIFRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGNvbmNlcHR1 YWxseSBldmFsdWF0ZWQgaW4gdGhlIGZvbGxvd2luZwogICAgY29udGV4dDoKCiAgICBvICBUaGUg Y29udGV4dCBub2RlIGlzIHRoZSBub2RlIGluIHRoZSBkYXRhIHRyZWUgZm9yIHdoaWNoIHRoZSAi bXVzdCIKICAgICAgIHN0YXRlbWVudCBpcyBkZWZpbmVkLgoKICAgIG8gIFRoZSBhY2Nlc3NpYmxl IHRyZWUgaXMgbWFkZSB1cCBvZiBhbGwgbm9kZXMgaW4gdGhlIGRhdGEgdHJlZSwgYW5kCiAgICAg ICBhbGwgbGVhZnMgd2l0aCBkZWZhdWx0IHZhbHVlcy4KCiAgICBvICBUaGUgc2V0IG9mIG5hbWVz cGFjZSBkZWNsYXJhdGlvbnMgaXMgdGhlIHNldCBvZiBhbGwgImltcG9ydCIKICAgICAgIHN0YXRl bWVudHMnIHByZWZpeCBhbmQgbmFtZXNwYWNlIHBhaXJzLCBhbmQgdGhlICJwcmVmaXgiCiAgICAg ICBzdGF0ZW1lbnQncyBwcmVmaXggZm9yIHRoZSAibmFtZXNwYWNlIiBzdGF0ZW1lbnQncyBVUkku CgogICAgbyAgVGhlIG51bGwgbmFtZXNwYWNlIGlzIGRlZmluZWQgdG8gYmUgdGhlIG5hbWVzcGFj ZSBvZiB0aGUgY3VycmVudAogICAgICAgbW9kdWxlLgoKICAgIG8gIE9uZSB2YXJpYWJsZSAidGhp cyIsIHdoaWNoIGlzIHRoZSBjb250ZXh0IG5vZGUsIGlzIGRlZmluZWQuCgoKWUFORyByZXF1aXJl cyBjdXN0b20gaW1wbGVtZW50YXRpb24gb2YgWFBhdGggYWxyZWFkeS4KQnV0IHRoZSBZQU5HIHBh cnNlciByZXF1aXJlcyBsb3RzIG9mIGRpZmZpY3VsdCBjdXN0b20gY29kZSwKc28gbWF5YmUgdGhp cyBpcyBub3QgYSBwcm9ibGVtLgoKSSBzdXNwZWN0IHRoYXQgInNvcnQgb2YgdXNpbmcgWFBhdGgg MS4wIiBpcyBub3QgcXVpdGUgd2hhdAp0aGUgV0cgdGhvdWdodCB3ZSB3ZXJlIGRvaW5nLgoKCgo+ IExhZGEKPiAKCkFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 4 07:58:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411AF3A6CBE; Mon, 4 Aug 2008 07:58:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F8228C2BD for ; Mon, 4 Aug 2008 07:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcTJvH3ZSgNz for ; Mon, 4 Aug 2008 07:58:00 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 0455C3A6CBE for ; Mon, 4 Aug 2008 07:57:59 -0700 (PDT) Received: (qmail 62871 invoked from network); 4 Aug 2008 14:58:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2008 14:58:26 -0000 X-YMail-OSG: fmEI5z0VM1ld57WagF0S0qzR0mhYpZg7SYp51UbBdVVpso2dqPSWJqnixDN2OCulK2aXETkbUh7fHStusdFj_qm7DaLQfYzymcU7yHBGww-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48971910.9080105@netconfcentral.com> Date: Mon, 04 Aug 2008 07:58:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <48933C80.1060300@netconfcentral.com> <20080802.225907.84658836.mbj@tail-f.com> <1217832298.6212.14.camel@missotis> <489711E8.4050608@netconfcentral.com> <1217861538.6212.91.camel@missotis> In-Reply-To: <1217861538.6212.91.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAwNC4gMDgu IDIwMDggdiAwNzoyNyAtMDcwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pj4gTWFydGlu IEJqb3JrbHVuZCBww63FoWUgdiBTbyAwMi4gMDguIDIwMDggdiAyMjo1OSArMDIwMDoKPj4+PiBB bmR5IEJpZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPiB3cm90ZToKPj4+Pj4gT25lIGV4 YW1wbGUsIG5hbWVzcGFjZSBVUklzOgo+Pj4+PiBJIGFtIHdpdGggdGhlIGNhbXAgdGhhdCBzZXRz IHRoaXMgZmllbGQgb25jZSBmb3IgYSBtb2R1bGUsCj4+Pj4+IGFuZCBuZXZlciBjaGFuZ2VzIGl0 IC0tIGV2ZXIuCj4+Pj4gVGhpcyBoYXMgYWx3YXlzIGJlZW4gdGhlIGludGVudGlvbi4gIEJ1dCBz aW5jZSB3ZSBkb24ndCBoYXZlIHRoZQo+Pj4gVGhpcyBhcHByb2FjaCBoYXMgdHdvIHJlbGF0ZWQg ZHJhd2JhY2tzOgo+Pj4KPj4+IDEuIE5FVENPTkYgaGVsbG8gbWVzc2FnZSBjYXJyaWVzIFVSSXMs IHNvIGlmIGEgVVJJIHVuaXF1ZWx5IGlkZW50aWZpZXMKPj4+IHRoZSBkYXRhIG1vZGVsLCB0aGlz IGlzIGFsbCB3aGF0J3MgbmVlZGVkLiBBbm90aGVyIG1ldGhvZCB3aWxsIGhhdmUgdG8KPj4+IGJl IGludmVudGVkIGluIG9yZGVyIHRvIGNvbW11bmljYXRlIHRoZSByZXZpc2lvbiBiZXR3ZWVuIHRo ZSBhZ2VudCBhbmQKPj4+IG1hbmFnZXIuCj4+Pgo+Pj4gMi4gVGhlIG5hbWVzcGFjZSBVUkkgd2ls bCBiZSBwcmVzZW50IGluIGFsbCBpbnN0YW5jZSBYTUwgZG9jdW1lbnRzIHN1Y2gKPj4+IGFzIE5F VENPTkYgUERVIHdoZXJlYXMgdGhlIHJldmlzaW9uIHN0cmluZyBjdXJyZW50bHkgbmVlZG4ndCBi ZS4KPj4+Cj4+PiBXaHkgaXMgaXQgYSBwcm9ibGVtIHRvIGhhdmUgdGhlIG5hbWVzcGFjZSBVUkkg YXMgdGhlIG9ubHkgb25lIGlkZW50aWZpZXIKPj4+IG9mIHRoZSBkYXRhIG1vZGVsLCBpbmNsdWRp bmcgaXRzIHZlcnNpb24/Cj4+Pgo+PiBCZWNhdXNlIHdlIGRvbid0IHdhbnQgdG8gbWFuYWdlIDEw WCBtb3JlIG5hbWVzcGFjZXMgdGhhbgo+PiB3ZSByZWFsbHkgbmVlZCwgYW5kIGJlY2F1c2UgdGhl IHJldmlzaW9uIGRhdGUgaXMgYSBzZXBhcmF0ZQo+PiBmaWVsZCB3aXRoIGl0cyBvd24gc2VtYW50 aWNzLiAgSSBwcmVmZXIgdXNpbmcgMiBkaXN0aW5jdCBmaWVsZHMKPj4gcmF0aGVyIHRoYW4gY3Jl YXRlIGEgc3RhbmRhcmQgZm9ybWF0IGZvciBzdHVmZmluZyBleHRyYSBkYXRhCj4+IGludG8gdGhl IG5hbWVzcGFjZSBVUkkuICBTdGFuZGFyZCBtb2R1bGVzIHVzZSBhIFVSTiBmb3JtYXQsIHdoaWxl Cj4gCj4gU28gd2hhdCdzIHlvdXIgcHJvcG9zYWwgZm9yIHNvbHZpbmcgdGhlIHByb2JsZW1zIDEg YW5kIDIgYWJvdmU/Cj4gCgpOZXcgcHJvdG9jb2wgbWVjaGFuaXNtcyBhbHJlYWR5IGRlZmluZWQg aW4KZHJhZnQtaWV0Zi1uZXRjb25mLW1vbml0b3JpbmctMDIKCgo+PiB2ZW5kb3JzIGFyZSBleHBl Y3RlZCB0byB1c2UgYSBVUkwgZm9ybWF0LiAgVGhlIG5hbWVzcGFjZQo+PiBmaWVsZCBpcyBub3Qg dW5pZm9ybWx5IHN0cnVjdHVyZWQsIHdoaWNoIGlzIGludGVuZGVkIGFzIGEgZmVhdHVyZS4KPiAK PiBZQU5HIG9yIG90aGVyIE5FVE1PRCBkcmFmdCBjYW4gZGVmaW5lIGEgcmVjb21tZW5kZWQgc3Ry dWN0dXJlIG9mIGJvdGgKPiBVUk5zIGFuZCBVUkxzLCBubyBiaWcgZGVhbC4gQW5kIGlmIGEgc2ls bHkgdmVuZG9yIGRlY2lkZXMgdG8gdXNlIGFub3RoZXIKPiBmb3JtYXQsIHRoZSBtYW5hZ2VyIHdp bGwgYXQgbGVhc3QgYmUgYWJsZSB0byBkZWNpZGUgd2hldGhlciB0aGUgZGF0YQo+IG1vZGVsIGlz IGV4YWN0bHkgdGhlIHNhbWUgb24gYm90aCBzaWRlcyBvciBub3QsIGJhc2VkIG9uIHN0cmluZwo+ IGVxdWFsaXR5LgoKWUFORyBzaG91bGQgbm90IHJlaW52ZW50IHRoZSBVUkkgc3ludGF4IGZvciB1 c2UgaW4gTkVUQ09ORi4KCj4gCj4gTGFkYQo+IAoKQW5keQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Aug 4 08:16:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383DB3A6CC9; Mon, 4 Aug 2008 08:16:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2596E3A6CCA for ; Mon, 4 Aug 2008 08:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1CYPSBqjy9B for ; Mon, 4 Aug 2008 08:16:54 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 0F7343A6CBE for ; Mon, 4 Aug 2008 08:16:54 -0700 (PDT) Received: (qmail 539 invoked from network); 4 Aug 2008 15:17:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2008 15:17:21 -0000 X-YMail-OSG: 8w3zUoEVM1mFKMTfVoNw1HgUcqGzpXr28cpIOLsWrvGPc_A4OQCV3lrT69JXnxrDGb3QfmTJz1Y1cyyLPZ.r5PQHnQeNaGJywECbUwmBYw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48971D7F.4090604@netconfcentral.com> Date: Mon, 04 Aug 2008 08:17:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Lahdensivu, Mikko (NSN - FI/Tampere)" References: <1217845614.6212.57.camel@missotis> <48970A0D.20702@netconfcentral.com> <210412A63D60154898B7CDC3C7172BDE31269D@FIESEXC007.nsn-intra.net> In-Reply-To: <210412A63D60154898B7CDC3C7172BDE31269D@FIESEXC007.nsn-intra.net> Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Lahdensivu, Mikko (NSN - FI/Tampere) wrote: > Hi, > >>> Therefore, I think it is absolutely necessary to follow the >> XPath spec >>> and remove the redefinition of null namespace. This means that node >>> names in must expressions will always have to have a NS prefix. >>> >> Phil suggested that the YANG compiler can add the missing >> prefix back into the expression, before processing it with XSLT. >> Since XSLT cannot possibly process a 'raw' YANG file at all, >> this seems reasonable. >> >> I'm not sure you understand the purpose of the human-friendly >> language form. We either teach one tool how to adapt to human >> needs, or we teach all the humans how to adapt to the the tool's needs. >> >>> Lada >>> >> Andy >> > > part of the "human-friendliness" of a language is also about how close > it is to existing languages. If it is close, it is easy for reader to > get confused about small, distinct behaviour. Integrating an existing > language, and modifying its rules slightly, can be worse than a language > that is more clearly distinct from other languages. > And yet, dozens if not hundreds of programming languages start with existing concepts and syntax, and refine/improve it in ways more suitable to their intended application. Add YANG to that list. At every step, the NETMOD WG is going to make design trade-offs, based on the intended audience and application space. IMO, operators who have not already learned XPath are not going to care 1 way or another. They will be too busy skipping over all the must-stmts and other cryptic noise they do not want to read. Parts of the YANG learning curve are so off the scale, that they will never be learned by some people. These people will simply 'skip over' all the XPath cruft. But what about the operators who know XPath? You are raising a very legitimate argument. I do not have enough implementation and operator experience to know if the XPath mods in YANG are worth it. The must-stmt may be more useful in theory than in practice. > I would consider that if you change the sub-language (xpath) trying to > optimize it for the main language (yang), you are requesting people to > actually adapt more to the language, than if you would do by keeping the > sub-language as it is. > > The most important aspect of human-friendliness of a language is that > people understand it correctly. > > Also, I hope that by "one tool" you mean just the language itself, not > that there wouldn't be multiple independent sets of tools around Yang, > which have to, like the people, adapt to the language. > > Mikko > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 08:22:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD9C3A68D0; Mon, 4 Aug 2008 08:22:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A183A68D0 for ; Mon, 4 Aug 2008 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkqPah71s+ai for ; Mon, 4 Aug 2008 08:22:43 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 3FCB83A688F for ; Mon, 4 Aug 2008 08:22:43 -0700 (PDT) Received: (qmail 20288 invoked from network); 4 Aug 2008 15:23:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2008 15:23:10 -0000 X-YMail-OSG: _u2vw4sVM1k6j3JwD0OUA.c_.nVSIa5M.3reQn.TAmnkJX.fPBh6atLOMTNtnBSMhQV78eGH4V9_xO_kd0M1ZgwnVPL4.T4JUlylPxfKcfhu_xHT_vYAoMDRkafpWTs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48971EDB.1060005@netconfcentral.com> Date: Mon, 04 Aug 2008 08:23:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: bernd.linowski.ext@nsn.com References: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> Cc: netmod@ietf.org Subject: Re: [netmod] Representation of instance identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org bernd.linowski.ext@nsn.com wrote: > Hi Everybody, > > in the NETMOD session last Thursday when Martin B. gave an overview > about YANG features, > I'll also touched the issue of the XML representation of an instance > identifier and was > suggesting a different, XML element based representation, which I'm > going to describe here. > This impacts the NETCONF protocol in fields like the element. It is not very hard for an agent to generate an XPath expression for this purpose. It does not need an XPath parser at all. It would be more work to generate the entire XML sub-tree for this purpose. As for encoding corner-cases, such as the single-quote char. That's what character entities are for. Andy > In the YANG spec it is currently stated that the instance identifier is > encoded > as XPath expression: > "The syntax for an instance-identifier is a subset of the XPath > syntax, which is used to uniquely identify a node in the data tree. > It is an absolute XPath location path in abbreviated syntax, where > axes are not permitted, and predicates are used only for specifying > the values for the key nodes for list entries, or a value of a leaf- > list. Each predicate consists of one equality test per key. Each > key MUST have a corresponding predicate. > > Imho, this way of encoding an instance identifier is a bit to much > biased > in direction of readability but makes creating and parsing instance > identifiers > harder as actually needed (see below). > > Therefore I would like to suggest another approach of > encoding an instance identifier, which uses an XML elements. > - For every node in the location path an XML element with that node > name > is created in the containing XML element (lead-(list) element) > - In case the node in the location path is a list > - a sub-element for every key is created > - that contains the key value as text > > For example the path > > "/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']" > > (YANG spec example) would be represented as > > > > 192.0.2.1 > 80 > > > The XPath notation is of course shorter and more easy to read > for humans. But this XPath expressions do not appear in the model > but in NETCONF payload. And this is (mostly) processed by > machines. > > * So for a NETCONF agent or manager to make use out of an XPath > expression > it has to first parse it. That means the agent / manager has to have > an > XPath expression scanner / parser available that does this job - which > could mean extra implementation respectively integration > effort. > E.g. in the Java 5 platform you have built-in functionality for > executing Xpath expression on an XML Input source. But that does > help too much when the referred instance is currently only represented > in a internal (non-XML) representation (as the referred entity might > not be part of the XML payload of the actual NETCONF PDU) > > * Also encoding instance reference relying on key values > in form of XPath expressions could be sometimes a bit of a challenge > as > the quotation mechanism of XPath is a bit limited afaics > (see XPath http://www.w3.org/TR/xpath#strings, 3.7 [29]. > > Consider an e-mail address like > > "John O'Conner"@example.ie > > This is unusual but valid (see RFC 3696). > Assuming that a node in a list of subscribers > where the e-mail address is the key must be identified > by that value. How do you quote it as part of an XPath > expression? Neither the single-quote form nor the double-quote > form work in that example. > > Having the identifier location path encoded in form of XML elements > as suggested above means > - that the job of encoding is simple and can be done by only > using the XML node tree creation API that is anyway used > - the job of correctly encoding / quoting key values is done > by the XML processor > - the job of parsing the elements of the instance identifier > locating path is done by the XML parser that is anyway used > - the job of decoding key values is done by the XML parser > - no need to implement / embed a XPath expression parser for this > purpose > > > As this is even the only place where XPath expressions are used > in the NETCONG payload afaics, or...? > > So what do you think, wouldn't be an XML element based representation of > instance identifiers be the easier, simpler solution? > > > Best wishes, > Bernd > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 08:46:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218613A6B6F; Mon, 4 Aug 2008 08:46:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A753A6CD7 for ; Mon, 4 Aug 2008 08:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4OneUjTTfhF for ; Mon, 4 Aug 2008 08:46:07 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CF29E3A6B6F for ; Mon, 4 Aug 2008 08:46:06 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6E1F120F9C for ; Mon, 4 Aug 2008 17:46:18 +0200 (CEST) X-AuditID: c1b4fb3e-aa991bb000004ec0-85-4897244aa049 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 579B4206C3 for ; Mon, 4 Aug 2008 17:46:18 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 17:46:18 +0200 Received: from [153.88.45.26] ([153.88.45.26]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 17:46:17 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 4 Aug 2008 17:47:19 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808041747.19929.david.partain@ericsson.com> X-OriginalArrivalTime: 04 Aug 2008 15:46:17.0986 (UTC) FILETIME=[3C01DE20:01C8F649] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Vacation... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, Just an FYI mail... I will be on vacation this week, so taking up threads from the IETF won't happen (for my part, anyway) until I get back to work in one week. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 09:14:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D893A697F; Mon, 4 Aug 2008 09:14:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5AC3A6B43 for ; Mon, 4 Aug 2008 09:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1-641tPAK-p for ; Mon, 4 Aug 2008 09:14:17 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 92E573A697F for ; Mon, 4 Aug 2008 09:14:16 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m74GEUJ5030420; Mon, 4 Aug 2008 19:14:34 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 19:14:06 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 19:13:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 19:13:55 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F26604519C45@esebe103.NOE.Nokia.com> In-Reply-To: <48971EDB.1060005@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Representation of instance identifiers Thread-Index: Acj2RgQJm770GTrDTwaX6pQRINxlQQAAWzMQ References: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> <48971EDB.1060005@netconfcentral.com> From: To: , X-OriginalArrivalTime: 04 Aug 2008 16:13:56.0419 (UTC) FILETIME=[1882A930:01C8F64D] X-Nokia-AV: Clean Subject: Re: [netmod] Representation of instance identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > -----Original Message----- > From: ext Andy Bierman [mailto:andy@netconfcentral.com] > Sent: 04 August, 2008 17:23 > To: Linowski Bernd (EXT-Other - DE/Dusseldorf) > Cc: netmod@ietf.org > Subject: Re: [netmod] Representation of instance identifiers > > bernd.linowski.ext@nsn.com wrote: > > Hi Everybody, > > > > in the NETMOD session last Thursday when Martin B. gave an overview > > about YANG features, > > I'll also touched the issue of the XML representation of an instance > > identifier and was > > suggesting a different, XML element based representation, which I'm > > going to describe here. > > > > > This impacts the NETCONF protocol in fields > like the element. It is not very > hard for an agent to generate an XPath expression > for this purpose. It does not need an XPath parser at all. Sure - not for generating an XPath expression. Here you need an builder / or writer. Still one quote character must be "manually" quoted to ensure valid XPath expressions. (E.g. the Java XML Transformer operating on a DOM source does not quote single or double quotes as part of an element text(!) content -which is fine as XML requires only to quote <, >, and & everywhere) > It would be more work to generate the entire XML sub-tree > for this purpose. I don't agree. Creating the element nodes describing the path is as least as simple as building a valid XPath expression. Considering corner cases it even simpler imho. But the issue of parsing XPath remains, as an agent might need to understand where an instance identifier points. And you cannot assume that it an up to date copy of its entire configuration is available as XML node tree so that you can use an expression evaluator for that. To me that looks that functionality needs to be re-invented that is already provided by an XML parser in case a XML element based representation is used. - Bernd > > As for encoding corner-cases, such as the single-quote char. > That's what character entities are for. > > > Andy > > > > > In the YANG spec it is currently stated that the instance > identifier is > > encoded > > as XPath expression: > > "The syntax for an instance-identifier is a subset of the XPath > > syntax, which is used to uniquely identify a node in the > data tree. > > It is an absolute XPath location path in abbreviated > syntax, where > > axes are not permitted, and predicates are used only for > specifying > > the values for the key nodes for list entries, or a > value of a leaf- > > list. Each predicate consists of one equality test per > key. Each > > key MUST have a corresponding predicate. > > > > Imho, this way of encoding an instance identifier is a bit to much > > biased > > in direction of readability but makes creating and parsing instance > > identifiers > > harder as actually needed (see below). > > > > Therefore I would like to suggest another approach of > > encoding an instance identifier, which uses an XML elements. > > - For every node in the location path an XML element with that node > > name > > is created in the containing XML element (lead-(list) element) > > - In case the node in the location path is a list > > - a sub-element for every key is created > > - that contains the key value as text > > > > For example the path > > > > "/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']" > > > > (YANG spec example) would be represented as > > > > > > > > 192.0.2.1 > > 80 > > > > > > The XPath notation is of course shorter and more easy to read > > for humans. But this XPath expressions do not appear in the model > > but in NETCONF payload. And this is (mostly) processed by > > machines. > > > > * So for a NETCONF agent or manager to make use out of an XPath > > expression > > it has to first parse it. That means the agent / manager > has to have > > an > > XPath expression scanner / parser available that does > this job - which > > could mean extra implementation respectively integration > > effort. > > E.g. in the Java 5 platform you have built-in functionality for > > executing Xpath expression on an XML Input source. But that does > > help too much when the referred instance is currently > only represented > > in a internal (non-XML) representation (as the referred > entity might > > not be part of the XML payload of the actual NETCONF PDU) > > > > * Also encoding instance reference relying on key values > > in form of XPath expressions could be sometimes a bit of > a challenge > > as > > the quotation mechanism of XPath is a bit limited afaics > > (see XPath http://www.w3.org/TR/xpath#strings, 3.7 [29]. > > > > Consider an e-mail address like > > > > "John O'Conner"@example.ie > > > > This is unusual but valid (see RFC 3696). > > Assuming that a node in a list of subscribers > > where the e-mail address is the key must be identified > > by that value. How do you quote it as part of an XPath > > expression? Neither the single-quote form nor the double-quote > > form work in that example. > > > > Having the identifier location path encoded in form of XML elements > > as suggested above means > > - that the job of encoding is simple and can be done by only > > using the XML node tree creation API that is anyway used > > - the job of correctly encoding / quoting key values is done > > by the XML processor > > - the job of parsing the elements of the instance identifier > > locating path is done by the XML parser that is anyway used > > - the job of decoding key values is done by the XML parser > > - no need to implement / embed a XPath expression parser for this > > purpose > > > > > > As this is even the only place where XPath expressions are used > > in the NETCONG payload afaics, or...? > > > > So what do you think, wouldn't be an XML element based > representation of > > instance identifiers be the easier, simpler solution? > > > > > > Best wishes, > > Bernd > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 09:56:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B623D3A6D15; Mon, 4 Aug 2008 09:56:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB593A6D17 for ; Mon, 4 Aug 2008 09:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhHd2oI2oG2g for ; Mon, 4 Aug 2008 09:56:58 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id A97C93A6D15 for ; Mon, 4 Aug 2008 09:56:58 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id yD6F1Z00316AWCUA3Gx1gd; Mon, 04 Aug 2008 16:57:01 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id yGwy1Z0174HwxpC8SGwzj0; Mon, 04 Aug 2008 16:57:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=VNYC8flkFltC6d80pfAA:9 a=j2VOTPdjG19n3IQgbIgA:7 a=0rM0CPe42MXhKtBDvcxgzUG4NksA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=4GGKM1rHjQwA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , Date: Mon, 4 Aug 2008 12:56:58 -0400 Message-ID: <00bf01c8f653$1c7fb8b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acj2TDlWcKLN99WQTb+UpdVM0cpb0QABhz5g Subject: [netmod] FW: Please ask your WG... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, It is nomcom time again. The selection process for those who steer and provide architectural guidance for the IETF is obviously very important. We really need volunteers to help make those selections. As a member of this community, you are uniquely qualified to help choose these leaders. Please consider being a volunteer to help in the selection process. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Sunday, August 03, 2008 10:43 AM To: Working Group Chairs Subject: Please ask your WG... To volunteer for the nomcom. The nomcom process is (in my opinion) better served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. As such, please ask on your individual mailing lists for folks to volunteer. Obviously, the exact method for doing so is up to you. The most recent call for volunteers can be reference here: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617 Whether you copy that message, or reference is probably up to you and the habits of your working group mailing list. If you want to reference or copy the status message I sent out, that can be found at: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618 Thank you, Joel M. Halpern Nomcom Chair jmh@joelahlpern.com nomcom-chair@ietf.org _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 13:36:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643E03A6984; Mon, 4 Aug 2008 13:36:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192573A6C0B for ; Mon, 4 Aug 2008 13:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9-B2W2yGKpK for ; Mon, 4 Aug 2008 13:36:56 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2DE073A6A4C for ; Mon, 4 Aug 2008 13:36:56 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id EED2C76C4CC; Mon, 4 Aug 2008 22:37:21 +0200 (CEST) Date: Mon, 04 Aug 2008 22:37:15 +0200 (CEST) Message-Id: <20080804.223715.232565284.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1217832298.6212.14.camel@missotis> References: <48933C80.1060300@netconfcentral.com> <20080802.225907.84658836.mbj@tail-f.com> <1217832298.6212.14.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD framework X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGksDQoNCkxhZGlzbGF2IExob3RrYSA8bGhvdGthQGNlc25ldC5jej4gd3JvdGU6DQo+IE1hcnRp biBCam9ya2x1bmQgcMOtxaFlIHYgU28gMDIuIDA4LiAyMDA4IHYgMjI6NTkgKzAyMDA6DQo+ID4g QW5keSBCaWVybWFuIDxhbmR5QG5ldGNvbmZjZW50cmFsLmNvbT4gd3JvdGU6DQo+ID4gPiBPbmUg ZXhhbXBsZSwgbmFtZXNwYWNlIFVSSXM6DQo+ID4gPiBJIGFtIHdpdGggdGhlIGNhbXAgdGhhdCBz ZXRzIHRoaXMgZmllbGQgb25jZSBmb3IgYSBtb2R1bGUsDQo+ID4gPiBhbmQgbmV2ZXIgY2hhbmdl cyBpdCAtLSBldmVyLg0KPiA+IA0KPiA+IFRoaXMgaGFzIGFsd2F5cyBiZWVuIHRoZSBpbnRlbnRp b24uICBCdXQgc2luY2Ugd2UgZG9uJ3QgaGF2ZSB0aGUNCj4gDQo+IFRoaXMgYXBwcm9hY2ggaGFz IHR3byByZWxhdGVkIGRyYXdiYWNrczoNCj4gDQo+IDEuIE5FVENPTkYgaGVsbG8gbWVzc2FnZSBj YXJyaWVzIFVSSXMsIHNvIGlmIGEgVVJJIHVuaXF1ZWx5IGlkZW50aWZpZXMNCj4gdGhlIGRhdGEg bW9kZWwsIHRoaXMgaXMgYWxsIHdoYXQncyBuZWVkZWQuIEFub3RoZXIgbWV0aG9kIHdpbGwgaGF2 ZSB0bw0KPiBiZSBpbnZlbnRlZCBpbiBvcmRlciB0byBjb21tdW5pY2F0ZSB0aGUgcmV2aXNpb24g YmV0d2VlbiB0aGUgYWdlbnQgYW5kDQo+IG1hbmFnZXIuDQoNClRoZSByZXZpc2lvbiBpcyBzZW50 IGluIHRoZSBoZWxsbyBleGNoYW5nZSBhcyB3ZWxsLCBsaWtlIHRoaXM6DQoNCiAgbmFtZXNwYWNl LXVyaSAiPyIgcmV2aXNpb24NCg0KSXQgaXMgYWxzbyBhdmFpbGFibGUgZnJvbSB0aGUgc2NoZW1h IGRpc2NvdmVyeSBtZWNoYW5pc20gZGVmaW5lZCBieQ0KdGhlIE5FVENPTkYgV0cuDQoNCj4gMi4g VGhlIG5hbWVzcGFjZSBVUkkgd2lsbCBiZSBwcmVzZW50IGluIGFsbCBpbnN0YW5jZSBYTUwgZG9j dW1lbnRzIHN1Y2gNCj4gYXMgTkVUQ09ORiBQRFUgd2hlcmVhcyB0aGUgcmV2aXNpb24gc3RyaW5n IGN1cnJlbnRseSBuZWVkbid0IGJlLg0KDQpUaGUgcmV2aXNpb24gaW4gdGhlIGhlbGxvIG1zZyBz cGVjaWZpZXMgdG8gdGhlIGNsaWVudCB3aGljaCB2ZXJzaW9uIG9mDQphIG1vZHVsZSB0aGUgc2Vy dmVyIGltcGxlbWVudHMuICBUaGUgVVJJIGluIHRoZSBYTUwgZW5jb2RpbmcgaXMNCnRoZXJlIHRv IGlkZW50aWZ5IHRoZSBYTUwgbmFtZXNwYWNlIG9mIHRoZSBYTUwgZWxlbWVudHMsIGFuZCBhdm9p ZHMNCm5hbWUgY2xhc2hlcy4gIEl0IGlzIGEgZmVhdHVyZSB0aGF0IHRoZSByZXZpc2lvbiBpcyBO T1QgcGFydCBvZiB0aGUNCmVuY29kaW5nLCBzaW5jZSBpdCB0aHVzIG1ha2VzIGl0IHBvc3NpYmxl IGZvciBhbiBvbGQgY2xpZW50IHRvIHRhbGsgdG8NCmEgbmV3IHNlcnZlciAob3IgbWF5YmUgdXBs b2FkIGFuIG9sZCBiYWNrdXAgb2YgKHBhcnRzIG9mKSB0aGUgY29uZmlnDQphZnRlciBhIHNvZnR3 YXJlIHVwZ3JhZGUpLg0KDQoNCi9tYXJ0aW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 4 14:00:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D943A68CE; Mon, 4 Aug 2008 14:00:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FA43A68CE for ; Mon, 4 Aug 2008 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWDTlBbl2WXG for ; Mon, 4 Aug 2008 14:00:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 15E783A6A99 for ; Mon, 4 Aug 2008 14:00:12 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F62276C4CC; Mon, 4 Aug 2008 22:52:19 +0200 (CEST) Date: Mon, 04 Aug 2008 22:52:14 +0200 (CEST) Message-Id: <20080804.225214.265720698.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1217845614.6212.57.camel@missotis> References: <1217845614.6212.57.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > here is the relevant text from Section 2.3 of XPath 1.0 recommendation > (http://www.w3.org/TR/xpath#node-tests): > > "if the QName does not have a prefix, then the namespace URI is null" > > The YANG draft says: > > "The null namespace is defined to be the namespace of the current > module". > > I understand this was an attempt to avoid the XPath requirement to write > explicit namespace prefixes but IMO it is not acceptable. It is the same > like defining empty set to contain something. Null namespace means NO > namespace. Maybe we should reword our spec and say "Elements without a namespace refer to nodes in the current module.". > >From the practical POV, the XPath expressions found in must statements > will never work (unmodified) in validation tools such as XSLT > processors. I think you will have to set up your execution environment carefully anyway if you want to use such tools. For example, you'll have to give them the entire config data store as one instance document, and if you have one instance document you will have one root, and that means that your absolute XPath statements will not work w/o modification. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 14:02:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29D83A6C1F; Mon, 4 Aug 2008 14:02:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260C33A6C38 for ; Mon, 4 Aug 2008 14:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGwj5aeoezh4 for ; Mon, 4 Aug 2008 14:02:43 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 22BC93A6C1F for ; Mon, 4 Aug 2008 14:02:42 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id C4CB376C4CC; Mon, 4 Aug 2008 23:02:05 +0200 (CEST) Date: Mon, 04 Aug 2008 23:02:01 +0200 (CEST) Message-Id: <20080804.230201.216290442.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48971848.7040408@netconfcentral.com> References: <48970A0D.20702@netconfcentral.com> <1217860502.6212.82.camel@missotis> <48971848.7040408@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > It already is something else. > YANG XPath has 'extra features' right? No. > Buried in the ABNF: > > this-variable-keyword = '$this' > > There is no normative text anywhere for '$this'. Yes there is, you quoted it yourself: > From 7.5.2: > > The XPath expression is conceptually evaluated in the following > context: > > o The context node is the node in the data tree for which the "must" > statement is defined. > > o The accessible tree is made up of all nodes in the data tree, and > all leafs with default values. > > o The set of namespace declarations is the set of all "import" > statements' prefix and namespace pairs, and the "prefix" > statement's prefix for the "namespace" statement's URI. > > o The null namespace is defined to be the namespace of the current > module. > > o One variable "this", which is the context node, is defined. This is part of the XPath "context" (or execution environment) which users of XPath must specify. > YANG requires custom implementation of XPath already. No! YANG *does not* require an implementation at all - this is what we currently say: Note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator on the device. How the evaluation is done in practice is an implementation decision. The idea is that the must expression tells the implementer about a constraint, and I suspect that often this constraint will be enforced by hand-written code, rather than automatically by the engine. > I suspect that "sort of using XPath 1.0" is not quite what > the WG thought we were doing. IMO we are using XPath 1.0. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 4 14:21:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC79B3A6BE5; Mon, 4 Aug 2008 14:21:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB08C3A6CE6 for ; Mon, 4 Aug 2008 14:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw5U1YbQnwow for ; Mon, 4 Aug 2008 14:21:49 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id B80503A6C0B for ; Mon, 4 Aug 2008 14:21:49 -0700 (PDT) Received: (qmail 31880 invoked from network); 4 Aug 2008 21:21:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2008 21:21:45 -0000 X-YMail-OSG: 9axuGqYVM1lSXLk8I4VoLxXOBZuYOwz5xIqE38buGqJuLyljQeS5v6izrVH4ncBfqJTJOMswsdvnKF3ltQ7OtK2fMIqi8QfTN8p7DvXfVQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489772E8.2020104@netconfcentral.com> Date: Mon, 04 Aug 2008 14:21:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48970A0D.20702@netconfcentral.com> <1217860502.6212.82.camel@missotis> <48971848.7040408@netconfcentral.com> <20080804.230201.216290442.mbj@tail-f.com> In-Reply-To: <20080804.230201.216290442.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> It already is something else. >> YANG XPath has 'extra features' right? > > No. > >> Buried in the ABNF: >> >> this-variable-keyword = '$this' >> >> There is no normative text anywhere for '$this'. > > Yes there is, you quoted it yourself: > >> From 7.5.2: >> >> The XPath expression is conceptually evaluated in the following >> context: >> >> o The context node is the node in the data tree for which the "must" >> statement is defined. >> >> o The accessible tree is made up of all nodes in the data tree, and >> all leafs with default values. >> >> o The set of namespace declarations is the set of all "import" >> statements' prefix and namespace pairs, and the "prefix" >> statement's prefix for the "namespace" statement's URI. >> >> o The null namespace is defined to be the namespace of the current >> module. >> >> o One variable "this", which is the context node, is defined. > > This is part of the XPath "context" (or execution environment) which > users of XPath must specify. > What about the 'self' axis in sec 2.2 of the XPath 1.0 spec, or the abbreviated syntax '.', for the context node? Why does YANG need a new one? >> YANG requires custom implementation of XPath already. > > No! YANG *does not* require an implementation at all - this is what > we currently say: > > Note that the XPath expression is conceptually evaluated. This > means that an implementation does not have to use an XPath evaluator > on the device. How the evaluation is done in practice is an > implementation decision. > This is a fairly content-free definition. As long as you fully support all of XPath 1.0, and the YANG context, you do not have to use an XPath interpreter. I'm not sure what that means. There are actually 2 YANG contexts -- the definition context will include choice and/or case names (augment target), but not the execution context (must, when targets), which allows the full XPath syntax. The limited syntax allowed in the unique-stmt is really a subset of the definition context, so it doesn't count. > The idea is that the must expression tells the implementer about a > constraint, and I suspect that often this constraint will be enforced > by hand-written code, rather than automatically by the engine. > I agree -- for the agent -- but it is quite likely that an application will try to use the must and when clauses in an automated fashion. > >> I suspect that "sort of using XPath 1.0" is not quite what >> the WG thought we were doing. > > IMO we are using XPath 1.0. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 01:46:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604903A69B9; Tue, 5 Aug 2008 01:46:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19BDA3A6BC0 for ; Tue, 5 Aug 2008 01:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuWleIlknRLb for ; Tue, 5 Aug 2008 01:46:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4E3783A69B9 for ; Tue, 5 Aug 2008 01:46:18 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id EE998D80098; Tue, 5 Aug 2008 10:46:47 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48971848.7040408@netconfcentral.com> References: <1217845614.6212.57.camel@missotis> <48970A0D.20702@netconfcentral.com> <1217860502.6212.82.camel@missotis> <48971848.7040408@netconfcentral.com> Organization: CESNET Date: Tue, 05 Aug 2008 10:46:47 +0200 Message-Id: <1217926007.6860.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDA0LiAwOC4gMjAwOCB2IDA3OjU1IC0wNzAwOgo+IEkg c3VzcGVjdCB0aGF0ICJzb3J0IG9mIHVzaW5nIFhQYXRoIDEuMCIgaXMgbm90IHF1aXRlIHdoYXQK PiB0aGUgV0cgdGhvdWdodCB3ZSB3ZXJlIGRvaW5nLgoKSWYgdGhlIGRyYWZ0IHNhaWQgdGhlIG11 c3QgYXJndW1lbnQgaXMgYSBZdW1ZdW0gZXhwcmVzc2lvbiwgaXQgd291bGQgYmUKbmF0dXJhbCB0 byBleHBlY3QgYSBwcmVjaXNlIGRlZmluaXRpb24gb2Ygc3VjaCBleHByZXNzaW9ucy4gVGhpcyB3 YXksIGl0CmlzIGxlZnQgdG8gdGhlIHJlYWRlciB0byBmaWd1cmUgb3V0IHdoYXQgdGhpcyAiWFBh dGgiIGV4cHJlc3Npb24gcmVhbGx5Cm1lYW5zLCB3aGF0IHJlbWFpbmVkIGZyb20gWFBhdGggc3Rh bmRhcmQgYW5kIHdoYXQgd2FzIG1vZGlmaWVkLiBJdCBpcyBhCnNsaXBwZXJ5IHN1cmZhY2UuCgpM YWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWls aW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Tue Aug 5 02:11:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66043A6A94; Tue, 5 Aug 2008 02:11:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA2D3A6CB1 for ; Tue, 5 Aug 2008 02:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T52jjxV2eugL for ; Tue, 5 Aug 2008 02:11:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4ED3D3A6A94 for ; Tue, 5 Aug 2008 02:11:49 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BF570D800BD for ; Tue, 5 Aug 2008 11:12:19 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20080804.230201.216290442.mbj@tail-f.com> References: <48970A0D.20702@netconfcentral.com> <1217860502.6212.82.camel@missotis> <48971848.7040408@netconfcentral.com> <20080804.230201.216290442.mbj@tail-f.com> Organization: CESNET Date: Tue, 05 Aug 2008 11:12:19 +0200 Message-Id: <1217927539.6860.31.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAwNC4gMDguIDIwMDggdiAyMzowMiArMDIwMDoK PiBJTU8gd2UgYXJlIHVzaW5nIFhQYXRoIDEuMC4KCkRvZXMgaXQgbWVhbiBhbGwgWFBhdGggZnVu Y3Rpb25zIHN1Y2ggYXMgY291bnQoKSBvciBjb250YWlucygpLCBhbmQgYXhlcwpzdWNoIGFzIHBy ZWNlZGluZy1zaWJsaW5nIGFyZSBzdXBwb3J0ZWQ/IENhbiBJIGp1c3QgdXNlIGRvdCAoLikgaW5z dGVhZApvZiAkdGhpcz8KCkluIGFueSBjYXNlLCB0aGUgaGFuZGxpbmcgb2YgbmFtZXNwYWNlcyB2 aW9sYXRlcyB0aGUgWFBhdGggMS4wIHN0YW5kYXJkLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3Rr YSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Aug 5 08:19:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80AE83A6B9E; Tue, 5 Aug 2008 08:19:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D853A6917 for ; Tue, 5 Aug 2008 08:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP+zPY7CDPlo for ; Tue, 5 Aug 2008 08:19:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 61E763A6C54 for ; Tue, 5 Aug 2008 08:19:02 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 56B3620855; Tue, 5 Aug 2008 17:19:31 +0200 (CEST) X-AuditID: c1b4fb3c-ae89cbb00000193b-4a-48986f83e6c6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 238AB205B1; Tue, 5 Aug 2008 17:19:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 17:19:30 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 17:19:30 +0200 Message-ID: <48987022.5070401@ericsson.com> Date: Tue, 05 Aug 2008 17:22:10 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: bernd.linowski.ext@nsn.com References: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> X-OriginalArrivalTime: 05 Aug 2008 15:19:30.0739 (UTC) FILETIME=[A86D3030:01C8F70E] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Representation of instance identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I would like to keep the encoding as present. Having big XML structures as the content of a simple type sounds ugly to me. Imagine reading or even more providing as an input the XML structure. Even if Netconf is mainly a machine interface it should not become a machine-ONLY interface. We also got strong comments from operators that protocols, including machine-machine protocols should be readable (after decryption). The syntax for an instance-identifier is only a subset of the XPath so writing and parsing it should not be so complicated. Balazs bernd.linowski.ext@nsn.com wrote: > Hi Everybody, > > in the NETMOD session last Thursday when Martin B. gave an overview > about YANG features, > I'll also touched the issue of the XML representation of an instance > identifier and was > suggesting a different, XML element based representation, which I'm > going to describe here. > > In the YANG spec it is currently stated that the instance identifier is > encoded > as XPath expression: > "The syntax for an instance-identifier is a subset of the XPath > syntax, which is used to uniquely identify a node in the data tree. > It is an absolute XPath location path in abbreviated syntax, where > axes are not permitted, and predicates are used only for specifying > the values for the key nodes for list entries, or a value of a leaf- > list. Each predicate consists of one equality test per key. Each > key MUST have a corresponding predicate. > > Imho, this way of encoding an instance identifier is a bit to much > biased > in direction of readability but makes creating and parsing instance > identifiers > harder as actually needed (see below). > > Therefore I would like to suggest another approach of > encoding an instance identifier, which uses an XML elements. > - For every node in the location path an XML element with that node > name > is created in the containing XML element (lead-(list) element) > - In case the node in the location path is a list > - a sub-element for every key is created > - that contains the key value as text > > For example the path > > "/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']" > > (YANG spec example) would be represented as > > > > 192.0.2.1 > 80 > > > The XPath notation is of course shorter and more easy to read > for humans. But this XPath expressions do not appear in the model > but in NETCONF payload. And this is (mostly) processed by > machines. > > * So for a NETCONF agent or manager to make use out of an XPath > expression > it has to first parse it. That means the agent / manager has to have > an > XPath expression scanner / parser available that does this job - which > could mean extra implementation respectively integration > effort. > E.g. in the Java 5 platform you have built-in functionality for > executing Xpath expression on an XML Input source. But that does > help too much when the referred instance is currently only represented > in a internal (non-XML) representation (as the referred entity might > not be part of the XML payload of the actual NETCONF PDU) > > * Also encoding instance reference relying on key values > in form of XPath expressions could be sometimes a bit of a challenge > as > the quotation mechanism of XPath is a bit limited afaics > (see XPath http://www.w3.org/TR/xpath#strings, 3.7 [29]. > > Consider an e-mail address like > > "John O'Conner"@example.ie > > This is unusual but valid (see RFC 3696). > Assuming that a node in a list of subscribers > where the e-mail address is the key must be identified > by that value. How do you quote it as part of an XPath > expression? Neither the single-quote form nor the double-quote > form work in that example. > > Having the identifier location path encoded in form of XML elements > as suggested above means > - that the job of encoding is simple and can be done by only > using the XML node tree creation API that is anyway used > - the job of correctly encoding / quoting key values is done > by the XML processor > - the job of parsing the elements of the instance identifier > locating path is done by the XML parser that is anyway used > - the job of decoding key values is done by the XML parser > - no need to implement / embed a XPath expression parser for this > purpose > > > As this is even the only place where XPath expressions are used > in the NETCONG payload afaics, or...? > > So what do you think, wouldn't be an XML element based representation of > instance identifiers be the easier, simpler solution? > > > Best wishes, > Bernd > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 08:59:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3463D3A6848; Tue, 5 Aug 2008 08:59:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDFAB3A68C1 for ; Tue, 5 Aug 2008 08:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wm4YjNxlo86 for ; Tue, 5 Aug 2008 08:59:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 321623A68CD for ; Tue, 5 Aug 2008 08:59:15 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D49D20762; Tue, 5 Aug 2008 17:59:44 +0200 (CEST) X-AuditID: c1b4fb3c-ae89cbb00000193b-5c-489878f000d9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7A5BF20517; Tue, 5 Aug 2008 17:59:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 17:59:44 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 17:59:44 +0200 Message-ID: <4898798F.9050101@ericsson.com> Date: Tue, 05 Aug 2008 18:02:23 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4893C984.2020400@netconfcentral.com> <20080802.224600.68135201.mbj@tail-f.com> In-Reply-To: X-OriginalArrivalTime: 05 Aug 2008 15:59:44.0224 (UTC) FILETIME=[46F9C600:01C8F714] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] module revision and source X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I understand that SMI translation needs a revision clause, but my little playground module inside ericsson might not. On the other hand adding one extra line is not worth the time arguing about. So I would vote mandatory. Balazs Romascanu, Dan (Dan) wrote: > > This was one of the instances where I was surprised by the arguments in > the discussions last Friday. I hope that all participants in the NETMOD > effort are aware about the discussions about SMIv2->XSD translations > vs. SMIv2->YANG->XSD translations and such. Even if REVISION clauses do > not directly generate XML, it is obvious that we need to define a > revision-stmt to be mandatory, even if it was only for compatibility of > translation and comparison of versioning. > > As a more general statement I would suggest that without entering in > limitations where it makes no sense, design decisions take SMIv2 > compatibility as one of the principal objectives in YANG. > > Dan > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 09:24:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8F33A6883; Tue, 5 Aug 2008 09:24:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5CA28C2D9 for ; Tue, 5 Aug 2008 09:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRK8+Pbvny7D for ; Tue, 5 Aug 2008 09:24:42 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id A8A4E3A6A82 for ; Tue, 5 Aug 2008 09:24:42 -0700 (PDT) Received: (qmail 70224 invoked from network); 5 Aug 2008 16:25:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 5 Aug 2008 16:25:12 -0000 X-YMail-OSG: 9PsK4zwVM1msDGFkkBZokfiV9VNHC8s422Dm.YrqE_AKl0jmCbucUjMcYZhrFiNO1dS_LZE.c1B6W2Mq.iOgLZ8wG7IA9RRpttctE7cb1Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48987EE5.40907@netconfcentral.com> Date: Tue, 05 Aug 2008 09:25:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] XPath prefix on rpc/input and output X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, What was the decision on the XML namespace for the input and output keywords within a definition context XPath expression? Is it the current module namespace? Otherwise a new YANG namespace would be needed for this purpose. I am currently generating an error if there is any prefix on 'input' or 'output', which is wrong. Current: /nc:edit-config/input/nc:test-option /ncx:load-module/input/ncx:modpath New: /nc:edit-config/nc:input/nc:test-option /ncx:load-module/ncx:input/ncx:modpath So 'input' is considered to be in the current module namespace, as if 'input' and 'output' are just more container objects. (Note that in an element, the input node is not present.) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 13:19:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A199A28C339; Tue, 5 Aug 2008 13:19:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B817328C339 for ; Tue, 5 Aug 2008 13:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkWdX0Eysmcm for ; Tue, 5 Aug 2008 13:18:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 024BC3A6935 for ; Tue, 5 Aug 2008 13:18:58 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id EB46F76C4CB; Tue, 5 Aug 2008 22:18:58 +0200 (CEST) Date: Tue, 05 Aug 2008 22:18:56 +0200 (CEST) Message-Id: <20080805.221856.155231484.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1217926007.6860.22.camel@missotis> References: <1217860502.6212.82.camel@missotis> <48971848.7040408@netconfcentral.com> <1217926007.6860.22.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Ladislav Lhotka wrote: > This way, it > is left to the reader to figure out what this "XPath" expression really > means, what remained from XPath standard and what was modified. I'm guessing that this statement refers to something else than which nodes unprefixed elements refer to. Could you be more specific? What text should we add to make sure there is no confusion about the fact that we use unmodified xpath 1.0? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 13:20:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13ED23A659B; Tue, 5 Aug 2008 13:20:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E0E3A689C for ; Tue, 5 Aug 2008 13:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYq+wHM3K8ZX for ; Tue, 5 Aug 2008 13:20:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A75E13A659B for ; Tue, 5 Aug 2008 13:20:38 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 110AF76C4CB; Tue, 5 Aug 2008 22:20:50 +0200 (CEST) Date: Tue, 05 Aug 2008 22:20:47 +0200 (CEST) Message-Id: <20080805.222047.153936243.mbj@tail-f.com> To: bernd.linowski.ext@nsn.com From: Martin Bjorklund In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> References: <46DCD7DCAFF0E94796B7C2894ED9F26604519B93@esebe103.NOE.Nokia.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Representation of instance identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, wrote: > I'll also touched the issue of the XML representation of an instance > identifier and was > suggesting a different, XML element based representation, which I'm > going to describe here. > > In the YANG spec it is currently stated that the instance identifier is > encoded > as XPath expression: > "The syntax for an instance-identifier is a subset of the XPath > syntax, which is used to uniquely identify a node in the data tree. > It is an absolute XPath location path in abbreviated syntax, where > axes are not permitted, and predicates are used only for specifying > the values for the key nodes for list entries, or a value of a leaf- > list. Each predicate consists of one equality test per key. Each > key MUST have a corresponding predicate. > > Imho, this way of encoding an instance identifier is a bit to much > biased > in direction of readability but makes creating and parsing instance > identifiers > harder as actually needed (see below). I don't agree with this statement. I don't think that such an instance identifier is harder to parse than the alternative you propose. > * So for a NETCONF agent or manager to make use out of an XPath > expression > it has to first parse it. That means the agent / manager has to have > an > XPath expression scanner / parser available that does this job I don't agree; an instance identifier happens to be (by design) valid XPath, but that does not mean that you have to be able to parse full XPath. An instance identifier is easily parsed with custom code. > As this is even the only place where XPath expressions are used > in the NETCONG payload afaics, or...? Andy pointed to the error-path element in rpc-error. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 13:28:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53293A6A5F; Tue, 5 Aug 2008 13:28:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70923A6B22 for ; Tue, 5 Aug 2008 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S0syOvSMlzq for ; Tue, 5 Aug 2008 13:28:16 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E48083A6AEC for ; Tue, 5 Aug 2008 13:28:15 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 36A0076C4CB; Tue, 5 Aug 2008 22:28:47 +0200 (CEST) Date: Tue, 05 Aug 2008 22:28:43 +0200 (CEST) Message-Id: <20080805.222843.179173610.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489772E8.2020104@netconfcentral.com> References: <48971848.7040408@netconfcentral.com> <20080804.230201.216290442.mbj@tail-f.com> <489772E8.2020104@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> YANG requires custom implementation of XPath already. > > No! YANG *does not* require an implementation at all - this is what > > we currently say: > > Note that the XPath expression is conceptually evaluated. This > > means that an implementation does not have to use an XPath evaluator > > on the device. How the evaluation is done in practice is an > > implementation decision. > > > > This is a fairly content-free definition. > As long as you fully support all of XPath 1.0, and > the YANG context, you do not have to use an XPath > interpreter. I'm not sure what that means. It means that the must expression specifies the constraint, and you are free to implement this constraint enforcement in any way you want. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 13:31:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B963A659B; Tue, 5 Aug 2008 13:31:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E0A3A69A9 for ; Tue, 5 Aug 2008 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df1ZFFDZdPN7 for ; Tue, 5 Aug 2008 13:31:04 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DDBA23A659B for ; Tue, 5 Aug 2008 13:31:03 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 03D1D76C4CB; Tue, 5 Aug 2008 22:31:34 +0200 (CEST) Date: Tue, 05 Aug 2008 22:31:31 +0200 (CEST) Message-Id: <20080805.223131.107834574.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48987EE5.40907@netconfcentral.com> References: <48987EE5.40907@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath prefix on rpc/input and output X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > What was the decision on the XML namespace for the input > and output keywords within a definition context XPath > expression? Is it the current module namespace? IMO using the current module namespace is easiest. I don't see any compelling reason for inventing a new namespace for these nodes. So if noone objects, I will clarify this in the spec. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 13:44:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634403A6CB3; Tue, 5 Aug 2008 13:44:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2253A6CB3 for ; Tue, 5 Aug 2008 13:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cVzxXIaIZgn for ; Tue, 5 Aug 2008 13:44:56 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 3F7063A6B4A for ; Tue, 5 Aug 2008 13:44:56 -0700 (PDT) Received: (qmail 36891 invoked from network); 5 Aug 2008 20:45:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 5 Aug 2008 20:45:26 -0000 X-YMail-OSG: 0k9XchoVM1k672QvuFEJ.ji07_ldKldf9vIBk7Ht_OZ0NhaRif74f_rcfCIheGqRn5mlFpmH2iuUCNx5cekJ2E1tzMk1rcAOMQeViiXkkQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4898BBE4.7030808@netconfcentral.com> Date: Tue, 05 Aug 2008 13:45:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48987EE5.40907@netconfcentral.com> <20080805.223131.107834574.mbj@tail-f.com> In-Reply-To: <20080805.223131.107834574.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XPath prefix on rpc/input and output X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> What was the decision on the XML namespace for the input >> and output keywords within a definition context XPath >> expression? Is it the current module namespace? > > IMO using the current module namespace is easiest. I don't see any > compelling reason for inventing a new namespace for these nodes. So > if noone objects, I will clarify this in the spec. > > Also clarify if it is legal to add an input or putput via augment to an rpc without one. There is also only zero or on of these nodes. If you define /foo:my-rpc/foo:input/foo:my-param, or even just /foo:my-rpc, then another module cannot add another input node: module bar { ... augment "/foo:my-rpc" { input { leaf aug-param { type string; } } } See why this is broken? We should only allow this form to augment input and output: module bar { ... augment "/foo:my-rpc/foo:input" { leaf aug-param { type string; } } So is an error generated if foo:input is not actually defined, but it is used in an augment target? It should be treated as an implied NP container, so it is added if the rpc-stmt is ever augmented. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 13:51:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278A83A6903; Tue, 5 Aug 2008 13:51:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71EB93A6903 for ; Tue, 5 Aug 2008 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9oDt5Wszers for ; Tue, 5 Aug 2008 13:51:21 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AA7A23A68BF for ; Tue, 5 Aug 2008 13:51:21 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 669C876C4CB; Tue, 5 Aug 2008 22:51:25 +0200 (CEST) Date: Tue, 05 Aug 2008 22:51:22 +0200 (CEST) Message-Id: <20080805.225122.139771251.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4898BBE4.7030808@netconfcentral.com> References: <48987EE5.40907@netconfcentral.com> <20080805.223131.107834574.mbj@tail-f.com> <4898BBE4.7030808@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath prefix on rpc/input and output X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Also clarify if it is legal to add an input or putput > via augment to an rpc without one. [...] > It should be treated as an implied NP container, so it is added > if the rpc-stmt is ever augmented. I started to do this on my way back from Dublin. Will be in the next version of the draft, /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 14:01:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8548C3A68B7; Tue, 5 Aug 2008 14:01:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C71F3A6AB5 for ; Tue, 5 Aug 2008 14:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0bysGfkSJUG for ; Tue, 5 Aug 2008 14:01:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 879ED3A68B7 for ; Tue, 5 Aug 2008 14:01:29 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id CB378D800BD; Tue, 5 Aug 2008 23:02:00 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080805.221856.155231484.mbj@tail-f.com> References: <1217860502.6212.82.camel@missotis> <48971848.7040408@netconfcentral.com> <1217926007.6860.22.camel@missotis> <20080805.221856.155231484.mbj@tail-f.com> Organization: CESNET Date: Tue, 05 Aug 2008 23:02:01 +0200 Message-Id: <1217970121.6212.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDDmnQgMDUuIDA4LiAyMDA4IHYgMjI6MTggKzAyMDA6 Cj4gSGksCj4gCj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToKPiA+ IFRoaXMgd2F5LCBpdAo+ID4gaXMgbGVmdCB0byB0aGUgcmVhZGVyIHRvIGZpZ3VyZSBvdXQgd2hh dCB0aGlzICJYUGF0aCIgZXhwcmVzc2lvbiByZWFsbHkKPiA+IG1lYW5zLCB3aGF0IHJlbWFpbmVk IGZyb20gWFBhdGggc3RhbmRhcmQgYW5kIHdoYXQgd2FzIG1vZGlmaWVkLgo+IAo+IEknbSBndWVz c2luZyB0aGF0IHRoaXMgc3RhdGVtZW50IHJlZmVycyB0byBzb21ldGhpbmcgZWxzZSB0aGFuIHdo aWNoCj4gbm9kZXMgdW5wcmVmaXhlZCBlbGVtZW50cyByZWZlciB0by4gIENvdWxkIHlvdSBiZSBt b3JlIHNwZWNpZmljPyAgV2hhdAo+IHRleHQgc2hvdWxkIHdlIGFkZCB0byBtYWtlIHN1cmUgdGhl cmUgaXMgbm8gY29uZnVzaW9uIGFib3V0IHRoZSBmYWN0Cj4gdGhhdCB3ZSB1c2UgdW5tb2RpZmll ZCB4cGF0aCAxLjA/CgpXaXRoIHRoaXMgSSByZXBsaWVkIHRvIEFuZHkncyBjbGFpbSB0aGF0IHRo ZSBtdXN0IGV4cHJlc3Npb24gaW4gZmFjdApkb2Vzbid0IHVzZSBYUGF0aC4gQXMgSSBzYWlkLCBJ IHRoaW5rIHRoZSBuYW1lc3BhY2UgaGFuZGxpbmcgaXMgbm90IGluCmFjY29yZCB3aXRoIFhQYXRo IDEuMCBzcGVjIGFuZCBhbHNvIHRoZSAnJHRoaXMnIHZhcmlhYmxlIGlzIG5vdCBpbiB0aGUKc3Bl YyAtIGluIGZhY3QsIGl0J3MgSU1PIG5vdCBuZWVkZWQsIHRoZSAnc2VsZicgYXhpcyAob3IgJy4n KSBhbmQgdGhlCmN1cnJlbnQoKSBmdW5jdGlvbiBzaG91bGQgZG8uCgpMYWRhCgotLSAKTGFkaXNs YXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9k QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Tue Aug 5 14:11:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7B53A68B7; Tue, 5 Aug 2008 14:11:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC533A6AF9 for ; Tue, 5 Aug 2008 14:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc21F0F9f+BC for ; Tue, 5 Aug 2008 14:11:04 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8F0023A68B7 for ; Tue, 5 Aug 2008 14:11:04 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id E6A1376C4CB; Tue, 5 Aug 2008 23:11:35 +0200 (CEST) Date: Tue, 05 Aug 2008 23:11:32 +0200 (CEST) Message-Id: <20080805.231132.70478941.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1217970121.6212.21.camel@missotis> References: <1217926007.6860.22.camel@missotis> <20080805.221856.155231484.mbj@tail-f.com> <1217970121.6212.21.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > With this I replied to Andy's claim that the must expression in fact > doesn't use XPath. As I said, I think the namespace handling is not in > accord with XPath 1.0 spec and also the '$this' variable is not in the > spec XPath 1.0 supports variables. We define one variable called 'this'. > - in fact, it's IMO not needed, the 'self' axis (or '.') and the > current() function should do. No, since '.' selects the current context node, but the context node changes in the expression. Compare leaf address { type keyref { path "../../interface[name = $this/../ifname]/address/ip"; with leaf address { type keyref { path "../../interface[name = ./../ifname]/address/ip"; $this refers to the 'address' node, but the '.' in the second expression refers to the 'interface' node. You can verify this by experimenting with some xpath expressions. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 5 22:44:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112743A6940; Tue, 5 Aug 2008 22:44:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2BF3A69E1 for ; Tue, 5 Aug 2008 22:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbA-vejkYrKz for ; Tue, 5 Aug 2008 22:44:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6BEB73A69D5 for ; Tue, 5 Aug 2008 22:44:17 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 04C4BD800BD; Wed, 6 Aug 2008 07:44:48 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080805.231132.70478941.mbj@tail-f.com> References: <1217926007.6860.22.camel@missotis> <20080805.221856.155231484.mbj@tail-f.com> <1217970121.6212.21.camel@missotis> <20080805.231132.70478941.mbj@tail-f.com> Organization: CESNET Date: Wed, 06 Aug 2008 07:44:47 +0200 Message-Id: <1218001487.6297.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > > - in fact, it's IMO not needed, the 'self' axis (or '.') and the > > current() function should do. > > No, since '.' selects the current context node, but the context node > changes in the expression. > > Compare > > leaf address { > type keyref { > path "../../interface[name = $this/../ifname]/address/ip"; path "../../interface[name = current()/../ifname]/address/ip"; > > with > > leaf address { > type keyref { > path "../../interface[name = ./../ifname]/address/ip"; > > $this refers to the 'address' node, but the '.' in the second > expression refers to the 'interface' node. > Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 01:37:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB323A6804; Wed, 6 Aug 2008 01:37:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F403A6ADF for ; Wed, 6 Aug 2008 01:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_26=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS++-zzD1BW1 for ; Wed, 6 Aug 2008 01:36:59 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 31D743A6804 for ; Wed, 6 Aug 2008 01:36:59 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 72407D800BD for ; Wed, 6 Aug 2008 10:37:31 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 06 Aug 2008 10:37:31 +0200 Message-Id: <1218011851.6297.61.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] DSDL translation of datatypes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I propose to include DSDL translation of standard datatype modules in the "datatypes" draft using the compact syntax. This means that each module will be first translated with pyang, e.g., pyang -f dsdl -o ieee-types.rng ieee-types.yang and then converted to the compact syntax using trang: java -jar trang.jar -I rng -O rnc ieee-types.rng ieee-types.rnc The result is shown below. Please have a look and tell me your opinion. The only thing that potentially has to be hand-edited are long lines - for example, long regexp patterns can be broken into the same chunks as in the original YANG module, just using the compact syntax concatenation operator '~'. Also note that the current release 0.9.1 of pyang will prefix all names of RELAX NG named patterns with double underscore '__'. In order to get the output below, checkout the head revision from the SVN repository (see http://code.google.com/p/pyang/source/checkout), or wait till the next release. Lada ============================= ieee-types.rnc=========================== namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace dc = "http://purl.org/dc/terms" namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" namespace sch = "http://purl.oclc.org/dsdl/schematron" dc:creator [ "YANG Language Design Team" ] dc:description [ "This module contains standard derived YANG types\x{a}" ~ "for IEEE 802 addresses and related things." ] dc:issued [ "2008-05-22" ] dc:source [ "YANG module 'ieee-types' (automatic translation)" ] dc:contributor [ "Juergen Schoenwaelder (Editor)\x{a}" ~ "" ] ## The mac-address type represents an 802 MAC address ## represented in the `canonical' order defined by ## IEEE 802.1a, i.e., as if it were transmitted least ## significant bit first, even though 802.5 (in contrast ## to other 802.x protocols) requires MAC addresses to ## be transmitted most significant bit first. ## See: RFC 2579 STD 58 mac-address = yang-types__phys-address yang-types__phys-address = xsd:string ## The bridgeid type represents identifers that uniquely ## identify a bridge. Its first four hexadecimal digits ## contain a priority value followed by a colon. The ## remaining characters contain the MAC address used to ## refer to a bridge in a unique fashion (typically, the ## numerically smallest MAC address of all ports on the ## bridge). ## See: RFC 4188 bridgeid = xsd:string { pattern = "[0-9a-fA-F]{4}:([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}" } ## The vlanid type uniquely identifies a VLAN. This is ## the 12-bit VLAN-ID used in the VLAN Tag header. The ## range is defined by the referenced specification. ## See: IEEE Std 802.1Q 2003 Edition, Virtual Bridged Local ## Area Networks. vlanid = xsd:unsignedShort { minInclusive = "1" maxInclusive = "4094" } -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 05:23:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23513A6BFC; Wed, 6 Aug 2008 05:23:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A2328C353 for ; Wed, 6 Aug 2008 05:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.317 X-Spam-Level: X-Spam-Status: No, score=0.317 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6HOoopG1xj6 for ; Wed, 6 Aug 2008 05:23:56 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6F52128C351 for ; Wed, 6 Aug 2008 05:23:56 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A0DFAD80098 for ; Wed, 6 Aug 2008 14:24:08 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 06 Aug 2008 14:24:09 +0200 Message-Id: <1218025449.6297.87.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I Dublin I proposed to allow when statement outside augment, as a general method for adding conditional contents. In my view, when condition { ... } could appear in all places where augment . { when condition { ... } } is currently allowed - it is supposed to do the same thing. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 06:44:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7523A68BF; Wed, 6 Aug 2008 06:44:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6C13A69DD for ; Wed, 6 Aug 2008 06:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAu-sTXXkZrp for ; Wed, 6 Aug 2008 06:44:19 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id B98B13A68BF for ; Wed, 6 Aug 2008 06:44:19 -0700 (PDT) Received: (qmail 37299 invoked from network); 6 Aug 2008 13:44:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 13:44:35 -0000 X-YMail-OSG: aHs8YNQVM1nufzbsjDS6fulAax81P6hC3z1H_owkWif2PlZLDpZh6g7dXPkpfHEmHnBP00rhr2p7FIt3jLw5mfFy5VR2_yU3tG4oeHsqvA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4899AAC1.1060902@netconfcentral.com> Date: Wed, 06 Aug 2008 06:44:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218025449.6297.87.camel@missotis> In-Reply-To: <1218025449.6297.87.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > I Dublin I proposed to allow when statement outside augment, as a > general method for adding conditional contents. In my view, > > when condition { > ... > } > > could appear in all places where > > augment . { > when condition { > ... > } > } > > is currently allowed - it is supposed to do the same thing. > I am opposed to this construct. IMO, YANG is already quite flexible, and it can already be very difficult to determine by inspection what a module actually requires. This is the hack version of the full #ifdef. I do not see how this offers interoperability. Would you allow this: list some-list { when "some-complicated-condition" { key "one-version"; } when "some-other-condition" { key "another-version"; } when "some-nested-conditions" { when "even-more-conditions" { key "yet-a-third-version"; } } ... } > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 08:00:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A06628C393; Wed, 6 Aug 2008 08:00:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D097C28C3A1 for ; Wed, 6 Aug 2008 07:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPLUTifTUAas for ; Wed, 6 Aug 2008 07:59:59 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 931B43A6BDE for ; Wed, 6 Aug 2008 07:59:44 -0700 (PDT) Received: (qmail 26310 invoked from network); 6 Aug 2008 15:00:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 15:00:13 -0000 X-YMail-OSG: 5zV7rl4VM1kjaJzXT3gepEj4V7NgDOiqh4gQXLvdsjQbMMaoUgXDJpPoPTnEr_Cloy8UJ8gTg.2GVtvymb0PD9ZrufVHMIvHE1FQXXz3.w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4899BC7B.1090905@netconfcentral.com> Date: Wed, 06 Aug 2008 08:00:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] standards vs. research X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I have some concerns that the NETMOD WG thinks YANG is an open sandbox that we can use to provide some really great new features. Documents headed for the standards track should actually be more concerned with maximum interoperability, rather than maximum new (unproven) features. IMO, we should standardize proven concepts and technology, even if this isn't always the bleeding edge in features. The IRTF is available for that, not the IETF. I know from RMON APM-MIB (and other) experience, that SMIv2 has a 'complexity ceiling'. If you try to create a MIB module too complicated, it will never be implemented by anybody. Ever. But it took us 10 years or so to reach the upper bound of SMIv2 data modeling capabilities. We started out with much simpler MIB modules and gained interoperability experience that way. YANG 1.0 is already getting near the complexity ceiling, and the 80/20 rule should be used to reign it in. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 08:08:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47FA3A67D8; Wed, 6 Aug 2008 08:08:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8D428C358 for ; Wed, 6 Aug 2008 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqA+yzQ4MNRQ for ; Wed, 6 Aug 2008 08:08:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 222383A6A7A for ; Wed, 6 Aug 2008 08:08:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E7B8FD80098; Wed, 6 Aug 2008 17:08:33 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4899AAC1.1060902@netconfcentral.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> Organization: CESNET Date: Wed, 06 Aug 2008 17:08:34 +0200 Message-Id: <1218035314.6297.94.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDA2LiAwOC4gMjAwOCB2IDA2OjQ0IC0wNzAwOgoKPiBJ IGFtIG9wcG9zZWQgdG8gdGhpcyBjb25zdHJ1Y3QuCj4gSU1PLCBZQU5HIGlzIGFscmVhZHkgcXVp dGUgZmxleGlibGUsIGFuZCBpdCBjYW4KPiBhbHJlYWR5IGJlIHZlcnkgZGlmZmljdWx0IHRvIGRl dGVybWluZSBieSBpbnNwZWN0aW9uCj4gd2hhdCBhIG1vZHVsZSBhY3R1YWxseSByZXF1aXJlcy4K CkJ1dCB3aGVuZXZlciBJIHdhbnQgdG8gdXNlIGl0LCBJIGNhbiBpbnNlcnQgdGhlIGNvbnN0cnVj dCB3aXRoCiJhdWdtZW50IC4iLCByaWdodD8gQW5kIHRoaXMgaXMgZXZlbiBtb3JlIGhhY2t5Lgo+ IAo+IFRoaXMgaXMgdGhlIGhhY2sgdmVyc2lvbiBvZiB0aGUgZnVsbCAjaWZkZWYuCj4gSSBkbyBu b3Qgc2VlIGhvdyB0aGlzIG9mZmVycyBpbnRlcm9wZXJhYmlsaXR5Lgo+IAo+IFdvdWxkIHlvdSBh bGxvdyB0aGlzOgoKTm8sIHNpbmNlIGtleSBub3cgY2Fubm90IGJlIGEgc3Vic3RhdGVtZW50IG9m IGF1Z21lbnQuCgo+IAo+ICAgIGxpc3Qgc29tZS1saXN0IHsKPiAgICAgIHdoZW4gInNvbWUtY29t cGxpY2F0ZWQtY29uZGl0aW9uIiB7Cj4gICAgICAgICBrZXkgIm9uZS12ZXJzaW9uIjsKPiAgICAg IH0KPiAgICAgIHdoZW4gInNvbWUtb3RoZXItY29uZGl0aW9uIiB7Cj4gICAgICAgICAga2V5ICJh bm90aGVyLXZlcnNpb24iOwo+ICAgICAgfQo+ICAgICAgd2hlbiAic29tZS1uZXN0ZWQtY29uZGl0 aW9ucyIgewo+ICAgICAgICAgIHdoZW4gImV2ZW4tbW9yZS1jb25kaXRpb25zIiB7Cj4gICAgICAg ICAgICAga2V5ICJ5ZXQtYS10aGlyZC12ZXJzaW9uIjsKPiAgICAgICAgICB9Cj4gICAgICB9Cj4g Cj4gICAgICAuLi4KPiAgICB9CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQ IEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Aug 6 08:10:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018E93A6891; Wed, 6 Aug 2008 08:10:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567EB28C39C for ; Wed, 6 Aug 2008 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQcrVhS9kYw1 for ; Wed, 6 Aug 2008 08:10:16 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id C56EB3A6AC8 for ; Wed, 6 Aug 2008 08:10:16 -0700 (PDT) Received: (qmail 41756 invoked from network); 6 Aug 2008 15:10:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 15:10:18 -0000 X-YMail-OSG: kOKwseMVM1nH15qoLhZ1de1ZzxA6pt_f0kYtw3uvmOn8etR1j.M3PuZZXfVMPqZRCyFODdLCWVYaOh0RajXOqO9S0g9Jl8KjFhy7aesx1pd1TLhECF2EDzrKXd1ByKc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4899BED9.9020609@netconfcentral.com> Date: Wed, 06 Aug 2008 08:10:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218011851.6297.61.camel@missotis> In-Reply-To: <1218011851.6297.61.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] DSDL translation of datatypes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, >.... IMO, the DSDL syntax is not an improvement over XSD. Here is the XSD that yangdump generates for the same file: http://www.netconfcentral.com/xsd/ieee-types_2008-05-22.xsd I am not convinced that XSD is dead and this is the future instead. I see plenty of I-Ds and RFCs published with XSDs in them, and doubt this practice will stop. Andy > ============================= ieee-types.rnc=========================== > namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" > namespace dc = "http://purl.org/dc/terms" > namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" > namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" > namespace sch = "http://purl.oclc.org/dsdl/schematron" > > dc:creator [ "YANG Language Design Team" ] > dc:description [ > "This module contains standard derived YANG types\x{a}" ~ > "for IEEE 802 addresses and related things." > ] > dc:issued [ "2008-05-22" ] > dc:source [ "YANG module 'ieee-types' (automatic translation)" ] > dc:contributor [ > "Juergen Schoenwaelder (Editor)\x{a}" ~ > "" > ] > > ## The mac-address type represents an 802 MAC address > ## represented in the `canonical' order defined by > ## IEEE 802.1a, i.e., as if it were transmitted least > ## significant bit first, even though 802.5 (in contrast > ## to other 802.x protocols) requires MAC addresses to > ## be transmitted most significant bit first. > > ## See: RFC 2579 STD 58 > mac-address = yang-types__phys-address > yang-types__phys-address = xsd:string > > ## The bridgeid type represents identifers that uniquely > ## identify a bridge. Its first four hexadecimal digits > ## contain a priority value followed by a colon. The > ## remaining characters contain the MAC address used to > ## refer to a bridge in a unique fashion (typically, the > ## numerically smallest MAC address of all ports on the > ## bridge). > > ## See: RFC 4188 > bridgeid = > xsd:string { > pattern = "[0-9a-fA-F]{4}:([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}" > } > > ## The vlanid type uniquely identifies a VLAN. This is > ## the 12-bit VLAN-ID used in the VLAN Tag header. The > ## range is defined by the referenced specification. > > ## See: IEEE Std 802.1Q 2003 Edition, Virtual Bridged Local > ## Area Networks. > vlanid = xsd:unsignedShort { minInclusive = "1" maxInclusive = "4094" } > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 08:17:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D31F3A63EC; Wed, 6 Aug 2008 08:17:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E97E3A6888 for ; Wed, 6 Aug 2008 08:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIu97t9nP6Q3 for ; Wed, 6 Aug 2008 08:17:42 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 7BCDE3A63EC for ; Wed, 6 Aug 2008 08:17:42 -0700 (PDT) Received: (qmail 16003 invoked from network); 6 Aug 2008 15:18:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 15:18:14 -0000 X-YMail-OSG: .em6OQMVM1lfjwShgTTv7WDXMOnKoLYFNJ_ntLAlPGXeSWmR9kh1.lQb3wMQWw.KMt.PD6d0KQcIyCA98lz2rgPBQKjGJ59ONGbH6vYwPw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4899C0B5.5070509@netconfcentral.com> Date: Wed, 06 Aug 2008 08:18:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> In-Reply-To: <1218035314.6297.94.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTdCAwNi4gMDgu IDIwMDggdiAwNjo0NCAtMDcwMDoKPiAKPj4gSSBhbSBvcHBvc2VkIHRvIHRoaXMgY29uc3RydWN0 Lgo+PiBJTU8sIFlBTkcgaXMgYWxyZWFkeSBxdWl0ZSBmbGV4aWJsZSwgYW5kIGl0IGNhbgo+PiBh bHJlYWR5IGJlIHZlcnkgZGlmZmljdWx0IHRvIGRldGVybWluZSBieSBpbnNwZWN0aW9uCj4+IHdo YXQgYSBtb2R1bGUgYWN0dWFsbHkgcmVxdWlyZXMuCj4gCj4gQnV0IHdoZW5ldmVyIEkgd2FudCB0 byB1c2UgaXQsIEkgY2FuIGluc2VydCB0aGUgY29uc3RydWN0IHdpdGgKPiAiYXVnbWVudCAuIiwg cmlnaHQ/IEFuZCB0aGlzIGlzIGV2ZW4gbW9yZSBoYWNreS4KClRoZXJlIGFscmVhZHkgaXMgYSB3 YXkgdG8gYWNoaWV2ZSB5b3VyICdmZWF0dXJlJywgc28gd2h5IGFkZCBhbm90aGVyCm9uZSB0byBz YXZlIGEgZmV3IGNoYXJhY3RlcnMgaW4gdGhlIFlBTkcgZmlsZS4KSSB0aG91Z2h0IGl0IHdhcyBh IGJpZyBkZWFsIHRvIHByb3ZpZGUgMiB3YXlzCm9mIGRvaW5nIHRoZSBzYW1lIHRoaW5nPwoKSU1P LCB0aGlzIERNIGRlc2lnbiBpcyBhd2Z1bCwgYW5kIGNvbXBsZXRlbHkgc3VidmVydHMKdGhlIGlu dGVudCBvZiBhdWdtZW50LXN0bXQuICAgSSBtdWNoIHByZWZlciB0byBkZWFsCndpdGggb3B0aW9u YWxpdHkgdGhyb3VnaCBtb2R1bGUgY29uZm9ybWFuY2UgJ3BhY2thZ2VzJywKcmF0aGVyIHRoZW4g ZW1iZWQgaXQgaW50byB0aGUgbW9kdWxlLgoKVGhhdCBtZXRob2QgaGFzIHByb3ZlbiB0byB3b3Jr IHdpdGggU01JdjIuCldoYXQgaXMgdGhlIHByb29mIHRoYXQgdGhpcyBtZXRob2Qgd2lsbCB3b3Jr CmZvciBJRVRGIHN0YW5kYXJkIGRhdGEgbW9kZWxzPwoKCgo+PiBUaGlzIGlzIHRoZSBoYWNrIHZl cnNpb24gb2YgdGhlIGZ1bGwgI2lmZGVmLgo+PiBJIGRvIG5vdCBzZWUgaG93IHRoaXMgb2ZmZXJz IGludGVyb3BlcmFiaWxpdHkuCj4+Cj4+IFdvdWxkIHlvdSBhbGxvdyB0aGlzOgo+IAo+IE5vLCBz aW5jZSBrZXkgbm93IGNhbm5vdCBiZSBhIHN1YnN0YXRlbWVudCBvZiBhdWdtZW50Lgo+IAo+PiAg ICBsaXN0IHNvbWUtbGlzdCB7Cj4+ICAgICAgd2hlbiAic29tZS1jb21wbGljYXRlZC1jb25kaXRp b24iIHsKPj4gICAgICAgICBrZXkgIm9uZS12ZXJzaW9uIjsKPj4gICAgICB9Cj4+ICAgICAgd2hl biAic29tZS1vdGhlci1jb25kaXRpb24iIHsKPj4gICAgICAgICAga2V5ICJhbm90aGVyLXZlcnNp b24iOwo+PiAgICAgIH0KPj4gICAgICB3aGVuICJzb21lLW5lc3RlZC1jb25kaXRpb25zIiB7Cj4+ ICAgICAgICAgIHdoZW4gImV2ZW4tbW9yZS1jb25kaXRpb25zIiB7Cj4+ICAgICAgICAgICAgIGtl eSAieWV0LWEtdGhpcmQtdmVyc2lvbiI7Cj4+ICAgICAgICAgIH0KPj4gICAgICB9Cj4+Cj4+ICAg ICAgLi4uCj4+ICAgIH0KPiAKPiBMYWRhCj4gCgpBbmR5CgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Aug 6 08:29:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1861F3A67D8; Wed, 6 Aug 2008 08:29:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E3128C3B6 for ; Wed, 6 Aug 2008 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlpU+CekB8iF for ; Wed, 6 Aug 2008 08:29:30 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BE9A328C39C for ; Wed, 6 Aug 2008 08:29:28 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 13549D800C5 for ; Wed, 6 Aug 2008 17:29:53 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4899BED9.9020609@netconfcentral.com> References: <1218011851.6297.61.camel@missotis> <4899BED9.9020609@netconfcentral.com> Organization: CESNET Date: Wed, 06 Aug 2008 17:29:54 +0200 Message-Id: <1218036594.6297.115.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] DSDL translation of datatypes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDA2LiAwOC4gMjAwOCB2IDA4OjEwIC0wNzAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IEhpLAo+ID4uLi4uCj4gCj4gCj4gSU1PLCB0aGUgRFNE TCBzeW50YXggaXMgbm90IGFuIGltcHJvdmVtZW50IG92ZXIgWFNELgoKRFNETCBpcyBpbiB0aGUg Y2hhcnRlciB3aGVyZWFzIFhTRCBpcyBub3QuIE1vcmVvdmVyLCBJIGZpbmQgdGhlIGNvbXBhY3QK c3ludGF4IGVhc2llciB0byByZWFkIGFuZCB1bmRlcnN0YW5kIHRoYW4gWE1MLgoKPiBIZXJlIGlz IHRoZSBYU0QgdGhhdCB5YW5nZHVtcCBnZW5lcmF0ZXMgZm9yIHRoZSBzYW1lIGZpbGU6Cj4gCj4g ICAgIGh0dHA6Ly93d3cubmV0Y29uZmNlbnRyYWwuY29tL3hzZC9pZWVlLXR5cGVzXzIwMDgtMDUt MjIueHNkCj4gCj4gSSBhbSBub3QgY29udmluY2VkIHRoYXQgWFNEIGlzIGRlYWQgYW5kIHRoaXMg aXMgdGhlIGZ1dHVyZSBpbnN0ZWFkLgoKTW9zdCBwZW9wbGUgdGhhdCByZWFsbHkgd29yayB3aXRo IFhNTCB0aGluayBpdCBpcyB0aGUgY2FzZSwgc2VlLCBlLmcuLApUaW0gQnJheSdzIHR1dG9yaWFs IGhlIGdhdmUgZHVyaW5nIElFVEYgNzAuIEV2ZW4gZ3JvdXBzIGluIFczQyB0aGF0CmV2ZW50dWFs bHkgcHVibGlzaCBYU0Qgc2NoZW1hcyB1c2UgUkVMQVggTkcgZm9yIHRoZSBkZXZlbG9wbWVudCBh bmQgdGhlbgp0cmFuc2xhdGUgdGhlIHJlc3VsdCB3aXRoIHRyYW5nLgoKPiBJIHNlZSBwbGVudHkg b2YgSS1EcyBhbmQgUkZDcyBwdWJsaXNoZWQgd2l0aCBYU0RzIGluIHRoZW0sCj4gYW5kIGRvdWJ0 IHRoaXMgcHJhY3RpY2Ugd2lsbCBzdG9wLgoKWWVzLCB0aGVyZSBpcyBzdGlsbCBhIGxvdCBvZiBz ZW50aW1lbnQgZm9yIFhTRCBpbiBJRVRGLiBJIGZpbmQgaXQKdW5mb3J0dW5hdGUuIEphbWVzIENs YXJrIHByZXNlbnRlZCB0aGUgYXJndW1lbnRzIGluIGZhdm9yIG9mIHVzaW5nIFJFTEFYCk5HIGlu IElFVEYgYWxyZWFkeSBpbiAyMDAyOgoKaHR0cDovL3d3dy5pbWMub3JnL2lldGYteG1sLXVzZS9t YWlsLWFyY2hpdmUvbXNnMDAyMTcuaHRtbAoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VT TkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Aug 6 08:34:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A051728C3A4; Wed, 6 Aug 2008 08:34:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D8A28C3A4 for ; Wed, 6 Aug 2008 08:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.883 X-Spam-Level: X-Spam-Status: No, score=-0.883 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-nbqCmlM42Z for ; Wed, 6 Aug 2008 08:34:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 93E2C28C3A1 for ; Wed, 6 Aug 2008 08:34:24 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 20EFFD800C0; Wed, 6 Aug 2008 17:34:58 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4899C0B5.5070509@netconfcentral.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> Organization: CESNET Date: Wed, 06 Aug 2008 17:34:59 +0200 Message-Id: <1218036899.6297.121.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDA2LiAwOC4gMjAwOCB2IDA4OjE4IC0wNzAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTdCAwNi4gMDgu IDIwMDggdiAwNjo0NCAtMDcwMDoKPiA+IAo+ID4+IEkgYW0gb3Bwb3NlZCB0byB0aGlzIGNvbnN0 cnVjdC4KPiA+PiBJTU8sIFlBTkcgaXMgYWxyZWFkeSBxdWl0ZSBmbGV4aWJsZSwgYW5kIGl0IGNh bgo+ID4+IGFscmVhZHkgYmUgdmVyeSBkaWZmaWN1bHQgdG8gZGV0ZXJtaW5lIGJ5IGluc3BlY3Rp b24KPiA+PiB3aGF0IGEgbW9kdWxlIGFjdHVhbGx5IHJlcXVpcmVzLgo+ID4gCj4gPiBCdXQgd2hl bmV2ZXIgSSB3YW50IHRvIHVzZSBpdCwgSSBjYW4gaW5zZXJ0IHRoZSBjb25zdHJ1Y3Qgd2l0aAo+ ID4gImF1Z21lbnQgLiIsIHJpZ2h0PyBBbmQgdGhpcyBpcyBldmVuIG1vcmUgaGFja3kuCj4gCj4g VGhlcmUgYWxyZWFkeSBpcyBhIHdheSB0byBhY2hpZXZlIHlvdXIgJ2ZlYXR1cmUnLCBzbyB3aHkg YWRkIGFub3RoZXIKPiBvbmUgdG8gc2F2ZSBhIGZldyBjaGFyYWN0ZXJzIGluIHRoZSBZQU5HIGZp bGUuCj4gSSB0aG91Z2h0IGl0IHdhcyBhIGJpZyBkZWFsIHRvIHByb3ZpZGUgMiB3YXlzCj4gb2Yg ZG9pbmcgdGhlIHNhbWUgdGhpbmc/Cj4gCgpOb3QgcmVhbGx5LCBJIGFsc28gcHJvcG9zZWQgdG8g YWxsb3cgYXVnbWVudC1zdG10IG9ubHkgdW5kZXIgdXNlcy1zdG10IC0KZXZlcnlib2R5IGluIER1 YmxpbiBzZWVtZWQgdG8gc3VwcG9ydCB0aGlzIGNoYW5nZS4KCklmIHRoZSBjb25zZW5zdXMgaXMg dGhhdCB0aGUgImdlbmVyYWwgd2hlbiIgaXMgbm90IG5lZWRlZCwgSSB3b3VsZG4ndAptaW5kIGlm IGl0IHN0YXlzIHVuZGVyIGF1Z21lbnQsIGJ1dCBhbHNvIHVuZGVyIHVzZXMuCgpMYWRhCgotLSAK TGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QK bmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kCg== From netmod-bounces@ietf.org Wed Aug 6 09:38:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BA53A63CB; Wed, 6 Aug 2008 09:38:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407213A63CB for ; Wed, 6 Aug 2008 09:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah1gDsWs8wyf for ; Wed, 6 Aug 2008 09:38:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CA5DA3A63EC for ; Wed, 6 Aug 2008 09:38:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB6F5204F9; Wed, 6 Aug 2008 18:38:40 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-5c-4899d3905327 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C801204F0; Wed, 6 Aug 2008 18:38:40 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 18:38:40 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 18:38:40 +0200 Message-ID: <4899D1CF.3090409@ericsson.com> Date: Wed, 06 Aug 2008 18:31:11 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218011851.6297.61.camel@missotis> In-Reply-To: <1218011851.6297.61.camel@missotis> X-OriginalArrivalTime: 06 Aug 2008 16:38:40.0126 (UTC) FILETIME=[E1B1E1E0:01C8F7E2] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] DSDL translation of datatypes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Support the idea. I hope the inmaturity of pyang will not delay the types work. Balazs Ladislav Lhotka wrote: > Hi, > > I propose to include DSDL translation of standard datatype modules in > the "datatypes" draft using the compact syntax. This means that each > module will be first translated with pyang, e.g., > > pyang -f dsdl -o ieee-types.rng ieee-types.yang > > and then converted to the compact syntax using trang: > > java -jar trang.jar -I rng -O rnc ieee-types.rng ieee-types.rnc > > The result is shown below. Please have a look and tell me your opinion. > > The only thing that potentially has to be hand-edited are long lines - > for example, long regexp patterns can be broken into the same chunks as > in the original YANG module, just using the compact syntax concatenation > operator '~'. > > Also note that the current release 0.9.1 of pyang will prefix all names > of RELAX NG named patterns with double underscore '__'. In order to get > the output below, checkout the head revision from the SVN repository > (see http://code.google.com/p/pyang/source/checkout), or wait till the > next release. > > Lada > > ============================= ieee-types.rnc=========================== > namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" > namespace dc = "http://purl.org/dc/terms" > namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" > namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" > namespace sch = "http://purl.oclc.org/dsdl/schematron" > > dc:creator [ "YANG Language Design Team" ] > dc:description [ > "This module contains standard derived YANG types\x{a}" ~ > "for IEEE 802 addresses and related things." > ] > dc:issued [ "2008-05-22" ] > dc:source [ "YANG module 'ieee-types' (automatic translation)" ] > dc:contributor [ > "Juergen Schoenwaelder (Editor)\x{a}" ~ > "" > ] > > ## The mac-address type represents an 802 MAC address > ## represented in the `canonical' order defined by > ## IEEE 802.1a, i.e., as if it were transmitted least > ## significant bit first, even though 802.5 (in contrast > ## to other 802.x protocols) requires MAC addresses to > ## be transmitted most significant bit first. > > ## See: RFC 2579 STD 58 > mac-address = yang-types__phys-address > yang-types__phys-address = xsd:string > > ## The bridgeid type represents identifers that uniquely > ## identify a bridge. Its first four hexadecimal digits > ## contain a priority value followed by a colon. The > ## remaining characters contain the MAC address used to > ## refer to a bridge in a unique fashion (typically, the > ## numerically smallest MAC address of all ports on the > ## bridge). > > ## See: RFC 4188 > bridgeid = > xsd:string { > pattern = "[0-9a-fA-F]{4}:([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}" > } > > ## The vlanid type uniquely identifies a VLAN. This is > ## the 12-bit VLAN-ID used in the VLAN Tag header. The > ## range is defined by the referenced specification. > > ## See: IEEE Std 802.1Q 2003 Edition, Virtual Bridged Local > ## Area Networks. > vlanid = xsd:unsignedShort { minInclusive = "1" maxInclusive = "4094" } > -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 10:10:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF133A6934; Wed, 6 Aug 2008 10:10:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74ADA3A69F1 for ; Wed, 6 Aug 2008 10:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3x0uJQiIzg5 for ; Wed, 6 Aug 2008 10:10:03 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id B3DEE3A6934 for ; Wed, 6 Aug 2008 10:10:03 -0700 (PDT) Received: (qmail 83079 invoked from network); 6 Aug 2008 17:10:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 17:10:24 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4899DAFE.4070203@netconfcentral.com> Date: Wed, 06 Aug 2008 10:10:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> In-Reply-To: <1218036899.6297.121.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTdCAwNi4gMDgu IDIwMDggdiAwODoxOCAtMDcwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pj4gQW5keSBC aWVybWFuIHDDrcWhZSB2IFN0IDA2LiAwOC4gMjAwOCB2IDA2OjQ0IC0wNzAwOgo+Pj4KPj4+PiBJ IGFtIG9wcG9zZWQgdG8gdGhpcyBjb25zdHJ1Y3QuCj4+Pj4gSU1PLCBZQU5HIGlzIGFscmVhZHkg cXVpdGUgZmxleGlibGUsIGFuZCBpdCBjYW4KPj4+PiBhbHJlYWR5IGJlIHZlcnkgZGlmZmljdWx0 IHRvIGRldGVybWluZSBieSBpbnNwZWN0aW9uCj4+Pj4gd2hhdCBhIG1vZHVsZSBhY3R1YWxseSBy ZXF1aXJlcy4KPj4+IEJ1dCB3aGVuZXZlciBJIHdhbnQgdG8gdXNlIGl0LCBJIGNhbiBpbnNlcnQg dGhlIGNvbnN0cnVjdCB3aXRoCj4+PiAiYXVnbWVudCAuIiwgcmlnaHQ/IEFuZCB0aGlzIGlzIGV2 ZW4gbW9yZSBoYWNreS4KPj4gVGhlcmUgYWxyZWFkeSBpcyBhIHdheSB0byBhY2hpZXZlIHlvdXIg J2ZlYXR1cmUnLCBzbyB3aHkgYWRkIGFub3RoZXIKPj4gb25lIHRvIHNhdmUgYSBmZXcgY2hhcmFj dGVycyBpbiB0aGUgWUFORyBmaWxlLgo+PiBJIHRob3VnaHQgaXQgd2FzIGEgYmlnIGRlYWwgdG8g cHJvdmlkZSAyIHdheXMKPj4gb2YgZG9pbmcgdGhlIHNhbWUgdGhpbmc/Cj4+Cj4gCj4gTm90IHJl YWxseSwgSSBhbHNvIHByb3Bvc2VkIHRvIGFsbG93IGF1Z21lbnQtc3RtdCBvbmx5IHVuZGVyIHVz ZXMtc3RtdCAtCj4gZXZlcnlib2R5IGluIER1YmxpbiBzZWVtZWQgdG8gc3VwcG9ydCB0aGlzIGNo YW5nZS4KPiAKCkV4Y2VwdCBmb3IgdG9wLWxldmVsIGF1Z21lbnQsIHJpZ2h0PwpZb3UgY2Fubm90 IHJlbW92ZSB0aGUgYWJpbGl0eSBmb3Igb25lIG1vZHVsZSB0byBhdWdtZW50CmFub3RoZXIgb25l LgoKCj4gSWYgdGhlIGNvbnNlbnN1cyBpcyB0aGF0IHRoZSAiZ2VuZXJhbCB3aGVuIiBpcyBub3Qg bmVlZGVkLCBJIHdvdWxkbid0Cj4gbWluZCBpZiBpdCBzdGF5cyB1bmRlciBhdWdtZW50LCBidXQg YWxzbyB1bmRlciB1c2VzLgoKSU1PLCB0aGlzIFdHIG5lZWRzIHRvIHN0YXJ0IGxvb2tpbmcgYXQg dGhlIGJpZyBwaWN0dXJlLAphbmQgZGVjaWRlIGhvdyBiaWcgcHJvYmxlbXMgYXJlIHNvbHZlZCB3 aXRoaW4gWUFORy4KVHdlYWtpbmcgdGhlIGNsYXVzZXMgd2l0aG91dCBhbnkgc2hhcmVkIHVuZGVy c3RhbmRpbmcKb2YgdGhlICd3b3JraW5ncyBvZiBZQU5HJyBpcyB0b28gYm90dG9tLXVwIHRvIHN1 Y2NlZWQKaW4gYSBkZXNpZ24tYnktY29tbWl0dGVlIGVudmlyb25tZW50LgoKSSBoYXZlIHNlcmlv dXMgY29uY2VybnMgYWJvdXQgdGhlIHN0YW5kYXJkcyB2YWx1ZSBvZiBZQU5HLAplc3BlY2lhbGx5 IGlmIGl0IGhhcyBhIG5lc3RlZCBjb25kaXRpb25hbCBibG9jaywgYmFzZWQKb24gYXJiaXRyYXJ5 IHZhbHVlcyB3aXRoaW4gdGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbi4KClRoZSBJRVRGIGhhcyBl eHBlcmllbmNlIHdpdGggc3RhdGljIG1vZHVsZSBkZWZpbml0aW9ucwp3aGljaCBhcmUgcGFydGl0 aW9uZWQgaW50byBncm91cHMgb2Ygb2JqZWN0cywgYW5kIGNvbmZvcm1hbmNlCmJhc2VkIG9uIGlt cGxlbWVudGF0aW9uIG9mIHNwZWNpZmljIGdyb3VwcyB3aXRoaW4gdGhlIG1vZHVsZS4KClRoaXMg c2ltcGxpc3RpYyBhcHByb2FjaCBpcyBkZXRlcm1pbmlzdGljLCBzdGF0aWMsCmFuZCBpbnRlci1v cGVyYWJsZS4gIENvbWJpbmluZyAnd2hlbicsICdtdXN0JywgJ2F1Z21lbnQnCmFuZCAndXNlcycg aW4gYXJiaXRyYXJ5IHdheXMgaXMgbm90IHByb3ZlbiBhdCBhbGwuCgoKPiAKPiBMYWRhCj4gCgpB bmR5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRt b2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Aug 6 10:18:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DDB3A6A00; Wed, 6 Aug 2008 10:18:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F543A6A00 for ; Wed, 6 Aug 2008 10:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.158 X-Spam-Level: X-Spam-Status: No, score=-0.158 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP2GIa7FanQp for ; Wed, 6 Aug 2008 10:18:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9255D3A69F9 for ; Wed, 6 Aug 2008 10:18:18 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D6DF7D800BD; Wed, 6 Aug 2008 19:18:49 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4899DAFE.4070203@netconfcentral.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> Organization: CESNET Date: Wed, 06 Aug 2008 19:18:51 +0200 Message-Id: <1218043131.6297.127.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDA2LiAwOC4gMjAwOCB2IDEwOjEwIC0wNzAwOgoKPiAK PiBFeGNlcHQgZm9yIHRvcC1sZXZlbCBhdWdtZW50LCByaWdodD8KPiBZb3UgY2Fubm90IHJlbW92 ZSB0aGUgYWJpbGl0eSBmb3Igb25lIG1vZHVsZSB0byBhdWdtZW50Cj4gYW5vdGhlciBvbmUuCgpS aWdodCwgYWx0aG91Z2ggSU1PIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byB1c2UgYW5vdGhlciBrZXl3 b3JkIGZvciB0aGlzCnR5cGUgb2YgdXNhZ2Ugc2luY2UgdGhlIG1lY2hhbmlzbSBpcyBkaWZmZXJl bnQgLSB0aGUgaW1wb3J0IHN0YXRlbWVudApoYXMgbm8gc2lkZSBlZmZlY3RzLCBzbyB0aGUgdHJl ZSB0aGF0IHRoaXMgYXVnbWVudCBvcGVyYXRlcyBvbiBpcyBub3QKcHJlc2VudC4KCkxhZGEKCi0t IApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlz dApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QK From netmod-bounces@ietf.org Wed Aug 6 10:31:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7053A6946; Wed, 6 Aug 2008 10:31:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866BE3A6946 for ; Wed, 6 Aug 2008 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2HJxCWstqX4 for ; Wed, 6 Aug 2008 10:31:48 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id A8CD93A68F1 for ; Wed, 6 Aug 2008 10:31:48 -0700 (PDT) Received: (qmail 45787 invoked from network); 6 Aug 2008 17:32:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 17:32:20 -0000 X-YMail-OSG: tIjDwp8VM1l.fh6HGu3wNh0S6qVya3zrgR8FtADJEwGYbksAbUdu7HGFEtcJ7jq5GoCBpdZPOfSwwgRTSE4SLugaJpsnakd6IOlFuIS0VQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4899E023.1000407@netconfcentral.com> Date: Wed, 06 Aug 2008 10:32:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> In-Reply-To: <1218043131.6297.127.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTdCAwNi4gMDgu IDIwMDggdiAxMDoxMCAtMDcwMDoKPiAKPj4gRXhjZXB0IGZvciB0b3AtbGV2ZWwgYXVnbWVudCwg cmlnaHQ/Cj4+IFlvdSBjYW5ub3QgcmVtb3ZlIHRoZSBhYmlsaXR5IGZvciBvbmUgbW9kdWxlIHRv IGF1Z21lbnQKPj4gYW5vdGhlciBvbmUuCj4gCj4gUmlnaHQsIGFsdGhvdWdoIElNTyBpdCB3b3Vs ZCBiZSB1c2VmdWwgdG8gdXNlIGFub3RoZXIga2V5d29yZCBmb3IgdGhpcwo+IHR5cGUgb2YgdXNh Z2Ugc2luY2UgdGhlIG1lY2hhbmlzbSBpcyBkaWZmZXJlbnQgCgpob3cgYWJvdXQgYXVnbWVudC1l eHRlcm4/CgpJIGRvbid0IG1pbmQgcHV0dGluZyBhdWdtZW50LXN0bXQgaW5zaWRlIHVzZXMuCkkg Y2Fubm90IHRoaW5rIG9mIGFueSBvdGhlciB1c2UgY2FzZSwgZXhjZXB0IHlvdXIKbmVzdGVkICd3 aGVuJyBjb25jZXB0dWFsIGNvbnRhaW5lcnMsIHdoaWNoIEkgZG8gbm90IHdhbnQuCgoKCi0gdGhl IGltcG9ydCBzdGF0ZW1lbnQKPiBoYXMgbm8gc2lkZSBlZmZlY3RzLCBzbyB0aGUgdHJlZSB0aGF0 IHRoaXMgYXVnbWVudCBvcGVyYXRlcyBvbiBpcyBub3QKPiBwcmVzZW50LgoKCnllcyBpdCBpcyAt LSBpbiB5b3VyIGltcGxlbWVudGF0aW9uLCB5b3UgaGF2ZSB0byB2YWxpZGF0ZQp0aGUgaW1wb3J0 ZWQgbW9kdWxlcyBhbG9uZyB3aXRoIHRoZSAndG9wJyBtb2R1bGUgb3Igc3ViLW1vZHVsZS4KWW91 IGNhbiBidWlsZCBhbiBvYmplY3QgZGF0YWJhc2UgYW5kIHZhbGlkYXRlIGFsbCAnZGVmaW5pdGlv bgpjb250ZXh0JyBYcGF0aCBleHByZXNzaW9ucyBhZ2FpbnN0IGl0LiAgWW91IGhhdmUgdG8gZGV0 ZXJtaW5lCmlmIHRoZSBhdWdtZW50IHRhcmdldCBjYW4gYmUgZXh0ZW5kZWQgaW4gdGhlIHJlcXVl c3RlZCBtYW5uZXIKYW55d2F5LgoKCj4gCj4gTGFkYQo+IAoKQW5keQoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRt b2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Aug 6 12:43:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895D63A6991; Wed, 6 Aug 2008 12:43:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623783A6991 for ; Wed, 6 Aug 2008 12:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.453 X-Spam-Level: X-Spam-Status: No, score=0.453 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, FU_LOTSOFCOLONS=4.999, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLV9hK9hRIzP for ; Wed, 6 Aug 2008 12:43:03 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 552803A6A4D for ; Wed, 6 Aug 2008 12:43:03 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 03A9076C4CC; Wed, 6 Aug 2008 21:43:35 +0200 (CEST) Date: Wed, 06 Aug 2008 21:43:31 +0200 (CEST) Message-Id: <20080806.214331.41767422.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1218001487.6297.4.camel@missotis> References: <1217970121.6212.21.camel@missotis> <20080805.231132.70478941.mbj@tail-f.com> <1218001487.6297.4.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > > > > - in fact, it's IMO not needed, the 'self' axis (or '.') and the > > > current() function should do. > > > > No, since '.' selects the current context node, but the context node > > changes in the expression. > > > > Compare > > > > leaf address { > > type keyref { > > path "../../interface[name = $this/../ifname]/address/ip"; > > path "../../interface[name = current()/../ifname]/address/ip"; First of all, current() is not an XPath 1.0 core function. I believe is an XSLT addition. Second, I found this (http://developer.mozilla.org/en/docs/XPath:Functions:current) The current node is always the same as the context node. The following two are symantically equivalent. So it doesn't help us. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 12:53:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191233A6991; Wed, 6 Aug 2008 12:53:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C973A68E1 for ; Wed, 6 Aug 2008 12:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.384 X-Spam-Level: X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=-2.349, BAYES_00=-2.599, FU_LOTSOFCOLONS=4.999, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBuJHf22Z8Hg for ; Wed, 6 Aug 2008 12:53:09 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id B843F3A6811 for ; Wed, 6 Aug 2008 12:53:09 -0700 (PDT) Received: (qmail 21502 invoked from network); 6 Aug 2008 19:53:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 19:53:42 -0000 X-YMail-OSG: HtNwq6oVM1lMNs2lpiZEGdaAxvpfN06Qf6E5.HBmsrvewK367pI.v6SZZ7bgjgOQGmKHNpRlteNjbXi9b4eYRFbhBljyNAynFpxsdMLhQ4VzCSFOMT7glQtSs4EOp8w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489A0143.40708@netconfcentral.com> Date: Wed, 06 Aug 2008 12:53:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <1217970121.6212.21.camel@missotis> <20080805.231132.70478941.mbj@tail-f.com> <1218001487.6297.4.camel@missotis> <20080806.214331.41767422.mbj@tail-f.com> In-Reply-To: <20080806.214331.41767422.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>>> - in fact, it's IMO not needed, the 'self' axis (or '.') and the >>>> current() function should do. >>> No, since '.' selects the current context node, but the context node >>> changes in the expression. >>> >>> Compare >>> >>> leaf address { >>> type keyref { >>> path "../../interface[name = $this/../ifname]/address/ip"; >> path "../../interface[name = current()/../ifname]/address/ip"; > > First of all, current() is not an XPath 1.0 core function. I believe > is an XSLT addition. Second, I found this > (http://developer.mozilla.org/en/docs/XPath:Functions:current) > > The current node is always the same as the context node. The > following two are symantically equivalent. > > > > > > So it doesn't help us. > I think I agree with Martin that we are not changing XPath 1.0. I should not have said that. We are creating 2 new custom contexts in which XPath expressions can be evaluated. XPath 1.0 is not changed at all. IMO, there is enough justification for '$this', just make sure all the mailing list examples and definitions make it into the draft. Nothing helps an implementer more than a correct example. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 6 13:23:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9663A68E1; Wed, 6 Aug 2008 13:23:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F563A6B4E for ; Wed, 6 Aug 2008 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOE2rEMShAfv for ; Wed, 6 Aug 2008 13:23:49 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id B51E83A68E1 for ; Wed, 6 Aug 2008 13:23:49 -0700 (PDT) Received: (qmail 31770 invoked from network); 6 Aug 2008 20:24:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 6 Aug 2008 20:24:22 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489A0874.1040103@netconfcentral.com> Date: Wed, 06 Aug 2008 13:24:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] YANG conformance idea X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, This is a synthesis of the various proposals so far, which avoids the complexity and unintended consequences of Xpath and the redundancy of the SMIv2 conformance macros. module acme { ... import if { prefix if; } ... feature acme1 { status current; description ""; reference ""; } ... conformance little-feature-set { status current; description ""; reference ""; uses-feature acme1; uses-feature acme2; } conformance big-feature-set { description ""; uses-feature acme1; uses-feature acme2; uses-feature acme3; uses-feature if:if-basic; } } Instead of adding arbitrarily nested 'if-feature' meta-containers, a new 'for-feature' sub-statement for the basic objects declaring which feature is associated with the entire subtree. Just like SMIv2, it is debatable whether or not an object has to be part of a feature or is there a default. Also, are child nodes allowed to be in different features? (IMO, no) module if { container interfaces { list interface { for-feature if-basic; ... } leaf ifNumber { // not part of any feature package } list ifStackTable { for-feature if-stack; ... } } feature if-basic { description "Basic interface parameters"; } feature if-stack { description "Interface stack table support."; } conformance full-if { uses-feature if-basic; uses-feature if-stack; } conformance readonly-if { uses-feature if-basic { refine "/if:interfaces/if:interface/if:mtu" { config false; } } } } IMO, this builds on our SMIv2 experience without creating a free-for-all in flexibility. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 00:16:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1513A6902; Thu, 7 Aug 2008 00:16:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D2E3A6A13 for ; Thu, 7 Aug 2008 00:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.361 X-Spam-Level: ** X-Spam-Status: No, score=2.361 tagged_above=-999 required=5 tests=[AWL=-2.877, BAYES_05=-1.11, FU_LOTSOFCOLONS=4.999, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlqRbNQqyxtJ for ; Thu, 7 Aug 2008 00:16:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1DBD93A69E0 for ; Thu, 7 Aug 2008 00:16:26 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id ABB6FD800C5 for ; Thu, 7 Aug 2008 09:16:25 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20080806.214331.41767422.mbj@tail-f.com> References: <1217970121.6212.21.camel@missotis> <20080805.231132.70478941.mbj@tail-f.com> <1218001487.6297.4.camel@missotis> <20080806.214331.41767422.mbj@tail-f.com> Organization: CESNET Date: Thu, 07 Aug 2008 09:16:25 +0200 Message-Id: <1218093385.6227.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAwNi4gMDguIDIwMDggdiAyMTo0MyArMDIwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gCj4gPiA+ID4g LSBpbiBmYWN0LCBpdCdzIElNTyBub3QgbmVlZGVkLCB0aGUgJ3NlbGYnIGF4aXMgKG9yICcuJykg YW5kIHRoZQo+ID4gPiA+IGN1cnJlbnQoKSBmdW5jdGlvbiBzaG91bGQgZG8uCj4gPiA+IAo+ID4g PiBObywgc2luY2UgJy4nIHNlbGVjdHMgdGhlIGN1cnJlbnQgY29udGV4dCBub2RlLCBidXQgdGhl IGNvbnRleHQgbm9kZQo+ID4gPiBjaGFuZ2VzIGluIHRoZSBleHByZXNzaW9uLgo+ID4gPiAKPiA+ ID4gQ29tcGFyZQo+ID4gPiAgICAKPiA+ID4gICBsZWFmIGFkZHJlc3Mgewo+ID4gPiAgICAgdHlw ZSBrZXlyZWYgewo+ID4gPiAgICAgICBwYXRoICIuLi8uLi9pbnRlcmZhY2VbbmFtZSA9ICR0aGlz Ly4uL2lmbmFtZV0vYWRkcmVzcy9pcCI7Cj4gPiAKPiA+ICAgICAgICAgcGF0aCAiLi4vLi4vaW50 ZXJmYWNlW25hbWUgPSBjdXJyZW50KCkvLi4vaWZuYW1lXS9hZGRyZXNzL2lwIjsKPiAKPiBGaXJz dCBvZiBhbGwsIGN1cnJlbnQoKSBpcyBub3QgYW4gWFBhdGggMS4wIGNvcmUgZnVuY3Rpb24uICBJ IGJlbGlldmUKClllcywgeW91IGFyZSByaWdodC4gSG93ZXZlciwgaW4gU2NoZW1hdHJvbiB5b3Ug Y2FuIHVzZSB0aGlzIGZ1bmN0aW9uLAp0b28sIGFuZCBpdCBpcyB1c2VkIHF1aXRlIG9mdGVuLgoK PiBpcyBhbiBYU0xUIGFkZGl0aW9uLiAgU2Vjb25kLCBJIGZvdW5kIHRoaXMKPiAoaHR0cDovL2Rl dmVsb3Blci5tb3ppbGxhLm9yZy9lbi9kb2NzL1hQYXRoOkZ1bmN0aW9uczpjdXJyZW50KQo+IAo+ ICAgVGhlIGN1cnJlbnQgbm9kZSBpcyBhbHdheXMgdGhlIHNhbWUgYXMgdGhlIGNvbnRleHQgbm9k ZS4gVGhlCj4gICBmb2xsb3dpbmcgdHdvIGFyZSBzeW1hbnRpY2FsbHkgZXF1aXZhbGVudC4KPiAK PiAgICAgPHhzbDp2YWx1ZS1vZiBzZWxlY3Q9ImN1cnJlbnQoKSIvPgo+IAo+ICAgICA8eHNsOnZh bHVlLW9mIHNlbGVjdD0iLiIvPgoKCk5vLCB0aGlzIGlzIG9ubHkgdHJ1ZSBpbiB0aGUgb3V0ZXJt b3N0IGxldmVsIG9mIHRoZSBleHByZXNzaW9ucy4gU2VjdGlvbgoxMi40IG9mIHRoZSBYU0xUIHNw ZWMgKGh0dHA6Ly93d3cudzMub3JnL1RSL3hzbHQjbWlzYy1mdW5jKSBtYWtlcyBpdAp2ZXJ5IGNs ZWFyLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4 QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRt b2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 00:30:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB403A6823; Thu, 7 Aug 2008 00:30:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753913A6823 for ; Thu, 7 Aug 2008 00:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQHBqG2Mmh0x for ; Thu, 7 Aug 2008 00:30:00 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EDAE23A683B for ; Thu, 7 Aug 2008 00:29:59 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0F220D80098; Thu, 7 Aug 2008 08:58:43 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4899E023.1000407@netconfcentral.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> <4899E023.1000407@netconfcentral.com> Organization: CESNET Date: Thu, 07 Aug 2008 08:58:42 +0200 Message-Id: <1218092322.6227.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDA2LiAwOC4gMjAwOCB2IDEwOjMyIC0wNzAwOgo+IC0g dGhlIGltcG9ydCBzdGF0ZW1lbnQKPiA+IGhhcyBubyBzaWRlIGVmZmVjdHMsIHNvIHRoZSB0cmVl IHRoYXQgdGhpcyBhdWdtZW50IG9wZXJhdGVzIG9uIGlzIG5vdAo+ID4gcHJlc2VudC4KPiAKPiAK PiB5ZXMgaXQgaXMgLS0gaW4geW91ciBpbXBsZW1lbnRhdGlvbiwgeW91IGhhdmUgdG8gdmFsaWRh dGUKCkkgZG9uJ3QgdGhpbmsgc28uIEluIGEgTkVUQ09ORiBzZXNzaW9uLCBpZiB0aGUgYWdlbnQg ZG9lc24ndCBzZXBhcmF0ZWx5CmFkdmVydGlzZSB0aGUgZm9yZWlnbiAoaW1wb3J0ZWQpIGRhdGEg bW9kZWwgdGhlbiB0aGUgbWFpbiBkYXRhIHRyZWUgb2YKdGhpcyBtb2RlbCBpcyBub3QgYXZhaWxh YmxlIGFuZCB0aGUgdG9wLWxldmVsIGF1Z21lbnQgY2Fubm90IGhhdmUgYW55CmVmZmVjdC4KCkl0 IHdvdWxkIGJlIG1vcmUgbG9naWNhbCB0byBleHBsaWNpdGx5IGFzc29jaWF0ZSB0aGUgbW9kaWZp Y2F0aW9ucyB3aXRoCnRoZSBkYXRhIG1vZGVsIHRoYXQgaXMgYmVpbmcgbW9kaWZpZWQuIElmIEkg dW5kZXJzdG9vZCBjb3JyZWN0bHkgdGhlCmNvbmNlcHQgb2Ygb3ZlcmxheSBtb2R1bGVzIHN1Z2dl c3RlZCBieSBNYXJ0aW4sIHRoaXMgaXMgdGhlIHdheSBob3cgdG8KZG8gaXQuCgpMYWRhCgotLSAK TGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QK bmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kCg== From netmod-bounces@ietf.org Thu Aug 7 00:51:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308EF3A68EA; Thu, 7 Aug 2008 00:51:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509433A68EA for ; Thu, 7 Aug 2008 00:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YriMzGFtBR4 for ; Thu, 7 Aug 2008 00:51:25 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7E6293A68B0 for ; Thu, 7 Aug 2008 00:51:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 758F120D27; Thu, 7 Aug 2008 09:51:58 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-4a-489aa99e8661 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5954D20CFF; Thu, 7 Aug 2008 09:51:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 09:51:57 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 09:51:57 +0200 Message-ID: <489AA3EC.6070603@ericsson.com> Date: Thu, 07 Aug 2008 09:27:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> In-Reply-To: <4899DAFE.4070203@netconfcentral.com> X-OriginalArrivalTime: 07 Aug 2008 07:51:57.0864 (UTC) FILETIME=[77B12280:01C8F862] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Lada, I definitely do NOT support this change and don't remember any kind of consensus around it. It would make mapping of object oriented data models to YANG impossible. As the Nokia-Siemens guys even proposed to extend the possibilities of augment, I don't believe they support your proposal. Today augmenting choice is the only way to make an extensible enumeration. We have augmentation of notifications which would be the proper way to extend standard notifications e.g. something like the stuff in Sharon's not-content draft. What happens if a standard module (YAM) is not defined using groupings. Your proposal would make that impossible to extend. Even Phil's examples in the YANG draft use augmenting without uses. Balazs > Ladislav Lhotka wrote: >> >> Not really, I also proposed to allow augment-stmt only under uses-stmt - >> everybody in Dublin seemed to support this change. >> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 00:58:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0691E3A68DD; Thu, 7 Aug 2008 00:58:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1E73A6A6C for ; Thu, 7 Aug 2008 00:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiSJ5qYkQEHK for ; Thu, 7 Aug 2008 00:58:18 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id ED02C3A68DD for ; Thu, 7 Aug 2008 00:58:17 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 575F920CD0; Thu, 7 Aug 2008 09:58:52 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-41-489aab3cfffe Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 41FDB20CC7; Thu, 7 Aug 2008 09:58:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 09:58:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 09:58:51 +0200 Message-ID: <489AA58A.8030100@ericsson.com> Date: Thu, 07 Aug 2008 09:34:34 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> <4899E023.1000407@netconfcentral.com> <1218092322.6227.10.camel@missotis> In-Reply-To: <1218092322.6227.10.camel@missotis> X-OriginalArrivalTime: 07 Aug 2008 07:58:51.0387 (UTC) FILETIME=[6E2BBCB0:01C8F863] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGVsbG8gTGFkYSwKU2VlIHNvbWUgcXVlc3Rpb25zIGJlbG93LgpCYWxhenMKCkxhZGlzbGF2IExo b3RrYSB3cm90ZToKPiBBbmR5IEJpZXJtYW4gcMOtxaFlIHYgU3QgMDYuIDA4LiAyMDA4IHYgMTA6 MzIgLTA3MDA6Cj4+IC0gdGhlIGltcG9ydCBzdGF0ZW1lbnQKPj4+IGhhcyBubyBzaWRlIGVmZmVj dHMsIHNvIHRoZSB0cmVlIHRoYXQgdGhpcyBhdWdtZW50IG9wZXJhdGVzIG9uIGlzIG5vdAo+Pj4g cHJlc2VudC4KPj4KPj4geWVzIGl0IGlzIC0tIGluIHlvdXIgaW1wbGVtZW50YXRpb24sIHlvdSBo YXZlIHRvIHZhbGlkYXRlCj4gCj4gSSBkb24ndCB0aGluayBzby4gSW4gYSBORVRDT05GIHNlc3Np b24sIGlmIHRoZSBhZ2VudCBkb2Vzbid0IHNlcGFyYXRlbHkKPiBhZHZlcnRpc2UgdGhlIGZvcmVp Z24gKGltcG9ydGVkKSBkYXRhIG1vZGVsIHRoZW4gdGhlIG1haW4gZGF0YSB0cmVlIG9mCj4gdGhp cyBtb2RlbCBpcyBub3QgYXZhaWxhYmxlIGFuZCB0aGUgdG9wLWxldmVsIGF1Z21lbnQgY2Fubm90 IGhhdmUgYW55Cj4gZWZmZWN0LgpJcyBpdCBub3QgYW4gZXJyb3IgdG8gaW1wb3J0ICh1c2UpIGEg ZGF0YSBtb2RlbCBhbmQgbm90IGFkdmVydGlzZSBpdD8KCklmIHlvdSBhcmUgZXZlbiBhdWdtZW50 aW5nIHRoYXQgbW9kZWwgLSBleHRlbmRpbmcgaXQgLSBidXQgeW91IGRvIG5vdCBzdXBwb3J0IGl0 IHRoYXQgCmRlZmluaXRlbHkgc291bmRzIGxpa2UgYW4gZXJyb3IuIEV4dGVuZGluZyBhIG5vbi1l eGlzdGluZyAoZm9yIG15IGJveCkgbW9kZWwgdGhhdCBzb3VuZHMgCmZyZWFreS4gSSBjb3VsZCBp bWFnaW5lIHRoYXQgeW91IG9ubHkgdXNlIHNvbWUgdHlwZXMgb3IgZ3JvdXBpbmdzIGZyb20gYW4g aW1wb3J0ZWQgbW9kdWxlLCBidXQgCmlmIHdlIHNwZWFrIG9mIGF1Z21lbnQgd2UgYXJlIHJlZmVy cmluZyB0byB0aGUgZGF0YSB0cmVlLgo+IAo+IEl0IHdvdWxkIGJlIG1vcmUgbG9naWNhbCB0byBl eHBsaWNpdGx5IGFzc29jaWF0ZSB0aGUgbW9kaWZpY2F0aW9ucyB3aXRoCj4gdGhlIGRhdGEgbW9k ZWwgdGhhdCBpcyBiZWluZyBtb2RpZmllZC4gCkNvdWxkIHlvdSBleHBsaWFuIHdpdGggYW4gZXhh bXBsZSB3aGF0IHRoaXMgd291bGQgbWVhbiBpbiB0aGUgYXVnbWVudGluZyBhbmQgdGhlIGF1Z21l bnRlZCBtb2R1bGU/Cj4gCj4gTGFkYQo+IAoKLS0gCkJhbGF6cyBMZW5neWVsICAgICAgICAgICAg ICAgICAgICAgICBFcmljc3NvbiBIdW5nYXJ5IEx0ZC4KVFNQIFN5c3RlbSBNYW5hZ2VyCkVDTjog ODMxIDczMjAgICAgICAgICAgICAgICAgICAgICAgICBGYXg6ICszNiAxIDQzNzc3OTIKVGVsOiAr MzYtMS00MzctNzMyMCAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGlu ZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 01:24:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9838E3A6952; Thu, 7 Aug 2008 01:24:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5393A696B for ; Thu, 7 Aug 2008 01:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUiFj6I5YcII for ; Thu, 7 Aug 2008 01:24:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A8F343A6952 for ; Thu, 7 Aug 2008 01:24:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BFB44D80098; Thu, 7 Aug 2008 10:24:58 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <489AA58A.8030100@ericsson.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> <4899E023.1000407@netconfcentral.com> <1218092322.6227.10.camel@missotis> <489AA58A.8030100@ericsson.com> Organization: CESNET Date: Thu, 07 Aug 2008 10:24:58 +0200 Message-Id: <1218097498.6227.71.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgxIx0IDA3LiAwOC4gMjAwOCB2IDA5OjM0ICswMjAwOgo+ IEhlbGxvIExhZGEsCj4gU2VlIHNvbWUgcXVlc3Rpb25zIGJlbG93Lgo+IEJhbGF6cwo+IAo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTdCAwNi4gMDgu IDIwMDggdiAxMDozMiAtMDcwMDoKPiA+PiAtIHRoZSBpbXBvcnQgc3RhdGVtZW50Cj4gPj4+IGhh cyBubyBzaWRlIGVmZmVjdHMsIHNvIHRoZSB0cmVlIHRoYXQgdGhpcyBhdWdtZW50IG9wZXJhdGVz IG9uIGlzIG5vdAo+ID4+PiBwcmVzZW50Lgo+ID4+Cj4gPj4geWVzIGl0IGlzIC0tIGluIHlvdXIg aW1wbGVtZW50YXRpb24sIHlvdSBoYXZlIHRvIHZhbGlkYXRlCj4gPiAKPiA+IEkgZG9uJ3QgdGhp bmsgc28uIEluIGEgTkVUQ09ORiBzZXNzaW9uLCBpZiB0aGUgYWdlbnQgZG9lc24ndCBzZXBhcmF0 ZWx5Cj4gPiBhZHZlcnRpc2UgdGhlIGZvcmVpZ24gKGltcG9ydGVkKSBkYXRhIG1vZGVsIHRoZW4g dGhlIG1haW4gZGF0YSB0cmVlIG9mCj4gPiB0aGlzIG1vZGVsIGlzIG5vdCBhdmFpbGFibGUgYW5k IHRoZSB0b3AtbGV2ZWwgYXVnbWVudCBjYW5ub3QgaGF2ZSBhbnkKPiA+IGVmZmVjdC4KPiBJcyBp dCBub3QgYW4gZXJyb3IgdG8gaW1wb3J0ICh1c2UpIGEgZGF0YSBtb2RlbCBhbmQgbm90IGFkdmVy dGlzZSBpdD8KCkEgbW9kdWxlIG1heSBiZSBpbXBvcnRlZCBmb3IgYSBudW1iZXIgb2YgcmVhc29u cy4gSWYgSSBpbXBvcnQgZS5nLiwKaW5ldC10eXBlcywgZG8gSSBoYXZlIHRvIGFkdmVydGlzZSBp bmV0LXR5cGVzIGluIGhlbGxvIGFsb25nIHdpdGggbXkKZGF0YSBtb2RlbD8gSSBkb24ndCB0aGlu ayBzby4KCj4gCj4gSWYgeW91IGFyZSBldmVuIGF1Z21lbnRpbmcgdGhhdCBtb2RlbCAtIGV4dGVu ZGluZyBpdCAtIGJ1dCB5b3UgZG8gbm90IHN1cHBvcnQgaXQgdGhhdCAKPiBkZWZpbml0ZWx5IHNv dW5kcyBsaWtlIGFuIGVycm9yLiBFeHRlbmRpbmcgYSBub24tZXhpc3RpbmcgKGZvciBteSBib3gp IG1vZGVsIHRoYXQgc291bmRzIAo+IGZyZWFreS4gSSBjb3VsZCBpbWFnaW5lIHRoYXQgeW91IG9u bHkgdXNlIHNvbWUgdHlwZXMgb3IgZ3JvdXBpbmdzIGZyb20gYW4gaW1wb3J0ZWQgbW9kdWxlLCBi dXQgCj4gaWYgd2Ugc3BlYWsgb2YgYXVnbWVudCB3ZSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBkYXRh IHRyZWUuCgpCYWNrIHRvIE9PUCAtIGl0IHlvdSBkZWZpbmUgYW4gaW5zdGFuY2Ugb2YgYSBjbGFz cywgeW91IGRvbid0IHNwZWNpZnkgaXQKdG9nZXRoZXIgd2l0aCBhbGwgaXRzIHN1cGVyY2xhc3Nl cy4gTXkgYm94IGp1c3QgdXNlcyBhIGRhdGEgbW9kZWwgdGhhdAppcyBkZXJpdmVkIGZyb20gYW5v dGhlciBvbmUgLSBhbmQgdGhhdCBzaG91bGQgYmUgc3BlY2lmaWVkIGluIHRoZQpkZXJpdmVkIGRh dGEgbW9kZWwuIAoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6 IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 01:31:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F633A6925; Thu, 7 Aug 2008 01:31:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121223A6958 for ; Thu, 7 Aug 2008 01:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F05Wzsmak2r for ; Thu, 7 Aug 2008 01:31:56 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 36A6E3A6925 for ; Thu, 7 Aug 2008 01:31:56 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 90765D80098 for ; Thu, 7 Aug 2008 10:32:31 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <489AA3EC.6070603@ericsson.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <489AA3EC.6070603@ericsson.com> Organization: CESNET Date: Thu, 07 Aug 2008 10:32:31 +0200 Message-Id: <1218097951.6227.72.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgxIx0IDA3LiAwOC4gMjAwOCB2IDA5OjI3ICswMjAwOgo+ IEhlbGxvIExhZGEsCj4gSSBkZWZpbml0ZWx5IGRvIE5PVCBzdXBwb3J0IHRoaXMgY2hhbmdlIGFu ZCBkb24ndCByZW1lbWJlciBhbnkga2luZCBvZiBjb25zZW5zdXMgYXJvdW5kIGl0Lgo+IAo+IEl0 IHdvdWxkIG1ha2UgbWFwcGluZyBvZiBvYmplY3Qgb3JpZW50ZWQgZGF0YSBtb2RlbHMgdG8gWUFO RyBpbXBvc3NpYmxlLgo+IAo+IEFzIHRoZSBOb2tpYS1TaWVtZW5zIGd1eXMgZXZlbiBwcm9wb3Nl ZCB0byBleHRlbmQgdGhlIHBvc3NpYmlsaXRpZXMgb2YgYXVnbWVudCwgSSBkb24ndCBiZWxpZXZl IAo+IHRoZXkgc3VwcG9ydCB5b3VyIHByb3Bvc2FsLgoKQnV0IGlzbid0IGl0IG1vcmUgYSB0YXNr IGZvciB0aGUgdG9wLWxldmVsIGF1Z21lbnQ/CgpJZiB5b3UgbWVudGlvbiBvYmplY3Qgb3JpZW50 ZWQgZGVzaWduIC0gc3ViY2xhc3MgZGVyaXZhdGlvbiBpcyBkb25lIHNvCnRoYXQgeW91IGRlZmlu ZSBhIG5ldyBjbGFzcyBhcyBhIHN1YmNsYXNzIG9mIGFuIGV4aXN0aW5nIGNsYXNzIGFuZCB0aGVu CnNwZWNpZnkgdGhlIGNoYW5nZXMgd2l0aGluIHRoYXQgY2xhc3MuIEJ1dCB0aGlzIGlzIG5vdCBo b3cgaXQgd29ya3MgaW4KWUFORy4gQSBZQU5HIG1vZHVsZSB0aGF0IGltcG9ydHMgYW5vdGhlciBh bmQgdXNlcyB0aGUgdG9wLWxldmVsIGF1Z21lbnQKZG9lcyB0aGVzZSBtb2RpZmljYXRpb25zIG9u bHkgImJ5IHRoZSB3YXkiIC0gaXQgbWF5IGRlZmluZSBpdHMgb3duIGRhdGEKdHJlZSwgcnBjcyBh bmQgbm90aWZpY2F0aW9ucyB0aGF0IGhhdmUgbm8gcmVsYXRpb24gdG8gdGhlIGZvcmVpZ24KbW9k dWxlLgoKU28gSSB3b3VsZCBpbmRlZWQgcHJlZmVyIHRoZSBvYmplY3Qtb3JpZW50ZWQgbW9kZWw6 IGlmIHlvdSB3YW50IHRvCm1vZGlmeSBhbiBleGlzdGluZyBtb2R1bGUsIHlvdSBjcmVhdGUgYSBu ZXcgb25lLCBkZWNsYXJlIHNvbWVob3cgdGhhdAppdCdzIGRlcml2ZWQgZnJvbSB0aGUgb3JpZ2lu YWwgbW9kdWxlIGFuZCBzcGVjaWZ5IHRoZSBtb2RpZmljYXRpb25zLiBJbgphIE5FVENPTkYgc2Vz c2lvbiBvbmx5IHRoaXMgbmV3IG1vZGVsIHdvdWxkIGJlIGFkdmVydGlzZWQsIG5vdCB0aGUKb3Jp Z2luYWwgb25lLgoKTGFkYQoKCj4gCj4gVG9kYXkgYXVnbWVudGluZyBjaG9pY2UgaXMgdGhlIG9u bHkgd2F5IHRvIG1ha2UgYW4gZXh0ZW5zaWJsZSBlbnVtZXJhdGlvbi4KPiAKPiBXZSBoYXZlIGF1 Z21lbnRhdGlvbiBvZiBub3RpZmljYXRpb25zIHdoaWNoIHdvdWxkIGJlIHRoZSBwcm9wZXIgd2F5 IHRvIGV4dGVuZCBzdGFuZGFyZCAKPiBub3RpZmljYXRpb25zIGUuZy4gc29tZXRoaW5nIGxpa2Ug dGhlIHN0dWZmIGluIFNoYXJvbidzIG5vdC1jb250ZW50IGRyYWZ0Lgo+IAo+IFdoYXQgaGFwcGVu cyBpZiBhIHN0YW5kYXJkIG1vZHVsZSAoWUFNKSBpcyBub3QgZGVmaW5lZCB1c2luZyBncm91cGlu Z3MuIFlvdXIgcHJvcG9zYWwgd291bGQgCj4gbWFrZSB0aGF0IGltcG9zc2libGUgdG8gZXh0ZW5k Lgo+IAo+IEV2ZW4gUGhpbCdzIGV4YW1wbGVzIGluIHRoZSBZQU5HIGRyYWZ0IHVzZSBhdWdtZW50 aW5nIHdpdGhvdXQgdXNlcy4KPiAKPiAKPiBCYWxhenMKPiAKPiAKPiAKPiA+IExhZGlzbGF2IExo b3RrYSB3cm90ZToKPiA+Pgo+ID4+IE5vdCByZWFsbHksIEkgYWxzbyBwcm9wb3NlZCB0byBhbGxv dyBhdWdtZW50LXN0bXQgb25seSB1bmRlciB1c2VzLXN0bXQgLQo+ID4+IGV2ZXJ5Ym9keSBpbiBE dWJsaW4gc2VlbWVkIHRvIHN1cHBvcnQgdGhpcyBjaGFuZ2UuCj4gPj4KLS0gCkxhZGlzbGF2IExo b3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 02:15:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8388F3A686B; Thu, 7 Aug 2008 02:15:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7A13A68AF for ; Thu, 7 Aug 2008 02:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rph2Cyq3VmF for ; Thu, 7 Aug 2008 02:15:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8F6533A686B for ; Thu, 7 Aug 2008 02:15:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2517E20DB9; Thu, 7 Aug 2008 11:16:19 +0200 (CEST) X-AuditID: c1b4fb3c-af0d0bb0000015b5-b2-489abd635f62 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 131E820D6B; Thu, 7 Aug 2008 11:16:19 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 11:16:18 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 11:16:18 +0200 Message-ID: <489AB79C.4090400@ericsson.com> Date: Thu, 07 Aug 2008 10:51:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> <4899E023.1000407@netconfcentral.com> <1218092322.6227.10.camel@missotis> <489AA58A.8030100@ericsson.com> <1218097498.6227.71.camel@missotis> In-Reply-To: <1218097498.6227.71.camel@missotis> X-OriginalArrivalTime: 07 Aug 2008 09:16:18.0454 (UTC) FILETIME=[4009E360:01C8F86E] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org CgpMYWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gQmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgxIx0IDA3 LiAwOC4gMjAwOCB2IDA5OjM0ICswMjAwOgo+PiBIZWxsbyBMYWRhLAo+PiBTZWUgc29tZSBxdWVz dGlvbnMgYmVsb3cuCj4+IEJhbGF6cwo+Pgo+PiBMYWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4+PiBB bmR5IEJpZXJtYW4gcMOtxaFlIHYgU3QgMDYuIDA4LiAyMDA4IHYgMTA6MzIgLTA3MDA6Cj4+Pj4g LSB0aGUgaW1wb3J0IHN0YXRlbWVudAo+Pj4+PiBoYXMgbm8gc2lkZSBlZmZlY3RzLCBzbyB0aGUg dHJlZSB0aGF0IHRoaXMgYXVnbWVudCBvcGVyYXRlcyBvbiBpcyBub3QKPj4+Pj4gcHJlc2VudC4K Pj4+PiB5ZXMgaXQgaXMgLS0gaW4geW91ciBpbXBsZW1lbnRhdGlvbiwgeW91IGhhdmUgdG8gdmFs aWRhdGUKPj4+IEkgZG9uJ3QgdGhpbmsgc28uIEluIGEgTkVUQ09ORiBzZXNzaW9uLCBpZiB0aGUg YWdlbnQgZG9lc24ndCBzZXBhcmF0ZWx5Cj4+PiBhZHZlcnRpc2UgdGhlIGZvcmVpZ24gKGltcG9y dGVkKSBkYXRhIG1vZGVsIHRoZW4gdGhlIG1haW4gZGF0YSB0cmVlIG9mCj4+PiB0aGlzIG1vZGVs IGlzIG5vdCBhdmFpbGFibGUgYW5kIHRoZSB0b3AtbGV2ZWwgYXVnbWVudCBjYW5ub3QgaGF2ZSBh bnkKPj4+IGVmZmVjdC4KPj4gSXMgaXQgbm90IGFuIGVycm9yIHRvIGltcG9ydCAodXNlKSBhIGRh dGEgbW9kZWwgYW5kIG5vdCBhZHZlcnRpc2UgaXQ/Cj4gCj4gQSBtb2R1bGUgbWF5IGJlIGltcG9y dGVkIGZvciBhIG51bWJlciBvZiByZWFzb25zLiBJZiBJIGltcG9ydCBlLmcuLAo+IGluZXQtdHlw ZXMsIGRvIEkgaGF2ZSB0byBhZHZlcnRpc2UgaW5ldC10eXBlcyBpbiBoZWxsbyBhbG9uZyB3aXRo IG15Cj4gZGF0YSBtb2RlbD8gSSBkb24ndCB0aGluayBzby4KPiAKPj4gSWYgeW91IGFyZSBldmVu IGF1Z21lbnRpbmcgdGhhdCBtb2RlbCAtIGV4dGVuZGluZyBpdCAtIGJ1dCB5b3UgZG8gbm90IHN1 cHBvcnQgaXQgdGhhdCAKPj4gZGVmaW5pdGVseSBzb3VuZHMgbGlrZSBhbiBlcnJvci4gRXh0ZW5k aW5nIGEgbm9uLWV4aXN0aW5nIChmb3IgbXkgYm94KSBtb2RlbCB0aGF0IHNvdW5kcyAKPj4gZnJl YWt5LiBJIGNvdWxkIGltYWdpbmUgdGhhdCB5b3Ugb25seSB1c2Ugc29tZSB0eXBlcyBvciBncm91 cGluZ3MgZnJvbSBhbiBpbXBvcnRlZCBtb2R1bGUsIGJ1dCAKPj4gaWYgd2Ugc3BlYWsgb2YgYXVn bWVudCB3ZSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBkYXRhIHRyZWUuCj4gCj4gQmFjayB0byBPT1Ag LSBpdCB5b3UgZGVmaW5lIGFuIGluc3RhbmNlIG9mIGEgY2xhc3MsIHlvdSBkb24ndCBzcGVjaWZ5 IGl0Cj4gdG9nZXRoZXIgd2l0aCBhbGwgaXRzIHN1cGVyY2xhc3Nlcy4gTXkgYm94IGp1c3QgdXNl cyBhIGRhdGEgbW9kZWwgdGhhdAo+IGlzIGRlcml2ZWQgZnJvbSBhbm90aGVyIG9uZSAtIGFuZCB0 aGF0IHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gdGhlCj4gZGVyaXZlZCBkYXRhIG1vZGVsLiAKPiAK VGhpcyBleGFtcGxlIElNSE8gaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBPTy4KCllvdSBoYXZlIGEg Y29udGFpbmVyIHdpdGggYSBsdW1wIG9mIGRhdGEgaW4gbW9kdWxlIEEuIFRoZSBpbiBtb2R1bGUg QiB5b3UgYXVnbWVudCBpdCB3aXRoIGEgCnNlY29uZCBsdW1wIG9mIGRhdGEuIElmIHlvdXIgbm9k ZSBkb2VzIG5vdCBhZHZlcnRpc2UvaW1wbGVtZW50IG1vZHVsZSBBLCB3aGF0IGFyZSB5b3UgCmF1 Z21lbnRpbmcgYWN0dWFsbHk/ClNvIGlmIHlvdSBhdWdtZW50IHNvbWV0aGluZyBpbiBtb2R1bGUg QSwgeW91IE1VU1QgaW1wbGVtZW50L2FkdmVydGlzZSBtb2R1bGUgQS4KCk9yIGRvIHlvdSBwcm9w b3NlLCB0aGF0IGFkdmVydGlzaW5nIHRoZSBhdWdtZW50aW5nIG1vZHVsZSBpbXBsaWNpdGx5IG1l YW5zIEkgaW1wbGVtZW50IGFsbCAKb3RoZXIgbmVlZGVkIG1vZHVsZXMgYXMgd2VsbD8gSSBwcmVm ZXIgZXhwbGljaXQgbWV0aG9kcy4KCkJhbGF6cwpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 02:48:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41003A69D4; Thu, 7 Aug 2008 02:48:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9C03A6AA4 for ; Thu, 7 Aug 2008 02:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsyaAnb6Pevx for ; Thu, 7 Aug 2008 02:48:07 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BCACF3A69D4 for ; Thu, 7 Aug 2008 02:48:07 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 26B58214CE for ; Thu, 7 Aug 2008 11:48:42 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-88-489ac4fa23bf Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1358021498 for ; Thu, 7 Aug 2008 11:48:42 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 11:48:41 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 11:48:41 +0200 Message-ID: <489ABF33.7020102@ericsson.com> Date: Thu, 07 Aug 2008 11:24:03 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 07 Aug 2008 09:48:41.0849 (UTC) FILETIME=[C6646E90:01C8F872] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Advertising yang-types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, If I use a module (YAM) that only contains types and groupings like yang-types do I have to advertise it? If I use a YAM that contains both data definition statements and types, but I only use/implement the types do I have to advertise it? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 02:50:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E883A6B23; Thu, 7 Aug 2008 02:50:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7B73A6B26 for ; Thu, 7 Aug 2008 02:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NA1zY9iSZQX for ; Thu, 7 Aug 2008 02:50:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 03D933A6AD1 for ; Thu, 7 Aug 2008 02:50:51 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 76511D800C5; Thu, 7 Aug 2008 11:51:26 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <489AB79C.4090400@ericsson.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> <4899E023.1000407@netconfcentral.com> <1218092322.6227.10.camel@missotis> <489AA58A.8030100@ericsson.com> <1218097498.6227.71.camel@missotis> <489AB79C.4090400@ericsson.com> Organization: CESNET Date: Thu, 07 Aug 2008 11:51:26 +0200 Message-Id: <1218102686.6227.82.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgxIx0IDA3LiAwOC4gMjAwOCB2IDEwOjUxICswMjAwOgoK PiA+IAo+ID4gQmFjayB0byBPT1AgLSBpdCB5b3UgZGVmaW5lIGFuIGluc3RhbmNlIG9mIGEgY2xh c3MsIHlvdSBkb24ndCBzcGVjaWZ5IGl0Cj4gPiB0b2dldGhlciB3aXRoIGFsbCBpdHMgc3VwZXJj bGFzc2VzLiBNeSBib3gganVzdCB1c2VzIGEgZGF0YSBtb2RlbCB0aGF0Cj4gPiBpcyBkZXJpdmVk IGZyb20gYW5vdGhlciBvbmUgLSBhbmQgdGhhdCBzaG91bGQgYmUgc3BlY2lmaWVkIGluIHRoZQo+ ID4gZGVyaXZlZCBkYXRhIG1vZGVsLiAKPiA+IAo+IFRoaXMgZXhhbXBsZSBJTUhPIGhhcyBub3Ro aW5nIHRvIGRvIHdpdGggT08uCj4gCj4gWW91IGhhdmUgYSBjb250YWluZXIgd2l0aCBhIGx1bXAg b2YgZGF0YSBpbiBtb2R1bGUgQS4gVGhlIGluIG1vZHVsZSBCIHlvdSBhdWdtZW50IGl0IHdpdGgg YSAKPiBzZWNvbmQgbHVtcCBvZiBkYXRhLiBJZiB5b3VyIG5vZGUgZG9lcyBub3QgYWR2ZXJ0aXNl L2ltcGxlbWVudCBtb2R1bGUgQSwgd2hhdCBhcmUgeW91IAo+IGF1Z21lbnRpbmcgYWN0dWFsbHk/ Cj4gU28gaWYgeW91IGF1Z21lbnQgc29tZXRoaW5nIGluIG1vZHVsZSBBLCB5b3UgTVVTVCBpbXBs ZW1lbnQvYWR2ZXJ0aXNlIG1vZHVsZSBBLgoKQnV0IEkgdGhpbmsgaXQgaXMgYW4gZXhhY3QgYW5h bG9neSB3aXRoIHN1YmNsYXNzaW5nOiBJIGFkdmVydGlzZSBqdXN0Cm1vZHVsZSBCLCB3aGljaCBp biB0dXJuIGRlY2xhcmVzIHRoYXQgaXQgaXMgZGVyaXZlZCBmcm9tIG1vZHVsZSBBLiBTbwpuYXR1 cmFsbHkgdGhlIGRldmljZSBoYXMgdG8gaW1wbGVtZW50IGV2ZXJ5dGhpbmcgdGhhdCBpcyBpbiB0 aGUKInN1cGVyY2xhc3MiIG1vZHVsZSBBIFBMVVMgdGhlIGNoYW5nZXMgZnJvbSBCLgoKQnV0IG1h eWJlIG91ciBOb2tpYS1TaWVtZW5zIGZyaWVuZHMgY291bGQgc3BlYWsgdXAgYW5kIGZvcm11bGF0 ZSB0aGVpcgpPTyBwcm9wb3NhbHMsIGl0IG1heSBoZWxwIGNsYXJpZnkgdGhpcy4KCkxhZGEKCi0t IApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlz dApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QK From netmod-bounces@ietf.org Thu Aug 7 03:02:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A003A6895; Thu, 7 Aug 2008 03:02:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB453A6B24 for ; Thu, 7 Aug 2008 03:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKjCvBG4m38E for ; Thu, 7 Aug 2008 03:02:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8031D3A6895 for ; Thu, 7 Aug 2008 03:02:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7C3B720ED5 for ; Thu, 7 Aug 2008 12:02:55 +0200 (CEST) X-AuditID: c1b4fb3e-a6e81bb000007a96-31-489ac84f56a9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 663E72125E for ; Thu, 7 Aug 2008 12:02:55 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 12:02:55 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 12:02:55 +0200 Message-ID: <489AC288.1000300@ericsson.com> Date: Thu, 07 Aug 2008 11:38:16 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <489AA3EC.6070603@ericsson.com> <1218096942.6227.63.camel@missotis> In-Reply-To: <1218096942.6227.63.camel@missotis> X-OriginalArrivalTime: 07 Aug 2008 10:02:55.0161 (UTC) FILETIME=[C3018290:01C8F874] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGVsbG8gTGFkYSwKCgpMYWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gQmFsYXpzIExlbmd5ZWwgcMOt xaFlIHYgxIx0IDA3LiAwOC4gMjAwOCB2IDA5OjI3ICswMjAwOgo+PiBIZWxsbyBMYWRhLAo+PiBJ IGRlZmluaXRlbHkgZG8gTk9UIHN1cHBvcnQgdGhpcyBjaGFuZ2UgYW5kIGRvbid0IHJlbWVtYmVy IGFueSBraW5kIG9mIGNvbnNlbnN1cyBhcm91bmQgaXQuCj4+Cj4+IEl0IHdvdWxkIG1ha2UgbWFw cGluZyBvZiBvYmplY3Qgb3JpZW50ZWQgZGF0YSBtb2RlbHMgdG8gWUFORyBpbXBvc3NpYmxlLgo+ Pgo+PiBBcyB0aGUgTm9raWEtU2llbWVucyBndXlzIGV2ZW4gcHJvcG9zZWQgdG8gZXh0ZW5kIHRo ZSBwb3NzaWJpbGl0aWVzIG9mIGF1Z21lbnQsIEkgZG9uJ3QgYmVsaWV2ZSAKPj4gdGhleSBzdXBw b3J0IHlvdXIgcHJvcG9zYWwuCj4gCj4gQnV0IGlzbid0IGl0IG1vcmUgYSB0YXNrIGZvciB0aGUg dG9wLWxldmVsIGF1Z21lbnQ/Cj4gCi4uLgo+IExhZGEKPiAKQ291bGQgeW91IGRlZmluZSBtb3Jl IHByZWNpc2VseSB3aGF0IGRvIHlvdSBtZWFuIGJ5ICJ0b3AtbGV2ZWwiIGF1Z21lbnQ/CgpJIGZv cmVzZWUgaW4gbXkgbW9kZWxzIG1vZHVsZSBCIGF1Z21lbnRpbmcgbW9kdWxlIEEgaW4gbXVsdGlw bGUgcGxhY2VzLiBUaGUgYXVnbWVudGVkIHBsYWNlcyAKYXJlIHR5cGljYWxseSBub3Qgb24gdGhl IHRvcCBsZXZlbCBvZiBtb2R1bGUgQSdzIGRhdGEgdHJlZT8gVGhlIGF1Z21lbnRzIGFyZSBhbGwg b24gdGhlIHRvcCAKbGV2ZWwgaW4gbW9kdWxlIEIuIElzIHRoaXMgdG9wLWxldmVsIGF1Z21lbnRp bmcgaW4geW91IGRlZmluaXRpb24/CgpCYWxhenMKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Aug 7 03:25:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB383A6896; Thu, 7 Aug 2008 03:25:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A493A6896 for ; Thu, 7 Aug 2008 03:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ6xFjkSj8WF for ; Thu, 7 Aug 2008 03:25:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 95A323A6B56 for ; Thu, 7 Aug 2008 03:25:09 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CB93C20FDF; Thu, 7 Aug 2008 12:24:59 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-45-489acd7b52f1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A9F0621002; Thu, 7 Aug 2008 12:24:59 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 12:24:59 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 12:24:59 +0200 Message-ID: <489AC7B5.9000003@ericsson.com> Date: Thu, 07 Aug 2008 12:00:21 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> <4899E023.1000407@netconfcentral.com> <1218092322.6227.10.camel@missotis> <489AA58A.8030100@ericsson.com> <1218097498.6227.71.camel@missotis> <489AB79C.4090400@ericsson.com> <1218102686.6227.82.camel@missotis> In-Reply-To: <1218102686.6227.82.camel@missotis> X-OriginalArrivalTime: 07 Aug 2008 10:24:59.0434 (UTC) FILETIME=[D85588A0:01C8F877] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGVsbG8gTGFkYSwKCkxhZGlzbGF2IExob3RrYSB3cm90ZToKPiBCYWxhenMgTGVuZ3llbCBww63F oWUgdiDEjHQgMDcuIDA4LiAyMDA4IHYgMTA6NTEgKzAyMDA6Cj4gCj4+PiBCYWNrIHRvIE9PUCAt IGl0IHlvdSBkZWZpbmUgYW4gaW5zdGFuY2Ugb2YgYSBjbGFzcywgeW91IGRvbid0IHNwZWNpZnkg aXQKPj4+IHRvZ2V0aGVyIHdpdGggYWxsIGl0cyBzdXBlcmNsYXNzZXMuIE15IGJveCBqdXN0IHVz ZXMgYSBkYXRhIG1vZGVsIHRoYXQKPj4+IGlzIGRlcml2ZWQgZnJvbSBhbm90aGVyIG9uZSAtIGFu ZCB0aGF0IHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gdGhlCj4+PiBkZXJpdmVkIGRhdGEgbW9kZWwu IAo+Pj4KPj4gVGhpcyBleGFtcGxlIElNSE8gaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBPTy4KPj4K Pj4gWW91IGhhdmUgYSBjb250YWluZXIgd2l0aCBhIGx1bXAgb2YgZGF0YSBpbiBtb2R1bGUgQS4g VGhlIGluIG1vZHVsZSBCIHlvdSBhdWdtZW50IGl0IHdpdGggYSAKPj4gc2Vjb25kIGx1bXAgb2Yg ZGF0YS4gSWYgeW91ciBub2RlIGRvZXMgbm90IGFkdmVydGlzZS9pbXBsZW1lbnQgbW9kdWxlIEEs IHdoYXQgYXJlIHlvdSAKPj4gYXVnbWVudGluZyBhY3R1YWxseT8KPj4gU28gaWYgeW91IGF1Z21l bnQgc29tZXRoaW5nIGluIG1vZHVsZSBBLCB5b3UgTVVTVCBpbXBsZW1lbnQvYWR2ZXJ0aXNlIG1v ZHVsZSBBLgo+IAo+IEJ1dCBJIHRoaW5rIGl0IGlzIGFuIGV4YWN0IGFuYWxvZ3kgd2l0aCBzdWJj bGFzc2luZzogSSBhZHZlcnRpc2UganVzdAo+IG1vZHVsZSBCLCB3aGljaCBpbiB0dXJuIGRlY2xh cmVzIHRoYXQgaXQgaXMgZGVyaXZlZCBmcm9tIG1vZHVsZSBBLiBTbwo+IG5hdHVyYWxseSB0aGUg ZGV2aWNlIGhhcyB0byBpbXBsZW1lbnQgZXZlcnl0aGluZyB0aGF0IGlzIGluIHRoZQo+ICJzdXBl cmNsYXNzIiBtb2R1bGUgQSBQTFVTIHRoZSBjaGFuZ2VzIGZyb20gQi4KPiAKbW9kdWxlIEEgewog ICBsaXN0IGZvbyB7CiAgICAgLi4uCiAgIH0KCiAgIGxpc3QgYmFyIHsKICAgICAgbGlzdCBiYXIt Y2hpbGQxIHsKICAgICAgICBsaXN0IGJhci1ncmFuZENoaWxkMSB7IC4uLiB9CiAgICAgIH0KCiAg ICAgIGxpc3QgYmFyLWNoaWxkMiB7IC4uLiB9CiAgIH0KfQoKbW9kdWxlIEIgewogICBpbXBvcnQg QSB7CiAgICAgcHJlZml4IGE7CiAgIH0KCiAgIGF1Z21lbnQgYTovYmFyL2Jhci1jaGlsZDEgeyAu Li4gfQp9CgpBc3N1bWluZyB5b3VyIGxvZ2ljIEkgYWR2ZXJ0aXNlIG9ubHkgbW9kdWxlIEIgYW5k IG5vdCBBLiBQbGVhc2UgYW5zd2VyIGZvciBlYWNoLCBkb2VzIG15IApuZXRjb25mIGFnZW50IGlt cGxlbWVudAotIGZvbyA/Ci0gYmFyLWNoaWxkMiA/Ci0gYmFyLWdyYW5kY2hpbGQxID8KCkZvciBt ZSB0aGUgYW5zd2VycyBhcmUgbm90IHRyaXZpYWwuIFVzaW5nIGluc3RlYWQgYW4gZXhwbGljaXQg YWR2ZXJ0aXNpbmcgb2YgbW9kdWxlIEEgaXMgbXVjaCAKbW9yZSBzaW1wbGUgbG9naWMuIEFueXdh eSB0aGUgZHJhZnQgTVVTVCBjaG9zZSBhbmQgZGVzY3JpYmUgb25lIG9mIHRoZSBzb2x1dGlvbnMu CkJhbGF6cwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpu ZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 04:21:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893653A698E; Thu, 7 Aug 2008 04:21:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61CA3A6B8C for ; Thu, 7 Aug 2008 04:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LQ3WgoQb9uc for ; Thu, 7 Aug 2008 04:21:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D07643A6B83 for ; Thu, 7 Aug 2008 04:21:05 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5D890D800C7; Thu, 7 Aug 2008 13:21:40 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <489AC7B5.9000003@ericsson.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <1218043131.6297.127.camel@missotis> <4899E023.1000407@netconfcentral.com> <1218092322.6227.10.camel@missotis> <489AA58A.8030100@ericsson.com> <1218097498.6227.71.camel@missotis> <489AB79C.4090400@ericsson.com> <1218102686.6227.82.camel@missotis> <489AC7B5.9000003@ericsson.com> Organization: CESNET Date: Thu, 07 Aug 2008 13:21:40 +0200 Message-Id: <1218108100.6227.102.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgxIx0IDA3LiAwOC4gMjAwOCB2IDEyOjAwICswMjAwOgoK PiA+IAo+IG1vZHVsZSBBIHsKPiAgICBsaXN0IGZvbyB7Cj4gICAgICAuLi4KPiAgICB9Cj4gCj4g ICAgbGlzdCBiYXIgewo+ICAgICAgIGxpc3QgYmFyLWNoaWxkMSB7Cj4gICAgICAgICBsaXN0IGJh ci1ncmFuZENoaWxkMSB7IC4uLiB9Cj4gICAgICAgfQo+IAo+ICAgICAgIGxpc3QgYmFyLWNoaWxk MiB7IC4uLiB9Cj4gICAgfQo+IH0KPiAKPiBtb2R1bGUgQiB7Cj4gICAgaW1wb3J0IEEgewo+ICAg ICAgcHJlZml4IGE7Cj4gICAgfQo+IAo+ICAgIGF1Z21lbnQgYTovYmFyL2Jhci1jaGlsZDEgeyAu Li4gfQo+IH0KPiAKPiBBc3N1bWluZyB5b3VyIGxvZ2ljIEkgYWR2ZXJ0aXNlIG9ubHkgbW9kdWxl IEIgYW5kIG5vdCBBLiBQbGVhc2UgYW5zd2VyIGZvciBlYWNoLCBkb2VzIG15IAo+IG5ldGNvbmYg YWdlbnQgaW1wbGVtZW50Cj4gLSBmb28gPwo+IC0gYmFyLWNoaWxkMiA/Cj4gLSBiYXItZ3JhbmRj aGlsZDEgPwoKV2hhdCBJIGFtIHRhbGtpbmcgYWJvdXQgaXMgbm90IHBvc3NpYmxlIHdpdGhpbiB0 aGUgY3VycmVudCBZQU5HCnNlbWFudGljcywgd2hpY2ggeW91ciBleGFtcGxlIHNlZW1zIHRvIGlt cGx5LiBTbyBvZiBjb3Vyc2UgdGhlIGFuc3dlcgppczogbm9uZSBvZiB0aGUgdGhyZWUgbm9kZXMu IEEgcG9zc2libGUgc29sdXRpb24gY291bGQgbG9vayBsaWtlIHRoaXM6Cgptb2R1bGUgQiB7CiAg aW5jbHVkZSBBIHsKICAgIHByZWZpeCBhOwogICAgYXVnbWVudCAvYTpiYXIvYTpiYXItY2hpbGQx IHsgLi4uIH0KICB9Cn0KClRoaXMgaW5jbHVkZSAtIGFzIG9wcG9zZWQgdG8gaW1wb3J0IC0gd291 bGQgcmVhbGx5IGluY2x1ZGUgdGhlIHRyZWUgZnJvbQpBIGluIHRoZSBtb2R1bGUgQiwgc28gYWxs IHRocmVlIG5vZGVzIGZyb20geW91ciBleGFtcGxlIHdvdWxkIGJlCmF2YWlsYWJsZSBpZiB5b3Ug YWR2ZXJ0aXNlIGp1c3QgQi4KClBlcmhhcHMgdGhpcyBjb3VsZCBiZSByZWFsaXplZCBqdXN0IGJ5 IGV4dGVuZGluZyB0aGUgaW5jbHVkZSBzdGF0ZW1lbnQKc28gdGhhdCBpdCBjYW4gaW5jbHVkZSAi bWFpbiIgbW9kdWxlcywgdG9vIC0gYnV0IHRoYXQncyBvbmx5IG9uZQpvcHRpb24uIAoKSW4gdGhp cyBjYXNlIGF1Z21lbnQgY291bGQgYmUgYWxsb3dlZCBpbnNpZGUgdXNlcyBhbmQgaW5jbHVkZQpz dGF0ZW1lbnRzLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6 IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 04:40:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E13E3A68CC; Thu, 7 Aug 2008 04:40:04 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEF93A69F0 for ; Thu, 7 Aug 2008 04:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jPcOXI1ZaKS for ; Thu, 7 Aug 2008 04:40:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 15A243A6830 for ; Thu, 7 Aug 2008 04:40:02 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id EBB54D800C5; Thu, 7 Aug 2008 13:40:04 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <489AC288.1000300@ericsson.com> References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <489AA3EC.6070603@ericsson.com> <1218096942.6227.63.camel@missotis> <489AC288.1000300@ericsson.com> Organization: CESNET Date: Thu, 07 Aug 2008 13:40:05 +0200 Message-Id: <1218109205.6227.120.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgxIx0IDA3LiAwOC4gMjAwOCB2IDExOjM4ICswMjAwOgoK PiA+IAo+IENvdWxkIHlvdSBkZWZpbmUgbW9yZSBwcmVjaXNlbHkgd2hhdCBkbyB5b3UgbWVhbiBi eSAidG9wLWxldmVsIiBhdWdtZW50PwoKSWYgeW91IHVzZSAiYXVnbWVudCIgaW5zaWRlIHRoZSBt b2R1bGUgc2NoZW1hIGhpZXJhcmFyY2h5Cig9bm9uLXRvcC1sZXZlbCksIHRoaXMgYXVnbWVudCBv cGVyYXRlcyBvbiB0aGUgbG9jYWwgc2NoZW1hIHRyZWUuCgpUaGUgdG9wLWxldmVsIGF1Z21lbnQg aW5kaWNhdGVzIHRoYXQgd2hlbmV2ZXIgdGhlIHNjaGVtYSB0cmVlIGZyb20gdGhlCmZvcmVpZ24g bW9kdWxlIGlzIHVzZWQsIGl0IHNob3VsZCBiZSBhdWdtZW50ZWQuCgo+IAo+IEkgZm9yZXNlZSBp biBteSBtb2RlbHMgbW9kdWxlIEIgYXVnbWVudGluZyBtb2R1bGUgQSBpbiBtdWx0aXBsZSBwbGFj ZXMuIFRoZSBhdWdtZW50ZWQgcGxhY2VzIAo+IGFyZSB0eXBpY2FsbHkgbm90IG9uIHRoZSB0b3Ag bGV2ZWwgb2YgbW9kdWxlIEEncyBkYXRhIHRyZWU/IFRoZSBhdWdtZW50cyBhcmUgYWxsIG9uIHRo ZSB0b3AgCj4gbGV2ZWwgaW4gbW9kdWxlIEIuIElzIHRoaXMgdG9wLWxldmVsIGF1Z21lbnRpbmcg aW4geW91IGRlZmluaXRpb24/CgpJZiB0aGUgYXJndW1lbnQgb2YgdGhvc2UgYXVnbWVudHMgcG9p bnRzIHRvIHRoZSBmb3JlaWduIHNjaGVtYSB0cmVlIChpdHMKcGFydHMgdXNlIHRoZSBmb3JlaWdu IG5hbWVzcGFjZSBwcmVmaXgpLCB0aGVuIHRoZXkgYXJlIHdoYXQgSSBtZWFuIGJ5CnRoZSB0b3At bGV2ZWwgYXVnbWVudHMuCgpBY3R1YWxseSB0aGUgbmFtZSBpcyBhIGJpdCBtaXNsZWFkaW5nIHNp bmNlIGF1Z21lbnQtc3RtdCBhdCB0aGUgdG9wCmxldmVsIG9mIGEgbW9kdWxlIGNhbiBhbHNvIGNo YW5nZSB0aGUgbG9jYWwgc2NoZW1hIHRyZWUuIFNvIG1heWJlCiJleHRlcm5hbCBhdWdtZW50IiBp cyBiZXR0ZXIsIGFzIEFuZHkgc3VnZ2VzdGVkLgoKTGFkYQoKPiAKPiBCYWxhenMKPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5n IGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0 RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5l dG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Aug 7 08:47:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D990F3A6955; Thu, 7 Aug 2008 08:47:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFCE3A694A for ; Thu, 7 Aug 2008 08:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q29bAxi8WdEW for ; Thu, 7 Aug 2008 08:47:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 69AFF3A68D0 for ; Thu, 7 Aug 2008 08:47:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B31D120974; Thu, 7 Aug 2008 17:48:12 +0200 (CEST) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-54-489b193c5c89 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A074C207BB; Thu, 7 Aug 2008 17:48:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 17:48:12 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 17:48:12 +0200 Message-ID: <489B1376.40403@ericsson.com> Date: Thu, 07 Aug 2008 17:23:34 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B415B6F4E1@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415B6F4E1@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 07 Aug 2008 15:48:12.0110 (UTC) FILETIME=[FF450EE0:01C8F8A4] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] minAccess/maxAccess X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, - create-only is used in Ericsson as well so I fully support Sharon's idea. You can set leaf foo's value once, when you create the containing list/container but never after leaf foo { type int32; default 27; create-only; // we actually call this restricted } Balazs Sharon Chisholm wrote: > Hi > > While inheriting minAccess and maxAccess is a good approach, it is > important to be able to override this to support things like create-only > or the ability to modify, but not create or delete. > > I propose then that we need a minAccess/maxAccess mechanism that > optionally overrides the access provided by the config/non-config bit. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 09:17:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9D43A6BF7; Thu, 7 Aug 2008 09:17:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771863A6C1F for ; Thu, 7 Aug 2008 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMmbm0bhhsQw for ; Thu, 7 Aug 2008 09:17:42 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 8E7843A6C21 for ; Thu, 7 Aug 2008 09:17:42 -0700 (PDT) Received: (qmail 28708 invoked from network); 7 Aug 2008 16:18:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 16:18:17 -0000 X-YMail-OSG: rzmvrdwVM1mrSQmdQh6QQ9QNE1QcMM2zZ6fvFBEA65Ubmka655FXlYJCe4gPJvoYiDhb7fTlAEpLdM1TyppLMPuYmBk8jc3sn5IF8o69zA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B2048.2090203@netconfcentral.com> Date: Thu, 07 Aug 2008 09:18:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <1218025449.6297.87.camel@missotis> <4899AAC1.1060902@netconfcentral.com> <1218035314.6297.94.camel@missotis> <4899C0B5.5070509@netconfcentral.com> <1218036899.6297.121.camel@missotis> <4899DAFE.4070203@netconfcentral.com> <489AA3EC.6070603@ericsson.com> In-Reply-To: <489AA3EC.6070603@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello Lada, > I definitely do NOT support this change and don't remember any kind of > consensus around it. > > It would make mapping of object oriented data models to YANG impossible. > I do not think augmenting a grouping will work because there is no way to detect which uses-stmts get augmented, unless your application knows about the augmenting module. Nothing in the any of the augmented modules is going to give any clue that all the 'uses acme:foo;' statements are really augmented with something else. The tool which is processing the augmented module really needs to know that when the 'uses' gets expanded. > As the Nokia-Siemens guys even proposed to extend the possibilities of > augment, I don't believe they support your proposal. > > Today augmenting choice is the only way to make an extensible enumeration. > This is not really the same thing. With an enumeration, the element name remains constant, and the content string varies. With a choice, the element names must all be different, and they can only appear once (in 1 case-stmt). BTW, I just found another error-check with augmenting a choice. If the choice has a default case, then you cannot augment the default case with any mandatory nodes. (Not sure pyang checks for that.) > We have augmentation of notifications which would be the proper way to > extend standard notifications e.g. something like the stuff in Sharon's > not-content draft. > > What happens if a standard module (YAM) is not defined using groupings. > Your proposal would make that impossible to extend. > > Even Phil's examples in the YANG draft use augmenting without uses. > Where is that? The only examples of augment I can find (4.2.8 and 7.15.4) are showing the 'when' clause and/or augmenting external nodes. But clearly, the 'when-stmt' can be used outside of a 'uses-stmt', so making this change would take away that feature. IMO, YANG lacks the ability for an operator or implementor to easily and correctly determine which objects must be supported (for any version of the module.) A simple 'table row' could have so many holes in it, or extras added to it, or even objects that pop in and out of existence depending on the arbitrary 'when-stmt' Xpath expression, that a human might not be able to make this determination just by reading the specification. Since YANG is supposed to be the human-friendly version of the DML, this is a problem. > > Balazs > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 09:34:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6583A6902; Thu, 7 Aug 2008 09:34:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534923A6C08 for ; Thu, 7 Aug 2008 09:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fnf+JEmbxDdY for ; Thu, 7 Aug 2008 09:34:56 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id C2FC03A6902 for ; Thu, 7 Aug 2008 09:34:31 -0700 (PDT) Received: (qmail 67673 invoked from network); 7 Aug 2008 16:35:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 16:35:07 -0000 X-YMail-OSG: _r0f5LAVM1l8Syh2jhnfasM.Wp77n4M16wbPWbpXju8_8HCyoW3fvjATVGwJBz9TkSvgYMrmyrvJtwYNHdRI78mZ_veM3jcOcj2aULjOrA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B2439.9030409@netconfcentral.com> Date: Thu, 07 Aug 2008 09:35:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <713043CE8B8E1348AF3C546DBE02C1B415B6F4E1@zcarhxm2.corp.nortel.com> <489B1376.40403@ericsson.com> In-Reply-To: <489B1376.40403@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] minAccess/maxAccess X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > - create-only is used in Ericsson as well so I fully support Sharon's idea. > You can set leaf foo's value once, when you create the containing > list/container but never after > > leaf foo { > type int32; > default 27; > create-only; // we actually call this restricted > } > This shows up a lot in MIBs, so it seems like a good idea to support it in YANG. What about the use-case where the agent is going to generate the value of the leaf, based on the other parameters or other factors? It will get saved in NV-storage, but the manager doesn't always get to pick the value. leaf ifIndex { description "The interface number assigned by the agent to this entry."; type if:InterfaceIndex; agent-create-only; } > Balazs > > Sharon Chisholm wrote: >> Hi >> >> While inheriting minAccess and maxAccess is a good approach, it is >> important to be able to override this to support things like create-only >> or the ability to modify, but not create or delete. >> >> I propose then that we need a minAccess/maxAccess mechanism that >> optionally overrides the access provided by the config/non-config bit. >> minAccess is a module conformance concept, not related to the object definition itself. >> Sharon Chisholm Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 10:32:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E363A697F; Thu, 7 Aug 2008 10:32:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F713A697F for ; Thu, 7 Aug 2008 10:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtNFr+ffSwgi for ; Thu, 7 Aug 2008 10:29:37 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 5060A3A68CF for ; Thu, 7 Aug 2008 10:29:37 -0700 (PDT) Received: (qmail 39343 invoked from network); 7 Aug 2008 17:29:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 17:29:48 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B310A.5070802@andybierman.com> Date: Thu, 07 Aug 2008 10:29:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group X-Mailman-Approved-At: Thu, 07 Aug 2008 10:32:52 -0700 Subject: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, From 7.6.5: The value of the leaf node is encoded to XML according to the type, and sent as character data in the element. The sections on built-in types do not define any XML encoding rules (yet). When will those be done? A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an for a or request, must be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value. I strongly object to this paragraph. It has no place in the YANG specification. If you want to modify the NETCONF operations, then do it in the NETCONF WG. I also object to the idea a module which happens to be specified in a YANG module should use a special 'YANG version' of the NETCONF protocol. The manager should control the retrieval of defaults, not the agent. This feature has nothing to do with YANG. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 13:09:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD5F3A6996; Thu, 7 Aug 2008 13:09:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2463A698A for ; Thu, 7 Aug 2008 13:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBkP4zujpCFv for ; Thu, 7 Aug 2008 13:09:40 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 562A53A688F for ; Thu, 7 Aug 2008 13:09:37 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 21A3476C4CB; Thu, 7 Aug 2008 22:09:09 +0200 (CEST) Date: Thu, 07 Aug 2008 22:09:04 +0200 (CEST) Message-Id: <20080807.220904.108338659.mbj@tail-f.com> To: andy@andybierman.com From: Martin Bjorklund In-Reply-To: <489B310A.5070802@andybierman.com> References: <489B310A.5070802@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > From 7.6.5: > > The value of the leaf node is encoded to XML according to the type, > and sent as character data in the element. > > > The sections on built-in types do not define any XML encoding > rules (yet). When will those be done? Section 8 says: The lexicographic representation of a value of a certain type is used in the XML encoding over NETCONF, and when specifying default values in a YANG module. And then each built-in type has a section called "Lexicographic Representation", e.g. 8.1.1. > A NETCONF server that replies to a or request MAY > choose not to send the leaf element if its value is the default > value. Thus, a client that receives an for a or > request, must be prepared to handle the case that a leaf > node with a default value is not present in the XML. In this case, > the value used by the server is known to be the default value. > > > I strongly object to this paragraph. > It has no place in the YANG specification. > If you want to modify the NETCONF operations, > then do it in the NETCONF WG. I don't agree that the NETCONF operation is changed. rfc4741 does not say one way or the other re. defaults. NETCONF has no concept of default values. The intention of this paragraph is to allow a capability such as 'with-defaults' to control if defaults are sent or not. IMO it is better to keep this paragraph - if we remove it people will not know if defaults should always be sent or what the intention of YANG was. Esp. since there is no standard 'with-defaults' capability, and it does not seem that it will get standardized any time soon. > I also object to the idea a module which happens to be > specified in a YANG module should use a special 'YANG version' > of the NETCONF protocol. The manager should control > the retrieval of defaults, not the agent. I agree. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 13:16:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F35428C125; Thu, 7 Aug 2008 13:16:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A96628C128 for ; Thu, 7 Aug 2008 13:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjrOkhxZVx1Q for ; Thu, 7 Aug 2008 13:16:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E905128C125 for ; Thu, 7 Aug 2008 13:16:11 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 7492476C4D0; Thu, 7 Aug 2008 22:16:07 +0200 (CEST) Date: Thu, 07 Aug 2008 22:16:05 +0200 (CEST) Message-Id: <20080807.221605.18131225.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489B2439.9030409@netconfcentral.com> References: <713043CE8B8E1348AF3C546DBE02C1B415B6F4E1@zcarhxm2.corp.nortel.com> <489B1376.40403@ericsson.com> <489B2439.9030409@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] minAccess/maxAccess X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Balazs Lengyel wrote: > > Hello, > > - create-only is used in Ericsson as well so I fully support Sharon's idea. > > You can set leaf foo's value once, when you create the containing list/container but never after > > leaf foo { > > type int32; > > default 27; > > create-only; // we actually call this restricted > > } > > > > This shows up a lot in MIBs, so it seems > like a good idea to support it in YANG. ...touching again the discussion about how much should be machine-readable and how much should be specified in the description clause ;-) > What about the use-case where the agent is > going to generate the value of the leaf, based on > the other parameters or other factors? It will get > saved in NV-storage, but the manager doesn't always > get to pick the value. > > leaf ifIndex { > description > "The interface number assigned by the agent to this entry."; > type if:InterfaceIndex; > agent-create-only; > } On my slides from Dublin we suggested: created-by ("system" / "user"); But it would be better if we can find one concept / keyword which covers all (most?) of the use cases. It is important to keep in mind how these creation/modification-specifications interact with a manager that does get-config to store a backup and later copy-config to restore it. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 13:22:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963E63A6358; Thu, 7 Aug 2008 13:22:10 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B03C3A6908 for ; Thu, 7 Aug 2008 13:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IijsZItprmOQ for ; Thu, 7 Aug 2008 13:22:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C7F8D3A6358 for ; Thu, 7 Aug 2008 13:22:08 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C50976C4CB; Thu, 7 Aug 2008 22:22:08 +0200 (CEST) Date: Thu, 07 Aug 2008 22:22:06 +0200 (CEST) Message-Id: <20080807.222206.134268097.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1218097498.6227.71.camel@missotis> References: <1218092322.6227.10.camel@missotis> <489AA58A.8030100@ericsson.com> <1218097498.6227.71.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQmFsYXpzIExlbmd5 ZWwgcMOtxaFlIHYgxIx0IDA3LiAwOC4gMjAwOCB2IDA5OjM0ICswMjAwOg0KPiA+IElzIGl0IG5v dCBhbiBlcnJvciB0byBpbXBvcnQgKHVzZSkgYSBkYXRhIG1vZGVsIGFuZCBub3QgYWR2ZXJ0aXNl IGl0Pw0KPiANCj4gQSBtb2R1bGUgbWF5IGJlIGltcG9ydGVkIGZvciBhIG51bWJlciBvZiByZWFz b25zLiBJZiBJIGltcG9ydCBlLmcuLA0KPiBpbmV0LXR5cGVzLCBkbyBJIGhhdmUgdG8gYWR2ZXJ0 aXNlIGluZXQtdHlwZXMgaW4gaGVsbG8gYWxvbmcgd2l0aCBteQ0KPiBkYXRhIG1vZGVsPyBJIGRv bid0IHRoaW5rIHNvLg0KDQoNCk5vLiAgQnV0IGl0IGlzbid0IHNwZWNpZmllZCAoeWV0KSBpbiB0 aGUgZHJhZnQuICBUaGlzIHdpbGwgYmUgZG9uZQ0Kd2hlbiB3ZSd2ZSBkZWNpZGVkIHdoYXQgdG8g ZG8gYWJvdXQgY29uZm9ybWFuY2UgaW4gZ2VuZXJhbC4gIEZvcg0KZXhhbXBsZSwgb25lIG9mIHRo ZSBxdWVzdGlvbnMgaXMgaWYgeW91IGFkdmVydGlzZSBtb2R1bGUgZm9vLCBhbmQgZm9vDQphdWdt ZW50cyBiYXIsIGRvIHlvdSBoYXZlIHRvIGltcGxlbWVudCBhbmQgYWR2ZXJ0aXNlIGJhciBhcyB3 ZWxsPyAgKEkNCmRvbid0IHRoaW5rIHNvKS4NCg0KDQovbWFydGluDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1v ZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 7 13:28:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AF23A67B3; Thu, 7 Aug 2008 13:28:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81633A6936 for ; Thu, 7 Aug 2008 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bXbEySwu942 for ; Thu, 7 Aug 2008 13:28:03 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 0E3E23A67B3 for ; Thu, 7 Aug 2008 13:28:03 -0700 (PDT) Received: (qmail 83781 invoked from network); 7 Aug 2008 20:27:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 20:27:45 -0000 X-YMail-OSG: 6QGjunYVM1k.0c3izHBQhF8B15NsezNtqILtOZUMnLjtJVoB4jAjq0EuA.NluavgI4GAjpdRLvK4AlAQLX5ID.d2s37QsjcwABmqUFXVYA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B5ABF.50102@netconfcentral.com> Date: Thu, 07 Aug 2008 13:27:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> In-Reply-To: <20080807.220904.108338659.mbj@tail-f.com> Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> From 7.6.5: >> >> The value of the leaf node is encoded to XML according to the type, >> and sent as character data in the element. >> >> >> The sections on built-in types do not define any XML encoding >> rules (yet). When will those be done? > > Section 8 says: > > The lexicographic representation of a value of a certain type is used > in the XML encoding over NETCONF, and when specifying default values > in a YANG module. > > And then each built-in type has a section called "Lexicographic > Representation", e.g. 8.1.1. > >> A NETCONF server that replies to a or request MAY >> choose not to send the leaf element if its value is the default >> value. Thus, a client that receives an for a or >> request, must be prepared to handle the case that a leaf >> node with a default value is not present in the XML. In this case, >> the value used by the server is known to be the default value. >> >> >> I strongly object to this paragraph. >> It has no place in the YANG specification. >> If you want to modify the NETCONF operations, >> then do it in the NETCONF WG. > > I don't agree that the NETCONF operation is changed. rfc4741 does not > say one way or the other re. defaults. NETCONF has no concept of > default values. > That is not true. It the leaf exists in the system, because mandatory is false and there is a default value to apply, then it is part of the configuration database. 7.1. Description: Retrieve all or part of a specified configuration. ... filter: The filter element identifies the portions of the device configuration to retrieve. If this element is unspecified, the entire configuration is returned. RFC 4741 clearly states that a get-config (and also get) without any filter returns the entire configuration database. Nowhere in the text on filtering does it mention any consideration of the default value as part of the filtering process. That means it is NOT part of the filtering process. I do not agree at all that agent MAY leave these nodes out, if they claim conformance to RFC 4741. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 14:08:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0A53A6976; Thu, 7 Aug 2008 14:08:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A82D28C179 for ; Thu, 7 Aug 2008 14:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81-L3mHV53G3 for ; Thu, 7 Aug 2008 14:08:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6F24928C165 for ; Thu, 7 Aug 2008 14:08:45 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id F3C9776C4CB; Thu, 7 Aug 2008 23:08:44 +0200 (CEST) Date: Thu, 07 Aug 2008 23:08:40 +0200 (CEST) Message-Id: <20080807.230840.181322445.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489A0874.1040103@netconfcentral.com> References: <489A0874.1040103@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Instead of adding arbitrarily nested 'if-feature' > meta-containers, a new 'for-feature' sub-statement for the basic > objects declaring which feature is associated > with the entire subtree. This is also how the if-feature statement me and Phil suggested in Dublin would work. Or did I misunderstand something? > Just like SMIv2, > it is debatable whether or not an object has to be > part of a feature or is there a default. Also, > are child nodes allowed to be in different features? (IMO, no) No. I think a flat partitioning of the module into features covers the magic 80% of the use cases. > conformance readonly-if { > uses-feature if-basic { > refine "/if:interfaces/if:interface/if:mtu" { > config false; > } > } > } > > } I suggested three different types of variations of a module: 1. variations defined in the module itself - e.g. partition the module into "features" 2. sane implementation-specific variations - e.g. limits on max-elements due to hw limitations or 3. insane implementation-specific variations - changing a leaf into a container I think the discussion would benefit from concentrating on which variations we would like to support (if any) in the different categories. It seems we agree that partitioning the module falls into category 1, and that it is useful. We also discussed having server-specific defaults in category 1, but having "access-restricions" (changing from config true to false) in category 2. Is there a use case when this clearly falls into category 1? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 14:13:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395B628C1A5; Thu, 7 Aug 2008 14:13:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4247E28C1A6 for ; Thu, 7 Aug 2008 14:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOwQPoQe-4SS for ; Thu, 7 Aug 2008 14:13:48 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6222628C197 for ; Thu, 7 Aug 2008 14:13:48 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 67D7476C4CB; Thu, 7 Aug 2008 23:13:47 +0200 (CEST) Date: Thu, 07 Aug 2008 23:13:43 +0200 (CEST) Message-Id: <20080807.231343.51668324.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489B5ABF.50102@netconfcentral.com> References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489B5ABF.50102@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Martin Bjorklund wrote: > > I don't agree that the NETCONF operation is changed. rfc4741 does not > > say one way or the other re. defaults. NETCONF has no concept of > > default values. > > > > That is not true. > It the leaf exists in the system, because mandatory is false > and there is a default value to apply, then it is part > of the configuration database. > > 7.1. > > Description: > > Retrieve all or part of a specified configuration. > > ... > > filter: > > The filter element identifies the portions of the device > configuration to retrieve. If this element is unspecified, the > entire configuration is returned. > > > RFC 4741 clearly states that a get-config (and also get) without > any filter returns the entire configuration database. Right, but it does not say that if a leaf has a default, then it exist in the configuration database. So if you have the view that the configuration consist of all data that the user explicitly sets, then you are compliant if defaults are not returned. I think it is clear that rfc4741 is a bit fussy on this subject. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 7 14:18:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EDE28C146; Thu, 7 Aug 2008 14:18:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498A028C1B1 for ; Thu, 7 Aug 2008 14:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXMSWEkjHOSM for ; Thu, 7 Aug 2008 14:18:38 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 8E82028C1A8 for ; Thu, 7 Aug 2008 14:18:38 -0700 (PDT) Received: (qmail 75556 invoked from network); 7 Aug 2008 21:18:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 21:18:37 -0000 X-YMail-OSG: ATwDFkkVM1nXz5Q.D7ZXu8NG9GSU63mm8uHNLDopy9f3rj2FUZre0O713kwF1aFul9pioeKkMR3Ae5.wZZm3HRHRnJOB1iaWA.Kpv6fW6Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B66AB.70302@netconfcentral.com> Date: Thu, 07 Aug 2008 14:18:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489A0874.1040103@netconfcentral.com> <20080807.230840.181322445.mbj@tail-f.com> In-Reply-To: <20080807.230840.181322445.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Instead of adding arbitrarily nested 'if-feature' >> meta-containers, a new 'for-feature' sub-statement for the basic >> objects declaring which feature is associated >> with the entire subtree. > > This is also how the if-feature statement me and Phil suggested in Dublin > would work. Or did I misunderstand something? > I do not want if-feature to be nested. I prefer to consider it a property I attach to a container, list, leaf, etc., rather than adding another unnamed meta-containment layer to the YANG 'tree'. >> Just like SMIv2, >> it is debatable whether or not an object has to be >> part of a feature or is there a default. Also, >> are child nodes allowed to be in different features? (IMO, no) > > No. I think a flat partitioning of the module into features covers > the magic 80% of the use cases. > >> conformance readonly-if { >> uses-feature if-basic { >> refine "/if:interfaces/if:interface/if:mtu" { >> config false; >> } >> } >> } >> >> } > > I suggested three different types of variations of a module: > > 1. variations defined in the module itself > - e.g. partition the module into "features" > 2. sane implementation-specific variations > - e.g. limits on max-elements due to hw limitations or > 3. insane implementation-specific variations > - changing a leaf into a container > > I think the discussion would benefit from concentrating on which > variations we would like to support (if any) in the different > categories. > > It seems we agree that partitioning the module falls into category 1, > and that it is useful. We also discussed having server-specific > defaults in category 1, but having "access-restricions" (changing from > config true to false) in category 2. Is there a use case when this > clearly falls into category 1? > IMO, it should be up to the data modelers to decide what the conformance levels for the module should be. My conformance macro proposal allows features from other modules to be included in the conformance requirements, which is important in the IETF. It also allows the DM writer to decide how features relate to conformance requirements. It allows the same feature (with different refinements) to be included in different conformance levels. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 01:28:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58BE3A6CC5; Fri, 8 Aug 2008 01:28:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FEF3A6C9A; Fri, 8 Aug 2008 01:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ZLZ4VpMW1R; Fri, 8 Aug 2008 01:28:37 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 144A23A6CCD; Fri, 8 Aug 2008 01:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 6DCD33BF5F; Fri, 8 Aug 2008 10:28:00 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30565-01-90; Fri, 8 Aug 2008 10:28:00 +0200 (CEST) Received: from wl-eduroam-50-246.publik.su.se (wl-eduroam-50-246.publik.su.se [77.238.33.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 03BF93BE22; Fri, 8 Aug 2008 10:27:59 +0200 (CEST) From: Leif Johansson To: netconf@ietf.org Date: Fri, 8 Aug 2008 10:27:58 +0200 User-Agent: KMail/1.9.9 References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> In-Reply-To: <20080807.231856.142574379.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808081027.58888.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] XML element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thursday 07 August 2008 23:18:56 Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, Sorry for cross-posting this but this is probably critically important for netmod wg too... > > > > Is the NETCONF agent allowed to accept XML elements > > out of the specified order? > > Do you mean inside the protocol or inside the data? > I think this question may be related to the question I asked at the mic in Dublin about the uniqueness of representation of a yang model in xml form. A necessary (but probably not sufficient) requirement that since yang lists are order-preserving the corresponging xml representation needs to be order-preserving too. It is absolutely critical for yang that there is a *unique* mapping between yang and xml since yang uses xpath. Cheers Leif _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 02:12:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B713A68C0; Fri, 8 Aug 2008 02:12:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF5C3A68C0 for ; Fri, 8 Aug 2008 02:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdG8Iddsek1H for ; Fri, 8 Aug 2008 02:12:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DF5263A693B for ; Fri, 8 Aug 2008 02:12:27 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F04221225; Fri, 8 Aug 2008 11:12:21 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-04-489c0df5ef09 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 27BE520141; Fri, 8 Aug 2008 11:12:21 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:12:20 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:12:20 +0200 Message-ID: <489C0DEC.9040807@ericsson.com> Date: Fri, 08 Aug 2008 11:12:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489B5ABF.50102@netconfcentral.com> <20080807.231343.51668324.mbj@tail-f.com> In-Reply-To: <20080807.231343.51668324.mbj@tail-f.com> X-OriginalArrivalTime: 08 Aug 2008 09:12:20.0634 (UTC) FILETIME=[DCB32FA0:01C8F936] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I think whether a leaf set by default exists or not should be a topic on the interim. We have been debating this for a long time and I would like to have it very clearly described after the interim. We have discussed all 3 possibilities: A) Configuration is what drives a device, so it is not important how it got there: default or an explicit set. This means a leaf set by default DOES exist. B) Configuration is what you set manually to make the device work, so even if a default does modify how the device works, a leaf set by default DOES NOT exist. C) We try to accommodate both views and try to avoid saying whether such a leaf exists or not. D) Make this a capability, but that might be an overkill. My preference is A, but not everyone agrees. We should also consider that the existence of a leaf effects at least the following: - results of get/get-config - success of edit-config for delete/create - evaluation of must statements - evaluation of unique statements - else? It is a separate question whether such values should be presented in replies to get/get-config. Balazs Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> I don't agree that the NETCONF operation is changed. rfc4741 does not >>> say one way or the other re. defaults. NETCONF has no concept of >>> default values. >>> >> That is not true. >> It the leaf exists in the system, because mandatory is false >> and there is a default value to apply, then it is part >> of the configuration database. >> >> 7.1. >> >> Description: >> >> Retrieve all or part of a specified configuration. >> >> ... >> >> filter: >> >> The filter element identifies the portions of the device >> configuration to retrieve. If this element is unspecified, the >> entire configuration is returned. >> >> >> RFC 4741 clearly states that a get-config (and also get) without >> any filter returns the entire configuration database. > > Right, but it does not say that if a leaf has a default, then it exist > in the configuration database. So if you have the view that the > configuration consist of all data that the user explicitly sets, then > you are compliant if defaults are not returned. > > I think it is clear that rfc4741 is a bit fussy on this subject. > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 02:18:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699A23A6CC1; Fri, 8 Aug 2008 02:18:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B763A6CE4; Fri, 8 Aug 2008 02:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP6-boqSFHk6; Fri, 8 Aug 2008 02:18:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 191583A6CC3; Fri, 8 Aug 2008 02:18:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48A9D203D1; Fri, 8 Aug 2008 11:18:23 +0200 (CEST) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-d7-489c0f5f953b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 26C71209A5; Fri, 8 Aug 2008 11:18:23 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18:22 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18:22 +0200 Message-ID: <489C0F56.6030801@ericsson.com> Date: Fri, 08 Aug 2008 11:18:14 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , "Ersue, Mehmet (NSN - DE/Muenich)" , Bert Wijnen - IETF References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> In-Reply-To: <20080807.220904.108338659.mbj@tail-f.com> X-OriginalArrivalTime: 08 Aug 2008 09:18:22.0389 (UTC) FILETIME=[B4529E50:01C8F937] X-Brightmail-Tracker: AAAAAA== Cc: David B Harrington , netconf mailing list , netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: >> A NETCONF server that replies to a or request MAY >> choose not to send the leaf element if its value is the default >> value. Thus, a client that receives an for a or >> request, must be prepared to handle the case that a leaf >> node with a default value is not present in the XML. In this case, >> the value used by the server is known to be the default value. >> >> >> I strongly object to this paragraph. >> It has no place in the YANG specification. >> If you want to modify the NETCONF operations, >> then do it in the NETCONF WG. > > I don't agree that the NETCONF operation is changed. rfc4741 does not > say one way or the other re. defaults. NETCONF has no concept of > default values. > > The intention of this paragraph is to allow a capability such as > 'with-defaults' to control if defaults are sent or not. IMO it is > better to keep this paragraph - if we remove it people will not know > if defaults should always be sent or what the intention of YANG was. > Esp. since there is no standard 'with-defaults' capability, and it > does not seem that it will get standardized any time soon. > Maybe we should get with-defaults standardized. I hereby ask the NETCONF/NETMOD community and specially the chairs of NETCONF if they would accept as a new NETCONF work item a small draft adding a with-defaults option to Netconf as a capability. As my Partial locking draft seems to wind down (Is this wishful thinking :-) I might even volunteer to write a draft on with-defaults. Opinions? Good idea? Feasible idea? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 02:38:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243D43A6407; Fri, 8 Aug 2008 02:38:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58CA3A6B81 for ; Fri, 8 Aug 2008 02:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAZChPK0s51a for ; Fri, 8 Aug 2008 02:38:33 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id B007D3A6841 for ; Fri, 8 Aug 2008 02:38:14 -0700 (PDT) Received: (qmail 77968 invoked from network); 8 Aug 2008 09:38:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 09:37:59 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C13F5.5030800@netconfcentral.com> Date: Fri, 08 Aug 2008 02:37:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489B5ABF.50102@netconfcentral.com> <20080807.231343.51668324.mbj@tail-f.com> <489C0DEC.9040807@ericsson.com> In-Reply-To: <489C0DEC.9040807@ericsson.com> Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > I think whether a leaf set by default exists or not should be a topic on > the interim. We have been debating this for a long time and I would like > to have it very clearly described after the interim. > The first step is agreement that this is a protocol issue and has nothing to do with YANG. If the manager sets a leaf to its default value, is the agent required to save that leaf in NV-storage? Upon the next reboot, is the agent required to use the manager-stored value, no matter what? Even if the SW image changes and the default value changes? The argument against returning defaults seems to be that it will waste bandwidth to retrieve them. There is probably 1000s of pages of external CLI documentation that the operator could track down and read, rather than waste 50 milliseconds retrieving the data directly. Remember that the defaults on the agent may have nothing to do with YANG, or may not have any default defined, or may have different platform-specific defaults. Andy > We have discussed all 3 possibilities: > A) Configuration is what drives a device, so it is not important how it > got there: default or an explicit set. This means a leaf set by default > DOES exist. > B) Configuration is what you set manually to make the device work, so > even if a default does modify how the device works, a leaf set by > default DOES NOT exist. > C) We try to accommodate both views and try to avoid saying whether such > a leaf exists or not. > D) Make this a capability, but that might be an overkill. > > My preference is A, but not everyone agrees. We should also consider > that the existence of a leaf effects at least the following: > - results of get/get-config > - success of edit-config for delete/create > - evaluation of must statements > - evaluation of unique statements > - else? > > It is a separate question whether such values should be presented in > replies to get/get-config. > > Balazs > > Martin Bjorklund wrote: >> Hi, >> >> Andy Bierman wrote: >>> Martin Bjorklund wrote: >>>> I don't agree that the NETCONF operation is changed. rfc4741 does not >>>> say one way or the other re. defaults. NETCONF has no concept of >>>> default values. >>>> >>> That is not true. >>> It the leaf exists in the system, because mandatory is false >>> and there is a default value to apply, then it is part >>> of the configuration database. >>> >>> 7.1. >>> >>> Description: >>> >>> Retrieve all or part of a specified configuration. >>> >>> ... >>> >>> filter: >>> >>> The filter element identifies the portions of the device >>> configuration to retrieve. If this element is unspecified, >>> the >>> entire configuration is returned. >>> >>> >>> RFC 4741 clearly states that a get-config (and also get) without >>> any filter returns the entire configuration database. >> >> Right, but it does not say that if a leaf has a default, then it exist >> in the configuration database. So if you have the view that the >> configuration consist of all data that the user explicitly sets, then >> you are compliant if defaults are not returned. >> >> I think it is clear that rfc4741 is a bit fussy on this subject. >> >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 02:40:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688CB3A6407; Fri, 8 Aug 2008 02:40:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EC23A6841 for ; Fri, 8 Aug 2008 02:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHQ3cLDMDuUm for ; Fri, 8 Aug 2008 02:39:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6B6B53A693B for ; Fri, 8 Aug 2008 02:39:58 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F0A3920B47; Fri, 8 Aug 2008 11:39:46 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-78-489c1462b784 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D465B20C85; Fri, 8 Aug 2008 11:39:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:39:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:39:45 +0200 Message-ID: <489C145A.6030801@ericsson.com> Date: Fri, 08 Aug 2008 11:39:38 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <1218092322.6227.10.camel@missotis> <489AA58A.8030100@ericsson.com> <1218097498.6227.71.camel@missotis> <20080807.222206.134268097.mbj@tail-f.com> In-Reply-To: <20080807.222206.134268097.mbj@tail-f.com> X-OriginalArrivalTime: 08 Aug 2008 09:39:45.0989 (UTC) FILETIME=[B1686F50:01C8F93A] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > ... > For > example, one of the questions is if you advertise module foo, and foo > augments bar, do you have to implement and advertise bar as well? (I > don't think so). > > > /martin I would be surprised by this bit. In my view if you advertise foo you promise to implement all data definition statements of foo. Augment is a data definition statement. If you don't implement bar you can not implement the augment that means you must implement bar as well. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 02:48:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FF33A68FF; Fri, 8 Aug 2008 02:48:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185AA3A6C31 for ; Fri, 8 Aug 2008 02:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKMBgVZ1NHPm for ; Fri, 8 Aug 2008 02:48:58 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 129A73A6407 for ; Fri, 8 Aug 2008 02:48:58 -0700 (PDT) Received: (qmail 2249 invoked from network); 8 Aug 2008 09:48:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 09:48:56 -0000 X-YMail-OSG: zvXXqgUVM1k3mg3m7eLBN4MMC08VG_4RUsR_lEKUjU4QuzTP0QSsm.RFRJTH__Exkr_5IAzlzjqqJLglJqVWeq37SrhGM1hZ3W4xLHW7_WzuCYUMF6dE3LsRGoN6Frw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C1686.8000607@netconfcentral.com> Date: Fri, 08 Aug 2008 02:48:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489C0F56.6030801@ericsson.com> In-Reply-To: <489C0F56.6030801@ericsson.com> Cc: David B Harrington , netmod@ietf.org, netconf mailing list Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > > > Martin Bjorklund wrote: >>> A NETCONF server that replies to a or request MAY >>> choose not to send the leaf element if its value is the default >>> value. Thus, a client that receives an for a or >>> request, must be prepared to handle the case that a >>> leaf >>> node with a default value is not present in the XML. In this case, >>> the value used by the server is known to be the default value. >>> >>> >>> I strongly object to this paragraph. >>> It has no place in the YANG specification. >>> If you want to modify the NETCONF operations, >>> then do it in the NETCONF WG. >> >> I don't agree that the NETCONF operation is changed. rfc4741 does not >> say one way or the other re. defaults. NETCONF has no concept of >> default values. >> >> The intention of this paragraph is to allow a capability such as >> 'with-defaults' to control if defaults are sent or not. IMO it is >> better to keep this paragraph - if we remove it people will not know >> if defaults should always be sent or what the intention of YANG was. >> Esp. since there is no standard 'with-defaults' capability, and it >> does not seem that it will get standardized any time soon. >> > > Maybe we should get with-defaults standardized. > > I hereby ask the NETCONF/NETMOD community and specially the chairs of > NETCONF if they would accept as a new NETCONF work item a small draft > adding a with-defaults option to Netconf as a capability. As my Partial > locking draft seems to wind down (Is this wishful thinking :-) I might > even volunteer to write a draft on with-defaults. > You mean something like this: http://tools.ietf.org/html/draft-bierman-ncx-ext-00 I would be interested in pulling out just the with-defaults and republishing this draft. IMO, a capability is overkill, but if an agent wants to suppress defaults unless explicitly requested to send them, that should be OK, as long as there is a status flag the manager can retrieve that indicates this is how the agent works. > Opinions? Good idea? Feasible idea? > > Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 03:01:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35C43A6CF5; Fri, 8 Aug 2008 03:01:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799933A6CF9 for ; Fri, 8 Aug 2008 03:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQLqkcwP+u53 for ; Fri, 8 Aug 2008 03:01:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id ECD4B3A6CC3 for ; Fri, 8 Aug 2008 03:01:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 167712016D; Fri, 8 Aug 2008 12:01:25 +0200 (CEST) X-AuditID: c1b4fb3e-a8684bb000007a96-0a-489c1974c7b4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F29D320103; Fri, 8 Aug 2008 12:01:24 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:01:24 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:01:24 +0200 Message-ID: <489C196C.5000209@ericsson.com> Date: Fri, 08 Aug 2008 12:01:16 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <20080702.091623.190514914.mbj@tail-f.com> <20080702074204.GC850@elstar.local> <486B3F45.1010802@netconfcentral.com> In-Reply-To: <486B3F45.1010802@netconfcentral.com> X-OriginalArrivalTime: 08 Aug 2008 10:01:24.0379 (UTC) FILETIME=[B74F06B0:01C8F93D] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I think the definition of deprecated should be changed. Today it states that if foo is deprecated it might or might not be there, but I agree with Andy that it should rather mean it is supported now, but will be removed in the future (that is the same philosophy that they use in Java). So the proposed text is: Old text: "deprecated" indicates an obsolete definition, but it permits new/ continued implementation in order to foster interoperability with older/existing implementations. New text: "deprecated" means that a definition is still implemented and usable - but you should not use it. It will gradually be phased out in the future. Balazs Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Wed, Jul 02, 2008 at 09:16:23AM +0200, Martin Bjorklund wrote: >> >>> As we have discussed earlier, we don't currently have a fine grained >>> agent conformance mechanism, and it seems consensus is to not do this >>> now >>> (with the possible exception of when-capability). >>> >>> This means that a server that claims conformance to a module must >>> implement it fully (modulo when-capability). >>> >>> But this makes a 'deprected' object problematic. If an object is >>> deprecated, it means: >>> >>> "deprecated" indicates an obsolete definition, but it permits >>> new/continued implementation in order to foster >>> interoperability with older/existing implementations. >>> >>> So a client knows that a server fully implements a module, but if >>> there are any deprecated objects, it doesn't know if those objects are >>> implemented or not. >>> >>> Can we remove 'deprected' and use 'current' and 'obsolete' only? >> >> The assumption that every implementation will implement modules fully >> is an illusion if you ask me. I think the distinction between obsolete >> and deprecated has been useful in the SMI space and so I would not >> easily give it up. >> > > deprecated serves a very useful purpose -- it means the > feature is supported now, but it will go away in the future. > It is needed to phase out old API mechanisms, instead of > eliminating them abruptly from version N to N+1. > >> /js >> > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 03:13:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43A83A6D17; Fri, 8 Aug 2008 03:13:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C143A6967; Fri, 8 Aug 2008 03:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56FkErNHIZrF; Fri, 8 Aug 2008 03:13:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9AC5E3A6D25; Fri, 8 Aug 2008 03:12:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B817620030; Fri, 8 Aug 2008 12:12:23 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-12-489c1c077c25 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 97AC120535; Fri, 8 Aug 2008 12:12:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:12:23 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:12:23 +0200 Message-ID: <489C1BFF.70707@ericsson.com> Date: Fri, 08 Aug 2008 12:12:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489C0F56.6030801@ericsson.com> <489C1686.8000607@netconfcentral.com> In-Reply-To: <489C1686.8000607@netconfcentral.com> X-OriginalArrivalTime: 08 Aug 2008 10:12:23.0136 (UTC) FILETIME=[3FF55E00:01C8F93F] X-Brightmail-Tracker: AAAAAA== Cc: David B Harrington , netmod@ietf.org, netconf mailing list Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: >> Maybe we should get with-defaults standardized. >> >> I hereby ask the NETCONF/NETMOD community and specially the chairs of >> NETCONF if they would accept as a new NETCONF work item a small draft >> adding a with-defaults option to Netconf as a capability. As my >> Partial locking draft seems to wind down (Is this wishful thinking :-) >> I might even volunteer to write a draft on with-defaults. >> > > You mean something like this: > > http://tools.ietf.org/html/draft-bierman-ncx-ext-00 > > I would be interested in pulling out just the with-defaults > and republishing this draft. IMO, a capability is overkill, > but if an agent wants to suppress defaults unless explicitly > requested to send them, that should be OK, as long > as there is a status flag the manager can retrieve that > indicates this is how the agent works. > I think that would be splendid. The flag you mention could go into the Netconf Monitoring model Scott is working on (timing, extensibility of that model). On the other hand some might argue, that if we already have one method to indicate optional behavior (capabilities) why invent a second one (flags). If you do this yourself good. if you think I should help or do it myself say so. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 05:24:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6343A6AEA; Fri, 8 Aug 2008 05:24:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED013A6D39 for ; Fri, 8 Aug 2008 05:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocF636vCTaqY for ; Fri, 8 Aug 2008 05:24:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EAFC73A6CF3 for ; Fri, 8 Aug 2008 05:24:14 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC78520022 for ; Fri, 8 Aug 2008 14:24:13 +0200 (CEST) X-AuditID: c1b4fb3c-b00d2bb0000015b5-9a-489c3aeda578 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BC8862052D for ; Fri, 8 Aug 2008 14:24:13 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 14:24:13 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 14:24:13 +0200 Message-ID: <489C3AE6.2030709@ericsson.com> Date: Fri, 08 Aug 2008 14:24:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 08 Aug 2008 12:24:13.0513 (UTC) FILETIME=[AAE91B90:01C8F951] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] RPCs in Lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, In Dublin I presented a proposal to allow RPC definitions in lists. I believe this is an important and needed feature for a big part of the NETCONF/NETMOD community and something that will not disturb others who don't want to use it. My presentation can be found at: http://www3.ietf.org/proceedings/08jul/slides/netmod-4.ppt Due to the shortage of time there was no debate about the proposal. But now please voice your opinion - is this a good idea (of course it is)? - which encoding would you prefer (slides 7 and 8)? - is this needed for notifications as well? - if you don't need it can you at least live with it, if not why not? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 09:01:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E263A6973; Fri, 8 Aug 2008 09:01:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA733A6B4D for ; Fri, 8 Aug 2008 09:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bGJGJaRntYe for ; Fri, 8 Aug 2008 09:01:06 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id E554B3A691F for ; Fri, 8 Aug 2008 09:01:06 -0700 (PDT) Received: (qmail 87462 invoked from network); 8 Aug 2008 16:01:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 16:01:05 -0000 X-YMail-OSG: hEDBcV8VM1krJWF4h8ZFnz2W9nbWkBO.TCt1dUaiaS320MwTHU14m6c.B6ToSLGVFs41iBGcTOi8KWKaRZY45xEykFfRwxKEtlw6GQV8Pp8AxjjJWDAtwe1U3Gwbwt0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C6DC0.6010804@netconfcentral.com> Date: Fri, 08 Aug 2008 09:01:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <489C3AE6.2030709@ericsson.com> In-Reply-To: <489C3AE6.2030709@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] RPCs in Lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > In Dublin I presented a proposal to allow RPC definitions in lists. I > believe this is an important and needed feature for a big part of the > NETCONF/NETMOD community and something that will not disturb others who > don't want to use it. My presentation can be found at: > http://www3.ietf.org/proceedings/08jul/slides/netmod-4.ppt > > Due to the shortage of time there was no debate about the proposal. But > now please voice your opinion > - is this a good idea (of course it is)? > - which encoding would you prefer (slides 7 and 8)? > - is this needed for notifications as well? > - if you don't need it can you at least live with it, if not why not? > You brought up this 'exec' and 'callingPoint' idea before. I'm unclear on what problem needs to be solved here. "Need to make YANG seem more OO-like" is not an actual NETCONF problem. The input parameters to an RPC method can handle any data that needs to be conveyed. I don't see how placing an RPC (or notification) inside the database helps convey any info that could not just be passed as a parameter, if this 'callingPoint' is really important. Right now we have config true/false to determine if any nested data can be written. This would no longer be good enough because an RPC method is not config data. Would the RPCs and notifications show up in a or like normal data? Does it make any sense whatsoever to reuse these constructs within a grouping? Do they affect NV-storage at all? (no) I prefer to keep the configuration database separate from the other NETCONF protocol support. I prefer to use a new conformance statement to declare what must be implemented, with the RPC or notification tagged as part of a 'feature'. This makes it clear which config data is associated with which RPC or notification, regardless of module location. > Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 09:23:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC5E3A68CF; Fri, 8 Aug 2008 09:23:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9835A3A6AD9 for ; Fri, 8 Aug 2008 09:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3McWE1WhJ3Oz for ; Fri, 8 Aug 2008 09:23:42 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 76FF93A68CF for ; Fri, 8 Aug 2008 09:23:42 -0700 (PDT) Received: (qmail 71503 invoked from network); 8 Aug 2008 16:17:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 16:17:02 -0000 X-YMail-OSG: olfLywsVM1lAX5K7yzot0ue.WFDBJ1kHdQ7mu4d4R2QSeLgjVQ1gB_u0oapzmnn5.JIklLWVIns5SaQurmpnqHQyboKFjfk6hL.GO1wO4Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C717C.70906@netconfcentral.com> Date: Fri, 08 Aug 2008 09:17:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Leif Johansson References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> <200808081027.58888.leifj@it.su.se> In-Reply-To: <200808081027.58888.leifj@it.su.se> Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] XML element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Leif Johansson wrote: > On Thursday 07 August 2008 23:18:56 Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, > > Sorry for cross-posting this but this is probably critically important > for netmod wg too... > >>> Is the NETCONF agent allowed to accept XML elements >>> out of the specified order? >> Do you mean inside the protocol or inside the data? >> > > I think this question may be related to the question I asked at the > mic in Dublin about the uniqueness of representation of a yang > model in xml form. A necessary (but probably not sufficient) > requirement that since yang lists are order-preserving the > corresponging xml representation needs to be order-preserving > too. > > It is absolutely critical for yang that there is a *unique* mapping > between yang and xml since yang uses xpath. > I am talking about XML elements within NETCONF PDUs on the wire. There are a few corner-cases in the YANG mapping (leaf-list, ordered-by user, keys) in which relative order among a sibling node set is significant. I don't see what XPath has to do with it. As long as the agent maintains the same conceptual XML instance document for a database, XPath will always work the same on that agent. XPath in NETCONF only applies to this database, not the PDUs. > Cheers Leif Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 10:10:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139FD3A6A9C; Fri, 8 Aug 2008 10:10:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D140F3A6919 for ; Fri, 8 Aug 2008 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtZdD+tTKh9N for ; Fri, 8 Aug 2008 10:10:24 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 9A5BF3A6BCF for ; Fri, 8 Aug 2008 10:10:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 10:10:18 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:10:12 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:10:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:10:11 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78HAAu57779; Fri, 8 Aug 2008 10:10:10 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78H6tSW080555; Fri, 8 Aug 2008 17:06:55 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081706.m78H6tSW080555@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1218036899.6297.121.camel@missotis> Date: Fri, 08 Aug 2008 13:06:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 17:10:11.0456 (UTC) FILETIME=[9DD77000:01C8F979] Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >If the consensus is that the "general when" is not needed, I wouldn't >mind if it stays under augment, but also under uses. One particular use case is making enumeration values conditional, something augment can't do (currently). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 11:10:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF58F28C129; Fri, 8 Aug 2008 11:10:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5649A28C11B for ; Fri, 8 Aug 2008 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9h7siT+5ziN for ; Fri, 8 Aug 2008 11:10:38 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id AF18E28C105 for ; Fri, 8 Aug 2008 11:10:38 -0700 (PDT) Received: (qmail 96270 invoked from network); 8 Aug 2008 18:10:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 18:10:37 -0000 X-YMail-OSG: s7A4n1UVM1kfLpv_OHet7bUP7GgzWAeG2LSpyPw7mtjIN4_RAoF6fbqTDwgMKTGW71PgG6F2pA41qpPgyqe9pzguytv8WhPj3_GREEp6ow-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C8C1B.6090301@netconfcentral.com> Date: Fri, 08 Aug 2008 11:10:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808081706.m78H6tSW080555@idle.juniper.net> In-Reply-To: <200808081706.m78H6tSW080555@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> If the consensus is that the "general when" is not needed, I wouldn't >> mind if it stays under augment, but also under uses. > > One particular use case is making enumeration values conditional, > something augment can't do (currently). > This could be done with the 'if-feature' mechanism within the enum as well. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 11:12:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB513A68BD; Fri, 8 Aug 2008 11:12:34 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CB328C125 for ; Fri, 8 Aug 2008 11:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJwoLK71drI9 for ; Fri, 8 Aug 2008 11:12:32 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 5E59528C120 for ; Fri, 8 Aug 2008 11:12:32 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 11:12:24 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:01:38 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:01:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:01:37 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78I1Vu74877; Fri, 8 Aug 2008 11:01:31 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78HwFCC080979; Fri, 8 Aug 2008 17:58:16 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081758.m78HwFCC080979@idle.juniper.net> To: Balazs Lengyel In-reply-to: <489C3AE6.2030709@ericsson.com> Date: Fri, 08 Aug 2008 13:58:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 18:01:37.0943 (UTC) FILETIME=[CD87FA70:01C8F980] Cc: NETMOD Working Group Subject: Re: [netmod] RPCs in Lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >http://www3.ietf.org/proceedings/08jul/slides/netmod-4.ppt >- is this a good idea (of course it is)? I dislike this idea for two big reasons: (a) it only handles trivial cases (b) it defines "similar procedures" using completely distinct RPCs Details: (a): This technique only works for _one_ argument. If I want to shutdown an interface, great. But if I want to give a second argument that's the name of a user, I'm stuck. I only get one "calling point", which may work for simple cases, but add something outside your containment tree and it stops working. (b) You've defined a shutdown RPC, but you need to define it again for every object that you want it to work for. You end up with fifteen "shutdown" functions that _might_ looks similar, but that's not enough. Your sales point was "Often the same management action is relevant for different managed entities" but you've ended up with different mechanisms for doing the same thing. Your commonality is lost. >- which encoding would you prefer (slides 7 and 8)? Consider your encoding: immediate This could easily be: /mib-2/interface[ifId=3] immediate (which avoids annoying attribute namespace issues) But this suddenly looks just like a normal RPC. If you had: rpc shutdown { choice target { // placeholder } leaf mode { ... } } then your module can augment this RPC as needed. You can define this augmentation in your module using normal YANG-fu: augment /rpc/shutdown/target { leaf interface { type instance-identifier { ... } } } And you end up with the XML encoding of: /what/ever sure If you want to define this content along side the definition for the "interface" node, we can relax the rule about "no absolute argument paths except for top level". Using the technique of augmenting choices provides a set of consistent RPCs (only one shutdown, not one per "action"). It scales to include any number of arguments. The encoding is simpler and more consistent. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 11:18:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947E828C143; Fri, 8 Aug 2008 11:18:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088FE28C114; Fri, 8 Aug 2008 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIORJsm7sj2y; Fri, 8 Aug 2008 11:18:47 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3DD803A68E7; Fri, 8 Aug 2008 11:18:47 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 11:17:40 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:18:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:18:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78IIiu80065; Fri, 8 Aug 2008 11:18:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78IFSAR081219; Fri, 8 Aug 2008 18:15:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081815.m78IFSAR081219@idle.juniper.net> To: Andy Bierman In-reply-to: <489C1686.8000607@netconfcentral.com> Date: Fri, 08 Aug 2008 14:15:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 18:18:45.0450 (UTC) FILETIME=[31F91AA0:01C8F983] Cc: David B Harrington , netconf mailing list , netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >http://tools.ietf.org/html/draft-bierman-ncx-ext-00 Two comments: (a) with-defaults shouldn't be an attribute on . It should be an element on the appropriate RPCs (get-config). (b) Having a mechanism to learn default values is fine, but since defaults will increase the size of configurations by several orders of magnitude, making this the base behavior is a Very Bad Idea. It should be an option. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 11:26:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4023A6931; Fri, 8 Aug 2008 11:26:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1503A68EB; Fri, 8 Aug 2008 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3D0ZlT-Gt9o; Fri, 8 Aug 2008 11:26:47 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id C2AC03A6892; Fri, 8 Aug 2008 11:26:45 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 11:26:33 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:26:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:26:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:26:44 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78IQhu82655; Fri, 8 Aug 2008 11:26:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78INR6r081269; Fri, 8 Aug 2008 18:23:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081823.m78INR6r081269@idle.juniper.net> To: Leif Johansson In-reply-to: <200808081027.58888.leifj@it.su.se> Date: Fri, 08 Aug 2008 14:23:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 18:26:44.0141 (UTC) FILETIME=[4F4B8DD0:01C8F984] Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] XML element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Leif Johansson writes: >I think this question may be related to the question I asked at the >mic in Dublin about the uniqueness of representation of a yang >model in xml form. A necessary (but probably not sufficient) >requirement that since yang lists are order-preserving the >corresponging xml representation needs to be order-preserving >too. > >It is absolutely critical for yang that there is a *unique* mapping >between yang and xml since yang uses xpath. XML encoding should be predictable and consistent, but need for "uniqueness" implies a level of exactness that XML is meant to be the solution for. If you define two leafs in a container, your program (and certainly any XPath expressions you write) should not can which order those elements arrive in, _unless_ that order carries some semantic information. rpc ping { input { leaf size { ... } leaf count { ... } leaf wait { ... } } } There is no semantic difference between: 1024 10 5 and: 10 1024 5 or: 1010245 Order and whitespace differences only matter when they matter, and shouldn't become CLRs any other time. The XPath expression "ping/count" finds the count no matter the order. Assuming that "ping/*[position() = 1]" is the count will give you fragile code. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 12:09:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3EE3A635F; Fri, 8 Aug 2008 12:09:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3893A681A for ; Fri, 8 Aug 2008 12:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVzu-d4ETGcl for ; Fri, 8 Aug 2008 12:09:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3D3663A635F for ; Fri, 8 Aug 2008 12:09:51 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 44A1DD80098 for ; Fri, 8 Aug 2008 21:09:51 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200808081823.m78INR6r081269@idle.juniper.net> References: <200808081823.m78INR6r081269@idle.juniper.net> Organization: CESNET Date: Fri, 08 Aug 2008 21:09:52 +0200 Message-Id: <1218222592.6827.91.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] [Netconf] XML element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgUMOhIDA4LiAwOC4gMjAwOCB2IDE0OjIzIC0wNDAwOgo+IFhN TCBlbmNvZGluZyBzaG91bGQgYmUgcHJlZGljdGFibGUgYW5kIGNvbnNpc3RlbnQsIGJ1dCBuZWVk IGZvcgo+ICJ1bmlxdWVuZXNzIiBpbXBsaWVzIGEgbGV2ZWwgb2YgZXhhY3RuZXNzIHRoYXQgWE1M IGlzIG1lYW50IHRvIGJlCj4gdGhlIHNvbHV0aW9uIGZvci4gIElmIHlvdSBkZWZpbmUgdHdvIGxl YWZzIGluIGEgY29udGFpbmVyLCB5b3VyCj4gcHJvZ3JhbSAoYW5kIGNlcnRhaW5seSBhbnkgWFBh dGggZXhwcmVzc2lvbnMgeW91IHdyaXRlKSBzaG91bGQgbm90Cj4gY2FuIHdoaWNoIG9yZGVyIHRo b3NlIGVsZW1lbnRzIGFycml2ZSBpbiwgX3VubGVzc18gdGhhdCBvcmRlciBjYXJyaWVzCj4gc29t ZSBzZW1hbnRpYyBpbmZvcm1hdGlvbi4KCisxLiBIb3dldmVyLCBZQU5HIGRyYWZ0IHNheXM6Cgoi VGhlIGNvbnRhaW5lcidzIGNoaWxkIG5vZGVzIGFyZSBlbmNvZGVkIGFzIHN1YmVsZW1lbnRzIHRv IHRoZSBjb250YWluZXIKZWxlbWVudCwgaW4gdGhlIHNhbWUgb3JkZXIgYXMgdGhleSBhcmUgZGVm aW5lZCB3aXRoaW4gdGhlIGNvbnRhaW5lcgpzdGF0ZW1lbnQuIgoKV2lsbCB0aGlzIGJlIGNoYW5n ZWQ/CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThD MEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1v ZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri Aug 8 12:42:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E28C3A692A; Fri, 8 Aug 2008 12:42:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E254D3A69A8 for ; Fri, 8 Aug 2008 12:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyWhk9IWhlGI for ; Fri, 8 Aug 2008 12:42:33 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3ECDA3A692A for ; Fri, 8 Aug 2008 12:42:29 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 12:41:32 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:41:54 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:41:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:36:02 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78JZwu07538; Fri, 8 Aug 2008 12:35:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78JWhKY081788; Fri, 8 Aug 2008 19:32:43 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081932.m78JWhKY081788@idle.juniper.net> To: Andy Bierman In-reply-to: <489B5ABF.50102@netconfcentral.com> Date: Fri, 08 Aug 2008 15:32:42 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 19:36:02.0698 (UTC) FILETIME=[FDFCFEA0:01C8F98D] Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >It the leaf exists in the system, because mandatory is false >and there is a default value to apply, then it is part >of the configuration database. This seems to be your opinion, but not one shared by many on the device side of the world. The device view is either: (a) Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. or: (b) Configuration data is the set of writable data that the users have specified to transform a system from its initial default state into its current state. Most devices take one or the other view. Few take the "all defaults, all the time" view, since it leads to big configs filled with uninterested data. By limiting the config to what's required or what the user said, the config is kept to a reasonable size and the content is (by definition) the bits that the user cares about. Operators care about config content and about config sizes. They look at config, they archive config, they diff config, they love config. It's the instructions they give the the device to tell it what to do. This is a reach, let's try a non-router example. Consider the contents of /etc/rc.conf on a unix box. This file contains a set of shell variables used by shell scripts like /etc/rc to trigger boot-time box behavior. For example: defaultrouter="10.0.0.1 hostname="idle.juniper.net" ifconfig_fxp0="inet 10.0.0.2 netmask 255.255.255.0" kern_securelevel_enable="NO" linux_enable="YES" lpd_enable="YES" sendmail_enable="YES" sshd_enable="YES" usbd_enable="YES" firewall_type="open" nfs_server_enable="YES" Software packages may define one or more shell variables to control their base action. Most define a "XXX_enable" variable to trigger their initial start, but the variables and their meaning differ. So in this world, the contents of /etc/rc.conf are my config database, and no defaults appear. If you add "ntp_enable=NO" (the default), it doesn't change anything. If sysinstall reads your setting and rewrites them, it might not re-record this interesting setting. The operation of your box is unaffected. But it won't ever write the hundreds of variables that you don't care about and never set, even though they will also not affect the operation of your box. The places you'll see this "flushed-with-defaults" behavior is where the user is not expected to look at the config or to interact with it. I don't see our problem domain as suitable for this style. >RFC 4741 clearly states that a get-config (and also get) without >any filter returns the entire configuration database. Nowhere in >the text on filtering does it mention any consideration >of the default value as part of the filtering process. >That means it is NOT part of the filtering process. >I do not agree at all that agent MAY leave these nodes out, >if they claim conformance to RFC 4741. I disagree with this line of thought. My implementation returns the entire configuration database, unfiltered. Default values are not part of my configuration database. Your plank is "default values must appear in the configuration database". I strongly disagree. This isn't the way my part of the world works and is not present on my reading of NETCONF. NETCONF leaves content up to the data model. YANG-based data model certainly don't have this "flushed-with-defaults" point of view. I think you'll have an uphill battle pushing for this. An optional element would be fine, but I don't see changing YANG to add this plank. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 12:42:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7324E3A6846; Fri, 8 Aug 2008 12:42:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF033A692A for ; Fri, 8 Aug 2008 12:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRR3LqsNGrO3 for ; Fri, 8 Aug 2008 12:42:45 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id A30A43A6774 for ; Fri, 8 Aug 2008 12:42:27 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 12:41:32 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:41:34 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:41:33 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:39:44 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78Jdhu08460; Fri, 8 Aug 2008 12:39:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78JaSno081984; Fri, 8 Aug 2008 19:36:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081936.m78JaSno081984@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1218222592.6827.91.camel@missotis> Date: Fri, 08 Aug 2008 15:36:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 19:39:44.0356 (UTC) FILETIME=[821B5240:01C8F98E] Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] XML element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >+1. However, YANG draft says: > >"The container's child nodes are encoded as subelements to the container >element, in the same order as they are defined within the container >statement." > >Will this be changed? IMHO yes. The only restriction should be that keys appear before non-keys. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 12:42:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8610E3A6A37; Fri, 8 Aug 2008 12:42:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960B33A6774 for ; Fri, 8 Aug 2008 12:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNcHqcmjLRhm for ; Fri, 8 Aug 2008 12:42:45 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 722A03A6969 for ; Fri, 8 Aug 2008 12:42:32 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 12:41:49 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:41:54 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:41:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:41:16 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78JfFu09135; Fri, 8 Aug 2008 12:41:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78JbxQ9082009; Fri, 8 Aug 2008 19:38:00 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081938.m78JbxQ9082009@idle.juniper.net> To: Andy Bierman In-reply-to: <489C8C1B.6090301@netconfcentral.com> Date: Fri, 08 Aug 2008 15:37:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 19:41:16.0419 (UTC) FILETIME=[B8FB0530:01C8F98E] Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >This could be done with the 'if-feature' mechanism within >the enum as well. feature space is flat and requires specific advertisement on the feature. when's argument can supply logic detailing when the enumeration is valid ('when "../mtu > 1500"'). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 12:50:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABB43A6846; Fri, 8 Aug 2008 12:50:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7BF3A6846 for ; Fri, 8 Aug 2008 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p81bcjWdDFQZ for ; Fri, 8 Aug 2008 12:49:59 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id E58593A69D9 for ; Fri, 8 Aug 2008 12:49:56 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 12:49:26 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:49:32 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:49:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:49:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78Jmmu11549; Fri, 8 Aug 2008 12:48:48 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78JjWL7082067; Fri, 8 Aug 2008 19:45:32 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081945.m78JjWL7082067@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1218001487.6297.4.camel@missotis> Date: Fri, 08 Aug 2008 15:45:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 19:49:01.0782 (UTC) FILETIME=[CE5BC760:01C8F98F] Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >> path "../../interface[name = $this/../ifname]/address/ip"; > path "../../interface[name = current()/../ifname]/address/ip"; You're absolutely right. $this and current() are identical. We should mimic this XSLT function instead of rolling our own. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 12:50:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD093A69D9; Fri, 8 Aug 2008 12:50:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246FC3A6846 for ; Fri, 8 Aug 2008 12:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxNX3j53COpr for ; Fri, 8 Aug 2008 12:50:41 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 953783A69D9 for ; Fri, 8 Aug 2008 12:50:38 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 12:50:39 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:49:49 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:49:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:49:47 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78Jnhu11835; Fri, 8 Aug 2008 12:49:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78JkRq8082083; Fri, 8 Aug 2008 19:46:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081946.m78JkRq8082083@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080804.225214.265720698.mbj@tail-f.com> Date: Fri, 08 Aug 2008 15:46:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 19:49:47.0501 (UTC) FILETIME=[E99BF1D0:01C8F98F] Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Maybe we should reword our spec and say "Elements without a namespace >refer to nodes in the current module.". This sounds like a fine solution to me. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 12:55:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B8D3A6AC9; Fri, 8 Aug 2008 12:55:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5083A6CFA for ; Fri, 8 Aug 2008 12:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVUQ9yFy3cjQ for ; Fri, 8 Aug 2008 12:55:13 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C32C03A6AC9 for ; Fri, 8 Aug 2008 12:55:11 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 12:54:49 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:54:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 12:54:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:54:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m78Jsju13487; Fri, 8 Aug 2008 12:54:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78JpTLN082144; Fri, 8 Aug 2008 19:51:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081951.m78JpTLN082144@idle.juniper.net> To: "Lahdensivu, Mikko (NSN - FI/Tampere)" In-reply-to: <210412A63D60154898B7CDC3C7172BDE31269D@FIESEXC007.nsn-intra.net> Date: Fri, 08 Aug 2008 15:51:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 19:54:45.0862 (UTC) FILETIME=[9B723860:01C8F990] Cc: NETMOD Working Group Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Lahdensivu, Mikko (NSN - FI/Tampere)" writes: >I would consider that if you change the sub-language (xpath) trying to >optimize it for the main language (yang), you are requesting people to >actually adapt more to the language, than if you would do by keeping the >sub-language as it is. XPath expressions are always evaluated in a context which is defined by the environment. For example in XSLT, the binding of prefixes to namespaces is defined by the nesting of the XSLT document. The context has the prefix binding if one of the parent elements contains the xmlns attribute to bind it. A developer writing an XSLT script is aware of those rules. The YANG scenario is identical. We define rules about how the context is built, the developer knows those rules, and everyone is happy. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 13:08:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DBE3A6AC0; Fri, 8 Aug 2008 13:08:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C6F3A6CD0 for ; Fri, 8 Aug 2008 13:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cfena185kOr1 for ; Fri, 8 Aug 2008 13:08:03 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 7A3053A6D33 for ; Fri, 8 Aug 2008 13:06:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EQlWaSN1nWCyFBdvALY6z2hCm3ZHsz7BfhO/ly6v1IUolyykIqjnAECBhx59aKBR; 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.28.63] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KRYEZ-0001pd-KP for netmod@ietf.org; Fri, 08 Aug 2008 16:06:47 -0400 Message-ID: <000e01c8f992$69ef6fe0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200808081932.m78JWhKY081788@idle.juniper.net> Date: Fri, 8 Aug 2008 13:07:40 -0700 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3b097a258e13afe0cd5e1717c58609c53350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.28.63 Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: ; > Sent: Friday, August 08, 2008 12:32 PM > Subject: Re: [netmod] leaf encoding rules ... > This seems to be your opinion, but not one shared by many on > the device side of the world. The device view is either: > > (a) Configuration data is the set of writable data that is > required to transform a system from its initial default state > into its current state. > > or: > > (b) Configuration data is the set of writable data that the users > have specified to transform a system from its initial default > state into its current state. I think there are two problems with both of these formulations - the formulation in terms of "initial default state" and the formulation in terms of "current state." A third formulation might be closer to a more classical view of what constitutes configuration management: (c) Configuration data is the set of writable data required to transform a system from any possible state into a (fully-specified) desired state. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 13:24:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A403A69B9; Fri, 8 Aug 2008 13:24:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE903A69F5 for ; Fri, 8 Aug 2008 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7UToT0alGBm for ; Fri, 8 Aug 2008 13:24:47 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id E20083A69B9 for ; Fri, 8 Aug 2008 13:24:47 -0700 (PDT) Received: (qmail 23160 invoked from network); 8 Aug 2008 20:24:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 20:24:46 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489CAB8C.4050008@andybierman.com> Date: Fri, 08 Aug 2008 13:24:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808081932.m78JWhKY081788@idle.juniper.net> In-Reply-To: <200808081932.m78JWhKY081788@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> It the leaf exists in the system, because mandatory is false >> and there is a default value to apply, then it is part >> of the configuration database. > > This seems to be your opinion, but not one shared by many on > the device side of the world. The device view is either: > The *nix .conf file and CLI models you cite are extremely flawed for standards-based configuration. Problems with tracking down documentation, discovering default behavior changes through new bugs, and little or no consistency are well understood. For YANG leafs without any default defined, there is also no other way to find out what the agent is expected to do. In order for standards-based configuration to actually work, all nodes that are affecting system behavior need to be accessible to the operator. These defaults are not always needed, but sometimes they are. For example, when bench-testing a new SW version or new platform, it is useful to know ahead of time if the the agent has changed any of the defaults. Usually the default change is OK, but some operators want to know, not just hope. In many of the unix .conf files I use, they are stuffed with comments, showing all the knobs set to their default values. This is an obvious attempt to deal with the problem of changing defaults and operators' need to know what all the knob settings really are. Andy > (a) Configuration data is the set of writable data that is > required to transform a system from its initial default state > into its current state. > > or: > > (b) Configuration data is the set of writable data that the users > have specified to transform a system from its initial default > state into its current state. > > Most devices take one or the other view. Few take the "all defaults, > all the time" view, since it leads to big configs filled with uninterested > data. By limiting the config to what's required or what the user said, > the config is kept to a reasonable size and the content is (by definition) > the bits that the user cares about. > > Operators care about config content and about config sizes. They > look at config, they archive config, they diff config, they love > config. It's the instructions they give the the device to tell it > what to do. > > This is a reach, let's try a non-router example. Consider the > contents of /etc/rc.conf on a unix box. This file contains a set > of shell variables used by shell scripts like /etc/rc to trigger > boot-time box behavior. For example: > > defaultrouter="10.0.0.1 > hostname="idle.juniper.net" > ifconfig_fxp0="inet 10.0.0.2 netmask 255.255.255.0" > kern_securelevel_enable="NO" > linux_enable="YES" > lpd_enable="YES" > sendmail_enable="YES" > sshd_enable="YES" > usbd_enable="YES" > firewall_type="open" > nfs_server_enable="YES" > > Software packages may define one or more shell variables to control > their base action. Most define a "XXX_enable" variable to trigger > their initial start, but the variables and their meaning differ. > > So in this world, the contents of /etc/rc.conf are my config database, > and no defaults appear. If you add "ntp_enable=NO" (the default), > it doesn't change anything. If sysinstall reads your setting and > rewrites them, it might not re-record this interesting setting. > The operation of your box is unaffected. But it won't ever write > the hundreds of variables that you don't care about and never set, > even though they will also not affect the operation of your box. > > The places you'll see this "flushed-with-defaults" behavior is where > the user is not expected to look at the config or to interact with > it. I don't see our problem domain as suitable for this style. > >> RFC 4741 clearly states that a get-config (and also get) without >> any filter returns the entire configuration database. Nowhere in >> the text on filtering does it mention any consideration >> of the default value as part of the filtering process. >> That means it is NOT part of the filtering process. >> I do not agree at all that agent MAY leave these nodes out, >> if they claim conformance to RFC 4741. > > I disagree with this line of thought. My implementation returns > the entire configuration database, unfiltered. Default values are > not part of my configuration database. > > Your plank is "default values must appear in the configuration > database". I strongly disagree. This isn't the way my part of the > world works and is not present on my reading of NETCONF. NETCONF > leaves content up to the data model. YANG-based data model certainly > don't have this "flushed-with-defaults" point of view. I think you'll > have an uphill battle pushing for this. An optional > element would be fine, but I don't see changing YANG to add this plank. > > Thanks, > Phil > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 13:25:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869273A6C13; Fri, 8 Aug 2008 13:25:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD763A6CD0 for ; Fri, 8 Aug 2008 13:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqSlKMH5pxrB for ; Fri, 8 Aug 2008 13:25:24 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B72EC3A6CC2 for ; Fri, 8 Aug 2008 13:25:24 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id F2BC676C4CC; Fri, 8 Aug 2008 22:25:23 +0200 (CEST) Date: Fri, 08 Aug 2008 22:25:23 +0200 (CEST) Message-Id: <20080808.222523.22583218.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: [netmod] empty choice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The following example reminds me of a detail with choice: Phil Shafer wrote: > But this suddenly looks just like a normal RPC. If you had: > > rpc shutdown { > choice target { > // placeholder > } > leaf mode { > ... > } > } > > then your module can augment this RPC as needed. Currently, we have a CLR which says that there must be at least one case in a choice. Thus, the example above is not legal YANG. Instead, you have to do: rpc shutdown { choice target { case dummy { description "Must not be instatiated."; leaf dummy { type string; } } } ... } I would like to remove the current rule and allow an empty choice. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 13:36:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9273A69A1; Fri, 8 Aug 2008 13:36:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6703A6969 for ; Fri, 8 Aug 2008 13:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9puT--lZWSHJ for ; Fri, 8 Aug 2008 13:36:50 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 0422B3A6951 for ; Fri, 8 Aug 2008 13:36:50 -0700 (PDT) Received: (qmail 96084 invoked from network); 8 Aug 2008 20:36:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 20:36:48 -0000 X-YMail-OSG: ZHGdnlQVM1niLzFXpcd8YksG28e871Jgxw6XskmlyqsiXZapkF8JWPINtcp2q0cpXm9rAQ3CLZmCos.05L5L6D_b7qnZDR9WxbKBq903QQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489CAE5E.8030206@netconfcentral.com> Date: Fri, 08 Aug 2008 13:36:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080808.222523.22583218.mbj@tail-f.com> In-Reply-To: <20080808.222523.22583218.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] empty choice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > The following example reminds me of a detail with choice: > > Phil Shafer wrote: >> But this suddenly looks just like a normal RPC. If you had: >> >> rpc shutdown { >> choice target { >> // placeholder >> } >> leaf mode { >> ... >> } >> } >> >> then your module can augment this RPC as needed. > > Currently, we have a CLR which says that there must be at least one > case in a choice. Thus, the example above is not legal YANG. > Instead, you have to do: > > rpc shutdown { > choice target { > case dummy { > description "Must not be instatiated."; > leaf dummy { type string; } > } > } > ... > } > > > I would like to remove the current rule and allow an empty choice. > I do not mind the change, but this seems strange to me. By itself, inline, this RPC method is nonsense. Unless it gets augmented externally, there is no target. How does the inline RPC description clause document the parameters? Just add enough examples so readers understand what to do. I prefer function calls where the parameters are more stable. I would probably use an XPath target if I wanted a generic shutdown-object function. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 15:06:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2EE3A683A; Fri, 8 Aug 2008 15:06:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8453A683A for ; Fri, 8 Aug 2008 15:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6YGhA56D6DK for ; Fri, 8 Aug 2008 15:06:49 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 974CE3A6B45 for ; Fri, 8 Aug 2008 15:06:49 -0700 (PDT) Received: (qmail 25760 invoked from network); 8 Aug 2008 22:06:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 22:06:48 -0000 X-YMail-OSG: ehm04jgVM1kAXG5Tnp_0IxhUeNKSxWyjXx77e5dWCLtyZ1gIG_MfvbzcHbQ2FGpJhSHrrGaD16qFoa3M46DrvK7ZbrfbZKMAeH_xRWg5GC0Ivc0X80CQmOrAeqimIdI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489CC376.9060509@netconfcentral.com> Date: Fri, 08 Aug 2008 15:06:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808081815.m78IFSAR081219@idle.juniper.net> In-Reply-To: <200808081815.m78IFSAR081219@idle.juniper.net> Cc: David B Harrington , netconf mailing list , netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> http://tools.ietf.org/html/draft-bierman-ncx-ext-00 > > Two comments: > (a) with-defaults shouldn't be an attribute on . It should be > an element on the appropriate RPCs (get-config). IMO, it is easier and more consistent to use the XML attribute mechanism already defined for the element. The same mechanism works for all standard and vendor RPC methods. > (b) Having a mechanism to learn default values is fine, but since > defaults will increase the size of configurations by several orders > of magnitude, making this the base behavior is a Very Bad Idea. It > should be an option. agreed. A read-only leaf in the netconf-state spec is fine. But if you support the (separate) 'with-defaults' capability, then you must return these default leafs when 'with-defaults' is set to true. It is OK to make this a marketing decision, similar to retrieving all the YANG, XSD, or RNG files directly from the agent. IMO, NE devices will continue to get smarter, and 1 way to do that is to help the operator quickly get out of a jam with instant, context-sensitive documentation. > > Thanks, > Phil > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 8 15:18:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C083A6847; Fri, 8 Aug 2008 15:18:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F7D3A6A2D for ; Fri, 8 Aug 2008 15:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-yOEmuhv7fk for ; Fri, 8 Aug 2008 15:18:14 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 1E2323A69C4 for ; Fri, 8 Aug 2008 15:18:14 -0700 (PDT) Received: (qmail 33679 invoked from network); 8 Aug 2008 22:18:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 22:18:12 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489CC623.3010104@netconfcentral.com> Date: Fri, 08 Aug 2008 15:18:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808081936.m78JaSno081984@idle.juniper.net> In-Reply-To: <200808081936.m78JaSno081984@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] XML element order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> +1. However, YANG draft says: >> >> "The container's child nodes are encoded as subelements to the container >> element, in the same order as they are defined within the container >> statement." >> >> Will this be changed? > > IMHO yes. The only restriction should be that keys appear > before non-keys. > To be more precise: A manager SHOULD send all XML elements in the specified order. A manager MUST send the following items in the specified order: - list key leafs - ordered-by user (list, leaf-list) - anyxml An agent MAY issue the (TBD) error-tag when it detects elements in the wrong error. I do not want to force agents to issue errors for non-problems. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 09:16:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A42F28C12C; Sat, 9 Aug 2008 09:16:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD5828C13E for ; Sat, 9 Aug 2008 09:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TmA7rl94Uyj for ; Sat, 9 Aug 2008 09:16:26 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 417E928C139 for ; Sat, 9 Aug 2008 09:16:26 -0700 (PDT) Received: (qmail 31022 invoked from network); 9 Aug 2008 16:16:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2008 16:16:25 -0000 X-YMail-OSG: 5bU2bicVM1muWgfGUVzBFaGzUAXuLrxyxdL7z0uIn31sAgfeAeOd9GAIGbOOt_QaF4QZ6FTDV84srTyn2QXUDfo8iHz34MbI7SQQTBbusw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489DC2D7.4040501@netconfcentral.com> Date: Sat, 09 Aug 2008 09:16:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] must-stmt in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, From 4.2.8: Here is the example on pg 23: augment system/login/user { when "class != 'wheel'"; leaf uid { type uint16 { range "1000 .. 30000"; } } } What if this augment were in a grouping (because it's legal)? module foo { ... grouping foo { augment /system/login/user { when "class != 'wheel'"; leaf uid { type uint16 { range "1000 .. 30000"; } } } } } module bar { ... uses foo:foo; } 1) The no-prefix == local module rule breaks the augment Xpath target, since the local prefix in the grouping module is different for a uses-stmt in another module. 2) If the augment had a global target (/nm:system/nm:login/nm:user) which is allowed in a top-level grouping, expanded to a top-level uses, then even if all the prefixes are entered, they are relative to the grouping module (foo), not the uses module (bar). It's broken with or without prefixes. 3) The 'when' target Xpath expression is specified with prefixes from the grouping module, but there is no point evaluating this expression in the grouping, since the node position that matters is relative to the 'uses' statement in a different module. 4) If the 'when' Xpath expression has any QNames in it, then they will be evaluated with the wrong prefixes if the 'uses' is in a different module. 3 fatal flaws, 1 non-intuitive warning. Back to the drawing board. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 09:43:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB733A6831; Sat, 9 Aug 2008 09:43:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC233A6C3F for ; Sat, 9 Aug 2008 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmDT7acT0TlS for ; Sat, 9 Aug 2008 09:43:30 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 177003A69E3 for ; Sat, 9 Aug 2008 09:43:30 -0700 (PDT) Received: (qmail 92900 invoked from network); 9 Aug 2008 16:43:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2008 16:43:29 -0000 X-YMail-OSG: I3dJgekVM1lgr4dWiZ1jyToiWEs6C1XLWjyRoKNymFISV4HMPJ0R3JC6DPBvkN4oage.aOyDGrOjtARzlmYCVvY.KGytvCy55OPgCNvFCQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489DC930.7090103@netconfcentral.com> Date: Sat, 09 Aug 2008 09:43:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group References: <489DC2D7.4040501@netconfcentral.com> In-Reply-To: <489DC2D7.4040501@netconfcentral.com> Subject: Re: [netmod] must-stmt in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, > 3 fatal flaws, 1 non-intuitive warning. > Back to the drawing board. > 1 solution (for those playing along in the Home Edition ;-) is to make top-level augments a separate statement, like augment-external, and make it a body-stmt instead of a data-def-stmt. The 'when' clause is still a problem though. > > Andy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 10:39:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DEFB3A69A2; Sat, 9 Aug 2008 10:39:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99363A69B5 for ; Sat, 9 Aug 2008 10:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k476k7pXHjxx for ; Sat, 9 Aug 2008 10:39:37 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 48ABE3A69A2 for ; Sat, 9 Aug 2008 10:39:37 -0700 (PDT) Received: (qmail 30575 invoked from network); 9 Aug 2008 17:39:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2008 17:39:36 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489DD656.3090909@netconfcentral.com> Date: Sat, 09 Aug 2008 10:39:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] leaf-list and Xpath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, IMO the leaf-list is an odd data structure, and it does not really fit in with all the others. This is especially noticeable when considering Xpath filtering and validation. All the other data types can be associated with a single XML sub-tree. The 'list' data type is actually a 'row' data type. There is no real 'list' data type in YANG. The leaf-list is a conceptual data type representing N sequential sibling elements. You may declare a leaf-list and give it a name (/acme:foo), but in Xpath this conceptual object does not exist -- just /acme:foo[1], acme:/foo[2], etc. Good luck implementing leaf-list with off-the-shelf tools. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 12:40:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462ED3A6DE7; Sat, 9 Aug 2008 12:40:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1073A6DE7 for ; Sat, 9 Aug 2008 12:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDYLQXuPlplw for ; Sat, 9 Aug 2008 12:39:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6184A3A6DCC for ; Sat, 9 Aug 2008 12:39:59 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 6ADE076C4D0; Sat, 9 Aug 2008 21:39:35 +0200 (CEST) Date: Sat, 09 Aug 2008 21:39:31 +0200 (CEST) Message-Id: <20080809.213931.238323260.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489DC2D7.4040501@netconfcentral.com> References: <489DC2D7.4040501@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] must-stmt in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > From 4.2.8: > > > Here is the example on pg 23: > > > augment system/login/user { > when "class != 'wheel'"; > leaf uid { > type uint16 { > range "1000 .. 30000"; > } > } > } > > What if this augment were in a grouping (because it's legal)? > > > module foo { > > ... > grouping foo { > augment /system/login/user { No, this is not legal. 7.15 says If the "augment" statement is on the top-level in a module or submodule, the absolute form of a schema node identifier MAY be used. Otherwise, the descendant form MUST be used. But I agree that it might be a good idea to use two separate statements. The current 'uses' substatements have another problem, so maybe we can solve both problems. The problem is that the grammar for e.g. 'leaf' is context-dependant. When it appears within a 'uses', it cannot have a type for example. Here is one idea: uses Interface { refine interface/mtu { default 1500; } extend interface/unit { leaf my-vlan-param { ... } } } The substatements to 'uses' clearly signals what is going on - refinements and extensions to the grouping. Then the 'augment' statement would be a top-level thing only. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 13:33:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F10A3A67D4; Sat, 9 Aug 2008 13:33:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F31E3A68BC for ; Sat, 9 Aug 2008 13:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK8ZaQyFe8xl for ; Sat, 9 Aug 2008 13:33:32 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 65F823A67D4 for ; Sat, 9 Aug 2008 13:33:32 -0700 (PDT) Received: (qmail 52571 invoked from network); 9 Aug 2008 20:33:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2008 20:33:32 -0000 X-YMail-OSG: t26mhGkVM1m8BmEfWg2JugF5uSqMJGHw62YNVTgwqquLJeoChyJcg3ZNEenQxA.6uCg988vuql2lbRtSbj6NM8DIEiqvqiVuMWrvnUtt8Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489DFF1B.90409@netconfcentral.com> Date: Sat, 09 Aug 2008 13:33:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489DC2D7.4040501@netconfcentral.com> <20080809.213931.238323260.mbj@tail-f.com> In-Reply-To: <20080809.213931.238323260.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] must-stmt in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> From 4.2.8: >> >> >> Here is the example on pg 23: >> >> >> augment system/login/user { >> when "class != 'wheel'"; >> leaf uid { >> type uint16 { >> range "1000 .. 30000"; >> } >> } >> } >> >> What if this augment were in a grouping (because it's legal)? >> >> >> module foo { >> >> ... >> grouping foo { >> augment /system/login/user { > > No, this is not legal. 7.15 says > > If the > "augment" statement is on the top-level in a module or submodule, the > absolute form of a schema node identifier MAY be used. Otherwise, > the descendant form MUST be used. > This seems odd because objects within a top-level grouping and used at the top-level are visible in other modules as top level elements. There is still a problem with prefixes in must/when XPath expressions that appear within a grouping which is used in a different module. > But I agree that it might be a good idea to use two separate > statements. The current 'uses' substatements have another problem, so > maybe we can solve both problems. The problem is that the grammar for > e.g. 'leaf' is context-dependant. When it appears within a 'uses', it > cannot have a type for example. Here is one idea: > > uses Interface { > refine interface/mtu { > default 1500; > } > extend interface/unit { > leaf my-vlan-param { ... } > } > } > > The substatements to 'uses' clearly signals what is going on - > refinements and extensions to the grouping. > But this is broken because you cannot refine a local grouping this way. I like the current augments and uses design just fine because there cannot be any duplicates and it supports local groupings. It is an implementation detail to keep track of the calling context. > Then the 'augment' statement would be a top-level thing only. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 14:12:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E413A68AD; Sat, 9 Aug 2008 14:12:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA693A68C7 for ; Sat, 9 Aug 2008 14:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv2qQGBRYtzd for ; Sat, 9 Aug 2008 14:12:38 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 274D83A6816 for ; Sat, 9 Aug 2008 14:11:38 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 14:11:34 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:11:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:11:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 14:11:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m79LBCu57185; Sat, 9 Aug 2008 14:11:12 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m79L7tES088127; Sat, 9 Aug 2008 21:07:56 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808092107.m79L7tES088127@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080808.222523.22583218.mbj@tail-f.com> Date: Sat, 09 Aug 2008 17:07:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2008 21:11:13.0456 (UTC) FILETIME=[74474300:01C8FA64] Cc: netmod@ietf.org Subject: Re: [netmod] empty choice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Currently, we have a CLR which says that there must be at least one >case in a choice. Thus, the example above is not legal YANG. Yup, this was my "//placeholder". >I would like to remove the current rule and allow an empty choice. Completely agree. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 14:15:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15DF3A68BA; Sat, 9 Aug 2008 14:15:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1513A6835; Sat, 9 Aug 2008 14:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzhFFYRN1806; Sat, 9 Aug 2008 14:15:51 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id AF8B13A6816; Sat, 9 Aug 2008 14:15:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 14:15:49 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:15:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:15:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 14:15:02 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m79LF1u57869; Sat, 9 Aug 2008 14:15:01 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m79LBigd088169; Sat, 9 Aug 2008 21:11:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808092111.m79LBigd088169@idle.juniper.net> To: Andy Bierman In-reply-to: <489CC376.9060509@netconfcentral.com> Date: Sat, 09 Aug 2008 17:11:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2008 21:15:02.0833 (UTC) FILETIME=[FCFF6A10:01C8FA64] Cc: David B Harrington , netconf mailing list , netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >IMO, it is easier and more consistent to use the XML attribute >mechanism already defined for the element. The same mechanism works >for all standard and vendor RPC methods. "works" != "makes sense". with-defaults makes no sense for many RPCs. It should only be defined for those RPCs where it makes sense. Imagine if we allow this as a general concept and everyone starts stuffing all their cruft in because is "easier". Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 14:35:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A163A67B5; Sat, 9 Aug 2008 14:35:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400CB3A68E3 for ; Sat, 9 Aug 2008 14:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+eF0brdfSDu for ; Sat, 9 Aug 2008 14:35:37 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 8CE463A67B5 for ; Sat, 9 Aug 2008 14:35:36 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 14:35:35 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:34:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:34:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 14:34:39 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m79LYcu60768; Sat, 9 Aug 2008 14:34:38 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m79LVLgw088349; Sat, 9 Aug 2008 21:31:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808092131.m79LVLgw088349@idle.juniper.net> To: Andy Bierman In-reply-to: <489CAB8C.4050008@andybierman.com> Date: Sat, 09 Aug 2008 17:31:21 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2008 21:34:39.0215 (UTC) FILETIME=[BA2D0FF0:01C8FA67] Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >The *nix .conf file and CLI models you cite are extremely >flawed for standards-based configuration. "flawed"? Maybe, but definitely real world. If you are trying to model lab experiments and trivial "hello world" models, you won't hit 80% of the interesting issues that happen out in the real world. We've seen this in the sort of issues we're hitting with the WGs using YANG already. We can make claims about "flawed" but the folks doing the modeling and the device folks doing the coding need real solutions to their problems. My belief is that the closer we follow the CLI model the more likely is that YANG and NETCONF will find a place as an integral part of device implementations, rather than becoming "yet another management API" that gets glommed on after the real world is done (in the CLI). >These defaults are not always needed, but sometimes they are. I'm fine with an optional knob to get this information. But I completely disagree with your assertion that default values are part of the config database and any data model that doesn't work that way isn't compliant with NETCONF. NETCONF leaves the entire content of the to the data model, with few rules about what that content looks like, means, or how it behaves. YANG defines the rules (keys, ops, encoding, etc) that apply to YANG-based data models. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 15:03:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2039E3A697E; Sat, 9 Aug 2008 15:03:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D853A6984 for ; Sat, 9 Aug 2008 15:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+JkjglLS+vN for ; Sat, 9 Aug 2008 15:03:26 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 01A683A697E for ; Sat, 9 Aug 2008 15:03:26 -0700 (PDT) Received: (qmail 64930 invoked from network); 9 Aug 2008 22:03:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 9 Aug 2008 22:03:26 -0000 X-YMail-OSG: HJmkOsMVM1nCCbtWN5d19rPd7MVZaqniY1NUIKmU3QSLuXOEYFPIAOgca_FJLtjAJlqD2MeWEwgfAbzYrVFf3HT0Jzc.sHIXKWuPJF90SA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489E142C.9090205@netconfcentral.com> Date: Sat, 09 Aug 2008 15:03:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808092131.m79LVLgw088349@idle.juniper.net> In-Reply-To: <200808092131.m79LVLgw088349@idle.juniper.net> Cc: netmod@ietf.org, Andy Bierman Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The *nix .conf file and CLI models you cite are extremely >> flawed for standards-based configuration. > > "flawed"? Maybe, but definitely real world. If you are trying to > model lab experiments and trivial "hello world" models, you won't > hit 80% of the interesting issues that happen out in the real world. > We've seen this in the sort of issues we're hitting with the WGs > using YANG already. We can make claims about "flawed" but the folks > doing the modeling and the device folks doing the coding need real > solutions to their problems. > I am using examples like the ipfix-psamp DM. It is a tough sell to convince an SDO that access to device data in a standard way is a bad idea. Your device knows there is a leaf there, and knows what the effective value is, but chooses not to let the manager know that info as well. Memory and bandwidth are dirt cheap. Skilled labor and network downtime are not. > My belief is that the closer we follow the CLI model the more likely > is that YANG and NETCONF will find a place as an integral part of > device implementations, rather than becoming "yet another management > API" that gets glommed on after the real world is done (in the CLI). > >> These defaults are not always needed, but sometimes they are. > > I'm fine with an optional knob to get this information. But I > completely disagree with your assertion that default values are > part of the config database and any data model that doesn't work > that way isn't compliant with NETCONF. NETCONF leaves the entire > content of the to the data model, with few rules about > what that content looks like, means, or how it behaves. YANG defines > the rules (keys, ops, encoding, etc) that apply to YANG-based data > models. > I suspect your implementation keeps track internally of every leaf, and if it has a default value. Otherwise, how would you be prepared to allow edit-config on that leaf? It is a implementation detail to use this internal data to generate the default in effect for RPC requests. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 15:03:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4927E3A6995; Sat, 9 Aug 2008 15:03:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE063A6A2D for ; Sat, 9 Aug 2008 15:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOPnTvHvlBQ1 for ; Sat, 9 Aug 2008 15:03:54 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 67F973A6904 for ; Sat, 9 Aug 2008 15:03:53 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 15:03:54 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 15:03:11 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 15:03:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 15:03:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m79M3Au65980; Sat, 9 Aug 2008 15:03:10 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m79LxrtI088487; Sat, 9 Aug 2008 21:59:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808092159.m79LxrtI088487@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <000e01c8f992$69ef6fe0$6801a8c0@oemcomputer> Date: Sat, 09 Aug 2008 17:59:53 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2008 22:03:10.0742 (UTC) FILETIME=[B6535B60:01C8FA6B] Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Randy Presuhn" writes: >(c) Configuration data is the set of writable data required to >transform a system from any possible state into a (fully-specified) >desired state. This (c) is the world of "CLI screen scraping". NETCONF brings us above this level by defining configuration as a cohesive whole. The configuration tells you what you want, not what you might need to throw away. The current config can be discarded as a new configuration is loaded. The role of "from any possible state" is unrelated to the validity of the target configuration. The configuration database tells you want; the server figures out how to get there. While allows you to change an existing configuration, the end result is a new configuration dataset. That config can be fetched, archived, and restored later without regard to the future state of the device. When you load a new config, it need not have instructions to handle any possible current state. The old config can be completely overwritten with the new config ("replace" for edit-config, or just do a copy-config). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 15:31:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9175A3A68BA; Sat, 9 Aug 2008 15:31:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439C93A68BA for ; Sat, 9 Aug 2008 15:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRb+AdQC5Flq for ; Sat, 9 Aug 2008 15:31:50 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 6B0A93A691B for ; Sat, 9 Aug 2008 15:31:50 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 15:31:35 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 15:31:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 15:31:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 15:25:19 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m79MPIu69113; Sat, 9 Aug 2008 15:25:18 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m79MM2NU088775; Sat, 9 Aug 2008 22:22:02 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808092222.m79MM2NU088775@idle.juniper.net> To: Andy Bierman In-reply-to: <489E142C.9090205@netconfcentral.com> Date: Sat, 09 Aug 2008 18:22:02 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2008 22:25:19.0320 (UTC) FILETIME=[CE384580:01C8FA6E] Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Memory and bandwidth are dirt cheap. >Skilled labor and network downtime are not. My static routes have 70-80 configurable knobs, many with sane defaults. Skilled labor looks at those routes when they run "show configuration". Showing them the uninteresting values costs time and money. The signal (important values they set) would be lost in the noise. Increasing the volume of configuration an operator has to look at will have a negative impact on uptime. [ FWIW, my first implementation actually worked this way, keeping nodes in the config database for defaults, but the first test our systest ran was 50,000 static routes. The memory footprint sent me back to the drawing board to make a sparse database. Memory isn't always cheap. ] Try this as an experiment in your software. Make a list with a hundred leafs, build 50,000 of them, and see if you like it. >I suspect your implementation keeps track internally of every >leaf, and if it has a default value. Otherwise, how would >you be prepared to allow edit-config on that leaf? Can't parse the question, but it works like this: we have rich meta-data which defines the hiearchy of objects and the type and defaults for leafs. As the user creates config, we build data structures in the configuration database that mirror this hierarchy for each node they create. If a system subcomponent requires a leaf and it does not appear in the tree, the API looks at the meta data and returns the default there as the value. The user need not enter or see this default. If they want to know it, there's a option that displays all meta-data (defaults, patterns, types, etc). >It is a implementation detail to use this internal data >to generate the default in effect for RPC requests. It's a design principal to not mix meta-data (like types and defaults) into the configuration. Yes, we can, but it's Bad News. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 17:12:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4166A3A68C1; Sat, 9 Aug 2008 17:12:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F33528C0CF for ; Sat, 9 Aug 2008 17:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duJ44eBm-e-G for ; Sat, 9 Aug 2008 17:12:23 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 3B5013A68C1 for ; Sat, 9 Aug 2008 17:12:22 -0700 (PDT) Received: (qmail 18619 invoked from network); 10 Aug 2008 00:12:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 00:12:22 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489E3264.1000108@netconfcentral.com> Date: Sat, 09 Aug 2008 17:12:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808092222.m79MM2NU088775@idle.juniper.net> In-Reply-To: <200808092222.m79MM2NU088775@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Memory and bandwidth are dirt cheap. >> Skilled labor and network downtime are not. > > My static routes have 70-80 configurable knobs, many with sane > defaults. Skilled labor looks at those routes when they run "show > configuration". Showing them the uninteresting values costs time > and money. The signal (important values they set) would be lost > in the noise. Increasing the volume of configuration an operator > has to look at will have a negative impact on uptime. > > [ FWIW, my first implementation actually worked this way, keeping > nodes in the config database for defaults, but the first test our > systest ran was 50,000 static routes. The memory footprint sent > me back to the drawing board to make a sparse database. Memory > isn't always cheap. ] > > Try this as an experiment in your software. Make a list with a > hundred leafs, build 50,000 of them, and see if you like it. > >> I suspect your implementation keeps track internally of every >> leaf, and if it has a default value. Otherwise, how would >> you be prepared to allow edit-config on that leaf? > > Can't parse the question, but it works like this: we have rich > meta-data which defines the hiearchy of objects and the type and > defaults for leafs. As the user creates config, we build data > structures in the configuration database that mirror this hierarchy > for each node they create. If a system subcomponent requires a > leaf and it does not appear in the tree, the API looks at the meta > data and returns the default there as the value. The user need not > enter or see this default. If they want to know it, there's a > option that displays all meta-data (defaults, patterns, types, etc). > >> It is a implementation detail to use this internal data >> to generate the default in effect for RPC requests. > > It's a design principal to not mix meta-data (like types and defaults) > into the configuration. Yes, we can, but it's Bad News. > leaf if-mtu { type uint32; default 1500; } Does the interface have a maximum transmission unit at all times, or will the NE device allow infinite sized packets? If it does have an MTU, whether the value is 1500 or not, the manager should get to read it. We disagree on the value of accessing the actual default values in effect, right now, on a particular device. Nobody ever said the manager wants to see these defaults all the time. Several people have agreed with me that sometimes these values are needed. This is is the same category as the RPC or module version advertisement. The manager can just use off-line vendor provided documentation somehow, so why bother with these on-line mechanisms? Vendors that think instant online documentation (including defaults) is useful will provide that feature, and others will not. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 20:21:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A043A6840; Sat, 9 Aug 2008 20:21:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429CD3A6909 for ; Sat, 9 Aug 2008 20:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJfyvfMCsQSq for ; Sat, 9 Aug 2008 20:21:51 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 68FDF3A6840 for ; Sat, 9 Aug 2008 20:21:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 20:21:52 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 20:21:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 20:21:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 20:21:03 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7A3L3u14219; Sat, 9 Aug 2008 20:21:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7A3Hk9i089983; Sun, 10 Aug 2008 03:17:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808100317.m7A3Hk9i089983@idle.juniper.net> To: Andy Bierman In-reply-to: <489E3264.1000108@netconfcentral.com> Date: Sat, 09 Aug 2008 23:17:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2008 03:21:03.0823 (UTC) FILETIME=[1EC48DF0:01C8FA98] Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Does the interface have a maximum transmission unit at all >times, or will the NE device allow infinite sized packets? >If it does have an MTU, whether the value is 1500 or not, >the manager should get to read it. These are all valid questions but are really about the meta-data, which we should find a way to address. See Martin's email earlier (on this thread?) about "device deviations". The idea is creating it and _then_ discovering what value was used is strange. If my app really cares about the mtu, it cares before it creates an interface, not after the fact. >We disagree on the value of accessing the actual default values >in effect, right now, on a particular device. Nobody ever said >the manager wants to see these defaults all the time. Apologies, I misunderstood you when you said: It the leaf exists in the system, because mandatory is false and there is a default value to apply, then it is part of the configuration database. I read this as saying that default values appear as part of the config, but I'm glad to have misread it. >Vendors that think instant online documentation (including defaults) >is useful will provide that feature, and others will not. I think that online meta-data (machine readable info, not human- oriented documentation) provides a better solution. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 20:33:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F4C28C143; Sat, 9 Aug 2008 20:33:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1445B3A6A5E for ; Sat, 9 Aug 2008 20:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtAbKTNX1bRZ for ; Sat, 9 Aug 2008 20:33:48 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 5A68128C16A for ; Sat, 9 Aug 2008 20:33:48 -0700 (PDT) Received: (qmail 36538 invoked from network); 10 Aug 2008 03:33:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 03:33:47 -0000 X-YMail-OSG: OiVF9e0VM1mmru9NCFRU9Kmt05And4v7oAMm4xp2i0_BdnAJvYkX42h9c0SSKgGAmYWamlt1Thi3LyguMr9gCQZtxNqbN.pBpXwZSAyQmg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489E619A.6080207@netconfcentral.com> Date: Sat, 09 Aug 2008 20:33:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808100317.m7A3Hk9i089983@idle.juniper.net> In-Reply-To: <200808100317.m7A3Hk9i089983@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Does the interface have a maximum transmission unit at all >> times, or will the NE device allow infinite sized packets? >> If it does have an MTU, whether the value is 1500 or not, >> the manager should get to read it. > > These are all valid questions but are really about the meta-data, > which we should find a way to address. See Martin's email earlier > (on this thread?) about "device deviations". > I don't see this as meta-data. If the user sends a request for the exact node (subtree or Xpath), then you pretend the node is not there if it has the default value? And generate and error instead? Do you require that the user only include nodes in must/when expressions that they have explicitly set? So if the user sets the MTU value to 1500, the Xpath works, but if the agent sets it to 1500, then the Xpath is an error because 'if-mtu' does not exist? IMO, your model is fragile, and not suitable for standards. It doesn't matter if CLI and foo.conf do it some other way. They aren't standards and never will be. Andy > The idea is creating it and _then_ discovering what value was used > is strange. If my app really cares about the mtu, it cares before > it creates an interface, not after the fact. > >> We disagree on the value of accessing the actual default values >> in effect, right now, on a particular device. Nobody ever said >> the manager wants to see these defaults all the time. > > Apologies, I misunderstood you when you said: > > It the leaf exists in the system, because mandatory is false > and there is a default value to apply, then it is part > of the configuration database. > > I read this as saying that default values appear as part of the > config, but I'm glad to have misread it. > >> Vendors that think instant online documentation (including defaults) >> is useful will provide that feature, and others will not. > > I think that online meta-data (machine readable info, not human- > oriented documentation) provides a better solution. > > Thanks, > Phil > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 21:40:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA12F3A682D; Sat, 9 Aug 2008 21:40:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20ADD3A682D for ; Sat, 9 Aug 2008 21:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaRcq7Prhbol for ; Sat, 9 Aug 2008 21:40:55 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 32AC93A6BA1 for ; Sat, 9 Aug 2008 21:40:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mk2zdR+yJbH8A0AhQAYSpN2llELrL9kvcshO6FUioR1Ei7uYXoixVJ+NNscIsyJy; 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.89.224] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KS2jg-0005qQ-4e for netmod@ietf.org; Sun, 10 Aug 2008 00:40:56 -0400 Message-ID: <000a01c8faa3$670a4a40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200808100317.m7A3Hk9i089983@idle.juniper.net> <489E619A.6080207@netconfcentral.com> Date: Sat, 9 Aug 2008 21:41:47 -0700 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3e796fce363a7c7bfec1c7f44b7763ba1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.224 Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Saturday, August 09, 2008 8:33 PM > Subject: Re: [netmod] leaf encoding rules ... > I don't see this as meta-data. > > If the user sends a request for the exact > node (subtree or Xpath), then you pretend the node is > not there if it has the default value? And generate > and error instead? I think where this thread is leading it depends on the kind of request. > Do you require that the user only include nodes in > must/when expressions that they have explicitly set? > So if the user sets the MTU value to 1500, the Xpath works, > but if the agent sets it to 1500, then the Xpath is an > error because 'if-mtu' does not exist? It *does* exist in some sense, but because it has not explictly been configured, I think Phil would like to be able to retrieve a representation of the configuration that omits this information. I don't think we're terribly far apart on this. > IMO, your model is fragile, and not suitable for standards. > It doesn't matter if CLI and foo.conf do it some other way. > They aren't standards and never will be. In fairness, it depends on the strength of the contract implied by a claim of conformance to a particular model. One of the things that eventually became quite clear to the requirements design team was that "defaults" were only useful if they really were an "iron-clad" part of the contract specified by a model. If a device claims to support a model and does not do defaults exactly as specified, then yes, it will be "fragile", but just how robust against non-conformant implementations do things need to be? (This isn't merely a rhetorical question!) Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 9 22:48:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B083A677D; Sat, 9 Aug 2008 22:48:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96D53A677D for ; Sat, 9 Aug 2008 22:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5FVThuZW2kG for ; Sat, 9 Aug 2008 22:48:15 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id C0C633A6820 for ; Sat, 9 Aug 2008 22:48:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 22:48:14 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 22:47:57 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 22:47:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 22:47:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7A5luu37657; Sat, 9 Aug 2008 22:47:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7A5idqc090583; Sun, 10 Aug 2008 05:44:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808100544.m7A5idqc090583@idle.juniper.net> To: Andy Bierman In-reply-to: <489E619A.6080207@netconfcentral.com> Date: Sun, 10 Aug 2008 01:44:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Aug 2008 05:47:56.0602 (UTC) FILETIME=[A397E9A0:01C8FAAC] Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I don't see this as meta-data. This is meta-data, since it's information about the data (what value will be used as a default?) rather than data itself. Pick another statement where a device might differ from a standard. "max-elements"? If the model defines a list of "users", does an application need to know that a particular device supports only 16 users? Should the app have to create 17 users to watch the failure to "know" that 16 is the real max-elements? The idea is that there are three types of information: (a) the basic model elements (b) deviations (from the basic model) that the modeler wants to model. These are constructs that are important to the model but are optional. (c) deviations from the model that the modeler didn't model which the device wants to make apps aware of. (a) is normal YANG. (b) is the new "feature" feature. And (c) is the "overlay" or "device deviation" mechanism we've been talking about. The device deviation is not likely to be part of YANG 1.0, so we can table it for now, but I'm imagining something like: module my-bgp-deviations { import bgp; deviation /bgp/peers { max-elements 16; // Fixed number of peers } deviation /bgp/as-number { range min..1024; // trim range } deviation /bgp/priority { default 20; // provide my default } } This puts these deviations in a machine readable form that apps can use to learn device specific _before_ they create/change configuration. >If the user sends a request for the exact >node (subtree or Xpath), then you pretend the node is >not there if it has the default value? And generate >and error instead? Did you intentionally move from config data to here? For configuration, if the node isn't there, it's _not_ there. I don't pretend that it is. Default values for non-config data returned by are an interesting question. If I follow your view, the device has to provide the leaf with the default value, but if I have to provide the value, what's the use of the default? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 01:17:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBED13A69CD; Sun, 10 Aug 2008 01:17:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8D83A69CD for ; Sun, 10 Aug 2008 01:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvv6Cs-1LXtO for ; Sun, 10 Aug 2008 01:17:27 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id B51BF3A68EA for ; Sun, 10 Aug 2008 01:17:21 -0700 (PDT) Received: (qmail 18433 invoked from network); 10 Aug 2008 08:17:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 08:17:20 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489EA40F.5000200@netconfcentral.com> Date: Sun, 10 Aug 2008 01:17:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808100544.m7A5idqc090583@idle.juniper.net> In-Reply-To: <200808100544.m7A5idqc090583@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I don't see this as meta-data. > > This is meta-data, since it's information about the data (what value > will be used as a default?) rather than data itself. > > Pick another statement where a device might differ from a standard. > "max-elements"? If the model defines a list of "users", does an > application need to know that a particular device supports only 16 > users? Should the app have to create 17 users to watch the failure > to "know" that 16 is the real max-elements? > > The idea is that there are three types of information: > (a) the basic model elements > (b) deviations (from the basic model) that the modeler wants to > model. These are constructs that are important to the model > but are optional. > (c) deviations from the model that the modeler didn't model which > the device wants to make apps aware of. > > (a) is normal YANG. (b) is the new "feature" feature. And (c) is > the "overlay" or "device deviation" mechanism we've been talking > about. > > The device deviation is not likely to be part of YANG 1.0, so we > can table it for now, but I'm imagining something like: > > module my-bgp-deviations { > import bgp; > > deviation /bgp/peers { > max-elements 16; // Fixed number of peers > } > > deviation /bgp/as-number { > range min..1024; // trim range > } > > deviation /bgp/priority { > default 20; // provide my default > } > } > > This puts these deviations in a machine readable form that apps can > use to learn device specific _before_ they create/change configuration. > >> If the user sends a request for the exact >> node (subtree or Xpath), then you pretend the node is >> not there if it has the default value? And generate >> and error instead? > > Did you intentionally move from config data to here? > > For configuration, if the node isn't there, it's _not_ there. I > don't pretend that it is. > > Default values for non-config data returned by are an interesting > question. If I follow your view, the device has to provide the > leaf with the default value, but if I have to provide the value, > what's the use of the default? > IMO, your view of 'config data' means an optional leaf can never be used in a must or when XPath expression. If you allow something like 'if-mtu != 1500' in your XPath, only when the manager has set it 1500 (but not the agent), then that seems fairly broken and unreliable to me. If you always allow the XPath access for must/when, but ignore the node's existence for protocol operations, that also seems broken to me. > Thanks, > Phil > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 01:18:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E377A3A68EA; Sun, 10 Aug 2008 01:18:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF853A6923 for ; Sun, 10 Aug 2008 01:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pYslcxwAfWm for ; Sun, 10 Aug 2008 01:18:01 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 133393A6906 for ; Sun, 10 Aug 2008 01:18:01 -0700 (PDT) Received: (qmail 13446 invoked from network); 10 Aug 2008 08:18:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 08:17:59 -0000 X-YMail-OSG: v2ccHRYVM1mW.suYmoI9DDAnboOBhBJPiy0R61zSyiR7dEAcRZb60EPSdJb7Kag0Ji4FO5YJDdBc591hd_HlhFm0g1Ofa5g7U8Isn3np0SuFesS4WwiRLz_42tZCDlE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489EA436.2000507@netconfcentral.com> Date: Sun, 10 Aug 2008 01:17:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Randy Presuhn References: <200808100317.m7A3Hk9i089983@idle.juniper.net> <489E619A.6080207@netconfcentral.com> <000a01c8faa3$670a4a40$6801a8c0@oemcomputer> In-Reply-To: <000a01c8faa3$670a4a40$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Phil Shafer" >> Cc: >> Sent: Saturday, August 09, 2008 8:33 PM >> Subject: Re: [netmod] leaf encoding rules > ... >> I don't see this as meta-data. >> >> If the user sends a request for the exact >> node (subtree or Xpath), then you pretend the node is >> not there if it has the default value? And generate >> and error instead? > > I think where this thread is leading it depends on the kind of > request. > how about the ones in RFC 4741. What are your specific comments on yang-00 and RFC 4741? Andy >> Do you require that the user only include nodes in >> must/when expressions that they have explicitly set? >> So if the user sets the MTU value to 1500, the Xpath works, >> but if the agent sets it to 1500, then the Xpath is an >> error because 'if-mtu' does not exist? > > It *does* exist in some sense, but because it has not > explictly been configured, I think Phil would like to be > able to retrieve a representation of the configuration > that omits this information. I don't think we're terribly > far apart on this. > >> IMO, your model is fragile, and not suitable for standards. >> It doesn't matter if CLI and foo.conf do it some other way. >> They aren't standards and never will be. > > In fairness, it depends on the strength of the contract implied by a > claim of conformance to a particular model. One of the things > that eventually became quite clear to the requirements design > team was that "defaults" were only useful if they really were an > "iron-clad" part of the contract specified by a model. If a device > claims to support a model and does not do defaults exactly as > specified, then yes, it will be "fragile", but just how robust against > non-conformant implementations do things need to be? (This > isn't merely a rhetorical question!) > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 09:18:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232D93A6813; Sun, 10 Aug 2008 09:18:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D103A6DE3 for ; Sun, 10 Aug 2008 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT2-wqQYZ9kO for ; Sun, 10 Aug 2008 09:17:58 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 7EFF23A6DEA for ; Sun, 10 Aug 2008 09:17:58 -0700 (PDT) Received: (qmail 27450 invoked from network); 10 Aug 2008 16:17:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 16:17:57 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489F14B4.80000@netconfcentral.com> Date: Sun, 10 Aug 2008 09:17:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Randy Presuhn References: <200808100317.m7A3Hk9i089983@idle.juniper.net> <489E619A.6080207@netconfcentral.com> <000a01c8faa3$670a4a40$6801a8c0@oemcomputer> <489EA436.2000507@netconfcentral.com> In-Reply-To: <489EA436.2000507@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org >.. >> In fairness, it depends on the strength of the contract implied by a >> claim of conformance to a particular model. One of the things >> that eventually became quite clear to the requirements design >> team was that "defaults" were only useful if they really were an >> "iron-clad" part of the contract specified by a model. If a device >> claims to support a model and does not do defaults exactly as >> specified, then yes, it will be "fragile", but just how robust against >> non-conformant implementations do things need to be? (This >> isn't merely a rhetorical question!) What about agent-selected, platform-specific defaults? Sure, you could retrieve the YANG files for all the optional leafs that have defaults defined. What about all the leafs that have no default defined? You could hope for the first time in history a vendor actually ships bug-free, 100% fully documented code. This seems less robust than just asking the agent directly for these leaf values. Perhaps YANG's mandatory true/false is too simplistic? Sometimes an optional leaf will not be used by an agent at all. Sometimes it will be used with the defined default. Sometimes it will be used with an undocumented default. Sounds like 4 classifications, not 2. >> >> Randy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 12:27:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B673A68D5; Sun, 10 Aug 2008 12:27:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25123A68EE for ; Sun, 10 Aug 2008 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5hniffeG+8o for ; Sun, 10 Aug 2008 12:27:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E52D63A6874 for ; Sun, 10 Aug 2008 12:27:05 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id A062B616001; Sun, 10 Aug 2008 21:27:05 +0200 (CEST) Date: Sun, 10 Aug 2008 21:27:01 +0200 (CEST) Message-Id: <20080810.212701.216264341.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489E619A.6080207@netconfcentral.com> References: <200808100317.m7A3Hk9i089983@idle.juniper.net> <489E619A.6080207@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > If the user sends a request for the exact > node (subtree or Xpath), then you pretend the node is > not there if it has the default value? And generate > and error instead? > > Do you require that the user only include nodes in > must/when expressions that they have explicitly set? Different 'user' here. The first is the NETCONF user, and IMO the answer again depends on the with-defaults parameter. In the second case the 'user' is the DM writer, and section 7.5.2 specifies that default values are visible in must expressions. The same text should be in 7.15.2 (for when) as well. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 12:30:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847923A6874; Sun, 10 Aug 2008 12:30:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8899D3A6928 for ; Sun, 10 Aug 2008 12:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0dtroUDx+02 for ; Sun, 10 Aug 2008 12:30:52 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C43A33A6874 for ; Sun, 10 Aug 2008 12:30:52 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 59C00616009; Sun, 10 Aug 2008 21:30:54 +0200 (CEST) Date: Sun, 10 Aug 2008 21:30:52 +0200 (CEST) Message-Id: <20080810.213052.220006375.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808081945.m78JjWL7082067@idle.juniper.net> References: <1218001487.6297.4.camel@missotis> <200808081945.m78JjWL7082067@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: > >> path "../../interface[name = $this/../ifname]/address/ip"; > > path "../../interface[name = current()/../ifname]/address/ip"; > > You're absolutely right. $this and current() are identical. We > should mimic this XSLT function instead of rolling our own. Unless someone objects, I will make this change and use current() instead of $this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 12:37:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EA53A68CA; Sun, 10 Aug 2008 12:37:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339C53A6C23 for ; Sun, 10 Aug 2008 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To5zOitwmzvi for ; Sun, 10 Aug 2008 12:37:04 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B30B73A68CA for ; Sun, 10 Aug 2008 12:36:56 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 503B4616001; Sun, 10 Aug 2008 21:36:58 +0200 (CEST) Date: Sun, 10 Aug 2008 21:36:53 +0200 (CEST) Message-Id: <20080810.213653.159547579.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489DFF1B.90409@netconfcentral.com> References: <489DC2D7.4040501@netconfcentral.com> <20080809.213931.238323260.mbj@tail-f.com> <489DFF1B.90409@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] must-stmt in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > No, this is not legal. 7.15 says > > If the > > "augment" statement is on the top-level in a module or submodule, the > > absolute form of a schema node identifier MAY be used. Otherwise, > > the descendant form MUST be used. > > > > > This seems odd because objects within a top-level grouping > and used at the top-level are visible in other modules > as top level elements. But the "augment" statement is not on the top-level, it is within a grouping. > There is still a problem with prefixes in must/when XPath expressions > that appear within a grouping which is used in a different module. 7.11 says: Prefix mappings, type names, grouping names, and extension usage are evaluated in the hierarchy where the grouping statement appears. So I don't think this is a problem. > > But I agree that it might be a good idea to use two separate > > statements. The current 'uses' substatements have another problem, so > > maybe we can solve both problems. The problem is that the grammar for > > e.g. 'leaf' is context-dependant. When it appears within a 'uses', it > > cannot have a type for example. Here is one idea: > > uses Interface { > > refine interface/mtu { > > default 1500; > > } > > extend interface/unit { > > leaf my-vlan-param { ... } > > } > > } > > The substatements to 'uses' clearly signals what is going on - > > refinements and extensions to the grouping. > > > > > But this is broken because you cannot refine a local grouping this way. I don't udnerstand what you mean. What is broken? > I like the current augments and uses design just fine because there > cannot be any duplicates and it supports local groupings. The idea is that you can do exacty the same things with the new 'refine' statement. It is just a different syntax, but the syntax has a couple of advantages - it gets rid of the context-dependendent grammar; it uses a target path to modify, just like augemnt (and possibly extend) instead of the current "overlay" style. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 12:44:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B9228C1D4; Sun, 10 Aug 2008 12:44:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E4828C1D5 for ; Sun, 10 Aug 2008 12:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPEacyHtVaLX for ; Sun, 10 Aug 2008 12:44:36 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 772F928C1D4 for ; Sun, 10 Aug 2008 12:44:36 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 1482E616001; Sun, 10 Aug 2008 21:44:38 +0200 (CEST) Date: Sun, 10 Aug 2008 21:44:36 +0200 (CEST) Message-Id: <20080810.214436.179750973.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489F14B4.80000@netconfcentral.com> References: <000a01c8faa3$670a4a40$6801a8c0@oemcomputer> <489EA436.2000507@netconfcentral.com> <489F14B4.80000@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > What about agent-selected, platform-specific defaults? Currently in YANG, there is no formal way to learn these or even know that a leaf is intended to get an agent-selected default. We have discussed several ways to address this, but I think the main question the WG has to answer is what level of support YANG should provide for this problem, if any. One way for a client to *know* that a leaf has an egent-selected value is to add the "created-by" statement. In order to learn such a value, I think the best solution is to keep these values in category 2 "vendor-specific deviations not specified in the model", and as Phil said thus probably out of scope for YANG 1.0. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 12:54:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7023A6902; Sun, 10 Aug 2008 12:54:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E253A6902 for ; Sun, 10 Aug 2008 12:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO5RHJ1SUBfG for ; Sun, 10 Aug 2008 12:54:48 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 5982C28C1C8 for ; Sun, 10 Aug 2008 12:54:48 -0700 (PDT) Received: (qmail 94710 invoked from network); 10 Aug 2008 19:54:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 19:54:48 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489F4786.3070000@netconfcentral.com> Date: Sun, 10 Aug 2008 12:54:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, IMO, we were on the right track with capabilities, and all this feature stuff conflicts with the established conformance mechanism in NETCONF. The following example shows a much less ambitious conformance model: - If no module capabilities exist then the entire module is mandatory-to-implement - Otherwise, - any object (or even an enum or bit) can be tagged with zero or more 'if-capability' statements. - multiple 'if-capability' statements are ANDed together if more than one is in effect for a given node Module compliance variance, such as SMIv2 MIN-ACCESS is punted to a future version of YANG. Agent variance, such as SMIv2 AGENT-CAPABILITIES, or Martin's yet undocumented overlay mechanism, is punted to a future version of YANG. ============================== module acme { ... import if { prefix if; } ... list foo { if-capability "acme-1"; if-capability "if:if-table"; ... } // entire module is mandatory except anything // tagged with any 'if-capability' statements capability acme1 { status current; description ""; reference ""; uri "http://example.com/capabilities/acme1"; } } module if { container interfaces { list interface { if-capability "if-table"; ... } leaf ifNumber { // conformance is mandatory for module 'if' } list ifStackTable { if-capability "if-table"; if-capability "if-stack"; ... } } capability if-table { description "Basic interface table support"; uri "http://example.com/capabilities/if-table"; } capability if-stack { description "Interface stack table support."; uri "http://example.com/capabilities/if-stack"; } } module netconf { // RPC example rpc edit-config { input { ... leaf error-option { type enumeration { enum stop-on-error; enum continue-on-error; enum rollback-on-error { if-capability "rollback-on-error"; } } } } } capability rollback-on-error { description "If an error condition occurs such that an error severity element is generated, the server will stop processing the edit-config operation and restore the specified configuration to its complete state at the start of this edit-config operation."; reference "RFC 4741, section 8.5"; uri "urn:ietf:params:netconf:capability:rollback-on-error:1.0"; } } ============================== Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 13:22:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609F83A6935; Sun, 10 Aug 2008 13:22:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E8E3A6DF3 for ; Sun, 10 Aug 2008 13:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnDqVnH79MhQ for ; Sun, 10 Aug 2008 13:22:50 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 54EC43A6935 for ; Sun, 10 Aug 2008 13:22:50 -0700 (PDT) Received: (qmail 28505 invoked from network); 10 Aug 2008 20:22:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 20:22:50 -0000 X-YMail-OSG: S44CJVYVM1nAIzuVAfVnMqtzUVuHCQriWIlgbyTBkGUUDTFIqzTuzNrokJXnbHhrthsDSibWeHW9Hv5JJilw2xKm_oc_n2QTTF.wPSTvng-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489F4E19.30608@netconfcentral.com> Date: Sun, 10 Aug 2008 13:22:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489DC2D7.4040501@netconfcentral.com> <20080809.213931.238323260.mbj@tail-f.com> <489DFF1B.90409@netconfcentral.com> <20080810.213653.159547579.mbj@tail-f.com> In-Reply-To: <20080810.213653.159547579.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] must-stmt in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> No, this is not legal. 7.15 says >>> If the >>> "augment" statement is on the top-level in a module or submodule, the >>> absolute form of a schema node identifier MAY be used. Otherwise, >>> the descendant form MUST be used. >>> >> >> This seems odd because objects within a top-level grouping >> and used at the top-level are visible in other modules >> as top level elements. > > But the "augment" statement is not on the top-level, it is within a > grouping. > >> There is still a problem with prefixes in must/when XPath expressions >> that appear within a grouping which is used in a different module. > > 7.11 says: > > Prefix mappings, type names, grouping names, > and extension usage are evaluated in the hierarchy where the grouping > statement appears. > > So I don't think this is a problem. > Right -- the prefixes in any must-stmt in some leaf in the grouping are relative to the module containing the grouping. When the agent expands the grouping into another module, it must normalize all the Xpath expressions so they refer to the correct module, regardless of the set of module prefixes in use in the module with the uses-stmt. The draft should explain that a must-stmt within a grouping cannot be fully evaluated because the uses node is the current context, and it is unknown. Also, an implementation must resolve all differences in module prefix usage when using groupings from other modules. > >>> But I agree that it might be a good idea to use two separate >>> statements. The current 'uses' substatements have another problem, so >>> maybe we can solve both problems. The problem is that the grammar for >>> e.g. 'leaf' is context-dependant. When it appears within a 'uses', it >>> cannot have a type for example. Here is one idea: >>> uses Interface { >>> refine interface/mtu { >>> default 1500; >>> } >>> extend interface/unit { >>> leaf my-vlan-param { ... } >>> } >>> } >>> The substatements to 'uses' clearly signals what is going on - >>> refinements and extensions to the grouping. >>> >> >> But this is broken because you cannot refine a local grouping this way. > > I don't udnerstand what you mean. What is broken? > Currently, I can refine a local grouping within a uses: uses FooContainer { container foo { grouping foo-local { leaf a1 { type string { length "min..10"; } } } } } How are you going to do that with Xpath? IMO, adding meta-data like groupings into the object tree makes it too complicated. The current nested approach also makes it easier to read and force top-down definition. The Xpath approach can be in any order: uses FooContainer { refine "foo/tab1/a1" { length "min..10"; } // 11 more direct mods of 'a1' leafs... refine "foo/tab1/a1" { config true; } refine "foo/tab1" { config false; } } IMO the current approach is cleaner, but one can construct examples where XPath is much more terse (at the expense of the info carried in the object type). >> I like the current augments and uses design just fine because there >> cannot be any duplicates and it supports local groupings. > > The idea is that you can do exacty the same things with the new > 'refine' statement. It is just a different syntax, but the syntax has > a couple of advantages - it gets rid of the context-dependendent > grammar; it uses a target path to modify, just like augemnt (and > possibly extend) instead of the current "overlay" style. > But groupings are not objects and grouping names are not in the same YANG naming scope as objects. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 13:36:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61183A6C24; Sun, 10 Aug 2008 13:36:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED22C3A6E0A for ; Sun, 10 Aug 2008 13:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVbA6wLrvGd8 for ; Sun, 10 Aug 2008 13:36:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id ABD193A698D for ; Sun, 10 Aug 2008 13:36:34 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 80856616001; Sun, 10 Aug 2008 22:36:35 +0200 (CEST) Date: Sun, 10 Aug 2008 22:36:32 +0200 (CEST) Message-Id: <20080810.223632.199656179.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489F4786.3070000@netconfcentral.com> References: <489F4786.3070000@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > IMO, we were on the right track with capabilities, and all > this feature stuff conflicts with the established conformance > mechanism in NETCONF. The following example shows a much > less ambitious conformance model: > > - If no module capabilities exist then the entire module > is mandatory-to-implement > - Otherwise, > - any object (or even an enum or bit) can be tagged with > zero or more 'if-capability' statements. > - multiple 'if-capability' statements are ANDed together > if more than one is in effect for a given node This is what we had in mind when we came to Dublin. But after discussion with the IPFIX people, we proposed the "feature"-feature instead. It can be defined exactly as you describe above with s/capability/feature/g. But it solves the scalability problem associated with capabilities. Instead of getting one huge flat list of all capabilities, you get two levels of capabilities/features. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 14:09:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13913A69A5; Sun, 10 Aug 2008 14:09:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B563A69A5 for ; Sun, 10 Aug 2008 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMXpHbRmKFBM for ; Sun, 10 Aug 2008 14:09:32 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 05B393A6B16 for ; Sun, 10 Aug 2008 14:09:32 -0700 (PDT) Received: (qmail 21229 invoked from network); 10 Aug 2008 21:09:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 10 Aug 2008 21:09:32 -0000 X-YMail-OSG: MWng35AVM1lDipru2gh7E6qHslIrIuTvx9n_zAatJ1iOkgYqSlWTN4uHI8hOYY6LFNm79FLfjpVFOMQbcREw3LErLzb6_1Av9CJ9dljtWg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489F590B.2030807@netconfcentral.com> Date: Sun, 10 Aug 2008 14:09:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489F4786.3070000@netconfcentral.com> <20080810.223632.199656179.mbj@tail-f.com> In-Reply-To: <20080810.223632.199656179.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> IMO, we were on the right track with capabilities, and all >> this feature stuff conflicts with the established conformance >> mechanism in NETCONF. The following example shows a much >> less ambitious conformance model: >> >> - If no module capabilities exist then the entire module >> is mandatory-to-implement >> - Otherwise, >> - any object (or even an enum or bit) can be tagged with >> zero or more 'if-capability' statements. >> - multiple 'if-capability' statements are ANDed together >> if more than one is in effect for a given node > > This is what we had in mind when we came to Dublin. But after > discussion with the IPFIX people, we proposed the "feature"-feature > instead. It can be defined exactly as you describe above with > s/capability/feature/g. But it solves the scalability problem > associated with capabilities. Instead of getting one huge flat list > of all capabilities, you get two levels of capabilities/features. > > OK. How is a feature associated with a capability in machine-readable format? How does an application automatically learn this hierarchy definition and its usage within the entire module set? > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 10 21:37:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A533A6BE7; Sun, 10 Aug 2008 21:37:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3903A6BE7 for ; Sun, 10 Aug 2008 21:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SF9tTyxWEv0d for ; Sun, 10 Aug 2008 21:37:24 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 2D1883A67EA for ; Sun, 10 Aug 2008 21:37:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Sun, 10 Aug 2008 21:37:22 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 21:37:21 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 21:37:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Aug 2008 21:37:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7B4bKu71935; Sun, 10 Aug 2008 21:37:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7B4Y1jS094679; Mon, 11 Aug 2008 04:34:02 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808110434.m7B4Y1jS094679@idle.juniper.net> To: Andy Bierman In-reply-to: <489F590B.2030807@netconfcentral.com> Date: Mon, 11 Aug 2008 00:34:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 04:37:21.0016 (UTC) FILETIME=[F1668780:01C8FB6B] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >How is a feature associated with a capability in machine-readable >format? How does an application automatically learn this hierarchy >definition and its usage within the entire module set? A new rpc will be defined that accepts a namespace and returns the features that are implemented for the module with that namespace. The application performs this RPC and learns from the device which features are supported. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 03:17:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F203A6E3D; Mon, 11 Aug 2008 03:17:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B613A6E3B for ; Mon, 11 Aug 2008 03:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.412 X-Spam-Level: X-Spam-Status: No, score=0.412 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DATE_IN_PAST_03_06=0.044, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNnSA56rLGct for ; Mon, 11 Aug 2008 03:17:55 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 274F43A6B97 for ; Mon, 11 Aug 2008 03:17:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2BCB576C4E9 for ; Mon, 11 Aug 2008 12:17:56 +0200 (CEST) Date: Mon, 11 Aug 2008 09:05:08 +0200 (CEST) Message-Id: <20080811.090508.104047439.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I believe it was Andy who pointed out that there is one thing which breaks the rule that a submodule can be validated in isolation from its main module. The problem is the local prefix used for the module. In a submodule, an XPath expression might use the module's local prefix to refer to local nodes. But the module's prefix is defined in the main module. This implies that a validator which validates a submodule has to parse the main module as well, just to get to the prefix. It is also harder on the reader, since it is very implicit. To solve this problem, I suggest we add an optional prefix substatement to belongs-to: submodule foo { belongs-to bar { prefix b; } ... } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 03:25:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3F33A69DF; Mon, 11 Aug 2008 03:25:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8DF3A69DF for ; Mon, 11 Aug 2008 03:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, DATE_IN_PAST_03_06=0.044, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIwqylUjxiBe for ; Mon, 11 Aug 2008 03:25:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5F1CD3A690C for ; Mon, 11 Aug 2008 03:25:29 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0970E76C4D7; Mon, 11 Aug 2008 12:17:56 +0200 (CEST) Date: Mon, 11 Aug 2008 08:55:16 +0200 (CEST) Message-Id: <20080811.085516.193230054.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: [netmod] augment clarification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > BTW, I just found another error-check with augmenting > a choice. If the choice has a default case, then you cannot > augment the default case with any mandatory nodes. You're right, but I don't think this is specific to a choice with a default case. It applies to all cases in a choice. We need to clarify that augment MUST NOT add any mandatory nodes (i.e. mandatory leaf, list or leaf-list w/ min-elements > 0 etc). The idea behind this is that an augment must not break a client that doesn't understand the augmentation. Such a client will never be able to add the mandatory nodes... /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 05:53:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8783A67B2; Mon, 11 Aug 2008 05:53:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445313A67B2 for ; Mon, 11 Aug 2008 05:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN0G26m3Gws6 for ; Mon, 11 Aug 2008 05:53:40 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 920693A6A71 for ; Mon, 11 Aug 2008 05:53:38 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 05:52:43 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 05:52:57 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 05:52:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 05:52:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7BCqtu19825; Mon, 11 Aug 2008 05:52:55 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BCnbQ1097029; Mon, 11 Aug 2008 12:49:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111249.m7BCnbQ1097029@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080811.090508.104047439.mbj@tail-f.com> Date: Mon, 11 Aug 2008 08:49:37 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 12:52:56.0576 (UTC) FILETIME=[2D2CE800:01C8FBB1] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >I believe it was Andy who pointed out that there is one thing which >breaks the rule that a submodule can be validated in isolation from >its main module. The problem is the local prefix used for the module. >In a submodule, an XPath expression might use the module's local >prefix to refer to local nodes. But the module's prefix is defined in >the main module. Can we require that XPath expressions for the current namespace not use a prefix? It's more clear and less work. Or is there some case where you need the prefix? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 06:00:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770153A6D3F; Mon, 11 Aug 2008 06:00:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F423A6D3F for ; Mon, 11 Aug 2008 06:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=1.160, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZo5GCRahSqZ for ; Mon, 11 Aug 2008 06:00:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4B28C3A6C8A for ; Mon, 11 Aug 2008 06:00:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0596376C4D7; Mon, 11 Aug 2008 15:00:22 +0200 (CEST) Date: Mon, 11 Aug 2008 15:00:17 +0200 (CEST) Message-Id: <20080811.150017.202801987.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808111249.m7BCnbQ1097029@idle.juniper.net> References: <20080811.090508.104047439.mbj@tail-f.com> <200808111249.m7BCnbQ1097029@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > >I believe it was Andy who pointed out that there is one thing which > >breaks the rule that a submodule can be validated in isolation from > >its main module. The problem is the local prefix used for the module. > >In a submodule, an XPath expression might use the module's local > >prefix to refer to local nodes. But the module's prefix is defined in > >the main module. > > Can we require that XPath expressions for the current namespace > not use a prefix? It's more clear and less work. Or is there > some case where you need the prefix? Another use case which I forgot to mention is references to local typedefs and groupings. This can be solved in the same way of course (by not allowing prefix on references to local definitions), but I would prefer to let the user decide whether local definitions should be prefixed or not. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 06:26:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F653A6AFD; Mon, 11 Aug 2008 06:26:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A923A68FE; Mon, 11 Aug 2008 06:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEHF4PtNpBKg; Mon, 11 Aug 2008 06:26:09 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9F4EF3A68AD; Mon, 11 Aug 2008 06:26:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,341,1215403200"; d="scan'208";a="117853006" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Aug 2008 09:26:08 -0400 X-IronPort-AV: E=Sophos;i="4.31,341,1215403200"; d="scan'208";a="255587345" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Aug 2008 09:26:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 15:25:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: InetAddress in http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-10.txt Thread-Index: Acj7tcJpfVSmPNGAQ8it6X+S8ruZYQ== From: "Romascanu, Dan (Dan)" To: , Subject: [netmod] InetAddress in http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org FYI, and somehow related with OPSAWG (and NETMOD) discussions we had in Dublin. The Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-10. txt which is on the agenda of this week IESG telechat for approval as Proposed Standard defines an XML representation of InetAddress as part of the definition of a data model for traceroute results. Any comments or concerns? Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 06:48:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE803A6965; Mon, 11 Aug 2008 06:48:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F95C3A6965 for ; Mon, 11 Aug 2008 06:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlJoh218d8JA for ; Mon, 11 Aug 2008 06:48:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6A1E43A6AB4 for ; Mon, 11 Aug 2008 06:48:38 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2BBFC76C4D6; Mon, 11 Aug 2008 15:48:37 +0200 (CEST) Date: Mon, 11 Aug 2008 15:48:37 +0200 (CEST) Message-Id: <20080811.154837.65694432.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <20080811.150017.202801987.mbj@tail-f.com> References: <20080811.090508.104047439.mbj@tail-f.com> <200808111249.m7BCnbQ1097029@idle.juniper.net> <20080811.150017.202801987.mbj@tail-f.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > > >I believe it was Andy who pointed out that there is one thing which > > >breaks the rule that a submodule can be validated in isolation from > > >its main module. The problem is the local prefix used for the module. > > >In a submodule, an XPath expression might use the module's local > > >prefix to refer to local nodes. But the module's prefix is defined in > > >the main module. > > > > Can we require that XPath expressions for the current namespace > > not use a prefix? It's more clear and less work. Or is there > > some case where you need the prefix? > > Another use case which I forgot to mention is references to local > typedefs and groupings. This can be solved in the same way of course > (by not allowing prefix on references to local definitions), but I > would prefer to let the user decide whether local definitions should > be prefixed or not. Yet another use-case is references to extensions. In this case, the extension MUST have a prefix, even when it is local. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 06:51:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32ED73A6B5F; Mon, 11 Aug 2008 06:51:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FA43A6B5F for ; Mon, 11 Aug 2008 06:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwqg0EX0TudY for ; Mon, 11 Aug 2008 06:51:29 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 5748A3A6C38 for ; Mon, 11 Aug 2008 06:51:29 -0700 (PDT) Received: (qmail 9591 invoked from network); 11 Aug 2008 13:51:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 13:51:24 -0000 X-YMail-OSG: .UeOcwgVM1ny2Z8fbhBc_YiM9YIgS0FBv__roUkX8n0vuiAfnEM5O9orViinPv_Tk.AorS2g5WJW2qYcFCPqlN6XdP38Z9XD0rUvz3wGaw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A043DA.6080307@netconfcentral.com> Date: Mon, 11 Aug 2008 06:51:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.090508.104047439.mbj@tail-f.com> In-Reply-To: <20080811.090508.104047439.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > I believe it was Andy who pointed out that there is one thing which > breaks the rule that a submodule can be validated in isolation from > its main module. The problem is the local prefix used for the module. > In a submodule, an XPath expression might use the module's local > prefix to refer to local nodes. But the module's prefix is defined in > the main module. This implies that a validator which validates a > submodule has to parse the main module as well, just to get to the > prefix. It is also harder on the reader, since it is very implicit. > > To solve this problem, I suggest we add an optional prefix > substatement to belongs-to: > > submodule foo { > belongs-to bar { > prefix b; > } > ... > } > It isn't that hard to read in the module header to get this info. I agree it is confusing because the sub-module can use a prefix that is not actually declared anywhere in the sub-module. You need to maintain a context record anyway to detect multi-module definition loops, so this is just a few mores days of coding on top of that ;-) I don't know that self-compiling sub-modules are important for the standard. You can never release just a sub-module. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 06:59:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CF33A6B59; Mon, 11 Aug 2008 06:59:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3925C3A6BF1 for ; Mon, 11 Aug 2008 06:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlXcprl+i8VJ for ; Mon, 11 Aug 2008 06:59:17 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 54D323A6B59 for ; Mon, 11 Aug 2008 06:59:17 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EBFB76C4D6; Mon, 11 Aug 2008 15:59:19 +0200 (CEST) Date: Mon, 11 Aug 2008 15:59:15 +0200 (CEST) Message-Id: <20080811.155915.44773034.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48A043DA.6080307@netconfcentral.com> References: <20080811.090508.104047439.mbj@tail-f.com> <48A043DA.6080307@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > I believe it was Andy who pointed out that there is one thing which > > breaks the rule that a submodule can be validated in isolation from > > its main module. The problem is the local prefix used for the module. > > In a submodule, an XPath expression might use the module's local > > prefix to refer to local nodes. But the module's prefix is defined in > > the main module. This implies that a validator which validates a > > submodule has to parse the main module as well, just to get to the > > prefix. It is also harder on the reader, since it is very implicit. > > To solve this problem, I suggest we add an optional prefix > > substatement to belongs-to: > > submodule foo { > > belongs-to bar { > > prefix b; > > } > > ... > > } > > ... > I agree it is confusing because the sub-module can use a prefix > that is not actually declared anywhere in the sub-module. This is the main problem. I'm adding some clarifications that you suggested earlier: - submodules must be self-contained -- if a foreign symbol is encountered (e.g., type or grouping name) then it must be found through the import or include mechanisms. - since a sub-module can never import or include its parent(s), it cannot use any definitions from those files. - the one exception to this rule is the module prefix, which may optionally be used within its submodules. (This means a compiler parsing a sub-module must also partially parse the top module, via the belongs-to clause, to get the module prefix). And I would like to avoid this one exception. Everything will be simpler if we keep the number of exceptions to a minimum, and the resolution to this one seems pretty obvious and easy. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 07:03:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693DB3A687F; Mon, 11 Aug 2008 07:03:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7723A6AB4 for ; Mon, 11 Aug 2008 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fdsofsyHvFx for ; Mon, 11 Aug 2008 07:03:41 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BFEAD3A687F for ; Mon, 11 Aug 2008 07:03:41 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 44E2E76C4D7; Mon, 11 Aug 2008 16:03:43 +0200 (CEST) Date: Mon, 11 Aug 2008 16:03:41 +0200 (CEST) Message-Id: <20080811.160341.191552656.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <20080728.102612.142840307.mbj@tail-f.com> References: <488CE107.1090509@netconfcentral.com> <20080728.102612.142840307.mbj@tail-f.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] config-stmt on choice and/or case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > Remind me again why we don't need config-stmt within choice-stmt > > or case-stmt? > > I don't see any reasons for not allowing config under choice and > case. If no one objects, I'll make this change. Hmmm, I object. What does this mean: choice foo { case a { config true; leaf x { ... } case b { config false; leaf y { ... } } I think config under choice makes perfect sense. But for 'case', I'd like to be more restrictive and say that if any node in any case is config, then there must be at least one config node in each case. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 07:25:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D073A6CB2; Mon, 11 Aug 2008 07:25:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391113A6D53 for ; Mon, 11 Aug 2008 07:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCH9Hab8O8zJ for ; Mon, 11 Aug 2008 07:25:14 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 7F2FB3A6CB2 for ; Mon, 11 Aug 2008 07:25:14 -0700 (PDT) Received: (qmail 46971 invoked from network); 11 Aug 2008 14:25:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 14:25:06 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A04BC0.6000706@netconfcentral.com> Date: Mon, 11 Aug 2008 07:25:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <488CE107.1090509@netconfcentral.com> <20080728.102612.142840307.mbj@tail-f.com> <20080811.160341.191552656.mbj@tail-f.com> In-Reply-To: <20080811.160341.191552656.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] config-stmt on choice and/or case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, >>> >>> Remind me again why we don't need config-stmt within choice-stmt >>> or case-stmt? >> I don't see any reasons for not allowing config under choice and >> case. If no one objects, I'll make this change. > > Hmmm, I object. What does this mean: > > choice foo { > case a { > config true; > leaf x { ... } > case b { > config false; > leaf y { ... } > } > > I think config under choice makes perfect sense. But for 'case', I'd > like to be more restrictive and say that if any node in any case is > config, then there must be at least one config node in each case. > OK -- I agree this is unlikely. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 07:36:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989DE3A6E80; Mon, 11 Aug 2008 07:36:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C0F3A6E7B for ; Mon, 11 Aug 2008 07:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVfoldcBz0-D for ; Mon, 11 Aug 2008 07:36:28 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id C17C43A6E76 for ; Mon, 11 Aug 2008 07:36:28 -0700 (PDT) Received: (qmail 66629 invoked from network); 11 Aug 2008 14:36:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 14:36:30 -0000 X-YMail-OSG: XfoKcvIVM1krRovwOemlkTtOc2eD3rU6PqZqJ5EmezFQwa4tI3P.wk7o3V.RtkQ6gWVTcqGcmn7MK8rI_Jt4gXpeUiN4V_z2k9vXC5nmXQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A04E6D.20304@netconfcentral.com> Date: Mon, 11 Aug 2008 07:36:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.090508.104047439.mbj@tail-f.com> <48A043DA.6080307@netconfcentral.com> <20080811.155915.44773034.mbj@tail-f.com> In-Reply-To: <20080811.155915.44773034.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> I believe it was Andy who pointed out that there is one thing which >>> breaks the rule that a submodule can be validated in isolation from >>> its main module. The problem is the local prefix used for the module. >>> In a submodule, an XPath expression might use the module's local >>> prefix to refer to local nodes. But the module's prefix is defined in >>> the main module. This implies that a validator which validates a >>> submodule has to parse the main module as well, just to get to the >>> prefix. It is also harder on the reader, since it is very implicit. >>> To solve this problem, I suggest we add an optional prefix >>> substatement to belongs-to: >>> submodule foo { >>> belongs-to bar { >>> prefix b; >>> } >>> ... >>> } >>> > > ... > >> I agree it is confusing because the sub-module can use a prefix >> that is not actually declared anywhere in the sub-module. > > This is the main problem. I'm adding some clarifications that you > suggested earlier: > > - submodules must be self-contained -- if a foreign symbol is > encountered (e.g., type or grouping name) then it must be > found through the import or include mechanisms. > > - since a sub-module can never import or include its parent(s), > it cannot use any definitions from those files. > > - the one exception to this rule is the module prefix, which > may optionally be used within its submodules. (This means > a compiler parsing a sub-module must also partially parse > the top module, via the belongs-to clause, to get the module prefix). > > And I would like to avoid this one exception. Everything will be > simpler if we keep the number of exceptions to a minimum, and the > resolution to this one seems pretty obvious and easy. > The obvious solution is the one Phil suggested, not adding yet another prefix variant into the module. What if the module uses sub-module definitions in Xpath with its own prefix, and all the sub-modules use different prefixes as well -- it makes other tasks like grouping/uses and augment processing more difficult. (And yes, it is a pain to code this, but yangdump will always allow the local prefix or no prefix -- even on extensions in the local module. And yes, I am annoyed, because I suggested the 'no prefix on current module' rule a year ago :-) > > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 07:52:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8543A684C; Mon, 11 Aug 2008 07:52:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6733A6965 for ; Mon, 11 Aug 2008 07:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmbOQr0fFfud for ; Mon, 11 Aug 2008 07:52:09 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 746D33A67F8 for ; Mon, 11 Aug 2008 07:52:00 -0700 (PDT) Received: (qmail 49763 invoked from network); 11 Aug 2008 14:51:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 14:51:11 -0000 X-YMail-OSG: PmaaXE0VM1l9LCUWmHvGMyaEMtPPpw7gmHYNQvgZbRCLyarIiLXNjaInYERKiJH18cRosQTzn.UX873860iFtne74iuMvX8qeAiI4Bh8BA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A051DE.6050606@netconfcentral.com> Date: Mon, 11 Aug 2008 07:51:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.090508.104047439.mbj@tail-f.com> <48A043DA.6080307@netconfcentral.com> <20080811.155915.44773034.mbj@tail-f.com> <48A04E6D.20304@netconfcentral.com> In-Reply-To: <48A04E6D.20304@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: >... > (And yes, it is a pain to code this, but yangdump will > always allow the local prefix or no prefix -- even on extensions > in the local module. And yes, I am annoyed, because I suggested > the 'no prefix on current module' rule a year ago :-) > The reason for not doing this was that we could never add any new built-in data types without incrementing the yang-version to '2'. IMO, so what? Adding new built-in types is a major change so bumping the YANG version is appropriate. But I also think the current design is OK. The belongs-to statement implies the module prefix. Add some documentation and it won't be confusing anymore. > >> >> /martin >> > > Andy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 07:52:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8A33A67F8; Mon, 11 Aug 2008 07:52:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427DF3A67F8 for ; Mon, 11 Aug 2008 07:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcjcXVapH9cP for ; Mon, 11 Aug 2008 07:52:43 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id B50F83A684C for ; Mon, 11 Aug 2008 07:52:41 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 07:51:32 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:51:31 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:51:30 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:51:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7BEpTu51883; Mon, 11 Aug 2008 07:51:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BEmAZb098317; Mon, 11 Aug 2008 14:48:11 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111448.m7BEmAZb098317@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080811.150017.202801987.mbj@tail-f.com> Date: Mon, 11 Aug 2008 10:48:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 14:51:29.0841 (UTC) FILETIME=[BD030210:01C8FBC1] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Another use case which I forgot to mention is references to local >typedefs and groupings. Ah, right. I'm fine with prefix inside belongs-to. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 08:18:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6033A699A; Mon, 11 Aug 2008 08:18:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8162E3A6A4D for ; Mon, 11 Aug 2008 08:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlaZ1Fo9r9IX for ; Mon, 11 Aug 2008 08:18:27 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6E2613A699A for ; Mon, 11 Aug 2008 08:18:27 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7BFI7Vl024254; Mon, 11 Aug 2008 18:18:22 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 18:10:30 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 18:10:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 18:10:28 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F266045916D8@esebe103.NOE.Nokia.com> In-Reply-To: <20080811.085516.193230054.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] augment clarification Thread-Index: Acj7nJ5yb7YNug/jRd6BBndR1yryggAJJpdw References: <20080811.085516.193230054.mbj@tail-f.com> From: To: , X-OriginalArrivalTime: 11 Aug 2008 15:10:30.0056 (UTC) FILETIME=[64A20280:01C8FBC4] X-Nokia-AV: Clean Cc: netmod@ietf.org Subject: Re: [netmod] augment clarification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi , Martin Bjorklund mbj@tail-f.com> wrote: > You're right, but I don't think this is specific to a choice with a > default case. It applies to all cases in a choice. We need to > clarify that augment MUST NOT add any mandatory nodes (i.e. mandatory > leaf, list or leaf-list w/ min-elements > 0 etc). Doesn't this apply to also to augmentations of list, container etc? (Not sure if that way implicitly included in your statement above). > > The idea behind this is that an augment must not break a client that > doesn't understand the augmentation. Such a client will never be able > to add the mandatory nodes... > Exactly. So I think that this is a useful restriction - as it allows to focus on a data tree as originally defined in the original module. - Bernd > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 11:33:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D00F3A6C2F; Mon, 11 Aug 2008 11:33:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340D23A6C33 for ; Mon, 11 Aug 2008 11:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ+sitfcphST for ; Mon, 11 Aug 2008 11:33:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6107B3A6801 for ; Mon, 11 Aug 2008 11:33:27 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id DAE6F76C4D7; Mon, 11 Aug 2008 20:33:20 +0200 (CEST) Date: Mon, 11 Aug 2008 20:34:07 +0200 (CEST) Message-Id: <20080811.203407.208282771.mbj@tail-f.com> To: bernd.linowski.ext@nsn.com From: Martin Bjorklund In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F266045916D8@esebe103.NOE.Nokia.com> References: <20080811.085516.193230054.mbj@tail-f.com> <46DCD7DCAFF0E94796B7C2894ED9F266045916D8@esebe103.NOE.Nokia.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] augment clarification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org wrote: > > Hi , > > Martin Bjorklund mbj@tail-f.com> wrote: > > You're right, but I don't think this is specific to a choice with a > > default case. It applies to all cases in a choice. We need to > > clarify that augment MUST NOT add any mandatory nodes (i.e. mandatory > > leaf, list or leaf-list w/ min-elements > 0 etc). > > Doesn't this apply to also to augmentations of list, container etc? Yes it does. > > The idea behind this is that an augment must not break a client that > > doesn't understand the augmentation. Such a client will never be able > > to add the mandatory nodes... > > > > Exactly. > So I think that this is a useful restriction - as it > allows to focus on a data tree as originally defined > in the original module. Ok, I will try to clarify this in the text. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 12:30:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3D53A68B1; Mon, 11 Aug 2008 12:30:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A633A6A96 for ; Mon, 11 Aug 2008 12:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu4qV9z6T-NH for ; Mon, 11 Aug 2008 12:30:20 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 252223A68B1 for ; Mon, 11 Aug 2008 12:30:20 -0700 (PDT) Received: (qmail 69763 invoked from network); 11 Aug 2008 19:30:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 19:30:18 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A09348.7090604@netconfcentral.com> Date: Mon, 11 Aug 2008 12:30:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.085516.193230054.mbj@tail-f.com> <46DCD7DCAFF0E94796B7C2894ED9F266045916D8@esebe103.NOE.Nokia.com> <20080811.203407.208282771.mbj@tail-f.com> In-Reply-To: <20080811.203407.208282771.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] augment clarification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > wrote: >> Hi , >> >> Martin Bjorklund mbj@tail-f.com> wrote: >>> You're right, but I don't think this is specific to a choice with a >>> default case. It applies to all cases in a choice. We need to >>> clarify that augment MUST NOT add any mandatory nodes (i.e. mandatory >>> leaf, list or leaf-list w/ min-elements > 0 etc). >> Doesn't this apply to also to augmentations of list, container etc? > > Yes it does. > >>> The idea behind this is that an augment must not break a client that >>> doesn't understand the augmentation. Such a client will never be able >>> to add the mandatory nodes... >>> >> Exactly. >> So I think that this is a useful restriction - as it >> allows to focus on a data tree as originally defined >> in the original module. > > Ok, I will try to clarify this in the text. > It was never clear to me that was the case, but it seems OK. If you need to add any mandatory leafs you should start over instead of breaking the original data structure for existing managers. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 11 22:28:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E3E3A6843; Mon, 11 Aug 2008 22:28:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B9C3A6853; Mon, 11 Aug 2008 22:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpZlme8rGDuU; Mon, 11 Aug 2008 22:28:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C905A3A6843; Mon, 11 Aug 2008 22:28:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B95E6C0026; Tue, 12 Aug 2008 07:27:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oXLXWb1gsl9J; Tue, 12 Aug 2008 07:27:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97819C0009; Tue, 12 Aug 2008 07:27:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 429716850C0; Tue, 12 Aug 2008 07:27:43 +0200 (CEST) Date: Tue, 12 Aug 2008 07:27:43 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080812052743.GA9044@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , opsawg@ietf.org, netmod@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: opsawg@ietf.org, netmod@ietf.org Subject: Re: [netmod] [OPSAWG] InetAddress in http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes -10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 11, 2008 at 03:25:44PM +0200, Romascanu, Dan (Dan) wrote: > FYI, and somehow related with OPSAWG (and NETMOD) discussions we had in > Dublin. The Internet-Draft > http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-10. > txt which is on the agenda of this week IESG telechat for approval as > Proposed Standard defines an XML representation of InetAddress as part > of the definition of a data model for traceroute results. I don't think this document tries to provide an XML representation of RFC4001's InetAddress. As stated in section 5.1, the document only imports "allowed values" but then pretty much changes InetAddress semantics to fit the specific needs of this document. Whether the IP address pattern are correct I can't tell; it seems they are different from what is found in other places. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 05:36:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3753A67E5; Tue, 12 Aug 2008 05:36:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAD03A6A28 for ; Tue, 12 Aug 2008 05:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1Xu+4y3dmyP for ; Tue, 12 Aug 2008 05:36:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6E0263A67E5 for ; Tue, 12 Aug 2008 05:36:10 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8B0F920D89; Tue, 12 Aug 2008 14:35:34 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-5d-48a183961042 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 75CA7208FB; Tue, 12 Aug 2008 14:35:34 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 14:35:16 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 14:35:16 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 12 Aug 2008 14:35:15 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808121435.15930.david.partain@ericsson.com> X-OriginalArrivalTime: 12 Aug 2008 12:35:16.0084 (UTC) FILETIME=[DF7C6B40:01C8FC77] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, At the recent IETF, there seemed to be strong consensus for having an interim meeting SINCE we have an aggressive timeline we ARE going to meet. We have a tentative host near Washington, D.C, but please don't book your tickets yet... I'll send out mail when everything is confirmed. Just to confirm that consensus on the mailing list, let me ask a few questions: Who supports having an interim on 8 - 10 October? Who is opposed to such an interim? It might be nice to know why, in this case. I doubt seriously there will be the possibility of remote participation. Combining 20 people sitting in a room around a whiteboard with a teleconference seems like an impossible combination. To get some idea of how big the facilities need to be, I need to know about attendance figures. Please respond (directly to me, not the list) and tell me: - You will attend - You will probably attend http://tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 will be used to keep information about the interim, including venue, recommended hotel(s), agenda, attendee list, and so on. There's nothing there yet... Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 05:39:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1A33A6A5B; Tue, 12 Aug 2008 05:39:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56CE3A6A40 for ; Tue, 12 Aug 2008 05:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ4LFZdXv0yi for ; Tue, 12 Aug 2008 05:39:22 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 136D73A6A5B for ; Tue, 12 Aug 2008 05:39:22 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4103776C423; Tue, 12 Aug 2008 14:39:09 +0200 (CEST) Date: Tue, 12 Aug 2008 14:39:05 +0200 (CEST) Message-Id: <20080812.143905.240452490.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200808121435.15930.david.partain@ericsson.com> References: <200808121435.15930.david.partain@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Who supports having an interim on 8 - 10 October? I support this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 06:23:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CCF3A6780; Tue, 12 Aug 2008 06:23:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C5D3A6780 for ; Tue, 12 Aug 2008 06:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS--LbP0juuV for ; Tue, 12 Aug 2008 06:23:41 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 003083A6A59 for ; Tue, 12 Aug 2008 06:23:40 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 06:21:39 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 06:21:43 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 06:21:42 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 06:21:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7CDLKu91281; Tue, 12 Aug 2008 06:21:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7CDI1L4006702; Tue, 12 Aug 2008 13:18:01 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808121318.m7CDI1L4006702@idle.juniper.net> To: David Partain In-reply-to: <200808121435.15930.david.partain@ericsson.com> Date: Tue, 12 Aug 2008 09:18:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Aug 2008 13:21:21.0221 (UTC) FILETIME=[4FA2D750:01C8FC7E] Cc: netmod@ietf.org Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain writes: >Who supports having an interim on 8 - 10 October? I support it and will attend. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 07:14:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191603A697B; Tue, 12 Aug 2008 07:14:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4A33A6A1C for ; Tue, 12 Aug 2008 07:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9Nl8Ha0rwpO for ; Tue, 12 Aug 2008 07:14:19 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 8E36C3A68F8 for ; Tue, 12 Aug 2008 07:14:18 -0700 (PDT) Received: (qmail 93014 invoked from network); 12 Aug 2008 14:14:02 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 12 Aug 2008 14:14:02 -0000 Message-ID: <04E36EC28B6544DB838572E53B2CD3A8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "David Partain" , "Phil Shafer" References: <200808121318.m7CDI1L4006702@idle.juniper.net> In-Reply-To: <200808121318.m7CDI1L4006702@idle.juniper.net> Date: Tue, 12 Aug 2008 16:05:44 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000 Cc: netmod@ietf.org Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I support it but will not be able to participate. Bert ----- Original Message ----- From: "Phil Shafer" To: "David Partain" Cc: Sent: Tuesday, August 12, 2008 3:18 PM Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 > David Partain writes: >>Who supports having an interim on 8 - 10 October? > > I support it and will attend. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 08:27:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3593A6A46; Tue, 12 Aug 2008 08:27:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2FD3A6B18 for ; Tue, 12 Aug 2008 08:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PA9P+aZHGXv for ; Tue, 12 Aug 2008 08:26:59 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 991003A6924 for ; Tue, 12 Aug 2008 08:26:57 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7CFQhc9000661 for ; Tue, 12 Aug 2008 18:26:58 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 18:26:57 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 18:26:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 18:26:46 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F26604591C90@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: Acj8j9TRe5e/CypwTvy3qhxdtwSe3w== From: To: X-OriginalArrivalTime: 12 Aug 2008 15:26:46.0680 (UTC) FILETIME=[D528C180:01C8FC8F] X-Nokia-AV: Clean Subject: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1180340167==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --===============1180340167== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FC8F.D5115EEE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FC8F.D5115EEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 in the Friday session of NETMOD WG, I proposed to=20 support the concept of augmentable groupings.=20 module A {=20 grouping concept {=20 ...=20 }.=20 }=20 module B {=20 import A {prefix a;}=20 augment a:/concept {=20 ...=20 }=20 }=20 In particular that would mean:=20 - A groupings can be the target (node) of an=20 augment statement.=20 - Augmentation of a grouping becomes only effective in case the module containing the augment statement is advertized. - The nodes added to the grouping are therefore=20 implicitly added to all places the grouping is used=20 in the set of modules supported by an agent. - The augmented nodes are in the XML namespace=20 of the module of the augment statement.=20 For example assume a module for providing a reusable=20 definition of network interface parameters=20 module Interfaces {=20 grouping NetworkInterface {=20 leaf ifName {type string;} leaf ifDescription {type DisplayString;} leaf ifMtu {type int32;} // . . . leaf ifSpeed {type Gauge;} leaf ifInOctets {type Counter;}=20 // . . . } =20 which is then used to define one or more interface=20 lists (tables).=20 If now high capacity support should be added=20 consistently, this could be done by augmenting=20 this group with HC attributes:=20 module HCSupport { import NetworkInterfaces {prefix if; }=20 augment /if:NetworkInterface { leaf ifHCInOctets {type Counter64;} leaf ifHCOutOctets {type Counter64;} // . . }=20 }=20 Of course, the module HCSupport should only be used and advertized if HC support is available for all interfaces controlled by the advertizing agent. There are different benefits of augmentable=20 groupings: - Supports consistent and YANG-like extension=20 of a grouping by using an existing language=20 construct, i.e. it provides additional capabilities=20 without introducing new keywords.=20 - Augmentable groupings maximize re-use of=20 model code. In that sense augmentable=20 groupings introduce a modeling mechanism,=20 which is based on "true re-use" and is=20 technically better compared to the existing=20 grouping concept, which requires copying=20 and pasting augmentation many times.=20 - When combined with the when statement,=20 augmentable groupings even allow selective,=20 content based augmentation in a consistent=20 manner.=20 - Augmentable groupings adopt every benefit=20 but also obstacle of augmentations in the YANG=20 language. As it already has been suggested by=20 Martin B., we would like propose that an augment=20 MUST NOT add any mandatory nodes (i.e.=20 mandatory leaf, list or leaf-list w/ min-elements > 0=20 etc). An augment must not break a client that=20 doesn't understand the augmentation. - Augmenting all places where a grouping is used is error-prone and causes unnecessary development costs. The problem is actually worse than this.=20 When someone writes an extension module,=20 he/she might not know all places where the grouping must be augmented. BR, Bernd ------_=_NextPart_001_01C8FC8F.D5115EEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [netmod] Augmentable Groupings

Hi All, =

in the Friday session = of NETMOD WG, I proposed to
support the concept = of augmentable groupings.

module A { =
  grouping = concept {
    = ...
  }. =
}

module B { =
  import A = {prefix a;}
  augment = a:/concept {
    = ...
  } =
}

In particular that = would mean:

- A groupings can be = the target (node) of an
  augment = statement.
- Augmentation of a = grouping becomes only effective
  in case the = module containing the augment statement
  is = advertized.
- The nodes added to = the grouping are therefore
  implicitly = added to all places the grouping is used
  in the set of = modules supported by an agent.
- The augmented = nodes are in the XML namespace
  of the module = of the augment statement.


For example assume a = module for providing a reusable
definition of = network interface parameters

module Interfaces { =
  grouping = NetworkInterface {

    = leaf ifName {type string;}
    = leaf ifDescription {type DisplayString;}
    = leaf ifMtu {type int32;}
    = // . . .
    = leaf ifSpeed {type Gauge;}
    = leaf ifInOctets {type Counter;}
    = // . . .
 }
 
which is then used = to define one or more interface
lists (tables). =
If now high capacity = support should be added
consistently, this = could be done by augmenting
this group with HC = attributes:

module HCSupport = {
  import = NetworkInterfaces {prefix if; }
  augment = /if:NetworkInterface {
    = leaf ifHCInOctets {type Counter64;}
    = leaf ifHCOutOctets {type Counter64;}
    = // . .
   } =
}

Of course, the module = HCSupport should only
be used and = advertized if HC support
is available for all = interfaces controlled
by the advertizing = agent.

There are different = benefits of augmentable
groupings:

- Supports consistent = and YANG-like extension
  of a grouping = by using an existing language
  construct, = i.e. it provides additional capabilities
  without = introducing new keywords.

- Augmentable = groupings maximize re-use of
  model code. = In that sense augmentable
  groupings = introduce a modeling mechanism,
  which is = based on "true re-use" and is
  technically = better compared to the existing
  grouping = concept, which requires copying
  and pasting = augmentation many times.

- When combined with = the when statement,
  augmentable = groupings even allow selective,
  content based = augmentation in a consistent
  manner. =

- Augmentable = groupings adopt every benefit
  but also = obstacle of augmentations in the YANG
  language. As = it already has been suggested by
  Martin B., we = would like propose that an augment
  MUST NOT add = any mandatory nodes (i.e.
  mandatory = leaf, list or leaf-list w/ min-elements > 0
  etc). An = augment must not break a client that
  doesn't = understand the augmentation.

- Augmenting all = places where a grouping is used
  is = error-prone and causes unnecessary development
  = costs.
  The problem = is actually worse than this.
  When someone = writes an extension module,
  he/she might = not know all places where the
  grouping must = be augmented.

BR,
Bernd

------_=_NextPart_001_01C8FC8F.D5115EEE-- --===============1180340167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============1180340167==-- From netmod-bounces@ietf.org Tue Aug 12 08:50:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802333A6B6E; Tue, 12 Aug 2008 08:50:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28DF3A6B6E for ; Tue, 12 Aug 2008 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ5UTlODl1Lb for ; Tue, 12 Aug 2008 08:50:12 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 562203A6B6F for ; Tue, 12 Aug 2008 08:50:12 -0700 (PDT) Received: (qmail 34520 invoked from network); 12 Aug 2008 15:50:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2008 15:50:13 -0000 X-YMail-OSG: f2627nYVM1kNDifNfm7hy8RM1nP6CJoxMcZ1uWY7HUc6lLi5L9RxSSl09p8eQ1JpngW17_AXsKKhhV9v69oo4HzAe8SBqfNBjuB8MYPwZd_vmXMDcibbOkvQ16e7rfE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A1B134.9000601@netconfcentral.com> Date: Tue, 12 Aug 2008 08:50:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: bernd.linowski.ext@nsn.com References: <46DCD7DCAFF0E94796B7C2894ED9F26604591C90@esebe103.NOE.Nokia.com> In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F26604591C90@esebe103.NOE.Nokia.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org bernd.linowski.ext@nsn.com wrote: > > Hi All, > > in the Friday session of NETMOD WG, I proposed to > support the concept of augmentable groupings. > > module A { > grouping concept { > ... > }. > } > > module B { > import A {prefix a;} > augment a:/concept { Actually groupings are not in the same namespace as objects, so this Xpath is broken. grouping foo; container foo; Both of these are legal YANG. > ... > } > } > If I nest the groupings, then what happens to the augment: module C { grouping new-concepts { uses concepts; } Does new-concepts contain the augmentations from concepts? How is somebody reading 'uses C:new-concepts;' in module D know if this is augmented or not? What if I want to use the 'concept' grouping with the augment and sometimes without it in the same system? Advertising module B means that every use of concepts is now augmented. What if some existing 'uses concepts;' statements do not support the new nodes? There are also conformance issues, depending on what the WG does about 'if-feature' and capabilities documentation. How is a YANG compiler supposed to know that M of N modules will be augmenting groupings in other modules, which changes the uses expansion in all the modules. Do you think the compiler is going to 'redo' N-1 modules, as it processes the Nth module? Have you implemented this feature in a complete NETCONF system? I am not convinced it is even implementable, let alone deployable. IMO, this approach has more unintended consequences than benefits. Andy > In particular that would mean: > > - A groupings can be the target (node) of an > augment statement. > - Augmentation of a grouping becomes only effective > in case the module containing the augment statement > is advertized. > - The nodes added to the grouping are therefore > implicitly added to all places the grouping is used > in the set of modules supported by an agent. > - The augmented nodes are in the XML namespace > of the module of the augment statement. > > > For example assume a module for providing a reusable > definition of network interface parameters > > module Interfaces { > grouping NetworkInterface { > > leaf ifName {type string;} > leaf ifDescription {type DisplayString;} > leaf ifMtu {type int32;} > // . . . > leaf ifSpeed {type Gauge;} > leaf ifInOctets {type Counter;} > // . . . > } > > which is then used to define one or more interface > lists (tables). > If now high capacity support should be added > consistently, this could be done by augmenting > this group with HC attributes: > > module HCSupport { > import NetworkInterfaces {prefix if; } > augment /if:NetworkInterface { > leaf ifHCInOctets {type Counter64;} > leaf ifHCOutOctets {type Counter64;} > // . . > } > } > > Of course, the module HCSupport should only > be used and advertized if HC support > is available for all interfaces controlled > by the advertizing agent. > > There are different benefits of augmentable > groupings: > > - Supports consistent and YANG-like extension > of a grouping by using an existing language > construct, i.e. it provides additional capabilities > without introducing new keywords. > > - Augmentable groupings maximize re-use of > model code. In that sense augmentable > groupings introduce a modeling mechanism, > which is based on "true re-use" and is > technically better compared to the existing > grouping concept, which requires copying > and pasting augmentation many times. > > - When combined with the when statement, > augmentable groupings even allow selective, > content based augmentation in a consistent > manner. > > - Augmentable groupings adopt every benefit > but also obstacle of augmentations in the YANG > language. As it already has been suggested by > Martin B., we would like propose that an augment > MUST NOT add any mandatory nodes (i.e. > mandatory leaf, list or leaf-list w/ min-elements > 0 > etc). An augment must not break a client that > doesn't understand the augmentation. > > - Augmenting all places where a grouping is used > is error-prone and causes unnecessary development > costs. > The problem is actually worse than this. > When someone writes an extension module, > he/she might not know all places where the > grouping must be augmented. > > BR, > Bernd > > > ------------------------------------------------------------------------ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 09:17:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78ECF3A67DB; Tue, 12 Aug 2008 09:17:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8953E28C199 for ; Tue, 12 Aug 2008 09:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcFGX8oxfLbz for ; Tue, 12 Aug 2008 09:17:16 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id D96623A6A5F for ; Tue, 12 Aug 2008 09:16:48 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA05474 for ; Tue, 12 Aug 2008 12:16:15 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA04554 for ; Tue, 12 Aug 2008 12:16:15 -0400 (EDT) Message-Id: <200808121616.MAA04554@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Tue, 12 Aug 2008 14:35:15 +0200. <200808121435.15930.david.partain@ericsson.com> Date: Tue, 12 Aug 2008 12:16:14 -0400 Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > Who supports having an interim on 8 - 10 October? I support this and will probably attend. -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 09:52:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D1D3A67FE; Tue, 12 Aug 2008 09:52:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70D73A6818 for ; Tue, 12 Aug 2008 09:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JixVHLKJ6ydv for ; Tue, 12 Aug 2008 09:52:43 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id EEAA43A67FE for ; Tue, 12 Aug 2008 09:52:42 -0700 (PDT) Received: (qmail 19737 invoked from network); 12 Aug 2008 16:52:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2008 16:52:38 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A1BFD4.6000903@netconfcentral.com> Date: Tue, 12 Aug 2008 09:52:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Partain References: <200808121435.15930.david.partain@ericsson.com> In-Reply-To: <200808121435.15930.david.partain@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Hi, > > At the recent IETF, there seemed to be strong consensus for having an interim > meeting SINCE we have an aggressive timeline we ARE going to meet. We have a > tentative host near Washington, D.C, but please don't book your tickets > yet... I'll send out mail when everything is confirmed. > > Just to confirm that consensus on the mailing list, let me ask a few > questions: > > Who supports having an interim on 8 - 10 October? > I support the interim and will attend. > Who is opposed to such an interim? It might be nice to know why, in this > case. > > I doubt seriously there will be the possibility of remote participation. > Combining 20 people sitting in a room around a whiteboard with a > teleconference seems like an impossible combination. > We could look into an audio feed via SHOUTcast, etc. and run jabber. (No better or worse remote participation support than a real IETF.) > To get some idea of how big the facilities need to be, I need to know about > attendance figures. Please respond (directly to me, not the list) and tell > me: > > - You will attend > - You will probably attend > > http://tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 will be used to keep > information about the interim, including venue, recommended hotel(s), agenda, > attendee list, and so on. There's nothing there yet... > > Cheers, > > David Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 10:24:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BBF3A6B7A; Tue, 12 Aug 2008 10:24:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995B03A6BCE for ; Tue, 12 Aug 2008 10:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-Ehk1y+Wlvy for ; Tue, 12 Aug 2008 10:24:34 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 8E8FC3A67FE for ; Tue, 12 Aug 2008 10:24:34 -0700 (PDT) X-Trace: 12636479/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.136.14 X-SBRS: None X-RemoteIP: 62.188.136.14 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAGVkoUg+vIgO/2dsb2JhbACDQTWHaqUzA4Em X-IronPort-AV: E=Sophos;i="4.32,196,1217804400"; d="scan'208";a="12636479" X-IP-Direction: IN Received: from 1cust14.tnt7.lnd4.gbr.da.uu.net (HELO allison) ([62.188.136.14]) by smtp.pipex.tiscali.co.uk with SMTP; 12 Aug 2008 18:24:28 +0100 Message-ID: <003701c8fc97$001b27a0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <1218025449.6297.87.camel@missotis> <4899DAFE.4070203@netconfcentral.com> Date: Tue, 12 Aug 2008 16:49:12 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Andy Bierman" Sent: Wednesday, August 06, 2008 7:10 PM Subject: Re: [netmod] when statement > > IMO, this WG needs to start looking at the big picture, > and decide how big problems are solved within YANG. > Tweaking the clauses without any shared understanding > of the 'workings of YANG' is too bottom-up to succeed > in a design-by-committee environment. > +1 (and +1 to all the times Andy has raised something similar). Bottom-up detailed design can and does produce a viable system that can be implemented and deployed. But lacking an internal coherence, it will be harder to understand, harder to learn, harder to get right both for users and implementers of tools (see XML:-(. Tom Petch > I have serious concerns about the standards value of YANG, > especially if it has a nested conditional block, based > on arbitrary values within the running configuration. > > The IETF has experience with static module definitions > which are partitioned into groups of objects, and conformance > based on implementation of specific groups within the module. > > This simplistic approach is deterministic, static, > and inter-operable. Combining 'when', 'must', 'augment' > and 'uses' in arbitrary ways is not proven at all. > > > Lada > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 11:04:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BAC3A68A7; Tue, 12 Aug 2008 11:04:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062043A69A2 for ; Tue, 12 Aug 2008 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ImpoVGPjIe5 for ; Tue, 12 Aug 2008 11:04:52 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 4535A3A68A7 for ; Tue, 12 Aug 2008 11:04:52 -0700 (PDT) Received: (qmail 13115 invoked from network); 12 Aug 2008 18:04:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2008 18:04:53 -0000 X-YMail-OSG: Hq.xjL4VM1mVhyw8FfHDlbqP8jcWvJWETq5f4FzviHCP8mf_Gn6WYbYKIfcX85XVlp8tXFv1FsYsd30ngZrpZQyO321Qer5_UcSq6zFJww-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A1D0C3.8060503@netconfcentral.com> Date: Tue, 12 Aug 2008 11:04:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808110434.m7B4Y1jS094679@idle.juniper.net> In-Reply-To: <200808110434.m7B4Y1jS094679@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> How is a feature associated with a capability in machine-readable >> format? How does an application automatically learn this hierarchy >> definition and its usage within the entire module set? > > A new rpc will be defined that accepts a namespace and returns the > features that are implemented for the module with that namespace. > The application performs this RPC and learns from the device which > features are supported. Do you mean capability URI or namespace URI? So when I read the YANG module, I have no idea what features are defined as part of what (completely unspecified) capabilities? I have to get the agent capabilities at run-time, and then call this new RPC method, and then match up features to the undocumented capabilities? I have doubts about the standards value to DM readers of this approach. This assumes a rather generalized conformance model that addresses the feature partitioning aspect only. Every little detail that a WG decides is optional will potentially become its own 'feature'. SMIv2 experience with conformance issues goes back a couple decades. A SMIv2 GROUP is stable forever, and one can always tell what is supposed to be implemented, and how the conformance requirements changed over time. The most common variant is of course 'MIN-ACCESS read-only', which is not handled well by this YANG approach at all. Other common variants include the SYNTAX clause to make some enums optional (e.g., 'ipv6' or 'dns' in InetAddressType objects). These variants are likely to occur anywhere, not just within optional chunks partitioned by capabilities. Most importantly, SMIv2 provides a small number of conformance variants, which can be implemented in an inter-operable manner. The YANG approach potentially leads to dozens of undocumented permutations per module. This is a burden on manager applications that have to support multiple agent platforms, and have no idea which permutations to expect in advance. I am not convinced at all that the YANG approach of scattered if-feature statements, attached to undocumented capabilities, plus augment/uses complexities, will actually support an ever-growing pool of IETF YANG modules. It can be difficult to figure out exactly what to implement the day the module is published. As potentially all the modules change over time, it becomes nearly impossible. > > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 12:00:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5EC28C243; Tue, 12 Aug 2008 12:00:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCCF28C213 for ; Tue, 12 Aug 2008 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE6ztMLggftT for ; Tue, 12 Aug 2008 11:59:57 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 4195728C0E1 for ; Tue, 12 Aug 2008 11:59:55 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 11:58:55 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 11:58:43 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 11:58:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 11:58:42 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7CIwgu02044; Tue, 12 Aug 2008 11:58:42 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7CItMd2009055; Tue, 12 Aug 2008 18:55:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808121855.m7CItMd2009055@idle.juniper.net> To: Andy Bierman In-reply-to: <48A1D0C3.8060503@netconfcentral.com> Date: Tue, 12 Aug 2008 14:55:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Aug 2008 18:58:42.0851 (UTC) FILETIME=[70967730:01C8FCAD] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Do you mean capability URI or namespace URI? They are identical. The YANG module defines a unique namespace which is associated with that module. Devices that implement that module will announce that namespace as a capability via their hello message and the data model discovery mechanism. If an application knows a device implements a module and is interesting in learning which optional feature are implement, the application performs this new RPC, passing in the namespace and receiving the list of features in return. >So when I read the YANG module, I have no idea what features >are defined as part of what (completely unspecified) capabilities? When you read the module, you learn which pieces of the model the modeler has designated as optional. These optional pieces are grouped together into well-defined sets that are meaningful to the modeler. For example, the IPFIX model defines a number of roles which devices can perform. If your device is a collector, you have configuration nodes associated with that specific role which an application can configure. If your device does not support this role, no one can ask you to perform that role and any attempt to configure your device as a collector is doomed to failure. When an application contacts a device, it learns which roles are supported and behaves accordingly. >This assumes a rather generalized conformance model that addresses >the feature partitioning aspect only. Every little detail that >a WG decides is optional will potentially become its own 'feature'. There is nothing to prevent the rampant use of the "feature" feature to turn a model into an unreadable mountain of goo. The control of this tool is given to the modeler, and they can use it for good or for evil. As mentioned before, this is nothing that cannot be accomplished today in YANG via multiple modules and multiple namespaces, but the interactions between the modules is less clear. The "feature" feature adds a hiearchy to our solution (namespace/feature) and allows the modeler to put all the elements of the model within a single module. This is most important if the features affect a number of nodes that are not adjacent within the YANG module. It is much more obvious to tag "one", "two", and "three" with "if-feature one-two-three" than define a new module that augments the appropriate parents to add these nodes. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 12:01:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3473A6934; Tue, 12 Aug 2008 12:01:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356E83A6934 for ; Tue, 12 Aug 2008 12:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9stJIef-5maD for ; Tue, 12 Aug 2008 12:01:05 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id 563293A6ADB for ; Tue, 12 Aug 2008 12:01:01 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob62.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 11:59:46 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 12:00:00 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 11:59:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 11:59:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7CIxwu02417; Tue, 12 Aug 2008 11:59:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7CIudXm009073; Tue, 12 Aug 2008 18:56:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808121856.m7CIudXm009073@idle.juniper.net> To: "tom.petch" In-reply-to: <003701c8fc97$001b27a0$0601a8c0@allison> Date: Tue, 12 Aug 2008 14:56:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Aug 2008 18:59:59.0429 (UTC) FILETIME=[9E3B5750:01C8FCAD] Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "tom.petch" writes: >Bottom-up detailed design can and does produce a viable system that can be >implemented and deployed. But lacking an internal coherence, it will be harder >to understand, harder to learn, harder to get right both for users and >implementers of tools (see XML:-(. Are we not doing enough to communicate the "Zen of YANG"? Or are you feeling that there's no zen here at all? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 12:22:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7142C3A68CA; Tue, 12 Aug 2008 12:22:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1073A68CA for ; Tue, 12 Aug 2008 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65zXzcemuKAO for ; Tue, 12 Aug 2008 12:22:40 -0700 (PDT) Received: from chip3mo2-old.postini.com (chip3mo2-old.postini.com [64.18.14.205]) by core3.amsl.com (Postfix) with ESMTP id 046053A6A5F for ; Tue, 12 Aug 2008 12:22:31 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob64.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 12:21:45 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 12:09:50 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 12:09:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 12:09:49 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7CJ9nu06788; Tue, 12 Aug 2008 12:09:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7CJ6TCk009270; Tue, 12 Aug 2008 19:06:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808121906.m7CJ6TCk009270@idle.juniper.net> To: bernd.linowski.ext@nsn.com In-reply-to: <46DCD7DCAFF0E94796B7C2894ED9F26604591C90@esebe103.NOE.Nokia.com> Date: Tue, 12 Aug 2008 15:06:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Aug 2008 19:09:49.0429 (UTC) FILETIME=[FDE63250:01C8FCAE] Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org bernd.linowski.ext@nsn.com writes: > The problem is actually worse than this. > When someone writes an extension module, > he/she might not know all places where the > grouping must be augmented. The reverse is also true, and I think this is the problem with this proposal. When you augment a grouping, you have no idea who has used it and what havoc you are wrecking on those other users. Imagine the case where I have taken your NetworkInterface grouping and used it in a list of low speed interfaces: list slow-dudes { use NetworkInterface; leaf how-slow { type enumeration { enum very-slow { ... } enum horribly-slow { ... } enum 2g { ... } } } } When you augment NetworkInterface in your module, I suddenly get your ifHCIn/OutOctets leafs, which are completely inappropriate. I can't turn them off and I can't tell nm apps "hey he didn't mean my list". Sure, I can choose not to implement/announce your module, but if both slow-dudes and HCSupport are IETF standards, I'm stuck. I see the attraction of "say it once and it happens everywhere", but the down side far overways the benefit. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 13:10:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA5F28C14A; Tue, 12 Aug 2008 13:10:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E369328C14B for ; Tue, 12 Aug 2008 13:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CrA9dCqDNX2 for ; Tue, 12 Aug 2008 13:10:31 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id E91E528C14A for ; Tue, 12 Aug 2008 13:10:30 -0700 (PDT) Received: (qmail 59468 invoked from network); 12 Aug 2008 20:10:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2008 20:10:20 -0000 X-YMail-OSG: i4sNWJ8VM1mXUAvLlXyzLMyWOlDKWfpiewr.GcR_8MJMMylkVcAUv6NIkPz55UJH3YrVS2c0TXbXS0Ew4AuOmm5xKprrBMazQOEdbjmUrg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A1EE2A.1070602@netconfcentral.com> Date: Tue, 12 Aug 2008 13:10:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808121855.m7CItMd2009055@idle.juniper.net> In-Reply-To: <200808121855.m7CItMd2009055@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Do you mean capability URI or namespace URI? > > They are identical. The YANG module defines a unique namespace > which is associated with that module. oops -- I misunderstood (A major downside of email). I thought there would be the ability for data modelers to define arbitrary protocol capabilities, like in RFC 4741. Since the module itself is the one and only protocol capability allowed for the data model, then this 'feature' idea is more tractable. It still does not support the most common feature: r/o vs. r/w. container foo-service { presence "Enables the foo service if present."; if-feature write-foo-service { config true; } else { config false; } // leafs ... } This is going to be needed, but the 'if-feature' approach is going to be just as complicated as the MIN-ACCESS approach, and not nearly as intuitive. (But I'm familiar with SMIv2, so that biases what seems intuitive to me.) WGs often cannot decide that every single code point knob in their protocol must be controlled in a standard way, even if they agree everybody must provide the same read-only implementation of that knob. That's the reality that YANG has to deal with. Andy Devices that implement that > module will announce that namespace as a capability via their hello > message and the data model discovery mechanism. If an application > knows a device implements a module and is interesting in learning > which optional feature are implement, the application performs this > new RPC, passing in the namespace and receiving the list of features > in return. > >> So when I read the YANG module, I have no idea what features >> are defined as part of what (completely unspecified) capabilities? > > When you read the module, you learn which pieces of the model the > modeler has designated as optional. These optional pieces are > grouped together into well-defined sets that are meaningful to the > modeler. > > For example, the IPFIX model defines a number of roles which devices > can perform. If your device is a collector, you have configuration > nodes associated with that specific role which an application can > configure. If your device does not support this role, no one can > ask you to perform that role and any attempt to configure your > device as a collector is doomed to failure. When an application > contacts a device, it learns which roles are supported and behaves > accordingly. > >> This assumes a rather generalized conformance model that addresses >> the feature partitioning aspect only. Every little detail that >> a WG decides is optional will potentially become its own 'feature'. > > There is nothing to prevent the rampant use of the "feature" feature > to turn a model into an unreadable mountain of goo. The control > of this tool is given to the modeler, and they can use it for good > or for evil. > > As mentioned before, this is nothing that cannot be accomplished > today in YANG via multiple modules and multiple namespaces, but the > interactions between the modules is less clear. The "feature" > feature adds a hiearchy to our solution (namespace/feature) and > allows the modeler to put all the elements of the model within a > single module. This is most important if the features affect a > number of nodes that are not adjacent within the YANG module. It > is much more obvious to tag "one", "two", and "three" with "if-feature > one-two-three" than define a new module that augments the appropriate > parents to add these nodes. > > Thanks, > Phil > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 13:28:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2AA3A68CA; Tue, 12 Aug 2008 13:28:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55CB3A68CA for ; Tue, 12 Aug 2008 13:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMn+BhURIWPc for ; Tue, 12 Aug 2008 13:28:49 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 2B1013A68E6 for ; Tue, 12 Aug 2008 13:28:49 -0700 (PDT) Received: (qmail 31801 invoked from network); 12 Aug 2008 20:28:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2008 20:28:48 -0000 X-YMail-OSG: rTeNYZIVM1nh1JRhT.xcqk1.XDFweno1hnrs8SJmSErVYE8l9bK.kXrSqxrKzikqhi_kSMY5qeMs42L_chNHHgTFn7H1ItgBAuvZQ4gkxw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A1F27D.90203@netconfcentral.com> Date: Tue, 12 Aug 2008 13:28:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808121855.m7CItMd2009055@idle.juniper.net> <48A1EE2A.1070602@netconfcentral.com> In-Reply-To: <48A1EE2A.1070602@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> Do you mean capability URI or namespace URI? >> >> They are identical. The YANG module defines a unique namespace >> which is associated with that module. > > oops -- I misunderstood (A major downside of email). > I thought there would be the ability for data modelers > to define arbitrary protocol capabilities, like in RFC 4741. > > Since the module itself is the one and only protocol capability > allowed for the data model, then this 'feature' idea is more > tractable. > > It still does not support the most common feature: r/o vs. r/w. > > > container foo-service { > presence "Enables the foo service if present."; > if-feature write-foo-service { > config true; > } else { > config false; > } > // leafs ... > } > I think min-access addresses a separate problem than partitioning a module into features. Perhaps both are needed. Sharon likes in-line min-access, which may be better than nothing (compared to full-blown SMIv2-style conformance). E.g.: (?) container ping-service { presence "Enables the PING service if present."; if-feature "exec-services" config true; min-access { config false; // maybe the WG agrees how to report a PING service knob // but does not agree everybody must support standard config // editing via NETCONF for every knob. // this would likely appear in individual leafs, not a container } // leafs ... } The alternative is to create 'read-only-exec-services' and 'exec-services' and have 2 separate containers, 1 a clone of the other. (ping-service and ping-service-ro). We MUST avoid this type of definition duplication. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 13:52:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2B73A63EC; Tue, 12 Aug 2008 13:52:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CA63A68E6 for ; Tue, 12 Aug 2008 13:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO0l1x5sIIr6 for ; Tue, 12 Aug 2008 13:52:19 -0700 (PDT) Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id B132C3A63EC for ; Tue, 12 Aug 2008 13:52:18 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob61.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 13:52:14 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 13:51:42 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 13:51:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 13:46:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7CKkiu64575; Tue, 12 Aug 2008 13:46:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7CKhPcK010151; Tue, 12 Aug 2008 20:43:25 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808122043.m7CKhPcK010151@idle.juniper.net> To: Andy Bierman In-reply-to: <48A1F27D.90203@netconfcentral.com> Date: Tue, 12 Aug 2008 16:43:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 Aug 2008 20:46:45.0085 (UTC) FILETIME=[884CE0D0:01C8FCBC] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: > container ping-service { > presence "Enables the PING service if present."; > if-feature "exec-services" > config true; > > min-access { > config false; > // maybe the WG agrees how to report a PING service knob > // but does not agree everybody must support standard config > // editing via NETCONF for every knob. > // this would likely appear in individual leafs, not a container > } This is a great example, since it shows why if-feature matches YANG's needs better. If a device doesn't support the ping service, it need not implement the "ping-service" container, read-only or otherwise. container ping-service { if-feature allows-ping; ... } If you don't allow-ping, you don't need/want/support/grok the ping-service container at all. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 14:25:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82CF3A6897; Tue, 12 Aug 2008 14:25:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D83D3A6C4D for ; Tue, 12 Aug 2008 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtxvsKJZmwIA for ; Tue, 12 Aug 2008 14:25:11 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id E4C953A6C4A for ; Tue, 12 Aug 2008 14:25:11 -0700 (PDT) Received: (qmail 47502 invoked from network); 12 Aug 2008 21:25:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2008 21:25:13 -0000 X-YMail-OSG: YHOyEpwVM1mFOEXjr76orlenlN8XNmOMt8CjL8DjsYjOjS63Mu42qvYknUQ9qy2YNgZS4zpRSoR4mvpG9NC0otMy95hFXxL30YbElaMGRg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A1FFB7.3060105@netconfcentral.com> Date: Tue, 12 Aug 2008 14:25:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808122043.m7CKhPcK010151@idle.juniper.net> In-Reply-To: <200808122043.m7CKhPcK010151@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> container ping-service { >> presence "Enables the PING service if present."; >> if-feature "exec-services" >> config true; >> >> min-access { >> config false; >> // maybe the WG agrees how to report a PING service knob >> // but does not agree everybody must support standard config >> // editing via NETCONF for every knob. >> // this would likely appear in individual leafs, not a container >> } > > This is a great example, since it shows why if-feature matches > YANG's needs better. If a device doesn't support the ping service, > it need not implement the "ping-service" container, read-only or > otherwise. > > container ping-service { > if-feature allows-ping; > ... > } > > If you don't allow-ping, you don't need/want/support/grok the > ping-service container at all. You are probably correct in that it is extremely unlikely the entire ping service would be read-only. A much more likely usage: container ping-service { presence "Enables the PING service if present."; if-feature "ping-service"; config true; leaf target-host { description "Host to ping"; type { inet:ip-address; } } leaf ip-protocol { description "IP version used to ping the target if the target contains a DNS name."; type enumeration { enum ipv4; enum ipv6; } min-access { // you MUST report which IP version was used // write access not mandatory config false; } } leaf payload { description "Payload portion for each ICMP echo packet."; if-feature ping-service-payload; type binary; // the agent does not have to provide any access to the // PDU payload unless the addition ping-service-payload // feature is also supported } // more leafs } See how nicely both features work together? :-) (Ignore the exact min-access syntax for now and look at the concept.) > > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 19:02:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D093A69FB; Tue, 12 Aug 2008 19:02:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B7D3A67FA for ; Tue, 12 Aug 2008 19:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF5vogIIk9HF for ; Tue, 12 Aug 2008 19:02:10 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id C21B83A6767 for ; Tue, 12 Aug 2008 19:02:09 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Tue, 12 Aug 2008 19:01:41 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 19:01:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 19:01:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 18:57:44 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7D1vhu51869; Tue, 12 Aug 2008 18:57:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7D1sNq8011938; Wed, 13 Aug 2008 01:54:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808130154.m7D1sNq8011938@idle.juniper.net> To: Andy Bierman In-reply-to: <48A1FFB7.3060105@netconfcentral.com> Date: Tue, 12 Aug 2008 21:54:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2008 01:57:44.0153 (UTC) FILETIME=[F9F8B490:01C8FCE7] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: > leaf ip-protocol { > description > "IP version used to ping the target if the target > contains a DNS name."; > type enumeration { > enum ipv4; > enum ipv6; > } > min-access { > // you MUST report which IP version was used > // write access not mandatory > config false; > } > } I'm missing something. How do you "report which IP version was used" in the middle of config data? It seems like you are mixing the config to turn on a service with the data returned by using that service, which isn't appropriate. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 12 21:19:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564D73A6A07; Tue, 12 Aug 2008 21:19:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2D43A6B46 for ; Tue, 12 Aug 2008 21:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huy4gTbEa3ab for ; Tue, 12 Aug 2008 21:19:46 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 1382C3A6A07 for ; Tue, 12 Aug 2008 21:19:45 -0700 (PDT) Received: (qmail 89214 invoked from network); 13 Aug 2008 04:19:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.235 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 13 Aug 2008 04:19:47 -0000 X-YMail-OSG: 9F70OZoVM1k46uw0htEFOnOmMXji1HuTmw.xt34DSVhLicQMEiCA8AIywBQJuzxE9LrViXyXa9UNQnfSeYtMOrwhet5ZRaBJHjUCTy.GcA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A260E1.9050609@netconfcentral.com> Date: Tue, 12 Aug 2008 21:19:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808130154.m7D1sNq8011938@idle.juniper.net> In-Reply-To: <200808130154.m7D1sNq8011938@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> leaf ip-protocol { >> description >> "IP version used to ping the target if the target >> contains a DNS name."; >> type enumeration { >> enum ipv4; >> enum ipv6; >> } >> min-access { >> // you MUST report which IP version was used >> // write access not mandatory >> config false; >> } >> } > > I'm missing something. How do you "report which IP version was > used" in the middle of config data? It seems like you are mixing > the config to turn on a service with the data returned by using > that service, which isn't appropriate. SNMP mixes manager-provided config and agent-provided config all the time. NETCONF has and to distinguish between them. min-access 'config false' is not really correct. It is still config, but read-only config. Just because you can create a row in the fooTable does not automatically mean the agent allows you to select a value for every leaf in the row. Often a WG decides that it is OK (via MIN-ACCESS) for an agent to always provide a suitable value for that leaf, instead of allowing the manager to set it. This is usually what happens when an optional YANG leaf is missing from a list. The only difference is the WG deciding that it is OK for the agent to provide a valid value and not allow the manager to set the leaf at all. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 01:15:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702DA3A6809; Wed, 13 Aug 2008 01:15:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E66F3A6809 for ; Wed, 13 Aug 2008 01:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1AODJc96Oe5 for ; Wed, 13 Aug 2008 01:15:39 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 957C13A68C5 for ; Wed, 13 Aug 2008 01:15:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C72D776C040; Wed, 13 Aug 2008 10:15:41 +0200 (CEST) Date: Wed, 13 Aug 2008 10:15:43 +0200 (CEST) Message-Id: <20080813.101543.160348537.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48A1F27D.90203@netconfcentral.com> References: <200808121855.m7CItMd2009055@idle.juniper.net> <48A1EE2A.1070602@netconfcentral.com> <48A1F27D.90203@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I think min-access addresses a separate problem than > partitioning a module into features. Perhaps both are needed. Yes, and maybe it is best to wait with the min-access until yang 2.0? > Sharon likes in-line min-access I like this approach as well. But it solves just one part of the problem - it tells the module reader or client that an agent MAY implement a particular object read only. The other part of the problem is how the manager can know the real access of a particular object (ACCESS in AGENT-CAPABILITIES). I think both parts of the problem need to be solved simultaneously. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 03:00:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600B23A69B1; Wed, 13 Aug 2008 03:00:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EF128C0D6 for ; Wed, 13 Aug 2008 03:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm9QwyYQJtyv for ; Wed, 13 Aug 2008 03:00:04 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id E68B13A69B1 for ; Wed, 13 Aug 2008 03:00:03 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KTD97-000894-2p for netmod@ietf.org; Wed, 13 Aug 2008 12:00:01 +0200 Message-ID: <48A2B0C6.8020609@informatik.uni-tuebingen.de> Date: Wed, 13 Aug 2008 12:00:38 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1004118808==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1004118808== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040308060907090707060900" This is a cryptographically signed message in MIME format. --------------ms040308060907090707060900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, I'm glad to see how you are addressing problems and questions we have in the IPFIX WG. Distinguishing two capability levels (support of entire modules and support of optional features within a module) nicely solves one of our problems. Phil has already given an example (collector capability). Here is another one which stresses the advantage of features: Several packet selection methods have been standardized. A typical IPFIX device supports a couple of them. If a certain method is supported, it is configured in a standardized way. The manager should be able to query the supported selection methods. With features, we can have a single module covering the configuration data of all selection methods. The manager can query the supported selection methods (features) without getting capability information of other modules it is not interested in. The example can be extended: an IPFIX device supporting a specific selection method may allow only a limited number of Selection Processes which make use of this method, e.g. because the packet selection is performed by a blade in a router. A possible solution is to specify a readonly parameter in the DM which returns the corresponding value and to explain its meaning in the description clause. Do you have a better idea? Regards, Gerhard > Andy Bierman wrote: >> I think min-access addresses a separate problem than >> partitioning a module into features. Perhaps both are needed. > > Yes, and maybe it is best to wait with the min-access until yang 2.0? > >> Sharon likes in-line min-access > > I like this approach as well. But it solves just one part of the > problem - it tells the module reader or client that an agent MAY > implement a particular object read only. The other part of the > problem is how the manager can know the real access of a particular > object (ACCESS in AGENT-CAPABILITIES). I think both parts of the > problem need to be solved simultaneously. > > > /martin --------------ms040308060907090707060900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDgxMzEwMDAzOFowIwYJKoZIhvcNAQkEMRYEFI0eJiN4bIQx PZ+h9U7L0QU9Zg0BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBE+joT5o/piOsEQ3hzVbO5aTVydPwdVmjD3iEUjjIZhfFvCsuVMYBdFX9A pD5HOUqF7SHLGnX4/2XsUS+0oESrkrFkh4vB0sADMialBGBl7cAQ6gsqwJm1+NNgCKDpleeL cTPhbYPM4t6Da36HzGNvvK3wsnbzA2QskikZz4ZCtPAK4WGNHlvKiyNLZMLJPFb30BJKgtvh TK2AppaOnx6VnSPQPbDULTe4debPZIoItQ9Gu6ugZgtb8pUJZX4ZRz5DadO3BcFUpUoVqx6l tqWufAvZKxFCN7cRXpewXmgZ9+tjNA/152bCqk4HB5QcJttvWNMImeUHVp5jqry8rFLDAAAA AAAA --------------ms040308060907090707060900-- --===============1004118808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============1004118808==-- From netmod-bounces@ietf.org Wed Aug 13 04:12:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCB73A6804; Wed, 13 Aug 2008 04:12:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17223A6B20 for ; Wed, 13 Aug 2008 04:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z--CjJa+Kpyt for ; Wed, 13 Aug 2008 04:12:03 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id B47963A6884 for ; Wed, 13 Aug 2008 04:12:02 -0700 (PDT) X-Trace: 122169696/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.186 X-SBRS: None X-RemoteIP: 213.116.52.186 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FACReokjVdDS6/2dsb2JhbACDQTWHbatSA4FS X-IronPort-AV: E=Sophos;i="4.32,201,1217804400"; d="scan'208";a="122169696" X-IP-Direction: IN Received: from 1cust186.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.186]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Aug 2008 12:11:03 +0100 Message-ID: <031901c8fd2c$00457740$0601a8c0@allison> From: "tom.petch" To: "Phil Shafer" References: <200808121856.m7CIudXm009073@idle.juniper.net> Date: Wed, 13 Aug 2008 11:56:05 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: NETMOD Working Group Subject: Re: [netmod] when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ---- Original Message ----- From: "Phil Shafer" To: "tom.petch" Cc: "Andy Bierman" ; "NETMOD Working Group" Sent: Tuesday, August 12, 2008 8:56 PM Subject: Re: [netmod] when statement > "tom.petch" writes: > >Bottom-up detailed design can and does produce a viable system that can be > >implemented and deployed. But lacking an internal coherence, it will be harder > >to understand, harder to learn, harder to get right both for users and > >implementers of tools (see XML:-(. > > Are we not doing enough to communicate the "Zen of YANG"? Or > are you feeling that there's no zen here at all? > My perception is that the communication is lacking, that the Zen is encoded across a number of details and so is hard to mine. (I was going to say Tao of YANG but think that your Zen of YANG is better). Tom Petch > Thanks, > Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 06:29:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787B03A6B1B; Wed, 13 Aug 2008 06:29:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8610E3A6B83 for ; Wed, 13 Aug 2008 06:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o147ZSPkQBnY for ; Wed, 13 Aug 2008 06:29:11 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 192B03A6B20 for ; Wed, 13 Aug 2008 06:29:09 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7DDQCTa022155; Wed, 13 Aug 2008 16:29:06 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 16:29:04 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 16:28:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 16:28:50 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netmod] Augmentable Groupings Thread-Index: Acj9Rg+TWxuQdD0wSQCNCdvfpi/OEA== From: To: , X-OriginalArrivalTime: 13 Aug 2008 13:28:50.0601 (UTC) FILETIME=[85E68990:01C8FD48] X-Nokia-AV: Clean Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0574289265==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --===============0574289265== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FD48.85C82F26" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FD48.85C82F26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 Andy Bierman andy@netconfcentral.com wrote: > Actually groupings are not in the same namespace as objects, > so this Xpath is broken. >=20 >=20 > grouping foo; >=20 > container foo; >=20 > Both of these are legal YANG. That is not in line what is stated in section 7.11 of the YANG specification: " If the grouping is defined at the top level of a YANG module or submodule, the grouping's identifier MUST be unique within the module." Name "foo" is not unqiue within the module. >=20 > If I nest the groupings, then what happens to the augment: >=20 > module C { >=20 > grouping new-concepts { > uses concepts; > } >=20 > Does new-concepts contain the augmentations from concepts? >=20 Yes. > How is somebody reading 'uses C:new-concepts;' in module D > know if this is augmented or not? >=20 The person or system reading 'uses C:new-concepts;' has also to read module B (as this was advertized). You anyway have to do that since in module B there could be also an augment statement that is adding something else to the place where 'uses C:new-concepts;' appears - which has to be known as well. > What if I want to use the 'concept' grouping with the augment and > sometimes without it in the same system? Advertising module B > means that every use of concepts is now augmented. > What if some existing 'uses concepts;' statements > do not support the new nodes? >=20 Then augmenting the grouping should not be done. > There are also conformance issues, depending on what the WG > does about 'if-feature' and capabilities documentation. >=20 Augmenting a grouping should not be treated differently=20 with respect to 'if-feature' than any other YANG modeling feature. Assuming that the augmentaion of a group is inside an 'if-feature' scope, then the augmentation would only become effective if the referred feature is supported. > How is a YANG compiler supposed to know that M of N modules > will be augmenting groupings in other modules, which changes > the uses expansion in all the modules. Do you think the > compiler is going to 'redo' N-1 modules, as it processes > the Nth module? Yes - as it could anyway happen that in module N an augmentation to a node in modules 1..N-1 could have been done. >=20 > Have you implemented this feature in a complete NETCONF system? > I am not convinced it is even implementable, let alone deployable. I don't see that augmentable groupings make things more complicated than they are already. As modules could already augment nodes in other modules, the "effective node tree" must be build up incrementally. In general, augmentable groupings extend the YANG augmentation=20 feature as it is. So augmentable groupings have all benefits=20 but also possible obstacles of augmentations. BR, Bernd >=20 > IMO, this approach has more unintended consequences than benefits. >=20 >=20 > Andy >=20 > > In particular that would mean: > >=20 > > - A groupings can be the target (node) of an > > augment statement. > > - Augmentation of a grouping becomes only effective > > in case the module containing the augment statement > > is advertized. > > - The nodes added to the grouping are therefore > > implicitly added to all places the grouping is used > > in the set of modules supported by an agent. > > - The augmented nodes are in the XML namespace > > of the module of the augment statement. > >=20 > >=20 > > For example assume a module for providing a reusable > > definition of network interface parameters > >=20 > > module Interfaces { > > grouping NetworkInterface { > >=20 > > leaf ifName {type string;} > > leaf ifDescription {type DisplayString;} > > leaf ifMtu {type int32;} > > // . . . > > leaf ifSpeed {type Gauge;} > > leaf ifInOctets {type Counter;} > > // . . . > > } > > =20 > > which is then used to define one or more interface > > lists (tables). > > If now high capacity support should be added > > consistently, this could be done by augmenting > > this group with HC attributes: > >=20 > > module HCSupport { > > import NetworkInterfaces {prefix if; } > > augment /if:NetworkInterface { > > leaf ifHCInOctets {type Counter64;} > > leaf ifHCOutOctets {type Counter64;} > > // . . > > } > > } > >=20 > > Of course, the module HCSupport should only > > be used and advertized if HC support > > is available for all interfaces controlled > > by the advertizing agent. > >=20 > > There are different benefits of augmentable > > groupings: > >=20 > > - Supports consistent and YANG-like extension > > of a grouping by using an existing language > > construct, i.e. it provides additional capabilities > > without introducing new keywords. > >=20 > > - Augmentable groupings maximize re-use of > > model code. In that sense augmentable > > groupings introduce a modeling mechanism, > > which is based on "true re-use" and is > > technically better compared to the existing > > grouping concept, which requires copying > > and pasting augmentation many times. > >=20 > > - When combined with the when statement, > > augmentable groupings even allow selective, > > content based augmentation in a consistent > > manner. > >=20 > > - Augmentable groupings adopt every benefit > > but also obstacle of augmentations in the YANG > > language. As it already has been suggested by > > Martin B., we would like propose that an augment > > MUST NOT add any mandatory nodes (i.e. > > mandatory leaf, list or leaf-list w/ min-elements > 0 > > etc). An augment must not break a client that > > doesn't understand the augmentation. > >=20 > > - Augmenting all places where a grouping is used > > is error-prone and causes unnecessary development > > costs. > > The problem is actually worse than this. > > When someone writes an extension module, > > he/she might not know all places where the > > grouping must be augmented. > >=20 > > BR, > > Bernd > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod ------_=_NextPart_001_01C8FD48.85C82F26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [netmod] Augmentable Groupings

Hi,

Andy Bierman = andy@netconfcentral.com wrote:
> Actually groupings are not = in the same namespace as objects,
> so this Xpath is = broken.
>
>
>     = grouping foo;
>
>     = container foo;
>
> Both of these are legal = YANG.

That is not in line what is = stated in section 7.11 of the
YANG specification:
" If the grouping is = defined at the top level of a YANG module or
   submodule, the = grouping's identifier MUST be unique within the
   = module."
Name "foo" is not = unqiue within the module.

>
> If I nest the groupings, = then what happens to the augment:
>
> module C {
>
>    grouping = new-concepts {
>       uses concepts;
>    }
>
> Does new-concepts contain = the augmentations from concepts?
>

Yes.


> How is somebody reading = 'uses C:new-concepts;' in module D
> know if this is augmented = or not?
>

The person or system reading = 'uses C:new-concepts;' has
also to read module B (as this = was advertized).
You anyway have to do that since = in module B there could
be also an augment statement = that is adding something else
to the place where 'uses = C:new-concepts;' appears - which
has to be known as well.


> What if I want to use the = 'concept' grouping with the augment and
> sometimes without it in the = same system?  Advertising module B
> means that every use of = concepts is now augmented.
> What if some existing 'uses = concepts;' statements
> do not support the new = nodes?
>

Then augmenting the grouping = should not be done.


> There are also conformance = issues, depending on what the WG
> does about 'if-feature' and = capabilities documentation.
>
Augmenting a grouping should not = be treated differently
with respect to 'if-feature' = than any other YANG modeling feature.

Assuming that the augmentaion of = a group is inside an 'if-feature'
scope, then the augmentation = would only become effective if the
referred feature is = supported.

> How is a YANG compiler = supposed to know that M of N modules
> will be augmenting = groupings in other modules, which changes
> the uses expansion in all = the modules.  Do you think the
> compiler is going to 'redo' = N-1 modules, as it processes
> the Nth module?

Yes - as it could anyway happen = that in module N an
augmentation to a node in = modules 1..N-1 could have been done.

>
> Have you implemented this = feature in a complete NETCONF system?
> I am not convinced it is = even implementable, let alone deployable.

I don't see that augmentable = groupings make things more complicated
than they are already. As = modules could already augment nodes in other
modules, the "effective = node tree" must be build up incrementally.

In general, augmentable groupings = extend the YANG augmentation
feature as it is. So augmentable = groupings have all benefits
but also possible obstacles of = augmentations.


BR,
Bernd

>
> IMO, this approach has more = unintended consequences than benefits.
>
>
> Andy
>
> > In particular that = would mean:
> >
> > - A groupings can be = the target (node) of an
> >   augment = statement.
> > - Augmentation of a = grouping becomes only effective
> >   in case = the module containing the augment statement
> >   is = advertized.
> > - The nodes added to = the grouping are therefore
> >   implicitly = added to all places the grouping is used
> >   in the set = of modules supported by an agent.
> > - The augmented nodes = are in the XML namespace
> >   of the = module of the augment statement.
> >
> >
> > For example assume a = module for providing a reusable
> > definition of network = interface parameters
> >
> > module Interfaces = {
> >   grouping = NetworkInterface {
> >
> = >     leaf ifName {type string;}
> = >     leaf ifDescription {type = DisplayString;}
> = >     leaf ifMtu {type int32;}
> = >     // . . .
> = >     leaf ifSpeed {type Gauge;}
> = >     leaf ifInOctets {type Counter;}
> = >     // . . .
> >  }
> > 
> > which is then used to = define one or more interface
> > lists (tables).
> > If now high capacity = support should be added
> > consistently, this = could be done by augmenting
> > this group with HC = attributes:
> >
> > module HCSupport = {
> >   import = NetworkInterfaces {prefix if; }
> >   augment = /if:NetworkInterface {
> = >     leaf ifHCInOctets {type Counter64;}
> = >     leaf ifHCOutOctets {type Counter64;}
> = >     // . .
> >    = }
> > }
> >
> > Of course, the module = HCSupport should only
> > be used and advertized = if HC support
> > is available for all = interfaces controlled
> > by the advertizing = agent.
> >
> > There are different = benefits of augmentable
> > groupings:
> >
> > - Supports consistent = and YANG-like extension
> >   of a = grouping by using an existing language
> >   construct, = i.e. it provides additional capabilities
> >   without = introducing new keywords.
> >
> > - Augmentable = groupings maximize re-use of
> >   model = code. In that sense augmentable
> >   groupings = introduce a modeling mechanism,
> >   which is = based on "true re-use" and is
> >   = technically better compared to the existing
> >   grouping = concept, which requires copying
> >   and = pasting augmentation many times.
> >
> > - When combined with = the when statement,
> >   = augmentable groupings even allow selective,
> >   content = based augmentation in a consistent
> >   = manner.
> >
> > - Augmentable = groupings adopt every benefit
> >   but also = obstacle of augmentations in the YANG
> >   language. = As it already has been suggested by
> >   Martin B., = we would like propose that an augment
> >   MUST NOT = add any mandatory nodes (i.e.
> >   mandatory = leaf, list or leaf-list w/ min-elements > 0
> >   etc). An = augment must not break a client that
> >   doesn't = understand the augmentation.
> >
> > - Augmenting all = places where a grouping is used
> >   is = error-prone and causes unnecessary development
> >   = costs.
> >   The = problem is actually worse than this.
> >   When = someone writes an extension module,
> >   he/she = might not know all places where the
> >   grouping = must be augmented.
> >
> > BR,
> > Bernd
> >
> >
> >
> = --------------------------------------------------------------
> ----------
> >
> > = _______________________________________________
> > netmod mailing = list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod

------_=_NextPart_001_01C8FD48.85C82F26-- --===============0574289265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============0574289265==-- From netmod-bounces@ietf.org Wed Aug 13 07:03:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08293A69A6; Wed, 13 Aug 2008 07:03:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F88D3A69A6 for ; Wed, 13 Aug 2008 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLfw7XWLRkQ8 for ; Wed, 13 Aug 2008 07:03:18 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1F2E23A68C7 for ; Wed, 13 Aug 2008 07:03:11 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7DE2c8k027595; Wed, 13 Aug 2008 17:02:40 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 17:02:04 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 17:01:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 17:01:55 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F266045C8FA9@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netmod] Augmentable Groupings Thread-Index: Acj9TSUZhwKR92qyS0uLP86XpTWoNQ== From: To: , X-OriginalArrivalTime: 13 Aug 2008 14:01:57.0040 (UTC) FILETIME=[25E91300:01C8FD4D] X-Nokia-AV: Clean Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1815409464==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --===============1815409464== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FD4D.2599503E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FD4D.2599503E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Phil Shafer phil@juniper.net wrote: > The reverse is also true, and I think this is the problem > with this proposal. When you augment a grouping, you have > no idea who has used it and what havoc you are wrecking on > those other users. >=20 > Imagine the case where I have taken your NetworkInterface > grouping and used it in a list of low speed interfaces: >=20 > list slow-dudes { > use NetworkInterface; > leaf how-slow { > type enumeration { > enum very-slow { ... } > enum horribly-slow { ... } > enum 2g { ... } > } > } > } >=20 > When you augment NetworkInterface in your module, I suddenly get > your ifHCIn/OutOctets leafs, which are completely inappropriate. But in this case you should not augment the NetworkInterface grouping but rather augment HC features to the place where HC support is needed. Another option is to use a 'when' statement in the augmentation: augment NetworkInterface {=20 when "if:ifSpeed > 100000000"; leaf ifHCInOctets {type Counter64;}=20 leaf ifHCOutOctets {type Counter64;}=20 // . .=20 }=20 This kind of "selective augmentations" would be anyway recommended in case the augmented contents makes only sense under certain circumstances. > I can't turn them off and I can't tell nm apps "hey he didn't > mean my list". Sure, I can choose not to implement/announce > your module, but if both slow-dudes and HCSupport are IETF > standards, I'm stuck. >=20 Of course, in this case only one of the two IETF standards can be implemented. But this happens if standard body B extends something from standard body A without aligning their models. To avoid such a problem standard body A should extend the module=20 in a consistent manner - based on input of standard body B. > I see the attraction of "say it once and it happens everywhere", > but the down side far overways the benefit. Augmentable groupings also solve another problem you would=20 have when an existing standard should be enhanced with a standard addition (Martin B. made us aware of this scenario): Assuming that grouping 'NetworkInterface' is used in two modules that you also don't control by yourself module X { import NetworkInterfaces {prefix if; }=20 list interfaces { uses if:NetworkInterface } } module Y { import NetworkInterfaces {prefix if; }=20 list interfaces { uses if:NetworkInterface } } In case you want to add a HC support standard extension without augmentable groupings, what could be done is to define a grouping module NetworkInterfacesExt { grouping HCInterfaceExtensions {=20 when "if:ifSpeed > 100000000"; leaf ifHCInOctets {type Counter64;}=20 leaf ifHCOutOctets {type Counter64;}=20 // . .=20 } =20 and augment this grouping in every place "NetworkInterface" is used: module VENDOR_SPECIFIC { import X {prefix x;} import Y {prefix y;} =20 import NetworkInterfacesExt {prefix ifex;} augment x:interfaces { uses ifex:HCInterfaceExtensions; } =20 augment y:interfaces { uses ifex:HCInterfaceExtensions; } =20 =20 The effect of that is that the HC-counters are in the namespace of the vendor specific module. So=20 clients that only understand NetworkInterface and=20 NetworkInterfaceExt don't understand the HC-counters as they are in a non-standard namespace. Contrast this with putting the augmentation of the grouping NetworkInterfaces in the module NetworkInterfacesExt. In this case the HC-counters appear in the "correct" namespace - so a client that knows only modules NetworkInterface and NetworkInterfaceExt" has no problem of understanding them. Not to mention that the explicit augment statements are not needed. BR, Bernd > Thanks, > Phil ------_=_NextPart_001_01C8FD4D.2599503E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [netmod] Augmentable Groupings

Hi,

Phil Shafer phil@juniper.net = wrote:
> The reverse is also true, = and I think this is the problem
> with this proposal.  = When you augment a grouping, you have
> no idea who has used it and = what havoc you are wrecking on
> those other users.
>
> Imagine the case where I = have taken your NetworkInterface
> grouping and used it in a = list of low speed interfaces:
>
>     = list slow-dudes {
>         use = NetworkInterface;
>         leaf how-slow = {
>          &nbs= p;  type enumeration {
>          &nbs= p;      enum very-slow { ... }
>          &nbs= p;      enum horribly-slow { ... }
>          &nbs= p;      enum 2g { ... }
>          &nbs= p;  }
>         }
>     = }
>
> When you augment = NetworkInterface in your module, I suddenly get
> your ifHCIn/OutOctets = leafs, which are completely inappropriate.

But in this case you should not = augment the NetworkInterface grouping
but rather augment HC features = to the place where HC support is needed.

Another option is to use a 'when' = statement in the augmentation:

 augment NetworkInterface { =
    when = "if:ifSpeed > 100000000";
    leaf = ifHCInOctets {type Counter64;}
    leaf = ifHCOutOctets {type Counter64;}
    // . . =
   }

This kind of "selective = augmentations" would be anyway
recommended in case the = augmented contents makes only
sense under certain = circumstances.

> I can't turn them off and I = can't tell nm apps "hey he didn't
> mean my list".  = Sure, I can choose not to implement/announce
> your module, but if both = slow-dudes and HCSupport are IETF
> standards, I'm = stuck.
>
Of course, in this case only one = of the two IETF standards can
be implemented. But this happens = if standard body B extends
something from standard body A = without aligning their models.
To avoid such a problem standard = body A should extend the module
in a consistent manner - based = on input of standard body B.

> I see the attraction of = "say it once and it happens everywhere",
> but the down side far = overways the benefit.

Augmentable groupings also solve = another problem you would
have when an existing standard = should be enhanced with a standard
addition (Martin B. made us = aware of this scenario):

Assuming that grouping = 'NetworkInterface' is used
in two modules that you also = don't control by yourself
  module X {
     import = NetworkInterfaces {prefix if; }
     list = interfaces {
        uses = if:NetworkInterface
     = }
  }
  module Y {
     import = NetworkInterfaces {prefix if; }
     list = interfaces {
        uses = if:NetworkInterface
     = }
  }


In case you want to add a HC = support standard extension without
augmentable groupings, what = could be done is to define a grouping

module NetworkInterfacesExt = {
 grouping = HCInterfaceExtensions {
    when = "if:ifSpeed > 100000000";
    leaf = ifHCInOctets {type Counter64;}
    leaf = ifHCOutOctets {type Counter64;}
    // . . =
   } 

and augment this grouping in = every place "NetworkInterface" is used:

  module VENDOR_SPECIFIC = {
     import = X {prefix x;}
     import = Y {prefix y;}  
     import = NetworkInterfacesExt {prefix ifex;}

     augment = x:interfaces {
        uses = ifex:HCInterfaceExtensions;
     = }   
     augment = y:interfaces {
        uses = ifex:HCInterfaceExtensions;
     }  =
 
The effect of that is that the = HC-counters are in
the namespace of the vendor = specific module. So
clients that only understand = NetworkInterface and
NetworkInterfaceExt don't = understand the
HC-counters as they are in a = non-standard namespace.

Contrast this with putting the = augmentation of the
grouping NetworkInterfaces in = the module NetworkInterfacesExt.
In this case the HC-counters = appear in the "correct"
namespace - so a client that = knows only modules
NetworkInterface and = NetworkInterfaceExt" has no
problem of understanding = them.
Not to mention that the explicit = augment statements
are not needed.

BR,
Bernd

> Thanks,
>  Phil

------_=_NextPart_001_01C8FD4D.2599503E-- --===============1815409464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============1815409464==-- From netmod-bounces@ietf.org Wed Aug 13 08:02:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFB63A692F; Wed, 13 Aug 2008 08:02:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122E73A69B3 for ; Wed, 13 Aug 2008 08:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F24OSsdMxXwA for ; Wed, 13 Aug 2008 08:02:16 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 7DED33A6939 for ; Wed, 13 Aug 2008 08:02:13 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 08:01:41 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:02:02 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:02:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:02:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7DF21u93591; Wed, 13 Aug 2008 08:02:01 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7DEwelY015955; Wed, 13 Aug 2008 14:58:41 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808131458.m7DEwelY015955@idle.juniper.net> To: bernd.linowski.ext@nsn.com In-reply-to: <46DCD7DCAFF0E94796B7C2894ED9F266045C8FA9@esebe103.NOE.Nokia.com> Date: Wed, 13 Aug 2008 10:58:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2008 15:02:01.0636 (UTC) FILETIME=[8A6AC640:01C8FD55] Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org bernd.linowski.ext@nsn.com writes: >But in this case you should not augment the NetworkInterface grouping >but rather augment HC features to the place where HC support is needed. The scenario remains. If anyone can augment a grouping, one module's augmentation can interfere with the use of the grouping in another module. If you allow augmenting of groupings, you lose control of what a module gets when they say use a grouping. >Of course, in this case only one of the two IETF standards can >be implemented. This would be an unacceptable outcome. >To avoid such a problem standard body A should extend the module=20 >in a consistent manner - based on input of standard body B. This may not be possible. If A's module is already published, B simply cannot use that grouping. This would require that any modeler that wants to use a grouping must understand all the other module writers that have augmented that grouping and avoid groupings that are augmented in unacceptable ways. This is unworkable. Worse, add a mixture of standard and proprietary modules. If I'm a making a proprietary model and want to use a grouping defined in a standard module, I cannot since I must be aware of the possibility of another working group augmenting that grouping in the future in ways that are incompatible with my use of the grouping. >The effect of that is that the HC-counters are in >the namespace of the vendor specific module. So >clients that only understand NetworkInterface and >NetworkInterfaceExt don't understand the >HC-counters as they are in a non-standard namespace. I would contend that this is a feature, since the bits you are adding that are _not_ in the original module are unknown to applications that only understand the original module and _should_ be in a distinct namespace. Worse, if you put these augmented nodes in the original namespace, you become ambiguous if the original module's author adds those nodes to their module. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 08:08:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186A33A69E7; Wed, 13 Aug 2008 08:08:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775F53A6A73 for ; Wed, 13 Aug 2008 08:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsUpCAY3+2V2 for ; Wed, 13 Aug 2008 08:08:12 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 6919D3A6A15 for ; Wed, 13 Aug 2008 08:08:10 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 08:07:50 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:07:38 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:07:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:07:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7DF7bu95459; Wed, 13 Aug 2008 08:07:37 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7DF4Hc4016007; Wed, 13 Aug 2008 15:04:17 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808131504.m7DF4Hc4016007@idle.juniper.net> To: Gerhard Muenz In-reply-to: <48A2B0C6.8020609@informatik.uni-tuebingen.de> Date: Wed, 13 Aug 2008 11:04:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2008 15:07:38.0174 (UTC) FILETIME=[530265E0:01C8FD56] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Gerhard Muenz writes: >The example can be extended: an IPFIX device supporting a specific >selection method may allow only a limited number of Selection Processes >which make use of this method, e.g. because the packet selection is >performed by a blade in a router. A possible solution is to specify a >readonly parameter in the DM which returns the corresponding value and >to explain its meaning in the description clause. Do you have a better idea? These are the "device deviations" Martin was talking about, and is work we are trying to put off til the next phase of YANG. But basically, the application asks the device where the device deviates from a specific module. The device replies with a list of deviations in the format: deviation { ; ... } ... For example, deviation making/up/the/path/to/process-list { max-elements 4; } The app learns the device only supports 4 elements in the process-list and can use this knowledge to configure the device appropriately. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 08:12:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D123A6AA2; Wed, 13 Aug 2008 08:12:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204C73A6AA7 for ; Wed, 13 Aug 2008 08:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr-l4O7C35eZ for ; Wed, 13 Aug 2008 08:12:17 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 4A1123A6AA2 for ; Wed, 13 Aug 2008 08:12:17 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 08:12:13 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:12:14 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:12:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 08:12:14 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7DFCDu96327; Wed, 13 Aug 2008 08:12:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7DF8rtN016062; Wed, 13 Aug 2008 15:08:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808131508.m7DF8rtN016062@idle.juniper.net> To: Andy Bierman In-reply-to: <48A260E1.9050609@netconfcentral.com> Date: Wed, 13 Aug 2008 11:08:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2008 15:12:14.0198 (UTC) FILETIME=[F7885160:01C8FD56] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >It is still config, but read-only config. IMHO: If I can't set it, it's not config. Config is the instructions I give the device to get to a known state. If I can't give that instruction, it's not config data. >This is usually what happens when an optional YANG >leaf is missing from a list. The only difference is the >WG deciding that it is OK for the agent to provide >a valid value and not allow the manager to set the leaf >at all. This makes big trouble for applications that attempt to save and restore configuration. If I get a node via that I can't restore via , then I can't do save/restore. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 08:18:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4673A698F; Wed, 13 Aug 2008 08:18:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456E43A6A9C for ; Wed, 13 Aug 2008 08:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSnoHspRR5cJ for ; Wed, 13 Aug 2008 08:18:10 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 13FF03A698F for ; Wed, 13 Aug 2008 08:18:10 -0700 (PDT) Received: (qmail 15635 invoked from network); 13 Aug 2008 15:18:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2008 15:18:11 -0000 X-YMail-OSG: V232agAVM1m6EleJZmrS_UOkAk55cewWLbt63KnUUPpIV_BgLPmDpN5zmWnmHo_z3msl_mk9l_PRotxp2tIDaktzoMn0TIf6mxwrvliijgyZLh8AIBlEo0p3KEk5mRY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A2FB32.9060405@netconfcentral.com> Date: Wed, 13 Aug 2008 08:18:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: bernd.linowski.ext@nsn.com References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org bernd.linowski.ext@nsn.com wrote: > > Hi, > > Andy Bierman andy@netconfcentral.com wrote: > > Actually groupings are not in the same namespace as objects, > > so this Xpath is broken. > > > > > > grouping foo; > > > > container foo; > > > > Both of these are legal YANG. > > That is not in line what is stated in section 7.11 of the > YANG specification: > " If the grouping is defined at the top level of a YANG module or > submodule, the grouping's identifier MUST be unique within the > module." > Name "foo" is not unqiue within the module. > Here is the text from the draft: 6.2.1. Identifiers and their namespaces Each identifier is valid in a namespace which depends on the type of the YANG item being defined: o All module and submodule names share the same global module identifier namespace. o All extension names defined in a module and its submodules share the same extension identifier namespace. o All derived type names defined within a parent node or at the top- level of the module or its submodules share the same type identifier namespace. This namespace is scoped to the parent node or module. o All groupings defined within a parent node or at the top-level of the module or its submodules share the same grouping identifier namespace. This namespace is scoped to the parent node or module. o All leafs, leaf-lists, lists, containers, choices, rpcs, and notifications defined within a parent node or at the top-level of the module or its submodules share the same identifier namespace. This namespace is scoped to the parent node or module, unless the parent node is a case node. In that case, the namespace is scoped to the parent node of the case node's parent choice node. o All cases within a choice share the same case identifier namespace. This namespace is scoped to the parent choice node. All identifiers defined in a namespace MUST be unique. > > > > If I nest the groupings, then what happens to the augment: > > > > module C { > > > > grouping new-concepts { > > uses concepts; > > } > > > > Does new-concepts contain the augmentations from concepts? > > > > Yes. > Yes, well this makes it an NP-complete problem to resolve all the uses statements in all the modules. Even if that did not matter (just implementation!), the NETCONF vendors have to deal with a pool of modules for which they have no change control whatsoever. And what about their own modules already out there in shipping code? This 'write once, and it shows up everywhere' feature is not actually usable in the operational environment that YANG must address. Andy > > > How is somebody reading 'uses C:new-concepts;' in module D > > know if this is augmented or not? > > > > The person or system reading 'uses C:new-concepts;' has > also to read module B (as this was advertized). > You anyway have to do that since in module B there could > be also an augment statement that is adding something else > to the place where 'uses C:new-concepts;' appears - which > has to be known as well. > > > > What if I want to use the 'concept' grouping with the augment and > > sometimes without it in the same system? Advertising module B > > means that every use of concepts is now augmented. > > What if some existing 'uses concepts;' statements > > do not support the new nodes? > > > > Then augmenting the grouping should not be done. > > > > There are also conformance issues, depending on what the WG > > does about 'if-feature' and capabilities documentation. > > > Augmenting a grouping should not be treated differently > with respect to 'if-feature' than any other YANG modeling feature. > > Assuming that the augmentaion of a group is inside an 'if-feature' > scope, then the augmentation would only become effective if the > referred feature is supported. > > > How is a YANG compiler supposed to know that M of N modules > > will be augmenting groupings in other modules, which changes > > the uses expansion in all the modules. Do you think the > > compiler is going to 'redo' N-1 modules, as it processes > > the Nth module? > > Yes - as it could anyway happen that in module N an > augmentation to a node in modules 1..N-1 could have been done. > > > > > Have you implemented this feature in a complete NETCONF system? > > I am not convinced it is even implementable, let alone deployable. > > I don't see that augmentable groupings make things more complicated > than they are already. As modules could already augment nodes in other > modules, the "effective node tree" must be build up incrementally. > > In general, augmentable groupings extend the YANG augmentation > feature as it is. So augmentable groupings have all benefits > but also possible obstacles of augmentations. > > > BR, > Bernd > > > > > IMO, this approach has more unintended consequences than benefits. > > > > > > Andy > > > > > In particular that would mean: > > > > > > - A groupings can be the target (node) of an > > > augment statement. > > > - Augmentation of a grouping becomes only effective > > > in case the module containing the augment statement > > > is advertized. > > > - The nodes added to the grouping are therefore > > > implicitly added to all places the grouping is used > > > in the set of modules supported by an agent. > > > - The augmented nodes are in the XML namespace > > > of the module of the augment statement. > > > > > > > > > For example assume a module for providing a reusable > > > definition of network interface parameters > > > > > > module Interfaces { > > > grouping NetworkInterface { > > > > > > leaf ifName {type string;} > > > leaf ifDescription {type DisplayString;} > > > leaf ifMtu {type int32;} > > > // . . . > > > leaf ifSpeed {type Gauge;} > > > leaf ifInOctets {type Counter;} > > > // . . . > > > } > > > > > > which is then used to define one or more interface > > > lists (tables). > > > If now high capacity support should be added > > > consistently, this could be done by augmenting > > > this group with HC attributes: > > > > > > module HCSupport { > > > import NetworkInterfaces {prefix if; } > > > augment /if:NetworkInterface { > > > leaf ifHCInOctets {type Counter64;} > > > leaf ifHCOutOctets {type Counter64;} > > > // . . > > > } > > > } > > > > > > Of course, the module HCSupport should only > > > be used and advertized if HC support > > > is available for all interfaces controlled > > > by the advertizing agent. > > > > > > There are different benefits of augmentable > > > groupings: > > > > > > - Supports consistent and YANG-like extension > > > of a grouping by using an existing language > > > construct, i.e. it provides additional capabilities > > > without introducing new keywords. > > > > > > - Augmentable groupings maximize re-use of > > > model code. In that sense augmentable > > > groupings introduce a modeling mechanism, > > > which is based on "true re-use" and is > > > technically better compared to the existing > > > grouping concept, which requires copying > > > and pasting augmentation many times. > > > > > > - When combined with the when statement, > > > augmentable groupings even allow selective, > > > content based augmentation in a consistent > > > manner. > > > > > > - Augmentable groupings adopt every benefit > > > but also obstacle of augmentations in the YANG > > > language. As it already has been suggested by > > > Martin B., we would like propose that an augment > > > MUST NOT add any mandatory nodes (i.e. > > > mandatory leaf, list or leaf-list w/ min-elements > 0 > > > etc). An augment must not break a client that > > > doesn't understand the augmentation. > > > > > > - Augmenting all places where a grouping is used > > > is error-prone and causes unnecessary development > > > costs. > > > The problem is actually worse than this. > > > When someone writes an extension module, > > > he/she might not know all places where the > > > grouping must be augmented. > > > > > > BR, > > > Bernd > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > _https://www.ietf.org/mailman/listinfo/netmod_ > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 08:28:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7673A68C3; Wed, 13 Aug 2008 08:28:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915133A68C3 for ; Wed, 13 Aug 2008 08:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlrIL1FjNPsE for ; Wed, 13 Aug 2008 08:28:47 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id CE6123A6AA2 for ; Wed, 13 Aug 2008 08:28:47 -0700 (PDT) Received: (qmail 75099 invoked from network); 13 Aug 2008 15:28:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2008 15:28:42 -0000 X-YMail-OSG: fD4ISmkVM1mBSiI6c_Y5rFTOTWVWAvfVsCsSZhBymXMh4sh._p5Vu7EZW4PM3vo0KSM8FAr95UJmRZuQ5LdwPx2E4BKPcSGxkPLeQEgrgg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A2FDA8.8000608@netconfcentral.com> Date: Wed, 13 Aug 2008 08:28:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808131508.m7DF8rtN016062@idle.juniper.net> In-Reply-To: <200808131508.m7DF8rtN016062@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> It is still config, but read-only config. > > IMHO: If I can't set it, it's not config. Config is the instructions > I give the device to get to a known state. If I can't give that > instruction, it's not config data. > NETCONF has no such definition of config. YANG has no concept of conformance that actually accounts for the way that compromises are made in standard data models. A WG may decide that a leaf is writable, but that it is not mandatory for a compliant agent to implement it. The 'if-feature' approach will result in an artificial 'read-only' feature every time this happens. It will result in some 'row create' operations that are not the same across all platforms. One problem YANG is going to face is deployment within the IETF, such that WGs can develop YANG models instead of SMIv2 modules, if they so choose. There are many WG that already know how to develop a standard MIB. There are none that know how to develop a standard YANG module. Perhaps "forget everything you know and learn all this new stuff instead" is not the best transition plan. >> This is usually what happens when an optional YANG >> leaf is missing from a list. The only difference is the >> WG deciding that it is OK for the agent to provide >> a valid value and not allow the manager to set the leaf >> at all. > > This makes big trouble for applications that attempt to save and > restore configuration. If I get a node via that I > can't restore via , then I can't do save/restore. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 09:07:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EE93A69C3; Wed, 13 Aug 2008 09:07:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01563A6A9C for ; Wed, 13 Aug 2008 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHJrh86aQ1hp for ; Wed, 13 Aug 2008 09:07:26 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id ABD983A67A8 for ; Wed, 13 Aug 2008 09:07:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7DG7EGC024880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 18:07:14 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7DG7Ebq029588; Wed, 13 Aug 2008 18:07:14 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 18:07:14 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 18:07:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 19:07:08 +0300 Message-ID: <210412A63D60154898B7CDC3C7172BDE3D026A@FIESEXC007.nsn-intra.net> In-Reply-To: <48A1B134.9000601@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: Acj8kyHmhegQ5oeYSGalOgcbnyF29QAxdDmQ References: <46DCD7DCAFF0E94796B7C2894ED9F26604591C90@esebe103.NOE.Nokia.com> <48A1B134.9000601@netconfcentral.com> From: "Lahdensivu, Mikko (NSN - FI/Tampere)" To: "ext Andy Bierman" X-OriginalArrivalTime: 13 Aug 2008 16:07:13.0232 (UTC) FILETIME=[A5E8F500:01C8FD5E] Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, >If I nest the groupings, then what happens to the augment: > >module C { > > grouping new-concepts { > uses concepts; > } > >Does new-concepts contain the augmentations from concepts? > >How is somebody reading 'uses C:new-concepts;' in module D >know if this is augmented or not? If module A defines a list "a", and module B augments list "a", how is somebody reading module C which contains reference to "a" know whether "a" is augmented or not? Assuming mandatory content cannot be added in an augmentation, you can in both cases (list, grouping) not provide values for the mandatory part, and ignore the values in reading. > >What if I want to use the 'concept' grouping with the augment >and sometimes without it in the same system? Advertising >module B means that every use of concepts is now augmented. >What if some existing 'uses concepts;' statements do not >support the new nodes? What if I want that, from one list, elements referred in one place of the model can be augmented, but those referred in other places cannot be augmented? Let's say I have a list of "server" (name and IP address pair), which I can reuse in several places in my model (to avoid redundant entering of the same address in multiple places of the model). Now an application processing "connection" (which refers to a server) would encounter the augmentation, like it would have if I would have used grouping "server" instead. In both cases the application reading the "connection", including the related address, need to be able to handle situation with unexpected optional leaves. I don't think we should assume that a grouping always has multiple implementations in an application/server, but a list always has one implementation in an application/server. >How is a YANG compiler supposed to know that M of N modules >will be augmenting groupings in other modules, which changes >the uses expansion in all the modules. Do you think the >compiler is going to 'redo' N-1 modules, as it processes the >Nth module? Let's say each module corresponds to a header file. If module augments another module, the compiler would update the header file. When you would compile the Yang compiler output, the compiler would be able to include the modified, instead of the original, header file in every place it is used. There would not be any difference on whether the header file would be modified by an augmentation of a grouping or augmentation of a list. Even without augmentation of groupings the compiler needs modify the original header file, once it encounters a module with the augmentation. Mikko _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 09:16:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF4E3A688C; Wed, 13 Aug 2008 09:16:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2403A69C3 for ; Wed, 13 Aug 2008 09:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4Ma14Dk0bM2 for ; Wed, 13 Aug 2008 09:16:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 656AB3A69A4 for ; Wed, 13 Aug 2008 09:16:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7DGGRnE017930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 18:16:27 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7DGGQwu001774; Wed, 13 Aug 2008 18:16:26 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 18:16:27 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 18:16:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 19:16:22 +0300 Message-ID: <210412A63D60154898B7CDC3C7172BDE3D026D@FIESEXC007.nsn-intra.net> In-Reply-To: <200808121906.m7CJ6TCk009270@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: Acj8sM/Ic68xSm8mShqmvNjD6A7OtAArdY9g References: <46DCD7DCAFF0E94796B7C2894ED9F26604591C90@esebe103.NOE.Nokia.com> <200808121906.m7CJ6TCk009270@idle.juniper.net> From: "Lahdensivu, Mikko (NSN - FI/Tampere)" To: "ext Phil Shafer" X-OriginalArrivalTime: 13 Aug 2008 16:16:26.0678 (UTC) FILETIME=[EFCA1D60:01C8FD5F] Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, >The reverse is also true, and I think this is the problem with >this proposal. When you augment a grouping, you have no idea >who has used it and what havoc you are wrecking on those other users. > >Imagine the case where I have taken your NetworkInterface >grouping and used it in a list of low speed interfaces: > > list slow-dudes { > use NetworkInterface; > leaf how-slow { > type enumeration { > enum very-slow { ... } > enum horribly-slow { ... } > enum 2g { ... } > } > } > } > >When you augment NetworkInterface in your module, I suddenly >get your ifHCIn/OutOctets leafs, which are completely inappropriate. >I can't turn them off and I can't tell nm apps "hey he didn't >mean my list". Sure, I can choose not to implement/announce >your module, but if both slow-dudes and HCSupport are IETF >standards, I'm stuck. And if concept NetworkInterface is mapped to a list NetworkInterface. Now when you refer the list NetworkInterface from other places of your model (where otherwise you could use a grouping), and you add your slow-dudes elements to the list, they will again have the high capacity leaves. What is the difference from application point of view whether it reads the data from NetworkInterface list or NetworkInterface grouping? In both cases your application can have a generic routine for reading NetworkInterface data from the element, and on both cases you can have a condition on the type of the NetworkInterface so that augmented leaves are not applicable to incorrect type of NetworkInterface. Mikko _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 09:27:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CDF3A6B0C; Wed, 13 Aug 2008 09:27:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CA43A6AC8 for ; Wed, 13 Aug 2008 09:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X++TKtPFLjAH for ; Wed, 13 Aug 2008 09:27:39 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 127383A6AF1 for ; Wed, 13 Aug 2008 09:27:39 -0700 (PDT) Received: (qmail 36644 invoked from network); 13 Aug 2008 16:27:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2008 16:26:59 -0000 X-YMail-OSG: y_ZcQecVM1lEI660Fl8nGQESvB9d4IYLIkTdlOy5J0rEwhf4yWybXB20P_2TwyAnecRiyx6EzSfLggVYuVXHvq_iKl1lmAGjMcYCgJWytA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A30B51.6040908@netconfcentral.com> Date: Wed, 13 Aug 2008 09:26:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808131508.m7DF8rtN016062@idle.juniper.net> In-Reply-To: <200808131508.m7DF8rtN016062@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> It is still config, but read-only config. > > IMHO: If I can't set it, it's not config. Config is the instructions > I give the device to get to a known state. If I can't give that > instruction, it's not config data. > >> This is usually what happens when an optional YANG >> leaf is missing from a list. The only difference is the >> WG deciding that it is OK for the agent to provide >> a valid value and not allow the manager to set the leaf >> at all. > > This makes big trouble for applications that attempt to save and > restore configuration. If I get a node via that I > can't restore via , then I can't do save/restore. > YANG needs to support the following type of conformance scenario: 1) A WG defines 17 conceptual knobs that make sense to control their new protocol 2) Vendors do not agree that they should have to provide user control of all 17 knobs 3) Instead of removing most of the 17 knobs, the WG agrees on a subset that MUST allow user control and the rest that MAY provide user control. 4) If the optional leafs are the type that really are not used at all if not configured, then the GROUP mechanism is used to partition the optional objects for conformance purposes 5) If the optional leafs are the type that really are used, but with an agent selected value, then the agent will create a knob instance with a valid value, depending on the data type for the knob. 6) Even though the agent may not accept this type of optional knob when the NP container (table row) is created, the WG may decide that the manager needs to know which value was selected by the agent for that knob. (Unless filtered via 'with-defaults'). 7) The way NETCONF works wrt/ this feature is TBD. The way to look at this in NETCONF/YANG is that this last sort of knob is config where the agent will only accept 1 particular value for the knob. If the agent must accept the optional leaf when it contains the one and only value supported by the agent, then edit-config, copy-config, and get-config will still work. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 09:35:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31853A6B31; Wed, 13 Aug 2008 09:35:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6743A6A69 for ; Wed, 13 Aug 2008 09:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1rIDGM7tnDG for ; Wed, 13 Aug 2008 09:35:02 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 9D8E73A6B57 for ; Wed, 13 Aug 2008 09:35:02 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 09:34:07 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 09:34:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 09:34:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 09:34:26 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7DGYQu21489; Wed, 13 Aug 2008 09:34:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7DGV63e016696; Wed, 13 Aug 2008 16:31:06 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808131631.m7DGV63e016696@idle.juniper.net> To: Andy Bierman In-reply-to: <48A2FDA8.8000608@netconfcentral.com> Date: Wed, 13 Aug 2008 12:31:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2008 16:34:26.0931 (UTC) FILETIME=[73ABA430:01C8FD62] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >NETCONF has no such definition of config. But it does: Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. >YANG has no concept of conformance that actually >accounts for the way that compromises are made in standard >data models. I hope we are creating such mechanisms, with the feature feature and device deviations. >A WG may decide that a leaf is writable, but that it >is not mandatory for a compliant agent to implement it. >The 'if-feature' approach will result in an artificial >'read-only' feature every time this happens. It will result >in some 'row create' operations that are not the >same across all platforms. I don't think so. SNMP had these issues do to the lack of expressibility and the nature of the protocol. NETCONF and YANG are more expressive and I hope to see better use of these mechanism for expressing such optional behaviors, modeled and unmodeled. >There are none that know how to develop a standard YANG module. >Perhaps "forget everything you know and learn all this new stuff >instead" is not the best transition plan. No, but neither is "carry your baggage forever". We're not trying to do "SNMP in XML". We're trying to do something better. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 10:02:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20383A6B05; Wed, 13 Aug 2008 10:02:34 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A53B3A6B5D for ; Wed, 13 Aug 2008 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iKbzpX3Akrc for ; Wed, 13 Aug 2008 10:02:32 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 8187A3A6B05 for ; Wed, 13 Aug 2008 10:02:29 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 10:01:59 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 10:01:43 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 10:01:42 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 09:55:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7DGtvu27467; Wed, 13 Aug 2008 09:55:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7DGqaks016865; Wed, 13 Aug 2008 16:52:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808131652.m7DGqaks016865@idle.juniper.net> To: "Lahdensivu, Mikko (NSN - FI/Tampere)" In-reply-to: <210412A63D60154898B7CDC3C7172BDE3D026D@FIESEXC007.nsn-intra.net> Date: Wed, 13 Aug 2008 12:52:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2008 16:55:57.0805 (UTC) FILETIME=[751761D0:01C8FD65] Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Lahdensivu, Mikko (NSN - FI/Tampere)" writes: >Now when you refer the list NetworkInterface from other places of your >model (where otherwise you could use a grouping), and you add your >slow-dudes elements to the list, they will again have the high capacity >leaves. The problem remains: if I use a grouping that you can randomly augment, then I can never be sure of the set of nodes I'm getting when I use a grouping. On a theoretical level, it may not matter to your application, but on the practical level, when your application sends my box content that it doesn't understand, things break. If I made a list of interfaces and reused a standard grouping, and you augment that grouping with your new nodes, how do you know whether I implemented your augmented nodes in my list? I can't come in after that fact and say "he didn't mean me". Yes, you can put a "when" on your augment, but that condition may not match my reuse of the grouping. >In both cases your application can have a generic routine for reading >NetworkInterface data from the element, and on both cases you can have a >condition on the type of the NetworkInterface so that augmented leaves >are not applicable to incorrect type of NetworkInterface. The generic solution doesn't exist on the device side, where the config that your application ships to my device must match the nodes I've implemented in my software. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 10:22:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFBC3A6B05; Wed, 13 Aug 2008 10:22:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBD73A6BD3 for ; Wed, 13 Aug 2008 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f-ZvBE9Gb9P for ; Wed, 13 Aug 2008 10:22:56 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 876673A6B05 for ; Wed, 13 Aug 2008 10:22:56 -0700 (PDT) Received: (qmail 16161 invoked from network); 13 Aug 2008 17:22:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2008 17:22:47 -0000 X-YMail-OSG: UDnGa_cVM1lGk0kxT6I0R6jSF.yojBjhwmPZOCmK0ZmScOR3T8XqxHHpy3AQeEqS9PYlCgRPtdo8WJuzHpGALGF1xJ76YtTVgHQ_I_gF2g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A31864.3040702@netconfcentral.com> Date: Wed, 13 Aug 2008 10:22:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808131631.m7DGV63e016696@idle.juniper.net> In-Reply-To: <200808131631.m7DGV63e016696@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >... >> There are none that know how to develop a standard YANG module. >> Perhaps "forget everything you know and learn all this new stuff >> instead" is not the best transition plan. > > No, but neither is "carry your baggage forever". We're not trying > to do "SNMP in XML". We're trying to do something better. > In order to distinguish 'better' from 'different', one needs to understand SMIv2/SNMP and how it is used in the IETF. There are some practices (such as clearly identifying the exact objects associated with a specific version of a conformance macro) that have proven to support inter-operable implementations. The exact SMIv2 mechanisms and syntax are not important, but the features they support are. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 12:04:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270123A683B; Wed, 13 Aug 2008 12:04:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98243A6990 for ; Wed, 13 Aug 2008 12:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n13-EB1pp0FM for ; Wed, 13 Aug 2008 12:04:47 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 2FD993A683B for ; Wed, 13 Aug 2008 12:04:46 -0700 (PDT) Received: (qmail 7478 invoked from network); 13 Aug 2008 19:04:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2008 19:04:49 -0000 X-YMail-OSG: .ysGw6MVM1lR11Jyyxml_9X2bbBU.ieaEx1umOaWRM_SzOQ9HOfr3nQ4e0EjBsftQ.kmeevjYwT6xmD0XObIlshI3T7TiOkaHXHe_TTxFA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A3304F.8050603@netconfcentral.com> Date: Wed, 13 Aug 2008 12:04:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808131631.m7DGV63e016696@idle.juniper.net> In-Reply-To: <200808131631.m7DGV63e016696@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> NETCONF has no such definition of config. > > But it does: > > Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state. > >> YANG has no concept of conformance that actually >> accounts for the way that compromises are made in standard >> data models. > > I hope we are creating such mechanisms, with the feature feature > and device deviations. I am on board with the feature feature. :-) You sold me on that already. My additional concerns depend on what we do about import-by-revision, or some other way to deal with module changes over time, especially my favorite target -- interactions between grouping/uses/augment across modules, over time. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 12:16:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59573A695B; Wed, 13 Aug 2008 12:16:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412523A6C21 for ; Wed, 13 Aug 2008 12:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0KnE3MjsVRi for ; Wed, 13 Aug 2008 12:16:54 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 82E023A695B for ; Wed, 13 Aug 2008 12:16:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 12:16:51 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 12:15:52 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 12:15:52 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 12:15:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7DJFou77261; Wed, 13 Aug 2008 12:15:51 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7DJCU6B018193; Wed, 13 Aug 2008 19:12:30 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808131912.m7DJCU6B018193@idle.juniper.net> To: Andy Bierman In-reply-to: <48A3304F.8050603@netconfcentral.com> Date: Wed, 13 Aug 2008 15:12:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 13 Aug 2008 19:15:51.0449 (UTC) FILETIME=[0017D090:01C8FD79] Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I am on board with the feature feature. :-) >You sold me on that already. Cool. >My additional concerns depend on what we do about import-by-revision, >or some other way to deal with module changes over time, >especially my favorite target -- interactions between >grouping/uses/augment across modules, over time. So what issues do you see that import-by-revision doesn't solve? To me, it permanently fixes the content (and the contract) of the module. New revisions of imported modules require specific action to migrate the content (and renew the contract). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 12:31:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1C43A685B; Wed, 13 Aug 2008 12:31:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD6D3A685B for ; Wed, 13 Aug 2008 12:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhrTH1SkPABx for ; Wed, 13 Aug 2008 12:31:39 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id AC21C3A6A58 for ; Wed, 13 Aug 2008 12:31:39 -0700 (PDT) Received: (qmail 96743 invoked from network); 13 Aug 2008 19:31:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2008 19:31:41 -0000 X-YMail-OSG: 1aeq_6wVM1mFTzd1CDoLogvEoRTUUAeko10zcPsw4n1N_1N3mW9CE0Ih_DxwmWDNfUxH0pCc7V8osnGwYu0yzKEC2hMIdOhgBnSyQskUsA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A3369C.6010506@netconfcentral.com> Date: Wed, 13 Aug 2008 12:31:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808131912.m7DJCU6B018193@idle.juniper.net> In-Reply-To: <200808131912.m7DJCU6B018193@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I am on board with the feature feature. :-) >> You sold me on that already. > > Cool. > >> My additional concerns depend on what we do about import-by-revision, >> or some other way to deal with module changes over time, >> especially my favorite target -- interactions between >> grouping/uses/augment across modules, over time. > > So what issues do you see that import-by-revision doesn't solve? > To me, it permanently fixes the content (and the contract) of the > module. New revisions of imported modules require specific action > to migrate the content (and renew the contract). > import-by-revision could work with the right change control rules. I already said I think that solution is the least painful route. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 13 18:43:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F4D3A6A8C; Wed, 13 Aug 2008 18:43:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009EF28C1BE for ; Wed, 13 Aug 2008 18:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCX9vkKHEDuP for ; Wed, 13 Aug 2008 18:43:12 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 3BF6328C1C7 for ; Wed, 13 Aug 2008 18:43:11 -0700 (PDT) Received: (qmail 49450 invoked from network); 14 Aug 2008 01:43:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2008 01:43:11 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A38DAD.4070201@netconfcentral.com> Date: Wed, 13 Aug 2008 18:43:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] augment and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I've been thinking about this issue some more. There is nothing wrong with a nested augment-stmt adding mandatory nodes to some data structure. The obvious use-case is augmenting an expanded uses-stmt object. However, an external augment (i.e., augmenting a different XML namespace) MUST NOT contain any mandatory objects. This breaks backward compatibility. Also, any augment-stmt with a 'when' clause configured MUST NOT contain any mandatory nodes. A mandatory node must always be provided by the user. By definition, the when clause is not 'always'. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 14 07:35:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D913A68CC; Thu, 14 Aug 2008 07:35:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F903A68CC for ; Thu, 14 Aug 2008 07:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRA6TnezYa1y for ; Thu, 14 Aug 2008 07:35:06 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 117BE3A6BD1 for ; Thu, 14 Aug 2008 07:35:05 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7EEYsuL032058; Thu, 14 Aug 2008 17:35:07 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Aug 2008 17:34:58 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Aug 2008 17:34:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 17:34:48 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F266045C9517@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netmod] Augmentable Groupings Thread-Index: Acj+GueDQFj9z6PmQWqN/jhdHp81GA== From: To: , X-OriginalArrivalTime: 14 Aug 2008 14:34:49.0658 (UTC) FILETIME=[E81871A0:01C8FE1A] X-Nokia-AV: Clean Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Phil Shafer phil@juniper.net wrote: > bernd.linowski.ext@nsn.com writes: > >But in this case you should not augment the NetworkInterface grouping > >but rather augment HC features to the place where HC support > is needed. > > The scenario remains. If anyone can augment a grouping, one module's > augmentation can interfere with the use of the grouping in another > module. If you allow augmenting of groupings, you lose control of > what a module gets when they say use a grouping. Yes - but due to the fact that augmentation already exists in YANG it always can happen that you get stuff into the data you wouldn't expect there. The user needs to be aware of this fact in general because of augmentations. > > >Of course, in this case only one of the two IETF standards can > >be implemented. > > This would be an unacceptable outcome. > > >To avoid such a problem standard body A should extend the module > >in a consistent manner - based on input of standard body B. > > This may not be possible. If A's module is already published, > B simply cannot use that grouping. This would require that any > modeler that wants to use a grouping must understand all the other > module writers that have augmented that grouping and avoid groupings > that are augmented in unacceptable ways. This is unworkable. So what would be the alternative? Standard body A augments some places where a particular grouping is used. Standard body B augments the same places where this grouping is used. Assuming the additions of A and B are incompatible the effect would also be that an agent can only implement A or B - but not both. The root cause is in my opinion that augmentations always have the risk of creating broken data node trees in case an agent wants to support different models specified by bodies that do not coordinate their work. Paraphrasing your statement above, with augmentations as it is defined today, it requires that any modeler who wants to augment a data node must understand other modules that have augmented that data node and avoid augmentations which are incompatible. > > Worse, add a mixture of standard and proprietary modules. If > I'm a making a proprietary model and want to use a grouping > defined in a standard module, I cannot since I must be aware > of the possibility of another working group augmenting that > grouping in the future in ways that are incompatible with my > use of the grouping. IMO "augmentable grouping" feature gets blamed for the fact that it makes apparent that augmentation in general could have undesired effects if not used correctly. BR, Bernd > > >The effect of that is that the HC-counters are in > >the namespace of the vendor specific module. So > >clients that only understand NetworkInterface and > >NetworkInterfaceExt don't understand the > >HC-counters as they are in a non-standard namespace. > > I would contend that this is a feature, since the bits you are > adding that are _not_ in the original module are unknown to > applications that only understand the original module and _should_ > be in a distinct namespace. > > Worse, if you put these augmented nodes in the original namespace, > you become ambiguous if the original module's author adds those > nodes to their module. > > Thanks, > Phil > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 14 08:49:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9D43A6DD3; Thu, 14 Aug 2008 08:49:23 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C5B3A6DD3 for ; Thu, 14 Aug 2008 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnk9tPxPV-UP for ; Thu, 14 Aug 2008 08:49:22 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id A5FF03A6DB6 for ; Thu, 14 Aug 2008 08:49:22 -0700 (PDT) Received: (qmail 49048 invoked from network); 14 Aug 2008 15:48:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2008 15:48:54 -0000 X-YMail-OSG: qLWHRFgVM1lRmcij2nbxaGRsdl9GclrCoexxLJqsAJWIkLRAMtK112_uhfKpe9MOevmDO8QpxjfpC4GJe.XK7B7L3bt36uvKrrYUPlTOEQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A453E4.6090903@netconfcentral.com> Date: Thu, 14 Aug 2008 08:48:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] error-message clause X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I think we might end up expanding the 'configured errors' construct used in the must/pattern/length/range clauses. As I'm writing code, I noticed that even though the error-message clause can override the internal msg string, I am still hardwiring the xml:lang attribute to 'en'. Perhaps an optional 'error-message-language' clause is also needed? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 14 09:39:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134D63A6B7F; Thu, 14 Aug 2008 09:39:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7EB3A6C70 for ; Thu, 14 Aug 2008 09:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGpkFhtOID3x for ; Thu, 14 Aug 2008 09:39:27 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 1D7A13A6B7F for ; Thu, 14 Aug 2008 09:39:26 -0700 (PDT) Received: (qmail 59164 invoked from network); 14 Aug 2008 16:39:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2008 16:39:19 -0000 X-YMail-OSG: 7v5ToDkVM1nIRoM9onqXPRIyqEZemTGAJsYoFgd8lJa.hfIHEXyxSKl8O6ObloAvWaE7Nl_ar5ih9eUglNqTTffWXWVwixPYaAqi18kqFg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A45FB5.8000500@netconfcentral.com> Date: Thu, 14 Aug 2008 09:39:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] section E.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The error appendix section E.4 needs to say that it defines the default error-app-tag field, if no error-app-tag statement is present. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 14 10:21:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837043A6AF0; Thu, 14 Aug 2008 10:21:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145D53A6CC4 for ; Thu, 14 Aug 2008 10:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v+HUQ8Og3za for ; Thu, 14 Aug 2008 10:21:00 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 52ECA3A6AD4 for ; Thu, 14 Aug 2008 10:21:00 -0700 (PDT) Received: (qmail 25763 invoked from network); 14 Aug 2008 17:21:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2008 17:21:02 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A4697C.1090202@netconfcentral.com> Date: Thu, 14 Aug 2008 10:21:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group References: <48A45FB5.8000500@netconfcentral.com> In-Reply-To: <48A45FB5.8000500@netconfcentral.com> Subject: Re: [netmod] section E.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > The error appendix section E.4 needs to say that > it defines the default error-app-tag field, > if no error-app-tag statement is present. > I also think this section needs to be split into 2 sections. The must-stmt error-tag is clearly operation-failed, as specified. What is a 'when' statement violation? I do not see any text in 7.15.2 about it. If a manager sets a node that is not really there, then the unknown-element error-tag is sent. The length, range, and pattern error-tag should be 'invalid-value', not 'operation-failed'. IMO, it would also be better to have 1 error-app-tag for length/range exceeded and another for pattern test failed. (Strings can have both length and pattern, and the manager needs to know which one failed. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 14 12:08:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D685A3A69D8; Thu, 14 Aug 2008 12:08:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF57C3A69D0 for ; Thu, 14 Aug 2008 12:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WtUcq5jarml for ; Thu, 14 Aug 2008 12:08:57 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C8FEF3A69CA for ; Thu, 14 Aug 2008 12:08:56 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 8A17A76C32E; Thu, 14 Aug 2008 21:08:56 +0200 (CEST) Date: Thu, 14 Aug 2008 21:08:52 +0200 (CEST) Message-Id: <20080814.210852.214923410.mbj@tail-f.com> To: bernd.linowski.ext@nsn.com From: Martin Bjorklund In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F266045C9517@esebe103.NOE.Nokia.com> References: <46DCD7DCAFF0E94796B7C2894ED9F266045C9517@esebe103.NOE.Nokia.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, wrote: > Hi, > > Phil Shafer phil@juniper.net wrote: > > The scenario remains. If anyone can augment a grouping, one module's > > augmentation can interfere with the use of the grouping in another > > module. If you allow augmenting of groupings, you lose control of > > what a module gets when they say use a grouping. > > Yes - but due to the fact that augmentation already exists in YANG > it always can happen that you get stuff into the data you wouldn't > expect there. But this is different. Normal augment is explicit. In your interface example, when you do your explicit augmentations, you will not augment the "slow-dudes" list with HC counters. But you do get into this problem if you augment a grouping. So IMO, this is a problem with the proposed new feature. > > >Of course, in this case only one of the two IETF standards can > > >be implemented. > > > > This would be an unacceptable outcome. > > > > >To avoid such a problem standard body A should extend the module > > >in a consistent manner - based on input of standard body B. > > > > This may not be possible. If A's module is already published, > > B simply cannot use that grouping. This would require that any > > modeler that wants to use a grouping must understand all the other > > module writers that have augmented that grouping and avoid groupings > > that are augmented in unacceptable ways. This is unworkable. > > So what would be the alternative? > Standard body A augments some places where a particular grouping is > used. > Standard body B augments the same places where this grouping is used. > Assuming the additions of A and B are incompatible > the effect would also be that an agent can only > implement A or B - but not both. You don't have to go to augment to find this (theoretical?) problem. What if std body A defines a module w/ some objects and std body B another module wih some objects, and they are incomatible? Then a device cannot implement both A and B. I don't think this is a problem for augment. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 14 14:01:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109083A67BD; Thu, 14 Aug 2008 14:01:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833B93A67BD for ; Thu, 14 Aug 2008 14:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibpJy8NBXeSv for ; Thu, 14 Aug 2008 14:01:12 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id D01063A69D0 for ; Thu, 14 Aug 2008 14:01:12 -0700 (PDT) Received: (qmail 33862 invoked from network); 14 Aug 2008 21:01:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2008 21:01:16 -0000 X-YMail-OSG: qc._dNAVM1mqmL2RglJQlqOaKO4mfFCRRVWlqAeVdH7RNs8v.oSytw2aDPCd2Rueay__O5JtxaWuaUeJL.A5xLwJYT.Iyro2.BmgHpCPMw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A49D1A.10401@netconfcentral.com> Date: Thu, 14 Aug 2008 14:01:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I know this is a sore topic, but an important one. An important use-case for with-defaults=true is the off-line validation of database changes by a manager. A manager should be able to retrieve all the agent schema-discovery data, and a complete . Given the YANG modules that the agent is actually using, plus a complete element, a manager can perform all the 'must', 'when', and 'unique' tests (along with all the value checking tests). (OK, add in Martin's platform 'overlay' and the data is complete.) However, if the must and when XPath expressions break if a leaf contains the agent default, and works if the leaf contains a manager value, then the value of these statements is severely diminished. Or, if the XPath magically works on the agent, but nodes referenced in the XPath expression do not get returned in the because they are the default value, then the same XPath will not work on the manager. This breaks the manager's ability to test config changes offline. IMO, this is an important feature. (Not everybody just flings commands at a router to see what will happen ;-) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 14 16:11:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3161D3A6A70; Thu, 14 Aug 2008 16:11:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F6C3A6A78 for ; Thu, 14 Aug 2008 16:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onjXwFxjnpC4 for ; Thu, 14 Aug 2008 16:11:29 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 6A5583A68A6 for ; Thu, 14 Aug 2008 16:11:29 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id 2M8T1a0050FhH24A1PBZMR; Thu, 14 Aug 2008 23:11:33 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id 2PBV1a00T4HwxpC8UPBWu2; Thu, 14 Aug 2008 23:11:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=SSrnItO0qubmSVeBmWsA:9 a=W6uTyS0wa4tBw6Ta0b00RFz-FdAA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=c5zHXd76wwQA:10 a=vj2nFF74AAAA:8 a=_GvNhCDSv1A3ZLxvYqkA:9 a=jr2-Y1qWb9T88zHUms0A:7 a=-mXosvDL-UQ-HneW74WeAPs4V1kA:4 a=5QnYhFGni70A:10 a=0dRpvnS4h04A:10 From: "David Harrington" To: Date: Thu, 14 Aug 2008 19:11:29 -0400 Message-ID: <072501c8fe63$16812940$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0726_01C8FE41.8F6F8940" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acj+YxU1eH9xC27OS9WqHsaRJgtzAQ== Cc: netmod@ietf.org Subject: [netmod] ietf72 netmod session minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0726_01C8FE41.8F6F8940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0726_01C8FE41.8F6F8940 Content-Type: text/plain; name="IETF72-netmod-minutes.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IETF72-netmod-minutes.txt" Minutes from the NETMOD session, 31 July 2008 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D audio archive: = http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch4-thu= rs-am.mp3 1. Session started at 9:00, blue sheets were circulated. 2. Agenda bashing - no objections raised. David H: we have two sessions this week. The first session will be = higher=20 level abstraction of the documents and how they fit together.=20 Tomorrow's session will be a highly technical discussion of open = issues. 3. David Partain presented the WG status: - WG has an aggressive deadline, all work should be finished in September 09 - Architecural document is needed, no draft is available yet, Phil and Ladislav will work on it - YANG draft is in a good shape - datatypes draft is ready for becoming WG deliverable - DSDL mapping draft will be a merger of the two existing individual drafts, to be finished in September 08. 4. Phil Shafer: NETMOD Architecture Discussion: Sharon Chisholm: Since there is no architectural draft, where can contributors send stuff? Phil: To me. Dan Romascanu: The architecture should be described in an informational draft. David P.: That's the plan. David P.: WG has to decide whether to address YIN and YANG in separate documents or not. Andy Bierman (via Jabber): In the use case#2 in th epresentation, = =20 How can an agent generate RPC error messages? Tony Finnerty: RPCs were not explained in the presentation. Balazs Lenygel: Isn't it more a question for the DSDL mapping? David P: The presentation is a tutoiral and not fully detailed.=20 Please ask the question on the mailing list. 5. Martin Bjorklund: YANG - A Data Modeling Language for NETCONF Slide #2 Sharon: What are the reasons for and advantages of having modules and submodules? Martin: Submodules share the namespace with the main module they belong to, modules must use different namespaces. This also allows=20 developing big modules in smaller pieces. Slide #7 Bernd Linowski: Can you model a set with YANG lists (unique elements, order not important)? Martin: Yes, that's the default. This is the high level desc,=20 so I haven't shown it. Order by user or by system. Leif Johansson: Is unordered list different from a set? Martin: No, it is the same thing. Wes Hardaker: Keys have to be unique? Martin: Combination of keys must be unique. Slide #8 Leif: Is leaf-list still a set? Martin: Yes. Leif: But it could be useful to have repeated values, for example array of integers with non-unique entries. Andy: Values needn't be unique, there are no keys in a leaf list. Martin: In leaf-lists the value is the key, so it must be unique. A leaf list entry is uniquely identified by it's value. Have to=20 model this in slightly different way if it's what you wanted. it=20 must be possible to manip this list. Whith multiple entries, how=20 will you refer to entries? David P. (as chair): Please take it to the list. Slide #11 Bernd: Inside rpc, can you have typedefs and groupings? Martin: Yang provides locally scoped typedefs and groupings Bernd: Then they can only be used in input part of RPC? Martin: They can be anywhere in the module hierarchy. Slide #12 Leif: Is the YIN representation unique? Martin: Yes, modulo whitespace and namespace prefixes. David P.: The rules how to make YIN from YANG will be in the specification. Slide #16 Tony: Is modularity in YIN different from YANG? is the intention=20 to have mapping into one file? Martin: No, the mapping is pure syntactical, not semantic. It's exactly the same, modules in YIN correspond to modules in YANG, and similarly for submodules. Slide #21 Bernd: The instance-identifier type uses XPath. Another option would be to represent it explicitly with XML structure. Why XPath? Bernd: In yang there's a modeling feature, instance identifier.=20 XML as XPath expression. Another option would be to encode the key=20 value of every element of the path in XML elements and sub=20 elements. Why was the xpath chosen and not something like this=20 which is more xml is since it doesn't require you to understand=20 xpath. Martin: XPath is less verbose. Bernd: But XML is supposed to be generated and read by machines, so it doesn't matter. David P. (to Bernd): good to post to mailing list and offer an=20 alternative text if what's there is not optimal. Not going to be=20 able to do that here now. Offer some examples for us. Suggest the=20 alternative on the list. Leif: Primary reason is XPath is a standard. Leif: Are basic types in yang mapped to XSD types? Is it lossy? Martin: Yes, the DSDL draft have a table that shows the mapping. J=FCrgen Sch=F6nw=E4lder: Mapping of YANG types to XSD will be = discussed later on. 6. J=FCrgen Sch=F6nw=E4lder: Common YANG Data Types Sharon: Are these datatypes mappable to XSD datatypes? are the xml,=20 base data types, going to be mappable to behaviour you'd expect=20 from base data types. ints will behave same as xml schema? Data and=20 time will behave the same? Requirement. J=FCrgen: I propose the mapping be specified in an appendix of the=20 draft, and explain how this relates or not to the OPSAWG-XSDMI=20 defintions. Sharon: I Hope that's primary, The XSD defs used for specifying=20 xml are more important than mapping to smiv2 ints eg. Benoit Claise: If other groups such as IPFIX come up with datatypes that are of general interest, will NETMOD WG adopt them? David P.: Definitely, send suggestions to the mailing list. Andy: I am concerned about duplications. J=FCrgen: This is a natural evolution, no need to get worried. 7. Sharon Chisholm and Lada Lhotka: Mapping YANG to DSDL Balazs: You have to specify what the DSDL schema is actually supposed to be used for - validation of datastores, get-config PDUs, RPCs, notifications,...? Lada: The output of the DSDL mapping can be used in principle (possibly in transformed form) for all of these purposes. The same question can be posed to YANG itself. Phil: So you can select the form of output suitable for each particular purpose, e.g., via command line options? Lada: Currently no, it would need post-processing using other tools. Command line options only allow you to select which of the schema languages are included in the output.=20 David P: is this code available in what martin pointed to on the=20 web already? Lada: yes. David P: you've agreed to merge two docs and take out the bits=20 that don't have to do with mapping? And you think you'll have that=20 done by September? Lada: Yes. David P: We like you! Lada: It's easy to promise :-) David P: Suddenly we like you less :-) Balacz: ealier we had a debate, what is DSDL describing? Data model = or=20 schema for individual ops? You have seperate schema for rpcs, so we = get=20 back to that topic. Is this something directly usefulo for ops or=20 conceptual? Sharon: Both in DSDL as well as yang, need to make sure we specify = server=20 side conformance as well as client side. Need to specify whether=20 individual content is valid, we need to support both of those. Hope = this=20 is supported in YANG as well as DSDL. Lada: Currently tool discards rpc notifications, not good of course,=20 currently output of translation is schema of full translation same = as=20 yang expresses in it's main part acceptable to rpc notification. If = you=20 want YANG or DSL schema for validating netconf bus, need to apply = some=20 transformations to it to do it, but it's quite no problem. Andy Bierman via jabber: multiple roots is OK in XSD. Lada: not in XML, may not map to relative form in xml doc IIRC. Martin: when mapped to netconf BUs everything will be well formed, so = there=20 is no stand alone doc containting multiple top level nodes. Back to=20 Balacz's question: what are we trying to define with XML schema? Both? = You would=20 have to generate one scheme for top level node and one schema for all=20 the modules, so it doesn't solve that problem I think. Lada: conceptual tree would solve these issues, but need to look for=20 specific examples. Balaj: need to state more clearly how many modules for... Other places=20 one schema per module. State more clearly in next version. Lada: can use output of translator for validating. Phil: you can do it the other way: DSDL decribe a wrapper, but the=20 config in that wrapper, may be easier. Phil: schema describe edit config etc, all the other places we use... Lada: same stuff as expressed in YANG. You will have to extract that = part=20 from the main config tree to put optional to all elements. Will require=20 some translation of full schema. If you try to convert straight from=20 YANG, will be no different. Phil: don't know DSDL, but thought you can turn on/off parts of the = machinery. Lada: you can use command line options for translator to switch on/off=20 parts of vocabulary. You can get it no problem. Phil: Is there some way to make the content of the rpc section extend a=20 base netconf rpc and then you just add to that with the rpcs defined in=20 the new module. Lada: haven't thought about this. Asked you today about example. Phil: dsdl has that ability: std netconf module describes rpc tags,=20 notification tags, in dsdl generated from yang you describe additional=20 tags to base module Lada: ... Not targetting specific task of validating additional... Phil: that's one of the things I want to validate with dsdl. Lada: me too. I think it's the next step David P: Let's see what they put in the draft and take it from here. David P: the draft will be the beginning of september? David P: So the answer was both, right? with a little effort, both? Lada: Up to us to decide here. 8. David Harrington - Consensus for Adoption of Drafts as WG Items YANG draft - full consensus for adopting. YIN separated from YANG?=20 The chairs read consensus of the mailing list to be that YIN should = be kept=20 in YANG spec. A call for objections showed no objections in the room. Separate document for XML mapping?=20 The chairs read consensus of the mailing list to be that the XML = mapping should=20 be kept in YANG spec. A call for objections showed no objections in = the room. Datatypes=20 The chairs read consensus of the mailing list to accept the = schoenwaelder draft =20 as starting point for YANG datatypes. Any objections? No objections. DSDL mapping draft will be merged from the two existing individual drafts, stuff that is not related to the mapping has to be removed. When published, the WG can talk about adopting this into WG charter. Sharon: Should the merged document be submitted as an indvidual draft first: David P.: Definitely, the WG cannot accept it as a WG item without seeing it first. True also for architecture doc. After couple of weeks we'll issue a = consensus call to accept the individual draft as a starting point for the WG = draft. 9. J=FCrgen: Data Type Issues David P: ho wmnay people have read this draft? a significant show of = hands Issue #1: We have two uri types; the suggestion is to keep it in inet-types. no objections Issue #2: Allow multiple patterns as in XSD? Suggestion: YES Phil: I am for this, and it supports multiple error messages Andy: Get this from ntypes - already supported in YANG Phil: But in a hacky way. No objections in the room to supporting this. Room consensus is to = allow it. Andy: This is too complicated. Phil: what's complicated about it? David P: send to mailing list Issue #3: - Define groupings along with types? Suggestion: YES, but be very conservative. Balazs: We should be really very careful with adding groupings. We = could be=20 revising the document monthly. Leif: What is the difference between grouping and typedef? Is it the modifiability of groupings? Reusable typedefs are a good idea. = But groupings can be modified after definition. David P. No, grouping *currently* cannot be modified according to = YANG. David P. (as contributor): I support adding groupings in a separate = document=20 as long as they are reusable. If we have things that will be reusable = we should put them someplace so they can be reused. Phil: Conservative opinions are hard to get by consensus. How do keep = things conservative when we often let things slide. J=FCrgen: One approach is to require that there be a module using it. David H.: In the MIB world, we have a web page with pointers to = reusable=20 textual conventions. That way you do not have the document revision = problem. Leif: I suggest a directorate to approve reusable definitions similar = to MIB doctors. David P: I like after-the-fact, because that shows it is useful, and = possible used in multiple places. Sharon: After the fact it may be too late, Once it is used, it can = cause=20 backwards compatibility issues. We need to predict what types will be = reused. Andy: Modelers can import just the reusable bits. No objections to adding them; Sense of the room is to support this. Issue #4: - IEEE types: coordination with IEEE required Dan: Cooperation between IETF and IEEE is usually smooth, because = there are a number of people here that are also involved in IEEE 802.1, and there = are official liasions to and from 802.1. Dan will be the contact person. Dave H: IEEE has adopted MIBs, but has not yet adopted YANG, so this = work=20 should be done here. Dan: other IETF WGs are using IEEE structures, so there is good = reason to=20 standardize these structures in YANG. Issue #5:=20 Boilerplate information should be similar to IETF MIB modules, where = certain=20 information is required: contact information, organization, etc. This can be added once the draft is adopted as a WG item. Not controversial Issue#6:=20 - Introducing other IEEE types, e.g., vlan-indexes. ... We should be sure we need them and what the representation should be. David H.: In MIBs various groups were defining them in inconsistent = ways, so the IETF worked closely with IEEE to decide on the = representations. Those are the definitnons I suggest be added. Dan: we should look at what TCs the IEEE has added since taking over = the=20 Bridge MIBs to make sure what we define is consistent with current = IEEE standards and TC definitions. Wes: Publishing the TC-like things in IETF via RFCs is a lengthy = process. If we want to make this easier, we should outsource it to IANA, much = as we=20 have done with ifTypes. David P: This is a process issue and we would need to talk to the = area director Dan (AD hat off): We can outsource it, but should we? Designing = textual=20 conventions would have an impact on how it's going to be used. This = needs more than one expert's view, and I would be very careful outsourcing this. Sharon: We sould make the definitions URL-accessible. Let's create a NETMOD directory and make sure the URIs resolve to URLs. We = discussed this earlier and were blocked because of network traffic issues. We should = try to=20 get IANA to provide this type of support. J=FCrgen: We have to make sure first that we properly understand the process, and the issue might impact our ability to complete the WG=20 deliverables by 2009. This is something to keep in mind, but let's = defer it. Wes: I do agree revising an RFC is not that difficult, it is just = slow. I=20 would like to avoid the approach sometimes taken with MIB modules, = where the=20 TCs are published in little tiny MIB modules. 10. Other Discussion - David P. announced that a NETMOD wiki will be set up where all outstanding issues will be recorded and tracked. And thanks to = Henrich. This will document the open issues, and the closed issues. - We will not finish all detailed discussion of issues this week. The chairs propose an interim meeting for October 8-10, on the east = coast of the US, to go through open issues and close them. The dates unfortunately conflict with Yom Kippur. A show of hands shows 10-12 people in the room would attend. How many want to attend, but cannot on Oct 8-10? 3 hands How many could attend Oct 15-17 that could not attend 8-10? A number = of people=20 said it would make it harder rather than easier. Dan: We have to make sure the the interim meeting will not exclude people from the process. Ask if anybody objects. David P: Does anybody object to holdin gan interim meeting? No = reponse Dan: Consider other means - voice or videoconferencing.=20 David P: They are a bit difficult with participants in several time = zones,=20 and virtual meetings might end up excluding more people than an = interim. We believe teleconferences are viable for editing conferences, but the = number of attendees would seem to preclude a teleconference. Dan: Even with an interim, we should try to support alternative = methods of participation. J=FCrgen: Whiteboard is by far the most productive tool. And even if = we reach=20 consensus, we still need to take issues to the mailing list. Sharon: We should figure out how to use Voice Conferencing = effectively, to help=20 reduce travel costs. Other SDOs are effectively doing it. There are = tools to do=20 this effectively. We should not rule these things out. David P: we have not ruled out any tools; the chairs have not = discussed the possible alternatives to supplement how we work together. Dan: IESG is discussing this issue right now. They are encouraging = the use of teleconferences in the IETF. Andy: what about jabber? David P: It depends a lot on what the interim host can provide for = Internet connectivity. David Kessens: Some people prefer to meet virtually. How many would = prefer a real face-to-face meeting (about 10), and how many would prefer a = virutal=20 meeting (about 5)? Wes: A good option is to combine face-to-face meeting with virtual means. David P: the chairs will try to ensure there are remote options = available. Wes: There are some virtual whiteboards available. David P: We are looking for hosts. Please contact the chairs if you = think you can host the interim. Consensus was to hold a face-to-face meeting on 8-10 October, venue will be specified later. The Thursday meeting was closed at 11:32. ------------------------------------------------------- Friday Meeting audio archive: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch5-fri= -am.mp3 continuing with technical discussion started on Thursday. - Juergen issues on datatypes Issue #6: - ieee types Eric Gray is liaison + Dan 802.1p work is in progress that will redefine the existing Bridge = mib=20 modules and TCs. They have also created additional TCs. We should review these and decide which we should adopt here. Bert will send new ieee 802.1 TC MIB module to list - issue 7 Do we make IANA suggestions for namespace names? In MIBs, IANA could simply assign the next number; now we need to provide = suggested names to IANA. This is just a procedural issue, so all YANG modules recommend the name for the namespace and the module.=09 Lada suggests one URI for YANG and then subdivide for various groups Proposal to use NETMOD instead of YANG in current draft, so the=20 namespace is not specific to the language used. Sharon: we are already doing some XSD schemas in Netconf Not=20 Content. We should dfeine a tree and subdivide it by content. Juergen does not care so much, except that the name needs to be = unique LADA and Sharon to send suggestion(s) to the mlist =20 - issue 8 XSD translation Proposal to add XSD translations in an appendix. Sharon wants XSD types to be baked into the core of YANG, not just = an=20 appendix. We sghould not get creative with core datatypes. Juergen: it is about the new types that we create in YANG, should we = put the XSD version (generated by aiutomatic translation) in an=20 appendix of the document. This would be a courtesy for people to see = them directly in the document Seems Sharon and Lada worry that this is of no use to RELAXNG (and=20 DSDL) Juergen: But that is not the intent. This is for stuff created in = the=20 document, not the base types. Sharon: In Philadelphia, we agreed there should be an appendix for = the=20 DSDL translation, and I would like to also see an appendix for the = XSD Juergen: the DSDL is the outpu tof the DSDL mapping work.=20 David P: this work is about definition of yang types, and this would = just be a courtesy to put the corresponding XSD in an appendix. The=20 DSDL work would go in the chartered DSDL mapping document. But we = are=20 not chartered to produce a document with XSD, so this is just a=20 courtesy, especially for the XSDMI effort in the OPSAWG WG. Lada: is this complex types? Juergen:=20 Lada: this would not be of use to DSDL Juergen: there are a number of WGs using XSD, and this would also be = a=20 courtesy to them. It would help them understand YANG. Lada: We agreed DSDL was the other format we would use. I would = prefer=20 to publish the RelaxNG rather than XSD translation, since XSD is not = in the charter. Bert: I would prefer it be available in an appendix. We define the=20 rules about how to translate yang to XSD, right? David P: No. we are not chartered to do XSD translations. This is a simple automated translation for Juergen. Lada: I recommend doing both RelaxNG and XSD in appendices. Bert: that would be OK with me. Juergen: is there a tool available to translate to relaxNG? I do not = want to have to manually add translations David H: I recommend the top of the appendix state that this is not=20 within the scope of the WG, is non-normative, is provided solely as = a courtesy, and the appendix might be removed in the future. - issue 9 - document differences Juergen wants to be very clear about the differences of the yang = types=20 and their SMIv2 'equivalents'. 3 examples discussed/presented Sharon: there is not much value to move away from the existing = base/core=20 XSD and SMIv2 types=20 Juergen, it depends on each datatype that we look at. The = Date-and-time=20 case is clearly one where we want to deviate and use the IETF agreed = =20 RFC3339 concept.=20 So we need to take this to the list on a case by case basis and be = precise=20 about how and why it differs. Sharon: there is not muchg value in doing SMIv2 compatibility David P: There is definitely value in preserving the information = models=20 that operators already know. Consensus call:=20 Leif agrees as long as we also have a "faithful" definition for the=20 old/existing SMIv2 types DBH: didn't we already discuss date-and-time on list? Isn't that a = closed=20 issue? as new chairs, we really want a chance to use our power to = say "that=20 issue is closed" ;-) Wes agrees that it is mandatory to describe/document the differences for those that we take from base XSD. We may end up defining a lot = of=20 little spcial datatypes that we would better use the standard XSD = types for - issue 10 translation rules Juergen suggests to add disclaimers for bidirectional and = unidirectional translations. We should be precise about which might be useable in a = bidirectional way, versus unidirectional Sharon: why is this different than issue 9? Juergen wants to be precise (it is one para for the whole document). = This=20 would be described, maybe in a table, that says this type allows=20 bidirectional mapping? dbh: are you suggesting adding a field to mark a dataype as = 'equivalent' Juergen: we must define 'equivalent'; a table that says these are equivalent is all we need. Sharon still thinks this is a duplication of issue 9. Can you submit = text=20 so we can consider? Juergen: it is certainly related David P: any other comments? I think looking at the text is fine. Go = ahead=20 and add this to the document so we can consider it. =20 - Martin YANG Open Issues -Controlling features 4 slides optional-to-implement features need a complete module for the data this could result in many small modules The capability list will be very long Proposed solutionL 2 new statements (feature and if-feature) and add = an rpc get-features. You can turn on/off different features. DaveParain (DP) is this sort of an #ifdef? dbh: instead of if-feature can you use when-feature (for = consistency) Martin: it is a bit different though ("if" is a compile-time = decision, but=20 "when" is a dynamic runtime decision) Lada suggests that "when" becomes first class. Using when to test = for a=20 static state (feature is/is-not supported) Martin: That is a different issue though. DP: let us not worry too much about the name now, but if we need the = feature BL: thinks the idea is great, but objects to the special rpc. We = should=20 just use a simple get to determine what is supported. and objects it to being when-feature;=20 DBH: we need to be watch out for too-many optional things. There was = a=20 discussion in SAAG ysterday about why IPsec VPNs have been less = successful than SSL-VPNs, and once consieration is that there are so many = options in=20 IPsec, it is difficult for operators to deploy. If we add to many = switches that vendors can turn on and off, or choose to support features or = not,=20 then netconf may become too difficult for operators to deploy, and = they=20 may just ignore netconf. The IETF is about developing interoperable vendor-neutral **standards**, and going down the road of making it = easy to=20 have lots of optional things hurts interoperablility and is going to = hurt=20 our long-term effort. DP agrees to some extent. But there is the reality vendors will also = use this language and some features may apply to some devices and not = others.=20 This will eb useful to write one module that has conditional = features, and=20 the same module can be used by different divisions in the company, = with different features enabled. dbh: just watch out for deployability mark: to respond to David's comment, we tend to do this with = sub-modules=20 rather than large modules with lots of conditions. Andy: is if-feature top level or nested? martin: it can be nested. If you go back a slide; oh, it is = top-level. mark for andy: can you import a feature across modules: martin/dp: not sure. good question, but no answer yet Mark: I think Andy might be asking if=20 Leif: maybe it is usefull to point out (in doc) the difference = between=20 compile time and runtime agrees with dbh that there is the risk of feature creap but you will need a feature rich language if this YANG is to be=20 usefull acroos IETF/Internet we must decide if we want a really scaled down language or not Leif thinks you will need it DP: concludes that Leif supports the feature Leif: sort of. maybe better to be a compile-time evaluation. you = need to=20 clearly spell out when something is a compile-time versus runtime = decision martin: ok need to be more clear in the document what this is Phil: it is both compile-time and run-time it may be compile-time on the device, which might support ethernet but it is runtime on the netconf server which needs to determine the = ifType=20 to see if the device supports it. on the application side, you need to query what is supported to know = whether to apply the application logic. Leif: that tells me you really need a sort of a class-member = concept, so you can apply compile time optimizations. so it needs more thought how we design this optional stuff I think the feature is nice, but it needs more thought.=20 phil: support this feature two other WGs who are developing yang modules need this this is somewhat more rope, but not too complex dp: we must be carefull what we throw in. This looks reasonable to = me it is a balancing act phil: it is a balancing act. You don't want to add sharp knives = everywhere,=20 but if you need a sharp knife there is no substitute. sharon: we have the concept of conditional conformance in our = company=20 schema definitions, but we find this can be done through nesting = rather than needing a tag on individual elements.=20 sharon for andy: could be handled via conformance instead of inline=20 if-feature sharon: in my company, we found maintaining MIB conformance = information in=20 two different places within the document (the object definitions and = the compliance groups) was a maintenance nightmare. martin: responding to your comments about maintaining the = information in=20 multiple places, in a container example it applies to whole = container sharon: but you could, and if you make this available then it could = be=20 abused. Adding too much complexity into the model is something to be = aware=20 of. andy: how does renaming and capability into a feature really help? martin it is not really naming. It is given a capability, you can go = look at sub-features for this capability. dbh: so the features would not be exposed in the capability query? martin: no, the capability is exposed and then you can go back and = query=20 the features in the capabilities. marting: we could just stick with the capabilities. However, ipfix = has=20 multiple optional pieces, and reporting every little feature makes = getting=20 a general capailities statement more difficult. It capabiities = reports the=20 general technologies available in the whole configuration, then an = NMS interested in ipfix can go query for the ipfix features withuot = having to=20 get a full report of all the features supported for all the = technologies on the device. sharon: I think understanding the feature set is important. As we = move away=20 from just doing device management to doing capability-based = management, an=20 NMS needs to know what sort of real world technologies the device = supports so it can determine how to manage them. So it's not just a mattter = of the=20 schemas. It is translating from the schema lists into an = understanding of=20 what sort of real world technology things does this thing support. andy: agrees with DBH: try for a first solution that covers 80% of = the=20 needs. Capability+features leads to confusion. martin: problem is that WGs are starting to use this and run into=20 problems right away. Should we just ignore them or try to address = this? sharon: I think we need to consider this more. JS: is feature same as OBJECT-GROUP in SMIv2 that is optional in=20 COMPLIANCE statements martin yes it solves the same problem: So then JS thinks it is good BL: I want to get this clarified. Can features change during = runtime? Likes it. This is more fine-grained than capabilties. He does = not want=20 capabilities for each leaf Andy: This is a slippery slope. We will be adding if-if-else-if-else = in a=20 few minutes when we realize this form of macro is too simplistic. Phil: the choice is to make it a first class feature or not or 2nd = class=20 xpath-function based thing, where you can add ands, ors, and nots, = which=20 makes it both more flexible and more difficult to understand. So I = would rather have this as a first-class if-feature DP: we do not have consensus yet, but the room seems receptive.=20 Need to work it out on the list - IMPORT by revision this has been discussed on the mailing list already. let me recap. currrent mechanism: once a grouping or typedef is defined it can = never=20 be changed. Non-backwards-compatible changes could require a = namespace=20 change.=20 suggestion for solution: allow an optional import by revision, so = you specify which revision you want to import. Then you know just which version of a grouping your module will use. I would liek to add = this. sharon: You don't need this if you have good backward compatibility=20 rules. This is bad thing. And having optional content in a grouping = makes this a more interesting problem. Martin: even with conditional content, you will need this. sharon: I am thinkin gbaout relaxng, and I don't see the need. Is = there=20 something about yang that makes this more necessary? martin: this is when a whiteboard would help. It was discussed in = depth on=20 the ML. Phil gives an example why this is good. Your device code imports a = grouping=20 that has one element. The grouping gets revised with a second = element. My=20 NMS imports the module with the revised grouping and thinks the = device=20 supports the new element. When the NMS tries to set the new element, = the device core dumps (or whatever) Sharon thinks she needs to reread discussion on list Leif: this not a technical problem. It is a core engineering issue. = Be conservative in what you send iand liberal in what you accept. You=20 need something like this because you need to have code freezes. maybe you can do it by carefully enginreering the namespace Sharon: I DO want to get away from revision-based management Lada: IN the XML world, there is a controversy of whether to change = the=20 namespace or using a revision. DO not change the URI for every = revision.=20 WE should define the rules under which the namespace should change. = And not=20 change the namesapce too easily martin: I agree. we have not yet started writing the upgrade rules = yet. Bernd: basically supports the idea if this defines different = versions of=20 a device in the network. Some difference smight be backwards = compatible, while other changes are not backwards compatible. So I would like to = clarify the semantics for revisions JS: this depends on the change rules that we come up with if can manage to avoid this I would prefer to avoid it. it depends on the changes rules andy: if module A imports module B and module C.1, and module B = imports=20 C.2, it that an error?=20 (see jabber log) Bernd thinks it IS an error Martin thinks it is not Martin explains how IMPORT works... seems argument goes away. There = is no=20 recursion during imports. sharon: I can see where this could lead implemnters to do the wrong = thing. Phil likes this DP: need to keep this in lock-step with comformance DP: there is no consensus yet phil: the lock-step issue is real simple. without versioning, you = cannot change something once it is defined. andy: Not true Martin. uses stmt can cause this to be a conflict in = A. DP: Andy pls send to mlist so we can further discuss - Revision Issue Should the revision statement be mandatory also unresolved on ML. = Important for schema discovery and import revision. Currently you can not have = a=20 revision statement. Proposed solution is: make it mandatory. Bernd: supports it. You MUST have this. There is no such thing as a = module that simply exists; it is always relative to the time that it = exists, and you have to . Sharon: This is siilar to the REVIION clause in SLIv2. Hates that = she needs=20 to add this. It feels like a CLR, espeically in the presence of diff = tools. I do not see the value JS: Thinks it is very useful. it helps identify which RFCs preceded = it.=20 DP as contributor: it is abolutely needed Wes: Could do it for IETF documents, but maybe we do not need it for = vendor specific. Why force vendors to add it? Andy: import by revision is less painful... (see jabber) Lada: perhaps it could be namespace and then maybe it should not be=20 mandatory in such cases. would not make it mandatory JS: if you have 2 modules that seem the same, then a revision helps. Bert: why are we even discussing this? how difficult is it to add a = date=20 string? DP: Humm for consensus seems a rough in favor. Take it to list - Revision is currently a date string some want more than just a date; they want a time too. Proposal is to keep it the same DP wants to keep it Dan: we have date/time in SMI. Seems fine Phil: would it be acceptable to have :stuff Leif: was gonna make same statement.: just make it an opaque string JS: Likes just the date If that is not acceptable, then I would = prefer=20 just a number (I cannot do anything with an arbitrary string Dan: It should be sortable. Prefers date and time Bernd: we must have this. But would be happy with an arbitrary = string Andy: it is useful to know which is the older/newer revision Bernd: and what branch DP: don't want to rathole on this anymore; take to list - LADA on DSDL open issues (the first few slides are tutorial in nature; issues start at slide 6 - slide 6 (rpc and notification) rpc and notification statements define content of specific netconmf=20 messages options: - generate multiple separate schemas... - one schema with multiple parts... proposal is 2nd one with special NETMOD-tree namespace Sharon: Which use case are you focusing on? is this full-schema = validation, partial schema validation? get response validation? are you = proposing a=20 single DSDL schema with conditional parts depending on the = operation? lada: yes, I would like one schema with all the information from the = yang=20 module, that can be used for multiple use cases. Phil: Yesterday we talked about making a base netconf DSDL module, = and=20 then the output of the mapping be an extension to that base. The = DSDL base=20 would include an rpc element. The DSDL output would define addition=20 extensions to that base rpc mapping. That way you have both a = consistent=20 hierarchy and additional schemas. Lada: so we would not have an artifical root; we will use the = netconf root to the hierarchy. Phil: that way you could generate for your configuration the valid = content=20 for both the configuration itself plus the edit-config, etc. Sharon: Maybe a third approach is to generate two schemas - one that = is the=20 most straightforward - defines the config datastore like a MIB = module, plus=20 a second schema document with a protocol operation mapping. Exactly = 2=20 documents, no matter how many rpcs we have. I don't want users = weighed down=20 with lots of additional schemas. There seem to be no objections now. So take it to the list - slide 9: extension - need to know the semantics of extensions before we can translate = them=20 into the relaxNG schema. so maybe make a decision later. for now = ignore=20 extensions until we have some real world experience phil: so do DSDL provide hooks for constarints in other namespaces? lada: yes you can do lots of things in annotations. Some tools can = be=20 developed to understand the different types of annotations. phil: can I procvide a hook to routines in my code to force my = constraints? sharon: wants to see the details of the issue, but thinks that this = is=20 possible in Schematron phil: do you want real world examples? DP: take it to the list - slide 10 (augment) - YANG issue: suggestion to clarify where the augment applies (ie. = to which import) - not clear what to do in some case (see slide) - proposal: for now ignore top-level augment Andy: this is the only way a vendor can extend a module (see more in = jabber) BL: we abdolutely need thie top level augment LADA: yes, but it can be done in a different way, like a vendor = includes=20 the standard definition and them modifies it. I don't know hwo the = current augment can be translated into DSDL phil: I'm not a DSDL guy, but can't you use pattern replacements? lada: but I don't have the stuff in the foreign module, and I cannot = import the foreign module. phil: so you cannot parse the foreign module and know how to = augment? lada: we could generate the foreign module as is Martin: You can only add to top-level elements in RELAX, so the = schema =20 would have to be very flat. phil: you can only add things at the highest level granularity of = the DSDL, =20 but you can make the assumptions about the first DSDL module was = generated,=20 but we have rules that can state . lada: for purpose of name mangling, I need to bring all types of ... = to top=20 level so things can be mangled. DP: pls send mail to the list to explain the issue more and offer=20 alternatives solutions for discussion lada: I would like to propose this augment become a part of YANG = issues. Martin has this also on the list of YANG issues - slide 12 (No Root Elemenmt) - conceptual tree would solve this; propose adding conceptual tree phil: pls explain what 1st sentence in 2nd para means it seems the tools are not in sync with the RLAXNG authorities if reusable shemas are a common practice, why would the relaxNG = authorities=20 endorse it? Sharon: it shows up more as a warning than an error. If there is a = problem with the thing being imported, the tools can still validate the = importing module with just a warning about the imported schema. lada: essentially resolved. - slide 13 andy: are you suggesting to add an element in XML netconf PDUS? lada: no, the cnoceptual tree is just a helper to have an exact=20 representation of an XML instance that is said to be valid. - slide 14 (Xpath and Namespaces) all names in "must" must have explicit full names. phil: that will affect the readabaility; I would rather see the = tools do the expansion. lada: But if we do not do the expansions in the spec, then it will = be=20 invalid XPath. phil: so we need to define the context or rewrite the XPath during=20 translation to DSDL. lada: the name without the explicit namespace means that the name = belongs to the default namespace.=20 DP so we need more words in YEAN spec to clarify this. lada: not sure this will/can fix it JS: phil and lada, pls both point to the specs where you believe it = is=20 right or wrong so that we (others) can check nad make up our opinion - Martin on more YANS open issues - slide 14: server variance martin: concern that including such specifics in the schema is very complicated (backwards compat, etc).=20 sharon: other solutions outside schema are being used, may not be = needed in YANG at all. suggest defer the whole feature: concern this could = complicate=20 YANG such as to slow the timeline JS: this sounds like yang 2.0; we should defer this work. Andy: agree - slide 15: server supplied values Phil: so this can be done indepndent of th emodel. We can publish 1.0 = models, and deal witht the variances later. - slide 16: server supplied defaults there is no formal way to specify that the server will define a = default. this can be in the description clause, or in a formalized field. DP slide 14-16 needs to be broken down in bits and pieces (even = though they=20 hang together in a way) so we can discuss them (hopefully) more = easily sharon: so there should be a get config and get-config with defaults. = In practice, some defaults are calculated at runtime. JS: we really need to be careful about what is in scope and what is = not, if we want to finish in september 2009. With a CLI, you do not get all = these details modeled. we don't need to do them now. martin: working with other WGs, they asked these questions. we need = to be=20 clear what we do and do not support in yang. Phil: but the slide presents the model of how to make models. We have = deviations that can be documented ahead of time, deviations that we = can=20 provide defaults for, and things that servers do that will anger = everybody. BL: most of these are server variations. But default are specific. Would like a simple statement: what can we do without going down the=20 slippery slope that woudl delay the deliverables. DP: take it to the list - slide 17 multiple patterns skip this slide Andy" must align with how XSD processes patterns JS: we will do exactly what XSD does - slide 18 conditional content using "when" issue not resolved, there was discussion on list JS: like to see a more concrete proposal and like to know what = pecicesly=20 it menans sharon: this type of conditional should have no negative impact on=20 Schematron lada: this can be added everywhere where you put augment andy: .. see jabber - slide 19 Why contrain keyref (mailing list raised issue) - propose: make it possible to mark a ketref to allow unsatisfied=20 reference. Details TBD Sharon: wants an answer why she is not allowed to reference static=20 information (??) Need more time to discuss this on the mailing list Sometimes posting to nonexisting things is OK, other times it is = not Phil: if you allow to become invalid over time, how do you deal with = that? We're out of time. Rest needs to go to mlist - BL: Wants a new feature: Netmod-actions RPCs and Notifications in YANG lists issue 1: see slide issue2: see slide issue 3: see slide Solution: RPCs defined in Lists Sharon is not too supportive of this wes: is OK with putting it inline. But got to be wrapped in a sort of=20 "this is rpc tag" it is DP: pls turn slide set into text and send it to mlist - BERND: Netmod Augmentable Groupings - lada would it be an option to make it a substatement of import? - bernd: cannot say yes or no at this point DP: pls turn this into text and send to mlist as a suggested addition = to=20 Yang DBH: would be wonderfeature if I were developing product code but we are developing a standard and we need to "fix" a lot of things = for=20 that. people seem to want to add feature that let them change things = after=20 the fact. We should not make things so flexible that the standard = makes no =20 sense anymore. This is a generic comment about proposed features. DP reality needs us to be flexible. Mehmet: do not see the problem. This is a way to reduce development = effort does not break any standards development DP we're out of time Andy: agrees with DBH: complicated to implement and use safely Leif agres it is complicated and dagenerous but you will need it pls go read a book on oo-programming Mark: The last 2 proposals could solve some real problems I am facing = today phil: worries about mis-use (if not used correctly) DP: we're done. Thanks all. Sessions were successfull. Appreciate = technical=20 dialog. there is a tentative plan to have interim 8-10 october. Things will be divided in current issues and new features. Preference to get current things done fist. End of session ------=_NextPart_000_0726_01C8FE41.8F6F8940 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0726_01C8FE41.8F6F8940-- From netmod-bounces@ietf.org Fri Aug 15 07:43:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6543A6A55; Fri, 15 Aug 2008 07:43:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52F93A6D79 for ; Fri, 15 Aug 2008 07:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueadNgLQ86gc for ; Fri, 15 Aug 2008 07:43:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B29EA3A6A55 for ; Fri, 15 Aug 2008 07:43:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7FEhX2n015330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 16:43:33 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7FEhXIK004977; Fri, 15 Aug 2008 16:43:33 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 16:43:33 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Aug 2008 16:43:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netmod] augment and mandatory Thread-Index: Acj9ryPCp0PcjiPlRIaRF2/0VCYNGQAX8ILwAC3U+CAAAExAQA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 15 Aug 2008 14:43:33.0348 (UTC) FILETIME=[4AA6F240:01C8FEE5] Subject: Re: [netmod] augment and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Andy, I support both cases you mention since they are useful to avoid misuse and support backward compatibility. An augment must not break a client that doesn't understand the augmentation. Cheers, Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Thursday, August 14, 2008 3:43 AM > To: NETMOD Working Group > Subject: [netmod] augment and mandatory > > Hi, > > I've been thinking about this issue some more. > > There is nothing wrong with a nested augment-stmt > adding mandatory nodes to some data structure. > The obvious use-case is augmenting an expanded uses-stmt > object. > > However, an external augment (i.e., augmenting a > different XML namespace) MUST NOT contain any mandatory > objects. This breaks backward compatibility. > > Also, any augment-stmt with a 'when' clause configured > MUST NOT contain any mandatory nodes. A mandatory > node must always be provided by the user. By definition, > the when clause is not 'always'. > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 08:44:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3753A6DCE; Fri, 15 Aug 2008 08:44:23 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD153A6DCE for ; Fri, 15 Aug 2008 08:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4VzcCpjGDCe for ; Fri, 15 Aug 2008 08:44:22 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6653F3A6DAC for ; Fri, 15 Aug 2008 08:44:22 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7FFhkTi020012; Fri, 15 Aug 2008 10:44:17 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 18:43:47 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 18:43:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Aug 2008 18:43:29 +0300 Message-ID: <46DCD7DCAFF0E94796B7C2894ED9F266045C99AC@esebe103.NOE.Nokia.com> In-Reply-To: <48A2FB32.9060405@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: Acj9V9FFql5wX0k4QaatA67fhFnTAQBk3f0Q References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> From: To: , X-OriginalArrivalTime: 15 Aug 2008 15:43:30.0142 (UTC) FILETIME=[AA8227E0:01C8FEED] X-Nokia-AV: Clean Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman andy@netconfcentral.com wrote: > -----Original Message----- > From: ext Andy Bierman [mailto:andy@netconfcentral.com] > Sent: 13 August, 2008 17:18 > To: Linowski Bernd (EXT-Other - DE/Dusseldorf) > Cc: netmod@ietf.org > Subject: Re: [netmod] Augmentable Groupings > > bernd.linowski.ext@nsn.com wrote: > > > > Hi, > > > > Andy Bierman andy@netconfcentral.com wrote: > > > Actually groupings are not in the same namespace as objects, > > > so this Xpath is broken. > > > > > > > > > grouping foo; > > > > > > container foo; > > > > > > Both of these are legal YANG. > > > > That is not in line what is stated in section 7.11 of the > > YANG specification: > > " If the grouping is defined at the top level of a YANG module or > > submodule, the grouping's identifier MUST be unique within the > > module." > > Name "foo" is not unqiue within the module. > > > > Here is the text from the draft: > > 6.2.1. Identifiers and their namespaces > > .... > > o All groupings defined within a parent node or at the > top-level of > the module or its submodules share the same grouping identifier > namespace. This namespace is scoped to the parent > node or module. > > .... > > All identifiers defined in a namespace MUST be unique. > I agree, there could be an ambiguity as there is a separate grouping identifier namespace. Let me reconsider the options how to address this. BR, Bernd > > > > > > > > If I nest the groupings, then what happens to the augment: > > > > > > module C { > > > > > > grouping new-concepts { > > > uses concepts; > > > } > > > > > > Does new-concepts contain the augmentations from concepts? > > > > > > > Yes. > > > > > Yes, well this makes it an NP-complete problem to resolve all the > uses statements in all the modules. > > Even if that did not matter (just implementation!), the NETCONF > vendors have to deal with a pool of modules for which > they have no change control whatsoever. And what about their own > modules already out there in shipping code? > > This 'write once, and it shows up everywhere' feature is not > actually usable in the operational environment that YANG must address. > > > Andy > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 08:51:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230ED3A6810; Fri, 15 Aug 2008 08:51:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569733A6810 for ; Fri, 15 Aug 2008 08:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyyBs8VJafDb for ; Fri, 15 Aug 2008 08:51:22 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id BA0FE3A6924 for ; Fri, 15 Aug 2008 08:51:20 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 15 Aug 2008 08:50:42 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 08:50:31 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 08:50:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 08:50:30 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7FFo8u03527; Fri, 15 Aug 2008 08:50:08 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7FFkkQF042193; Fri, 15 Aug 2008 15:46:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808151546.m7FFkkQF042193@idle.juniper.net> To: Andy Bierman In-reply-to: <48A49D1A.10401@netconfcentral.com> Date: Fri, 15 Aug 2008 11:46:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Aug 2008 15:50:30.0947 (UTC) FILETIME=[A553E730:01C8FEEE] Cc: NETMOD Working Group Subject: Re: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >This breaks the manager's ability to test config >changes offline. The mgmt app can use the defaults from the YANG module and the device deviations to test config changes. Additional default values will likely not matter to the model and the constraints therein. >(Not everybody just flings commands at a router >to see what will happen ;-) But this is exactly what you are doing. You are wanting to throw config at a router, fetch it back with a flag to get all default values, and then validate it. You are flinging config at the router and then seeing what you made. I'm fine with adding the flag, but I don't see it as a valuable replacement to knowing the default values _before_ I throw the config at the router. Here's a dumb never-gonna-happen example: The IETF-USER module says users have a default password of "*", meaning unusable. Someone makes a box with a device deviation that gives a default password of "" (the empty string, no password needed). Wouldn't you want to know the _before_ you make a user instance that depends on the default password value? A with-defaults flag might be useful to know what someone else made, but it's not useful to know what you are going to make if you fling config at a router. You find out what you made after you made it, which is a bit too late. I have a "show | display defaults" command in my code, so users that don't want to look up defaults can see what they've made, but while a user may want to avoid looking up the default, an application shouldn't. Users are lazy. Applications shouldn't be. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 09:03:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378803A67A8; Fri, 15 Aug 2008 09:03:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28A83A67A8 for ; Fri, 15 Aug 2008 09:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT5NBYDKqzqk for ; Fri, 15 Aug 2008 09:03:56 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id DF8303A6B22 for ; Fri, 15 Aug 2008 09:03:56 -0700 (PDT) Received: (qmail 82875 invoked from network); 15 Aug 2008 16:03:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 15 Aug 2008 16:03:36 -0000 X-YMail-OSG: 4DsuhtkVM1kByeFNaxNxkAcBAkYQfORKayT6wiegEWHq97j_.zF2g7sddKmmI_f3QCfMBd9lFmai0RFbimKEOtG3vS0Hk3KNFRkE6qbD3A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A5A8D6.10708@netconfcentral.com> Date: Fri, 15 Aug 2008 09:03:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: bernd.linowski.ext@nsn.com References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <46DCD7DCAFF0E94796B7C2894ED9F266045C99AC@esebe103.NOE.Nokia.com> In-Reply-To: <46DCD7DCAFF0E94796B7C2894ED9F266045C99AC@esebe103.NOE.Nokia.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org bernd.linowski.ext@nsn.com wrote: > > Hi, > > Andy Bierman andy@netconfcentral.com wrote: >> -----Original Message----- >> From: ext Andy Bierman [mailto:andy@netconfcentral.com] >> Sent: 13 August, 2008 17:18 >> To: Linowski Bernd (EXT-Other - DE/Dusseldorf) >> Cc: netmod@ietf.org >> Subject: Re: [netmod] Augmentable Groupings >> >> bernd.linowski.ext@nsn.com wrote: >>> Hi, >>> >>> Andy Bierman andy@netconfcentral.com wrote: >>> > Actually groupings are not in the same namespace as objects, >>> > so this Xpath is broken. >>> > >>> > >>> > grouping foo; >>> > >>> > container foo; >>> > >>> > Both of these are legal YANG. >>> >>> That is not in line what is stated in section 7.11 of the >>> YANG specification: >>> " If the grouping is defined at the top level of a YANG module or >>> submodule, the grouping's identifier MUST be unique within the >>> module." >>> Name "foo" is not unqiue within the module. >>> >> Here is the text from the draft: >> >> 6.2.1. Identifiers and their namespaces >> >> .... >> >> o All groupings defined within a parent node or at the >> top-level of >> the module or its submodules share the same grouping identifier >> namespace. This namespace is scoped to the parent >> node or module. >> >> .... >> >> All identifiers defined in a namespace MUST be unique. >> > > I agree, there could be an ambiguity as there is a separate grouping > identifier namespace. > > Let me reconsider the options how to address this. This is a minor issue, easily fixed by collapsing the grouping namespace into the object namespace. The major issue is the ripple effect through all the uses, what Phil calls the 'drive-by augment'. If I create a derived class FooPrime from Foo, all the instances of the Foo class are unchanged. I actually have to change the code everywhere I want to have an instance of FooPrime instead of Foo. If I want to affect all instances of Foo, I have to edit the Foo class itself (or its ancestors). This is correct. This is how it should work. This is how grouping/uses does work. You must create a new grouping FooPrime (that uses Foo) and change the exact uses statements where the new version should be applied. > > BR, > Bernd Andy >> >>> > >>> > If I nest the groupings, then what happens to the augment: >>> > >>> > module C { >>> > >>> > grouping new-concepts { >>> > uses concepts; >>> > } >>> > >>> > Does new-concepts contain the augmentations from concepts? >>> > >>> >>> Yes. >>> >> >> Yes, well this makes it an NP-complete problem to resolve all the >> uses statements in all the modules. >> >> Even if that did not matter (just implementation!), the NETCONF >> vendors have to deal with a pool of modules for which >> they have no change control whatsoever. And what about their own >> modules already out there in shipping code? >> >> This 'write once, and it shows up everywhere' feature is not >> actually usable in the operational environment that YANG must address. >> >> >> Andy > > > > > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 09:24:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DA53A6D29; Fri, 15 Aug 2008 09:24:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7385E3A6882 for ; Fri, 15 Aug 2008 09:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy4h7WiVNZZg for ; Fri, 15 Aug 2008 09:24:14 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id A2A793A6D29 for ; Fri, 15 Aug 2008 09:24:14 -0700 (PDT) Received: (qmail 28462 invoked from network); 15 Aug 2008 16:24:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 15 Aug 2008 16:24:17 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A5ADAF.1060403@netconfcentral.com> Date: Fri, 15 Aug 2008 09:24:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808151546.m7FFkkQF042193@idle.juniper.net> In-Reply-To: <200808151546.m7FFkkQF042193@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> This breaks the manager's ability to test config >> changes offline. > > The mgmt app can use the defaults from the YANG module and the > device deviations to test config changes. Additional default > values will likely not matter to the model and the constraints > therein. I do not see how the application is going to use off the shelf tools like libxml2 to test all the must and when XPath expressions. If the default node is not in the instance document, the same XPath expression that worked by magic on the agent does not work at all for the manager. > >> (Not everybody just flings commands at a router >> to see what will happen ;-) > > But this is exactly what you are doing. You are wanting to throw > config at a router, fetch it back with a flag to get all default > values, and then validate it. You are flinging config at the router > and then seeing what you made. No. I said . Given the complete output and all the YANG modules and vendor overlays, an application can test some operator config changes off-line to see if the or should work on the agent. A manager could use , but this is optional, and not actually required to do any specific tests at all. If the is available, you can fill up that sandbox and fling it at the router with . But if is not supported, the manager is SOL, and needs an off-line sandbox. > > I'm fine with adding the flag, but I don't see it as a valuable > replacement to knowing the default values _before_ I throw the > config at the router. > > Here's a dumb never-gonna-happen example: The IETF-USER module > says users have a default password of "*", meaning unusable. Someone > makes a box with a device deviation that gives a default password > of "" (the empty string, no password needed). Wouldn't you want > to know the _before_ you make a user instance that depends on the > default password value? > > A with-defaults flag might be useful to know what someone else made, > but it's not useful to know what you are going to make if you fling > config at a router. You find out what you made after you made it, > which is a bit too late. > > I have a "show | display defaults" command in my code, so users > that don't want to look up defaults can see what they've made, but > while a user may want to avoid looking up the default, an application > shouldn't. Users are lazy. Applications shouldn't be. How does the manager know the default values for the nodes without a YANG-specified default, in advance? > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 09:37:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8713A67A8; Fri, 15 Aug 2008 09:37:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14CF3A6924 for ; Fri, 15 Aug 2008 09:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts3wGyTVPW-7 for ; Fri, 15 Aug 2008 09:37:33 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 31E573A67A8 for ; Fri, 15 Aug 2008 09:37:33 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 15 Aug 2008 09:36:40 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 09:36:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 09:36:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Aug 2008 09:36:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7FGa4u19460; Fri, 15 Aug 2008 09:36:04 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7FGWgdL042387; Fri, 15 Aug 2008 16:32:42 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808151632.m7FGWgdL042387@idle.juniper.net> To: Andy Bierman In-reply-to: <48A5ADAF.1060403@netconfcentral.com> Date: Fri, 15 Aug 2008 12:32:42 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Aug 2008 16:36:27.0475 (UTC) FILETIME=[1058B230:01C8FEF5] Cc: NETMOD Working Group Subject: Re: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Given the complete output and all the YANG modules >and vendor overlays, an application can test some >operator config changes off-line to see if the > or should work on the agent. Completely agree. >A manager could use , but this is optional, >and not actually required to do any specific tests at all. >If the is available, you can fill up >that sandbox and fling it at the router with . >But if is not supported, the manager is SOL, >and needs an off-line sandbox. Completely agree. And the YANG module plus the device deviations should be sufficient to drive the off line sandbox. >How does the manager know the default values for the nodes without >a YANG-specified default, in advance? Device deviations. If the device adds a default value to the standard, it can announce it as a device deviation. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 10:29:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C433A6AE9; Fri, 15 Aug 2008 10:29:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5553A6AE9 for ; Fri, 15 Aug 2008 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpDTgO9meSL9 for ; Fri, 15 Aug 2008 10:28:59 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 732833A6818 for ; Fri, 15 Aug 2008 10:28:59 -0700 (PDT) Received: (qmail 47382 invoked from network); 15 Aug 2008 17:28:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 15 Aug 2008 17:28:55 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A5BCD5.3000601@netconfcentral.com> Date: Fri, 15 Aug 2008 10:28:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808151632.m7FGWgdL042387@idle.juniper.net> In-Reply-To: <200808151632.m7FGWgdL042387@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Given the complete output and all the YANG modules >> and vendor overlays, an application can test some >> operator config changes off-line to see if the >> or should work on the agent. > > Completely agree. > >> A manager could use , but this is optional, >> and not actually required to do any specific tests at all. >> If the is available, you can fill up >> that sandbox and fling it at the router with . >> But if is not supported, the manager is SOL, >> and needs an off-line sandbox. > > Completely agree. And the YANG module plus the device deviations > should be sufficient to drive the off line sandbox. > >> How does the manager know the default values for the nodes without >> a YANG-specified default, in advance? > > Device deviations. If the device adds a default value to > the standard, it can announce it as a device deviation. > A lot of custom code to reconstruct the element is needed with this approach. Several people (including me) do not see the need to make such a big deal out of config leafs which happen to contain the default value. Sometimes optional leafs (with or without YANG defaults defined) are really not there in the agent. Not used. Not implemented. Nowhere to be found. Sometimes optional leafs (with or without YANG defaults defined) really are there in the agent. It depends on the data model, as to what the default means and whether or not it makes sense to create an instance or that leaf. Sometimes defaults like 'off', 'disabled', etc. amount to the same thing as if the leaf was not there. But defaults like '1500' for MTU or 'root@localhost' for sysadmin-email-address are not just placeholders. I will continue to use (+with-defaults=true) to deal with this problem. I want a single XML tree from the agent that has the nodes the agent is using, and does not have any nodes it is not using. already provides that, without any new work required. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 10:52:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E02428C294; Fri, 15 Aug 2008 10:52:04 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8680328C274 for ; Fri, 15 Aug 2008 10:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35TWqWGtkb90 for ; Fri, 15 Aug 2008 10:52:02 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id E6D2828C29B for ; Fri, 15 Aug 2008 10:51:57 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Fri, 15 Aug 2008 10:50:50 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 10:50:59 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 10:50:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 10:50:58 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7FHoau52844; Fri, 15 Aug 2008 10:50:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7FHlD4H042684; Fri, 15 Aug 2008 17:47:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808151747.m7FHlD4H042684@idle.juniper.net> To: Andy Bierman In-reply-to: <48A5BCD5.3000601@netconfcentral.com> Date: Fri, 15 Aug 2008 13:47:13 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Aug 2008 17:50:58.0901 (UTC) FILETIME=[79862850:01C8FEFF] Cc: NETMOD Working Group Subject: Re: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >A lot of custom code to reconstruct the >element is needed with this approach. s/reconstruct/pre-construct/ Doesn't seem that hard to me. You are merging the tree of "stuff you want to make" with "defaults you learn from modules and deviations". Traverse the tree, if a node isn't there and has a default, add it. >I will continue to use (+with-defaults=true) >to deal with this problem. I want a single XML tree from >the agent that has the nodes the agent is using, and does not >have any nodes it is not using. This works for after-the-fact validation. If you're happy with that, a with-defaults capability will satisfy you. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 11:26:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751CF28C26D; Fri, 15 Aug 2008 11:26:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B717928C26E for ; Fri, 15 Aug 2008 11:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS8t3EJw2HRj for ; Fri, 15 Aug 2008 11:26:20 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 19C0B3A6AB2 for ; Fri, 15 Aug 2008 11:26:19 -0700 (PDT) Received: (qmail 23034 invoked from network); 15 Aug 2008 18:26:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 15 Aug 2008 18:26:23 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A5CA4D.9010108@netconfcentral.com> Date: Fri, 15 Aug 2008 11:26:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808151747.m7FHlD4H042684@idle.juniper.net> In-Reply-To: <200808151747.m7FHlD4H042684@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> A lot of custom code to reconstruct the >> element is needed with this approach. > > s/reconstruct/pre-construct/ > > Doesn't seem that hard to me. You are merging the tree of "stuff > you want to make" with "defaults you learn from modules and > deviations". Traverse the tree, if a node isn't there and has a > default, add it. > >> I will continue to use (+with-defaults=true) >> to deal with this problem. I want a single XML tree from >> the agent that has the nodes the agent is using, and does not >> have any nodes it is not using. > > This works for after-the-fact validation. If you're happy with > that, a with-defaults capability will satisfy you. > this works for taking the running config from a particular known good state to a different good state. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 15 12:08:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC733A6780; Fri, 15 Aug 2008 12:08:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F6D3A688D for ; Fri, 15 Aug 2008 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Khlw04g7LN6 for ; Fri, 15 Aug 2008 12:07:59 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id D68D83A6780 for ; Fri, 15 Aug 2008 12:07:59 -0700 (PDT) Received: (qmail 39602 invoked from network); 15 Aug 2008 19:07:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.181 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 15 Aug 2008 19:07:31 -0000 X-YMail-OSG: gtFYRl4VM1mofc9V.cReKfv6c2nPgtxOYiyzIbEj3A2rDiXBKZZXWMYIuhrSKMp15eEwuCHsapfZEqu2Z.0CYfzjqJJAcYTQpwBnx4JAcw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A5D3F1.5020503@netconfcentral.com> Date: Fri, 15 Aug 2008 12:07:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808151747.m7FHlD4H042684@idle.juniper.net> In-Reply-To: <200808151747.m7FHlD4H042684@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] defaults and offline validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> A lot of custom code to reconstruct the >> element is needed with this approach. > > s/reconstruct/pre-construct/ > > Doesn't seem that hard to me. You are merging the tree of "stuff > you want to make" with "defaults you learn from modules and > deviations". Traverse the tree, if a node isn't there and has a > default, add it. Within your agent implementation, you know whether or not any leaf is being used or not, and if it being used, you know the internal (or manager-supplied) value. It is easy to code 'with-defaults', so it should be no problem to support both types of validation: 1) device is not available for validation 2) device is available for validation and possibly already part of a running network You cannot evaluate the must and when statements without a element to test against. > >> I will continue to use (+with-defaults=true) >> to deal with this problem. I want a single XML tree from >> the agent that has the nodes the agent is using, and does not >> have any nodes it is not using. > > This works for after-the-fact validation. If you're happy with > that, a with-defaults capability will satisfy you. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 01:23:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9043A67E6; Mon, 18 Aug 2008 01:23:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9233A69A8 for ; Mon, 18 Aug 2008 01:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTGyyYHC8pZ2 for ; Mon, 18 Aug 2008 01:23:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 75BCA3A67E6 for ; Mon, 18 Aug 2008 01:23:53 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 087772050E; Mon, 18 Aug 2008 10:23:53 +0200 (CEST) X-AuditID: c1b4fb3c-af8d1bb0000015b5-58-48a93198aad0 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EEA68204C7; Mon, 18 Aug 2008 10:23:52 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 10:23:52 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 10:23:51 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 18 Aug 2008 10:23:51 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808181023.51944.david.partain@ericsson.com> X-OriginalArrivalTime: 18 Aug 2008 08:23:51.0952 (UTC) FILETIME=[BF1F0900:01C9010B] X-Brightmail-Tracker: AAAAAA== Cc: Ron Bonica Subject: [netmod] Interim Meeting, October 8 - 10, 2008 in Herndon, Virginia, USA (near Washington, D.C.) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings NETMODers, There will be an interim meeting from Oct 8 - 10, 2008. Ron Bonica has kindly volunteered to host the meeting at Juniper's site in Herndon, Virginia (USA). You can now book your flights to Dulles... The meeting is scheduled to start early on Wednesday and end at 15:00 on Friday, so please plan accordingly. This is so people can (hopefully) get a flight home on Friday. Information about the interim can be found at: http://wiki.tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 The agenda is not set yet, but will likely be to go through known issues in existing documents. Again, if you are coming, please let me know! The list is not as long as I thought it'd be yet... Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 04:02:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA0A28C0E0; Mon, 18 Aug 2008 04:02:23 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763B03A6C5E for ; Mon, 18 Aug 2008 04:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USkXc7agXNy2 for ; Mon, 18 Aug 2008 04:02:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8FD5328C0FC for ; Mon, 18 Aug 2008 04:02:19 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7IB2OxE014011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 13:02:24 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7IB2NgY023329; Mon, 18 Aug 2008 13:02:23 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 13:02:24 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 13:02:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Augmenting vs. Sub-classing WAS:RE: [netmod] when statement Thread-Index: Acj9+hQ0Fcsn36uIQySHygg7ooUdnwABdYsQAAAF0kAABsjOkAAA4V0wAAVHOUAAHk8ckAAFYYbgAACQv0AAAHWu8A== From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "Ladislav Lhotka" X-OriginalArrivalTime: 18 Aug 2008 11:02:24.0014 (UTC) FILETIME=[E4C082E0:01C90121] Subject: [netmod] Augmenting vs. Sub-classing WAS:RE: when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0636912791==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --===============0636912791== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C90121.E36561AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C90121.E36561AC Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Lada,=20 =20 we need to differentiate between augmenting data=20 nodes which have been advertized and OO sub-classing,=20 i.e. inheriting types.=20 In case of augmenting data nodes in module A, module=20 A must be advertised.=20 Enhancing a data node tree without supporting it does=20 not make much sense.=20 In case you just use a type X from module A or even=20 inherit type Y from type X advertizing is not needed.=20 It becomes apparent that a type is supported when=20 it is used inside an advertized data node tree.=20 When using a type it should not matter whether a=20 type extends any other type or not.=20 There is also a general difference between augmentations=20 and inheritance. In the latter case if we derive type Y from=20 type X, X and Y are literally different types.=20 Also, if I derive a class fooChild from foo, all instances=20 of the foo class remain the same. fooChild and foo generate different type of instances although the actions=20 and data have been derived and are reused. In that sense inheritance is a clear language feature without ambiguities and supports simple model extension. =20 Cheers,=20 Mehmet=20 =09 > >=20 > > > -----Original Message-----=20 > > > From: netmod-bounces@ietf.org=20 > > > [mailto:netmod-bounces@ietf.org = ] On Behalf Of ext Ladislav Lhotka=20 > > > Sent: Thursday, August 07, 2008 11:51 AM=20 > > > To: Balazs Lengyel=20 > > > Cc: NETMOD Working Group=20 > > > Subject: Re: [netmod] when statement=20 > > >=20 > > > Balazs Lengyel p=ED=B9e v =C8t 07. 08. 2008 v 10:51 +0200:=20 > > >=20 > > > > >=20 > > > > > Back to OOP - it you define an instance of a class, you=20 > > > don't specify it=20 > > > > > together with all its superclasses. My box just uses a=20 > > > data model that=20 > > > > > is derived from another one - and that should be=20 > > specified in the=20 > > > > > derived data model.=20 > > > > >=20 > > > > This example IMHO has nothing to do with OO.=20 > > > >=20 > > > > You have a container with a lump of data in module A. The=20 > > > in module B you augment it with a=20 > > > > second lump of data. If your node does not=20 > > > advertise/implement module A, what are you=20 > > > > augmenting actually?=20 > > > > So if you augment something in module A, you MUST=20 > > > implement/advertise module A.=20 > > >=20 > > > But I think it is an exact analogy with subclassing: I=20 > > advertise just=20 > > > module B, which in turn declares that it is derived from=20 > > module A. So=20 > > > naturally the device has to implement everything that is in the=20 > > > "superclass" module A PLUS the changes from B.=20 > > >=20 > > > But maybe our Nokia-Siemens friends could speak up and=20 > > formulate their=20 > > > OO proposals, it may help clarify this.=20 > > >=20 > > > Lada=20 > > >=20 > > > --=20 > > > Ladislav Lhotka, CESNET=20 > > > PGP Key ID: E74E8C0C=20 > > >=20 > > > _______________________________________________=20 > > > netmod mailing list=20 > > > netmod@ietf.org=20 > > > https://www.ietf.org/mailman/listinfo/netmod = =20 > > >=20 > >=20 >=20 ------_=_NextPart_001_01C90121.E36561AC Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Augmenting vs. Sub-classing WAS:RE: [netmod] when = statement

Hi Lada, =
 
we need to = differentiate between augmenting data
nodes which have = been advertized and OO sub-classing,
i.e. inheriting = types.

In case of = augmenting data nodes in module A, module
A must be = advertised.
Enhancing a data = node tree without supporting it does
not make much = sense.

In case you just = use a type X from module A or even
inherit type Y = from type X advertizing is not needed.
It becomes = apparent that a type is supported when
it is used inside = an advertized data node tree.
When using a type = it should not matter whether a
type extends any = other type or not.

There is also a = general difference between augmentations
and inheritance. = In the latter case if we derive type Y from
type X, X and Y = are literally different types.

Also, if I derive a class fooChild from foo, all instances =
of the foo = class remain the same. fooChild and foo
generate = different type of instances although the actions
and data have = been derived and are reused.

In that sense = inheritance is a clear language feature
without = ambiguities and supports simple model extension.
         
Cheers, =
Mehmet =

       
        > >
        > > > -----Original Message----- =
        > > > From: netmod-bounces@ietf.org =
        > > > [mailto:netmod-bounces@ietf.org <mailto:netmod-bounces@ietf.org> ] On Behalf Of ext = Ladislav Lhotka
        > > > Sent: Thursday, August 07, 2008 = 11:51 AM
        > > > To: Balazs Lengyel
        > > > Cc: NETMOD Working Group =
        > > > Subject: Re: [netmod] when = statement
        > > >
        > > > Balazs Lengyel p=ED=B9e v =C8t = 07. 08. 2008 v 10:51 +0200:
        > > >
        > > > > >
        > > > > > Back to OOP - it you = define an instance of a class, you
        > > > don't specify it
        > > > > > together with all its = superclasses. My box just uses a
        > > > data model that
        > > > > > is derived from another = one - and that should be
        > > specified in the
        > > > > > derived data model. =
        > > > > >
        > > > > This example IMHO has = nothing to do with OO.
        > > > >
        > > > > You have a container with a = lump of data in module A. The
        > > > in module B you augment it with a =
        > > > > second lump of data. If your = node does not
        > > > advertise/implement module A, = what are you
        > > > > augmenting actually? =
        > > > > So if you augment something = in module A, you MUST
        > > > implement/advertise module A. =
        > > >
        > > > But I think it is an exact = analogy with subclassing: I
        > > advertise just
        > > > module B, which in turn declares = that it is derived from
        > > module A. So
        > > > naturally the device has to = implement everything that is in the
        > > > "superclass" module A = PLUS the changes from B.
        > > >
        > > > But maybe our Nokia-Siemens = friends could speak up and
        > > formulate their
        > > > OO proposals, it may help clarify = this.
        > > >
        > > > Lada
        > > >
        > > > --
        > > > Ladislav Lhotka, CESNET =
        > > > PGP Key ID: E74E8C0C =
        > > >
        > > > = _______________________________________________
        > > > netmod mailing list =
        > > > netmod@ietf.org
        > > > https://www.ietf.org/mailman/listinfo/netmod = <https://www.ietf.org/mailman/listinfo/netmod>  =
        > > >
        > >
        >

------_=_NextPart_001_01C90121.E36561AC-- --===============0636912791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============0636912791==-- From netmod-bounces@ietf.org Mon Aug 18 04:50:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DE23A67F4; Mon, 18 Aug 2008 04:50:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D5B28C11E for ; Mon, 18 Aug 2008 04:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8soRB1vwp3o for ; Mon, 18 Aug 2008 04:50:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 618E93A67F4 for ; Mon, 18 Aug 2008 04:50:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 205D8C0015; Mon, 18 Aug 2008 13:50:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qvSvv7TiL4p5; Mon, 18 Aug 2008 13:50:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1102C0014; Mon, 18 Aug 2008 13:50:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 68DBC693F1B; Mon, 18 Aug 2008 13:50:49 +0200 (CEST) Date: Mon, 18 Aug 2008 13:50:49 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080818115049.GC12968@elstar.local> Mail-Followup-To: Balazs Lengyel , Andy Bierman , netmod@ietf.org References: <20080702.091623.190514914.mbj@tail-f.com> <20080702074204.GC850@elstar.local> <486B3F45.1010802@netconfcentral.com> <489C196C.5000209@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <489C196C.5000209@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Aug 08, 2008 at 12:01:16PM +0200, Balazs Lengyel wrote: > I think the definition of deprecated should be changed. Today it states > that if foo is deprecated it might or might not be there, but I agree > with Andy that it should rather mean it is supported now, but will be > removed in the future (that is the same philosophy that they use in > Java). > So the proposed text is: > > Old text: > > "deprecated" indicates an obsolete definition, but it permits new/ > continued implementation in order to foster interoperability with > older/existing implementations. > > New text: > > "deprecated" means that a definition is still implemented and usable - > but you should not use it. It will gradually be phased out in the future. I believe the wording "is still implemented and usable" is asking for confusion. What about this: "deprecated" means that a definition is still supported but should not be used anymore. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 05:24:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5791A28C14B; Mon, 18 Aug 2008 05:24:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9646828C14D for ; Mon, 18 Aug 2008 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0lVcCkgcaKP for ; Mon, 18 Aug 2008 05:24:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8E58728C14B for ; Mon, 18 Aug 2008 05:24:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7470C0015; Mon, 18 Aug 2008 14:24:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xuGB5ieubdaP; Mon, 18 Aug 2008 14:24:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56BE9C0014; Mon, 18 Aug 2008 14:24:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 631C569424E; Mon, 18 Aug 2008 14:24:16 +0200 (CEST) Date: Mon, 18 Aug 2008 14:24:16 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080818122416.GD12968@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20080811.090508.104047439.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080811.090508.104047439.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: > To solve this problem, I suggest we add an optional prefix > substatement to belongs-to: > > submodule foo { > belongs-to bar { > prefix b; > } > ... > } Is this problem important enough to require the suggested solution? What happens if the prefix declared in belongs-to is different from the prefix declared in the module? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 05:37:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D6928C14B; Mon, 18 Aug 2008 05:37:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550153A6A9D for ; Mon, 18 Aug 2008 05:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GxGKhj27zhy for ; Mon, 18 Aug 2008 05:37:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47CE128C153 for ; Mon, 18 Aug 2008 05:36:38 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89B19C0002; Mon, 18 Aug 2008 14:36:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EzlmTdI7CNGa; Mon, 18 Aug 2008 14:36:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DC69C0028; Mon, 18 Aug 2008 14:36:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 457E9694354; Mon, 18 Aug 2008 14:36:05 +0200 (CEST) Date: Mon, 18 Aug 2008 14:36:05 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080818123605.GA13227@elstar.local> Mail-Followup-To: Phil Shafer , bernd.linowski.ext@nsn.com, netmod@ietf.org References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8FA9@esebe103.NOE.Nokia.com> <200808131458.m7DEwelY015955@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200808131458.m7DEwelY015955@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Aug 13, 2008 at 10:58:40AM -0400, Phil Shafer wrote: > bernd.linowski.ext@nsn.com writes: > >But in this case you should not augment the NetworkInterface grouping > >but rather augment HC features to the place where HC support is needed. > > The scenario remains. If anyone can augment a grouping, one module's > augmentation can interfere with the use of the grouping in another > module. If you allow augmenting of groupings, you lose control of > what a module gets when they say use a grouping. I share Phil's concerns. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 05:37:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3473A68E5; Mon, 18 Aug 2008 05:37:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532FF3A6C88 for ; Mon, 18 Aug 2008 05:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXjJzXLiCIpy for ; Mon, 18 Aug 2008 05:37:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5BFC43A6C48 for ; Mon, 18 Aug 2008 05:37:35 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B26B76C040; Mon, 18 Aug 2008 14:37:41 +0200 (CEST) Date: Mon, 18 Aug 2008 14:37:46 +0200 (CEST) Message-Id: <20080818.143746.228944386.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080818122416.GD12968@elstar.local> References: <20080811.090508.104047439.mbj@tail-f.com> <20080818122416.GD12968@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: > > > To solve this problem, I suggest we add an optional prefix > > substatement to belongs-to: > > > > submodule foo { > > belongs-to bar { > > prefix b; > > } > > ... > > } > > Is this problem important enough to require the suggested solution? Since solution is simple enough, yes. It closes the only special rule we have - with this there are no implicit dependencies. > What happens if the prefix declared in belongs-to is different from > the prefix declared in the module? Nothing. Just as you can import with a different prefix than is used in the imported module. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 05:55:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD0D28C134; Mon, 18 Aug 2008 05:55:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795C628C164 for ; Mon, 18 Aug 2008 05:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+kuZf3Z2nNV for ; Mon, 18 Aug 2008 05:55:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6C94028C116 for ; Mon, 18 Aug 2008 05:55:54 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E090C0015; Mon, 18 Aug 2008 14:56:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N1PjyK4QZqRl; Mon, 18 Aug 2008 14:55:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32340C0014; Mon, 18 Aug 2008 14:55:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4C15D69469C; Mon, 18 Aug 2008 14:55:54 +0200 (CEST) Date: Mon, 18 Aug 2008 14:55:54 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080818125554.GD13227@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20080811.090508.104047439.mbj@tail-f.com> <20080818122416.GD12968@elstar.local> <20080818.143746.228944386.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080818.143746.228944386.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 18, 2008 at 02:37:46PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: > > > > > To solve this problem, I suggest we add an optional prefix > > > substatement to belongs-to: > > > > > > submodule foo { > > > belongs-to bar { > > > prefix b; > > > } > > > ... > > > } > > > > Is this problem important enough to require the suggested solution? > > Since solution is simple enough, yes. It closes the only special rule > we have - with this there are no implicit dependencies. > > > What happens if the prefix declared in belongs-to is different from > > the prefix declared in the module? > > Nothing. Just as you can import with a different prefix than is used > in the imported module. I assume the scope of the prefix b is restricted to the submodule, right? But something I define with prefix b does likely not make sense in the module which has a different prefix, lets say a. In other words, an implementation has to pay attention to the submodule prefix since it may be different than the module prefix. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 06:33:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CD73A6AE4; Mon, 18 Aug 2008 06:33:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27CE3A6A72 for ; Mon, 18 Aug 2008 06:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGkkl9ngtIod for ; Mon, 18 Aug 2008 06:33:09 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 28C6A3A6AFC for ; Mon, 18 Aug 2008 06:33:09 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C761176C040; Mon, 18 Aug 2008 15:33:15 +0200 (CEST) Date: Mon, 18 Aug 2008 15:33:21 +0200 (CEST) Message-Id: <20080818.153321.09114776.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080818125554.GD13227@elstar.local> References: <20080818122416.GD12968@elstar.local> <20080818.143746.228944386.mbj@tail-f.com> <20080818125554.GD13227@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Aug 18, 2008 at 02:37:46PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: > > > > > > > To solve this problem, I suggest we add an optional prefix > > > > substatement to belongs-to: > > > > > > > > submodule foo { > > > > belongs-to bar { > > > > prefix b; > > > > } > > > > ... > > > > } > > > > > > Is this problem important enough to require the suggested solution? > > > > Since solution is simple enough, yes. It closes the only special rule > > we have - with this there are no implicit dependencies. > > > > > What happens if the prefix declared in belongs-to is different from > > > the prefix declared in the module? > > > > Nothing. Just as you can import with a different prefix than is used > > in the imported module. > > I assume the scope of the prefix b is restricted to the submodule, > right? Yes. > But something I define with prefix b does likely not make > sense in the module which has a different prefix, lets say a. In other > words, an implementation has to pay attention to the submodule prefix > since it may be different than the module prefix. All prefixes are local to the module/submodule where they are declared (in import). An implementation must keep a prefix-to-module map per module/submodule, and when a prefixed identifier is found, the map is consulted to (i) make sure the prefix is declared, and (ii) check the identifier in the module. I'm not sure I addressed your concern though... /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 06:42:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B6D3A6C48; Mon, 18 Aug 2008 06:42:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847B73A6C48 for ; Mon, 18 Aug 2008 06:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm7H5QuZwS74 for ; Mon, 18 Aug 2008 06:42:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 11C383A6BB4 for ; Mon, 18 Aug 2008 06:42:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D1F5C0039; Mon, 18 Aug 2008 15:42:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FRcaATdfaFOi; Mon, 18 Aug 2008 15:42:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A232EC0033; Mon, 18 Aug 2008 15:42:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE75C694854; Mon, 18 Aug 2008 15:42:28 +0200 (CEST) Date: Mon, 18 Aug 2008 15:42:28 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080818134228.GE13227@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <20080801102824.GA4873@elstar.local> <1217702626.9157.21.camel@missotis> <4894AE39.5010001@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4894AE39.5010001@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sat, Aug 02, 2008 at 11:58:01AM -0700, Andy Bierman wrote: > Ladislav Lhotka wrote: >> Hi, >> >> in RELAX NG, multiple patterns are ANDed: >> >> http://www.relaxng.org/xsd-20010907.html#IDAMDYR >> >> This was accepted in order to have the functionality available in XSD, >> see >> http://lists.oasis-open.org/archives/relax-ng/200105/msg00211.html >> >> I guess the issue for YANG is: Is there a way for ANDing patterns? If >> not, I'd suggest to follow the RELAX NG way. > > Yes there already is a way to AND patterns with multiple > typedefs. You can also split up pattern strings into > as many lines and fragments as you want. I just made the experiment of feeding foo = xsd:string { pattern = "bb" pattern = "a.*a" } into trang and I got the following output Obviously, they do translate ANDed pattern by generating additional anonymous types. If we want to support multiple ANDed pattern in YANG, we could simply do the same. I am not saying we should - just that there is a relatively straight-forward translation path. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 07:06:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6543A6AE4; Mon, 18 Aug 2008 07:06:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E1F3A6AE4 for ; Mon, 18 Aug 2008 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.244 X-Spam-Level: ** X-Spam-Status: No, score=2.244 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiUMa7lCfZlr for ; Mon, 18 Aug 2008 07:06:30 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id B893F3A6C1C for ; Mon, 18 Aug 2008 07:06:30 -0700 (PDT) Received: (qmail 46582 invoked from network); 18 Aug 2008 14:06:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2008 14:06:17 -0000 X-YMail-OSG: qKWONe0VM1mbh8g4h7vp9fkivKQ_5zXD.eMz8R69EiOGakxtZ_ZU8q7ZV5WNeQn5YrfBFQplFwHCUZV9JU9hSnH_3BMeWL1Bc4B19cXaieA15s6sMnT8P3JmjRdhNPb7q0dEV5B.fDoh4W.fyA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A981D6.9080202@netconfcentral.com> Date: Mon, 18 Aug 2008 07:06:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <20080801102824.GA4873@elstar.local> <1217702626.9157.21.camel@missotis> <4894AE39.5010001@netconfcentral.com> <20080818134228.GE13227@elstar.local> In-Reply-To: <20080818134228.GE13227@elstar.local> Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Sat, Aug 02, 2008 at 11:58:01AM -0700, Andy Bierman wrote: >> Ladislav Lhotka wrote: >>> Hi, >>> >>> in RELAX NG, multiple patterns are ANDed: >>> >>> http://www.relaxng.org/xsd-20010907.html#IDAMDYR >>> >>> This was accepted in order to have the functionality available in XSD, >>> see >>> http://lists.oasis-open.org/archives/relax-ng/200105/msg00211.html >>> >>> I guess the issue for YANG is: Is there a way for ANDing patterns? If >>> not, I'd suggest to follow the RELAX NG way. >> Yes there already is a way to AND patterns with multiple >> typedefs. You can also split up pattern strings into >> as many lines and fragments as you want. > > I just made the experiment of feeding > > foo = > xsd:string { > pattern = "bb" > pattern = "a.*a" > } > > into trang and I got the following output > > > > > > > > > > > > > Obviously, they do translate ANDed pattern by generating additional > anonymous types. If we want to support multiple ANDed pattern in YANG, > we could simply do the same. I am not saying we should - just that > there is a relatively straight-forward translation path. > But this is not correct according to the rules in XSD. These patterns are supposed to be ORed together. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 07:11:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991B33A6AFC; Mon, 18 Aug 2008 07:11:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E3B3A6C45 for ; Mon, 18 Aug 2008 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.111 X-Spam-Level: ** X-Spam-Status: No, score=2.111 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7nIKrOb3oLc for ; Mon, 18 Aug 2008 07:11:50 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 71BF33A6AFC for ; Mon, 18 Aug 2008 07:11:50 -0700 (PDT) Received: (qmail 92642 invoked from network); 18 Aug 2008 14:11:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 18 Aug 2008 14:11:25 -0000 X-YMail-OSG: kkq7qgEVM1koaztcBuodw93qwkb2lzHQJ7VdmfT41321K4PgR5TIHmDpVBPbonJxbJOUGGhVyunDAODPIYW51xG0MCwKUqBWv50WSq.5aw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A9830A.9090700@netconfcentral.com> Date: Mon, 18 Aug 2008 07:11:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund , netmod@ietf.org References: <20080811.090508.104047439.mbj@tail-f.com> <20080818122416.GD12968@elstar.local> In-Reply-To: <20080818122416.GD12968@elstar.local> Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: > >> To solve this problem, I suggest we add an optional prefix >> substatement to belongs-to: >> >> submodule foo { >> belongs-to bar { >> prefix b; >> } >> ... >> } > > Is this problem important enough to require the suggested solution? > What happens if the prefix declared in belongs-to is different from > the prefix declared in the module? > IMO - NO. What about include statements in sub-modules? They have no prefix. It is assumed that all sub-modules share the same prefix. If sub-module A uses 'foo' from sub-module B, is is 'foo', 'A:foo', 'B:foo', or something new? What if a 'B' is already imported into sub-A? I do not like this solution proposal because the problem is not really very hard to solve with code. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 07:28:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187F13A6BB4; Mon, 18 Aug 2008 07:28:23 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55533A695D for ; Mon, 18 Aug 2008 07:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnU3diZpNol2 for ; Mon, 18 Aug 2008 07:28:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BA3CD3A6BB4 for ; Mon, 18 Aug 2008 07:28:20 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 969E2C0033; Mon, 18 Aug 2008 16:28:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6-nFt1NZBMiQ; Mon, 18 Aug 2008 16:28:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1AC88C0028; Mon, 18 Aug 2008 16:28:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2DA3B694AB0; Mon, 18 Aug 2008 16:28:20 +0200 (CEST) Date: Mon, 18 Aug 2008 16:28:20 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080818142820.GA13861@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <20080801102824.GA4873@elstar.local> <1217702626.9157.21.camel@missotis> <4894AE39.5010001@netconfcentral.com> <20080818134228.GE13227@elstar.local> <48A981D6.9080202@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48A981D6.9080202@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 18, 2008 at 07:06:14AM -0700, Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Sat, Aug 02, 2008 at 11:58:01AM -0700, Andy Bierman wrote: >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> in RELAX NG, multiple patterns are ANDed: >>>> >>>> http://www.relaxng.org/xsd-20010907.html#IDAMDYR >>>> >>>> This was accepted in order to have the functionality available in XSD, >>>> see >>>> http://lists.oasis-open.org/archives/relax-ng/200105/msg00211.html >>>> >>>> I guess the issue for YANG is: Is there a way for ANDing patterns? If >>>> not, I'd suggest to follow the RELAX NG way. >>> Yes there already is a way to AND patterns with multiple >>> typedefs. You can also split up pattern strings into >>> as many lines and fragments as you want. >> >> I just made the experiment of feeding >> >> foo = xsd:string { >> pattern = "bb" >> pattern = "a.*a" >> } >> >> into trang and I got the following output >> >> >> >> >> >> >> >> >> >> >> >> >> Obviously, they do translate ANDed pattern by generating additional >> anonymous types. If we want to support multiple ANDed pattern in YANG, >> we could simply do the same. I am not saying we should - just that >> there is a relatively straight-forward translation path. > > But this is not correct according to the rules in XSD. > These patterns are supposed to be ORed together. I fail to see why this is not correct. Please explain. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 07:37:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D19A28C17B; Mon, 18 Aug 2008 07:37:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A1228C172 for ; Mon, 18 Aug 2008 07:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT-TMjh-sxxd for ; Mon, 18 Aug 2008 07:37:03 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B0F5B28C139 for ; Mon, 18 Aug 2008 07:36:44 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B06E176C040; Mon, 18 Aug 2008 16:36:50 +0200 (CEST) Date: Mon, 18 Aug 2008 16:36:56 +0200 (CEST) Message-Id: <20080818.163656.193370708.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080818115049.GC12968@elstar.local> References: <486B3F45.1010802@netconfcentral.com> <489C196C.5000209@ericsson.com> <20080818115049.GC12968@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Aug 08, 2008 at 12:01:16PM +0200, Balazs Lengyel wrote: > > > I think the definition of deprecated should be changed. Today it states > > that if foo is deprecated it might or might not be there, but I agree > > with Andy that it should rather mean it is supported now, but will be > > removed in the future (that is the same philosophy that they use in > > Java). > > So the proposed text is: > > > > Old text: > > > > "deprecated" indicates an obsolete definition, but it permits new/ > > continued implementation in order to foster interoperability with > > older/existing implementations. > > > > New text: > > > > "deprecated" means that a definition is still implemented and usable - > > but you should not use it. It will gradually be phased out in the future. > > I believe the wording "is still implemented and usable" is asking for > confusion. What about this: > > "deprecated" means that a definition is still supported but should > not be used anymore. I think this definition is better than the old one. But the terms "supported" and "used" are maybe confusing. I think you mean: "deprecated" means that a definition is still supported by servers but should not be used by clients anymore. s/should not/SHOULD NOT/ ? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 07:48:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4F128C193; Mon, 18 Aug 2008 07:48:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1645928C19A for ; Mon, 18 Aug 2008 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.085 X-Spam-Level: ** X-Spam-Status: No, score=2.085 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_40=-0.185, J_CHICKENPOX_36=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sgo3dWZvwuzc for ; Mon, 18 Aug 2008 07:48:06 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 729B528C193 for ; Mon, 18 Aug 2008 07:48:03 -0700 (PDT) Received: (qmail 48316 invoked from network); 18 Aug 2008 14:48:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2008 14:48:05 -0000 X-YMail-OSG: DPf7scwVM1n7ANz.lDD8ck9y4Qp8wOKwK6p4g94.XRGI2tC1jkq.gbDUooEC6uDosf5RDyOrpkl1X.18R5Ex6z1XSXGKYJey6hdSj55qmzT6eITFd16QdcWnhNVUokw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A98BA2.6040908@netconfcentral.com> Date: Mon, 18 Aug 2008 07:48:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <20080801102824.GA4873@elstar.local> <1217702626.9157.21.camel@missotis> <4894AE39.5010001@netconfcentral.com> <20080818134228.GE13227@elstar.local> <48A981D6.9080202@netconfcentral.com> <20080818142820.GA13861@elstar.local> In-Reply-To: <20080818142820.GA13861@elstar.local> Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Aug 18, 2008 at 07:06:14AM -0700, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Sat, Aug 02, 2008 at 11:58:01AM -0700, Andy Bierman wrote: >>>> Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> in RELAX NG, multiple patterns are ANDed: >>>>> >>>>> http://www.relaxng.org/xsd-20010907.html#IDAMDYR >>>>> >>>>> This was accepted in order to have the functionality available in XSD, >>>>> see >>>>> http://lists.oasis-open.org/archives/relax-ng/200105/msg00211.html >>>>> >>>>> I guess the issue for YANG is: Is there a way for ANDing patterns? If >>>>> not, I'd suggest to follow the RELAX NG way. >>>> Yes there already is a way to AND patterns with multiple >>>> typedefs. You can also split up pattern strings into >>>> as many lines and fragments as you want. >>> I just made the experiment of feeding >>> >>> foo = xsd:string { >>> pattern = "bb" >>> pattern = "a.*a" >>> } >>> >>> into trang and I got the following output >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Obviously, they do translate ANDed pattern by generating additional >>> anonymous types. If we want to support multiple ANDed pattern in YANG, >>> we could simply do the same. I am not saying we should - just that >>> there is a relatively straight-forward translation path. >> But this is not correct according to the rules in XSD. >> These patterns are supposed to be ORed together. > > I fail to see why this is not correct. Please explain. > oops -- sorry -- I did not see the nested simpleType. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 07:54:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117993A6978; Mon, 18 Aug 2008 07:54:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4333A6A05 for ; Mon, 18 Aug 2008 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.943 X-Spam-Level: * X-Spam-Status: No, score=1.943 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMrpl76EXVoq for ; Mon, 18 Aug 2008 07:54:25 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 7290A3A6978 for ; Mon, 18 Aug 2008 07:54:25 -0700 (PDT) Received: (qmail 424 invoked from network); 18 Aug 2008 14:54:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 18 Aug 2008 14:54:31 -0000 X-YMail-OSG: La.VFoEVM1mTBF47uIA6kdeI9_aJK5C6_eyVR5Aac_vI1Bwzw9XJ9RthC582xzmK6DaamWFtVtX1wb7Lg6.qq6tbBRwlllYHA_8WaeCxEg1Q8rbzidKK1_vNkIik5RY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A98D24.2040109@netconfcentral.com> Date: Mon, 18 Aug 2008 07:54:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <486B3F45.1010802@netconfcentral.com> <489C196C.5000209@ericsson.com> <20080818115049.GC12968@elstar.local> <20080818.163656.193370708.mbj@tail-f.com> In-Reply-To: <20080818.163656.193370708.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Fri, Aug 08, 2008 at 12:01:16PM +0200, Balazs Lengyel wrote: >> >>> I think the definition of deprecated should be changed. Today it states >>> that if foo is deprecated it might or might not be there, but I agree >>> with Andy that it should rather mean it is supported now, but will be >>> removed in the future (that is the same philosophy that they use in >>> Java). >>> So the proposed text is: >>> >>> Old text: >>> >>> "deprecated" indicates an obsolete definition, but it permits new/ >>> continued implementation in order to foster interoperability with >>> older/existing implementations. >>> >>> New text: >>> >>> "deprecated" means that a definition is still implemented and usable - >>> but you should not use it. It will gradually be phased out in the future. >> I believe the wording "is still implemented and usable" is asking for >> confusion. What about this: >> >> "deprecated" means that a definition is still supported but should >> not be used anymore. > > I think this definition is better than the old one. But the terms > "supported" and "used" are maybe confusing. I think you mean: > > "deprecated" means that a definition is still supported by servers > but should not be used by clients anymore. > > s/should not/SHOULD NOT/ ? > The old text is wrong. Deprecated means the object exists and is supported for now, but could be removed in the future. The DM reader should check for a replacement definition. A normative SHOULD NOT is not appropriate. An implementor MAY choose to use a deprecated definition, but it is NOT RECOMMENDED. Obsolete means the definition in the YANG module is a placeholder (to make sure the name is never reused), and it is no longer in use in the implementation. > > /martin Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 08:24:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4D13A68E8; Mon, 18 Aug 2008 08:24:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D4C3A69E9 for ; Mon, 18 Aug 2008 08:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1a3t5MawLA7 for ; Mon, 18 Aug 2008 08:24:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 290FA3A68E8 for ; Mon, 18 Aug 2008 08:24:37 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B5279D800CB for ; Mon, 18 Aug 2008 17:24:42 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200808111249.m7BCnbQ1097029@idle.juniper.net> References: <200808111249.m7BCnbQ1097029@idle.juniper.net> Organization: CESNET Date: Mon, 18 Aug 2008 17:24:42 +0200 Message-Id: <1219073082.6236.3.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgUG8gMTEuIDA4LiAyMDA4IHYgMDg6NDkgLTA0MDA6Cj4gTWFy dGluIEJqb3JrbHVuZCB3cml0ZXM6Cj4gPkkgYmVsaWV2ZSBpdCB3YXMgQW5keSB3aG8gcG9pbnRl ZCBvdXQgdGhhdCB0aGVyZSBpcyBvbmUgdGhpbmcgd2hpY2gKPiA+YnJlYWtzIHRoZSBydWxlIHRo YXQgYSBzdWJtb2R1bGUgY2FuIGJlIHZhbGlkYXRlZCBpbiBpc29sYXRpb24gZnJvbQo+ID5pdHMg bWFpbiBtb2R1bGUuICBUaGUgcHJvYmxlbSBpcyB0aGUgbG9jYWwgcHJlZml4IHVzZWQgZm9yIHRo ZSBtb2R1bGUuCj4gPkluIGEgc3VibW9kdWxlLCBhbiBYUGF0aCBleHByZXNzaW9uIG1pZ2h0IHVz ZSB0aGUgbW9kdWxlJ3MgbG9jYWwKPiA+cHJlZml4IHRvIHJlZmVyIHRvIGxvY2FsIG5vZGVzLiAg QnV0IHRoZSBtb2R1bGUncyBwcmVmaXggaXMgZGVmaW5lZCBpbgo+ID50aGUgbWFpbiBtb2R1bGUu Cj4gCj4gQ2FuIHdlIHJlcXVpcmUgdGhhdCBYUGF0aCBleHByZXNzaW9ucyBmb3IgdGhlIGN1cnJl bnQgbmFtZXNwYWNlCj4gbm90IHVzZSBhIHByZWZpeD8gIEl0J3MgbW9yZSBjbGVhciBhbmQgbGVz cyB3b3JrLiAgT3IgaXMgdGhlcmUKPiBzb21lIGNhc2Ugd2hlcmUgeW91IG5lZWQgdGhlIHByZWZp eD8KCkkgaGF2ZSB0byByZWl0ZXJhdGUgdGhhdCBhY2NvcmRpbmcgdG8gdGhlIFhQYXRoIDEuMCBu byBwcmVmaXggbWVhbnMgbnVsbApuYW1lc3BhY2UuIFNvIGFjY2VwdGluZyB0aGlzIGNvbnZlbnRp b24gYnJlYWtzIHRoZSBYUGF0aCBzcGVjLgoKTGFkYQoKPiAKPiBUaGFua3MsCj4gIFBoaWwKPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBt YWlsaW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJ RDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 18 08:40:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E951128C136; Mon, 18 Aug 2008 08:40:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263093A6B55 for ; Mon, 18 Aug 2008 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.831 X-Spam-Level: * X-Spam-Status: No, score=1.831 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_50=0.001, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc8tgJjhZKuA for ; Mon, 18 Aug 2008 08:40:54 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 3B23728C149 for ; Mon, 18 Aug 2008 08:40:53 -0700 (PDT) Received: (qmail 494 invoked from network); 18 Aug 2008 15:40:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2008 15:40:50 -0000 X-YMail-OSG: m4pyOHcVM1lSfYL0EqXwB6Y79WEtDPQ1Gf5M0uidk6pXM8Uv4bteyxThSGLEfhx96n93gZdPElaBowHhWBA0gygJTrUSdnGxiWL1NLyTUQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A997FF.7060509@netconfcentral.com> Date: Mon, 18 Aug 2008 08:40:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200808111249.m7BCnbQ1097029@idle.juniper.net> <1219073082.6236.3.camel@missotis> In-Reply-To: <1219073082.6236.3.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IFBvIDExLiAwOC4g MjAwOCB2IDA4OjQ5IC0wNDAwOgo+PiBNYXJ0aW4gQmpvcmtsdW5kIHdyaXRlczoKPj4+IEkgYmVs aWV2ZSBpdCB3YXMgQW5keSB3aG8gcG9pbnRlZCBvdXQgdGhhdCB0aGVyZSBpcyBvbmUgdGhpbmcg d2hpY2gKPj4+IGJyZWFrcyB0aGUgcnVsZSB0aGF0IGEgc3VibW9kdWxlIGNhbiBiZSB2YWxpZGF0 ZWQgaW4gaXNvbGF0aW9uIGZyb20KPj4+IGl0cyBtYWluIG1vZHVsZS4gIFRoZSBwcm9ibGVtIGlz IHRoZSBsb2NhbCBwcmVmaXggdXNlZCBmb3IgdGhlIG1vZHVsZS4KPj4+IEluIGEgc3VibW9kdWxl LCBhbiBYUGF0aCBleHByZXNzaW9uIG1pZ2h0IHVzZSB0aGUgbW9kdWxlJ3MgbG9jYWwKPj4+IHBy ZWZpeCB0byByZWZlciB0byBsb2NhbCBub2Rlcy4gIEJ1dCB0aGUgbW9kdWxlJ3MgcHJlZml4IGlz IGRlZmluZWQgaW4KPj4+IHRoZSBtYWluIG1vZHVsZS4KPj4gQ2FuIHdlIHJlcXVpcmUgdGhhdCBY UGF0aCBleHByZXNzaW9ucyBmb3IgdGhlIGN1cnJlbnQgbmFtZXNwYWNlCj4+IG5vdCB1c2UgYSBw cmVmaXg/ICBJdCdzIG1vcmUgY2xlYXIgYW5kIGxlc3Mgd29yay4gIE9yIGlzIHRoZXJlCj4+IHNv bWUgY2FzZSB3aGVyZSB5b3UgbmVlZCB0aGUgcHJlZml4Pwo+IAo+IEkgaGF2ZSB0byByZWl0ZXJh dGUgdGhhdCBhY2NvcmRpbmcgdG8gdGhlIFhQYXRoIDEuMCBubyBwcmVmaXggbWVhbnMgbnVsbAo+ IG5hbWVzcGFjZS4gU28gYWNjZXB0aW5nIHRoaXMgY29udmVudGlvbiBicmVha3MgdGhlIFhQYXRo IHNwZWMuCj4gCgoxKSB0aGVyZSBpcyBhIHByZWZpeCAtLSBpdCBpcyBpbiB0aGUgbWFpbiBtb2R1 bGUsCiAgICBpbmRpY2F0ZWQgYnkgdGhlICdiZWxvbmdzLXRvJy4gIFlvdSBnZXQgaXQgZnJvbSB0 aGVyZS4KCjIpIFdlIGFyZSBkZWZpbmluZyB0aGUgWUFORyBzcGVjLCBub3QgdGhlIFhQYXRoIHNw ZWMuCiAgICBQYXJ0IG9mIHRoZSBZQU5HIHNwZWMgZGVmaW5lcyB0aGUgZXZhbHVhdGlvbiBjb250 ZXh0cwogICAgdGhhdCBhcmUgdXNlZCBieSBhIFlBTkcgY29tcGlsZXIgdG8gcHJvY2VzcyBYUGF0 aCBleHByZXNzaW9ucy4KICAgIEl0IGlzIHBlcmZlY3RseSB2YWxpZCBmb3IgdGhlIGFscmVhZHkg Y3VzdG9tIFlBTkcgY29udGV4dAogICAgdG8gZGVjbGFyZSB0aGF0IG1pc3NpbmcgcHJlZml4ZXMg YXJlIHJlcGxhY2VkIHdpdGggdGhlIGN1cnJlbnQKICAgIG1vZHVsZSBwcmVmaXgsIHdoZW4gZXZh bHVhdGluZyB0aGUgWFBhdGggZXhwcmVzc2lvbiwKICAgIGFuZCB3aGVuIHRyYW5zbGF0aW5nIFlB TkcgdG8gRFNETC4KCgo+IExhZGEKPiAKPj4gVGhhbmtzLAo+PiAgUGhpbAoKQW5keQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcg bGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QK From netmod-bounces@ietf.org Mon Aug 18 09:33:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6AB3A687E; Mon, 18 Aug 2008 09:33:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544783A698D for ; Mon, 18 Aug 2008 09:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3Zz186aep2H for ; Mon, 18 Aug 2008 09:33:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7AB3F3A687E for ; Mon, 18 Aug 2008 09:33:06 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 949AC76C040; Mon, 18 Aug 2008 18:33:12 +0200 (CEST) Date: Mon, 18 Aug 2008 18:33:09 +0200 (CEST) Message-Id: <20080818.183309.251529235.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48A9830A.9090700@netconfcentral.com> References: <20080811.090508.104047439.mbj@tail-f.com> <20080818122416.GD12968@elstar.local> <48A9830A.9090700@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: > > > >> To solve this problem, I suggest we add an optional prefix > >> substatement to belongs-to: > >> > >> submodule foo { > >> belongs-to bar { > >> prefix b; > >> } > >> ... > >> } > > Is this problem important enough to require the suggested solution? > > What happens if the prefix declared in belongs-to is different from > > the prefix declared in the module? > > > > IMO - NO. > > What about include statements in sub-modules? > They have no prefix. It is assumed that > all sub-modules share the same prefix. Yes. Specifying the prefix in belongs-to does not change this. > If sub-module A uses 'foo' from sub-module B, > is is 'foo', 'A:foo', 'B:foo', or something new? It is either just 'foo' or 'x:foo' if x is the prefix from the belongs-to. > What if a 'B' is already imported into sub-A? A submodule cannot be imported. > I do not like this solution proposal because the problem > is not really very hard to solve with code. But it is hard to solve for the reader. With this simple solution, all prefixes are locally declared. This is more clear and a win for the reader. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 09:45:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C233A6852; Mon, 18 Aug 2008 09:45:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45E13A6852 for ; Mon, 18 Aug 2008 09:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.794 X-Spam-Level: * X-Spam-Status: No, score=1.794 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTDxynyR--1c for ; Mon, 18 Aug 2008 09:45:46 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id CF0CF3A67E6 for ; Mon, 18 Aug 2008 09:45:45 -0700 (PDT) Received: (qmail 74198 invoked from network); 18 Aug 2008 16:45:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2008 16:45:50 -0000 X-YMail-OSG: WeJEtKEVM1nWI5u3doZArI5QMLyDmrmGrASB8H_MUPNeTs4BDCCMItug92aWC8XsMUtLGSJjjIpC9nQm9YUxNSLsbYE21I1GPMVstA7nvBepFQ28fI_w9AqLumKalWI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A9A73D.2030001@netconfcentral.com> Date: Mon, 18 Aug 2008 09:45:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.090508.104047439.mbj@tail-f.com> <20080818122416.GD12968@elstar.local> <48A9830A.9090700@netconfcentral.com> <20080818.183309.251529235.mbj@tail-f.com> In-Reply-To: <20080818.183309.251529235.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: >>> >>>> To solve this problem, I suggest we add an optional prefix >>>> substatement to belongs-to: >>>> >>>> submodule foo { >>>> belongs-to bar { >>>> prefix b; >>>> } >>>> ... >>>> } >>> Is this problem important enough to require the suggested solution? >>> What happens if the prefix declared in belongs-to is different from >>> the prefix declared in the module? >>> >> IMO - NO. >> >> What about include statements in sub-modules? >> They have no prefix. It is assumed that >> all sub-modules share the same prefix. > > Yes. Specifying the prefix in belongs-to does not change this. > >> If sub-module A uses 'foo' from sub-module B, >> is is 'foo', 'A:foo', 'B:foo', or something new? > > It is either just 'foo' or 'x:foo' if x is the prefix from the > belongs-to. > >> What if a 'B' is already imported into sub-A? > > A submodule cannot be imported. > >> I do not like this solution proposal because the problem >> is not really very hard to solve with code. > > But it is hard to solve for the reader. With this simple solution, > all prefixes are locally declared. This is more clear and a win for > the reader. > IMO, it is not a win. If each prefix represents a different namespace, that is clear to the reader. If 2 prefixes sometimes indicate the same module and same namespace, then this is confusing. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 10:19:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196CF3A67DB; Mon, 18 Aug 2008 10:19:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8973A6852 for ; Mon, 18 Aug 2008 10:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_50=0.001, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPozMwQpgogx for ; Mon, 18 Aug 2008 10:19:29 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 14ECF3A67DB for ; Mon, 18 Aug 2008 10:19:29 -0700 (PDT) Received: (qmail 52201 invoked from network); 18 Aug 2008 17:18:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2008 17:18:49 -0000 X-YMail-OSG: UBoiAMEVM1npJOILOpJIEVt71ZX30L_vuZJnCUBiWmaMU2RwIRUlu_N9sVRUuuXiFTXdK8BzDhcALk3Rk0hpqlPUgK5wYk3IzshLokCByNUKNvRa9lqSo0ELmJSO1Z8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A9AEF7.8010902@netconfcentral.com> Date: Mon, 18 Aug 2008 10:18:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.090508.104047439.mbj@tail-f.com> <20080818122416.GD12968@elstar.local> <48A9830A.9090700@netconfcentral.com> <20080818.183309.251529235.mbj@tail-f.com> In-Reply-To: <20080818.183309.251529235.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Mon, Aug 11, 2008 at 09:05:08AM +0200, Martin Bjorklund wrote: >>> >>>> To solve this problem, I suggest we add an optional prefix >>>> substatement to belongs-to: >>>> >>>> submodule foo { >>>> belongs-to bar { >>>> prefix b; >>>> } >>>> ... >>>> } >>> Is this problem important enough to require the suggested solution? >>> What happens if the prefix declared in belongs-to is different from >>> the prefix declared in the module? >>> >> IMO - NO. >> >> What about include statements in sub-modules? >> They have no prefix. It is assumed that >> all sub-modules share the same prefix. > > Yes. Specifying the prefix in belongs-to does not change this. > >> If sub-module A uses 'foo' from sub-module B, >> is is 'foo', 'A:foo', 'B:foo', or something new? > > It is either just 'foo' or 'x:foo' if x is the prefix from the > belongs-to. > >> What if a 'B' is already imported into sub-A? > > A submodule cannot be imported. > I meant included. What happens if the optional 'prefix b;' is not present? Does that mean the module prefix MUST NOT be used for any local identifier (or any identifier from an 'include')? Otherwise, the compiler (and reader) need to look at the main module to get the prefix. I do not mind this change if that rule was in place. Add it to the list of complex prefix transformations that a compiler needs to do when expanding augments and uses. >> I do not like this solution proposal because the problem >> is not really very hard to solve with code. > > But it is hard to solve for the reader. With this simple solution, > all prefixes are locally declared. This is more clear and a win for > the reader. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 10:29:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E5E3A6768; Mon, 18 Aug 2008 10:29:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521B53A6932 for ; Mon, 18 Aug 2008 10:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf-G3JsZSSm1 for ; Mon, 18 Aug 2008 10:29:36 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 3D5883A6768 for ; Mon, 18 Aug 2008 10:29:35 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 18 Aug 2008 10:27:36 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 10:27:34 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 10:27:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 10:27:31 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7IHRVu36595; Mon, 18 Aug 2008 10:27:31 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7IHO5cu058503; Mon, 18 Aug 2008 17:24:05 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808181724.m7IHO5cu058503@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1219073082.6236.3.camel@missotis> Date: Mon, 18 Aug 2008 13:24:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2008 17:27:31.0758 (UTC) FILETIME=[B20A6CE0:01C90157] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >I have to reiterate that according to the XPath 1.0 no prefix means null >namespace. So accepting this convention breaks the XPath spec. But I think we get to say what the null namespace means in our context. I think this is fine. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 10:32:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9846B3A677E; Mon, 18 Aug 2008 10:32:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B68A3A6B88 for ; Mon, 18 Aug 2008 10:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PSSh1qrqhdD for ; Mon, 18 Aug 2008 10:32:46 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 98AB93A677E for ; Mon, 18 Aug 2008 10:32:41 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 18 Aug 2008 10:31:48 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 10:31:12 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 10:31:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 10:31:11 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7IHVBu38037; Mon, 18 Aug 2008 10:31:11 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7IHRjjp058573; Mon, 18 Aug 2008 17:27:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808181727.m7IHRjjp058573@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-reply-to: Date: Mon, 18 Aug 2008 13:27:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 18 Aug 2008 17:31:11.0867 (UTC) FILETIME=[353C64B0:01C90158] Cc: netmod@ietf.org Subject: Re: [netmod] Augmenting vs. Sub-classing WAS:RE: when statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Ersue, Mehmet (NSN - DE/Munich)" writes: >Also, if I derive a class fooChild from foo, all instances >of the foo class remain the same. fooChild and foo >generate different type of instances although the actions >and data have been derived and are reused. If you only wish to derive fooChild from foo, you can just use foo inside fooChild: grouping foo { leaf neat-stuff { ... } } grouping fooChild { use foo; leaf child-stuff { ... } } This will leave all original uses of foo untouched, protecting them in a way augmented grouping does not. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 12:26:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEF63A6D83; Mon, 18 Aug 2008 12:26:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBC33A6D88 for ; Mon, 18 Aug 2008 12:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0R8sA3JVpLY for ; Mon, 18 Aug 2008 12:25:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B831B3A6D83 for ; Mon, 18 Aug 2008 12:25:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4FF2D1C40F4B for ; Mon, 18 Aug 2008 12:26:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-162.clppva.btas.verizon.net [71.161.51.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 5E8121C40F49 for ; Mon, 18 Aug 2008 12:26:03 -0700 (PDT) Message-ID: <48A9CC80.8010206@joelhalpern.com> Date: Mon, 18 Aug 2008 15:24:48 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: netmod@ietf.org Subject: [netmod] YANG thoughts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Having read the document, below are some comments that the working group may find helpful. After talking with folks, it seemed worthwhile to send them to the list. The main thing that strikes me, as you can probably see in the comments, is that this would have been easier to understand with a bit of motivation. There are a number of design choices which while reasonable, seem odd. I suspect that there are strong reasons for the choices. But they are not stated. Comments: The first thing that struck me was that the absolute insistence on non-leafs not having values seemed strange. It makes for much cleaner XML. And is not actually unreasonable. But it is jarring to the reader. It would also help if the sentence about datatypes being simple values occurred earlier. For a while I was wondering when one used a collection of leafs and when one used a complex data structure. Once I hit the statement that datatypes are always simple values, this became clear. In describing the choice construct, (in 4.2.7, not the later formal definition) it would be useful if the document showed where a choice would go. Is it free-standing, and referenced like "using", or does it appear in a container as if it were a node? (Yes, it is clear later, but it leaves the reader wondering.) It might be a good idea to indicate when "key" is first described (4.2.2.4) whether a single leaf is always used as a key (so one uses nested nodes for multiple indices) or whether multiple keys can be use together. (I see later that you went for multiple keys. Just say the statement can list multiple keys in 4.2.2.4.) The include /import rules seem designed to make life difficult. 1) It is not clear what happens if the same module is imported more than once by different parts of the include tree. 2) The prohibition against circular includes and imports means that folks writing these things have to be very careful. (I understand that the basic answer is that if two pieces need to include or import each other, then they should be one piece. The point is that these rule means that they HAVE to be one one piece.) These rules presumably exist for good reasons. But I suspect that some explanation of the reasons will help the reader grasp the context better. And probably help the implementors do a better job. Also, the distinction between import and include, with include only for pieces that are part of the same module, and import for anything at all, looks arbitrary. It presumably isn't. But as it stands it is at best confusing. Is there some subtle but substantive difference in what they do? Given that the key-arg syntax in appendix D is a list of identifiers, it seems that all of the leafs referenced by a key statment must be directly contained in the list being keyed, and not in a nested container (much less a nested list). It would be sensible to actually say this in 7.8.2. 7.8.3 (unique) and later 7.15 refer to things being in descendant form. But no text in this document says what descendant form is. Could something be put in the glossary section, even if this is a standard XML term? (If so, then the glossary can just say "XML term for ..., see ... for a precise definition.) Confusions: The prefix statement within a module (as distinct from that used in an import statement) appears to be advisory, even though it is mandatory, and is described as "defining" the prefix for the module. In practice, it seems to be advise to anyone importing the module (either in xml or YANG) as to what prefix they SHOULD use, if there is no conflict. So it appears never to be checked. Am I missing something important about how this statement works? Personal prejudice: The fact that leaf, and similar statements, have very restricted fields allowed inside a "uses" makes me uncomfortable. It seems that the parser will need to understand that many things that are normally legal are not allowed in that particular leaf (leaf-list...). _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 18 13:06:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646033A6852; Mon, 18 Aug 2008 13:06:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553423A6CCA for ; Mon, 18 Aug 2008 13:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDD9v4FFSJdM for ; Mon, 18 Aug 2008 13:06:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B4BB53A6D7B for ; Mon, 18 Aug 2008 13:06:49 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A4804D800C5; Mon, 18 Aug 2008 22:06:56 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48A997FF.7060509@netconfcentral.com> References: <200808111249.m7BCnbQ1097029@idle.juniper.net> <1219073082.6236.3.camel@missotis> <48A997FF.7060509@netconfcentral.com> Organization: CESNET Date: Mon, 18 Aug 2008 22:06:56 +0200 Message-Id: <1219090016.6236.56.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDE4LiAwOC4gMjAwOCB2IDA4OjQwIC0wNzAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IFBvIDExLiAwOC4g MjAwOCB2IDA4OjQ5IC0wNDAwOgo+ID4+IE1hcnRpbiBCam9ya2x1bmQgd3JpdGVzOgo+ID4+PiBJ IGJlbGlldmUgaXQgd2FzIEFuZHkgd2hvIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgaXMgb25lIHRo aW5nIHdoaWNoCj4gPj4+IGJyZWFrcyB0aGUgcnVsZSB0aGF0IGEgc3VibW9kdWxlIGNhbiBiZSB2 YWxpZGF0ZWQgaW4gaXNvbGF0aW9uIGZyb20KPiA+Pj4gaXRzIG1haW4gbW9kdWxlLiAgVGhlIHBy b2JsZW0gaXMgdGhlIGxvY2FsIHByZWZpeCB1c2VkIGZvciB0aGUgbW9kdWxlLgo+ID4+PiBJbiBh IHN1Ym1vZHVsZSwgYW4gWFBhdGggZXhwcmVzc2lvbiBtaWdodCB1c2UgdGhlIG1vZHVsZSdzIGxv Y2FsCj4gPj4+IHByZWZpeCB0byByZWZlciB0byBsb2NhbCBub2Rlcy4gIEJ1dCB0aGUgbW9kdWxl J3MgcHJlZml4IGlzIGRlZmluZWQgaW4KPiA+Pj4gdGhlIG1haW4gbW9kdWxlLgo+ID4+IENhbiB3 ZSByZXF1aXJlIHRoYXQgWFBhdGggZXhwcmVzc2lvbnMgZm9yIHRoZSBjdXJyZW50IG5hbWVzcGFj ZQo+ID4+IG5vdCB1c2UgYSBwcmVmaXg/ICBJdCdzIG1vcmUgY2xlYXIgYW5kIGxlc3Mgd29yay4g IE9yIGlzIHRoZXJlCj4gPj4gc29tZSBjYXNlIHdoZXJlIHlvdSBuZWVkIHRoZSBwcmVmaXg/Cj4g PiAKPiA+IEkgaGF2ZSB0byByZWl0ZXJhdGUgdGhhdCBhY2NvcmRpbmcgdG8gdGhlIFhQYXRoIDEu MCBubyBwcmVmaXggbWVhbnMgbnVsbAo+ID4gbmFtZXNwYWNlLiBTbyBhY2NlcHRpbmcgdGhpcyBj b252ZW50aW9uIGJyZWFrcyB0aGUgWFBhdGggc3BlYy4KPiA+IAo+IAo+IDEpIHRoZXJlIGlzIGEg cHJlZml4IC0tIGl0IGlzIGluIHRoZSBtYWluIG1vZHVsZSwKPiAgICAgaW5kaWNhdGVkIGJ5IHRo ZSAnYmVsb25ncy10bycuICBZb3UgZ2V0IGl0IGZyb20gdGhlcmUuCgpTZWMuIDIuMyBvZiB0aGUg WFBhdGggMS4wIFJlY29tbWVuZGF0aW9uOiAiaWYgdGhlIFFOYW1lIGRvZXMgbm90IGhhdmUgYQpw cmVmaXgsIHRoZW4gdGhlIG5hbWVzcGFjZSBVUkkgaXMgbnVsbCIuIEFuZCBRTmFtZSBpcyBldmVy eSBpbmRpdmlkdWFsCmNvbXBvbmVudCBvZiBldmVyeSBYUGF0aCBleHByZXNzaW9uLiBFdmVyeW9u ZSB3aG8gaGFzIGJlZW4gdXNpbmcKWFBhdGgvWFNMVCBleHRlbnNpdmVseSBtdXN0IGhhdmUgYmVl biBiaXR0ZW4gYnkgdGhpcyBhbHJlYWR5OiBUaGVyZSBpcwpOTyBXQVkgdG8gc3BlY2lmeSBhIGNv bnRleHQgaW4gd2hpY2ggdGhlIGNvbmNlcHQgb2YgYSBkZWZhdWx0IChub24tbnVsbCkKbmFtZXNw YWNlIGNhbiBhcHBseS4gTm90ZSB0aGF0IFhQYXRoIDIuMCBhZGRyZXNzZXMgdGhpcyBpc3N1ZSwg cHJvYmFibHkKb24gcG9wdWxhciBkZW1hbmQuCgo+IAo+IDIpIFdlIGFyZSBkZWZpbmluZyB0aGUg WUFORyBzcGVjLCBub3QgdGhlIFhQYXRoIHNwZWMuCgpJdCB3aWxsIHRha2UgbW9yZSB0aGFuIG9u ZSBwYXJhZ3JhcGggdG8gZGVmaW5lICJzb21ldGhpbmcgbGlrZSBYUGF0aCIuIEkKd291bGQgcHJl ZmVyIHRvIHVzZSBYUGF0aCAxLjAgYWNjb3JkaW5nIHRvIGl0cyBzcGVjIGFuZCBhY2NlcHQgaXRz CmZlYXR1cmVzIHRoYXQgbWF5IGJlIHBlcmNlaXZlZCBhcyBhbm5veWluZy4gSSB0aGluayBpdCB3 b3VsZG4ndCBiZSB0aGF0CmJhZCBhZnRlciBhbGwgLSBhbmQgcGVyaGFwcyBpdCBtYXkgaGVscCB0 byBjbGFyaWZ5IHRoZSB1c2Ugb2YgWFBhdGgKZXhwcmVzc2lvbnMgaW4gYXVnbWVudHMgZXRjLgoK TGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Aug 18 13:30:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB9828C1FD; Mon, 18 Aug 2008 13:30:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46D93A6ADB for ; Mon, 18 Aug 2008 13:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.195 X-Spam-Level: * X-Spam-Status: No, score=1.195 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_05=-1.11, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4oaaOXwk8Eo for ; Mon, 18 Aug 2008 13:30:02 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id D378428C202 for ; Mon, 18 Aug 2008 13:30:01 -0700 (PDT) Received: (qmail 45328 invoked from network); 18 Aug 2008 20:30:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 18 Aug 2008 20:30:07 -0000 X-YMail-OSG: vtsPnjUVM1lUez1Z67rI49YCqmKqHK_o7jFm.aWRGzrqk07hfaKrFmZ06XVn9q7u03yYLCNMdNxBoi4OpVDqBEJVMHp06ldvE0eeat0ZJg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A9DBCD.70903@netconfcentral.com> Date: Mon, 18 Aug 2008 13:30:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200808111249.m7BCnbQ1097029@idle.juniper.net> <1219073082.6236.3.camel@missotis> <48A997FF.7060509@netconfcentral.com> <1219090016.6236.56.camel@missotis> In-Reply-To: <1219090016.6236.56.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAxOC4gMDgu IDIwMDggdiAwODo0MCAtMDcwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pj4gUGhpbCBT aGFmZXIgcMOtxaFlIHYgUG8gMTEuIDA4LiAyMDA4IHYgMDg6NDkgLTA0MDA6Cj4+Pj4gTWFydGlu IEJqb3JrbHVuZCB3cml0ZXM6Cj4+Pj4+IEkgYmVsaWV2ZSBpdCB3YXMgQW5keSB3aG8gcG9pbnRl ZCBvdXQgdGhhdCB0aGVyZSBpcyBvbmUgdGhpbmcgd2hpY2gKPj4+Pj4gYnJlYWtzIHRoZSBydWxl IHRoYXQgYSBzdWJtb2R1bGUgY2FuIGJlIHZhbGlkYXRlZCBpbiBpc29sYXRpb24gZnJvbQo+Pj4+ PiBpdHMgbWFpbiBtb2R1bGUuICBUaGUgcHJvYmxlbSBpcyB0aGUgbG9jYWwgcHJlZml4IHVzZWQg Zm9yIHRoZSBtb2R1bGUuCj4+Pj4+IEluIGEgc3VibW9kdWxlLCBhbiBYUGF0aCBleHByZXNzaW9u IG1pZ2h0IHVzZSB0aGUgbW9kdWxlJ3MgbG9jYWwKPj4+Pj4gcHJlZml4IHRvIHJlZmVyIHRvIGxv Y2FsIG5vZGVzLiAgQnV0IHRoZSBtb2R1bGUncyBwcmVmaXggaXMgZGVmaW5lZCBpbgo+Pj4+PiB0 aGUgbWFpbiBtb2R1bGUuCj4+Pj4gQ2FuIHdlIHJlcXVpcmUgdGhhdCBYUGF0aCBleHByZXNzaW9u cyBmb3IgdGhlIGN1cnJlbnQgbmFtZXNwYWNlCj4+Pj4gbm90IHVzZSBhIHByZWZpeD8gIEl0J3Mg bW9yZSBjbGVhciBhbmQgbGVzcyB3b3JrLiAgT3IgaXMgdGhlcmUKPj4+PiBzb21lIGNhc2Ugd2hl cmUgeW91IG5lZWQgdGhlIHByZWZpeD8KPj4+IEkgaGF2ZSB0byByZWl0ZXJhdGUgdGhhdCBhY2Nv cmRpbmcgdG8gdGhlIFhQYXRoIDEuMCBubyBwcmVmaXggbWVhbnMgbnVsbAo+Pj4gbmFtZXNwYWNl LiBTbyBhY2NlcHRpbmcgdGhpcyBjb252ZW50aW9uIGJyZWFrcyB0aGUgWFBhdGggc3BlYy4KPj4+ Cj4+IDEpIHRoZXJlIGlzIGEgcHJlZml4IC0tIGl0IGlzIGluIHRoZSBtYWluIG1vZHVsZSwKPj4g ICAgIGluZGljYXRlZCBieSB0aGUgJ2JlbG9uZ3MtdG8nLiAgWW91IGdldCBpdCBmcm9tIHRoZXJl Lgo+IAo+IFNlYy4gMi4zIG9mIHRoZSBYUGF0aCAxLjAgUmVjb21tZW5kYXRpb246ICJpZiB0aGUg UU5hbWUgZG9lcyBub3QgaGF2ZSBhCj4gcHJlZml4LCB0aGVuIHRoZSBuYW1lc3BhY2UgVVJJIGlz IG51bGwiLiBBbmQgUU5hbWUgaXMgZXZlcnkgaW5kaXZpZHVhbAo+IGNvbXBvbmVudCBvZiBldmVy eSBYUGF0aCBleHByZXNzaW9uLiBFdmVyeW9uZSB3aG8gaGFzIGJlZW4gdXNpbmcKPiBYUGF0aC9Y U0xUIGV4dGVuc2l2ZWx5IG11c3QgaGF2ZSBiZWVuIGJpdHRlbiBieSB0aGlzIGFscmVhZHk6IFRo ZXJlIGlzCj4gTk8gV0FZIHRvIHNwZWNpZnkgYSBjb250ZXh0IGluIHdoaWNoIHRoZSBjb25jZXB0 IG9mIGEgZGVmYXVsdCAobm9uLW51bGwpCj4gbmFtZXNwYWNlIGNhbiBhcHBseS4gTm90ZSB0aGF0 IFhQYXRoIDIuMCBhZGRyZXNzZXMgdGhpcyBpc3N1ZSwgcHJvYmFibHkKPiBvbiBwb3B1bGFyIGRl bWFuZC4KPiAKPj4gMikgV2UgYXJlIGRlZmluaW5nIHRoZSBZQU5HIHNwZWMsIG5vdCB0aGUgWFBh dGggc3BlYy4KPiAKPiBJdCB3aWxsIHRha2UgbW9yZSB0aGFuIG9uZSBwYXJhZ3JhcGggdG8gZGVm aW5lICJzb21ldGhpbmcgbGlrZSBYUGF0aCIuIEkKPiB3b3VsZCBwcmVmZXIgdG8gdXNlIFhQYXRo IDEuMCBhY2NvcmRpbmcgdG8gaXRzIHNwZWMgYW5kIGFjY2VwdCBpdHMKPiBmZWF0dXJlcyB0aGF0 IG1heSBiZSBwZXJjZWl2ZWQgYXMgYW5ub3lpbmcuIEkgdGhpbmsgaXQgd291bGRuJ3QgYmUgdGhh dAo+IGJhZCBhZnRlciBhbGwgLSBhbmQgcGVyaGFwcyBpdCBtYXkgaGVscCB0byBjbGFyaWZ5IHRo ZSB1c2Ugb2YgWFBhdGgKPiBleHByZXNzaW9ucyBpbiBhdWdtZW50cyBldGMuCj4gCgpJIGFtIG5v dCBjb252aW5jZWQuCkl0IGlzIG5vdCBoYXJkIHRvIGtub3cgd2hpY2ggaXMgdGhlIGN1cnJlbnQg bW9kdWxlCmluIHlvdXIgaW1wbGVtZW50YXRpb24uICBJdCBpcyB0aGVyZWZvcmUgbm90IGhhcmQK dG8gaW5zZXJ0IHRoZSBtb2R1bGUgcHJlZml4IHdoZW4gaXQgaXMgbWlzc2luZy4KCkkgdGhpbmsg dGhlIFlBTkcgdG8gRFNETCB0cmFuc2xhdGlvbiBtdXN0IGFjY291bnQKZm9yIGFsbCBzb3J0cyBv ZiBwcmVmaXggdHJhbnNsYXRpb25zLCB0aGlzIGJlaW5nIG9uZSBvZiB0aGVtLgpZb3UgYXJlIGdv aW5nIHRvIGZlZWQgdGhlIERTREwgZmlsZSBkaXJlY3RseSB0byBYUGF0aCwKbm90IHRoZSBZQU5H IGZpbGUuCgpUaGUgYWN0dWFsIHVzYWdlIG9mIG11c3Qvd2hlbiBpcyBnb2luZyB0bwpiZSBhbG1v c3QgZW50aXJlbHkgcmVsYXRlZCB0byB0aGUgbG9jYWwgbW9kdWxlLgpBZGRpbmcgcHJlZml4ZXMg ZXZlcnl3aGVyZSBmb3IgdGhlIGxvY2FsIG1vZHVsZSBpcyBqdXN0Cm9uZSBvZiB0aGUgbWFueSB0 aGluZ3MgYSBZQU5HLWF3YXJlIHRvb2wgY2FuIGJlIGV4cGVjdGVkIHRvIGRvCnRvIG1ha2UgaXQg ZWFzaWVyIG9uIHRoZSBodW1hbnMgdXNpbmcgWUFORy4KClNpbmNlIFlBTkcgaXMgZ29pbmcgdG8g dXNlICdjdXJyZW50KCknIGZyb20gWFBhdGggMi4wLAp3aHkgbm90IHVzZSBkZWZhdWx0IG5hbWVz cGFjZSBhcyB3ZWxsPyAgT3IgZG9lcyB0aGlzIGFubm95CnRoZSBzdGFuZGFyZHMgcHVyaXN0cyBl dmVuIG1vcmU/ICBBcmUgd2Ugc3VwcG9zZSBmb3JjZQpodW1hbnMgdG8gZW50ZXIgZXhhY3RseSBY UGF0aCAxLjAgb3IgZXhhY3RseSBYUGF0aCAyLjAsCmJ1dCBub3Qgc29tZXRoaW5nIGluIGJldHdl ZW4/ICBZb3UgY2Fubm90IGZlZWQgJ2N1cnJlbnQoKScKdG8gYSAxLjAgWFBhdGggcGFyc2VyLiAo WW91IGNvdWxkIGZlZWQgaXQgJyR0aGlzJyBob3dldmVyLikKSXNuJ3QgJ2N1cnJlbnQnIGFsc28g YSBwcm9ibGVtLCBpZiBubyBwcmVmaXhlcyBpcyBhIHByb2JsZW0/CgpXZSBjYXJlIGFib3V0IGNv bmZvcm1hbmNlIHRvIFlBTkcgMS4wLCBhbmQgbm90IHNvIG11Y2gKYWJvdXQgY29tcGxldGUgaW1w bGVtZW50YXRpb24gb2YgWFBhdGggMi4wLiAgQ2FuIHdlIGNhbiByZXF1aXJlCmNvbXBsZXRlIGlt cGxlbWVudGF0aW9uIG9mIFhQYXRoIDEuMCwgcGx1cyAnZXh0cmFzJz8KCgo+IExhZGEKPiAKCkFu ZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1v ZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 18 18:22:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0FA3A6C14; Mon, 18 Aug 2008 18:22:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB3F3A6C40 for ; Mon, 18 Aug 2008 18:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLTzpY5+eL-T for ; Mon, 18 Aug 2008 18:22:03 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 0CDA93A6C20 for ; Mon, 18 Aug 2008 18:21:57 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 18 Aug 2008 18:21:51 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 18:12:19 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 18:12:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 18:12:18 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7J1CHu83343; Mon, 18 Aug 2008 18:12:17 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7J18p0t065686; Tue, 19 Aug 2008 01:08:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808190108.m7J18p0t065686@idle.juniper.net> To: Andy Bierman In-reply-to: <48A9DBCD.70903@netconfcentral.com> Date: Mon, 18 Aug 2008 21:08:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Aug 2008 01:12:18.0372 (UTC) FILETIME=[9FC20840:01C90198] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Since YANG is going to use 'current()' from XPath 2.0, >why not use default namespace as well? Or does this annoy >the standards purists even more? Are we suppose force >humans to enter exactly XPath 1.0 or exactly XPath 2.0, >but not something in between? You cannot feed 'current()' >to a 1.0 XPath parser. (You could feed it '$this' however.) >Isn't 'current' also a problem, if no prefixes is a problem? current() is lifted from XSLT, not XPath 2.0. It's the current node being inspected, as opposed to the context node where XPath predicates are evaluated. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 00:37:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137E23A6A6A; Tue, 19 Aug 2008 00:37:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0913A689C for ; Tue, 19 Aug 2008 00:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.67 X-Spam-Level: X-Spam-Status: No, score=-4.67 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIAqkCmcKWHh for ; Tue, 19 Aug 2008 00:37:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 512663A689E for ; Tue, 19 Aug 2008 00:36:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7J7aQkY005775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 09:36:26 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7J7aO3U006341; Tue, 19 Aug 2008 09:36:26 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 09:36:24 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 09:36:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 10:36:22 +0300 Message-ID: <210412A63D60154898B7CDC3C7172BDE4117E1@FIESEXC007.nsn-intra.net> In-Reply-To: <200808131652.m7DGqaks016865@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: Acj9ZmSorFI7h0rzRyeFg7gFthgyFwEY7bTQ References: <210412A63D60154898B7CDC3C7172BDE3D026D@FIESEXC007.nsn-intra.net> <200808131652.m7DGqaks016865@idle.juniper.net> From: "Lahdensivu, Mikko (NSN - FI/Tampere)" To: "ext Phil Shafer" X-OriginalArrivalTime: 19 Aug 2008 07:36:24.0727 (UTC) FILETIME=[4874BA70:01C901CE] Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, >The problem remains: if I use a grouping that you can >randomly augment, then I can never be sure of the set of nodes >I'm getting when I use a grouping. > >On a theoretical level, it may not matter to your application, >but on the practical level, when your application sends my box >content that it doesn't understand, things break. Right, but the problem is the same already with augmenting a list. When your applications needs to use the referred data, it needs to be handle it. In both cases the data structure (grouping or list element) could have been augmented. While use of grouping and reference to a list look different in the payload, I don't consider them fundamentally different from device/application logic point of view; in both cases I use a generic routine in both device and application to process the data, including any augmentations I support for such structure. > >If I made a list of interfaces and reused a standard grouping, >and you augment that grouping with your new nodes, how do you >know whether I implemented your augmented nodes in my list? I >can't come >in after that fact and say "he didn't mean me". Yes, you can put >a "when" on your augment, but that condition may not match my >reuse of the grouping. Right, and if I put a reference to your list, and you augment the list with some new nodes, I cannot say later that I didn't mean that the reference applies also to elements which have augmented nodes. > >>In both cases your application can have a generic routine for reading >>NetworkInterface data from the element, and on both cases you >can have >>a condition on the type of the NetworkInterface so that augmented >>leaves are not applicable to incorrect type of NetworkInterface. > >The generic solution doesn't exist on the device side, where >the config that your application ships to my device must match >the nodes I've implemented in my software. If you augment a grouping within your device (either in your device specific model, or by supporting some standard model), you can create a routine to handle processing of that grouping regardless of where in the model it is used, concept of sub-routine does exist in devices as well. Mikko _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 02:23:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2225B3A682F; Tue, 19 Aug 2008 02:23:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846F43A6835 for ; Tue, 19 Aug 2008 02:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uFBBsuYzlnF for ; Tue, 19 Aug 2008 02:23:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AAE3B3A682F for ; Tue, 19 Aug 2008 02:23:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CD842156A for ; Tue, 19 Aug 2008 11:23:16 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-42-48aa91043e2a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 668B32155E for ; Tue, 19 Aug 2008 11:23:16 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 11:23:16 +0200 Received: from selic023.ki.sw.ericsson.se ([147.214.33.175]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 11:23:16 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 19 Aug 2008 11:23:18 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808191123.18194.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Aug 2008 09:23:16.0062 (UTC) FILETIME=[35E8CFE0:01C901DD] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call: Issue types-001: duplicate uri definition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, This consensus call is for an issue in draft-schoenw-netmod-yang-types-01, which is to become a WG document at its next revision. See http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_types There are currently two URI definitions in the document (page 8 in the yang-types module and page 17 in the inet-types module). Proposed consensus is to remove the definition from yang-types. Speak up now if you object. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 03:28:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496033A699C; Tue, 19 Aug 2008 03:28:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0491A3A68D2 for ; Tue, 19 Aug 2008 03:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWqBCDs9butt for ; Tue, 19 Aug 2008 03:28:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B1C293A6828 for ; Tue, 19 Aug 2008 03:28:40 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B886420990 for ; Tue, 19 Aug 2008 12:28:42 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-d9-48aaa05ab1ba Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9CEBF208D0 for ; Tue, 19 Aug 2008 12:28:42 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 12:28:39 +0200 Received: from selic023.ki.sw.ericsson.se ([147.214.33.175]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 12:28:39 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 19 Aug 2008 12:28:41 +0200 User-Agent: KMail/1.9.9 References: <20080801102824.GA4873@elstar.local> <4894AE39.5010001@netconfcentral.com> <20080818134228.GE13227@elstar.local> In-Reply-To: <20080818134228.GE13227@elstar.local> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808191228.41549.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Aug 2008 10:28:39.0092 (UTC) FILETIME=[5837AF40:01C901E6] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi all, On Monday 18 August 2008 15.42.28 Juergen Schoenwaelder wrote: > On Sat, Aug 02, 2008 at 11:58:01AM -0700, Andy Bierman wrote: > > Ladislav Lhotka wrote: > >> Hi, > >> > >> in RELAX NG, multiple patterns are ANDed: > >> > >> http://www.relaxng.org/xsd-20010907.html#IDAMDYR > >> > >> This was accepted in order to have the functionality available in XSD, > >> see > >> http://lists.oasis-open.org/archives/relax-ng/200105/msg00211.html > >> > >> I guess the issue for YANG is: Is there a way for ANDing patterns? If > >> not, I'd suggest to follow the RELAX NG way. > > > > Yes there already is a way to AND patterns with multiple > > typedefs. You can also split up pattern strings into > > as many lines and fragments as you want. > > I just made the experiment of feeding > > foo = > xsd:string { > pattern = "bb" > pattern = "a.*a" > } > > into trang and I got the following output > > > > > > > > > > > > > Obviously, they do translate ANDed pattern by generating additional > anonymous types. If we want to support multiple ANDed pattern in YANG, > we could simply do the same. I am not saying we should - just that > there is a relatively straight-forward translation path. So, if I've got it right, we have two choices: 1. leave things like they are (only one pattern) 2. allow multiple patterns and assume that XSD will deal with it as above. Is there a compelling reason for #2? I would fall into the leave-things-as-they-are camp. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 03:37:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB62A3A67E7; Tue, 19 Aug 2008 03:37:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157AF3A6827 for ; Tue, 19 Aug 2008 03:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89RkZq3osdIb for ; Tue, 19 Aug 2008 03:37:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 974C63A67E7 for ; Tue, 19 Aug 2008 03:37:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACA26C0050; Tue, 19 Aug 2008 12:36:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cBGwcFtSJ2Dl; Tue, 19 Aug 2008 12:36:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8ECA3C005E; Tue, 19 Aug 2008 12:36:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B53FF695EEE; Tue, 19 Aug 2008 12:36:01 +0200 (CEST) Date: Tue, 19 Aug 2008 12:36:01 +0200 From: Juergen Schoenwaelder To: David Partain Message-ID: <20080819103601.GB16039@elstar.local> Mail-Followup-To: David Partain , netmod@ietf.org References: <20080801102824.GA4873@elstar.local> <4894AE39.5010001@netconfcentral.com> <20080818134228.GE13227@elstar.local> <200808191228.41549.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200808191228.41549.david.partain@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Aug 19, 2008 at 12:28:41PM +0200, David Partain wrote: > So, if I've got it right, we have two choices: > > 1. leave things like they are (only one pattern) > 2. allow multiple patterns and assume that XSD will deal with it as above. > > Is there a compelling reason for #2? The reason in favour of multiple ANDed pattern is expressive power. See Ladislav Lhotka's email: It does not make much sense to add multiple ORed pattern. > I would fall into the leave-things-as-they-are camp. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 05:01:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5DBE3A69E4; Tue, 19 Aug 2008 05:01:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3453A3A6960 for ; Tue, 19 Aug 2008 05:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88ltVmi6REfx for ; Tue, 19 Aug 2008 05:01:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1228A3A6A0D for ; Tue, 19 Aug 2008 05:01:27 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6569A20E5F; Tue, 19 Aug 2008 14:01:18 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-f5-48aab60e5312 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4AAF720E14; Tue, 19 Aug 2008 14:01:18 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 14:01:17 +0200 Received: from selic023.ki.sw.ericsson.se ([147.214.33.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 14:01:17 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 19 Aug 2008 14:01:19 +0200 User-Agent: KMail/1.9.9 References: <20080801102824.GA4873@elstar.local> <200808191228.41549.david.partain@ericsson.com> <20080819103601.GB16039@elstar.local> In-Reply-To: <20080819103601.GB16039@elstar.local> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808191401.19960.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Aug 2008 12:01:17.0345 (UTC) FILETIME=[4931C910:01C901F3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tuesday 19 August 2008 12.36.01 Juergen Schoenwaelder wrote: > On Tue, Aug 19, 2008 at 12:28:41PM +0200, David Partain wrote: > > So, if I've got it right, we have two choices: > > > > 1. leave things like they are (only one pattern) > > 2. allow multiple patterns and assume that XSD will deal with it as > > above. > > > > Is there a compelling reason for #2? > > The reason in favour of multiple ANDed pattern is expressive > power. See Ladislav Lhotka's email: > > Yep, that makes sense. >From this thread, it looks like we can maintain compatibility with XSD whether we do this or not. Given that, what's the cost of allowing multiple patterns? If the cost is negligible and the benefit non-negligible, we should do it. Comments? Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 05:44:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D996828C0FF; Tue, 19 Aug 2008 05:44:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3172928C10A for ; Tue, 19 Aug 2008 05:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDCpONDJzVaz for ; Tue, 19 Aug 2008 05:44:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5DCC528C0EE for ; Tue, 19 Aug 2008 05:44:32 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1BF0F76C423; Tue, 19 Aug 2008 14:44:13 +0200 (CEST) Date: Tue, 19 Aug 2008 14:44:09 +0200 (CEST) Message-Id: <20080819.144409.133181309.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808190108.m7J18p0t065686@idle.juniper.net> References: <48A9DBCD.70903@netconfcentral.com> <200808190108.m7J18p0t065686@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >Since YANG is going to use 'current()' from XPath 2.0, > >why not use default namespace as well? Or does this annoy > >the standards purists even more? Are we suppose force > >humans to enter exactly XPath 1.0 or exactly XPath 2.0, > >but not something in between? You cannot feed 'current()' > >to a 1.0 XPath parser. (You could feed it '$this' however.) > >Isn't 'current' also a problem, if no prefixes is a problem? > > current() is lifted from XSLT, not XPath 2.0. And note that XPath 1.0 allows new functions to be defined. It is not a deviation from the standard to add new functions. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 07:09:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876FC28C142; Tue, 19 Aug 2008 07:09:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB7828C142 for ; Tue, 19 Aug 2008 07:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkPk4wqtURMz for ; Tue, 19 Aug 2008 07:09:34 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id B1FE328C12C for ; Tue, 19 Aug 2008 07:09:34 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Tue, 19 Aug 2008 07:09:39 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 07:05:30 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 07:05:30 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 07:05:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7JE5Ku13524; Tue, 19 Aug 2008 07:05:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7JE1svY077146; Tue, 19 Aug 2008 14:01:54 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808191401.m7JE1svY077146@idle.juniper.net> To: David Partain In-reply-to: <200808191228.41549.david.partain@ericsson.com> Date: Tue, 19 Aug 2008 10:01:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Aug 2008 14:05:29.0935 (UTC) FILETIME=[A348C5F0:01C90204] Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain writes: >Is there a compelling reason for #2? My motivation was to allow multiple error information sets, so one could emit a message inline with the error. type foo { pattern "[^-]*-[^-]*" { error-message "must be a range in the form 'min'-'max'"; } pattern "[0-9]+-.*" { error-message "min must be decimal value"; } pattern ".*-[0-9]+" { error-message "max must be a decimal value"; } } hand-wave, hand-wave.... Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 07:24:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9B03A6818; Tue, 19 Aug 2008 07:24:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13833A6818 for ; Tue, 19 Aug 2008 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[AWL=1.157, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFiPf5xfTFJF for ; Tue, 19 Aug 2008 07:24:48 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 692F53A68BD for ; Tue, 19 Aug 2008 07:24:48 -0700 (PDT) Received: (qmail 52661 invoked from network); 19 Aug 2008 14:24:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2008 14:24:24 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AAD795.1020705@netconfcentral.com> Date: Tue, 19 Aug 2008 07:24:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808191401.m7JE1svY077146@idle.juniper.net> In-Reply-To: <200808191401.m7JE1svY077146@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > David Partain writes: >> Is there a compelling reason for #2? > > My motivation was to allow multiple error information sets, > so one could emit a message inline with the error. > > type foo { > pattern "[^-]*-[^-]*" { > error-message "must be a range in the form 'min'-'max'"; > } > pattern "[0-9]+-.*" { > error-message "min must be decimal value"; > } > pattern ".*-[0-9]+" { > error-message "max must be a decimal value"; > } > } > > hand-wave, hand-wave.... > How about fixing section E.4 first? (See my previous mail.) IMO, this is over-specification. We really do not need separate error-messages, error-app-tags, status, description, and reference clauses for arbitrary pattern fragments. (What does it mean to mix obsolete and deprecated fragments with current ones?) Assuming E.4 gets fixed, one 'pattern-violation' error-app-tag per leaf is plenty. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 07:41:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7273A6B46; Tue, 19 Aug 2008 07:41:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2676F3A6BA6 for ; Tue, 19 Aug 2008 07:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nthSmvkNMgni for ; Tue, 19 Aug 2008 07:41:30 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 469223A6B8F for ; Tue, 19 Aug 2008 07:41:30 -0700 (PDT) Received: (qmail 42565 invoked from network); 19 Aug 2008 14:41:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2008 14:41:35 -0000 X-YMail-OSG: f_n6rKAVM1me5QzKe7hM1o93BiDIpXRjQkl25Sy4klrjk.CYZRi9CUVYLk_LmNLWMmXwpukuckOkK6ddzCCu71RZ_2nwsVQwc1sYWuInYg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AADB9C.7030209@netconfcentral.com> Date: Tue, 19 Aug 2008 07:41:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808191401.m7JE1svY077146@idle.juniper.net> <48AAD795.1020705@netconfcentral.com> In-Reply-To: <48AAD795.1020705@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: >> David Partain writes: >>> Is there a compelling reason for #2? >> >> My motivation was to allow multiple error information sets, >> so one could emit a message inline with the error. >> >> type foo { >> pattern "[^-]*-[^-]*" { >> error-message "must be a range in the form 'min'-'max'"; >> } >> pattern "[0-9]+-.*" { >> error-message "min must be decimal value"; >> } >> pattern ".*-[0-9]+" { >> error-message "max must be a decimal value"; >> } >> } >> >> hand-wave, hand-wave.... >> > > How about fixing section E.4 first? (See my previous mail.) > > IMO, this is over-specification. > We really do not need separate error-messages, > error-app-tags, status, description, and reference clauses > for arbitrary pattern fragments. (What does it mean to > mix obsolete and deprecated fragments with current ones?) > oops -- just 4 clauses (no status). I don't really care about this change too much. It seems redundant, which I heard was bad. I also think this sort of AND expression is not going to be needed very often. It seems like "accept this OR that" is more likely. Multiple patterns ORed together works with XSD but not RelaxNG, so we can't use it. But at least this is adding new functionality, not redundancy. > Assuming E.4 gets fixed, one 'pattern-violation' error-app-tag > per leaf is plenty. > > >> Thanks, >> Phil > > Andy > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 09:21:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82F03A68A1; Tue, 19 Aug 2008 09:21:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7BB3A6954 for ; Tue, 19 Aug 2008 09:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd59UTGv3ltv for ; Tue, 19 Aug 2008 09:20:00 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 7DD633A6896 for ; Tue, 19 Aug 2008 09:20:00 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 4AXr1a0060x6nqcA4GKK0l; Tue, 19 Aug 2008 16:19:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id 4GKC1a00V4HwxpC8YGKDQy; Tue, 19 Aug 2008 16:19:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=IHYLhx_UwH4z5YNS2EkA:9 a=59O9O_N1PRDHT3TNr2sA:7 a=k3zenAVmCIbPq5ODFhxEcnduULUA:4 a=86L1PGDMzkIA:10 a=f7GxY0FH8QIA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Wes Hardaker'" , "'David Partain'" References: <200808191431.43731.david.partain@ericsson.com> Date: Tue, 19 Aug 2008 12:19:12 -0400 Message-ID: <08c501c90217$530464b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AckB/rBs9oX8746PS2+8Z1xV/nRwxwACZm8Q X-Mailman-Approved-At: Tue, 19 Aug 2008 09:21:25 -0700 Cc: netmod@ietf.org, 'Gerhard Muenz' Subject: Re: [netmod] NETMOD Interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I do not believe we ever said there would be no effort to support remote participants. We said that doing the whole interim as a teleconference did not seem feasible. The chairs will strongly consider providing for remote participation, but much of that will depend on sponsors, contributors, available resources, and available skills for operating such remote participation technologies. If somebody works for a company that would like to help improve support or remote particiaption by providing the needed infrastructure (such as a teleconference bridge or icecast audio recording equipment), the needed operations personnel (e.g., a remote jabber scribe listening over a teleconference and taking minutes), and so on, please contact the chairs. But the WG should also recognize that the chairs' responsibility is to organize the interim meeting to resolve open issues, not to arrange a fully-functional remote participation environment "where no interim has gone before". If anybody would like to take on the responsibility of organizing and coordinating the remote participation capabilities, the chairs would welcome such help. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Tuesday, August 19, 2008 9:23 AM > To: David Partain > Cc: Gerhard Muenz; Leif Johansson; Randy Presuhn; tom.petch; > Wes Hardaker; David B Harrington > Subject: Re: NETMOD Interim meeting > > >>>>> On Tue, 19 Aug 2008 14:31:43 +0200, David Partain > said: > > DP> Since you are a contributor on the NETMOD list (at least > once! :-)), > DP> I'm curious if there's a chance you might be attending the NETMOD > DP> interim meeting in October. Your contribution would be welcome! > > I'd absolutely love to attend, but I don't have any source of travel > funding to get me there at this point so no... I doubt I'll be > attending unless something magically turns up. Last I read > on the list > there wasn't going to be an attempt to get remote > participation services > working at all; I assume this is still the case? > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 09:47:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA9A3A6A8F; Tue, 19 Aug 2008 09:47:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B9A3A6D1B for ; Tue, 19 Aug 2008 09:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.39 X-Spam-Level: X-Spam-Status: No, score=-5.39 tagged_above=-999 required=5 tests=[AWL=1.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eve8r6NNEPQd for ; Tue, 19 Aug 2008 09:47:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id AFD7E3A6CF8 for ; Tue, 19 Aug 2008 09:46:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7JGjvaW027188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 18:45:57 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7JGjvN5013859; Tue, 19 Aug 2008 18:45:57 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 18:45:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 18:45:56 +0200 Message-ID: In-Reply-To: <08c501c90217$530464b0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] NETMOD Interim meeting Thread-Index: AckB/rBs9oX8746PS2+8Z1xV/nRwxwACZm8QAAQ+poA= References: <200808191431.43731.david.partain@ericsson.com> <08c501c90217$530464b0$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David B Harrington" , "Wes Hardaker" , "David Partain" X-OriginalArrivalTime: 19 Aug 2008 16:45:57.0743 (UTC) FILETIME=[0DE7AFF0:01C9021B] Cc: netmod@ietf.org, Gerhard Muenz Subject: Re: [netmod] NETMOD Interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I can organize a phone conference bridge with local access numbers, which is useful. IMO jabber scribe should be actually sitting in the meeting room to be able to help remote attendees. Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext David B Harrington > Sent: Tuesday, August 19, 2008 6:19 PM > To: 'Wes Hardaker'; 'David Partain' > Cc: netmod@ietf.org; 'Gerhard Muenz' > Subject: Re: [netmod] NETMOD Interim meeting > > Hi, > > I do not believe we ever said there would be no effort to support > remote participants. > We said that doing the whole interim as a teleconference did not seem > feasible. > > The chairs will strongly consider providing for remote participation, > but much of that will depend on sponsors, contributors, available > resources, and available skills for operating such remote > participation technologies. > > If somebody works for a company that would like to help improve > support or remote particiaption by providing the needed infrastructure > (such as a teleconference bridge or icecast audio recording > equipment), the needed operations personnel (e.g., a remote jabber > scribe listening over a teleconference and taking minutes), and so on, > please contact the chairs. > > But the WG should also recognize that the chairs' responsibility is to > organize the interim meeting to resolve open issues, not to arrange a > fully-functional remote participation environment "where no interim > has gone before". If anybody would like to take on the responsibility > of organizing and coordinating the remote participation capabilities, > the chairs would welcome such help. > > dbh > > > -----Original Message----- > > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > > Sent: Tuesday, August 19, 2008 9:23 AM > > To: David Partain > > Cc: Gerhard Muenz; Leif Johansson; Randy Presuhn; tom.petch; > > Wes Hardaker; David B Harrington > > Subject: Re: NETMOD Interim meeting > > > > >>>>> On Tue, 19 Aug 2008 14:31:43 +0200, David Partain > > said: > > > > DP> Since you are a contributor on the NETMOD list (at least > > once! :-)), > > DP> I'm curious if there's a chance you might be attending the > NETMOD > > DP> interim meeting in October. Your contribution would be welcome! > > > > I'd absolutely love to attend, but I don't have any source of travel > > funding to get me there at this point so no... I doubt I'll be > > attending unless something magically turns up. Last I read > > on the list > > there wasn't going to be an attempt to get remote > > participation services > > working at all; I assume this is still the case? > > -- > > Wes Hardaker > > Sparta, Inc. > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 10:11:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F603A68B1; Tue, 19 Aug 2008 10:11:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94BB3A68B1 for ; Tue, 19 Aug 2008 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWacPY4YR5Wx for ; Tue, 19 Aug 2008 10:11:31 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 935BD3A6909 for ; Tue, 19 Aug 2008 10:11:31 -0700 (PDT) X-Trace: 159534370/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.65 X-SBRS: None X-RemoteIP: 213.116.60.65 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAK6bqkjVdDxB/2dsb2JhbACDQziHcqlSA4FV X-IronPort-AV: E=Sophos;i="4.32,236,1217804400"; d="scan'208";a="159534370" X-IP-Direction: IN Received: from 1cust65.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.65]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Aug 2008 18:10:38 +0100 Message-ID: <009a01c90215$34b95620$0601a8c0@allison> From: "tom.petch" To: "David Partain" References: <200808121435.15930.david.partain@ericsson.com> <48A1BFD4.6000903@netconfcentral.com> Date: Tue, 19 Aug 2008 18:02:32 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I do have reservations about this. Were I to attend - unlikely - my expectations would be low. I think that the process might be interesting but that progress might be slight. This is the most active IETF list I can recall and yet .. sometimes it seems to be more a tutorial in the finer points of interactions of nuances within the I-D. Issues do arise that raise a vigorous debate but then they seem rarely to reach a consensus. There are also e-mails raising good points to which there is no response on the list. And then there are those 'Remind me, what did we conclude about ...' to which my personal answer would be 'We did not reach a conclusion that I could discern.' :-( E-mail is the most impoverished form of communication, face-to-face is much richer, but I wonder why this pattern would not recur at the interim. And, as has happened once already, there may be a tendency in the meantime to say "Let's resolve this at the interim" which is apt to delay progress. Tom Petch ----- Orginal Message ----- From: "Andy Bierman" Cc: Sent: Tuesday, August 12, 2008 6:52 PM Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 > David Partain wrote: > > Hi, > > > > At the recent IETF, there seemed to be strong consensus for having an interim > > meeting SINCE we have an aggressive timeline we ARE going to meet. We have a > > tentative host near Washington, D.C, but please don't book your tickets > > yet... I'll send out mail when everything is confirmed. > > > > Just to confirm that consensus on the mailing list, let me ask a few > > questions: > > > > Who supports having an interim on 8 - 10 October? > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 10:19:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3AD3A682A; Tue, 19 Aug 2008 10:19:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92D63A6C41 for ; Tue, 19 Aug 2008 10:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSvJnGNgQrmH for ; Tue, 19 Aug 2008 10:19:45 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0D5403A682A for ; Tue, 19 Aug 2008 10:19:45 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id F1337D800C5 for ; Tue, 19 Aug 2008 19:18:26 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200808191401.19960.david.partain@ericsson.com> References: <20080801102824.GA4873@elstar.local> <200808191228.41549.david.partain@ericsson.com> <20080819103601.GB16039@elstar.local> <200808191401.19960.david.partain@ericsson.com> Organization: CESNET Date: Tue, 19 Aug 2008 19:18:26 +0200 Message-Id: <1219166306.6338.80.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org RGF2aWQgUGFydGFpbiBww63FoWUgdiDDmnQgMTkuIDA4LiAyMDA4IHYgMTQ6MDEgKzAyMDA6Cgo+ IEZyb20gdGhpcyB0aHJlYWQsIGl0IGxvb2tzIGxpa2Ugd2UgY2FuIG1haW50YWluIGNvbXBhdGli aWxpdHkgd2l0aCBYU0Qgd2hldGhlciAKPiB3ZSBkbyB0aGlzIG9yIG5vdC4gIEdpdmVuIHRoYXQs IHdoYXQncyB0aGUgY29zdCBvZiBhbGxvd2luZyBtdWx0aXBsZSAKClRyYW5zbGF0aW9uIHRvIFJF TEFYIE5HIHdpbGwgbm93IGJlIHN0cmFpZ2h0Zm9yd2FyZCwgdHJhbnNsYXRpb24gdG8gWFNECndp bGwgbmVlZCB0byB1c2UgdGhlIGV4dHJhIGFub255bW91cyB0eXBlIGFzIHRyYW5nIGRvZXMuCgo+ IHBhdHRlcm5zPyAgSWYgdGhlIGNvc3QgaXMgbmVnbGlnaWJsZSBhbmQgdGhlIGJlbmVmaXQgbm9u LW5lZ2xpZ2libGUsIHdlIAo+IHNob3VsZCBkbyBpdC4KCkRvaW5nIHRoZSBBTkQgdmlhIG11bHRp cGxlIHR5cGVkZWZzIGluIFlBTkcgd291bGQgYmUgcXVpdGUgY2x1bXN5IGFuZApub24tb2J2aW91 cywgc28gSSdkIHNheSB0aGUgYmVuZWZpdCBpcyBub24tbmVnbGlnaWJsZS4KCkxhZGEKCi0tIApM YWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApu ZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QK From netmod-bounces@ietf.org Tue Aug 19 10:42:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3799C3A682A; Tue, 19 Aug 2008 10:42:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CA528C1D3 for ; Tue, 19 Aug 2008 10:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqotBTR08K7S for ; Tue, 19 Aug 2008 10:42:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EB19A3A682A for ; Tue, 19 Aug 2008 10:42:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18B02C0063; Tue, 19 Aug 2008 19:38:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1jM2rzMKnjrY; Tue, 19 Aug 2008 19:38:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F2AFC0067; Tue, 19 Aug 2008 19:38:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E37C696B03; Tue, 19 Aug 2008 19:38:19 +0200 (CEST) Date: Tue, 19 Aug 2008 19:38:19 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20080819173819.GB16866@elstar.local> Mail-Followup-To: "tom.petch" , David Partain , netmod@ietf.org References: <200808121435.15930.david.partain@ericsson.com> <48A1BFD4.6000903@netconfcentral.com> <009a01c90215$34b95620$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <009a01c90215$34b95620$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Aug 19, 2008 at 06:02:32PM +0200, tom.petch wrote: > I do have reservations about this. Were I to attend - unlikely - my > expectations would be low. I think that the process might be > interesting but that progress might be slight. I have been at two pre IETF YANG meetings and they were both extremely productive. The biggest advantage is a whiteboard where people can write down examples etc. and the fact that most people can concentrate on just on thing for 2+ days. > This is the most active IETF list I can recall and yet .. sometimes > it seems to be more a tutorial in the finer points of interactions > of nuances within the I-D. Issues do arise that raise a vigorous > debate but then they seem rarely to reach a consensus. There are > also e-mails raising good points to which there is no response on > the list. And then there are those 'Remind me, what did we conclude > about ...' to which my personal answer would be 'We did not reach a > conclusion that I could discern.' :-( See, this is how IETF mailing lists are. People read and react next to their daytime activities and so context is constantly lost. But on some issues, I do actually see progress. > E-mail is the most impoverished form of communication, face-to-face > is much richer, but I wonder why this pattern would not recur at the > interim. See above. > And, as has happened once already, there may be a tendency in the > meantime to say "Let's resolve this at the interim" which is apt to > delay progress. If you see this happening and you believe things can be resolved right now, please speak up and make it happen. The productivity of the WG mailing list is a function of the WG members. It is up to all of us to be disciplined and to move forward in a productive way. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 11:10:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10303A68C3; Tue, 19 Aug 2008 11:10:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109193A68C3 for ; Tue, 19 Aug 2008 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.349 X-Spam-Level: * X-Spam-Status: No, score=1.349 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_20=-0.74, J_CHICKENPOX_35=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CH8Cgcn7kK1 for ; Tue, 19 Aug 2008 11:10:33 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 72DEF3A691B for ; Tue, 19 Aug 2008 11:10:33 -0700 (PDT) Received: (qmail 93802 invoked from network); 19 Aug 2008 18:09:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2008 18:09:07 -0000 X-YMail-OSG: pz1I5MAVM1m_uY2X.IDG3fO5yWum9a_SiLYpWSFC._1GBBhqc7assU7ujj6ZGaX_RmNTlv6H2t.Bl338L4wODroDk.OJzx7BUD4GKWSD4Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AB0C40.50500@netconfcentral.com> Date: Tue, 19 Aug 2008 11:09:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "tom.petch" , David Partain , netmod@ietf.org References: <200808121435.15930.david.partain@ericsson.com> <48A1BFD4.6000903@netconfcentral.com> <009a01c90215$34b95620$0601a8c0@allison> <20080819173819.GB16866@elstar.local> In-Reply-To: <20080819173819.GB16866@elstar.local> Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Aug 19, 2008 at 06:02:32PM +0200, tom.petch wrote: > >> I do have reservations about this. Were I to attend - unlikely - my >> expectations would be low. I think that the process might be >> interesting but that progress might be slight. > > I have been at two pre IETF YANG meetings and they were both extremely > productive. The biggest advantage is a whiteboard where people can > write down examples etc. and the fact that most people can concentrate > on just on thing for 2+ days. > As Joel pointed out, it would be nice to capture the design motivations for various details, instead of just the details. >> This is the most active IETF list I can recall and yet .. sometimes >> it seems to be more a tutorial in the finer points of interactions >> of nuances within the I-D. Issues do arise that raise a vigorous >> debate but then they seem rarely to reach a consensus. There are >> also e-mails raising good points to which there is no response on >> the list. And then there are those 'Remind me, what did we conclude >> about ...' to which my personal answer would be 'We did not reach a >> conclusion that I could discern.' :-( > > See, this is how IETF mailing lists are. People read and react next to > their daytime activities and so context is constantly lost. But on > some issues, I do actually see progress. > If your day job is implementing YANG, then the WG progress seems quite slow, and the mailing list doesn't seem that active at all. When the co-Chairs get the issue tracker going, the issue resolution thing will go much faster. Some of us (like me) don't always keep the email subject aligned with the actual thread, which makes it harder to follow along and jump in. If we sent less mail with better subject lines, maybe that would help. >> E-mail is the most impoverished form of communication, face-to-face >> is much richer, but I wonder why this pattern would not recur at the >> interim. > > See above. I agree with Juergen. At a WG interim, the IETF is your day job. I have seen people travel to an interim just to work on their laptop and ignore the meeting, but (unlike an IETF) that is rare, not the status quo. Also, the co-Chairs can force issue resolution. Notice how the agenda says 8:30am to whenever? Old WG Chair trick: don't adjourn for dinner until the deadlock is broken. No food, no beer, until the issue is solved. (This works amazingly well on most of us :-) > >> And, as has happened once already, there may be a tendency in the >> meantime to say "Let's resolve this at the interim" which is apt to >> delay progress. > That's OK for some big complex issues. > If you see this happening and you believe things can be resolved right > now, please speak up and make it happen. The productivity of the WG > mailing list is a function of the WG members. It is up to all of us to > be disciplined and to move forward in a productive way. > Agreed. We used to call out "rathole" or "tar-baby" more often. Perhaps Martin can summarize the list of edits for -01 that have "no objections", and we see how many open issues there really are. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 11:14:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462AF3A6B49; Tue, 19 Aug 2008 11:14:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96D628C16C for ; Tue, 19 Aug 2008 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.762 X-Spam-Level: X-Spam-Status: No, score=-0.762 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85yn+ubbTASJ for ; Tue, 19 Aug 2008 11:14:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D64FD3A691B for ; Tue, 19 Aug 2008 11:14:08 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0D609D800CB; Tue, 19 Aug 2008 20:13:17 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48A9DBCD.70903@netconfcentral.com> References: <200808111249.m7BCnbQ1097029@idle.juniper.net> <1219073082.6236.3.camel@missotis> <48A997FF.7060509@netconfcentral.com> <1219090016.6236.56.camel@missotis> <48A9DBCD.70903@netconfcentral.com> Organization: CESNET Date: Tue, 19 Aug 2008 20:13:16 +0200 Message-Id: <1219169596.6338.125.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDE4LiAwOC4gMjAwOCB2IDEzOjMwIC0wNzAwOgoKPiBJ IGFtIG5vdCBjb252aW5jZWQuCj4gSXQgaXMgbm90IGhhcmQgdG8ga25vdyB3aGljaCBpcyB0aGUg Y3VycmVudCBtb2R1bGUKPiBpbiB5b3VyIGltcGxlbWVudGF0aW9uLiAgSXQgaXMgdGhlcmVmb3Jl IG5vdCBoYXJkCj4gdG8gaW5zZXJ0IHRoZSBtb2R1bGUgcHJlZml4IHdoZW4gaXQgaXMgbWlzc2lu Zy4KCldlbGwsIGlmIFhQYXRoIGlzIHVzZWQgaW4gYSBncm91cGluZywgd2hpY2ggaXMgdGhlIHJp Z2h0CnByZWZpeC9uYW1lc3BhY2U/CiAKPiAKPiBJIHRoaW5rIHRoZSBZQU5HIHRvIERTREwgdHJh bnNsYXRpb24gbXVzdCBhY2NvdW50Cj4gZm9yIGFsbCBzb3J0cyBvZiBwcmVmaXggdHJhbnNsYXRp b25zLCB0aGlzIGJlaW5nIG9uZSBvZiB0aGVtLgo+IFlvdSBhcmUgZ29pbmcgdG8gZmVlZCB0aGUg RFNETCBmaWxlIGRpcmVjdGx5IHRvIFhQYXRoLAo+IG5vdCB0aGUgWUFORyBmaWxlLgoKSSBhZ3Jl ZSB0aGF0IGl0IGNhbiBiZSBoYWNrZWQgc29tZWhvdyBidXQgbXkgcG9pbnQgaXMgdGhhdCBpZiBZ QU5HCmRlY2xhcmVzIHRoYXQgaXQgdXNlcyBYUGF0aCAxLjAgKG9yIDIuMCBvciB3aGF0ZXZlcikg aXQgc2hvdWxkIGJ5IGFsbAptZWFucyBkbyBpdCBpbiBhIGNvbXBsaWFudCB3YXkuIERvaW5nIGFy Yml0cmFyeSBZQU5HLXNwZWNpZmljIGNoYW5nZXMgdG8KdGhlIHN0YW5kYXJkcyBjYW4gY29uZnVz ZSBib3RoIGh1bWFucyBhbmQgdG9vbHMuCgo+IFNpbmNlIFlBTkcgaXMgZ29pbmcgdG8gdXNlICdj dXJyZW50KCknIGZyb20gWFBhdGggMi4wLAoKTm8sIGFzIFBoaWwgcG9pbnRlZCBvdXQsIGN1cnJl Y3QoKSBjb21lcyBmcm9tIFhTTFQgYW5kIGlzIGFsc28gdXNlZCBpbgp0aGUgc2FtZSB3YXkgaW4g U2NoZW1hdHJvbi4gQW55Ym9keSB3aG8gaXMgcmVhc29uYWJseSBYTUwtbGl0ZXJhdGUgd2lsbAp1 bmRlcnN0YW5kIHRoaXMgZnVuY3Rpb24gd2l0aG91dCBhbnkgbmVlZCB0byBsb29rIGluIFlBTkcg c3BlYy4KIAo+IHdoeSBub3QgdXNlIGRlZmF1bHQgbmFtZXNwYWNlIGFzIHdlbGw/ICBPciBkb2Vz IHRoaXMgYW5ub3kKPiB0aGUgc3RhbmRhcmRzIHB1cmlzdHMgZXZlbiBtb3JlPyAgQXJlIHdlIHN1 cHBvc2UgZm9yY2UKCkkgYW0gbm90IGEgc3RhbmRhcmQgcHVyaXN0LCBJIGp1c3QgdGhpbmsgVzND IHN0YW5kYXJkcyBhbmQgYXBwcm9hY2hlcwpkZXNlcnZlIHRoZSBzYW1lIHJlc3BlY3QgYXMgdGhl IElFVEYgb25lcywgb3RoZXJ3aXNlIHRoZSB3aG9sZSB0aGluZyBvZgp1c2luZyBYTUwgaW4gTkVU Q09ORiBtYWtlcyBsaXR0bGUgc2Vuc2UuCgo+IGh1bWFucyB0byBlbnRlciBleGFjdGx5IFhQYXRo IDEuMCBvciBleGFjdGx5IFhQYXRoIDIuMCwKPiBidXQgbm90IHNvbWV0aGluZyBpbiBiZXR3ZWVu PyAgWW91IGNhbm5vdCBmZWVkICdjdXJyZW50KCknCj4gdG8gYSAxLjAgWFBhdGggcGFyc2VyLiAo WW91IGNvdWxkIGZlZWQgaXQgJyR0aGlzJyBob3dldmVyLikKPiBJc24ndCAnY3VycmVudCcgYWxz byBhIHByb2JsZW0sIGlmIG5vIHByZWZpeGVzIGlzIGEgcHJvYmxlbT8KCk15IHByZWZlcmVuY2Ug aXMgdG8gc3RheSB3aXRoIFhQYXRoIDEuMCArIGN1cnJlbnQoKSBmdW5jdGlvbi4KCj4gCj4gV2Ug Y2FyZSBhYm91dCBjb25mb3JtYW5jZSB0byBZQU5HIDEuMCwgYW5kIG5vdCBzbyBtdWNoCj4gYWJv dXQgY29tcGxldGUgaW1wbGVtZW50YXRpb24gb2YgWFBhdGggMi4wLiAgQ2FuIHdlIGNhbiByZXF1 aXJlCj4gY29tcGxldGUgaW1wbGVtZW50YXRpb24gb2YgWFBhdGggMS4wLCBwbHVzICdleHRyYXMn PwoKSSB1bmRlcnN0YW5kIFlBTkcgYWxyZWFkeSBlc3NlbnRpYWxseSByZXF1aXJlcyBpdCAod2l0 aCAnJHRoaXMnIGluc3RlYWQKb2YgJ2N1cnJlbnQoKScpLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExo b3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Aug 19 11:47:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3583A6841; Tue, 19 Aug 2008 11:47:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062703A69B7 for ; Tue, 19 Aug 2008 11:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiRv5N1izcOI for ; Tue, 19 Aug 2008 11:47:17 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 60D1A3A66B4 for ; Tue, 19 Aug 2008 11:47:11 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Tue, 19 Aug 2008 11:45:09 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 11:41:07 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 11:41:06 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 11:41:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7JIf5u55918; Tue, 19 Aug 2008 11:41:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7JIbd6X080874; Tue, 19 Aug 2008 18:37:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808191837.m7JIbd6X080874@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1219169596.6338.125.camel@missotis> Date: Tue, 19 Aug 2008 14:37:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Aug 2008 18:41:06.0340 (UTC) FILETIME=[23BFEE40:01C9022B] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >I agree that it can be hacked somehow but my point is that if YANG >declares that it uses XPath 1.0 (or 2.0 or whatever) it should by all >means do it in a compliant way. Doing arbitrary YANG-specific changes to >the standards can confuse both humans and tools. I firmly believe that we have this. We are using XPath in a manner that is consistent with the XPath. We define the context in which XPath expressions are evaluated. XSLT does the exact same thing, in section 4 of the XSLT spec: http://www.w3.org/TR/xslt#section-Expressions In XSLT, an outermost expression (i.e. an expression that is not part of another expression) gets its context as follows: * the context node comes from the current node * the context position comes from the position of the current node in the current node list; the first position is 1 * the context size comes from the size of the current node list * the variable bindings are the bindings in scope on the element which has the attribute in which the expression occurs (see [11 Variables and Parameters]) * the set of namespace declarations are those in scope on the element which has the attribute in which the expression occurs; this includes the implicit declaration of the prefix xml required by the the XML Namespaces Recommendation [XML Names]; the default namespace (as declared by xmlns) is not part of this set * the function library consists of the core function library together with the additional functions defined in [12 Additional Functions] and extension functions as described in [14 Extensions]; it is an error for an expression to include a call to any other function The YANG draft will similarly dictate the context in which our XPath expressions are evaluated. (Note the except for the default namespace, which explains why this doesn't work the way I thought it did.) Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 12:03:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E023E3A685E; Tue, 19 Aug 2008 12:03:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05693A685E for ; Tue, 19 Aug 2008 12:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyfC-yuxkwLZ for ; Tue, 19 Aug 2008 12:03:33 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id CEA543A68A0 for ; Tue, 19 Aug 2008 12:03:32 -0700 (PDT) Received: (qmail 46772 invoked from network); 19 Aug 2008 18:50:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2008 18:50:55 -0000 X-YMail-OSG: PajOr.QVM1nZuJ6d2YujXQJJyZZuzcKFA4hxwydazTFE7qkQjaubtco6AJrluJPDkReeQ6ikQ0XPZpPZYGEFpg9.thI430Is11XOR3RLsA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AB160D.2050609@netconfcentral.com> Date: Tue, 19 Aug 2008 11:50:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200808111249.m7BCnbQ1097029@idle.juniper.net> <1219073082.6236.3.camel@missotis> <48A997FF.7060509@netconfcentral.com> <1219090016.6236.56.camel@missotis> <48A9DBCD.70903@netconfcentral.com> <1219169596.6338.125.camel@missotis> In-Reply-To: <1219169596.6338.125.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAxOC4gMDgu IDIwMDggdiAxMzozMCAtMDcwMDoKPiAKPj4gSSBhbSBub3QgY29udmluY2VkLgo+PiBJdCBpcyBu b3QgaGFyZCB0byBrbm93IHdoaWNoIGlzIHRoZSBjdXJyZW50IG1vZHVsZQo+PiBpbiB5b3VyIGlt cGxlbWVudGF0aW9uLiAgSXQgaXMgdGhlcmVmb3JlIG5vdCBoYXJkCj4+IHRvIGluc2VydCB0aGUg bW9kdWxlIHByZWZpeCB3aGVuIGl0IGlzIG1pc3NpbmcuCj4gCj4gV2VsbCwgaWYgWFBhdGggaXMg dXNlZCBpbiBhIGdyb3VwaW5nLCB3aGljaCBpcyB0aGUgcmlnaHQKPiBwcmVmaXgvbmFtZXNwYWNl PwoKKFRoaXMgaXNzdWUgaXMgdW5yZWxhdGVkIHRvIGJlbG9uZ3MtdG8gYW5kIHRoZSBsb2NhbCBw cmVmaXguKQoKWW91IGNhbm5vdCByZXNvbHZlIG11c3Qvd2hlbiBleHByZXNzaW9ucyB3aXRoaW4g YSBncm91cGluZy4KVGhlIERNIHdyaXRlciBtdXN0IGJlIGF3YXJlIHRoYXQgdGhlIGV4cHJlc3Np b24gbmVlZHMgdG8KYmUgdmFsaWQgYW55d2hlcmUgYSB1c2VzLXN0bXQgaXMgdmFsaWQsIGFuZCB0 aGUgWFBhdGggaXMgZXZhbHVhdGVkCmluIHRoZSBjb250ZXh0IG9mIHRoZSAndXNlcycgbW9kdWxl LiAgQWxsIHRoZSBkYXRhIHR5cGluZwphbmQgc3ludGF4IGZvciBhIGdyb3VwaW5nIGlzIGV2YWx1 YXRlZCBpbiB0aGUgbW9kdWxlCndpdGggdGhlIGdyb3VwaW5nLCB3aGljaCBpcyBjb25mdXNpbmcu CgpOb3Qgb25seSBkbyB5b3UgbmVlZCB0byB0cmFuc2xhdGUgbWlzc2luZyBwcmVmaXhlcyBpbiBt dXN0L3doZW4KdG8gdGhlIHByZWZpeCBmb3IgdGhlIGN1cnJlbnQgbW9kdWxlLCB5b3UgbmVlZCB0 byBhY2NvdW50CmZvciBkaWZmZXJlbnQgcHJlZml4ZXMgaW4gdGhlICdncm91cGluZycgYW5kICd1 c2VzJyBtb2R1bGVzLgoKKHNvcnJ5IGZvciB0aGUgYm9ndXMgZXhhbXBsZSkKCm1vZHVsZSBBIHsK CiAgIHByZWZpeCBBOwoKICAgaW1wb3J0IElGLU1JQiB7IHByZWZpeCBpZjsgfQoKICAgZ3JvdXBp bmcgQSB7CiAgICAgbGVhZiBmb28gewogICAgICAgIHR5cGUgc3RyaW5nOwogICAgICAgIG11c3Qg Ii9pZjppZk51bWJlcj09MiI7CiAgICAgfQogICAgIGxlYWYgYmFyIHsKICAgICAgICB0eXBlIHN0 cmluZzsKICAgICAgICBtdXN0ICIuLi9BOmZvbyAhPSAnZnJlZCciOwogICAgIH0KICAgICBsZWFm IGJheiB7CiAgICAgICAgdHlwZSBzdHJpbmc7CiAgICAgICAgbXVzdCAiLi4vYmFyID09ICdiYXJu ZXknIjsKICAgfQp9Cgptb2R1bGUgQiB7CgogICBwcmVmaXggQjsKCiAgIGltcG9ydCBBIHsgcHJl Zml4IGE7IH0KICAgaW1wb3J0IElGLU1JQiB7IHByZWZpeCBpdGY7IH0KCiAgIGNvbnRhaW5lciBC IHsKICAgICB1c2VzIGE6QTsKICAgfQp9CgoKU2VlIHdoYXQgSSBtZWFuPwooU2VlIGhvdyBlYXN5 IFlBTkcgaXMgdG8gcmVzb2x2ZSBpbiB5b3VyIGhlYWQ/IDotKQpUaGUgbXVzdCBleHByZXNzaW9u cyBuZWVkIHRvIGJlIGhhbmRsZWQgaW50ZXJuYWxseSBzb21laG93LApzbyB0aGF0IHRoZSBjb3Jy ZWN0IG1vZHVsZSBpcyByZWZlcmVuY2VkLCBubyBtYXR0ZXIgd2hhdC4KCiAgcHJlZml4IG1hcHBp bmcKICAtLS0tLS0tLS0tLS0tLQogIG5vbmU6ICBBIC0tPiBCCiAgICAgQTogIGEKICAgIGlmOiAg aXRmCgoKCj4gIAo+PiBJIHRoaW5rIHRoZSBZQU5HIHRvIERTREwgdHJhbnNsYXRpb24gbXVzdCBh Y2NvdW50Cj4+IGZvciBhbGwgc29ydHMgb2YgcHJlZml4IHRyYW5zbGF0aW9ucywgdGhpcyBiZWlu ZyBvbmUgb2YgdGhlbS4KPj4gWW91IGFyZSBnb2luZyB0byBmZWVkIHRoZSBEU0RMIGZpbGUgZGly ZWN0bHkgdG8gWFBhdGgsCj4+IG5vdCB0aGUgWUFORyBmaWxlLgo+IAo+IEkgYWdyZWUgdGhhdCBp dCBjYW4gYmUgaGFja2VkIHNvbWVob3cgYnV0IG15IHBvaW50IGlzIHRoYXQgaWYgWUFORwo+IGRl Y2xhcmVzIHRoYXQgaXQgdXNlcyBYUGF0aCAxLjAgKG9yIDIuMCBvciB3aGF0ZXZlcikgaXQgc2hv dWxkIGJ5IGFsbAo+IG1lYW5zIGRvIGl0IGluIGEgY29tcGxpYW50IHdheS4gRG9pbmcgYXJiaXRy YXJ5IFlBTkctc3BlY2lmaWMgY2hhbmdlcyB0bwo+IHRoZSBzdGFuZGFyZHMgY2FuIGNvbmZ1c2Ug Ym90aCBodW1hbnMgYW5kIHRvb2xzLgo+IAo+PiBTaW5jZSBZQU5HIGlzIGdvaW5nIHRvIHVzZSAn Y3VycmVudCgpJyBmcm9tIFhQYXRoIDIuMCwKPiAKPiBObywgYXMgUGhpbCBwb2ludGVkIG91dCwg Y3VycmVjdCgpIGNvbWVzIGZyb20gWFNMVCBhbmQgaXMgYWxzbyB1c2VkIGluCj4gdGhlIHNhbWUg d2F5IGluIFNjaGVtYXRyb24uIEFueWJvZHkgd2hvIGlzIHJlYXNvbmFibHkgWE1MLWxpdGVyYXRl IHdpbGwKPiB1bmRlcnN0YW5kIHRoaXMgZnVuY3Rpb24gd2l0aG91dCBhbnkgbmVlZCB0byBsb29r IGluIFlBTkcgc3BlYy4KPiAgCj4+IHdoeSBub3QgdXNlIGRlZmF1bHQgbmFtZXNwYWNlIGFzIHdl bGw/ICBPciBkb2VzIHRoaXMgYW5ub3kKPj4gdGhlIHN0YW5kYXJkcyBwdXJpc3RzIGV2ZW4gbW9y ZT8gIEFyZSB3ZSBzdXBwb3NlIGZvcmNlCj4gCj4gSSBhbSBub3QgYSBzdGFuZGFyZCBwdXJpc3Qs IEkganVzdCB0aGluayBXM0Mgc3RhbmRhcmRzIGFuZCBhcHByb2FjaGVzCj4gZGVzZXJ2ZSB0aGUg c2FtZSByZXNwZWN0IGFzIHRoZSBJRVRGIG9uZXMsIG90aGVyd2lzZSB0aGUgd2hvbGUgdGhpbmcg b2YKPiB1c2luZyBYTUwgaW4gTkVUQ09ORiBtYWtlcyBsaXR0bGUgc2Vuc2UuCj4gCj4+IGh1bWFu cyB0byBlbnRlciBleGFjdGx5IFhQYXRoIDEuMCBvciBleGFjdGx5IFhQYXRoIDIuMCwKPj4gYnV0 IG5vdCBzb21ldGhpbmcgaW4gYmV0d2Vlbj8gIFlvdSBjYW5ub3QgZmVlZCAnY3VycmVudCgpJwo+ PiB0byBhIDEuMCBYUGF0aCBwYXJzZXIuIChZb3UgY291bGQgZmVlZCBpdCAnJHRoaXMnIGhvd2V2 ZXIuKQo+PiBJc24ndCAnY3VycmVudCcgYWxzbyBhIHByb2JsZW0sIGlmIG5vIHByZWZpeGVzIGlz IGEgcHJvYmxlbT8KPiAKPiBNeSBwcmVmZXJlbmNlIGlzIHRvIHN0YXkgd2l0aCBYUGF0aCAxLjAg KyBjdXJyZW50KCkgZnVuY3Rpb24uCj4gCgoKT0ssIEkgYWdyZWUgLS0gYnV0IEkgZG8gbm90IHRo aW5rIGl0IGlzIGEgYmlnIGRlYWwgaW4gY29tcGFyaXNvbgp0byBhbGwgdGhlIG90aGVyIHdvcmsg YSBjb21waWxlciBoYXMgdG8gZG8uCgpXaGF0IHJlYWxseSBtYXR0ZXJzIGlzIHRoZSBzdHlsZSB0 aGF0IFhQYXRoIHVzZXJzCndpbGwgYmUgbW9zdCBsaWtlbHkgdG8gdXNlLiAgKEkgZG8gbm90IGtu b3cuKQpJZiBhIHByb2dyYW1tZXIga25vd3MgdGhhdCBORVRDT05GL1lBTkcgcmVxdWlyZXMgWE1M IG5hbWVzcGFjZXMKZXZlcnl3aGVyZSwgYW5kIGFsc28ga25vd3MgdGhhdCBYUGF0aCAxLjAgcmVx dWlyZXMgcHJlZml4ZXMKaW4gdGhpcyBjYXNlLCB0aGVuIHRoZXkgd2lsbCBiZSBpbmNsaW5lZCB0 byB1c2UgcHJlZml4ZXMgZXZlcnl3aGVyZS4KClNvIHlvdSBhcmUgcmlnaHQsIGJ5IHZpcnR1ZSBv ZiB0aGUgTGVhc3QgQXN0b25pc2htZW50IFByaW5jaXBsZS4KSU1PLCBYUGF0aCBpcyBoYXJkIHRv IHJlYWQgd2l0aCBvciB3aXRob3V0IHByZWZpeGVzLgpFaXRoZXIgeW91IGtub3cgaXQgb3IgeW91 IGRvbid0LiAgUmVtb3ZpbmcgdGhlIHByZWZpeGVzCmZvciB0aGUgbG9jYWwgbW9kdWxlIGRvZXNu J3QgcmVhbGx5IGhlbHAgcGVvcGxlIHdobyBkb24ndAprbm93IFhQYXRoLCBhbmQgaXQgY29uZnVz ZXMgcGVvcGxlIHdobyBkbyBrbm93IGl0LgoKPj4gV2UgY2FyZSBhYm91dCBjb25mb3JtYW5jZSB0 byBZQU5HIDEuMCwgYW5kIG5vdCBzbyBtdWNoCj4+IGFib3V0IGNvbXBsZXRlIGltcGxlbWVudGF0 aW9uIG9mIFhQYXRoIDIuMC4gIENhbiB3ZSBjYW4gcmVxdWlyZQo+PiBjb21wbGV0ZSBpbXBsZW1l bnRhdGlvbiBvZiBYUGF0aCAxLjAsIHBsdXMgJ2V4dHJhcyc/Cj4gCj4gSSB1bmRlcnN0YW5kIFlB TkcgYWxyZWFkeSBlc3NlbnRpYWxseSByZXF1aXJlcyBpdCAod2l0aCAnJHRoaXMnIGluc3RlYWQK PiBvZiAnY3VycmVudCgpJykuCj4gCj4gTGFkYQo+IAoKQW5keQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Tue Aug 19 12:09:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC113A66B4; Tue, 19 Aug 2008 12:09:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59503A684F for ; Tue, 19 Aug 2008 12:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLYzvZfwmP6M for ; Tue, 19 Aug 2008 12:09:46 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 9E5EA3A66B4 for ; Tue, 19 Aug 2008 12:09:44 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Tue, 19 Aug 2008 12:08:13 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 11:27:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 11:27:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 11:24:41 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7JIOfu42706; Tue, 19 Aug 2008 11:24:41 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7JILEtr080634; Tue, 19 Aug 2008 18:21:14 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808191821.m7JILEtr080634@idle.juniper.net> To: Andy Bierman Date: Tue, 19 Aug 2008 14:21:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 19 Aug 2008 18:24:41.0949 (UTC) FILETIME=[D901C8D0:01C90228] Cc: netmod@ietf.org Subject: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >As Joel pointed out, it would be nice to capture >the design motivations for various details, instead >of just the details. My question is: is the yang draft the appropriate place to record the "why" and motivation for the outcome? Should this be in distinct sections? Should we have an associated FAQ where the questions are of the form "what the heck where you thinking when you ...."? Should we make an "Annotated YANG Standard" document with the draft/rfc text plus the history/rationale/defense/motivation/etc? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 12:32:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBE73A66B4; Tue, 19 Aug 2008 12:32:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E393A67C1 for ; Tue, 19 Aug 2008 12:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoSzaHlfGHvr for ; Tue, 19 Aug 2008 12:32:03 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 9C8A33A6933 for ; Tue, 19 Aug 2008 12:32:02 -0700 (PDT) Received: (qmail 51742 invoked from network); 19 Aug 2008 19:31:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2008 19:31:02 -0000 X-YMail-OSG: bLzhdUYVM1m9JS7MkzEDu_mPDweXnyVFEKbwOzjYkEneceh5whSazGFhT4Ci7eSJs6AY72ohgGsMrTOfKxMmz6J7qgnIsmDq_hl.BrcvTg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AB1F73.5090202@netconfcentral.com> Date: Tue, 19 Aug 2008 12:30:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808191821.m7JILEtr080634@idle.juniper.net> In-Reply-To: <200808191821.m7JILEtr080634@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> As Joel pointed out, it would be nice to capture >> the design motivations for various details, instead >> of just the details. > > My question is: is the yang draft the appropriate place to record > the "why" and motivation for the outcome? Should this be in distinct > sections? Should we have an associated FAQ where the questions are > of the form "what the heck where you thinking when you ...."? Should > we make an "Annotated YANG Standard" document with the draft/rfc > text plus the history/rationale/defense/motivation/etc? > An appendix in the YANG draft is fine unless lots of text is needed. Maybe a YANG FAQ, outside this draft, is a good idea. - Why doesn't YANG support XML attributes? - Why doesn't YANG support the xsd:list data type? - Why doesn't YANG support reusable complex data types? - Why doesn't YANG use the RelaxNG instance qualifiers (?, *, +) instead of leaf-list? - What are the differences between P and NP containers and why should I care? - Why does YANG require that every version of every module be maintained by all users, instead of identifying version contents within one (most current) file per module? - Why doesn't YANG support nested key leafs? - Why does YANG require list keys to be encoded first in all NETCONF PDUs? - Why can't a leaf be used more than once in the same key? - Why doesn't it make sense to use the type 'empty' in a key? - Why can't choices be nested? - Why does the leaf-list represent a conceptual container of N successive instances of 1 leaf, but there is no corresponding conceptual container for 'list'? - Do augmented nodes with 'when' statements always exist for 'must' XPath evaluation purposes in other nodes? - What are the differences between instance-identifiers and keyref? - What happens if keyref objects loop? - Why does YANG have a keyref, but no leafref? - Why do keyrefs need to match the config value (T/F) of the leaf they point at? I support we could come up with 50 more questions, given enough time to think about it ;-) > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 12:35:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D200D3A66B4; Tue, 19 Aug 2008 12:35:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CF03A66B4 for ; Tue, 19 Aug 2008 12:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C06ExOCMoiQF for ; Tue, 19 Aug 2008 12:35:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 922233A6982 for ; Tue, 19 Aug 2008 12:35:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2B02C208F6; Tue, 19 Aug 2008 21:34:07 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-c3-48ab202f131a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 12D532005F; Tue, 19 Aug 2008 21:34:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 21:34:06 +0200 Received: from [153.88.46.53] ([153.88.46.53]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 21:34:06 +0200 From: David Partain Organization: Ericsson AB To: Andy Bierman Date: Tue, 19 Aug 2008 21:34:09 +0200 User-Agent: KMail/1.9.9 References: <200808191821.m7JILEtr080634@idle.juniper.net> <48AB1F73.5090202@netconfcentral.com> In-Reply-To: <48AB1F73.5090202@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808192134.09932.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Aug 2008 19:34:06.0470 (UTC) FILETIME=[8B414260:01C90232] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tuesday 19 August 2008 21.30.59 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> As Joel pointed out, it would be nice to capture > >> the design motivations for various details, instead > >> of just the details. > > > > My question is: is the yang draft the appropriate place to record > > the "why" and motivation for the outcome? Should this be in distinct > > sections? Should we have an associated FAQ where the questions are > > of the form "what the heck where you thinking when you ...."? Should > > we make an "Annotated YANG Standard" document with the draft/rfc > > text plus the history/rationale/defense/motivation/etc? > > An appendix in the YANG draft is fine unless lots of text is needed. > Maybe a YANG FAQ, outside this draft, is a good idea. > > - Why doesn't YANG support XML attributes? > - Why doesn't YANG support the xsd:list data type? > - Why doesn't YANG support reusable complex data types? > - Why doesn't YANG use the RelaxNG instance qualifiers > (?, *, +) instead of leaf-list? > - What are the differences between P and NP containers and > why should I care? > - Why does YANG require that every version of every module > be maintained by all users, instead of identifying version > contents within one (most current) file per module? > - Why doesn't YANG support nested key leafs? > - Why does YANG require list keys to be encoded first > in all NETCONF PDUs? > - Why can't a leaf be used more than once in the same key? > - Why doesn't it make sense to use the type 'empty' in a key? > - Why can't choices be nested? > - Why does the leaf-list represent a conceptual container > of N successive instances of 1 leaf, but there is no > corresponding conceptual container for 'list'? > - Do augmented nodes with 'when' statements always exist > for 'must' XPath evaluation purposes in other nodes? > - What are the differences between instance-identifiers > and keyref? > - What happens if keyref objects loop? > - Why does YANG have a keyref, but no leafref? > - Why do keyrefs need to match the config value (T/F) > of the leaf they point at? > > I support we could come up with 50 more questions, given > enough time to think about it ;-) Hi, I'm sure we could :-) We have a wiki we can use and I would strongly support doing so. If it needs to be turned into a document later, that's easy. Unless someone objects, I'll create a wiki page tomorrow for this purpose and populate it with these questions. We can work out who answers them later :-) Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 12:39:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127553A6841; Tue, 19 Aug 2008 12:39:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF333A684F for ; Tue, 19 Aug 2008 12:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKa1eOarkdFz for ; Tue, 19 Aug 2008 12:39:33 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7EBA53A6841 for ; Tue, 19 Aug 2008 12:39:32 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6792D2072A for ; Tue, 19 Aug 2008 21:19:11 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-7d-48ab1caf3a5a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4E41820723 for ; Tue, 19 Aug 2008 21:19:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 21:19:11 +0200 Received: from [153.88.46.53] ([153.88.46.53]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 21:19:10 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 19 Aug 2008 21:19:14 +0200 User-Agent: KMail/1.9.9 References: <200808121435.15930.david.partain@ericsson.com> <48A1BFD4.6000903@netconfcentral.com> <009a01c90215$34b95620$0601a8c0@allison> In-Reply-To: <009a01c90215$34b95620$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808192119.14599.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Aug 2008 19:19:10.0764 (UTC) FILETIME=[755F5EC0:01C90230] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Consensus on having an interim meeting Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, On Tuesday 19 August 2008 18.02.32 tom.petch wrote: > I do have reservations about this. Were I to attend - unlikely - my > expectations would be low. I think that the process might be interesting > but that progress might be slight. I completely disagree. The qualitative difference between sitting in the same room with a whiteboard and the evenings over a good beer is dramatically different than anything that happens anywhere on a mailing list. Of course, everything gets taken back to the mailing list... (should go without saying). > This is the most active IETF list I can recall and yet .. sometimes it > seems to be > more a tutorial in the finer points of interactions of nuances within the > I-D. Issues do arise that raise a vigorous debate but then they seem rarely > to reach a consensus. There are also e-mails raising good points to which > there is no response on the list. And then there are those > 'Remind me, what did we conclude about ...' > to which my personal answer would be > 'We did not reach a conclusion that I could discern.' :-( I hope that, in the end, all of these issues will be sufficiently documented that people will be able to deal with YANG without needing to know all of this background. > E-mail is the most impoverished form of communication, face-to-face is > much richer, but I wonder why this pattern would not recur at the interim. Of course, it _might_, but I absolutely don't believe so. I (as one of the co-chairs) have zero intention of letting us rat-hole. > And, as has happened once already, there may be a tendency in the meantime > to say "Let's resolve this at the interim" which is apt to delay progress. Sometimes a face-to-face (or a jabber session or a teleconference) makes consensus building much easier than anything email offers. I agree that email isn't a very good way to do this, but it's the tool we have at our disposal. All of that said, I hope you'll attend the interim. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 12:42:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6660B3A6933; Tue, 19 Aug 2008 12:42:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449433A68B4 for ; Tue, 19 Aug 2008 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzZaTE8pfjFq for ; Tue, 19 Aug 2008 12:42:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8ACA53A6933 for ; Tue, 19 Aug 2008 12:42:48 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FEDE20FE7 for ; Tue, 19 Aug 2008 21:08:40 +0200 (CEST) X-AuditID: c1b4fb3e-a7e83bb000007a96-3c-48ab1a38c1dd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F61120FA5 for ; Tue, 19 Aug 2008 21:08:40 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 21:08:39 +0200 Received: from [153.88.46.53] ([153.88.46.53]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 21:08:39 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 19 Aug 2008 21:08:43 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808192108.43818.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Aug 2008 19:08:39.0706 (UTC) FILETIME=[FD3B8FA0:01C9022E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Interim - hotel X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The wiki has been updated with a bunch of hotel information. See http://wiki.tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 I know that some people (myself included) are following Ran's suggestion and are now booked at the Homestead Studio Suites. A link is on the wiki. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 13:17:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646E63A67C1; Tue, 19 Aug 2008 13:17:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4DE53A67C1 for ; Tue, 19 Aug 2008 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zriJlN4WlZ5 for ; Tue, 19 Aug 2008 13:17:23 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D7E003A684F for ; Tue, 19 Aug 2008 13:17:22 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E50F76C423; Tue, 19 Aug 2008 22:16:37 +0200 (CEST) Date: Tue, 19 Aug 2008 22:16:34 +0200 (CEST) Message-Id: <20080819.221634.180955302.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808191821.m7JILEtr080634@idle.juniper.net> References: <200808191821.m7JILEtr080634@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >As Joel pointed out, it would be nice to capture > >the design motivations for various details, instead > >of just the details. > > My question is: is the yang draft the appropriate place to record > the "why" and motivation for the outcome? That's my concern as well. This can't be a new issue within the IETF. I know that there are lots of RFCs that don't document design decisions, but are there examples of standards track rfcs that do document design decisions? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 13:57:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0CF3A684B; Tue, 19 Aug 2008 13:57:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB4B3A6767 for ; Tue, 19 Aug 2008 13:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6Y4bsQlXUiF for ; Tue, 19 Aug 2008 13:57:50 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1999F3A684B for ; Tue, 19 Aug 2008 13:57:50 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 59CCE76C423; Tue, 19 Aug 2008 22:57:42 +0200 (CEST) Date: Tue, 19 Aug 2008 22:57:38 +0200 (CEST) Message-Id: <20080819.225738.47479998.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48A453E4.6090903@netconfcentral.com> References: <48A453E4.6090903@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] error-message clause X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > I think we might end up expanding the 'configured errors' construct > used in the must/pattern/length/range clauses. > > As I'm writing code, I noticed that even though the error-message > clause can override the internal msg string, I am still hardwiring > the xml:lang attribute to 'en'. Perhaps an optional 'error-message-language' > clause is also needed? Fine with me. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 14:12:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359613A6942; Tue, 19 Aug 2008 14:12:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DAF3A6942 for ; Tue, 19 Aug 2008 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.327 X-Spam-Level: X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHdyHK+0UyCV for ; Tue, 19 Aug 2008 14:12:20 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 491EF3A684B for ; Tue, 19 Aug 2008 14:12:20 -0700 (PDT) Received: (qmail 10248 invoked from network); 19 Aug 2008 21:11:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2008 21:11:52 -0000 X-YMail-OSG: WKkBiB0VM1lZHnmbFZLosfx3ixx95RuZViTyLnvp2TRqZOwOBXmp6q0HSFA0v_SsH7mZFZUfHTRIwl0Dzj6rbJDSodICrwCKL4CWG84kWerdXibGnV7VsH0QIw5PpG4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AB3716.4050501@netconfcentral.com> Date: Tue, 19 Aug 2008 14:11:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48A453E4.6090903@netconfcentral.com> <20080819.225738.47479998.mbj@tail-f.com> In-Reply-To: <20080819.225738.47479998.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] error-message clause X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I think we might end up expanding the 'configured errors' construct >> used in the must/pattern/length/range clauses. >> >> As I'm writing code, I noticed that even though the error-message >> clause can override the internal msg string, I am still hardwiring >> the xml:lang attribute to 'en'. Perhaps an optional 'error-message-language' >> clause is also needed? > > Fine with me. > What about a top-level 'language' clause to define the xml:lang enum for all the textual content instead? It is not going to be different for each error. If we were really clever, we would figure out how to support NETCONF agent language localization with a standard error construct in YANG and a standard read-write YANG data model to configure the agent. (But that will have to wait.) > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 14:17:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE153A6839; Tue, 19 Aug 2008 14:17:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432BC3A6839 for ; Tue, 19 Aug 2008 14:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZgy21UtFjWp for ; Tue, 19 Aug 2008 14:17:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 44E103A6767 for ; Tue, 19 Aug 2008 14:17:57 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D55D0C0069; Tue, 19 Aug 2008 23:17:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PMC+j9a-Fr2b; Tue, 19 Aug 2008 23:17:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6412AC0067; Tue, 19 Aug 2008 23:17:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 96DC8696EAD; Tue, 19 Aug 2008 23:17:33 +0200 (CEST) Date: Tue, 19 Aug 2008 23:17:33 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080819211733.GA17146@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , netmod@ietf.org References: <200808191401.m7JE1svY077146@idle.juniper.net> <48AAD795.1020705@netconfcentral.com> <48AADB9C.7030209@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48AADB9C.7030209@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Aug 19, 2008 at 07:41:32AM -0700, Andy Bierman wrote: > Multiple patterns ORed together works with XSD > but not RelaxNG, so we can't use it. But at least > this is adding new functionality, not redundancy. He? Two pattern A and B can always be OR combined into the pattern (A)|(B). Doing an AND combination of two pattern is much much harder and can lead to pretty obscure pattern. This is why an AND combination is actually interesting to have. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 14:33:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58503A6A58; Tue, 19 Aug 2008 14:33:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9FB3A6B67 for ; Tue, 19 Aug 2008 14:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coZnOyedKmFH for ; Tue, 19 Aug 2008 14:33:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0A7BB3A6A58 for ; Tue, 19 Aug 2008 14:32:19 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 81AE520FFF for ; Tue, 19 Aug 2008 23:31:35 +0200 (CEST) X-AuditID: c1b4fb3e-a6680bb000007a96-17-48ab3bb7475d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6A123204BB for ; Tue, 19 Aug 2008 23:31:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 23:31:34 +0200 Received: from [153.88.46.53] ([153.88.46.53]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 23:31:34 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 19 Aug 2008 23:31:38 +0200 User-Agent: KMail/1.9.9 References: <200808191821.m7JILEtr080634@idle.juniper.net> <20080819.221634.180955302.mbj@tail-f.com> In-Reply-To: <20080819.221634.180955302.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808192331.38871.david.partain@ericsson.com> X-OriginalArrivalTime: 19 Aug 2008 21:31:34.0647 (UTC) FILETIME=[F44BB870:01C90242] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tuesday 19 August 2008 22.16.34 Martin Bjorklund wrote: > Phil Shafer wrote: > > Andy Bierman writes: > > >As Joel pointed out, it would be nice to capture > > >the design motivations for various details, instead > > >of just the details. > > > > My question is: is the yang draft the appropriate place to record > > the "why" and motivation for the outcome? > > That's my concern as well. This can't be a new issue within the IETF. > I know that there are lots of RFCs that don't document design > decisions, but are there examples of standards track rfcs that do > document design decisions? Hi all, I am completely certain you won't get a single answer or even a small number of answers to that question. Ad-hoc is probably the nice way of putting it; chaos might be more true :-) Perhaps we can set a good trend here: the WG's wiki has a FAQ page that answers exactly this kind of question. I think it's worth giving a shot since I think wikis are the best way to record collective memory. Maybe we should also appoint a WG FAQ General whose job it is to keep an eye out for recurring questions and put them in the FAQ list... Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 14:33:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82AF3A6A46; Tue, 19 Aug 2008 14:33:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A7A3A6870 for ; Tue, 19 Aug 2008 14:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kOOEHDylhsH for ; Tue, 19 Aug 2008 14:33:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5353B3A6B51 for ; Tue, 19 Aug 2008 14:33:01 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id DC5D876C423; Tue, 19 Aug 2008 23:32:15 +0200 (CEST) Date: Tue, 19 Aug 2008 23:32:11 +0200 (CEST) Message-Id: <20080819.233211.52291247.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <48A9CC80.8010206@joelhalpern.com> References: <48A9CC80.8010206@joelhalpern.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG thoughts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Joel, "Joel M. Halpern" wrote: > The main thing that strikes me, as you can probably see in the comments, > is that this would have been easier to understand with a bit of > motivation. There are a number of design choices which while > reasonable, seem odd. I suspect that there are strong reasons for the > choices. But they are not stated. See the separate discussion on this issue. > Comments: > The first thing that struck me was that the absolute insistence on > non-leafs not having values seemed strange. It makes for much cleaner > XML. And is not actually unreasonable. But it is jarring to the reader. > It would also help if the sentence about datatypes being simple values > occurred earlier. I don't see any obvious place to put this, do you have any suggestions? > For a while I was wondering when one used a > collection of leafs and when one used a complex data structure. Once I > hit the statement that datatypes are always simple values, this became > clear. > > In describing the choice construct, (in 4.2.7, not the later formal > definition) it would be useful if the document showed where a choice > would go. Is it free-standing, and referenced like "using", or does it > appear in a container as if it were a node? (Yes, it is clear > later, but it leaves the reader wondering.) I will add a container wrapper element to the example. > It might be a good idea to indicate when "key" is first described > (4.2.2.4) whether a single leaf is always used as a key (so one uses > nested nodes for multiple indices) or whether multiple keys can be use > together. (I see later that you went for multiple keys. Just say the > statement can list multiple keys in 4.2.2.4.) Done. > The include /import rules seem designed to make life difficult. > 1) It is not clear what happens if the same module is imported more than > once by different parts of the include tree. > 2) The prohibition against circular includes and imports means that > folks writing these things have to be very careful. (I understand that > the basic answer is that if two pieces need to include or import each > other, then they should be one piece. The point is that these rule > means that they HAVE to be one one piece.) > These rules presumably exist for good reasons. But I suspect that some > explanation of the reasons will help the reader grasp the context > better. And probably help the implementors do a better job. > > Also, the distinction between import and include, with include only for > pieces that are part of the same module, and import for anything at all, > looks arbitrary. It presumably isn't. But as it stands it is at best > confusing. Is there some subtle but substantive difference in what they do? I will try to clarify this. > Given that the key-arg syntax in appendix D is a list of identifiers, it > seems that all of the leafs referenced by a key statment must be > directly contained in the list being keyed, and not in a nested > container (much less a nested list). It would be sensible to actually > say this in 7.8.2. The text in 7.8.2. currently says: Each such leaf identifier MUST refer to a child leaf of the list. Is this clear enough? > 7.8.3 (unique) and later 7.15 refer to things being in descendant form. > But no text in this document says what descendant form is. Could > something be put in the glossary section, even if this is a standard XML > term? (If so, then the glossary can just say "XML term for ..., see ... > for a precise definition.) No it's not a std term; its refers to the grammar rule. I'll try to clarify this. > Confusions: > > The prefix statement within a module (as distinct from that used in an > import statement) appears to be advisory, even though it is mandatory, > and is described as "defining" the prefix for the module. In practice, > it seems to be advise to anyone importing the module (either in xml or > YANG) as to what prefix they SHOULD use, if there is no conflict. So it > appears never to be checked. Am I missing something important about how > this statement works? The prefix MAY be used within the module to refer to local typedefs and groupings, and MUST be used to refer to local extensions. > Personal prejudice: > The fact that leaf, and similar statements, have very restricted fields > allowed inside a "uses" makes me uncomfortable. It seems that the > parser will need to understand that many things that are normally legal > are not allowed in that particular leaf (leaf-list...). I agree with you, see e.g. the threads: http://www.ietf.org/mail-archive/web/netmod/current/msg00088.html http://www.ietf.org/mail-archive/web/netmod/current/msg00730.html /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 14:44:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD56A3A6767; Tue, 19 Aug 2008 14:44:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3F43A685B for ; Tue, 19 Aug 2008 14:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbYiq3PUfWcN for ; Tue, 19 Aug 2008 14:44:13 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id A60EC3A6845 for ; Tue, 19 Aug 2008 14:44:13 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 4CrB1a0030b6N64A5Mk3UE; Tue, 19 Aug 2008 21:44:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id 4Mk11a00G4HwxpC8PMk2A4; Tue, 19 Aug 2008 21:44:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=OgIskRz5z9VIz6HG-iYA:9 a=C9UoB47B9X7gljaAl1pGbeLwG6QA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'David Partain'" , References: <200808192108.43818.david.partain@ericsson.com> Date: Tue, 19 Aug 2008 17:44:02 -0400 Message-ID: <091a01c90244$b359ac80$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <200808192108.43818.david.partain@ericsson.com> Thread-Index: AckCM8ulmu8kqkkNTPC+om9/v02O/wAEH4vw Subject: Re: [netmod] Interim - hotel X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Unfortunately, this is 2.5 miles from Juniper, over parkways, so it may not be walkable. The hotels I researched were within walking distance of Juniper and restaurants (although not necessarily as many as offered at Reston center). I thought the other options looked better for price-conscious shoppers. But I'd prefer us all to stay near each other so it is easy to have discussions during the evening and while walking. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of David Partain > Sent: Tuesday, August 19, 2008 3:09 PM > To: netmod@ietf.org > Subject: [netmod] Interim - hotel > > Hi, > > The wiki has been updated with a bunch of hotel information. See > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 > > I know that some people (myself included) are following Ran's > suggestion and > are now booked at the Homestead Studio Suites. A link is on the wiki. > > Cheers, > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 15:01:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14603A6836; Tue, 19 Aug 2008 15:01:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D8C3A6A6F for ; Tue, 19 Aug 2008 15:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlJj1c3vrqYV for ; Tue, 19 Aug 2008 15:01:28 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id C42063A6836 for ; Tue, 19 Aug 2008 15:01:28 -0700 (PDT) Received: (qmail 78268 invoked from network); 19 Aug 2008 22:01:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 19 Aug 2008 22:01:00 -0000 X-YMail-OSG: qG9dWp4VM1n_1ZIj8i6gPL3hskg4OwnHVwbkpzbG3FJqUaw1GjqRzbTr19XnTcg6h4WTmMKWCF2zFH7c7ZL9ZEMtyPU1rPQIX5apHX9rBw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AB429A.8050604@netconfcentral.com> Date: Tue, 19 Aug 2008 15:00:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , netmod@ietf.org References: <200808191401.m7JE1svY077146@idle.juniper.net> <48AAD795.1020705@netconfcentral.com> <48AADB9C.7030209@netconfcentral.com> <20080819211733.GA17146@elstar.local> In-Reply-To: <20080819211733.GA17146@elstar.local> Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Aug 19, 2008 at 07:41:32AM -0700, Andy Bierman wrote: > >> Multiple patterns ORed together works with XSD >> but not RelaxNG, so we can't use it. But at least >> this is adding new functionality, not redundancy. > > He? Two pattern A and B can always be OR combined into the pattern > (A)|(B). Doing an AND combination of two pattern is much much harder > and can lead to pretty obscure pattern. This is why an AND combination > is actually interesting to have. > You have to use chained data types to do this now, but AND expressions are supported. That use case made more sense to me as well (e.g., loopback tested added on top of existing InetAddress test). But fine, I do not care that much. IMO cut-and-pasting all the sub-clauses is not as bad as redesigning the pattern-stmt. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 19 16:26:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346433A6B67; Tue, 19 Aug 2008 16:26:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AA93A6B67 for ; Tue, 19 Aug 2008 16:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.025 X-Spam-Level: X-Spam-Status: No, score=-3.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4raxFpfqbsE0 for ; Tue, 19 Aug 2008 16:26:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1D4683A691D for ; Tue, 19 Aug 2008 16:26:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 529C41C40302; Tue, 19 Aug 2008 16:26:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-162.clppva.btas.verizon.net [71.161.51.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9EFD718434FC; Tue, 19 Aug 2008 16:26:31 -0700 (PDT) Message-ID: <48AB565B.6060603@joelhalpern.com> Date: Tue, 19 Aug 2008 19:25:15 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48A9CC80.8010206@joelhalpern.com> <20080819.233211.52291247.mbj@tail-f.com> In-Reply-To: <20080819.233211.52291247.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG thoughts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Comments in line... Martin Bjorklund wrote: > Hi Joel, > > "Joel M. Halpern" wrote: >> The main thing that strikes me, as you can probably see in the comments, >> is that this would have been easier to understand with a bit of >> motivation. There are a number of design choices which while >> reasonable, seem odd. I suspect that there are strong reasons for the >> choices. But they are not stated. > > See the separate discussion on this issue. > >> Comments: >> The first thing that struck me was that the absolute insistence on >> non-leafs not having values seemed strange. It makes for much cleaner >> XML. And is not actually unreasonable. But it is jarring to the reader. >> It would also help if the sentence about datatypes being simple values >> occurred earlier. > > I don't see any obvious place to put this, do you have any > suggestions? It would seem simple to add some text either to the second paragraph of 4.1, or as an additional paragraph right after that. The second paragraph of 4.1 is where this first comes up. Which lets me try to explain further my point about explanations. Mostly, my guess would be that this is simply a matter of adding a couple of sentences the first time a restriction or design decision is introduced. This sort of explanatory text is very common in RFCs (and very rare in other standards body documents.) .. >> Given that the key-arg syntax in appendix D is a list of identifiers, it >> seems that all of the leafs referenced by a key statment must be >> directly contained in the list being keyed, and not in a nested >> container (much less a nested list). It would be sensible to actually >> say this in 7.8.2. > > The text in 7.8.2. currently says: > > Each such leaf identifier MUST refer to a child leaf of the list. > > Is this clear enough? The issue here is probably as much in my head as in the document, and it is probably up to you folks. However, I tend to see "child leaf of the list" and think of both direct and indirect children. Partially this is simply because I have seen information group such that the necessary key is not a direct child. (We defines structs whose components are themselves structs all the time. While this can be flattened, that is not usually a good practice.) ... _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 01:31:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D63B3A6A0D; Wed, 20 Aug 2008 01:31:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B213A6805 for ; Wed, 20 Aug 2008 01:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMhAE22fx10T for ; Wed, 20 Aug 2008 01:31:34 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 03B643A6AFA for ; Wed, 20 Aug 2008 01:31:33 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CF36120F74 for ; Wed, 20 Aug 2008 10:31:40 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-56-48abd66c6854 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB1EE20D15 for ; Wed, 20 Aug 2008 10:31:40 +0200 (CEST) Received: from esealmw121.eemea.ericsson.se ([153.88.200.80]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Aug 2008 10:31:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Aug 2008 10:31:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Augmentable groupings and module inclusion Thread-Index: AckCnyobfoA8bx5RRG6+4TDauJh2/g== From: "Peter Loborg" To: X-OriginalArrivalTime: 20 Aug 2008 08:31:40.0631 (UTC) FILETIME=[2B4D4670:01C9029F] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Augmentable groupings and module inclusion X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Reading the mail threads about Augmentable groupings it seems to me that there should be some properties of the specification formalism that must not get lost, no matter how nice a construct might look at first glance. I would advocate that one such important property is the possibility to have an agent and sub agents where a sub agent implements one module which is imported and used in your main module (and thus called by your main agent). Important part here is that you should not need to re-compile the sub agent regardless of what you do in your own. In order for this to work there will need to be - a well defined interface between agents and sub agents (future work I presume?) - a language constructs that does not prohibit this usage of pre compiled sub agents e.g. in the form of code libraries from other vendors. Therefore I think that... 1) augmentation of groupings (if allowed) will/should only be applicable to top level groupings imported from another module (which is what I interpret from the draft - only top level groupings can be reused in another module, augmentation can only be done on stuff imported from another module - or?) 2) ...that I no longer can see the usefulness of this construct? What can we do in module A by augmenting an imported grouping B:g1 that we can't achieve by creating a new grouping that uses B:g1 and adds on what is needed? If we want this new grouping visible to others it must be defined on top level of our module, otherwise not. The possible usage I can see is that if we first write our own module A and inside A we uses B:g1 on several places, and then in release 2 wants to add stuff to B.g1 we would need to define our own grouping A:g1 and replace all occurrences in A of B:g1 with A:g1 (or replace them selectively). And we could perhaps save some typing in this process. Finally - if we do allow augmentation of groupings and augment B:g1 in module A, that augmentation can not be allowed to influence usage of B.g1 in another module C that directly imports and uses module B. Which is to say that augment statements per se are not part of the statements/constructs that can be imported to another module. But again, the net effect of an augmentation can be seen by others, if we publish a node from A that builds on it. But then it's a construct from A and does not break the usage-of-precompiled-subagent property (in lack of a better name). BR, Peter Loborg _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 02:17:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9723A6A03; Wed, 20 Aug 2008 02:17:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E823A6B5E for ; Wed, 20 Aug 2008 02:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkmkQVdMVhTM for ; Wed, 20 Aug 2008 02:17:18 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id D269F3A6A03 for ; Wed, 20 Aug 2008 02:17:17 -0700 (PDT) X-Trace: 125943638/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.131 X-SBRS: None X-RemoteIP: 213.116.60.131 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEAGJ+q0jVdDyD/2dsb2JhbACDRDiHb6ofA4FW X-IronPort-AV: E=Sophos;i="4.32,239,1217804400"; d="scan'208";a="125943638" X-IP-Direction: IN Received: from 1cust131.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.131]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Aug 2008 10:17:19 +0100 Message-ID: <028f01c9029c$402cc780$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <200808191821.m7JILEtr080634@idle.juniper.net> <20080819.221634.180955302.mbj@tail-f.com> Date: Wed, 20 Aug 2008 10:09:03 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, August 19, 2008 10:16 PM Subject: Re: [netmod] Recording Motivation > Phil Shafer wrote: > > Andy Bierman writes: > > >As Joel pointed out, it would be nice to capture > > >the design motivations for various details, instead > > >of just the details. > > > > My question is: is the yang draft the appropriate place to record > > the "why" and motivation for the outcome? > > That's my concern as well. This can't be a new issue within the IETF. > I know that there are lots of RFCs that don't document design > decisions, but are there examples of standards track rfcs that do > document design decisions? I notice the shift, that Joel raised the question of 'design motivations' which Martin has commuted into 'design decisions' and I think the latter is the more accurate: and that the discussions on details may be inconclusive or go round in circles because there is an underlying design decision (eg on reuse, on OO-ness, ...) which I do see clearly spelt out anywhere. I would write the I-D on these design decisions if I could, but do not have the wit to discern these decisions clearly from the detail of the current I-D. Likewise Andy's list of "Why doesn't .." seems to me could be paraphrased as "Someone seems to have decided that ... " ie a design decision has been taken but not discussed or recorded. And yes, I think it should be an I-D to best help the current process (and it may or may not become an RFC) and yes, I think that you do have something similar in introductory RFC, eg for SNMPv1 and, to a lesser extent, SNMPv3. In a different field, I see RFC4984 in a similar role as providing a valuable backdrop to the discussions on RRG on how to fix the future of routing (another incredibly active list, albeit an IRTF one). Tom Petch > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 04:27:23 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CA83A6BF3; Wed, 20 Aug 2008 04:27:23 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C089E3A6952 for ; Wed, 20 Aug 2008 04:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOU4L1GpDOSg for ; Wed, 20 Aug 2008 04:27:21 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EC1613A6BF3 for ; Wed, 20 Aug 2008 04:27:20 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 82A0176C040; Wed, 20 Aug 2008 13:27:07 +0200 (CEST) Date: Wed, 20 Aug 2008 13:27:11 +0200 (CEST) Message-Id: <20080820.132711.14262622.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48A4697C.1090202@netconfcentral.com> References: <48A45FB5.8000500@netconfcentral.com> <48A4697C.1090202@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] section E.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Andy Bierman wrote: > > Hi, > > The error appendix section E.4 needs to say that > > it defines the default error-app-tag field, > > if no error-app-tag statement is present. > > > > I also think this section needs to be split into 2 sections. > > The must-stmt error-tag is clearly operation-failed, as specified. > > What is a 'when' statement violation? > I do not see any text in 7.15.2 about it. > If a manager sets a node that is not really there, > then the unknown-element error-tag is sent. I agree. I will remove this. > The length, range, and pattern error-tag should > be 'invalid-value', not 'operation-failed'. Agreed. Actually, I think 'invalid-value' is all that's needed for these cases; there is no need for a specific 'data-restriction-violation' app-tag. So I suggest we remove the special app-tag for length/range/pattern. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 04:55:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36ABE3A6958; Wed, 20 Aug 2008 04:55:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90C13A6A2A for ; Wed, 20 Aug 2008 04:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqo5+dDwf2dN for ; Wed, 20 Aug 2008 04:55:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 105803A6958 for ; Wed, 20 Aug 2008 04:55:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BE81176C040; Wed, 20 Aug 2008 13:55:11 +0200 (CEST) Date: Wed, 20 Aug 2008 13:55:14 +0200 (CEST) Message-Id: <20080820.135514.235097152.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: [netmod] YANG 02 changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Perhaps Martin can summarize the list of edits for -01 > that have "no objections", and we see how many > open issues there really are. Currently the ChangeLog looks like this. I don't know if you wanted more details or if this is ok. - Removed "Appendix A. Derived YANG Types". - Removed "Appendix C. XML Schema Considerations". - Removed "Appendix F. Why We Need a New Modeling Language". - Moved "Appendix B. YIN" to its own section. - Moved "Appendix D. YANG ABNF Grammar" to its own section. - Moved "Appendix E. Error Responses for YANG Related Errors" into its own section. - The "input" and "output" nodes are now implicitly created by the "rpc" statement, in order for augmentation of these nodes to work correctly. - Allow "config" in "choice". - Added reference to XPath 1.0. - Using an XPath function "current()" instead of the variable "$this". - Clarified that a "must" expression in a configuration node must not reference non-configuration nodes. - Added XML encoding rules and usage examples for rpc and notification. - Removed requirement that refinements are specified in the same order as in the original grouping's definition. - Fixed whitespace issues in the ABNF grammar. - Several clarifications and fixed typos. The remaining open issues should be on the wiki, but I haven't had time to add them yet. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 07:52:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAA73A6841; Wed, 20 Aug 2008 07:52:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3EB3A6B6E for ; Wed, 20 Aug 2008 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p18cysyYKf-5 for ; Wed, 20 Aug 2008 07:52:51 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 40BD83A6841 for ; Wed, 20 Aug 2008 07:52:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 20 Aug 2008 07:51:59 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 07:47:57 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 07:47:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Aug 2008 07:47:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7KEluu79489 for ; Wed, 20 Aug 2008 07:47:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7KEiTON096551 for ; Wed, 20 Aug 2008 14:44:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808201444.m7KEiTON096551@idle.juniper.net> To: netmod@ietf.org Date: Wed, 20 Aug 2008 10:44:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2008 14:47:57.0271 (UTC) FILETIME=[BC072670:01C902D3] Subject: [netmod] Interim hotel arrangments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I've talked with the folks at the Homestead and they will give us a rate of $126/night for our group. To make arrangements, send email to Valerie Tiffany mentioning that you are part of the IETF NETMOD Interim Meeting hosted by Juniper Networks. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 08:43:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DDC3A6C19; Wed, 20 Aug 2008 08:43:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2AA23A6C19 for ; Wed, 20 Aug 2008 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhbmhHGS71YT for ; Wed, 20 Aug 2008 08:43:06 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 92B9A3A6849 for ; Wed, 20 Aug 2008 08:43:06 -0700 (PDT) Received: (qmail 32085 invoked from network); 20 Aug 2008 15:42:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2008 15:42:33 -0000 X-YMail-OSG: kiwcc7oVM1lHgv3tEWNPmpTYGzsI8pWhWugp0CzOIKTcqH7294btlX.Q.vgPV7moKNUGM6WT7AfZQlr2lhrrYGIUaRERwPuy1jOoTX1VUA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AC3B66.90901@netconfcentral.com> Date: Wed, 20 Aug 2008 08:42:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "tom.petch" References: <200808191821.m7JILEtr080634@idle.juniper.net> <20080819.221634.180955302.mbj@tail-f.com> <028f01c9029c$402cc780$0601a8c0@allison> In-Reply-To: <028f01c9029c$402cc780$0601a8c0@allison> Cc: netmod@ietf.org Subject: Re: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org tom.petch wrote: .... > Likewise Andy's list of "Why doesn't .." seems to me could be paraphrased as > "Someone seems to have decided that ... " ie a design decision has been taken > but not discussed or recorded. > The purpose of the list was to get people aware of many decisions that went into the individual submission. It is time to get buy-in from the WG, or change some things. I personally agree with many of the decisions, and I can live with the rest of them. I'm almost done implementing YANG and I am trying to point out some details from this experience. IMO, YANG is probably 10X - 50X harder than implementing SNMP. I know some of the complexity will go away (like getting the prefix for a sub-module from its 'belongs-to'.) I suspect when other implementers figure out how hard it is to align YANG nodes with XML nodes, more big changes will occur. > And yes, I think it should be an I-D to best help the current process (and it > may or may not become an RFC) and yes, I think that you do have something > similar in introductory RFC, eg for SNMPv1 and, to a lesser extent, SNMPv3. In > a different field, I see RFC4984 in a similar role as providing a valuable > backdrop to the discussions on RRG on how to fix the future of routing (another > incredibly active list, albeit an IRTF one). > > Tom Petch > >> /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 10:29:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FAC3A691F; Wed, 20 Aug 2008 10:29:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC743A691F for ; Wed, 20 Aug 2008 10:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=-1.174, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEZvy5j9jOMg for ; Wed, 20 Aug 2008 10:29:51 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 375DA3A680A for ; Wed, 20 Aug 2008 10:29:50 -0700 (PDT) Received: (qmail 2714 invoked from network); 20 Aug 2008 17:29:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2008 17:29:18 -0000 X-YMail-OSG: c55LQLkVM1lxA35HWE.4UvrAoEN2yzNAS7G1bMML3zdGoOEkUWX1LljhUmr4pAAqHQdkVFQRZT8eFbukswaJFeIM8H2upUS5S0E3Aw_vjZCPIV7pQXbJ.JFXUlUhcZw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AC546C.80204@netconfcentral.com> Date: Wed, 20 Aug 2008 10:29:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48A45FB5.8000500@netconfcentral.com> <48A4697C.1090202@netconfcentral.com> <20080820.132711.14262622.mbj@tail-f.com> In-Reply-To: <20080820.132711.14262622.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] section E.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Andy Bierman wrote: >>> Hi, >>> The error appendix section E.4 needs to say that >>> it defines the default error-app-tag field, >>> if no error-app-tag statement is present. >>> >> I also think this section needs to be split into 2 sections. >> >> The must-stmt error-tag is clearly operation-failed, as specified. >> >> What is a 'when' statement violation? >> I do not see any text in 7.15.2 about it. >> If a manager sets a node that is not really there, >> then the unknown-element error-tag is sent. > > I agree. I will remove this. > >> The length, range, and pattern error-tag should >> be 'invalid-value', not 'operation-failed'. > > Agreed. Actually, I think 'invalid-value' is all that's needed for > these cases; there is no need for a specific > 'data-restriction-violation' app-tag. So I suggest we remove the > special app-tag for length/range/pattern. > So that would leave must-violation. Good. I think this should have its own error-app-tag. Reusing 'invalid-value' is safe for any existing applications which might interpret this tag in a generic manner. Less work for everybody. > > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 10:58:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608F63A69CE; Wed, 20 Aug 2008 10:58:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D552E3A6C4B for ; Wed, 20 Aug 2008 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEcJV4Xet9C1 for ; Wed, 20 Aug 2008 10:58:14 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id C3F4D3A6C51 for ; Wed, 20 Aug 2008 10:58:13 -0700 (PDT) Received: (qmail 64161 invoked from network); 20 Aug 2008 17:57:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2008 17:57:37 -0000 X-YMail-OSG: MdhRMgoVM1mcSWN84Bk0abLtPtDaQqHLUHvLFcfqk1ayAqUtiQ9to0BZJCPWYtHekMeAz0WsezWNgH1pwdJjbr.O5nxhWUrx2YIz_YNCuQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AC5B0F.30202@netconfcentral.com> Date: Wed, 20 Aug 2008 10:57:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] E.2 and E.3 error-path X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Clearly, 1 of these errors is sent for the entire error when min-elements is not reached. For example, if container 'foo' had a list 'bar' with min-elements == 3, then 1 error is sent with error-path == "/f:foo/f:bar". Not as obvious is that 1 error is also sent if max-elements is exceeded, also with the parent node as the error-path. If list 'bar' had a leaf-list 'baz' with a min or max violation, then one would expect the instance identifier of the 'bar' entry to also be in the error-path: "/f:foo/f:bar[f:name='fred']/f:baz" I think the error-path should be specified in E.2 and E.3. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 11:11:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0DA3A6C4A; Wed, 20 Aug 2008 11:11:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEE23A68F3 for ; Wed, 20 Aug 2008 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSJ+Sh7shV7a for ; Wed, 20 Aug 2008 11:11:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5E3F63A6C4A for ; Wed, 20 Aug 2008 11:11:19 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2DA44D800CB; Wed, 20 Aug 2008 20:10:35 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200808191837.m7JIbd6X080874@idle.juniper.net> References: <200808191837.m7JIbd6X080874@idle.juniper.net> Organization: CESNET Date: Wed, 20 Aug 2008 20:10:36 +0200 Message-Id: <1219255836.6367.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgw5p0IDE5LiAwOC4gMjAwOCB2IDE0OjM3IC0wNDAwOgo+IExh ZGlzbGF2IExob3RrYSB3cml0ZXM6Cj4gPkkgYWdyZWUgdGhhdCBpdCBjYW4gYmUgaGFja2VkIHNv bWVob3cgYnV0IG15IHBvaW50IGlzIHRoYXQgaWYgWUFORwo+ID5kZWNsYXJlcyB0aGF0IGl0IHVz ZXMgWFBhdGggMS4wIChvciAyLjAgb3Igd2hhdGV2ZXIpIGl0IHNob3VsZCBieSBhbGwKPiA+bWVh bnMgZG8gaXQgaW4gYSBjb21wbGlhbnQgd2F5LiBEb2luZyBhcmJpdHJhcnkgWUFORy1zcGVjaWZp YyBjaGFuZ2VzIHRvCj4gPnRoZSBzdGFuZGFyZHMgY2FuIGNvbmZ1c2UgYm90aCBodW1hbnMgYW5k IHRvb2xzLgo+IAo+IEkgZmlybWx5IGJlbGlldmUgdGhhdCB3ZSBoYXZlIHRoaXMuICBXZSBhcmUg dXNpbmcgWFBhdGggaW4KPiBhIG1hbm5lciB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgWFBh dGguICBXZSBkZWZpbmUgdGhlCj4gY29udGV4dCBpbiB3aGljaCBYUGF0aCBleHByZXNzaW9ucyBh cmUgZXZhbHVhdGVkLiAgWFNMVCBkb2VzCj4gdGhlIGV4YWN0IHNhbWUgdGhpbmcsIGluIHNlY3Rp b24gNCBvZiB0aGUgWFNMVCBzcGVjOgo+IAo+IGh0dHA6Ly93d3cudzMub3JnL1RSL3hzbHQjc2Vj dGlvbi1FeHByZXNzaW9ucwo+IAo+ICAgICBJbiBYU0xULCBhbiBvdXRlcm1vc3QgZXhwcmVzc2lv biAoaS5lLiBhbiBleHByZXNzaW9uIHRoYXQgaXMKPiAgICAgbm90IHBhcnQgb2YgYW5vdGhlciBl eHByZXNzaW9uKSBnZXRzIGl0cyBjb250ZXh0IGFzIGZvbGxvd3M6Cj4gICAgIAoKVGhpcyBpcyBh bGwgdHJ1ZSwgYnV0IG5vdCByZWxldmFudCB0byB0aGUgdXNhZ2Ugb2YgTlMgcHJlZml4ZXMgaW4g WFBhdGgKZXhwcmVzc2lvbnMuIEluIFhTTFQsIHdoZW5ldmVyIHlvdSB1c2UgWFBhdGggZXhwcmVz c2lvbnMgY29udGFpbmluZwpRTmFtZXMgdGhhdCBiZWxvbmcgdG8gYSBub24tbnVsbCBuYW1lc3Bh Y2UsIHlvdSBoYXZlIHRvIHdyaXRlIGFsbCBvZgp0aGVtIHdpdGggYW4gKmV4cGxpY2l0KiBOUyBw cmVmaXggc2luY2Ugbm8gcHJlZml4IGFsd2F5cyBtZWFucyBudWxsCm5hbWVzcGFjZS4KClRha2Ug YXMgYW4gZXhhbXBsZSB0aGlzIHRyaXZpYWwgWE1MIGRvY3VtZW50OgoKPD94bWwgdmVyc2lvbj0i MS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPGZvbyB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tIi8+ CgpUaGUgZm9sbG93aW5nIFhTTFQgc3R5bGVzaGVldCAod2hlcmUgdGhlICdodHRwOi8vZXhhbXBs ZS5jb20nIG5hbWVzcGFjZQppcyBkZWZpbmVkIGFzIHRoZSBkZWZhdWx0IG5hbWVzcGFjZSkgd2ls bCBOT1QgZmluZCB0aGUgcm9vdCBlbGVtZW50Cidmb28nOgoKPD94bWwgdmVyc2lvbj0iMS4wIiBz dGFuZGFsb25lPSJ5ZXMiPz4KPHhzbDpzdHlsZXNoZWV0IHhtbG5zOnhzbD0iaHR0cDovL3d3dy53 My5vcmcvMTk5OS9YU0wvVHJhbnNmb3JtIgogICAgICAgICAgICAgICAgeG1sbnM9Imh0dHA6Ly9l eGFtcGxlLmNvbSIKICAgICAgICAgICAgICAgIHZlcnNpb249IjEuMCI+CiAgPHhzbDpvdXRwdXQg bWV0aG9kPSJ0ZXh0Ii8+CiAgPHhzbDp0ZW1wbGF0ZSBtYXRjaD0iLyI+CiAgICA8eHNsOmlmIHRl c3Q9ImZvbyI+Rm91bmQgZm9vLgogICAgPC94c2w6aWY+CiAgPC94c2w6dGVtcGxhdGU+CjwveHNs OnN0eWxlc2hlZXQ+CgpZb3UgYWx3YXlzIGhhdmUgdG8gZGVmaW5lIGFuIGV4cGxpY2l0IHByZWZp eCBhbmQgdXNlIGl0IGluIHRoZSBYUGF0aApleHByZXNzaW9uLiBUaGlzIHdvcmtzOgoKPD94bWwg dmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJ5ZXMiPz4KPHhzbDpzdHlsZXNoZWV0IHhtbG5zOnhz bD0iaHR0cDovL3d3dy53My5vcmcvMTk5OS9YU0wvVHJhbnNmb3JtIgogICAgICAgICAgICAgICAg eG1sbnM6ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbSIKICAgICAgICAgICAgICAgIHZlcnNpb249IjEu MCI+CiAgPHhzbDpvdXRwdXQgbWV0aG9kPSJ0ZXh0Ii8+CiAgPHhzbDp0ZW1wbGF0ZSBtYXRjaD0i LyI+CiAgICA8eHNsOmlmIHRlc3Q9ImV4OmZvbyI+Rm91bmQgZm9vLgogICAgPC94c2w6aWY+CiAg PC94c2w6dGVtcGxhdGU+CjwveHNsOnN0eWxlc2hlZXQ+CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhv dGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Aug 20 11:45:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1981A3A6933; Wed, 20 Aug 2008 11:45:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47553A6933 for ; Wed, 20 Aug 2008 11:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2hnOtjEmVJL for ; Wed, 20 Aug 2008 11:42:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D34723A68D4 for ; Wed, 20 Aug 2008 11:42:54 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 3A2FCD800CE; Wed, 20 Aug 2008 20:42:11 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080819211733.GA17146@elstar.local> References: <200808191401.m7JE1svY077146@idle.juniper.net> <48AAD795.1020705@netconfcentral.com> <48AADB9C.7030209@netconfcentral.com> <20080819211733.GA17146@elstar.local> Organization: CESNET Date: Wed, 20 Aug 2008 20:42:12 +0200 Message-Id: <1219257732.6367.53.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMOadCAxOS4gMDguIDIwMDggdiAyMzoxNyAr MDIwMDoKPiBPbiBUdWUsIEF1ZyAxOSwgMjAwOCBhdCAwNzo0MTozMkFNIC0wNzAwLCBBbmR5IEJp ZXJtYW4gd3JvdGU6Cj4gCj4gPiBNdWx0aXBsZSBwYXR0ZXJucyBPUmVkIHRvZ2V0aGVyIHdvcmtz IHdpdGggWFNECj4gPiBidXQgbm90IFJlbGF4TkcsIHNvIHdlIGNhbid0IHVzZSBpdC4gIEJ1dCBh dCBsZWFzdAo+ID4gdGhpcyBpcyBhZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHksIG5vdCByZWR1bmRh bmN5Lgo+IAo+IEhlPyBUd28gcGF0dGVybiBBIGFuZCBCIGNhbiBhbHdheXMgYmUgT1IgY29tYmlu ZWQgaW50byB0aGUgcGF0dGVybgo+IChBKXwoQikuIERvaW5nIGFuIEFORCBjb21iaW5hdGlvbiBv ZiB0d28gcGF0dGVybiBpcyBtdWNoIG11Y2ggaGFyZGVyCj4gYW5kIGNhbiBsZWFkIHRvIHByZXR0 eSBvYnNjdXJlIHBhdHRlcm4uIFRoaXMgaXMgd2h5IGFuIEFORCBjb21iaW5hdGlvbgo+IGlzIGFj dHVhbGx5IGludGVyZXN0aW5nIHRvIGhhdmUuCgorMS4KCkxhZGEKCj4gCj4gL2pzCj4gCi0tIApM YWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApu ZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QK From netmod-bounces@ietf.org Wed Aug 20 11:55:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3983A69B7; Wed, 20 Aug 2008 11:55:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF99A3A6C2E for ; Wed, 20 Aug 2008 11:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OERpUnsqTaVN for ; Wed, 20 Aug 2008 11:49:47 -0700 (PDT) Received: from chip3og55.obsmtp.com (chip3og55.obsmtp.com [64.18.14.175]) by core3.amsl.com (Postfix) with ESMTP id E13BC3A680A for ; Wed, 20 Aug 2008 11:49:45 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob55.postini.com ([64.18.6.12]) with SMTP; Wed, 20 Aug 2008 11:49:06 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 11:42:56 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 11:42:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 11:42:33 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7KIgWu87955; Wed, 20 Aug 2008 11:42:32 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7KId5bG000402; Wed, 20 Aug 2008 18:39:05 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808201839.m7KId5bG000402@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1219255836.6367.25.camel@missotis> Date: Wed, 20 Aug 2008 14:39:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2008 18:42:33.0479 (UTC) FILETIME=[821A0970:01C902F4] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >You always have to define an explicit prefix and use it in the XPath >expression. This is true because that is how the XSLT spec says the context for XPath expressions is defined. It explicitly says that "the default namespace (as declared by xmlns) is not part of this set" of namespaces in scope for the context. For YANG, we can (MUST) write similar (but different) rules that define the context in which our XPath expressions are evaluated. In our rules, we define the default namespace to be that of the current module. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 12:02:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A440C3A68AF; Wed, 20 Aug 2008 12:02:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1F23A680A for ; Wed, 20 Aug 2008 11:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niAlCG2aPQCN for ; Wed, 20 Aug 2008 11:58:25 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 4E2343A691F for ; Wed, 20 Aug 2008 11:58:25 -0700 (PDT) Received: (qmail 64780 invoked from network); 20 Aug 2008 18:57:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2008 18:57:24 -0000 X-YMail-OSG: qE7EzswVM1kTxYLDnjYzq5kpkBqWOuKuEPvMh2l9EJ8bqLOK2bO.AM2GL4FvBL5GoT7XTEWOuMfhCHo91CcxXt3YcwcZxh6iYB2up3rl.A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AC6912.9070604@netconfcentral.com> Date: Wed, 20 Aug 2008 11:57:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200808191401.m7JE1svY077146@idle.juniper.net> <48AAD795.1020705@netconfcentral.com> <48AADB9C.7030209@netconfcentral.com> <20080819211733.GA17146@elstar.local> <1219257732.6367.53.camel@missotis> In-Reply-To: <1219257732.6367.53.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBww63FoWUgdiDD mnQgMTkuIDA4LiAyMDA4IHYgMjM6MTcgKzAyMDA6Cj4+IE9uIFR1ZSwgQXVnIDE5LCAyMDA4IGF0 IDA3OjQxOjMyQU0gLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToKPj4KPj4+IE11bHRpcGxlIHBh dHRlcm5zIE9SZWQgdG9nZXRoZXIgd29ya3Mgd2l0aCBYU0QKPj4+IGJ1dCBub3QgUmVsYXhORywg c28gd2UgY2FuJ3QgdXNlIGl0LiAgQnV0IGF0IGxlYXN0Cj4+PiB0aGlzIGlzIGFkZGluZyBuZXcg ZnVuY3Rpb25hbGl0eSwgbm90IHJlZHVuZGFuY3kuCj4+IEhlPyBUd28gcGF0dGVybiBBIGFuZCBC IGNhbiBhbHdheXMgYmUgT1IgY29tYmluZWQgaW50byB0aGUgcGF0dGVybgo+PiAoQSl8KEIpLiBE b2luZyBhbiBBTkQgY29tYmluYXRpb24gb2YgdHdvIHBhdHRlcm4gaXMgbXVjaCBtdWNoIGhhcmRl cgo+PiBhbmQgY2FuIGxlYWQgdG8gcHJldHR5IG9ic2N1cmUgcGF0dGVybi4gVGhpcyBpcyB3aHkg YW4gQU5EIGNvbWJpbmF0aW9uCj4+IGlzIGFjdHVhbGx5IGludGVyZXN0aW5nIHRvIGhhdmUuCj4g Cj4gKzEuCj4gCgpJIHRoaW5rIEkgd2FzIHRoZSBvbmx5IG9uZSBvYmplY3RpbmcsIGFuZCBJIGFs cmVhZHkgZ2F2ZSBpbi4KSU1PLCBwdXQgdGhpcyBvbmUgaW4gdGhlICdhY2NlcHRlZCcgY29sdW1u LgoKCj4gTGFkYQo+IAo+PiAvanMKPj4KCkFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Aug 20 12:08:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44053A67ED; Wed, 20 Aug 2008 12:08:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017A83A67ED for ; Wed, 20 Aug 2008 12:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj-MFyGU9THG for ; Wed, 20 Aug 2008 12:08:57 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 5478F3A680B for ; Wed, 20 Aug 2008 12:08:57 -0700 (PDT) Received: (qmail 58632 invoked from network); 20 Aug 2008 19:08:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 20 Aug 2008 19:08:38 -0000 X-YMail-OSG: qyuOPnoVM1lgyKzq_ZNKIsD5gcoF070qf5C2gwdMS1t63MRyHosGS_nNNb0TKzR34JhrTsu_YWqGLkmDprsIEEQiB3LYVl7D6zQ2LWCXBw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AC6BB5.4040200@netconfcentral.com> Date: Wed, 20 Aug 2008 12:08:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] conclusion on mandatory in an augment? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Can we wrap up this detail? It is hard to describe, but mandatory=true is needed when a local 'uses' and 'augment' are added together at the same time. By design, certain properties such as mandatory, config, and even default, can be left out of groupings, and added in with uses refinements or by inherited the property from the parent of the 'uses' (i.e., late binding). It should be an error to augment an existing object with a mandatory node. This cannot be enforced within a single YANG module however. It should also be an error to ever augment another XML namespace with a mandatory node. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 12:29:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFE53A695F; Wed, 20 Aug 2008 12:29:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473AE3A695B for ; Wed, 20 Aug 2008 12:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aePmX3nW-GvA for ; Wed, 20 Aug 2008 12:29:25 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6200B3A680A for ; Wed, 20 Aug 2008 12:29:25 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id E922176C4D6; Wed, 20 Aug 2008 21:29:08 +0200 (CEST) Date: Wed, 20 Aug 2008 21:29:05 +0200 (CEST) Message-Id: <20080820.212905.169074094.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48AC6BB5.4040200@netconfcentral.com> References: <48AC6BB5.4040200@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] conclusion on mandatory in an augment? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > Can we wrap up this detail? > > It is hard to describe, but mandatory=true is needed > when a local 'uses' and 'augment' are added together at > the same time. > > By design, certain properties such as mandatory, config, > and even default, can be left out of groupings, > and added in with uses refinements or by inherited > the property from the parent of the 'uses' (i.e., late binding). > > It should be an error to augment an existing object > with a mandatory node. This cannot be enforced within > a single YANG module however. > > It should also be an error to ever augment another XML namespace > with a mandatory node. I agree with this. Before we can add this, we have to define the term "mandatory node" (leaf with mandatory true, list/leaf-list with min-elements > 0 etc) as we have discussed earlier. The problem with this term is that it's confusing b/c we already talk about mandatory leafs. Can anyone think of a better term? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 12:32:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1354D3A695F; Wed, 20 Aug 2008 12:32:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BEF3A6985 for ; Wed, 20 Aug 2008 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7flLm1P7ihp for ; Wed, 20 Aug 2008 12:32:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 49D353A6969 for ; Wed, 20 Aug 2008 12:32:20 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 52BF8D800CE; Wed, 20 Aug 2008 21:32:08 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200808201839.m7KId5bG000402@idle.juniper.net> References: <200808201839.m7KId5bG000402@idle.juniper.net> Organization: CESNET Date: Wed, 20 Aug 2008 21:32:09 +0200 Message-Id: <1219260729.6367.91.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMjAuIDA4LiAyMDA4IHYgMTQ6MzkgLTA0MDA6Cj4gTGFk aXNsYXYgTGhvdGthIHdyaXRlczoKPiA+WW91IGFsd2F5cyBoYXZlIHRvIGRlZmluZSBhbiBleHBs aWNpdCBwcmVmaXggYW5kIHVzZSBpdCBpbiB0aGUgWFBhdGgKPiA+ZXhwcmVzc2lvbi4KPiAKPiBU aGlzIGlzIHRydWUgYmVjYXVzZSB0aGF0IGlzIGhvdyB0aGUgWFNMVCBzcGVjIHNheXMgdGhlIGNv bnRleHQgZm9yCj4gWFBhdGggZXhwcmVzc2lvbnMgaXMgZGVmaW5lZC4gIEl0IGV4cGxpY2l0bHkg c2F5cyB0aGF0ICJ0aGUgZGVmYXVsdAo+IG5hbWVzcGFjZSAoYXMgZGVjbGFyZWQgYnkgeG1sbnMp IGlzIG5vdCBwYXJ0IG9mIHRoaXMgc2V0IiBvZgo+IG5hbWVzcGFjZXMgaW4gc2NvcGUgZm9yIHRo ZSBjb250ZXh0LgoKWWVzLCBiZWNhdXNlIGlmIGl0IHdlcmUsIGl0IHdvdWxkIHZpb2xhdGUgWFBh dGggc3BlYy4KCj4gCj4gRm9yIFlBTkcsIHdlIGNhbiAoTVVTVCkgd3JpdGUgc2ltaWxhciAoYnV0 IGRpZmZlcmVudCkgcnVsZXMgdGhhdAo+IGRlZmluZSB0aGUgY29udGV4dCBpbiB3aGljaCBvdXIg WFBhdGggZXhwcmVzc2lvbnMgYXJlIGV2YWx1YXRlZC4KPiBJbiBvdXIgcnVsZXMsIHdlIGRlZmlu ZSB0aGUgZGVmYXVsdCBuYW1lc3BhY2UgdG8gYmUgdGhhdCBvZiB0aGUKPiBjdXJyZW50IG1vZHVs ZS4KCkkgZG9uJ3QgdGhpbmsgWFBhdGggMS4wIGFsbG93cyB5b3UgdG8gZG8gdGhhdC4gSXQncyB0 cnVlIHRoYXQgaW4gdGhlCk5FVENPTkYmTkVUTU9EIGNvbnRleHQgWE1MIHZvY2FidWxhcmllcyB3 aXRob3V0IGEgbmFtZXNwYWNlIHNob3VsZCBuZXZlcgpiZSBlbmNvdW50ZXJlZCwgc28gdGhlIGNv bmZ1c2lvbiBiZXR3ZWVuIG5vIG5hbWVwYWNlIGFuZCBkZWZhdWx0Cm5hbWVzcGFjZSBjYW4gcHJv YmFibHkgbmV2ZXIgYXJpc2UsIGJ1dCBzdGlsbCAtIFhQYXRoIDEuMCBzcGVjIHNheXMgaXQKY2xl YXJseTogbm8gcHJlZml4ID0gbm8gbmFtZXNwYWNlLgoKTGFkYQoKPiAKPiBUaGFua3MsCj4gIFBo aWwKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGlu ZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Aug 20 12:41:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB703A6894; Wed, 20 Aug 2008 12:41:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C182D3A69AD for ; Wed, 20 Aug 2008 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SQEQJo+ryVK for ; Wed, 20 Aug 2008 12:41:30 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E9C8A3A6894 for ; Wed, 20 Aug 2008 12:41:29 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 05A0B76C040; Wed, 20 Aug 2008 21:41:03 +0200 (CEST) Date: Wed, 20 Aug 2008 21:41:00 +0200 (CEST) Message-Id: <20080820.214100.185618439.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808201839.m7KId5bG000402@idle.juniper.net> References: <1219255836.6367.25.camel@missotis> <200808201839.m7KId5bG000402@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > For YANG, we can (MUST) write similar (but different) rules that > define the context in which our XPath expressions are evaluated. And we already have some of these in place. > In our rules, we define the default namespace to be that of the > current module. No, that will not work, since there is no concept of "default namespace" in XPath 1.0. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 12:49:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D093A67ED; Wed, 20 Aug 2008 12:49:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47CC3A6894 for ; Wed, 20 Aug 2008 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOwsL-ydHkTG for ; Wed, 20 Aug 2008 12:49:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 097A33A6858 for ; Wed, 20 Aug 2008 12:49:53 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 77563D800CE; Wed, 20 Aug 2008 21:49:24 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48AB160D.2050609@netconfcentral.com> References: <200808111249.m7BCnbQ1097029@idle.juniper.net> <1219073082.6236.3.camel@missotis> <48A997FF.7060509@netconfcentral.com> <1219090016.6236.56.camel@missotis> <48A9DBCD.70903@netconfcentral.com> <1219169596.6338.125.camel@missotis> <48AB160D.2050609@netconfcentral.com> Organization: CESNET Date: Wed, 20 Aug 2008 21:49:25 +0200 Message-Id: <1219261765.5679.8.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IMOadCAxOS4gMDguIDIwMDggdiAxMTo1MCAtMDcwMDoKCj4g WW91IGNhbm5vdCByZXNvbHZlIG11c3Qvd2hlbiBleHByZXNzaW9ucyB3aXRoaW4gYSBncm91cGlu Zy4KPiBUaGUgRE0gd3JpdGVyIG11c3QgYmUgYXdhcmUgdGhhdCB0aGUgZXhwcmVzc2lvbiBuZWVk cyB0bwo+IGJlIHZhbGlkIGFueXdoZXJlIGEgdXNlcy1zdG10IGlzIHZhbGlkLCBhbmQgdGhlIFhQ YXRoIGlzIGV2YWx1YXRlZAo+IGluIHRoZSBjb250ZXh0IG9mIHRoZSAndXNlcycgbW9kdWxlLiAg QWxsIHRoZSBkYXRhIHR5cGluZwoKUmlnaHQsIGJ1dCBpdCBtZWFucyB0aGF0IGUuZy4sIHRyYW5z bGF0aW5nIHRoZSBtb2R1bGUgY29udGFpbmluZyB0aGUKZ3JvdXBpbmcgdG8gRFNETCAodGhlIG11 c3Qtc3RtdCB0byBTY2hlbWF0cm9uIGFzc2VydCkgaXMgbm90IHBvc3NpYmxlCnNpbmNlIHRoZSBu YW1lc3BhY2UgY2Fubm90IGJlIHJlc29sdmVkLgoKTGFkYQoKPiBhbmQgc3ludGF4IGZvciBhIGdy b3VwaW5nIGlzIGV2YWx1YXRlZCBpbiB0aGUgbW9kdWxlCj4gd2l0aCB0aGUgZ3JvdXBpbmcsIHdo aWNoIGlzIGNvbmZ1c2luZy4KCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElE OiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Aug 20 13:15:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751E23A682B; Wed, 20 Aug 2008 13:15:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE7A3A6859 for ; Wed, 20 Aug 2008 13:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em0FeD3nTM5Z for ; Wed, 20 Aug 2008 13:15:15 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 8A58C3A67FD for ; Wed, 20 Aug 2008 13:15:15 -0700 (PDT) Received: (qmail 10651 invoked from network); 20 Aug 2008 20:14:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2008 20:14:25 -0000 X-YMail-OSG: KpOWxccVM1lQffZy38qOyaNTVzI1m3BGwf.t64eCpOPFNPCBfndscLYxrA5gOgTvzoOQyOJhBl1wkp6bVmgkat1pWGv.lOC.c4pwQ2MAlA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AC7B1F.2060202@netconfcentral.com> Date: Wed, 20 Aug 2008 13:14:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200808111249.m7BCnbQ1097029@idle.juniper.net> <1219073082.6236.3.camel@missotis> <48A997FF.7060509@netconfcentral.com> <1219090016.6236.56.camel@missotis> <48A9DBCD.70903@netconfcentral.com> <1219169596.6338.125.camel@missotis> <48AB160D.2050609@netconfcentral.com> <1219261765.5679.8.camel@missotis> In-Reply-To: <1219261765.5679.8.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiDDmnQgMTkuIDA4 LiAyMDA4IHYgMTE6NTAgLTA3MDA6Cj4gCj4+IFlvdSBjYW5ub3QgcmVzb2x2ZSBtdXN0L3doZW4g ZXhwcmVzc2lvbnMgd2l0aGluIGEgZ3JvdXBpbmcuCj4+IFRoZSBETSB3cml0ZXIgbXVzdCBiZSBh d2FyZSB0aGF0IHRoZSBleHByZXNzaW9uIG5lZWRzIHRvCj4+IGJlIHZhbGlkIGFueXdoZXJlIGEg dXNlcy1zdG10IGlzIHZhbGlkLCBhbmQgdGhlIFhQYXRoIGlzIGV2YWx1YXRlZAo+PiBpbiB0aGUg Y29udGV4dCBvZiB0aGUgJ3VzZXMnIG1vZHVsZS4gIEFsbCB0aGUgZGF0YSB0eXBpbmcKPiAKPiBS aWdodCwgYnV0IGl0IG1lYW5zIHRoYXQgZS5nLiwgdHJhbnNsYXRpbmcgdGhlIG1vZHVsZSBjb250 YWluaW5nIHRoZQo+IGdyb3VwaW5nIHRvIERTREwgKHRoZSBtdXN0LXN0bXQgdG8gU2NoZW1hdHJv biBhc3NlcnQpIGlzIG5vdCBwb3NzaWJsZQo+IHNpbmNlIHRoZSBuYW1lc3BhY2UgY2Fubm90IGJl IHJlc29sdmVkLgo+IAoKeWVzIGl0IGNhbi4KV2hlbiB5b3UgY29uY2VwdHVhbGx5IHJlcGxhY2Ug dGhlIHVzZXMgbm9kZSB3aXRoIHRoZQpjb250ZW50cyBvZiB0aGUgZ3JvdXBpbmcsIHlvdSBrbm93 IHRoZSB1c2VzIG1vZHVsZSwKdGhlIGdyb3VwaW5nIG1vZHVsZSwgYW5kIHRoZSBpbXBvcnQgcHJl Zml4IG1hcHMgZm9yIGJvdGguCgoKPiBMYWRhCj4gCj4+IGFuZCBzeW50YXggZm9yIGEgZ3JvdXBp bmcgaXMgZXZhbHVhdGVkIGluIHRoZSBtb2R1bGUKPj4gd2l0aCB0aGUgZ3JvdXBpbmcsIHdoaWNo IGlzIGNvbmZ1c2luZy4KPiAKCkFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Aug 20 13:34:34 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02CE3A6858; Wed, 20 Aug 2008 13:34:34 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C22D3A697D for ; Wed, 20 Aug 2008 13:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nR8pNv+9xUQ for ; Wed, 20 Aug 2008 13:34:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 63DF83A691F for ; Wed, 20 Aug 2008 13:34:32 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 7CEFE76C040; Wed, 20 Aug 2008 22:33:54 +0200 (CEST) Date: Wed, 20 Aug 2008 22:33:51 +0200 (CEST) Message-Id: <20080820.223351.210200899.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48AC5B0F.30202@netconfcentral.com> References: <48AC5B0F.30202@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] E.2 and E.3 error-path X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > Clearly, 1 of these errors is sent for the entire error > when min-elements is not reached. For example, if container > 'foo' had a list 'bar' with min-elements == 3, then 1 error is > sent with error-path == "/f:foo/f:bar". > > Not as obvious is that 1 error is also sent if max-elements > is exceeded, also with the parent node as the error-path. > > If list 'bar' had a leaf-list 'baz' with a min or max violation, > then one would expect the instance identifier of the 'bar' > entry to also be in the error-path: > > "/f:foo/f:bar[f:name='fred']/f:baz" > > I think the error-path should be specified in E.2 and E.3. Just in these two? I started to add: Error-path: Identifies the list or leaf-list with the max-elements constraint. But I'm not sure it actually adds any value to the definition of error-path in rfc 4741: error-path: Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. If you had something particular in mind, could you propse some text to add? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 13:42:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4556E3A6848; Wed, 20 Aug 2008 13:42:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F82A3A6848 for ; Wed, 20 Aug 2008 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOolzdkPWTYY for ; Wed, 20 Aug 2008 13:42:14 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id DC8273A6969 for ; Wed, 20 Aug 2008 13:42:14 -0700 (PDT) Received: (qmail 24848 invoked from network); 20 Aug 2008 20:41:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 20 Aug 2008 20:41:08 -0000 X-YMail-OSG: UEhzbdwVM1lWMvRpH41TQX85BXvrCpPoIAPx8B2wy0CI68DST03_N9mWJbdeYAnxNkg7t9A3x19JwFx7EsF.ZZJoL2X71YOn6bMY2enJXw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AC8163.7040006@netconfcentral.com> Date: Wed, 20 Aug 2008 13:41:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48AC5B0F.30202@netconfcentral.com> <20080820.223351.210200899.mbj@tail-f.com> In-Reply-To: <20080820.223351.210200899.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] E.2 and E.3 error-path X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Clearly, 1 of these errors is sent for the entire error >> when min-elements is not reached. For example, if container >> 'foo' had a list 'bar' with min-elements == 3, then 1 error is >> sent with error-path == "/f:foo/f:bar". >> >> Not as obvious is that 1 error is also sent if max-elements >> is exceeded, also with the parent node as the error-path. >> >> If list 'bar' had a leaf-list 'baz' with a min or max violation, >> then one would expect the instance identifier of the 'bar' >> entry to also be in the error-path: >> >> "/f:foo/f:bar[f:name='fred']/f:baz" >> >> I think the error-path should be specified in E.2 and E.3. > > Just in these two? I started to add: > > Error-path: Identifies the list or leaf-list with the > max-elements constraint. > > But I'm not sure it actually adds any value to the definition of > error-path in rfc 4741: > > error-path: Contains the absolute XPath [2] expression identifying > the element path to the node that is associated with the error > being reported in a particular rpc-error element. > > > If you had something particular in mind, could you propse some text to > add? > I think just a sentence in E.2 that only one error per parent/child combination is generated, not an error for every extra child. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 14:45:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685D63A6980; Wed, 20 Aug 2008 14:45:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E794E3A68AF for ; Wed, 20 Aug 2008 14:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd30DGb-E6Gr for ; Wed, 20 Aug 2008 14:45:00 -0700 (PDT) Received: from chip3og50.obsmtp.com (chip3og50.obsmtp.com [64.18.14.165]) by core3.amsl.com (Postfix) with ESMTP id 317FB3A6359 for ; Wed, 20 Aug 2008 14:44:58 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob50.postini.com ([64.18.6.12]) with SMTP; Wed, 20 Aug 2008 14:44:11 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:35:23 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:35:22 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Aug 2008 14:35:22 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7KLZLu71458; Wed, 20 Aug 2008 14:35:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7KLVr7j003341; Wed, 20 Aug 2008 21:31:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808202131.m7KLVr7j003341@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1219260729.6367.91.camel@missotis> Date: Wed, 20 Aug 2008 17:31:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2008 21:35:22.0005 (UTC) FILETIME=[A6398C50:01C9030C] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >XPath 1.0 spec says it >clearly: no prefix = no namespace. XPath says "if the QName does not have a prefix, then the namespace URI is null", but YANG says "if the namespace URI is null, it refers to the current module". I don't think this is a problem. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 20 14:53:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82B73A67EA; Wed, 20 Aug 2008 14:53:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98153A67D7 for ; Wed, 20 Aug 2008 14:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Akh2A+XMrZv for ; Wed, 20 Aug 2008 14:53:54 -0700 (PDT) Received: from chip3og55.obsmtp.com (chip3og55.obsmtp.com [64.18.14.175]) by core3.amsl.com (Postfix) with ESMTP id CDE383A63CB for ; Wed, 20 Aug 2008 14:53:51 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob55.postini.com ([64.18.6.12]) with SMTP; Wed, 20 Aug 2008 14:53:47 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:32:57 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:32:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Aug 2008 14:32:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7KLWCu69819; Wed, 20 Aug 2008 14:32:12 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7KLSiD0003315; Wed, 20 Aug 2008 21:28:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808202128.m7KLSiD0003315@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080820.214100.185618439.mbj@tail-f.com> Date: Wed, 20 Aug 2008 17:28:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2008 21:32:13.0380 (UTC) FILETIME=[35CBA840:01C9030C] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >> In our rules, we define the default namespace to be that of the >> current module. >No, that will not work, since there is no concept of "default >namespace" in XPath 1.0. My bad. I meant "null", not "default". We define the null namespace to be that of the current module. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 00:36:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95203A68D5; Thu, 21 Aug 2008 00:36:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AAB3A6917 for ; Thu, 21 Aug 2008 00:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNO02vubJ0-x for ; Thu, 21 Aug 2008 00:36:53 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6CEDA3A68D5 for ; Thu, 21 Aug 2008 00:36:53 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AD7B276C4C8; Thu, 21 Aug 2008 09:35:50 +0200 (CEST) Date: Thu, 21 Aug 2008 09:35:52 +0200 (CEST) Message-Id: <20080821.093552.122461371.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1219257732.6367.53.camel@missotis> References: <48AADB9C.7030209@netconfcentral.com> <20080819211733.GA17146@elstar.local> <1219257732.6367.53.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyIHDDrcWhZSB2IMOadCAxOS4gMDguIDIwMDggdiAyMzoxNyArMDIwMDoNCj4gPiBP biBUdWUsIEF1ZyAxOSwgMjAwOCBhdCAwNzo0MTozMkFNIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3Jv dGU6DQo+ID4gDQo+ID4gPiBNdWx0aXBsZSBwYXR0ZXJucyBPUmVkIHRvZ2V0aGVyIHdvcmtzIHdp dGggWFNEDQo+ID4gPiBidXQgbm90IFJlbGF4TkcsIHNvIHdlIGNhbid0IHVzZSBpdC4gIEJ1dCBh dCBsZWFzdA0KPiA+ID4gdGhpcyBpcyBhZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHksIG5vdCByZWR1 bmRhbmN5Lg0KPiA+IA0KPiA+IEhlPyBUd28gcGF0dGVybiBBIGFuZCBCIGNhbiBhbHdheXMgYmUg T1IgY29tYmluZWQgaW50byB0aGUgcGF0dGVybg0KPiA+IChBKXwoQikuIERvaW5nIGFuIEFORCBj b21iaW5hdGlvbiBvZiB0d28gcGF0dGVybiBpcyBtdWNoIG11Y2ggaGFyZGVyDQo+ID4gYW5kIGNh biBsZWFkIHRvIHByZXR0eSBvYnNjdXJlIHBhdHRlcm4uIFRoaXMgaXMgd2h5IGFuIEFORCBjb21i aW5hdGlvbg0KPiA+IGlzIGFjdHVhbGx5IGludGVyZXN0aW5nIHRvIGhhdmUuDQo+IA0KPiArMS4N Cg0KSSBzdXBwb3J0IHRoaXMgY2hhbmdlLiAgSXQgd29ya3MgbGlrZSBpbiBSZWxheE5HLCBhbmQg aXQncyB0cml2aWFsbHkNCnN1cHBvcnRlZCBpbiBYU0QuDQoNCg0KL21hcnRpbg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlz dApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QK From netmod-bounces@ietf.org Thu Aug 21 01:44:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D78B3A6937; Thu, 21 Aug 2008 01:44:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97003A6AF9 for ; Thu, 21 Aug 2008 01:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x8WPoAkdHXj for ; Thu, 21 Aug 2008 01:37:55 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D082E3A68A6 for ; Thu, 21 Aug 2008 01:37:54 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4C7B120E5A; Thu, 21 Aug 2008 10:37:18 +0200 (CEST) X-AuditID: c1b4fb3c-af0d0bb0000015b5-1b-48ad293ec133 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3738320497; Thu, 21 Aug 2008 10:37:18 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 10:37:17 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 10:37:02 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 21 Aug 2008 10:37:02 +0200 User-Agent: KMail/1.9.9 References: <1218001487.6297.4.camel@missotis> <200808081945.m78JjWL7082067@idle.juniper.net> <20080810.213052.220006375.mbj@tail-f.com> In-Reply-To: <20080810.213052.220006375.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808211037.02282.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2008 08:37:02.0349 (UTC) FILETIME=[15794BD0:01C90369] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] XPath expressions in must X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sunday 10 August 2008 21.30.52 Martin Bjorklund wrote: > Phil Shafer wrote: > > Ladislav Lhotka writes: > > >> path "../../interface[name = $this/../ifname]/address/ip"; > > > > > > path "../../interface[name = current()/../ifname]/address/ip"; > > > > You're absolutely right. $this and current() are identical. We > > should mimic this XSLT function instead of rolling our own. > > Unless someone objects, I will make this change and use current() > instead of $this. Hi, That makes good sense to me... (and no one else has objected) David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 05:22:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9DD3A684A; Thu, 21 Aug 2008 05:22:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A603A6832 for ; Thu, 21 Aug 2008 05:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQWcMLIzGaz7 for ; Thu, 21 Aug 2008 05:21:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 026723A635F for ; Thu, 21 Aug 2008 05:21:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D9460210DC; Thu, 21 Aug 2008 14:20:21 +0200 (CEST) X-AuditID: c1b4fb3e-a6e81bb000007a96-a5-48ad5d85eee0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BF25121004; Thu, 21 Aug 2008 14:20:21 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:20:21 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:20:21 +0200 Message-ID: <48AD5D2B.7090505@ericsson.com> Date: Thu, 21 Aug 2008 14:18:51 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48A45FB5.8000500@netconfcentral.com> In-Reply-To: <48A45FB5.8000500@netconfcentral.com> X-OriginalArrivalTime: 21 Aug 2008 12:20:21.0139 (UTC) FILETIME=[47C66630:01C90388] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] section E.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, It is included in the text directly under Appendix E. Balazs Andy Bierman wrote: > Hi, > > The error appendix section E.4 needs to say that > it defines the default error-app-tag field, > if no error-app-tag statement is present. > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 05:33:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E213A635F; Thu, 21 Aug 2008 05:33:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA543A635F for ; Thu, 21 Aug 2008 05:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiupE45Er-UK for ; Thu, 21 Aug 2008 05:33:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2149D3A6846 for ; Thu, 21 Aug 2008 05:33:02 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CA53020F25 for ; Thu, 21 Aug 2008 14:32:41 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-25-48ad6069c36f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B7F8720DDD for ; Thu, 21 Aug 2008 14:32:41 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:32:41 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:32:41 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 21 Aug 2008 14:32:40 +0200 User-Agent: KMail/1.9.9 References: <200808201530.13195.david.partain@ericsson.com> <200808211025.18039.david.partain@ericsson.com> In-Reply-To: <200808211025.18039.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808211432.40881.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2008 12:32:41.0424 (UTC) FILETIME=[0104ED00:01C9038A] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] opinions on the "belong-to" thread X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings all, Contributor hat on... The discussion in question starts at http://www.ietf.org/mail-archive/web/netmod/current/msg00755.html and proposes adding a 'prefix' substatement to 'belongs-to' in order to allow a submodule to be validated in isolation from its main module. The last 15 messages or so with this subject line have nothing to do with the original question. Some issues remain unresolved in this thread, such as this issue is from Andy: What happens if the optional 'prefix b;' is not present? Does that mean the module prefix MUST NOT be used for any local identifier (or any identifier from an 'include')? I think it'd be good to know what people think about this, now that the issue isn't being discussed anymore and doesn't seem to be resolved (not to my satisfaction anyway). 1. Should we add the prefix substatement with relevant updates to address unresolved questions? 2. If you see unresolved issues, what are they? 3. Should NOT add the prefix substatement at all? Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 05:48:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051E33A6846; Thu, 21 Aug 2008 05:48:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BF83A6969 for ; Thu, 21 Aug 2008 05:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JNZ9dQ-8V5I for ; Thu, 21 Aug 2008 05:44:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D8EC33A6780 for ; Thu, 21 Aug 2008 05:44:49 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0FED520FE4; Thu, 21 Aug 2008 14:44:01 +0200 (CEST) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-6d-48ad631053d7 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E767F20FDC; Thu, 21 Aug 2008 14:44:00 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:44:00 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:44:00 +0200 Message-ID: <48AD62B7.7040206@ericsson.com> Date: Thu, 21 Aug 2008 14:42:31 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <000a01c8faa3$670a4a40$6801a8c0@oemcomputer> <489EA436.2000507@netconfcentral.com> <489F14B4.80000@netconfcentral.com> <20080810.214436.179750973.mbj@tail-f.com> In-Reply-To: <20080810.214436.179750973.mbj@tail-f.com> X-OriginalArrivalTime: 21 Aug 2008 12:44:00.0584 (UTC) FILETIME=[95D48480:01C9038B] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I don't agree. We have the case where the there is a default, but it is not just a simple value e.g. the number of users I can serve depends on the amount of memory, the number of interfaces etc. So we should have a marking stating: leaf foo does have a default, but it is not specified in the YAM. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> What about agent-selected, platform-specific defaults? > > Currently in YANG, there is no formal way to learn these or even know > that a leaf is intended to get an agent-selected default. We have > discussed several ways to address this, but I think the main question > the WG has to answer is what level of support YANG should provide for > this problem, if any. > > One way for a client to *know* that a leaf has an egent-selected value > is to add the "created-by" statement. > > In order to learn such a value, I think the best solution is to keep > these values in category 2 "vendor-specific deviations not specified > in the model", and as Phil said thus probably out of scope for YANG > 1.0. > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 05:55:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878203A67F8; Thu, 21 Aug 2008 05:55:10 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC46E3A6962 for ; Thu, 21 Aug 2008 05:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTSgH+hWhqq8 for ; Thu, 21 Aug 2008 05:50:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E1C523A68A3 for ; Thu, 21 Aug 2008 05:50:58 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BF0376C4C8; Thu, 21 Aug 2008 14:50:07 +0200 (CEST) Date: Thu, 21 Aug 2008 14:50:09 +0200 (CEST) Message-Id: <20080821.145009.116855580.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200808211432.40881.david.partain@ericsson.com> References: <200808201530.13195.david.partain@ericsson.com> <200808211025.18039.david.partain@ericsson.com> <200808211432.40881.david.partain@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] opinions on the "belong-to" thread X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Some issues remain unresolved in this thread, such as this issue is from Andy: > > What happens if the optional 'prefix b;' is not present? > Does that mean the module prefix MUST NOT be used for > any local identifier (or any identifier from an 'include')? Yes. If you want to refer to something in the local submodule with a prefix, you must declare a prefix. > I think it'd be good to know what people think about this, now that the issue > isn't being discussed anymore and doesn't seem to be resolved (not to my > satisfaction anyway). > > 1. Should we add the prefix substatement with relevant updates to address > unresolved questions? I think so. Regardless of what we decide here, we have to address the issue in the draft. Currently nothing is said about local prefixes in submodules. Adding the prefix statement to belongs-to is one option. Another option is to say that the prefix is found in the main module. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 06:01:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CECA23A6993; Thu, 21 Aug 2008 06:01:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2873F3A6B21 for ; Thu, 21 Aug 2008 05:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNVErFuizwf4 for ; Thu, 21 Aug 2008 05:56:37 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3DEBE3A6B27 for ; Thu, 21 Aug 2008 05:56:37 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6EF5976C4C8; Thu, 21 Aug 2008 14:56:09 +0200 (CEST) Date: Thu, 21 Aug 2008 14:56:09 +0200 (CEST) Message-Id: <20080821.145609.42591732.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48AD62B7.7040206@ericsson.com> References: <489F14B4.80000@netconfcentral.com> <20080810.214436.179750973.mbj@tail-f.com> <48AD62B7.7040206@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Balazs Lengyel wrote: > I don't agree. We have the case where the there is a default, but it > is not just a simple value e.g. the number of users I can serve > depends on the amount of memory, the number of interfaces etc. > > So we should have a marking stating: leaf foo does have a default, > but it is not specified in the YAM. I'm confused. What part did you disagree with? The suggestion below is to add a statement "created-by system". Isn't that what you ask for above? /martin > Balazs > > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> What about agent-selected, platform-specific defaults? > > Currently in YANG, there is no formal way to learn these or even know > > that a leaf is intended to get an agent-selected default. We have > > discussed several ways to address this, but I think the main question > > the WG has to answer is what level of support YANG should provide for > > this problem, if any. > > One way for a client to *know* that a leaf has an egent-selected value > > is to add the "created-by" statement. > > In order to learn such a value, I think the best solution is to keep > > these values in category 2 "vendor-specific deviations not specified > > in the model", and as Phil said thus probably out of scope for YANG > > 1.0. > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 06:09:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EF028C13B; Thu, 21 Aug 2008 06:09:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381493A6AF4 for ; Thu, 21 Aug 2008 06:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSx4Q8yqqHkY for ; Thu, 21 Aug 2008 06:01:58 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2C0223A6993 for ; Thu, 21 Aug 2008 06:01:58 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6001121194; Thu, 21 Aug 2008 15:01:10 +0200 (CEST) X-AuditID: c1b4fb3e-ab68abb000007a96-8f-48ad67167943 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 527DC200E3; Thu, 21 Aug 2008 15:01:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 15:01:10 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 15:01:09 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 21 Aug 2008 15:01:09 +0200 User-Agent: KMail/1.9.9 References: <200808202131.m7KLVr7j003341@idle.juniper.net> In-Reply-To: <200808202131.m7KLVr7j003341@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808211501.09441.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2008 13:01:09.0747 (UTC) FILETIME=[FB425430:01C9038D] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] XPath compliance and prefix on 'must'? (was Re: belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I'm very confused about the topic at hand... What is the last half of the 'belongs-to' thread talking about? - Whether we're XPath 1.0 compliant or not? (most, maybe all, people seem to think we are) - Whether we have to have a prefix or not on a 'must' statement? - Something else? As Andy correctly points out, we're certainly not talking about whether to add a prefix to belongs-to or not anymore. Looks to me like we have an answer to #1. What are opinions / proposed resolutions about #2? Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 06:34:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC2C3A67B6; Thu, 21 Aug 2008 06:34:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CC43A69BF for ; Thu, 21 Aug 2008 06:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueCRnq7HwHCL for ; Thu, 21 Aug 2008 06:24:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 87CAF3A6846 for ; Thu, 21 Aug 2008 06:24:22 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 57D4420EB9; Thu, 21 Aug 2008 15:00:19 +0200 (CEST) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-27-48ad66e3e06a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3F06120BDE; Thu, 21 Aug 2008 15:00:19 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 15:00:19 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 15:00:18 +0200 Message-ID: <48AD6689.6060800@ericsson.com> Date: Thu, 21 Aug 2008 14:58:49 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <489F14B4.80000@netconfcentral.com> <20080810.214436.179750973.mbj@tail-f.com> <48AD62B7.7040206@ericsson.com> <20080821.145609.42591732.mbj@tail-f.com> In-Reply-To: <20080821.145609.42591732.mbj@tail-f.com> X-OriginalArrivalTime: 21 Aug 2008 13:00:18.0600 (UTC) FILETIME=[DCC5EA80:01C9038D] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Martin, I got the mistaken feeling from your mail, that created-by system was covered by "thus probably out of scope for YANG 1.0." So as you propose to handle the case with "created-by system" in YANG 1.0, I am perfectly happy. Balazs Martin Bjorklund wrote: > Hi, > > Balazs Lengyel wrote: >> I don't agree. We have the case where the there is a default, but it >> is not just a simple value e.g. the number of users I can serve >> depends on the amount of memory, the number of interfaces etc. >> >> So we should have a marking stating: leaf foo does have a default, >> but it is not specified in the YAM. > > I'm confused. What part did you disagree with? The suggestion below > is to add a statement "created-by system". Isn't that what you ask > for above? > > > /martin > > > >> Balazs >> >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> What about agent-selected, platform-specific defaults? >>> Currently in YANG, there is no formal way to learn these or even know >>> that a leaf is intended to get an agent-selected default. We have >>> discussed several ways to address this, but I think the main question >>> the WG has to answer is what level of support YANG should provide for >>> this problem, if any. >>> One way for a client to *know* that a leaf has an egent-selected value >>> is to add the "created-by" statement. >>> In order to learn such a value, I think the best solution is to keep >>> these values in category 2 "vendor-specific deviations not specified >>> in the model", and as Phil said thus probably out of scope for YANG >>> 1.0. >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- 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 >> -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 06:38:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263C73A67F4; Thu, 21 Aug 2008 06:38:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AFD3A6974 for ; Thu, 21 Aug 2008 06:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFJVbVxeLFn0 for ; Thu, 21 Aug 2008 06:32:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C17EE3A68DA for ; Thu, 21 Aug 2008 06:32:23 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB606209B7 for ; Thu, 21 Aug 2008 15:32:00 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-e0-48ad6e5078ad Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B59C22139E for ; Thu, 21 Aug 2008 15:32:00 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 15:32:00 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 15:32:00 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 21 Aug 2008 15:31:59 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808211532.00031.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2008 13:32:00.0364 (UTC) FILETIME=[4A5012C0:01C90392] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy started a thread at http://www.ietf.org/mail-archive/web/netmod/current/msg00690.html entitled "leaf encoding rules". This thread addresses more than one issue, but one is about the XML encoding rules for built-in types. That topic appears in two message: Andy writes: "From 7.6.5: The value of the leaf node is encoded to XML according to the type, and sent as character data in the element. The sections on built-in types do not define any XML encoding rules (yet). When will those be done?" Martin responds: "Section 8 says: The lexicographic representation of a value of a certain type is used in the XML encoding over NETCONF, and when specifying default values in a YANG module. And then each built-in type has a section called "Lexicographic Representation", e.g. 8.1.1." As far as I can see, this isn't discussed anymore after Martin's message. Andy, are you satisfied with this answer or do you think we need to add more to address this issue? Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 07:04:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F73B3A684A; Thu, 21 Aug 2008 07:04:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6753A69A8 for ; Thu, 21 Aug 2008 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij5yRQXAPv3v for ; Thu, 21 Aug 2008 06:52:25 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 926163A68BC for ; Thu, 21 Aug 2008 06:52:25 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7400576C4C8; Thu, 21 Aug 2008 15:51:57 +0200 (CEST) Date: Thu, 21 Aug 2008 15:51:57 +0200 (CEST) Message-Id: <20080821.155157.226121170.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200808211501.09441.david.partain@ericsson.com> References: <200808202131.m7KLVr7j003341@idle.juniper.net> <200808211501.09441.david.partain@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Hi, > > I'm very confused about the topic at hand... > > What is the last half of the 'belongs-to' thread talking about? > > - Whether we're XPath 1.0 compliant or not? (most, maybe all, people seem to > think we are) > - Whether we have to have a prefix or not on a 'must' statement? The question is if we are compliant to XPath 1.0 when we say: Elements without a namespace refer to nodes in the current module. (note: this is the text from draft -02). I think we are, since XPath 1.0 allows both prefixed and unprefixed elements, which refer to elements with and without a namespace, respectively. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 07:25:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D31D28C106; Thu, 21 Aug 2008 07:25:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEA33A6AE4 for ; Thu, 21 Aug 2008 07:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxjOrYTE3RHA for ; Thu, 21 Aug 2008 07:11:30 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 11BC53A6B28 for ; Thu, 21 Aug 2008 07:11:30 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D5A8220588 for ; Thu, 21 Aug 2008 16:10:07 +0200 (CEST) X-AuditID: c1b4fb3e-a9686bb000007a96-b0-48ad773ff73a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C738921991 for ; Thu, 21 Aug 2008 16:10:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:10:07 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:10:07 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 21 Aug 2008 16:10:06 +0200 User-Agent: KMail/1.9.9 References: <200808191821.m7JILEtr080634@idle.juniper.net> <20080819.221634.180955302.mbj@tail-f.com> <028f01c9029c$402cc780$0601a8c0@allison> In-Reply-To: <028f01c9029c$402cc780$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808211610.07077.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2008 14:10:07.0297 (UTC) FILETIME=[9D6E5B10:01C90397] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Recording Motivation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi all, Just to close out this thread... I've created a FAQ page (http://wiki.tools.ietf.org/wg/netmod/trac/wiki/YANG_FAQ) as a place to do some of this work. The genesis of this FAQ list is to try to document things that are not documented in WG documents ("design decisions"). A few caveats... 1. This FAQ must not distract from getting the WG items done. If it does, we'll just get rid of it. This must not be the focus of the working group... 2. It's only questions at this point (largely). If you want to fill in answers, please do. 3. It's entirely possible that some of this should make it into documents we produce; time will tell. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 07:41:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4C03A68BC; Thu, 21 Aug 2008 07:41:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FB83A68DA for ; Thu, 21 Aug 2008 07:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djeTbl4ok+wi for ; Thu, 21 Aug 2008 07:24:43 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id B78923A684A for ; Thu, 21 Aug 2008 07:24:41 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 07:23:31 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:23:10 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:23:09 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 07:23:09 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7LEN9u36507; Thu, 21 Aug 2008 07:23:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7LEJef8013697; Thu, 21 Aug 2008 14:19:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808211419.m7LEJef8013697@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48AD6689.6060800@ericsson.com> Date: Thu, 21 Aug 2008 10:19:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2008 14:23:09.0719 (UTC) FILETIME=[6FCA7A70:01C90399] Cc: netmod@ietf.org Subject: Re: [netmod] leaf encoding rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >So as you propose to handle the case with "created-by system" in YANG 1.0, I a >m perfectly happy. "created-by system" and "I have a complex default that isn't static" are two distinct issues. "created-by system" means that if you don't specify a value, the system will happily assign you one that is better than one you could pick out of thin air. For example, if you are making users, the "uid" will be assigned based on the next available (unused) uid. This is different than complex defaults, where the value isn't created by the system explicitly, but an implicit value is used based on some conditions that aren't easily specified on a "default" statement. For example, the user's disk quota could be the amount of available space divided by the number of configured users. A 4G flash with 40 users will give each user 100M. Delete 20 users and you double the quota for the remaining users. If you assign "quota 100m" in the config, the quota is fixed and no longer floats in accordance with the formula. My question is: what does the application or the device do with the knowledge that the default value is complex? Do they not let the user set it? Do they warn the user "complex stuff here"? What's the value is saying "there's a default but I can't tell you it"? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 07:42:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1823A6B96; Thu, 21 Aug 2008 07:42:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13AC28C111 for ; Thu, 21 Aug 2008 07:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeh17O85lwxU for ; Thu, 21 Aug 2008 07:27:58 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 401253A696B for ; Thu, 21 Aug 2008 07:27:56 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 07:24:40 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:26:30 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:26:29 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 07:26:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7LEQSu37909; Thu, 21 Aug 2008 07:26:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7LEN09h013788; Thu, 21 Aug 2008 14:23:00 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808211423.m7LEN09h013788@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080821.145009.116855580.mbj@tail-f.com> Date: Thu, 21 Aug 2008 10:22:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2008 14:26:29.0469 (UTC) FILETIME=[E6D9E8D0:01C90399] Cc: netmod@ietf.org Subject: Re: [netmod] opinions on the "belong-to" thread X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Yes. If you want to refer to something in the local submodule with a >prefix, you must declare a prefix. Sounds good to me. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 07:42:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C53028C15E; Thu, 21 Aug 2008 07:42:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C283A68A3 for ; Thu, 21 Aug 2008 07:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BSLsx4Ysbfl for ; Thu, 21 Aug 2008 07:36:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6CE6C3A6829 for ; Thu, 21 Aug 2008 07:36:27 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB84B20FC6; Thu, 21 Aug 2008 16:35:22 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-a7-48ad7d2af793 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C75F920F98; Thu, 21 Aug 2008 16:35:22 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:35:22 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:35:22 +0200 Message-ID: <48AD7CD1.2080501@ericsson.com> Date: Thu, 21 Aug 2008 16:33:53 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.090508.104047439.mbj@tail-f.com> <200808111249.m7BCnbQ1097029@idle.juniper.net> <20080811.150017.202801987.mbj@tail-f.com> <20080811.154837.65694432.mbj@tail-f.com> In-Reply-To: <20080811.154837.65694432.mbj@tail-f.com> X-OriginalArrivalTime: 21 Aug 2008 14:35:22.0251 (UTC) FILETIME=[2469FDB0:01C9039B] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, The draft says in chapter 6.3.1. Language Extensions "When an imported extension is used, the keyword must be qualified using the prefix with which the extension's module was imported." The text above seems to imply that only imported extensions need a prefix. Please remove the word imported. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 07:43:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CACC3A6B68; Thu, 21 Aug 2008 07:43:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6603A6B1A for ; Thu, 21 Aug 2008 07:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpjK83+SUAyk for ; Thu, 21 Aug 2008 07:40:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2CB793A6B0A for ; Thu, 21 Aug 2008 07:40:55 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0DF4F2135F; Thu, 21 Aug 2008 16:40:25 +0200 (CEST) X-AuditID: c1b4fb3e-a8e85bb000007a96-b0-48ad7e587810 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E6D332116B; Thu, 21 Aug 2008 16:40:24 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:40:24 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:40:24 +0200 Message-ID: <48AD7DFF.4070200@ericsson.com> Date: Thu, 21 Aug 2008 16:38:55 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20080811.090508.104047439.mbj@tail-f.com> <20080818122416.GD12968@elstar.local> <20080818.143746.228944386.mbj@tail-f.com> In-Reply-To: <20080818.143746.228944386.mbj@tail-f.com> X-OriginalArrivalTime: 21 Aug 2008 14:40:24.0314 (UTC) FILETIME=[D87525A0:01C9039B] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I WANT to forbid using different prefixes in the module and it's submodules. I see no advantage, but find the idea rather confusing. If the prefix in belong-to is optional I don't really see the advantage, you must still be capable of handling non-prefixed submodules. Or would it be mandatory? otherwise I don't see the strong need for the prefix in belongs-to, but can live with it. Balazs Martin Bjorklund wrote: >> What happens if the prefix declared in belongs-to is different from >> the prefix declared in the module? > > Nothing. Just as you can import with a different prefix than is used > in the imported module. > > > /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 07:57:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5212C3A68E5; Thu, 21 Aug 2008 07:57:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0341A3A67F9 for ; Thu, 21 Aug 2008 07:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt6dMCtdkJr7 for ; Thu, 21 Aug 2008 07:57:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 95B2C3A696B for ; Thu, 21 Aug 2008 07:57:36 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E9ADF205C2; Thu, 21 Aug 2008 16:01:12 +0200 (CEST) X-AuditID: c1b4fb3e-a5e7fbb000007a96-68-48ad75287033 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D50DF200BF; Thu, 21 Aug 2008 16:01:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:01:12 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:01:12 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 21 Aug 2008 16:01:11 +0200 User-Agent: KMail/1.9.9 References: <48AC5B0F.30202@netconfcentral.com> <20080820.223351.210200899.mbj@tail-f.com> <48AC8163.7040006@netconfcentral.com> In-Reply-To: <48AC8163.7040006@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808211601.11970.david.partain@ericsson.com> X-OriginalArrivalTime: 21 Aug 2008 14:01:12.0327 (UTC) FILETIME=[5E906970:01C90396] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] E.2 and E.3 error-path X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi all, On Wednesday 20 August 2008 22.41.07 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> Clearly, 1 of these errors is sent for the entire error > >> when min-elements is not reached. For example, if container > >> 'foo' had a list 'bar' with min-elements == 3, then 1 error is > >> sent with error-path == "/f:foo/f:bar". > >> > >> Not as obvious is that 1 error is also sent if max-elements > >> is exceeded, also with the parent node as the error-path. > >> > >> If list 'bar' had a leaf-list 'baz' with a min or max violation, > >> then one would expect the instance identifier of the 'bar' > >> entry to also be in the error-path: > >> > >> "/f:foo/f:bar[f:name='fred']/f:baz" > >> > >> I think the error-path should be specified in E.2 and E.3. > > > > Just in these two? I started to add: > > > > Error-path: Identifies the list or leaf-list with the > > max-elements constraint. > > > > But I'm not sure it actually adds any value to the definition of > > error-path in rfc 4741: > > > > error-path: Contains the absolute XPath [2] expression identifying > > the element path to the node that is associated with the error > > being reported in a particular rpc-error element. > > > > > > If you had something particular in mind, could you propse some text to > > add? > > I think just a sentence in E.2 that only one error per parent/child > combination is generated, not an error for every extra child. Seems good to me... David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 08:07:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128593A69B1; Thu, 21 Aug 2008 08:07:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886D13A6945 for ; Thu, 21 Aug 2008 08:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHobL1TXTxjZ for ; Thu, 21 Aug 2008 08:06:45 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 73D203A6829 for ; Thu, 21 Aug 2008 08:06:45 -0700 (PDT) Received: (qmail 72244 invoked from network); 21 Aug 2008 15:06:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 15:06:15 -0000 X-YMail-OSG: JlmJh5EVM1nEMbUYZCzF5qTyn0xs7n0BPrEoYqvrUkIS6DA5t4Phpc3H_JSbP8crKfM2p41pY5S8ayPOVxS1RdTEGgJxk140.kOuSu5Kqbre5iTs6Xbw6rPzdNaNGPg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AD8465.4020307@netconfcentral.com> Date: Thu, 21 Aug 2008 08:06:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Partain References: <200808211532.00031.david.partain@ericsson.com> In-Reply-To: <200808211532.00031.david.partain@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Hi, > > Andy started a thread at > http://www.ietf.org/mail-archive/web/netmod/current/msg00690.html > entitled "leaf encoding rules". This thread addresses more than one issue, > but one is about the XML encoding rules for built-in types. That topic > appears in two message: > > Andy writes: > > "From 7.6.5: > > The value of the leaf node is encoded to XML according to the type, > and sent as character data in the element. > > > The sections on built-in types do not define any XML encoding > rules (yet). When will those be done?" > > Martin responds: > > "Section 8 says: > > The lexicographic representation of a value of a certain type is used > in the XML encoding over NETCONF, and when specifying default values > in a YANG module. > > And then each built-in type has a section called "Lexicographic > Representation", e.g. 8.1.1." > > As far as I can see, this isn't discussed anymore after Martin's message. > > Andy, are you satisfied with this answer or do you think we need to add more > to address this issue? > no -- I probably looked at one of the only sections that this was missing when I made that comment. I think -01 will complete the XML encoding details. > Cheers, > > David Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 08:20:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA333A67B2; Thu, 21 Aug 2008 08:20:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8D83A68D7 for ; Thu, 21 Aug 2008 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhDc47zKbKOO for ; Thu, 21 Aug 2008 08:19:27 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 707B03A67EE for ; Thu, 21 Aug 2008 08:19:27 -0700 (PDT) Received: (qmail 65973 invoked from network); 21 Aug 2008 15:18:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 15:18:47 -0000 X-YMail-OSG: zBXthIsVM1njfF1YZXLGb8hhr1AcIhE7Rrtv2.Gtnem6bG70y.Nx0sIFXm6mV8AURguB24VsS7zOe6Yxd9YRDl4heRQA99NY7MY13Rh0bg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AD8756.5040500@netconfcentral.com> Date: Thu, 21 Aug 2008 08:18:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <20080811.090508.104047439.mbj@tail-f.com> <200808111249.m7BCnbQ1097029@idle.juniper.net> <20080811.150017.202801987.mbj@tail-f.com> <20080811.154837.65694432.mbj@tail-f.com> <48AD7CD1.2080501@ericsson.com> In-Reply-To: <48AD7CD1.2080501@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > The draft says in chapter 6.3.1. Language Extensions > > "When an imported extension is used, the keyword must be qualified using > the prefix with which the extension's module was imported." > > The text above seems to imply that only imported extensions need a > prefix. Please remove the word imported. > I think you are right. If I want to define my own 'foo:leaf' clause, then of course I have to use foo:leaf, even in the foo module. If I just use 'leaf' in the foo module, then the YANG keyword wins, and 'foo:leaf' will not be checked. This would not be the case if the extension name did not conflict. (foo:my-leaf <--> my-leaf no problem). For consistency, an extension should always be used with a prefix. But I don't know if a special CLR is needed. The same issues apply to any imported symbol. > Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 08:56:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995D63A6AFA; Thu, 21 Aug 2008 08:56:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6F93A6BB6 for ; Thu, 21 Aug 2008 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lC5yXLsut4A for ; Thu, 21 Aug 2008 08:50:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 234F73A6BB5 for ; Thu, 21 Aug 2008 08:50:01 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id F08C9D800CE; Thu, 21 Aug 2008 17:49:23 +0200 (CEST) From: Ladislav Lhotka To: David Partain In-Reply-To: <200808211501.09441.david.partain@ericsson.com> References: <200808202131.m7KLVr7j003341@idle.juniper.net> <200808211501.09441.david.partain@ericsson.com> Organization: CESNET Date: Thu, 21 Aug 2008 17:49:23 +0200 Message-Id: <1219333763.6909.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re: belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org RGF2aWQgUGFydGFpbiBww63FoWUgdiDEjHQgMjEuIDA4LiAyMDA4IHYgMTU6MDEgKzAyMDA6Cj4g SGksCj4gCj4gSSdtIHZlcnkgY29uZnVzZWQgYWJvdXQgdGhlIHRvcGljIGF0IGhhbmQuLi4KPiAK PiBXaGF0IGlzIHRoZSBsYXN0IGhhbGYgb2YgdGhlICdiZWxvbmdzLXRvJyB0aHJlYWQgdGFsa2lu ZyBhYm91dD8gIAo+IAo+IC0gV2hldGhlciB3ZSdyZSBYUGF0aCAxLjAgY29tcGxpYW50IG9yIG5v dD8gIChtb3N0LCBtYXliZSBhbGwsIHBlb3BsZSBzZWVtIHRvIAo+IHRoaW5rIHdlIGFyZSkKCllB TkcgZHJhZnQgZGVmaW5lcyB0aGUgbnVsbCBuYW1lc3BhY2UgdG8gYmUgdGhlIG5hbWVzcGFjZSBv ZiB0aGUgY3VycmVudAptb2R1bGUsIHdoaWNoIGlzIElNTyBub3QgYWNjZXB0YWJsZSAtIG51bGwg bmFtZXNwYWNlIGhhcyBhIHZlcnkgcHJlY2lzZQptZWFuaW5nIHNpbWlsYXIgdG8gZW1wdHkgc2V0 IGluIHRoZSBzZXQgdGhlb3J5LgogCj4gLSBXaGV0aGVyIHdlIGhhdmUgdG8gaGF2ZSBhIHByZWZp eCBvciBub3Qgb24gYSAnbXVzdCcgc3RhdGVtZW50PwoKSSBiZWxpZXZlIHRoZSBhbnN3ZXIgaXMg eWVzIC0gYWN0dWFsbHksIGEgbmFtZXNwYWNlIHByZWZpeCBoYXMgdG8gYmUKYXR0YWNoZWQgdG8g ZXZlcnkgUU5hbWUgKGNvbXBvbmVudCkgb2YgdGhlIFhQYXRoIDEuMCBleHByZXNzaW9uIHRoYXQg aXMKaW4gdGhlIGFyZ3VtZW50IG9mIG11c3Qtc3RtdC4KCj4gLSBTb21ldGhpbmcgZWxzZT8KCiR0 aGlzIC0+IGN1cnJlbnQoKSwgYnV0IHRoZXJlIHNlZW1zIHRvIGJlIGNvbnNlbnN1cyBvbiB0aGlz LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBD CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2Qg bWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 21 09:48:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A063A688D; Thu, 21 Aug 2008 09:48:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948173A688D for ; Thu, 21 Aug 2008 09:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ6Q+HjmY0mT for ; Thu, 21 Aug 2008 09:45:26 -0700 (PDT) Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id 739473A6914 for ; Thu, 21 Aug 2008 09:45:21 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob61.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 09:45:02 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 09:23:41 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 09:23:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 09:23:40 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7LGNdu87346; Thu, 21 Aug 2008 09:23:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7LGKBmo015625; Thu, 21 Aug 2008 16:20:11 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808211620.m7LGKBmo015625@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1219333763.6909.13.camel@missotis> Date: Thu, 21 Aug 2008 12:20:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2008 16:23:40.0531 (UTC) FILETIME=[45B0D430:01C903AA] Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re: belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >YANG draft defines the null namespace to be the namespace of the current >module, which is IMO not acceptable - null namespace has a very precise >meaning similar to empty set in the set theory. Could you please point me a precise definition? >> - Whether we have to have a prefix or not on a 'must' statement? > >I believe the answer is yes - actually, a namespace prefix has to be >attached to every QName (component) of the XPath 1.0 expression that is >in the argument of must-stmt. This will our XPath expressions much uglier and much more error prone. I do not see any evil in allowing YANG to define the meaning of the null namespace as part of the context in which XPath expressions are evaluated. I do not see this as a source of confusion for data modelers and see the alternative as problematic. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 10:30:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDAE3A6A1A; Thu, 21 Aug 2008 10:30:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC4B3A6AAD for ; Thu, 21 Aug 2008 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRDbsPYIKSfu for ; Thu, 21 Aug 2008 10:25:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 24FC73A6A17 for ; Thu, 21 Aug 2008 10:25:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4758FC00A8; Thu, 21 Aug 2008 19:24:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kO1Q-koacW3k; Thu, 21 Aug 2008 19:24:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B7A8C00A7; Thu, 21 Aug 2008 19:24:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5519D69A394; Thu, 21 Aug 2008 19:24:22 +0200 (CEST) Date: Thu, 21 Aug 2008 19:24:22 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080821172422.GA21713@elstar.local> Mail-Followup-To: Phil Shafer , Ladislav Lhotka , netmod@ietf.org References: <1219333763.6909.13.camel@missotis> <200808211620.m7LGKBmo015625@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200808211620.m7LGKBmo015625@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re: belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Aug 21, 2008 at 12:20:10PM -0400, Phil Shafer wrote: > I do not see any evil in allowing YANG to define the meaning of the > null namespace as part of the context in which XPath expressions > are evaluated. I do not see this as a source of confusion for data > modelers and see the alternative as problematic. I do not see how requiring prefixes can lead to confusion. We optimize for the readers and a prefix is makes things unambiguous and avoids surprises if people cut'n'paste XPATH expressions. The only downside seems to be that expressions get slightly more verbose. To what extend is this really a problem? Do we have any idea how many local qnames our XPATH expressions will contain? Anything we can learn here from proprietary data modeling languages? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 11:05:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198383A6A32; Thu, 21 Aug 2008 11:05:04 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0823A6A32 for ; Thu, 21 Aug 2008 10:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrX1o1EQ4pD9 for ; Thu, 21 Aug 2008 10:51:52 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 041303A67E6 for ; Thu, 21 Aug 2008 10:51:52 -0700 (PDT) Received: (qmail 46614 invoked from network); 21 Aug 2008 17:46:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 17:46:34 -0000 X-YMail-OSG: tAK0wW8VM1kVFT9Ey3MNGEJ5a3WcaMEHatbeyKaNMnX5Zy8hrXLTlCDjPKPkmNtUN9Jw1MlIrAiR5cKqjWQNrPdpNh99yUbDnhbB9n0V4Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48ADA9F8.7080307@netconfcentral.com> Date: Thu, 21 Aug 2008 10:46:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer , Ladislav Lhotka , netmod@ietf.org References: <1219333763.6909.13.camel@missotis> <200808211620.m7LGKBmo015625@idle.juniper.net> <20080821172422.GA21713@elstar.local> In-Reply-To: <20080821172422.GA21713@elstar.local> Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re: belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Aug 21, 2008 at 12:20:10PM -0400, Phil Shafer wrote: > >> I do not see any evil in allowing YANG to define the meaning of the >> null namespace as part of the context in which XPath expressions >> are evaluated. I do not see this as a source of confusion for data >> modelers and see the alternative as problematic. > > I do not see how requiring prefixes can lead to confusion. We optimize > for the readers and a prefix is makes things unambiguous and avoids > surprises if people cut'n'paste XPATH expressions. > > The only downside seems to be that expressions get slightly more > verbose. To what extend is this really a problem? Do we have any idea > how many local qnames our XPATH expressions will contain? Anything we > can learn here from proprietary data modeling languages? > Well for starters, you really do not want prefixes when writing must statements for siblings within a grouping. You really mean 'use the local namespace' when you leave the prefix out in this case. However, as I pointed out in a previous mail, the tools will need to examine all the prefixes in the context of the grouping module, and translate them to the uses module. Whether the prefix is present or not has no impact whatsoever on the complexity of the code. If we go back to first principles for a moment, the reason prefixes are optional is to let the DM designer decide. It seems like forcing a usage either way moves against this valid design principle. Consistent handling of QNames throughout the YANG module would be less confusing than doing otherwise. That much I am certain of -- the rest, not so much... > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 12:52:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4294C3A6A86; Thu, 21 Aug 2008 12:52:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD6A3A6853 for ; Thu, 21 Aug 2008 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooRxC4DXeime for ; Thu, 21 Aug 2008 12:49:07 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 804FF3A687E for ; Thu, 21 Aug 2008 12:49:03 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 12:48:42 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 11:53:31 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 11:53:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 11:53:30 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7LIrUu58086; Thu, 21 Aug 2008 11:53:30 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7LIo0hN017834; Thu, 21 Aug 2008 18:50:01 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808211850.m7LIo0hN017834@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080821172422.GA21713@elstar.local> Date: Thu, 21 Aug 2008 14:50:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2008 18:53:30.0751 (UTC) FILETIME=[344788F0:01C903BF] Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re: belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >I do not see how requiring prefixes can lead to confusion. We optimize >for the readers and a prefix is makes things unambiguous and avoids >surprises if people cut'n'paste XPATH expressions. True but is also means I can't say: leaf one { ... } leaf two { ... } leaf three { must "../one || ../two" { ... } } I must use the prefix, even thru I just defined them without a prefix. (Sure, this is similar to types, which are defined with no prefix but must have one when used, but it sure feels worse.) >The only downside seems to be that expressions get slightly more >verbose. To what extend is this really a problem? Do we have any idea >how many local qnames our XPATH expressions will contain? Anything we >can learn here from proprietary data modeling languages? Real world examples appended. The ugly ones get uglier, but they are already ugly enough that it may not matter. Thanks, Phil example one: must not(../../../../snmp/routing-instance-access/access-list/default) becomes: must not(../../../../snmp:snmp/snmp:routing-instance-access/snmp:access-list/snmp:default) example two: leaf interface-name { type junos:interface-unit; must ../../../../protocols/pim/interface[name = current()]/disable || ../../../../routing-options/multicast/interface[name = current()]/disable || ../../../../routing-options/multicast/interface[name = current()]/maximum-bandwidth || not(../../../../protocols/pim/interface[name = current()] || (../../../../protocols/pim/interface[name = 'all'] && not(../../../../protocols/pim/interface[name = 'all']/disable)))) { error-message "PIM and multicast cannot be enabled on the same interface in the [edit routing-options] hierarchy"; } } becomes: leaf interface-name { type junos:interface-unit; must ../../../../protocols/pim:pim/pim:interface[pim:name = current()]/pim:disable || ../../../../routing-options/pim:multicast/pim:interface[pim:name = current()]/pim:disable || ../../../../routing-options/pim:multicast/pim:interface[pim:name = current()]/pim:maximum-bandwidth || not(../../../../protocols/pim:pim/pim:interface[pim:name = current()] || (../../../../protocols/pim:pim/pim:interface[pim:name = 'all'] && not(../../../../protocols/pim:pim/pim:interface[pim:name = 'all']/pim:disable)))) { error-message "PIM and multicast cannot be enabled on the same interface in the [edit routing-options] hierarchy"; } } _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 13:07:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2416F3A68F5; Thu, 21 Aug 2008 13:07:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D599D3A6B6E for ; Thu, 21 Aug 2008 13:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2l1jzVMwtb2 for ; Thu, 21 Aug 2008 13:02:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 74C3D3A6996 for ; Thu, 21 Aug 2008 13:02:46 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id C6CA776C4C8; Thu, 21 Aug 2008 21:52:37 +0200 (CEST) Date: Thu, 21 Aug 2008 21:52:33 +0200 (CEST) Message-Id: <20080821.215233.194872275.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48AD8756.5040500@netconfcentral.com> References: <20080811.154837.65694432.mbj@tail-f.com> <48AD7CD1.2080501@ericsson.com> <48AD8756.5040500@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Balazs Lengyel wrote: > > Hello, > > The draft says in chapter 6.3.1. Language Extensions > > "When an imported extension is used, the keyword must be qualified using the prefix with which the extension's module was imported." > > The text above seems to imply that only imported extensions need a prefix. Please remove the word imported. > > > > I think you are right. > > If I want to define my own 'foo:leaf' clause, then of course > I have to use foo:leaf, even in the foo module. > If I just use 'leaf' in the foo module, then > the YANG keyword wins, and 'foo:leaf' will not be checked. > This would not be the case if the extension name > did not conflict. (foo:my-leaf <--> my-leaf no problem). > > For consistency, an extension should always be used with a prefix. > But I don't know if a special CLR is needed. The same issues > apply to any imported symbol. Actually, there are two issues here, The general rule is defined in 4.2.1 and says: References to definitions in the local module MAY use the prefix notation. But this doesn't currently apply to extensions, since they must have a prefix. There are two reasons for this: one is to keep the grammar simpler. An unprefixed keyword is always a YANG keyword. The other reason is to keep the YIN mapping simpler. In YIN, the extension MUST be namespace qualified, since the XML namespace for the extension is different than the namespace for the YANG keywords. We have two options: 1) allow local extensions to be used w/o a local prefix, and change the text in 6.3.1 to: When an imported extension is used, the extension's keyword must be qualified using the prefix with which the extension's module was imported. If an extension is used in the module where it is defined, the extension's keyword MAY be qualified with the module's prefix. or simply remove the text about prefixes in 6.3.1, and just keep the the general rule in 4.2.1 We must also change the YIN mapping rules so that a prefix is added in the YIN output, if needed. 2) keep the rule that extensions must have prefix, and change the text in 4,2.1 to: References to definitions in the local module MAY use the prefix notation, except for references to language extensions, which MUST use the prefix notation. and also change the text in 6.3.1 to: When an imported extension is used, the extension's keyword must be qualified using the prefix with which the extension's module was imported. If an extension is used in the module where it is defined, the extension's keyword MUST be qualified with the module's prefix. My personal preference is 2. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 21 13:12:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572D43A6783; Thu, 21 Aug 2008 13:12:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548933A68F5 for ; Thu, 21 Aug 2008 13:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR7UFT6uXXMh for ; Thu, 21 Aug 2008 13:12:16 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8F6A43A6783 for ; Thu, 21 Aug 2008 13:12:16 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 6029976C4D6; Thu, 21 Aug 2008 22:01:13 +0200 (CEST) Date: Thu, 21 Aug 2008 22:01:08 +0200 (CEST) Message-Id: <20080821.220108.45908310.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808211850.m7LIo0hN017834@idle.juniper.net> References: <20080821172422.GA21713@elstar.local> <200808211850.m7LIo0hN017834@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > (Sure, this is similar to types, which are defined with no > prefix but must have one when used, but it sure feels worse.) No, when you refer to a local type or grouping, you can omit the prefix. > >The only downside seems to be that expressions get slightly more > >verbose. To what extend is this really a problem? Do we have any idea > >how many local qnames our XPATH expressions will contain? I suspect most must expressions will NOT refer to external identifiers. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 02:21:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8681D3A6946; Fri, 22 Aug 2008 02:21:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FAB3A6872 for ; Fri, 22 Aug 2008 02:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzg9t-y0twv1 for ; Fri, 22 Aug 2008 02:13:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 844543A688B for ; Fri, 22 Aug 2008 02:13:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 121652129F for ; Fri, 22 Aug 2008 10:50:01 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-76-48ae7db802e3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ECA19201F3 for ; Fri, 22 Aug 2008 10:50:00 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 10:50:00 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 10:50:00 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 22 Aug 2008 10:49:59 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808221050.00096.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Aug 2008 08:50:00.0555 (UTC) FILETIME=[0FBBDBB0:01C90434] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] various defaults discussions (was Re: leaf encoding rules) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, (sorry if you get this more than once. it keeps bouncing...) This thread's morphed beyond "leaf encoding rules", so I changed the subject. Andy objected to: A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an for a or request, must be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value. saying that this is a NETCONF affair, not a NETMOD affair. This has subsequently turned into a discussion of - whether we're changing NETCONF operations or not, - whether leafs with defaults are part of the configuration datastore or not, - whether we could start standardizing with-defaults or not, - agent-selected defaults ('system-created') So, I'm confused again and am having trouble digesting all the various questions. Will it cover enough if we answer the following questions: 1. Should we have the paragraph above in the YANG spec or not? That is, should the YANG spec say anything at all about what a server might or might not send? 2. Should we try to get with-defaults taken up as a work item in NETCONF? 3. Should we add system-created? If these are the right questions, let's break them into separate threads, please. Are there other questions in this thread that need answering? Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 04:07:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5A13A68D2; Fri, 22 Aug 2008 04:07:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063303A698D for ; Fri, 22 Aug 2008 04:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUMmrbEkbG3G for ; Fri, 22 Aug 2008 04:00:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6D3C13A67CF for ; Fri, 22 Aug 2008 04:00:53 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 520FD20BCB for ; Fri, 22 Aug 2008 13:00:15 +0200 (CEST) X-AuditID: c1b4fb3c-b00d2bb0000015b5-60-48ae9c3fd340 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3AC9A204E5 for ; Fri, 22 Aug 2008 13:00:15 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 13:00:14 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 13:00:14 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 22 Aug 2008 13:00:14 +0200 User-Agent: KMail/1.9.9 References: <200808211051.11290.david.partain@ericsson.com> In-Reply-To: <200808211051.11290.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808221300.14324.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Aug 2008 11:00:14.0745 (UTC) FILETIME=[415AA090:01C90446] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, The thread "XPath expressions in must" (which starts at http://www.ietf.org/mail-archive/web/netmod/current/msg00624.html) included at least two issues. To me, one seems to have been resolved by replacing $this with current(). See http://www.ietf.org/mail-archive/web/netmod/current/msg00747.html The second was the claim that 'must' expressions will always have to have a namespace prefix in order to be compliant with XPath 1.0 and that YANG is therefore not compliant. My personal take on rough consensus is that it seems to be that YANG _does_ use an unmodified XPath 1.0. However, we have one remaining issue that I don't see resolved: Lada wrote: > The YANG draft says: > > "The null namespace is defined to be the namespace of the current > module". > > I understand this was an attempt to avoid the XPath requirement to write > explicit namespace prefixes but IMO it is not acceptable. It is the same > like defining empty set to contain something. Null namespace means NO > namespace. Martin suggested that the specification say "Elements without a namespace refer to nodes in the current module" and received very few comments on that suggestion (Phil liked it). So, the chairs request that the WG respond whether this change addresses the concerns Lada brought up or not. If you believe it does _NOT_ address the concerns, please suggest an alternate change that would. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 04:40:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222813A681D; Fri, 22 Aug 2008 04:40:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C993F3A681D for ; Fri, 22 Aug 2008 04:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWGXIk5WcL-H for ; Fri, 22 Aug 2008 04:40:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A68983A6803 for ; Fri, 22 Aug 2008 04:40:42 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18BB4C00DE; Fri, 22 Aug 2008 13:40:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t+BIDXbMuZ19; Fri, 22 Aug 2008 13:40:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 531CBC00D7; Fri, 22 Aug 2008 13:40:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95B5D69ADE7; Fri, 22 Aug 2008 13:40:45 +0200 (CEST) Date: Fri, 22 Aug 2008 13:40:45 +0200 From: Juergen Schoenwaelder To: David Partain Message-ID: <20080822114045.GA22613@elstar.local> Mail-Followup-To: David Partain , netmod@ietf.org References: <200808211051.11290.david.partain@ericsson.com> <200808221300.14324.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200808221300.14324.david.partain@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Aug 22, 2008 at 01:00:14PM +0200, David Partain wrote: > Martin suggested that the specification say "Elements without a namespace > refer to nodes in the current module" and received very few comments on that > suggestion (Phil liked it). Clarification: I think this implies that YANG translators have to transform expressions by adding the correct prefixes since outside the YANG context, prefixes are required. (Correct me if I am wrong.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 05:00:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3BD3A67EE; Fri, 22 Aug 2008 05:00:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC3C3A68A2 for ; Fri, 22 Aug 2008 04:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQgsAhvvgjsc for ; Fri, 22 Aug 2008 04:56:34 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 00E963A67E2 for ; Fri, 22 Aug 2008 04:56:33 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5A22D206E6; Fri, 22 Aug 2008 13:55:58 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-01-48aea94ee98b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3480F206A1; Fri, 22 Aug 2008 13:55:58 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 13:55:57 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 13:55:57 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 22 Aug 2008 13:55:57 +0200 User-Agent: KMail/1.9.9 References: <20080811.154837.65694432.mbj@tail-f.com> <48AD8756.5040500@netconfcentral.com> <20080821.215233.194872275.mbj@tail-f.com> In-Reply-To: <20080821.215233.194872275.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808221355.57311.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Aug 2008 11:55:57.0416 (UTC) FILETIME=[09BDBE80:01C9044E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] using a prefix with extensions (was Re: belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thursday 21 August 2008 21.52.33 Martin Bjorklund wrote: > Andy Bierman wrote: > > Balazs Lengyel wrote: > > > Hello, > > > The draft says in chapter 6.3.1. Language Extensions > > > "When an imported extension is used, the keyword must be qualified > > > using the prefix with which the extension's module was imported." The > > > text above seems to imply that only imported extensions need a prefix. > > > Please remove the word imported. > > > > I think you are right. > > > > If I want to define my own 'foo:leaf' clause, then of course > > I have to use foo:leaf, even in the foo module. > > If I just use 'leaf' in the foo module, then > > the YANG keyword wins, and 'foo:leaf' will not be checked. > > This would not be the case if the extension name > > did not conflict. (foo:my-leaf <--> my-leaf no problem). > > > > For consistency, an extension should always be used with a prefix. > > But I don't know if a special CLR is needed. The same issues > > apply to any imported symbol. > > Actually, there are two issues here, The general rule is defined in > 4.2.1 and says: > > References to definitions in the local module MAY use > the prefix notation. > > But this doesn't currently apply to extensions, since they must have a > prefix. There are two reasons for this: one is to keep the grammar > simpler. An unprefixed keyword is always a YANG keyword. The other > reason is to keep the YIN mapping simpler. In YIN, the extension MUST > be namespace qualified, since the XML namespace for the extension is > different than the namespace for the YANG keywords. > > We have two options: > > 1) allow local extensions to be used w/o a local prefix, and change > the text in 6.3.1 to: > > When an imported extension is used, the extension's keyword must > be qualified using the prefix with which the extension's module > was imported. If an extension is used in the module where it is > defined, the extension's keyword MAY be qualified with the > module's prefix. > > or simply remove the text about prefixes in 6.3.1, and just keep > the the general rule in 4.2.1 > > We must also change the YIN mapping rules so that a prefix is > added in the YIN output, if needed. > > 2) keep the rule that extensions must have prefix, and change the > text in 4,2.1 to: > > References to definitions in the local module MAY use > the prefix notation, except for references to language > extensions, which MUST use the prefix notation. > > and also change the text in 6.3.1 to: > > When an imported extension is used, the extension's keyword must > be qualified using the prefix with which the extension's module > was imported. If an extension is used in the module where it is > defined, the extension's keyword MUST be qualified with the > module's prefix. > > My personal preference is 2. Seems good to me. David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 05:32:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64713A6A7E; Fri, 22 Aug 2008 05:28:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4F428C0EF for ; Fri, 22 Aug 2008 05:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crktOxvUgyZG for ; Fri, 22 Aug 2008 05:16:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0768828C2E3 for ; Fri, 22 Aug 2008 05:16:32 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 007C5D800CB; Fri, 22 Aug 2008 14:16:11 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080822114045.GA22613@elstar.local> References: <200808211051.11290.david.partain@ericsson.com> <200808221300.14324.david.partain@ericsson.com> <20080822114045.GA22613@elstar.local> Organization: CESNET Date: Fri, 22 Aug 2008 14:16:12 +0200 Message-Id: <1219407372.6710.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFDDoSAyMi4gMDguIDIwMDggdiAxMzo0MCAr MDIwMDoKPiBPbiBGcmksIEF1ZyAyMiwgMjAwOCBhdCAwMTowMDoxNFBNICswMjAwLCBEYXZpZCBQ YXJ0YWluIHdyb3RlOgo+IAo+ID4gTWFydGluIHN1Z2dlc3RlZCB0aGF0IHRoZSBzcGVjaWZpY2F0 aW9uIHNheSAiRWxlbWVudHMgd2l0aG91dCBhIG5hbWVzcGFjZQo+ID4gcmVmZXIgdG8gbm9kZXMg aW4gdGhlIGN1cnJlbnQgbW9kdWxlIiBhbmQgcmVjZWl2ZWQgdmVyeSBmZXcgY29tbWVudHMgb24g dGhhdCAKPiA+IHN1Z2dlc3Rpb24gKFBoaWwgbGlrZWQgaXQpLgo+IAo+IENsYXJpZmljYXRpb246 IEkgdGhpbmsgdGhpcyBpbXBsaWVzIHRoYXQgWUFORyB0cmFuc2xhdG9ycyBoYXZlIHRvCj4gdHJh bnNmb3JtIGV4cHJlc3Npb25zIGJ5IGFkZGluZyB0aGUgY29ycmVjdCBwcmVmaXhlcyBzaW5jZSBv dXRzaWRlIHRoZQo+IFlBTkcgY29udGV4dCwgcHJlZml4ZXMgYXJlIHJlcXVpcmVkLiAoQ29ycmVj dCBtZSBpZiBJIGFtIHdyb25nLikKClRoYXQgd291bGQgYmUgYSBuZWNlc3Nhcnkgd29ya2Fyb3Vu ZCBhbmQgdGhlIHRyYW5zbGF0b3Igd291bGQgYWxzbyBoYXZlCnRvIHBhcnNlIHRoZSBleHByZXNz aW9ucy4gSG93ZXZlciwgSSB0aGluayBpdCdzIGFsc28gYSBwcm9ibGVtIGZvciBZQU5HCml0c2Vs ZiB0byBjYWxsIHNvbWV0aGluZyBYUGF0aCAxLjAgaWYgdGhlIHNlbWFudGljcyBvZiB0aGUgZXhw cmVzc2lvbnMKaXMgZGlmZmVyZW50IGZyb20gd2hhdCB0aGUgWFBhdGggMS4wIHNwZWMgc2F5cy4K ClBlcmhhcHMgd2Ugc2hvdWxkIGxvb2sgYXQgWFBhdGggMi4wIGFmdGVyIGFsbC4KCkxhZGEKCj4g Cj4gL2pzCj4gCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMw QwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9k IG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri Aug 22 06:07:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37173A6AEF; Fri, 22 Aug 2008 06:07:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C8D28C361 for ; Fri, 22 Aug 2008 05:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiJlwjb8hSVU for ; Fri, 22 Aug 2008 05:42:21 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 326F928C35B for ; Fri, 22 Aug 2008 05:42:21 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 05:37:54 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:37:40 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:37:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 05:36:16 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7MCaFu11267; Fri, 22 Aug 2008 05:36:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MCWkVm027131; Fri, 22 Aug 2008 12:32:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221232.m7MCWkVm027131@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080822114045.GA22613@elstar.local> Date: Fri, 22 Aug 2008 08:32:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 12:36:16.0339 (UTC) FILETIME=[AB881A30:01C90453] Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >Clarification: I think this implies that YANG translators have to >transform expressions by adding the correct prefixes since outside the >YANG context, prefixes are required. (Correct me if I am wrong.) Yes, tools would need to rewrite XPath expressions to add prefixes. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 06:07:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE24A3A6ABD; Fri, 22 Aug 2008 06:07:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A03C28C359 for ; Fri, 22 Aug 2008 05:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88BEscb5f6UM for ; Fri, 22 Aug 2008 05:42:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4FA8228C354 for ; Fri, 22 Aug 2008 05:42:08 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DE835210D3; Fri, 22 Aug 2008 14:41:32 +0200 (CEST) X-AuditID: c1b4fb3e-a6680bb000007a96-a0-48aeb3fc2f86 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C350D2027E; Fri, 22 Aug 2008 14:41:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 14:41:32 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 14:41:32 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 22 Aug 2008 14:41:31 +0200 User-Agent: KMail/1.9.9 References: <48AADB9C.7030209@netconfcentral.com> <1219257732.6367.53.camel@missotis> <20080821.093552.122461371.mbj@tail-f.com> In-Reply-To: <20080821.093552.122461371.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808221441.32102.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Aug 2008 12:41:32.0162 (UTC) FILETIME=[67C6DE20:01C90454] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus on yang: multiple pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings all, >From the discussion in this thread (which starts at http://www.ietf.org/mail-archive/web/netmod/current/msg00605.html), the chairs believe that we have rough consensus to change the YANG specification to allow multiple patterns and assume that XSD mappings will have to deal with this by using extra anonymous types (as shown in message http://www.ietf.org/mail-archive/web/netmod/current/msg00836.html). If you disagree that this is an accurate assessment of rough consensus, please speak up. Cheers, David^2 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 06:07:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D596A3A6B60; Fri, 22 Aug 2008 06:07:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443E43A67AE for ; Fri, 22 Aug 2008 05:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLsURHjfxSKF for ; Fri, 22 Aug 2008 05:49:14 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 5BD3828C368 for ; Fri, 22 Aug 2008 05:49:14 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 05:48:42 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:45:56 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:45:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:45:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7MCjhu14766; Fri, 22 Aug 2008 05:45:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MCgDTw027239; Fri, 22 Aug 2008 12:42:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221242.m7MCgDTw027239@idle.juniper.net> To: David Partain In-reply-to: <200808221050.00096.david.partain@ericsson.com> Date: Fri, 22 Aug 2008 08:42:13 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 12:45:56.0094 (UTC) FILETIME=[0517B1E0:01C90455] Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions (was Re: leaf encoding rules) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain writes: >1. Should we have the paragraph above in the YANG spec or not? That is, >should the YANG spec say anything at all about what a server might or might >not send? >2. Should we try to get with-defaults taken up as a work item in NETCONF? >3. Should we add system-created? There was also Balazs' question about complex defaults, where the default value exists but can't be statically known. And "write once" data, where the value can be assigned by not changed. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 06:07:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB2F3A6B75; Fri, 22 Aug 2008 06:07:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F703A6A6A for ; Fri, 22 Aug 2008 05:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuEsGSig5TWj for ; Fri, 22 Aug 2008 05:52:54 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 995B63A6814 for ; Fri, 22 Aug 2008 05:52:52 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 05:51:34 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:51:08 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:51:07 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 05:51:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7MComu16374; Fri, 22 Aug 2008 05:50:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MCknX6027271; Fri, 22 Aug 2008 12:46:49 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221246.m7MCknX6027271@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080821.215233.194872275.mbj@tail-f.com> Date: Fri, 22 Aug 2008 08:46:49 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 12:51:29.0772 (UTC) FILETIME=[CBFAEAC0:01C90455] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >But this doesn't currently apply to extensions, since they must have a >prefix. There are two reasons for this: one is to keep the grammar >simpler. An unprefixed keyword is always a YANG keyword. The other >reason is to keep the YIN mapping simpler. In YIN, the extension MUST >be namespace qualified, since the XML namespace for the extension is >different than the namespace for the YANG keywords. Don't these reasons apply equally to types: module foo { type int32 { ... } leaf f { type int32; } } Is "f" foo:int32 or the real YANG int32? > 1) allow local extensions to be used w/o a local prefix, and change > the text in 6.3.1 to: This would be disturbing to the reader. Non-builtins that can appear where builtins appear should be easy for the reader to distinquish and not ambiguous. > When an imported extension is used, the extension's keyword must > be qualified using the prefix with which the extension's module > was imported. If an extension is used in the module where it is > defined, the extension's keyword MUST be qualified with the > module's prefix. Sounds good, but we should add types to this also. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 06:35:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DB73A6A81; Fri, 22 Aug 2008 06:35:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332BC3A6A85 for ; Fri, 22 Aug 2008 06:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0hRMHRahG-a for ; Fri, 22 Aug 2008 06:27:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 38F473A68C5 for ; Fri, 22 Aug 2008 06:27:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 041BDC00D7; Fri, 22 Aug 2008 15:26:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id erOKCUymFfdB; Fri, 22 Aug 2008 15:26:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FE41C00E7; Fri, 22 Aug 2008 15:26:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7CBD669B2D2; Fri, 22 Aug 2008 15:26:20 +0200 (CEST) Date: Fri, 22 Aug 2008 15:26:20 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080822132620.GA23158@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20080821.215233.194872275.mbj@tail-f.com> <200808221246.m7MCknX6027271@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200808221246.m7MCknX6027271@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Aug 22, 2008 at 08:46:49AM -0400, Phil Shafer wrote: > >But this doesn't currently apply to extensions, since they must have a > >prefix. There are two reasons for this: one is to keep the grammar > >simpler. An unprefixed keyword is always a YANG keyword. The other > >reason is to keep the YIN mapping simpler. In YIN, the extension MUST > >be namespace qualified, since the XML namespace for the extension is > >different than the namespace for the YANG keywords. > > Don't these reasons apply equally to types: > > module foo { > type int32 { ... } > leaf f { type int32; } > } > > Is "f" foo:int32 or the real YANG int32? The set of builtin types is small and likely to stay stable and that is why we decided the last time we discussed this (before there was a WG) that it is OK to not require prefixes on types. This does not mean we have to reach the same conclusion this time of course. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 07:37:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DC23A6A42; Fri, 22 Aug 2008 07:37:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9579A28C184 for ; Fri, 22 Aug 2008 07:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVhZGFKQpinM for ; Fri, 22 Aug 2008 07:23:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B0DBD3A6989 for ; Fri, 22 Aug 2008 07:23:38 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7B4D5D800D0; Fri, 22 Aug 2008 15:51:36 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080821.215233.194872275.mbj@tail-f.com> References: <20080811.154837.65694432.mbj@tail-f.com> <48AD7CD1.2080501@ericsson.com> <48AD8756.5040500@netconfcentral.com> <20080821.215233.194872275.mbj@tail-f.com> Organization: CESNET Date: Fri, 22 Aug 2008 15:51:36 +0200 Message-Id: <1219413096.6710.41.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMjEuIDA4LiAyMDA4IHYgMjE6NTIgKzAyMDA6 Cj4gQWN0dWFsbHksIHRoZXJlIGFyZSB0d28gaXNzdWVzIGhlcmUsICBUaGUgZ2VuZXJhbCBydWxl IGlzIGRlZmluZWQgaW4KPiA0LjIuMSBhbmQgc2F5czoKPiAKPiAgIFJlZmVyZW5jZXMgdG8gZGVm aW5pdGlvbnMgaW4gdGhlIGxvY2FsIG1vZHVsZSBNQVkgdXNlCj4gICB0aGUgcHJlZml4IG5vdGF0 aW9uLgo+IAo+IEJ1dCB0aGlzIGRvZXNuJ3QgY3VycmVudGx5IGFwcGx5IHRvIGV4dGVuc2lvbnMs IHNpbmNlIHRoZXkgbXVzdCBoYXZlIGEKPiBwcmVmaXguICBUaGVyZSBhcmUgdHdvIHJlYXNvbnMg Zm9yIHRoaXM6IG9uZSBpcyB0byBrZWVwIHRoZSBncmFtbWFyCj4gc2ltcGxlci4gIEFuIHVucHJl Zml4ZWQga2V5d29yZCBpcyBhbHdheXMgYSBZQU5HIGtleXdvcmQuICBUaGUgb3RoZXIKPiByZWFz b24gaXMgdG8ga2VlcCB0aGUgWUlOIG1hcHBpbmcgc2ltcGxlci4gIEluIFlJTiwgdGhlIGV4dGVu c2lvbiBNVVNUCj4gYmUgbmFtZXNwYWNlIHF1YWxpZmllZCwgc2luY2UgdGhlIFhNTCBuYW1lc3Bh Y2UgZm9yIHRoZSBleHRlbnNpb24gaXMKPiBkaWZmZXJlbnQgdGhhbiB0aGUgbmFtZXNwYWNlIGZv ciB0aGUgWUFORyBrZXl3b3Jkcy4KPiAKCkJ1dCBJIHRoaW5rIHRoZSBtYWluIHJlYXNvbiBpcyB0 aGF0IFlBTkcvWUlOIGtleXdvcmRzIGFyZSBpbiB0aGUKInVybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzoxIiBvciAidXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOnlpbjoxIgpuYW1lc3BhY2Ug d2hlcmVhcyB0aGUgZXh0ZW5zaW9uIGtleXdvcmQgaXMgaW4gdGhlIG5hbWVzcGFjZSBvZiB0aGUK bW9kdWxlIHRoYXQgZGVmaW5lcyBpdC4KClNvIElNTyBpdCBpcyBwcm9wZXIgdG8gcmVxdWlyZSB0 aGUgZXh0ZW5zaW9uIGtleXdvcmRzIHRvIGFsd2F5cyBjYXJyeQp0aGUgcHJlZml4LgoKTGFkYQoK LS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Fri Aug 22 07:37:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213713A6A89; Fri, 22 Aug 2008 07:37:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4A33A6965 for ; Fri, 22 Aug 2008 07:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOxkyvOzTlXl for ; Fri, 22 Aug 2008 07:29:49 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4A4BA3A67D1 for ; Fri, 22 Aug 2008 07:29:49 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF8A6201DC; Fri, 22 Aug 2008 16:00:05 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-c0-48aec66524dc Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C1FBA20125; Fri, 22 Aug 2008 16:00:05 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 16:00:05 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 16:00:05 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org, j.schoenwaelder@jacobs-university.de Date: Fri, 22 Aug 2008 16:00:04 +0200 User-Agent: KMail/1.9.9 References: <20080821.215233.194872275.mbj@tail-f.com> <200808221246.m7MCknX6027271@idle.juniper.net> <20080822132620.GA23158@elstar.local> In-Reply-To: <20080822132620.GA23158@elstar.local> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808221600.05099.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Aug 2008 14:00:05.0069 (UTC) FILETIME=[60E367D0:01C9045F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Friday 22 August 2008 15.26.20 Juergen Schoenwaelder wrote: > On Fri, Aug 22, 2008 at 08:46:49AM -0400, Phil Shafer wrote: > > >But this doesn't currently apply to extensions, since they must have a > > >prefix. There are two reasons for this: one is to keep the grammar > > >simpler. An unprefixed keyword is always a YANG keyword. The other > > >reason is to keep the YIN mapping simpler. In YIN, the extension MUST > > >be namespace qualified, since the XML namespace for the extension is > > >different than the namespace for the YANG keywords. > > > > Don't these reasons apply equally to types: > > > > module foo { > > type int32 { ... } > > leaf f { type int32; } > > } > > > > Is "f" foo:int32 or the real YANG int32? > > The set of builtin types is small and likely to stay stable and that > is why we decided the last time we discussed this (before there was a > WG) that it is OK to not require prefixes on types. This does not mean > we have to reach the same conclusion this time of course. ;-) Hi, Contributor hat. I think we should reach the same conclusion... the less clutter, the better. David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 10:40:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DBE3A6981; Fri, 22 Aug 2008 10:40:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7413A677D for ; Fri, 22 Aug 2008 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta+6S91jah8H for ; Fri, 22 Aug 2008 10:40:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 409463A67A5 for ; Fri, 22 Aug 2008 10:40:03 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 037F0207BF; Fri, 22 Aug 2008 19:39:17 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-91-48aef9c4e962 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DA58C20059; Fri, 22 Aug 2008 19:39:16 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 19:39:16 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 19:39:16 +0200 Message-ID: <48AEF96F.2090001@ericsson.com> Date: Fri, 22 Aug 2008 19:37:51 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <20080821.215233.194872275.mbj@tail-f.com> <200808221246.m7MCknX6027271@idle.juniper.net> <20080822132620.GA23158@elstar.local> <200808221600.05099.david.partain@ericsson.com> In-Reply-To: <200808221600.05099.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Aug 2008 17:39:16.0627 (UTC) FILETIME=[FFD3E630:01C9047D] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, +1 I don't want mandatory prefixes for local defined types. We sad readability is the big bonus for YANG, so cluttering all the stuff with prefixes would be ugly. Extensions are a rarer sort of animal, so asking for prefixing there is not that bad. I agree with martin we should keep it (although we could live with optional prefixing as well.) Balazs David Partain wrote: > On Friday 22 August 2008 15.26.20 Juergen Schoenwaelder wrote: >> On Fri, Aug 22, 2008 at 08:46:49AM -0400, Phil Shafer wrote: >>>> But this doesn't currently apply to extensions, since they must have a >>>> prefix. There are two reasons for this: one is to keep the grammar >>>> simpler. An unprefixed keyword is always a YANG keyword. The other >>>> reason is to keep the YIN mapping simpler. In YIN, the extension MUST >>>> be namespace qualified, since the XML namespace for the extension is >>>> different than the namespace for the YANG keywords. >>> Don't these reasons apply equally to types: >>> >>> module foo { >>> type int32 { ... } >>> leaf f { type int32; } >>> } >>> >>> Is "f" foo:int32 or the real YANG int32? >> The set of builtin types is small and likely to stay stable and that >> is why we decided the last time we discussed this (before there was a >> WG) that it is OK to not require prefixes on types. This does not mean >> we have to reach the same conclusion this time of course. ;-) > > Hi, > > Contributor hat. > > I think we should reach the same conclusion... the less clutter, the better. > > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 12:43:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2039E28C172; Fri, 22 Aug 2008 12:43:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588D728C18E for ; Fri, 22 Aug 2008 12:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bihe1JizjgHB for ; Fri, 22 Aug 2008 12:43:19 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 4FACC28C174 for ; Fri, 22 Aug 2008 12:43:08 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 12:42:00 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 12:31:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 12:31:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 12:31:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7MJVju96854; Fri, 22 Aug 2008 12:31:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MJSFPi031166; Fri, 22 Aug 2008 19:28:16 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221928.m7MJSFPi031166@idle.juniper.net> To: Andy Bierman In-reply-to: <48AEDD7E.90307@netconfcentral.com> Date: Fri, 22 Aug 2008 15:28:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 19:31:46.0532 (UTC) FILETIME=[B715AA40:01C9048D] Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >In the example above, the type is the YANG int32. >If you do something dumb (which I think is not allowed >anyway) like reusing the names of built-in types, >then you need to use the prefix on that type, >because the YANG built-in type names take precedence. Juergen was right. We pitched the idea of adding new builtin types in the future. Without this, there's no need to require a prefix, since they will never be a conflict. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 12:50:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EAAA28C1AB; Fri, 22 Aug 2008 12:50:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A3128C1AE for ; Fri, 22 Aug 2008 12:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFRhJBbL+R-x for ; Fri, 22 Aug 2008 12:50:06 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 2272028C1AB for ; Fri, 22 Aug 2008 12:50:05 -0700 (PDT) Received: (qmail 39960 invoked from network); 22 Aug 2008 19:49:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 22 Aug 2008 19:49:48 -0000 X-YMail-OSG: dUXD1UQVM1k3ZIRi.SiJX0gw3HlKyjFrfuF3mfL0OmTye9a1v3pRq7NM71XoA7KRDBkk6Ch8VB0wrovjmBm.s8U_v383Vkdrp9RanS1KPg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AF185A.8050200@netconfcentral.com> Date: Fri, 22 Aug 2008 12:49:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808221928.m7MJSFPi031166@idle.juniper.net> In-Reply-To: <200808221928.m7MJSFPi031166@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] belongs-to X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> In the example above, the type is the YANG int32. >> If you do something dumb (which I think is not allowed >> anyway) like reusing the names of built-in types, >> then you need to use the prefix on that type, >> because the YANG built-in type names take precedence. > > Juergen was right. We pitched the idea of adding new builtin types > in the future. Without this, there's no need to require a prefix, > since they will never be a conflict. > there is also the yang-version statement available to avoid any conflict in the future. the only changes to the SMI were to add 64 bit numbers. YANG already has 64 bit numbers and floating point. If I see a prefix, that means the definition came from a YANG module. No module actually contains int32 (or any built-in type), so why invent some hack prefix value that means 'the non-existent YANG built-in types module'? I actually do not see a problem with YANG defining its own context for prefix handling, within a YANG file. But within straight XML (YIN, XSLT, NETCONF PDU), the tool must generate prefixes according to the rules for that context. A missing prefix is just one corner case out of several. > Thanks, > Phil > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 22 13:14:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918DF28C122; Fri, 22 Aug 2008 13:14:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF5728C122 for ; Fri, 22 Aug 2008 13:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBsxl5xxxePT for ; Fri, 22 Aug 2008 13:14:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B3D993A697B for ; Fri, 22 Aug 2008 13:14:43 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6905220488 for ; Fri, 22 Aug 2008 22:13:52 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-78-48af1e00a0c6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 50CDB20024 for ; Fri, 22 Aug 2008 22:13:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 22:13:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 22:13:51 +0200 Message-ID: <48AF1DAB.6080500@ericsson.com> Date: Fri, 22 Aug 2008 22:12:27 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200808221050.00096.david.partain@ericsson.com> In-Reply-To: <200808221050.00096.david.partain@ericsson.com> X-OriginalArrivalTime: 22 Aug 2008 20:13:51.0614 (UTC) FILETIME=[982699E0:01C90493] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions (was Re: leaf encoding rules) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Hi, > > (sorry if you get this more than once. it keeps bouncing...) > > This thread's morphed beyond "leaf encoding rules", so I changed the subject. > > Andy objected to: > > A NETCONF server that replies to a or request MAY > choose not to send the leaf element if its value is the default > value. Thus, a client that receives an for a or > request, must be prepared to handle the case that a leaf > node with a default value is not present in the XML. In this case, > the value used by the server is known to be the default value. > > saying that this is a NETCONF affair, not a NETMOD affair. > > This has subsequently turned into a discussion of > - whether we're changing NETCONF operations or not, > - whether leafs with defaults are part of the configuration datastore or not, > - whether we could start standardizing with-defaults or not, > - agent-selected defaults ('system-created') > > So, I'm confused again and am having trouble digesting all the various > questions. > > Will it cover enough if we answer the following questions: > > 1. Should we have the paragraph above in the YANG spec or not? That is, > should the YANG spec say anything at all about what a server might or might > not send? BALAZS: Netmod should state whether a leaf not set but having a YANG default is or os not part of the conceptual data-store. Once we have this settled we can start answering questions like: - should defaults come back in get/get-config - use with-defaults - should must consider defaults - usually yes, but what if we are testing for the existence of the leaf in a must? will it give back true or false - should a conditional augment (when) consider defaults (yes) - how should existence tests for edit-config delete, create handle a default leaf - depends on the answer to the main question > 2. Should we try to get with-defaults taken up as a work item in NETCONF? BALAZS: Yes > 3. Should we add system-created? > > If these are the right questions, let's break them into separate threads, > please. Are there other questions in this thread that need answering? > > Cheers, > > David > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 23 02:05:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F823A6B56; Sat, 23 Aug 2008 02:05:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F52A3A6BA9 for ; Sat, 23 Aug 2008 02:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtXxOVaM2vhL for ; Sat, 23 Aug 2008 02:05:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 12B983A6BAA for ; Sat, 23 Aug 2008 02:05:14 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 70E1F76C4C8; Sat, 23 Aug 2008 11:04:54 +0200 (CEST) Date: Sat, 23 Aug 2008 11:04:53 +0200 (CEST) Message-Id: <20080823.110453.118380885.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080822114045.GA22613@elstar.local> References: <200808211051.11290.david.partain@ericsson.com> <200808221300.14324.david.partain@ericsson.com> <20080822114045.GA22613@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Aug 22, 2008 at 01:00:14PM +0200, David Partain wrote: > > > Martin suggested that the specification say "Elements without a namespace > > refer to nodes in the current module" and received very few comments on that > > suggestion (Phil liked it). > > Clarification: I think this implies that YANG translators have to > transform expressions by adding the correct prefixes since outside the > YANG context, prefixes are required. (Correct me if I am wrong.) Note that YANG does not reqiure an implementaton of XPath at all. An implementation is free to code the restrictions by hand. But if you have a proper XPath implementation, yes, then you will have to translate prefixes. You can never just use all must expressions as they are written in the modules, since all prefixes are local to each module, so you might have the prefix 'foo' map to different XML namespaces in different modules: module a { prefix foo; leaf y { type int32; } must "/foo:x == 42"; } module b { prefix foo; leaf y { type int32; } must "/foo:y == 4668"; } If you have your data as an XML instance document, you will also have to add whaterver root node you have in your XML instance document. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 23 02:55:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7524D28C14D; Sat, 23 Aug 2008 02:55:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45D13A6BF1 for ; Sat, 23 Aug 2008 02:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjOgxO6qK2Te for ; Sat, 23 Aug 2008 02:55:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EE3113A6BCD for ; Sat, 23 Aug 2008 02:55:18 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 9037C76C4C8; Sat, 23 Aug 2008 11:55:02 +0200 (CEST) Date: Sat, 23 Aug 2008 11:55:01 +0200 (CEST) Message-Id: <20080823.115501.104471813.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48AF1DAB.6080500@ericsson.com> References: <200808221050.00096.david.partain@ericsson.com> <48AF1DAB.6080500@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > > > David Partain wrote: > > Hi, > > (sorry if you get this more than once. it keeps bouncing...) > > This thread's morphed beyond "leaf encoding rules", so I changed the subject. > > Andy objected to: > > A NETCONF server that replies to a or request MAY > > choose not to send the leaf element if its value is the default > > value. Thus, a client that receives an for a or > > request, must be prepared to handle the case that a leaf > > node with a default value is not present in the XML. In this case, > > the value used by the server is known to be the default value. > > saying that this is a NETCONF affair, not a NETMOD affair. > > This has subsequently turned into a discussion of - whether we're > > changing NETCONF operations or not, > > - whether leafs with defaults are part of the configuration datastore or not, > > - whether we could start standardizing with-defaults or not, - > > agent-selected defaults ('system-created') > > So, I'm confused again and am having trouble digesting all the > > various questions. > > Will it cover enough if we answer the following questions: > > 1. Should we have the paragraph above in the YANG spec or not? > > That is, should the YANG spec say anything at all about what a > > server might or might not send? > > BALAZS: Netmod should state whether a leaf not set but having a YANG > default is or os not part of the conceptual data-store. Currently the spec specifies that defaults are not part of the conceptual data store. But not the word conceptual. This does *not* preclude an implementation to store the default in their database. > Once we have > this settled we can start answering questions like: > - should defaults come back in get/get-config - use with-defaults The current text allows for a capability like with-defaults, and also it allows for implementations to have different values for 'with-default-default'. > - should must consider defaults - usually yes, Yes. > but what if we are > testing for the existence of the leaf in a must? will it give back > true or false true. > - should a conditional augment (when) consider defaults (yes) yes. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 23 06:25:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD933A6A60; Sat, 23 Aug 2008 06:25:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF8C3A68E4 for ; Sat, 23 Aug 2008 06:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b258Dp8c7REt for ; Sat, 23 Aug 2008 06:25:09 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 83A513A69F4 for ; Sat, 23 Aug 2008 06:25:09 -0700 (PDT) Received: (qmail 46565 invoked from network); 23 Aug 2008 13:25:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 23 Aug 2008 13:25:10 -0000 X-YMail-OSG: 1f_wetoVM1l52SR8j9UL2DvTctc9dXylFDN75qwBBK7UEzE0zEvEJOUqbL689UimowVMsdxmKG2Mh4SPlFlV5VOgApYjN1t_uj9UEUZhCPOL1SToJ.s2RlB6sHpa7qI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B00FB4.8020502@netconfcentral.com> Date: Sat, 23 Aug 2008 06:25:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200808211051.11290.david.partain@ericsson.com> <200808221300.14324.david.partain@ericsson.com> <20080822114045.GA22613@elstar.local> <20080823.110453.118380885.mbj@tail-f.com> In-Reply-To: <20080823.110453.118380885.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Fri, Aug 22, 2008 at 01:00:14PM +0200, David Partain wrote: >> >>> Martin suggested that the specification say "Elements without a namespace >>> refer to nodes in the current module" and received very few comments on that >>> suggestion (Phil liked it). >> Clarification: I think this implies that YANG translators have to >> transform expressions by adding the correct prefixes since outside the >> YANG context, prefixes are required. (Correct me if I am wrong.) > > Note that YANG does not reqiure an implementaton of XPath at all. An > implementation is free to code the restrictions by hand. > But a YANG to YIN or YANG to DSDL translator does need to deal with prefix conversion. Clearly the 'no prefix==local module' rule only applies within a YANG file, not YIN, not XML or any kind. > But if you have a proper XPath implementation, yes, then you will have > to translate prefixes. You can never just use all must expressions as > they are written in the modules, since all prefixes are local to each > module, so you might have the prefix 'foo' map to different XML > namespaces in different modules: > > module a { > prefix foo; > > leaf y { type int32; } > must "/foo:x == 42"; > } > > module b { > prefix foo; > > leaf y { type int32; } > must "/foo:y == 4668"; > } > > If you have your data as an XML instance document, you will also have > to add whaterver root node you have in your XML instance document. > > > > /martin > ____ Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 23 06:37:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5003A68F0; Sat, 23 Aug 2008 06:37:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84703A69D3 for ; Sat, 23 Aug 2008 06:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsTf6QFlOaJH for ; Sat, 23 Aug 2008 06:37:06 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id C14123A68F0 for ; Sat, 23 Aug 2008 06:37:06 -0700 (PDT) Received: (qmail 11505 invoked from network); 23 Aug 2008 13:36:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 23 Aug 2008 13:36:41 -0000 X-YMail-OSG: CwNkP64VM1l.euFnN5qaQjQPrtaxlF5faL2O30HZvv2CJLXN.ZT6kdbjMlGhz1.5_Jzh5W43jWjK5pm1kYWC14.rl8CYCOvXLc6MqedFfzCwwzP3jBvbAnT6GejPbcs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B01267.8000305@netconfcentral.com> Date: Sat, 23 Aug 2008 06:36:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200808221050.00096.david.partain@ericsson.com> <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> In-Reply-To: <20080823.115501.104471813.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Balazs Lengyel wrote: >> 7.5.2. The must Statement The "must" statement, which is optional, takes as an argument a string which contains an XPath expression. It is used to formally declare a constraint on the configuration data. When a configuration datastore is validated, all "must" constraints are conceptually evaluated once for each corresponding instance in the datastore's data tree, and for all leafs with default values in effect. This text clearly says the defaults exist for the purpose of must-stmt evaluation. IMO, this text should be clarified to say 'all agent-created configuration nodes'. OLD: o The accessible tree is made up of all nodes in the data tree, and all leafs with default values. NEW: o The accessible tree is made up of all nodes in the data tree, and all leafs with agent-supplied values. 7.6.5. XML Encoding Rules A leaf node is encoded as an XML element. The element's name is the leaf's identifier, and its XML namespace is the module's XML namespace. The value of the leaf node is encoded to XML according to the type, and sent as character data in the element. A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an for a or request, must be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value. As I noted before, I strongly object para 3 above, because it changes NETCONF protocol behavior. Also, the last sentence is wrong. A missing node could mean it was filtered by access control. It could mean there is no node at all. It could mean there is an agent-supplied value. It will be harmful to interoperability to assume a missing node has a YANG specified default value. Andy >> David Partain wrote: >>> Hi, >>> (sorry if you get this more than once. it keeps bouncing...) >>> This thread's morphed beyond "leaf encoding rules", so I changed the subject. >>> Andy objected to: >>> A NETCONF server that replies to a or request MAY >>> choose not to send the leaf element if its value is the default >>> value. Thus, a client that receives an for a or >>> request, must be prepared to handle the case that a leaf >>> node with a default value is not present in the XML. In this case, >>> the value used by the server is known to be the default value. >>> saying that this is a NETCONF affair, not a NETMOD affair. >>> This has subsequently turned into a discussion of - whether we're >>> changing NETCONF operations or not, >>> - whether leafs with defaults are part of the configuration datastore or not, >>> - whether we could start standardizing with-defaults or not, - >>> agent-selected defaults ('system-created') >>> So, I'm confused again and am having trouble digesting all the >>> various questions. >>> Will it cover enough if we answer the following questions: >>> 1. Should we have the paragraph above in the YANG spec or not? >>> That is, should the YANG spec say anything at all about what a >>> server might or might not send? >> BALAZS: Netmod should state whether a leaf not set but having a YANG >> default is or os not part of the conceptual data-store. > > Currently the spec specifies that defaults are not part of the > conceptual data store. But not the word conceptual. This does *not* > preclude an implementation to store the default in their database. > > >> Once we have >> this settled we can start answering questions like: >> - should defaults come back in get/get-config - use with-defaults > > The current text allows for a capability like with-defaults, and also > it allows for implementations to have different values for > 'with-default-default'. > >> - should must consider defaults - usually yes, > > Yes. > >> but what if we are >> testing for the existence of the leaf in a must? will it give back >> true or false > > true. > >> - should a conditional augment (when) consider defaults (yes) > > yes. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 23 07:02:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D9C3A6B8D; Sat, 23 Aug 2008 07:02:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C083A6A77 for ; Sat, 23 Aug 2008 07:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7o1KopxrhhH for ; Sat, 23 Aug 2008 07:02:01 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 411FC3A6BAF for ; Sat, 23 Aug 2008 07:01:56 -0700 (PDT) Received: (qmail 46295 invoked from network); 23 Aug 2008 14:02:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 23 Aug 2008 14:02:05 -0000 X-YMail-OSG: nSpMNYIVM1koFH07RFDHYjCPgctzfAgkAnwTzKg6LMNH2ibnTXBqdPC8Yt.fex6BtMi_.ymsHoOqF_9VyWZdjExj9JyKsJLeLU9mnlwEdA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B0185B.6080907@netconfcentral.com> Date: Sat, 23 Aug 2008 07:02:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] defaults and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Here is Martin's recent example: module a { prefix foo; leaf y { type int32; } must "/foo:x == 42"; } module b { prefix foo; leaf y { type int32; } must "/foo:y == 4668"; } This is not valid YANG, so I will change it a bit to make my point; module a { namespace a; prefix foo; leaf x { type int32; must "/foo:x = 42 and /foo:z = 17"; } leaf z { type int32 { default 17; } } } module b { namespace b; prefix foo; import a { prefix a; } leaf y { type int32; must "/foo:y = 4668 and /a:x >= 17"; } } The manager gets back a without any agent-supplied defaults and it is useless for offline must-stmt evaluation: 4668 The manager needs to use the TBD 'with-defaults' in order to receive the same XML that passed the validation test on the agent: 42 17 4668 IMO, it is OK for YANG to leave defaults out only if the NETCONF protocol is extended (e.g., with-defaults) to compensate. If not, then YANG must not hide the agent-supplied nodes. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 23 08:38:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723503A6958; Sat, 23 Aug 2008 08:38:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E3E3A6958 for ; Sat, 23 Aug 2008 08:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YodFqueK83oe for ; Sat, 23 Aug 2008 08:38:04 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id DC71C3A6904 for ; Sat, 23 Aug 2008 08:38:03 -0700 (PDT) Received: (qmail 33214 invoked from network); 23 Aug 2008 15:38:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 23 Aug 2008 15:38:11 -0000 X-YMail-OSG: kwQaF4QVM1lTkTgNYKcJAxJjY9RFbMMjHxXkEQWvtl8LhRdJ.z6rSMA6wTbkntRgNT6e6_L5NdAitrqRQirjvzDiG5QGsfacfeZ8TUkwqQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B02EE1.1010707@netconfcentral.com> Date: Sat, 23 Aug 2008 08:38:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808221242.m7MCgDTw027239@idle.juniper.net> In-Reply-To: <200808221242.m7MCgDTw027239@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions (was Re: leaf encoding rules) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > David Partain writes: >> 1. Should we have the paragraph above in the YANG spec or not? That is, >> should the YANG spec say anything at all about what a server might or might >> not send? >> 2. Should we try to get with-defaults taken up as a work item in NETCONF? >> 3. Should we add system-created? > > There was also Balazs' question about complex defaults, where the > default value exists but can't be statically known. And "write > once" data, where the value can be assigned by not changed. > There is also the issue I brought up wrt/ min-access read-only. The old SMI way is to allow vendors to leave holes in the config by implementing some config knobs within table entries as read-only. Using the if-feature approach, there is no middle ground. Either the agent implements the knob read-create as intended, or the knob does not exist. This is really not any different than the manager providing a few knobs per list entry, and letting the agent fill in the defaults for the rest of them. The only difference is not every platform is going to allow the manager to set an explicit value. Maybe the old SMI way is broken. Maybe standard configuration will only succeed if it is an all-or-nothing contract, without all the wiggle room that min-access provides. I'm willing to toss min-access and start over with module + feature based conformance. It is simpler. If there are no features, you must implement everything in the module to claim conformance. If there are features, you must implement everything in the feature to return the feature name in the new 'get-features' operation. Agent variations would get punted to Martin's overlay solution (still very TBD), but they will be needed sooner or later. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 23 12:48:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71ECC3A6887; Sat, 23 Aug 2008 12:48:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3083A687F for ; Sat, 23 Aug 2008 12:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+N+30pIyVdR for ; Sat, 23 Aug 2008 12:48:47 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 29C613A63C9 for ; Sat, 23 Aug 2008 12:48:44 -0700 (PDT) Received: (qmail 62873 invoked from network); 23 Aug 2008 19:41:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 23 Aug 2008 19:41:30 -0000 X-YMail-OSG: 3G65DJsVM1kWUJnoo2glNk5veFJY.J6kys9iglagSc0UHUNGqubFFczh_Al67cz8sQcZxd0qIK0etkfm52sErx9AnlWeqRUQO_KacPCFkA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B067E8.7040206@netconfcentral.com> Date: Sat, 23 Aug 2008 12:41:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Subject: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Martin brought this up a long time ago, but maybe now is time to fix error-app-tag before it gets too hard to change it later. Right now, an application cannot use the string in a multi-module-publisher environment (gee, all of them) because there is no way to tell error-app-tag values apart from different vendors. There are also no definitions within YANG, so no way to associate them with a given module. Instead of the xsd:string data type we have now: my-error We should be using a xsd:QName instead: acme:my-error In this way, vendors and IETF WGs can define their own error-app-tags without any need for a centralized registry. An empty XML element works the same in YANG as a plain OBJECT-IDENTIFIER in SMIv2. But what prefix/namespace to use for the YANG error codes? YANG needs an XSD anyway to define the insert and key XML attributes, so that XSD can contain some empty elements for registration points YANG error-app-tag identifier for an unique statement violation during the validation of a NETCONF configuration database. ... yang:data-not-unique Note that YANG cannot support the definition of a registration QName (element name) because it would be interpreted as a database leaf, not a registration leaf. What if we had a generic object identifier statement for YANG, that was top-level only (body-stmt), and was used to define the YANG equivalent of registration OIDs? module yang { ... identifier data-not-unique { status current; description "YANG error-app-tag identifier for an unique statement violation during the validation of a NETCONF configuration database."; reference "draft-ietf-netmod-yang-00.txt, sec. E.1"; } ... } Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 01:43:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9097B3A692B; Sun, 24 Aug 2008 01:43:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D443A6A14 for ; Sun, 24 Aug 2008 01:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfbgyFo12lzx for ; Sun, 24 Aug 2008 01:43:25 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BC5A33A692B for ; Sun, 24 Aug 2008 01:43:25 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 01223616001; Sun, 24 Aug 2008 10:43:22 +0200 (CEST) Date: Sun, 24 Aug 2008 10:43:20 +0200 (CEST) Message-Id: <20080824.104320.36262059.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B00FB4.8020502@netconfcentral.com> References: <20080822114045.GA22613@elstar.local> <20080823.110453.118380885.mbj@tail-f.com> <48B00FB4.8020502@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> On Fri, Aug 22, 2008 at 01:00:14PM +0200, David Partain wrote: > >> > >>> Martin suggested that the specification say "Elements without a namespace > >>> refer to nodes in the current module" and received very few comments on that suggestion (Phil liked it). > >> Clarification: I think this implies that YANG translators have to > >> transform expressions by adding the correct prefixes since outside the > >> YANG context, prefixes are required. (Correct me if I am wrong.) > > Note that YANG does not reqiure an implementaton of XPath at all. An > > implementation is free to code the restrictions by hand. > > > > But a YANG to YIN or YANG to DSDL translator does need to > deal with prefix conversion. Clearly the 'no prefix==local module' > rule only applies within a YANG file, not YIN, not XML or any kind. As long as we're talking about must expressions, I do not agree. The rule that "Elements without a namespace refer to nodes in the current module" (from -01) for must expressions applies to YIN as well. For DSDL, you may be right. But I don't think we have agreed exactly what the DSDL mapping will be used for, or how. That's another discussion though. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 01:56:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0489F3A6BF2; Sun, 24 Aug 2008 01:56:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA99F3A68ED for ; Sun, 24 Aug 2008 01:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGrp7M8fIeMW for ; Sun, 24 Aug 2008 01:56:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B599E3A6BF2 for ; Sun, 24 Aug 2008 01:56:44 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 7CE2C616001; Sun, 24 Aug 2008 10:56:44 +0200 (CEST) Date: Sun, 24 Aug 2008 10:56:38 +0200 (CEST) Message-Id: <20080824.105638.116314310.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B01267.8000305@netconfcentral.com> References: <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Balazs Lengyel wrote: > >> > > 7.5.2. The must Statement > > The "must" statement, which is optional, takes as an argument a > string which contains an XPath expression. It is used to formally > declare a constraint on the configuration data. When a configuration > datastore is validated, all "must" constraints are conceptually > evaluated once for each corresponding instance in the datastore's > data tree, and for all leafs with default values in effect. > > > This text clearly says the defaults exist for the purpose of > must-stmt evaluation. IMO, this text should be clarified > to say 'all agent-created configuration nodes'. > > OLD: > > o The accessible tree is made up of all nodes in the data tree, and > all leafs with default values. > > NEW: > > o The accessible tree is made up of all nodes in the data tree, and > all leafs with agent-supplied values. But if we add this, we make a distinction between agent-supplied values and (I suppose) client-supplied values. Then we have to make sure that the rest of text follows this. I'm not sure I see the benefits of adding these terms. Maybe we can clarify somewhere that nodes in the data tree can be created by the server or client. > 7.6.5. XML Encoding Rules > > A leaf node is encoded as an XML element. The element's name is the > leaf's identifier, and its XML namespace is the module's XML > namespace. > > The value of the leaf node is encoded to XML according to the type, > and sent as character data in the element. > > A NETCONF server that replies to a or request MAY > choose not to send the leaf element if its value is the default > value. Thus, a client that receives an for a or > request, must be prepared to handle the case that a leaf > node with a default value is not present in the XML. In this case, > the value used by the server is known to be the default value. > > > As I noted before, I strongly object para 3 above, because it > changes NETCONF protocol behavior. The idea is that this text will cover implementations that always send all defaults, implementations that never send defaults, and implementations the use the with-defaults capability. > Also, the last sentence > is wrong. A missing node could mean it was filtered by > access control. Right. > It could mean there is no node at all. No. It means that the default is there. You cannot completely remove a leaf w/ default (unless you remove its parent of course). > It could mean there is an agent-supplied value. No, b/c in that case it would be present. An agent must not suppress agent-supplied values. > It will be harmful to interoperability to assume a missing > node has a YANG specified default value. This goes back to Randy's discussion of a strong contract for defaults. Without this strong contract, defaults will be more like SMI's DEFVAL, which I think we agreed we do not want. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 02:02:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC0D3A6890; Sun, 24 Aug 2008 02:02:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FB73A6A69 for ; Sun, 24 Aug 2008 02:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.279 X-Spam-Level: X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJStDPnROqAg for ; Sun, 24 Aug 2008 02:02:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D82A43A6890 for ; Sun, 24 Aug 2008 02:02:46 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id B7268616001; Sun, 24 Aug 2008 11:02:46 +0200 (CEST) Date: Sun, 24 Aug 2008 11:02:41 +0200 (CEST) Message-Id: <20080824.110241.233115842.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B0185B.6080907@netconfcentral.com> References: <48B0185B.6080907@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] defaults and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > The manager gets back a without any > agent-supplied defaults and it is useless for offline > must-stmt evaluation: > > > > 4668 > > > > > The manager needs to use the TBD 'with-defaults' in > order to receive the same XML that passed the validation > test on the agent: Or the client can add the missing defaults itself, before doing off-line must validation. I'm not an XSLT expert, but I'm sure it's fairly straightforward to let a tool like pyang generate an XSLT script which adds defaults for a given YANG module. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 09:10:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBDDE3A684A; Sun, 24 Aug 2008 09:10:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219773A69C3 for ; Sun, 24 Aug 2008 09:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0Ew9MPDuFtW for ; Sun, 24 Aug 2008 09:10:18 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 5B7293A6857 for ; Sun, 24 Aug 2008 09:10:18 -0700 (PDT) Received: (qmail 72878 invoked from network); 24 Aug 2008 16:10:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.104 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2008 16:10:16 -0000 X-YMail-OSG: CcrvI5EVM1mBsvkPxKoWvghwskGH94wl04J8NIG5SS6hyPBq2LoV9qRcTe7WiK_aB2Vo3BY_t2L68PjfyPfvXWIoXQ8PnzCLg1B07SSYc2KrcHgjZ.QicXFrup_29A0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B187E6.2010908@netconfcentral.com> Date: Sun, 24 Aug 2008 09:10:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> <20080824.105638.116314310.mbj@tail-f.com> In-Reply-To: <20080824.105638.116314310.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >... >> It could mean there is no node at all. > > No. It means that the default is there. You cannot completely remove > a leaf w/ default (unless you remove its parent of course). > >> It could mean there is an agent-supplied value. > > No, b/c in that case it would be present. An agent must not suppress > agent-supplied values. > What if the optional leaf is really optional? There might be other leafs (e.g, MTU) that work the way you describe -- they are only optional because there is a YANG default defined. Suppose I have this leaf: leaf alternate-foo-server { type inet:ip-address; } There is no default possible because it is an IP address. However, the clever agent can find a 'foo' server using other protocols or mechanisms. How does the manager know if the agent is going to setup and use an alternate 'foo' service or not? If the primary 'foo' service fails, is there a backup configured, or not? If so, which server is the backup? If the manager must configure this knob by hand to find out, then the auto-foo-discovery feature on the agent is not used. The manager does not want to *ever* provide a hard-wired value here, in order to use to auto-discovery instead. >> It will be harmful to interoperability to assume a missing >> node has a YANG specified default value. > > This goes back to Randy's discussion of a strong contract for > defaults. Without this strong contract, defaults will be more like > SMI's DEFVAL, which I think we agreed we do not want. > The IETF is not likely to take full advantage of the YANG default, which MUST be implemented exactly as specified, no exceptions. And there are plenty of use cases where no default is even possible, let alone agreed upon by the WG. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 11:51:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC593A67B2; Sun, 24 Aug 2008 11:51:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637CC3A6991 for ; Sun, 24 Aug 2008 11:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oXSIkdvbomf for ; Sun, 24 Aug 2008 11:51:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8DE8C3A67B2 for ; Sun, 24 Aug 2008 11:51:49 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB217C001D; Sun, 24 Aug 2008 20:50:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dqeFDP1USH7q; Sun, 24 Aug 2008 20:49:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93E25C0017; Sun, 24 Aug 2008 20:49:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC5FF6ADEE3; Sun, 24 Aug 2008 20:49:54 +0200 (CEST) Date: Sun, 24 Aug 2008 20:49:54 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080824184954.GB22649@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> <20080824.105638.116314310.mbj@tail-f.com> <48B187E6.2010908@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48B187E6.2010908@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sun, Aug 24, 2008 at 09:10:14AM -0700, Andy Bierman wrote: > Suppose I have this leaf: > > leaf alternate-foo-server { > type inet:ip-address; > } > > There is no default possible because it is an IP address. > However, the clever agent can find a 'foo' server using > other protocols or mechanisms. > > How does the manager know if the agent is going to > setup and use an alternate 'foo' service or not? > If the primary 'foo' service fails, is there a backup > configured, or not? If so, which server is the backup? There is likely a config setting that enables the magic protocol to obtain operational state with a backup server configuration. Note that the 'alternate-foo-server' is not config data anymore but operational state. > If the manager must configure this knob by hand to find > out, then the auto-foo-discovery feature on the agent > is not used. The manager does not want to *ever* provide > a hard-wired value here, in order to use to auto-discovery > instead. If alternate-foo-server is configured, then it is configured. This does not imply by itself that there can't be an auto-foo-discovery that configures alternate servers with a higher priority; so the config data would serve as a backup in case auto-foo-discovery fails. All this boils down to what the description clauses say. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 12:37:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C0B3A67FE; Sun, 24 Aug 2008 12:37:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB273A67FE for ; Sun, 24 Aug 2008 12:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.385 X-Spam-Level: X-Spam-Status: No, score=0.385 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viJmhf3L6WK4 for ; Sun, 24 Aug 2008 12:37:54 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id B6F8E3A68B9 for ; Sun, 24 Aug 2008 12:37:34 -0700 (PDT) Received: (qmail 45919 invoked from network); 24 Aug 2008 19:37:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.104 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 24 Aug 2008 19:37:07 -0000 X-YMail-OSG: 4kB86mEVM1nmyNibR7Buhnvc9FwI02EBAdegf5BWWSOC.E.cNO5k7xKh.OlVboYqxmlfqQgkwt_tByzdPGCX7oxgG0xVlNPPqqV9QallLQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B1B861.3060002@netconfcentral.com> Date: Sun, 24 Aug 2008 12:37:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> <20080824.105638.116314310.mbj@tail-f.com> <48B187E6.2010908@netconfcentral.com> <20080824184954.GB22649@elstar.local> In-Reply-To: <20080824184954.GB22649@elstar.local> Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Sun, Aug 24, 2008 at 09:10:14AM -0700, Andy Bierman wrote: > >> Suppose I have this leaf: >> >> leaf alternate-foo-server { >> type inet:ip-address; >> } >> >> There is no default possible because it is an IP address. >> However, the clever agent can find a 'foo' server using >> other protocols or mechanisms. >> >> How does the manager know if the agent is going to >> setup and use an alternate 'foo' service or not? >> If the primary 'foo' service fails, is there a backup >> configured, or not? If so, which server is the backup? > > There is likely a config setting that enables the magic protocol to > obtain operational state with a backup server configuration. Note that > the 'alternate-foo-server' is not config data anymore but operational > state. > It is not operational config unless the manager chooses that. >> If the manager must configure this knob by hand to find >> out, then the auto-foo-discovery feature on the agent >> is not used. The manager does not want to *ever* provide >> a hard-wired value here, in order to use to auto-discovery >> instead. > > If alternate-foo-server is configured, then it is configured. This > does not imply by itself that there can't be an auto-foo-discovery > that configures alternate servers with a higher priority; so the > config data would serve as a backup in case auto-foo-discovery > fails. All this boils down to what the description clauses say. > Right. And this is up the DM designer, not the YANG language. What if the 'enable-alternate-foo-service' knob said: "This knob is ignored if the alternate-foo-server knob is set by the manager. Otherwise, if equal to 'true', then the alternate-foo-service knob will contain the address of the alternate foo server selected by the agent." Does YANG force the DM designer to use more objects, and use the ifAdminStatus/ifOperStatus design instead of overloading one object? If so, then the rules need to be spelled out clearly in the draft, and say that optional leafs without YANG defaults MUST NOT exist, or be used in any fashion by the agent. Also, optional leafs with YANG defaults MUST exist and be used by the agent (if its parent exists). I don't mind throwing out the SNMP way of mixing config and operational state. The rules and consequences of using YANG default-stmt and mandatory-stmt need to be more clear. default | mandatory | rule --------+-----------+--------------------------------- no | false | node MUST NOT exist or be used --------+-----------+--------------------------------- yes | true | not allowed in YANG --------+-----------+--------------------------------- yes | false | node MUST exist and be used (if parent exists) --------+-----------+--------------------------------- no | true | node MUST be set by manager and be used --------+-----------+--------------------------------- This does not allow for any agent created config nodes that do not have YANG defaults. IMO, this category must be supported somehow (5th state somehow). > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 13:44:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807B83A68B9; Sun, 24 Aug 2008 13:44:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA18C3A68F0 for ; Sun, 24 Aug 2008 13:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nlgpi6vX0Tw6 for ; Sun, 24 Aug 2008 13:44:16 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 971033A68B9 for ; Sun, 24 Aug 2008 13:44:16 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id EA08E76C040; Sun, 24 Aug 2008 22:43:32 +0200 (CEST) Date: Sun, 24 Aug 2008 22:43:30 +0200 (CEST) Message-Id: <20080824.224330.107351011.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B1B861.3060002@netconfcentral.com> References: <48B187E6.2010908@netconfcentral.com> <20080824184954.GB22649@elstar.local> <48B1B861.3060002@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Does YANG force the DM designer to use more objects, > and use the ifAdminStatus/ifOperStatus design instead > of overloading one object? > > If so, then the rules need to be spelled out clearly > in the draft, and say that optional leafs without > YANG defaults MUST NOT exist, or be used in any fashion > by the agent. No, I don't think we want to do that. YANG clearly separates between config and non-config, but an optional config leaf can get an inital (not default!) value by the agent. The problem is how a client can know if a leaf is truly optional or will get a value by the agent. This is where 'created-by system;' would be useful. For such leafs, the client knows that it doesn't have to provide a value, but the agent will assign a reasonable value. This is still config, so the client can choose to override. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 14:09:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCE03A68F6; Sun, 24 Aug 2008 14:09:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8693A69BF for ; Sun, 24 Aug 2008 14:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[AWL=1.556, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geJt9N74Q7ni for ; Sun, 24 Aug 2008 14:09:45 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 6238B3A6937 for ; Sun, 24 Aug 2008 14:09:45 -0700 (PDT) Received: (qmail 88713 invoked from network); 24 Aug 2008 21:09:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.104 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 24 Aug 2008 21:09:43 -0000 X-YMail-OSG: rOH35CsVM1mzccADUURUHtOYJUrBxUr07cvqGAL8jZMjYdpXIbKmBhHTVsDuerWGM3p.9UEzKGQEh4k6sBsG1M.9oB4PtsOd_GJ5QyeMYlRCTm_2mOqb5HT5qGlVXmg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B1CE15.1060709@netconfcentral.com> Date: Sun, 24 Aug 2008 14:09:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B187E6.2010908@netconfcentral.com> <20080824184954.GB22649@elstar.local> <48B1B861.3060002@netconfcentral.com> <20080824.224330.107351011.mbj@tail-f.com> In-Reply-To: <20080824.224330.107351011.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Does YANG force the DM designer to use more objects, >> and use the ifAdminStatus/ifOperStatus design instead >> of overloading one object? >> >> If so, then the rules need to be spelled out clearly >> in the draft, and say that optional leafs without >> YANG defaults MUST NOT exist, or be used in any fashion >> by the agent. > > No, I don't think we want to do that. YANG clearly separates between > config and non-config, but an optional config leaf can get an inital > (not default!) value by the agent. The problem is how a client can > know if a leaf is truly optional or will get a value by the agent. > This is where 'created-by system;' would be useful. For such leafs, > the client knows that it doesn't have to provide a value, but the > agent will assign a reasonable value. This is still config, so the > client can choose to override. > Where is 'created-by-system' defined? I do not know the details this proposal. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 19:43:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F403A685F; Sun, 24 Aug 2008 19:43:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033F43A685F for ; Sun, 24 Aug 2008 19:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTWxseOhOg5w for ; Sun, 24 Aug 2008 19:43:05 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 2DCDC3A6852 for ; Sun, 24 Aug 2008 19:43:03 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sun, 24 Aug 2008 19:42:01 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:42:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:42:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 19:41:08 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7P2f8u73362; Sun, 24 Aug 2008 19:41:08 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7P2bZIu051616; Mon, 25 Aug 2008 02:37:35 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808250237.m7P2bZIu051616@idle.juniper.net> To: Andy Bierman In-reply-to: <48B187E6.2010908@netconfcentral.com> Date: Sun, 24 Aug 2008 22:37:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 02:41:08.0618 (UTC) FILETIME=[074F86A0:01C9065C] Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >Suppose I have this leaf: > leaf alternate-foo-server { > type inet:ip-address; > } >There is no default possible because it is an IP address. >However, the clever agent can find a 'foo' server using >other protocols or mechanisms. I think you are confusing config data with state data. The "foo server I will use" and "the foo server I was told to use" are not the same thing. The "list of users who are currently logged in" and "the list of users who are allowed to login" are different. The "list of currently known routes" and "the list of configured static routes" are different. All of these need data models for the operational state that are distinct from the data model for the configured state. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 19:48:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1353A68AF; Sun, 24 Aug 2008 19:48:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21513A695F for ; Sun, 24 Aug 2008 19:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENSU-F5I2NoH for ; Sun, 24 Aug 2008 19:48:14 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id C9A6D3A68AF for ; Sun, 24 Aug 2008 19:48:14 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Sun, 24 Aug 2008 19:47:03 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:43:24 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:43:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 19:43:23 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7P2hMu74070; Sun, 24 Aug 2008 19:43:22 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7P2doDM051642; Mon, 25 Aug 2008 02:39:50 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808250239.m7P2doDM051642@idle.juniper.net> To: Andy Bierman In-reply-to: <48B02EE1.1010707@netconfcentral.com> Date: Sun, 24 Aug 2008 22:39:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 02:43:23.0210 (UTC) FILETIME=[5788A2A0:01C9065C] Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions (was Re: leaf encoding rules) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >There is also the issue I brought up wrt/ min-access read-only. >The old SMI way is to allow vendors to leave holes in the config >by implementing some config knobs within table entries as >read-only. If the device doesn't allow it to be configured, there should be a specific way of saying that. It's not read-only, it's just not configurable: deviation some/knob { config false; } Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 19:48:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF5E3A690C; Sun, 24 Aug 2008 19:48:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB57B3A6913 for ; Sun, 24 Aug 2008 19:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD-M0zJhfhMj for ; Sun, 24 Aug 2008 19:48:49 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id BCCA23A690C for ; Sun, 24 Aug 2008 19:48:49 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Sun, 24 Aug 2008 19:48:10 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:45:11 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:45:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 19:45:09 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7P2j9u74715; Sun, 24 Aug 2008 19:45:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7P2faFB051668; Mon, 25 Aug 2008 02:41:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808250241.m7P2faFB051668@idle.juniper.net> To: Andy Bierman In-reply-to: <48B01267.8000305@netconfcentral.com> Date: Sun, 24 Aug 2008 22:41:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 02:45:09.0849 (UTC) FILETIME=[97187490:01C9065C] Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >This text clearly says the defaults exist for the purpose of >must-stmt evaluation. IMO, this text should be clarified >to say 'all agent-created configuration nodes'. "agent-created" and "agent-supplied" are misleading names, since there's no requirement for the agent to ever created these nodes. Would "implicit nodes" be an acceptable term? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Aug 24 23:56:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068FA3A65A6; Sun, 24 Aug 2008 23:56:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05C03A688E for ; Sun, 24 Aug 2008 23:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Foc8sFRXDww for ; Sun, 24 Aug 2008 23:56:40 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 10F073A65A6 for ; Sun, 24 Aug 2008 23:56:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AF8B3D800CB for ; Mon, 25 Aug 2008 08:55:40 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20080823.115501.104471813.mbj@tail-f.com> References: <200808221050.00096.david.partain@ericsson.com> <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> Organization: CESNET Date: Mon, 25 Aug 2008 08:55:40 +0200 Message-Id: <1219647340.6265.28.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTbyAyMy4gMDguIDIwMDggdiAxMTo1NSArMDIwMDoK PiBDdXJyZW50bHkgdGhlIHNwZWMgc3BlY2lmaWVzIHRoYXQgZGVmYXVsdHMgYXJlIG5vdCBwYXJ0 IG9mIHRoZQo+IGNvbmNlcHR1YWwgZGF0YSBzdG9yZS4gIEJ1dCBub3QgdGhlIHdvcmQgY29uY2Vw dHVhbC4gIFRoaXMgZG9lcyAqbm90Kgo+IHByZWNsdWRlIGFuIGltcGxlbWVudGF0aW9uIHRvIHN0 b3JlIHRoZSBkZWZhdWx0IGluIHRoZWlyIGRhdGFiYXNlLgoKSSBhbSBub3Qgc3VyZSB3aGV0aGVy ICJjb25jZXB0dWFsIGRhdGFzdG9yZSIgbWVhbnMgdGhlIHNhbWUgdGhpbmcgYXMKd2hhdCBJIGNh bGxlZCAiY29uY2VwdHVhbCBkYXRhIHRyZWUiIGluIER1Ymxpbi4gQnkgdGhlIGxhdHRlciBJIG1l YW50CmVzc2VudGlhbGx5IHRoZSByZXBseSB0byA8Z2V0PiB3aXRob3V0IGFueSBmaWx0ZXJzLCBp LmUuLCBYTUwuIElmIFlBTkcKbW9kZWxzIGFyZSBpbnRlcnByZXRlZCBhcyBjb250cmFjdHMgYmV0 d2VlbiB0aGUgYWdlbnQgYW5kIG1hbmFnZXIgdGhlbgppdCBpcyBJTU8gdGhlIG9ubHkgdGhpbmcg dGhhdCByZWFsbHkgbWF0dGVycy4gV2hldGhlciB0aGUgYWdlbnQgaGFzIHRoZQpkZWZhdWx0IHZh bHVlIGluIGl0cyBkYXRhYmFzZSBvciB3aGV0aGVyIGl0IGlzIGhhcmR3aXJlZCBldGMuIGRvZXNu J3QKc2VlbSBpbXBvcnRhbnQuCgpJbiB0aGlzIGNvbnRleHQsIHdpdGggcmVzcGVjdCB0byBkZWZh dWx0cyBpdCBpcyBvbmx5IG5lY2Vzc2FyeSB0byBkZWNpZGUKdW5kZXIgd2hhdCBjaXJjdW1zdGFu Y2VzIGEgbGVhZiBlbGVtZW50IHRoYXQgd291bGQgbm9ybWFsbHkgY29udGFpbiB0aGUKZGVmYXVs dCB2YWx1ZSBtYXkgYmUgb21pdHRlZCBpbiB0aGUgPGdldD4gb3IgPGdldC1jb25maWc+IHJlcGx5 LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBD CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2Qg bWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Aug 25 00:41:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453783A6848; Mon, 25 Aug 2008 00:41:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A0E3A6848 for ; Mon, 25 Aug 2008 00:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyAasCDH1bCQ for ; Mon, 25 Aug 2008 00:41:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A54123A693F for ; Mon, 25 Aug 2008 00:41:30 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9E8962076C; Mon, 25 Aug 2008 09:40:27 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-79-48b261eba0e6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8A10B20758; Mon, 25 Aug 2008 09:40:27 +0200 (CEST) Received: from esealmw121.eemea.ericsson.se ([153.88.200.80]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 09:40:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 25 Aug 2008 09:40:25 +0200 Message-ID: In-Reply-To: <1219647340.6265.28.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] various defaults discussions Thread-Index: AckGf75ME91hKRUSRJ+hAS9a/OMmPgAA8IUg References: <200808221050.00096.david.partain@ericsson.com><48AF1DAB.6080500@ericsson.com><20080823.115501.104471813.mbj@tail-f.com> <1219647340.6265.28.camel@missotis> From: "Peter Loborg" To: "Ladislav Lhotka" , "NETMOD Working Group" X-OriginalArrivalTime: 25 Aug 2008 07:40:27.0255 (UTC) FILETIME=[D77E1070:01C90685] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Ladislav Lhotka > Sent: den 25 augusti 2008 08:56 > To: NETMOD Working Group > Subject: Re: [netmod] various defaults discussions > = > Martin Bjorklund p=ED=B9e v So 23. 08. 2008 v 11:55 +0200: > > Currently the spec specifies that defaults are not part of the > > conceptual data store. But not the word conceptual. This does *not* > > preclude an implementation to store the default in their database. > = > I am not sure whether "conceptual datastore" means the same thing as > what I called "conceptual data tree" in Dublin. By the latter I meant > essentially the reply to without any filters, i.e., XML. If YANG > models are interpreted as contracts between the agent and manager then > it is IMO the only thing that really matters. Whether the agent has the > default value in its database or whether it is hardwired etc. doesn't > seem important. > = > In this context, with respect to defaults it is only necessary to decide > under what circumstances a leaf element that would normally contain the > default value may be omitted in the or reply. > = > Lada > = > -- I fully agree to this statement. In order to support simplistic (cheaper an= d easier to verify) implementations of agents/managers, any mechanism to om= it leafs with default values should as a default be OFF. If both sides exch= ange a capability "defaults-omitted" (or similar) then the function is turn= ed on. This is also quite usable for debugging purposes. If we desperately want to reduce the amount of data sent over the wire (is = there any other reason for omitting defaults?) then omitting the defaults w= on't really do the trick. We must also go outside YANG/NETMOD to solve that= problem, e.g. with a different encoding for NETCONF such as ASN.1 PER or b= y sending a compressed XML stream. IMHO /Peter _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 01:05:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11FB3A6902; Mon, 25 Aug 2008 01:05:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F443A6844 for ; Mon, 25 Aug 2008 01:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjoBRvS8wWiz for ; Mon, 25 Aug 2008 01:05:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EA7593A6902 for ; Mon, 25 Aug 2008 01:05:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AFDAC001D; Mon, 25 Aug 2008 10:04:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id csFimPIQ0dXk; Mon, 25 Aug 2008 10:04:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6AE8C0036; Mon, 25 Aug 2008 10:04:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B7406AE263; Mon, 25 Aug 2008 10:04:20 +0200 (CEST) Date: Mon, 25 Aug 2008 10:04:20 +0200 From: Juergen Schoenwaelder To: Peter Loborg Message-ID: <20080825080420.GA23200@elstar.local> Mail-Followup-To: Peter Loborg , Ladislav Lhotka , NETMOD Working Group References: <1219647340.6265.28.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 25, 2008 at 09:40:25AM +0200, Peter Loborg wrote: > I fully agree to this statement. In order to support simplistic > (cheaper and easier to verify) implementations of agents/managers, > any mechanism to omit leafs with default values should as a default > be OFF. If both sides exchange a capability "defaults-omitted" (or > similar) then the function is turned on. This is also quite usable > for debugging purposes. I like to be able to turn on/off the inclusion of "defaults" on an operation base. Having to start a new session to enable/disable this filter seems odd to me. > If we desperately want to reduce the amount of data sent over the > wire (is there any other reason for omitting defaults?) then > omitting the defaults won't really do the trick. We must also go > outside YANG/NETMOD to solve that problem, e.g. with a different > encoding for NETCONF such as ASN.1 PER or by sending a compressed > XML stream. The main motivation (as I understand it) is to ask NETCONF servers to help in hiding noise from human operators; things I did not set are not part of what I consider a device's configuration. Still, in some debugging situations, I like to see all config knobs and their "default" values - adding a with-defaults extension to get-config nicely gives me that functionality. (Or adding a new capability introducing a get-config-without-defaults operation; I don't really care much.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 01:21:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C14C3A6848; Mon, 25 Aug 2008 01:21:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E093A6848 for ; Mon, 25 Aug 2008 01:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZb7Hd58p13r for ; Mon, 25 Aug 2008 01:21:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A068E3A688E for ; Mon, 25 Aug 2008 01:21:10 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C8DC5D800D2; Mon, 25 Aug 2008 10:21:08 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48B0185B.6080907@netconfcentral.com> References: <48B0185B.6080907@netconfcentral.com> Organization: CESNET Date: Mon, 25 Aug 2008 10:21:08 +0200 Message-Id: <1219652468.6265.51.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] defaults and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFNvIDIzLiAwOC4gMjAwOCB2IDA3OjAyIC0wNzAwOgo+ICAg IG1vZHVsZSBhIHsKPiAgICAgICBuYW1lc3BhY2UgYTsKPiAgICAgICBwcmVmaXggZm9vOwo+IAo+ ICAgICAgIGxlYWYgeCB7Cj4gICAgICAgICAgdHlwZSBpbnQzMjsKPiAgICAgICAgICBtdXN0ICIv Zm9vOnggPSA0MiBhbmQgL2Zvbzp6ID0gMTciOwo+ICAgICAgICB9Cj4gICAgICAgIGxlYWYgeiB7 Cj4gICAgICAgICAgdHlwZSBpbnQzMiB7Cj4gICAgICAgICAgICAgZGVmYXVsdCAgMTc7Cj4gICAg ICAgICAgfQo+ICAgICAgICB9Cj4gICAgfQo+IAo+ICAgIG1vZHVsZSBiIHsKPiAgICAgICBuYW1l c3BhY2UgYjsKPiAgICAgICBwcmVmaXggZm9vOwo+ICAgICAgIGltcG9ydCBhIHsgcHJlZml4IGE7 IH0KPiAKPiAgICAgICBsZWFmIHkgewo+ICAgICAgICAgIHR5cGUgaW50MzI7Cj4gICAgICAgICAg bXVzdCAiL2Zvbzp5ID0gNDY2OCBhbmQgL2E6eCA+PSAxNyI7Cj4gICAgICAgfQo+ICAgIH0KPiAK PiBUaGUgbWFuYWdlciBnZXRzIGJhY2sgYSA8Z2V0LWNvbmZpZz4gd2l0aG91dCBhbnkKPiBhZ2Vu dC1zdXBwbGllZCBkZWZhdWx0cyBhbmQgaXQgaXMgdXNlbGVzcyBmb3Igb2ZmbGluZQo+IG11c3Qt c3RtdCBldmFsdWF0aW9uOgo+IAo+ICAgIDxycGMtcmVwbHkgLi4uPgo+ICAgICAgPGRhdGEgeG1s bnM6YT0iYSIgeG1sbnM6Yj0iYiI+Cj4gICAgICAgICA8Yjp5PjQ2Njg8L2I6eT4KPiAgICAgIDwv ZGF0YT4KPiAgICA8L3JwYy1yZXBseT4KPiAKVGhlIGRlZmF1bHQgZm9yICd4JyBpcyBub3QgZGVm aW5lZCBpbiB0aGUgRE0sIHNvIEkgZ3Vlc3MgPGE6eD4xNzwvYTp4PgptdXN0IGJlIGluY2x1ZGVk IGhlcmU/Cgo+IAo+IFRoZSBtYW5hZ2VyIG5lZWRzIHRvIHVzZSB0aGUgVEJEICd3aXRoLWRlZmF1 bHRzJyBpbgo+IG9yZGVyIHRvIHJlY2VpdmUgdGhlIHNhbWUgWE1MIHRoYXQgcGFzc2VkIHRoZSB2 YWxpZGF0aW9uCj4gdGVzdCBvbiB0aGUgYWdlbnQ6CgpOb3QgbmVjZXNzYXJpbHkuIERTREwgaXMg ZGVzaWduZWQgdG8gaGFuZGxlIHN1Y2ggY2FzZXM6IGRlZmF1bHQgdmFsdWVzCmRlZmluZWQgaW4g YSBEU1JMIHNjaGVtYSBhcmUgdXNlZCBmb3IgdmFsaWRhdGlvbiBpZiB0aGUgY29ycmVzcG9uZGlu ZwplbGVtZW50cyBhcmUgZW1wdHkgb3Igbm90IHByZXNlbnQgaW4gdGhlIGluc3RhbmNlIGRvY3Vt ZW50LiBTbyB0aGUKbWFuYWdlciBjb3VsZCBkbyB0aGUgc2FtZSBhbmQgZmlyc3QgYXNzdW1lIGRl ZmF1bHRzIHdoZXJlIHRoZQpjb3JyZXNwb25kaW5nIGxlYWYgaXMgbWlzc2luZy4KCkxhZGEKCj4g Cj4gICAgPHJwYyAuLi4gd2l0aC1kZWZhdWx0cz10cnVlPgo+ICAgICAgPGdldC1jb25maWc+Cj4g ICAgICAgICA8c291cmNlPjxydW5uaW5nLz48L3NvdXJjZT4KPiAgICAgIDwvZ2V0LWNvbmZpZz4K PiAgICA8L3JwYz4KPiAKPiAgICA8cnBjLXJlcGx5IC4uLj4KPiAgICAgIDxkYXRhIHhtbG5zOmE9 ImEiIHhtbG5zOmI9ImIiPgo+ICAgICAgICAgPGE6eD40MjwvYTp4Pgo+ICAgICAgICAgPGE6ej4x NzwvYTp6Pgo+ICAgICAgICAgPGI6eT40NjY4PC9iOnk+Cj4gICAgICA8L2RhdGE+Cj4gICAgPC9y cGMtcmVwbHk+Cj4gCj4gSU1PLCBpdCBpcyBPSyBmb3IgWUFORyB0byBsZWF2ZSBkZWZhdWx0cyBv dXQgb25seSBpZgo+IHRoZSBORVRDT05GIHByb3RvY29sIGlzIGV4dGVuZGVkIChlLmcuLCB3aXRo LWRlZmF1bHRzKSB0byBjb21wZW5zYXRlLgo+IElmIG5vdCwgdGhlbiBZQU5HIG11c3Qgbm90IGhp ZGUgdGhlIGFnZW50LXN1cHBsaWVkIG5vZGVzLgo+IAo+IAo+IEFuZHkKPiAKPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5nIGxp c3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThD MEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1v ZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Aug 25 01:40:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DAC3A680F; Mon, 25 Aug 2008 01:40:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDAFF3A693F for ; Mon, 25 Aug 2008 01:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUNIokH7aqTa for ; Mon, 25 Aug 2008 01:40:16 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2A5A23A680F for ; Mon, 25 Aug 2008 01:40:16 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0C370D800E8; Mon, 25 Aug 2008 10:39:03 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080825080420.GA23200@elstar.local> References: <1219647340.6265.28.camel@missotis> <20080825080420.GA23200@elstar.local> Organization: CESNET Date: Mon, 25 Aug 2008 10:39:02 +0200 Message-Id: <1219653542.6265.64.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFBvIDI1LiAwOC4gMjAwOCB2IDEwOjA0ICsw MjAwOgoKPiBUaGUgbWFpbiBtb3RpdmF0aW9uIChhcyBJIHVuZGVyc3RhbmQgaXQpIGlzIHRvIGFz ayBORVRDT05GIHNlcnZlcnMgdG8KPiBoZWxwIGluIGhpZGluZyBub2lzZSBmcm9tIGh1bWFuIG9w ZXJhdG9yczsgdGhpbmdzIEkgZGlkIG5vdCBzZXQgYXJlCj4gbm90IHBhcnQgb2Ygd2hhdCBJIGNv bnNpZGVyIGEgZGV2aWNlJ3MgY29uZmlndXJhdGlvbi4gU3RpbGwsIGluIHNvbWUKCkJ1dCBhc3N1 bWUgdGhhdCBpbiBvbmUgTkVUQ09ORiBzZXNzaW9uIHlvdSBleHBsaWNpdGx5IHNldCBhIGtub2Ig dG8gYQp2YWx1ZSB0aGF0IGhhcHBlbnMgdG8gYmUgaXRzIGRlZmF1bHQgdmFsdWUuIFRoZW4sIGlm IHlvdSBvciBzb21lb25lIGVsc2UKb3BlbnMgYW5vdGhlciBzZXNzaW9uLCBzaG91bGQgdGhlIHZh bHVlIGJlIHNlbnQgaW4gdGhpcyBuZXcgc2Vzc2lvbj8KCkkgdGhpbmsgdGhlIGhhbmRsaW5nIG9m IGRlZmF1bHRzIG11c3QgYmUgZGVmaW5lZCBpbiB0ZXJtcyBvZiBjb21wYXJpbmcKdGhlIGFjdHVh bCB2YWx1ZSB3aXRoIHRoZSBkZWZhdWx0IGRlZmluZWQgaW4gdGhlIGRhdGEgbW9kZWwsIG5vdCBp bgp0ZXJtcyBvZiB0aGUgcHJldmlvdXMgZXZlbnRzIHRoYXQgbWF5IG5vdCBiZSBrbm93biBhbnlt b3JlLiBGb3IgZXhhbXBsZToKIklmIHRoZSB2YWx1ZSBvZiBhIGxlYWYgZWxlbWVudCBpcyBlcXVh bCAoaW4gdGhlIHZhbHVlIHNwYWNlKSB0byB0aGUKZGVmYXVsdCB2YWx1ZSBvZiB0aGlzIGxlYWYg YXMgZGVmaW5lZCBieSB0aGUgRE0sIHRoZSBhZ2VudApNQVkvU0hPVUxEL01VU1Qgc3VwcHJlc3Mg dGhpcyBsZWFmIGluIHRoZSA8Z2V0PiBvdXRwdXQuIgoKTGFkYQoKPiBkZWJ1Z2dpbmcgc2l0dWF0 aW9ucywgSSBsaWtlIHRvIHNlZSBhbGwgY29uZmlnIGtub2JzIGFuZCB0aGVpcgo+ICJkZWZhdWx0 IiB2YWx1ZXMgLSBhZGRpbmcgYSB3aXRoLWRlZmF1bHRzIGV4dGVuc2lvbiB0byBnZXQtY29uZmln Cj4gbmljZWx5IGdpdmVzIG1lIHRoYXQgZnVuY3Rpb25hbGl0eS4gKE9yIGFkZGluZyBhIG5ldyBj YXBhYmlsaXR5Cj4gaW50cm9kdWNpbmcgYSBnZXQtY29uZmlnLXdpdGhvdXQtZGVmYXVsdHMgb3Bl cmF0aW9uOyBJIGRvbid0IHJlYWxseQo+IGNhcmUgbXVjaC4pCj4gCj4gL2pzCj4gCi0tIApMYWRp c2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRt b2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Aug 25 01:48:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C153A6844; Mon, 25 Aug 2008 01:48:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6957C3A6853 for ; Mon, 25 Aug 2008 01:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOnkFvElyFIC for ; Mon, 25 Aug 2008 01:48:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EA78F3A6844 for ; Mon, 25 Aug 2008 01:48:50 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D00CBC0026; Mon, 25 Aug 2008 10:47:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BerOAVI4KSoE; Mon, 25 Aug 2008 10:47:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0715EC0048; Mon, 25 Aug 2008 10:47:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 90E926AE4B9; Mon, 25 Aug 2008 10:47:02 +0200 (CEST) Date: Mon, 25 Aug 2008 10:47:02 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080825084702.GC23239@elstar.local> Mail-Followup-To: Ladislav Lhotka , Peter Loborg , NETMOD Working Group References: <1219647340.6265.28.camel@missotis> <20080825080420.GA23200@elstar.local> <1219653542.6265.64.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1219653542.6265.64.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 25, 2008 at 10:39:02AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v Po 25. 08. 2008 v 10:04 +0200: > > > The main motivation (as I understand it) is to ask NETCONF servers to > > help in hiding noise from human operators; things I did not set are > > not part of what I consider a device's configuration. Still, in some > > But assume that in one NETCONF session you explicitly set a knob to a > value that happens to be its default value. Then, if you or someone else > opens another session, should the value be sent in this new session? I would say yes. The knob was explicitely set by a management operation, so this becomes part of the configuration. > I think the handling of defaults must be defined in terms of comparing > the actual value with the default defined in the data model, not in > terms of the previous events that may not be known anymore. You don't need to remember previous events; all you need is a bit indicating "this value was set by an explicit operation and is part of the config". The more important question really is how to clear this bit. But I believe recording this bit on the NETCONF server is pretty important operationally. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 01:58:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE0C3A680F; Mon, 25 Aug 2008 01:58:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B4A3A6844 for ; Mon, 25 Aug 2008 01:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3rAjItb7qgu for ; Mon, 25 Aug 2008 01:58:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4070E3A680F for ; Mon, 25 Aug 2008 01:58:32 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id AB79F76C4F0; Mon, 25 Aug 2008 10:57:52 +0200 (CEST) Date: Mon, 25 Aug 2008 10:57:52 +0200 (CEST) Message-Id: <20080825.105752.154928548.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080825084702.GC23239@elstar.local> References: <20080825080420.GA23200@elstar.local> <1219653542.6265.64.camel@missotis> <20080825084702.GC23239@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Aug 25, 2008 at 10:39:02AM +0200, Ladislav Lhotka wrote: > > I think the handling of defaults must be defined in terms of comparing > > the actual value with the default defined in the data model, not in > > terms of the previous events that may not be known anymore. > > You don't need to remember previous events; all you need is a bit > indicating "this value was set by an explicit operation and is part of > the config". The more important question really is how to clear this > bit. But I believe recording this bit on the NETCONF server is pretty > important operationally. The way to "clear this bit" is to delete the leaf element: 1. The db is empty. Leaf 'foo' which has a default of 42 is not there in the db. The server internal applications use the value 42. 2. A client sends an edit-config which sets 'foo' to 4668. This value is stored in the db. The server internal applications use the value 4668. 3. A client deletes 'foo' in an edit-config. 'foo' is deleted from the db. Goto step 1. This is simple, cheap, and memory efficient. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 02:12:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579F93A688E; Mon, 25 Aug 2008 02:12:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BB63A6902 for ; Mon, 25 Aug 2008 02:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUnHTapx2Azv for ; Mon, 25 Aug 2008 02:12:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5D5B43A688E for ; Mon, 25 Aug 2008 02:12:06 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id D368D76C4F0; Mon, 25 Aug 2008 11:02:56 +0200 (CEST) Date: Mon, 25 Aug 2008 11:02:52 +0200 (CEST) Message-Id: <20080825.110252.83683233.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1219647340.6265.28.camel@missotis> References: <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <1219647340.6265.28.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > If YANG models are interpreted as contracts between the agent and > manager then it is IMO the only thing that really matters. Whether > the agent has the default value in its database or whether it is > hardwired etc. doesn't seem important. Exactly. That's what I meant. And the contract says that if a value is for a leaf w/ a default is not present when its parent is present in a PDU, then it means that the default value is used (modulo access rights). You are free to implement this any way you want - store the defaults in the db but don't send them; store the defaults in the db and always send them; don't store defaults in the db but always send them, ... /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 02:19:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53E43A683C; Mon, 25 Aug 2008 02:19:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F32D3A6844 for ; Mon, 25 Aug 2008 02:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2quzcEPpPRF for ; Mon, 25 Aug 2008 02:19:25 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 925043A683C for ; Mon, 25 Aug 2008 02:19:25 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 95BA076C4F0; Mon, 25 Aug 2008 11:18:44 +0200 (CEST) Date: Mon, 25 Aug 2008 11:18:42 +0200 (CEST) Message-Id: <20080825.111842.263460825.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B1CE15.1060709@netconfcentral.com> References: <48B1B861.3060002@netconfcentral.com> <20080824.224330.107351011.mbj@tail-f.com> <48B1CE15.1060709@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Where is 'created-by-system' defined? > I do not know the details this proposal. See: http://www.ietf.org/mail-archive/web/netmod/current/msg00692.html http://www.ietf.org/mail-archive/web/netmod/current/msg00749.html There is no finished proposal with all details filled in yet. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 02:21:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDA83A69C2; Mon, 25 Aug 2008 02:21:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1537E3A6912 for ; Mon, 25 Aug 2008 02:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0943aJoqTNwA for ; Mon, 25 Aug 2008 02:21:04 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 46C8C3A69B9 for ; Mon, 25 Aug 2008 02:21:04 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E7825D800F8; Mon, 25 Aug 2008 11:20:14 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080825.110252.83683233.mbj@tail-f.com> References: <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <1219647340.6265.28.camel@missotis> <20080825.110252.83683233.mbj@tail-f.com> Organization: CESNET Date: Mon, 25 Aug 2008 11:20:15 +0200 Message-Id: <1219656015.6265.83.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAyNS4gMDguIDIwMDggdiAxMTowMiArMDIwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+IAo+ID4gSWYgWUFO RyBtb2RlbHMgYXJlIGludGVycHJldGVkIGFzIGNvbnRyYWN0cyBiZXR3ZWVuIHRoZSBhZ2VudCBh bmQKPiA+IG1hbmFnZXIgdGhlbiBpdCBpcyBJTU8gdGhlIG9ubHkgdGhpbmcgdGhhdCByZWFsbHkg bWF0dGVycy4gV2hldGhlcgo+ID4gdGhlIGFnZW50IGhhcyB0aGUgZGVmYXVsdCB2YWx1ZSBpbiBp dHMgZGF0YWJhc2Ugb3Igd2hldGhlciBpdCBpcwo+ID4gaGFyZHdpcmVkIGV0Yy4gZG9lc24ndCBz ZWVtIGltcG9ydGFudC4KPiAKPiBFeGFjdGx5LiAgVGhhdCdzIHdoYXQgSSBtZWFudC4KPiAKPiBB bmQgdGhlIGNvbnRyYWN0IHNheXMgdGhhdCBpZiBhIHZhbHVlIGlzIGZvciBhIGxlYWYgdy8gYSBk ZWZhdWx0IGlzCj4gbm90IHByZXNlbnQgd2hlbiBpdHMgcGFyZW50IGlzIHByZXNlbnQgaW4gYSBQ RFUsIHRoZW4gaXQgbWVhbnMgdGhhdAo+IHRoZSBkZWZhdWx0IHZhbHVlIGlzIHVzZWQgKG1vZHVs byBhY2Nlc3MgcmlnaHRzKS4gIFlvdSBhcmUgZnJlZSB0bwo+IGltcGxlbWVudCB0aGlzIGFueSB3 YXkgeW91IHdhbnQgLSBzdG9yZSB0aGUgZGVmYXVsdHMgaW4gdGhlIGRiIGJ1dAo+IGRvbid0IHNl bmQgdGhlbTsgc3RvcmUgdGhlIGRlZmF1bHRzIGluIHRoZSBkYiBhbmQgYWx3YXlzIHNlbmQgdGhl bTsKPiBkb24ndCBzdG9yZSBkZWZhdWx0cyBpbiB0aGUgZGIgYnV0IGFsd2F5cyBzZW5kIHRoZW0s IC4uLgoKU291bmRzIGdvb2QuIFRoaXMgaWRlYSBvZiBhIGNvbmNlcHR1YWwgZGF0YXN0b3JlIChl eHByZXNzZWQgaW4gWE1MKQphY3R1YWxseSBhbHNvIGdpdmVzIG1vcmUgc2Vuc2UgdG8gdGhlIERT REwgc3R1ZmY6IFJhdGhlciB0aGFuIGJlaW5nIGEKdHJhbnNsYXRpb24gb2YgYSBZQU5HIGRhdGEg bW9kZWwgZm9yIG1hbmFnZXJzLCBpdCBpcyBhIGZvcm1hbApyZXByZXNlbnRhdGlvbiBvZiBjb25z dHJhaW50cyB0aGF0IHRoZSBjb25jZXB0dWFsIGRhdGFzdG9yZSAoYW5kLApjb25zZXF1ZW50bHks IHRoZSBORVRDT05GIFBEVXMpIG11c3Qgc2F0aXNmeSBpbiBvcmRlciB0byBiZSBjb21wbGlhbnQK d2l0aCB0aGUgWUFORyBkYXRhIG1vZGVsLgoKTGFkYQoKPiAKPiAKPiAvbWFydGluCi0tIApMYWRp c2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRt b2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Aug 25 02:28:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FA33A67AC; Mon, 25 Aug 2008 02:28:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A163A6880 for ; Mon, 25 Aug 2008 02:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deI2Ghqnrk7F for ; Mon, 25 Aug 2008 02:28:49 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 76F253A67AC for ; Mon, 25 Aug 2008 02:28:49 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 8A45876C4F0; Mon, 25 Aug 2008 11:27:13 +0200 (CEST) Date: Mon, 25 Aug 2008 11:27:10 +0200 (CEST) Message-Id: <20080825.112710.258053439.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B067E8.7040206@netconfcentral.com> References: <48B067E8.7040206@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, [removed cc: netconf, since I just comment on the YANG bits] Andy Bierman wrote: > Note that YANG cannot support the definition of a registration > QName (element name) because it would be interpreted as a > database leaf, not a registration leaf. > > What if we had a generic object identifier statement > for YANG, that was top-level only (body-stmt), and > was used to define the YANG equivalent of registration OIDs? > > module yang { > > ... > > identifier data-not-unique { > status current; > description > "YANG error-app-tag identifier for an unique > statement violation during the validation of > a NETCONF configuration database."; > reference > "draft-ietf-netmod-yang-00.txt, sec. E.1"; > } > > ... > } So when an "error-app-tag" statement is used, it MUST refer to an existing identifier? In the current module or some other module: import foo { prefix foo; } ... error-app-tag foo:fatal-error; Can the identifiers defined with this statement be used for something else than just error-app-tag? Is the idea that they can be used like OBJECT-IDENTITY - if so, do we also need a corresponding builtin type "identifier" (or better name) which is encoded as a QName: leaf encryption-method { type identifier; } identifier des3 { ... } identifier aes128 { ... } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 03:23:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14CA3A688B; Mon, 25 Aug 2008 03:23:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD153A688B for ; Mon, 25 Aug 2008 03:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9Mvr8PbYO4I for ; Mon, 25 Aug 2008 03:23:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 575A13A6BA4 for ; Mon, 25 Aug 2008 03:23:48 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45C1AC0033; Mon, 25 Aug 2008 12:23:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xXd1fkQ1sLcJ; Mon, 25 Aug 2008 12:22:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BAFAC002B; Mon, 25 Aug 2008 12:22:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DAD896AE969; Mon, 25 Aug 2008 12:22:56 +0200 (CEST) Date: Mon, 25 Aug 2008 12:22:56 +0200 From: Juergen Schoenwaelder To: Peter Loborg Message-ID: <20080825102256.GB23809@elstar.local> Mail-Followup-To: Peter Loborg , Ladislav Lhotka , NETMOD Working Group References: <1219647340.6265.28.camel@missotis> <20080825080420.GA23200@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 25, 2008 at 11:45:07AM +0200, Peter Loborg wrote: > Hmmm - you seem to consider machine-human interaction with one node with > a fairly long session time. That's rather opposite to our experience of > management tool operations - it's a machine-machine interaction (no > problems with "noise") and the human sits on the other end of a > configuration tool. The tool will do the information filtering/hiding > based on user preferences. If there is such a tool, great. However, there are many operational environments without such tools and I believe we make a mistake if we ignore them. > Summary - My view is that we should keep the modelling language simple > and clear, features to simplify for man-machine communication over > netconf are probably wasted (who will manually "talk" Netconf over ssh > with a node?). Optionalities and agent choices will complicate the > implementation of tool support. It's more important to provide managers > the possibility to catch up with changes on a node than to hide default > values - multiple users tend to contact the node at various times with > separate instances or variants of the management tool, and sometimes > there are site visits with reconfigurations as result. I believe we have to support both scenarios. (Note that for me the filtering of defaults is a protocol issue, not a modelling language issue so I am not sure I agree with your text above.) I agree that protocol capabilities will complicate implementations but ignoring the complexity of the real world and the different requirements of NETCONF users will also not work at the end. Right now, NETCONF implementations show different behaviour in a number of places and we need to work through this or you will end up with a vague standard that everybody implements in his own way - this is IMHO worse for interoperability than a bunch of capabilities. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 03:38:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1BC3A6A63; Mon, 25 Aug 2008 03:38:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B783A6AEE for ; Mon, 25 Aug 2008 03:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.575 X-Spam-Level: X-Spam-Status: No, score=-4.575 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlaTMxAXT3Pn for ; Mon, 25 Aug 2008 03:38:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 21FCB28C1FB for ; Mon, 25 Aug 2008 03:38:14 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9A59920996; Mon, 25 Aug 2008 11:45:13 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-62-48b27f2906c3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 167E420983; Mon, 25 Aug 2008 11:45:13 +0200 (CEST) Received: from esealmw121.eemea.ericsson.se ([153.88.200.80]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 11:45:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 11:45:07 +0200 Message-ID: In-Reply-To: <20080825080420.GA23200@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] various defaults discussions Thread-Index: AckGiTLfl7vggDpHRuS/gIFqQU54egABRUJw References: <1219647340.6265.28.camel@missotis> <20080825080420.GA23200@elstar.local> From: "Peter Loborg" To: X-OriginalArrivalTime: 25 Aug 2008 09:45:08.0867 (UTC) FILETIME=[42E17530:01C90697] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: den 25 augusti 2008 10:04 > To: Peter Loborg > Cc: Ladislav Lhotka; NETMOD Working Group > Subject: Re: [netmod] various defaults discussions > > On Mon, Aug 25, 2008 at 09:40:25AM +0200, Peter Loborg wrote: > > > I fully agree to this statement. In order to support simplistic > > (cheaper and easier to verify) implementations of agents/managers, > > any mechanism to omit leafs with default values should as a default > > be OFF. If both sides exchange a capability "defaults-omitted" (or > > similar) then the function is turned on. This is also quite usable > > for debugging purposes. > > I like to be able to turn on/off the inclusion of "defaults" on an > operation base. Having to start a new session to enable/disable this > filter seems odd to me. > > > If we desperately want to reduce the amount of data sent over the > > wire (is there any other reason for omitting defaults?) then > > omitting the defaults won't really do the trick. We must also go > > outside YANG/NETMOD to solve that problem, e.g. with a different > > encoding for NETCONF such as ASN.1 PER or by sending a compressed > > XML stream. > > The main motivation (as I understand it) is to ask NETCONF servers to > help in hiding noise from human operators; things I did not set are > not part of what I consider a device's configuration. Still, in some > debugging situations, I like to see all config knobs and their > "default" values - adding a with-defaults extension to get-config > nicely gives me that functionality. (Or adding a new capability > introducing a get-config-without-defaults operation; I don't really > care much.) Hmmm - you seem to consider machine-human interaction with one node with a fairly long session time. That's rather opposite to our experience of management tool operations - it's a machine-machine interaction (no problems with "noise") and the human sits on the other end of a configuration tool. The tool will do the information filtering/hiding based on user preferences. The "normal" interaction cycle is that the manager connects to multiple nodes, and reads out the whole or a substantial part of the config in one chunk, then releases the connections and lets the user re-configure and consistency check this multi-node data set (containing both data from Netconf-managed nodes and from other nodes). The result is a set of suggested config changes for one or several nodes, and when this is applied all nodes that need to be changed are connected to and the change is sent over. This process may be as fast as 10 minutes but may also be 24 hours (some telecom operators require a manger to check the planned reconfig done by a team of planners before the change can be applied, and we have seen situations where we have more than 100 planned reconfigurations waiting for approval in their system). So I would say that the needs for a single element manger tool used for debugging a node is quite different from the needs of a network management and planning tool. O&M interface designers in a node organisation tend to think foremost on the single element poking/debugging scenario rather than what is needed to plan and execute a change on 10 nodes in a network of 10000 nodes and while maintaining consistency in this operation. As an example of useful functionality on a node, it would be extremely valuable to be able to get a time stamp from the node telling when any config was last changed, and/or to ask for all changes since a certain point in time. Quite useful to check this info prior to applying a reconfig of a set of nodes. NETCONF does give us a similar solution if all nodes support the possibility to reconfig in a special area, then validate and finally apply - but how many node types will implement this capability? Summary - My view is that we should keep the modelling language simple and clear, features to simplify for man-machine communication over netconf are probably wasted (who will manually "talk" Netconf over ssh with a node?). Optionalities and agent choices will complicate the implementation of tool support. It's more important to provide managers the possibility to catch up with changes on a node than to hide default values - multiple users tend to contact the node at various times with separate instances or variants of the management tool, and sometimes there are site visits with reconfigurations as result. IMH?O, Peter Loborg, Systems Manager/Architect, Ericsson GSM Radio Access Network OSS. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 05:39:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143A728C0F3; Mon, 25 Aug 2008 05:39:04 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A75128C0F6 for ; Mon, 25 Aug 2008 05:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp261Z69f1JE for ; Mon, 25 Aug 2008 05:39:01 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 7BA0328C0F3 for ; Mon, 25 Aug 2008 05:39:01 -0700 (PDT) Received: (qmail 94568 invoked from network); 25 Aug 2008 12:38:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.104 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2008 12:38:13 -0000 X-YMail-OSG: cX4rwRoVM1mpAd5luTnWCX0d7r5WU04WLuIa3VDvLFX8Gaj.IcdYoREfY5HIxTbNG0zXEGAgXmnALzt.SHAAEXBrbn1TY6BEnQ72O1I1.BFUqeOQN.QQSbuRVWMqAag- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B2A7B0.2040508@netconfcentral.com> Date: Mon, 25 Aug 2008 05:38:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B067E8.7040206@netconfcentral.com> <20080825.112710.258053439.mbj@tail-f.com> In-Reply-To: <20080825.112710.258053439.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > [removed cc: netconf, since I just comment on the YANG bits] > > Andy Bierman wrote: >> Note that YANG cannot support the definition of a registration >> QName (element name) because it would be interpreted as a >> database leaf, not a registration leaf. >> >> What if we had a generic object identifier statement >> for YANG, that was top-level only (body-stmt), and >> was used to define the YANG equivalent of registration OIDs? >> >> module yang { >> >> ... >> >> identifier data-not-unique { >> status current; >> description >> "YANG error-app-tag identifier for an unique >> statement violation during the validation of >> a NETCONF configuration database."; >> reference >> "draft-ietf-netmod-yang-00.txt, sec. E.1"; >> } >> >> ... >> } > > > So when an "error-app-tag" statement is used, it MUST refer to an > existing identifier? In the current module or some other module: > > import foo { prefix foo; } > ... > error-app-tag foo:fatal-error; > yes > > Can the identifiers defined with this statement be used for something > else than just error-app-tag? Is the idea that they can be used like > OBJECT-IDENTITY - if so, do we also need a corresponding builtin type > "identifier" (or better name) which is encoded as a QName: > > leaf encryption-method { > type identifier; > } > > identifier des3 { ... } > identifier aes128 { ... } > > yes -- that is the main purpose. SNMP has a registration OID mechanism. The YANG approach (keep augmenting a choice with empty leafs) is pretty lame. YANG needs some sort of ID-only node to solve this correctly. Either assuming a bunch of IANA registries will be created, or simply ignoring naming collisions, seems like a bad idea. > /martin > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 06:13:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C553A68AF; Mon, 25 Aug 2008 06:13:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877DE3A691A for ; Mon, 25 Aug 2008 06:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEilZidokucz for ; Mon, 25 Aug 2008 06:13:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 398A33A68AF for ; Mon, 25 Aug 2008 06:13:29 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92DB5209F3; Mon, 25 Aug 2008 15:10:43 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-a7-48b2af53048c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 775332094B; Mon, 25 Aug 2008 15:10:43 +0200 (CEST) Received: from esealmw121.eemea.ericsson.se ([153.88.200.80]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 15:10:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 15:10:37 +0200 Message-ID: In-Reply-To: <20080825102256.GB23809@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] various defaults discussions Thread-Index: AckGnI8kwwR3kJnmTACazyvvCwBh2wAFTBQg References: <1219647340.6265.28.camel@missotis> <20080825080420.GA23200@elstar.local> <20080825102256.GB23809@elstar.local> From: "Peter Loborg" To: X-OriginalArrivalTime: 25 Aug 2008 13:10:38.0475 (UTC) FILETIME=[F7E655B0:01C906B3] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > > Hmmm - you seem to consider machine-human interaction with one node with > > a fairly long session time. That's rather opposite to our experience of > > management tool operations - it's a machine-machine interaction (no > > problems with "noise") and the human sits on the other end of a > > configuration tool. The tool will do the information filtering/hiding > > based on user preferences. > > If there is such a tool, great. However, there are many operational > environments without such tools and I believe we make a mistake if we > ignore them. I think it would be a mistake to think that any serious usage of Netconf will happen without the usage of at least some "dumb" tool support, a tool that given the yang models will actually present what's there and allow you to see and turn all knobs. And obviously, whatever we decide about e.g. sending or not sending defaults over the wire, even this type of tool will manage to fill in such blanks. As for SNMP there will probably exist a bunch of freeware Netmod/Yang tools with this basic capability... (possibly student projects from some university...) > > Right now, NETCONF implementations show different behaviour in a > number of places and we need to work through this or you will end up > with a vague standard that everybody implements in his own way - this > is IMHO worse for interoperability than a bunch of capabilities. > Agree completely! > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 06:30:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6646A3A6CE0; Mon, 25 Aug 2008 06:30:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008C23A6FC7 for ; Mon, 25 Aug 2008 06:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1ws453MdzLP for ; Mon, 25 Aug 2008 06:30:11 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 2580E3A69E7 for ; Mon, 25 Aug 2008 06:30:11 -0700 (PDT) Received: (qmail 84307 invoked from network); 25 Aug 2008 13:22:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.104 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2008 13:22:36 -0000 X-YMail-OSG: L3en_GQVM1lKRQr6S8YYJFRe_SEfV.rG_y0cucDiM7AdwFV0LxtmNXz508kGmsRyI3Fs4y1bWSX3QcRsGcLOMc4gM7gCIuS2JmCOEDkEYSjy.xCroiHXOKu4W3qT4Nk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B2B219.3050304@netconfcentral.com> Date: Mon, 25 Aug 2008 06:22:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <20080822114045.GA22613@elstar.local> <20080823.110453.118380885.mbj@tail-f.com> <48B00FB4.8020502@netconfcentral.com> <20080824.104320.36262059.mbj@tail-f.com> In-Reply-To: <20080824.104320.36262059.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Fri, Aug 22, 2008 at 01:00:14PM +0200, David Partain wrote: >>>> >>>>> Martin suggested that the specification say "Elements without a namespace >>>>> refer to nodes in the current module" and received very few comments on that suggestion (Phil liked it). >>>> Clarification: I think this implies that YANG translators have to >>>> transform expressions by adding the correct prefixes since outside the >>>> YANG context, prefixes are required. (Correct me if I am wrong.) >>> Note that YANG does not reqiure an implementaton of XPath at all. An >>> implementation is free to code the restrictions by hand. >>> >> But a YANG to YIN or YANG to DSDL translator does need to >> deal with prefix conversion. Clearly the 'no prefix==local module' >> rule only applies within a YANG file, not YIN, not XML or any kind. > > As long as we're talking about must expressions, I do not agree. The > rule that "Elements without a namespace refer to nodes in the current > module" (from -01) for must expressions applies to YIN as well. > What is the rationale for this decision? It seems to me the YIN version should be straight XML, ready to input to XML tools that do not know about YANG modules. > For DSDL, you may be right. But I don't think we have agreed exactly > what the DSDL mapping will be used for, or how. That's another > discussion though. It is the implementation choice that the IESG decided it likes best. When implementing NETCONF, whether you process YANG files directly, or process DSDL files directly, or some combination, or something else entirely -- has no impact whatsoever on your RFC 4741 conformance. > > > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 06:42:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24B93A686E; Mon, 25 Aug 2008 06:42:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13B53A696C for ; Mon, 25 Aug 2008 06:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGMocxq3zd2d for ; Mon, 25 Aug 2008 06:42:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47C943A7026 for ; Mon, 25 Aug 2008 06:42:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE3A3C0020; Mon, 25 Aug 2008 15:40:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ILd0wW6uTP+t; Mon, 25 Aug 2008 15:40:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5394BC003C; Mon, 25 Aug 2008 15:40:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE1136AF146; Mon, 25 Aug 2008 15:40:15 +0200 (CEST) Date: Mon, 25 Aug 2008 15:40:15 +0200 From: Juergen Schoenwaelder To: Peter Loborg Message-ID: <20080825134015.GA24647@elstar.local> Mail-Followup-To: Peter Loborg , Ladislav Lhotka , NETMOD Working Group References: <1219647340.6265.28.camel@missotis> <20080825080420.GA23200@elstar.local> <20080825102256.GB23809@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Aug 25, 2008 at 03:10:37PM +0200, Peter Loborg wrote: > I think it would be a mistake to think that any serious usage of Netconf > will happen without the usage of at least some "dumb" tool support, a > tool that given the yang models will actually present what's there and > allow you to see and turn all knobs. And obviously, whatever we decide > about e.g. sending or not sending defaults over the wire, even this type > of tool will manage to fill in such blanks. As for SNMP there will > probably exist a bunch of freeware Netmod/Yang tools with this basic > capability... (possibly student projects from some university...) I agree with the "dumb" tool support. Given the experience of SNMP, I do not agree with the general availability of "smarter than dump" tool support. And the question on the table is not anymore how defaults can be suppressed; the question has meanwhile become what _is_ configuration. I am in the camp of those who believe a device needs to distinguish between what has been "configured" by an explicit action from the outside world and what exists implicitely as part of the devices "default" settings or generated by the device based on other settings. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 07:05:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661823A7029; Mon, 25 Aug 2008 07:05:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC403A7028 for ; Mon, 25 Aug 2008 07:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql1smqEFTmMf for ; Mon, 25 Aug 2008 07:05:50 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 872C53A7034 for ; Mon, 25 Aug 2008 07:05:50 -0700 (PDT) Received: (qmail 29708 invoked from network); 25 Aug 2008 14:04:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.104 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2008 14:04:57 -0000 X-YMail-OSG: 0Uw30dYVM1lnh_ZRCpRjX8Tg1DlLiYGvUn7kqgfRJ8lXbC60ar7OdaD0.2LfjYjiDRtYDNe1YcSawJqn7.YgtCAnZ6UFr9kkU5E2CpNZJQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B2BC07.2020801@netconfcentral.com> Date: Mon, 25 Aug 2008 07:04:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] E.1 details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, E.1. Error Message for Data that Violates a YANG unique Statement: If a NETCONF operation would result in configuration data where a unique constraint is invalidated, the following error is returned: Tag: operation-failed Error-app-tag: data-not-unique Error-info: : Contains an instance identifier which points to a leaf which invalidates the unique constraint. This element is present once for each leaf invalidating the unique constraint. The element is in the YANG namespace ("urn:ietf:params:xml:ns:yang:1" [XXX IANA]). 1) Why is a new element needed? The existing in the NETCONF NS should be used instead. The application knows from the error-app-tag what to expect. 2) One is generated for each unique-stmt within the list which has non-unique leafs. This is not that clear from the Error-info last sentence. 3) There is no way to identify which uniq-stmt failed when a list has more than 1 of them defined. In my implementation, I have a element, and I'm stuffing the line number of the unique-stmt in there. (Not that elegant ;-) There are no CLRs on unique-stmts. The same leafs or even the same statements can appear any number of times. 4) Identifying the leaf(s) that are not unique is not really good enough, and it could be a lot of redundant data. What you really want here are the instance identifiers of all the list entries which are involved in the 'duplication collision'. There will be at least 2 of them. 5) The error-path is problematic. Does it identify the parent of the list entries (may not be any), or one of the list entries, or just an object identifier (not an instance identifier) of the list definition? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 07:31:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC953A6FC3; Mon, 25 Aug 2008 07:31:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800343A6A63 for ; Mon, 25 Aug 2008 07:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQnh84lyE0XL for ; Mon, 25 Aug 2008 07:31:20 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 0643D28C2CB for ; Mon, 25 Aug 2008 07:31:03 -0700 (PDT) Received: (qmail 96872 invoked from network); 25 Aug 2008 14:31:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.104 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2008 14:31:01 -0000 X-YMail-OSG: Vq3ZPMgVM1mE.adCdXaSVZIvq1jMoMvuqYkJUj5.QollnQLNNyhnFv1GTJJBcekzjlEPfO1htObNW9sgbFggRJyP2GJDrmkb40pMy.hTQQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B2C223.5070708@andybierman.com> Date: Mon, 25 Aug 2008 07:30:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] unique-stmt poorly defined X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Most of the YANG constructs are documented well enough to implement, but not the unique-stmt. According to the text in 7.8.3 (what there is of it), the following YANG is legal. Is this the intent of this feature? list foo { key a; unique "b c/d"; unique "a c/f"; unique "c/d c/h/j c/e b"; unique "c/d c/bar:augleaf"; // external augment leaf a { type int32; } leaf b { type int32; } list c { key "aa bb cc"; leaf aa { type int32; } leaf bb { type int32; } leaf cc { type int32; } leaf d { type int32; } choice e { leaf e { type int32; } case e2 { leaf f { type int32; } leaf g { type int32; } } case e3 { list h { key i; leaf i { type int32; } leaf j { type int32; } } } } } } If deep keys are too complicated, then unique-stmt is also too complicated. Why does the key-stmt restrict the list to child leaf identifiers, but unique-stmt does not do the same? The current 'rules' allow way too much unintended garbage, and the unique-stmt is not very implementable or useful defined this way. Are choice and case names supposed to be included in the descendant-node-id or not? In my example they are left out. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 07:35:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA693A6D01; Mon, 25 Aug 2008 07:35:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86E13A6D01 for ; Mon, 25 Aug 2008 07:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha4V0CJ9ARbj for ; Mon, 25 Aug 2008 07:35:19 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 056DC28C2BE for ; Mon, 25 Aug 2008 07:35:16 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 07:35:00 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 07:18:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 07:18:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 07:18:26 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7PEIPu45785; Mon, 25 Aug 2008 07:18:25 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7PEEqma056560; Mon, 25 Aug 2008 14:14:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808251414.m7PEEqma056560@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1219652468.6265.51.camel@missotis> Date: Mon, 25 Aug 2008 10:14:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 14:18:26.0362 (UTC) FILETIME=[708CA1A0:01C906BD] Cc: NETMOD Working Group Subject: Re: [netmod] defaults and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >Not necessarily. DSDL is designed to handle such cases: default values >defined in a DSRL schema are used for validation if the corresponding >elements are empty or not present in the instance document. So the >manager could do the same and first assume defaults where the >corresponding leaf is missing. Cool. This is exactly the behavior we are aiming for in YANG. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 09:42:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3ED28C24F; Mon, 25 Aug 2008 09:42:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEED3A67E9 for ; Mon, 25 Aug 2008 09:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHELLjUv7lXt for ; Mon, 25 Aug 2008 09:42:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 26AAA3A6956 for ; Mon, 25 Aug 2008 09:42:19 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 33A9476C4DE; Mon, 25 Aug 2008 18:42:07 +0200 (CEST) Date: Mon, 25 Aug 2008 18:42:06 +0200 (CEST) Message-Id: <20080825.184206.52024501.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B2A7B0.2040508@netconfcentral.com> References: <48B067E8.7040206@netconfcentral.com> <20080825.112710.258053439.mbj@tail-f.com> <48B2A7B0.2040508@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > > Can the identifiers defined with this statement be used for something > > else than just error-app-tag? Is the idea that they can be used like > > OBJECT-IDENTITY - if so, do we also need a corresponding builtin type > > "identifier" (or better name) which is encoded as a QName: > > leaf encryption-method { > > type identifier; > > } > > identifier des3 { ... } > > identifier aes128 { ... } > > > > yes -- that is the main purpose. > SNMP has a registration OID mechanism. I support this idea. > The YANG approach (keep augmenting a choice > with empty leafs) is pretty lame. I agree it's sort of not obvious. It's actually more powerful than OBJECT IDENTITY/OBJECT ODENTIFIER, b/c you cannot restrict the OID in the model; there is no formal way to know which values the 'encryotion-method' object above might get. E.g. there is no way to known that you cannot set 'encryotion-method' to 'data-not-unique'. If the 'encryption-method' is a choice, each value is an augment and thus very specific. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 09:46:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1251A3A6814; Mon, 25 Aug 2008 09:46:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE833A6814 for ; Mon, 25 Aug 2008 09:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVZDElzNi7HR for ; Mon, 25 Aug 2008 09:46:25 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D7F463A6A39 for ; Mon, 25 Aug 2008 09:46:24 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 22D6576C4DE; Mon, 25 Aug 2008 18:45:58 +0200 (CEST) Date: Mon, 25 Aug 2008 18:45:55 +0200 (CEST) Message-Id: <20080825.184555.238267928.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B2B219.3050304@netconfcentral.com> References: <48B00FB4.8020502@netconfcentral.com> <20080824.104320.36262059.mbj@tail-f.com> <48B2B219.3050304@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] XML encoding rules for built-in types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Juergen Schoenwaelder wrote: > >>>> On Fri, Aug 22, 2008 at 01:00:14PM +0200, David Partain wrote: > >>>> > >>>>> Martin suggested that the specification say "Elements without a namespace > >>>>> refer to nodes in the current module" and received very few comments on that suggestion (Phil liked it). > >>>> Clarification: I think this implies that YANG translators have to > >>>> transform expressions by adding the correct prefixes since outside the > >>>> YANG context, prefixes are required. (Correct me if I am wrong.) > >>> Note that YANG does not reqiure an implementaton of XPath at all. An > >>> implementation is free to code the restrictions by hand. > >>> > >> But a YANG to YIN or YANG to DSDL translator does need to > >> deal with prefix conversion. Clearly the 'no prefix==local module' > >> rule only applies within a YANG file, not YIN, not XML or any kind. > > As long as we're talking about must expressions, I do not agree. The > > rule that "Elements without a namespace refer to nodes in the current > > module" (from -01) for must expressions applies to YIN as well. > > > > What is the rationale for this decision? > It seems to me the YIN version should be straight XML, > ready to input to XML tools that do not know about YANG modules. Maybe we're talking about different things. Standard XML tools that do not know about YANG modules does not know how to interpret the must expression, so for them it's just a string. I'm saying that if the YANG statement is: must "foo:a = current()"; then the YIN statement is: No prefix translation in the YIN translation. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 10:00:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC003A6D66; Mon, 25 Aug 2008 10:00:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E36F28C266 for ; Mon, 25 Aug 2008 10:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoK7A65BW1Vp for ; Mon, 25 Aug 2008 10:00:13 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 4F57D28C1A6 for ; Mon, 25 Aug 2008 09:59:37 -0700 (PDT) Received: (qmail 25514 invoked from network); 25 Aug 2008 16:59:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2008 16:59:36 -0000 X-YMail-OSG: PHePXKUVM1lfYSfSEHoNJCW36ewF0gjp3mPP9PzFmjEHHhsL5ZLOzIExTA5pTDuHwrMoUmK_ZouX8d2dSx4NHIlNRlzdhJvt5QWGAbGNu0G3O6yRTRantv3OBCiHl1o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B2E4F6.4020808@netconfcentral.com> Date: Mon, 25 Aug 2008 09:59:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B067E8.7040206@netconfcentral.com> <20080825.112710.258053439.mbj@tail-f.com> <48B2A7B0.2040508@netconfcentral.com> <20080825.184206.52024501.mbj@tail-f.com> In-Reply-To: <20080825.184206.52024501.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>> Can the identifiers defined with this statement be used for something >>> else than just error-app-tag? Is the idea that they can be used like >>> OBJECT-IDENTITY - if so, do we also need a corresponding builtin type >>> "identifier" (or better name) which is encoded as a QName: >>> leaf encryption-method { >>> type identifier; >>> } >>> identifier des3 { ... } >>> identifier aes128 { ... } >>> >> yes -- that is the main purpose. >> SNMP has a registration OID mechanism. > > I support this idea. > >> The YANG approach (keep augmenting a choice >> with empty leafs) is pretty lame. > > I agree it's sort of not obvious. It's actually more powerful than > OBJECT IDENTITY/OBJECT ODENTIFIER, b/c you cannot restrict the OID in > the model; there is no formal way to know which values the > 'encryotion-method' object above might get. E.g. there is no way to > known that you cannot set 'encryotion-method' to 'data-not-unique'. > > If the 'encryption-method' is a choice, each value is an augment and > thus very specific. > This is true, and these are used more often for read-only data. In reality, the manager needs to know which module contains the 'identify' or the 'augment', and know what it means. A bunch of leaf x (identifies platform x) leaf y, etc. is no better than identifier x,y for this purpose. An invalid-value comes back either way if you send the ID for a chassis fan when the agent expects the ID of the encryption method. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 10:02:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888B43A67D4; Mon, 25 Aug 2008 10:02:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16893A67A4 for ; Mon, 25 Aug 2008 10:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FJqVElftKBW for ; Mon, 25 Aug 2008 10:02:56 -0700 (PDT) Received: from chip3og51.obsmtp.com (chip3og51.obsmtp.com [64.18.14.167]) by core3.amsl.com (Postfix) with ESMTP id C34273A63D2 for ; Mon, 25 Aug 2008 10:02:53 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob51.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 10:02:45 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 08:32:25 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 08:32:25 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 08:32:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7PFWOu79494; Mon, 25 Aug 2008 08:32:24 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7PFSpTx056979; Mon, 25 Aug 2008 15:28:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808251528.m7PFSpTx056979@idle.juniper.net> To: "Peter Loborg" In-reply-to: Date: Mon, 25 Aug 2008 11:28:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 15:32:24.0827 (UTC) FILETIME=[C614A4B0:01C906C7] Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Peter Loborg" writes: >I think it would be a mistake to think that any serious usage of Netconf >will happen without the usage of at least some "dumb" tool support... But even with tools, human users do not immediately disappear. The configuration on the box will continue to be something users look at. Throwing in uninteresting defaults is a non-starter. Consider Simon's case of a dynamic default. It's a more interesting value than a static default, but you cannot (MUST NOT) confuse the current value with configuration. (Imagine running rancid on that ever-changing config.) Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 12:17:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4013A6803; Mon, 25 Aug 2008 12:17:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3961E3A6964 for ; Mon, 25 Aug 2008 12:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oADizjdPS8bh for ; Mon, 25 Aug 2008 12:17:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 09FF63A6803 for ; Mon, 25 Aug 2008 12:17:54 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 44D0076C4DE; Mon, 25 Aug 2008 21:17:39 +0200 (CEST) Date: Mon, 25 Aug 2008 21:17:38 +0200 (CEST) Message-Id: <20080825.211738.221759182.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B2BC07.2020801@netconfcentral.com> References: <48B2BC07.2020801@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] E.1 details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > E.1. Error Message for Data that Violates a YANG unique Statement: > > If a NETCONF operation would result in configuration data where a > unique constraint is invalidated, the following error is returned: > > Tag: operation-failed > Error-app-tag: data-not-unique > Error-info: : Contains an instance identifier which > points to a leaf which invalidates the unique > constraint. This element is present once for each > leaf invalidating the unique constraint. > > The element is in the YANG > namespace ("urn:ietf:params:xml:ns:yang:1" > [XXX IANA]). > > 1) Why is a new element needed? > The existing in the NETCONF NS should be used instead. > The application knows from the error-app-tag what to expect. is just a QName. The is an instance identifier. But see below. > 2) One is generated for each unique-stmt within > the list which has non-unique leafs. This is not that clear > from the Error-info last sentence. Yes, but rfc4741 says that an implementation can choose to report the first error only, and I don't think we should change that here. > 3) There is no way to identify which uniq-stmt failed when a > list has more than 1 of them defined. In my implementation, > I have a element, and I'm stuffing the line number > of the unique-stmt in there. (Not that elegant ;-) > There are no CLRs on unique-stmts. The same leafs or > even the same statements can appear any number of times. > > 4) Identifying the leaf(s) that are not unique is not really > good enough, and it could be a lot of redundant data. Since all leafs are identified, you know which unique statement was invalidated, except if there are more than one exactly equal. But if they are equal it doesn't really matter which one of them it was... Again, see below. > What you really want here are the instance identifiers > of all the list entries which are involved in the > 'duplication collision'. There will be at least 2 of them. You are right. It is probably better and easier if the error could contain the two (or more) list instance identifiers, and a reference to the unique statement. But as you noted there is no such way currently. We would need something like unique address { // address is the identifier leafs "a/ip a/port"; } If we do this, or something similar, we should also change the corresponding error. > 5) The error-path is problematic. Does it identify the > parent of the list entries (may not be any), or > one of the list entries, or just an object identifier > (not an instance identifier) of the list definition? IMO, error-path is often problematic. Some time ago you clarified that the error-path is supposed to start with the '/rpc' node. So you might get /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server. But what if the operation that made the unique error was : If the error-path starts w/ rpc, what would it contain? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 12:34:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910553A684C; Mon, 25 Aug 2008 12:34:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AE83A6978 for ; Mon, 25 Aug 2008 12:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQkz865DAbTS for ; Mon, 25 Aug 2008 12:34:34 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 612C63A684C for ; Mon, 25 Aug 2008 12:34:34 -0700 (PDT) Received: (qmail 3008 invoked from network); 25 Aug 2008 19:33:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2008 19:33:28 -0000 X-YMail-OSG: _5jJ9TcVM1k5.Bm.7WVQWX.tUOmHwxkNEmcgodA4a09G2RyN4DvUu6.hr5rHu6egyCTZVNEW36nY5Nao9mjI1HxeWuasXvwH4gvPULjB7e_pNOOOZrAsjdMO0hR_N0w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B30906.4010302@netconfcentral.com> Date: Mon, 25 Aug 2008 12:33:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B2BC07.2020801@netconfcentral.com> <20080825.211738.221759182.mbj@tail-f.com> In-Reply-To: <20080825.211738.221759182.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] E.1 details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >.. You are right about . Too bad. I want as few of these 'extra bits' as possible. > IMO, error-path is often problematic. Some time ago you clarified > that the error-path is supposed to start with the '/rpc' node. So you > might get /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server. No, actually you would get the instance identifiers for list 'server' /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server[name='fred'] /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server[name='barney'] If I just get back 1 leaf ID (foo:knob), I don't know what clashed: /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server[name='fred']/foo:knob > > But what if the operation that made the unique error was : > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > If the error-path starts w/ rpc, what would it contain? You are right. For the operation, the eror-path values should start at a top-level node in a config-db namespace. For on 'running' you can include the path back to 'rpc'. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Aug 25 13:43:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C9E3A6B9A; Mon, 25 Aug 2008 13:43:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF193A6BA4 for ; Mon, 25 Aug 2008 13:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV26TwOSHHhe for ; Mon, 25 Aug 2008 13:43:22 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 94D3D3A6B9A for ; Mon, 25 Aug 2008 13:43:21 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id E9F48616001; Mon, 25 Aug 2008 22:43:00 +0200 (CEST) Date: Mon, 25 Aug 2008 22:42:59 +0200 (CEST) Message-Id: <20080825.224259.99161198.mbj@tail-f.com> To: andy@andybierman.com From: Martin Bjorklund In-Reply-To: <48B2C223.5070708@andybierman.com> References: <48B2C223.5070708@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] unique-stmt poorly defined X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > Most of the YANG constructs are documented well enough > to implement, but not the unique-stmt. According > to the text in 7.8.3 (what there is of it), > the following YANG is legal. Is this the > intent of this feature? In our DML we could only express uniqueness for leafs within a list entry. But consider this (simplified) case, where an interface has a list of addresses: list interface { ... list address { ... leaf ip { type inet:ipv4address; } } } I want to say that all values of 'ip' must be unique across all interfaces: list interface { ... unique "address/ip"; ... } It will not be possible to refer to augmented nodes. It would violate the rule that all references can be resolved and verified within a module. The same is true for must expressions etc. I agree that it is unclear how it will work with choice. I have to think some more about this. > Are choice and case names supposed to be included in the > descendant-node-id or not? In my example they are left out. The unique argument is a list of schema node identifiers, so choice and case names are included. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 02:15:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552D43A6A05; Tue, 26 Aug 2008 02:15:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FA73A6A5F for ; Tue, 26 Aug 2008 02:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.56 X-Spam-Level: X-Spam-Status: No, score=0.56 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjtBvGeN6lbs for ; Tue, 26 Aug 2008 02:15:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E55793A6A05 for ; Tue, 26 Aug 2008 02:15:47 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6ECDBD800C4 for ; Tue, 26 Aug 2008 11:15:12 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Tue, 26 Aug 2008 11:15:12 +0200 Message-Id: <1219742112.6511.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] rpc output X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, the example in section 4.2.9 RPC Definitions uses the element from the netconf namespace that encapsulates the result, but it is not defined by the rpc statement. Is it a convention accepted for YANG? RFC 4741 doesn't say that must be always directly under . Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 04:32:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1226C3A6967; Tue, 26 Aug 2008 04:32:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE2A3A6AEF for ; Tue, 26 Aug 2008 04:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM9zbyuwvZ+X for ; Tue, 26 Aug 2008 04:31:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D425B3A6AEE for ; Tue, 26 Aug 2008 04:31:58 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 028E276C4DF; Tue, 26 Aug 2008 13:31:58 +0200 (CEST) Date: Tue, 26 Aug 2008 13:31:58 +0200 (CEST) Message-Id: <20080826.133158.213136539.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1219742112.6511.10.camel@missotis> References: <1219742112.6511.10.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] rpc output X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > the example in section 4.2.9 RPC Definitions uses the element > from the netconf namespace that encapsulates the result, but it is not > defined by the rpc statement. Is it a convention accepted for YANG? RFC > 4741 doesn't say that must be always directly under . In the upcoming -01 draft, I have added subsections "XML encoding Rules" for rpc and notification (they were missing). The example you mention will be aligned to these rules as well. I also brought up this issue on the netconf list. The problem is that the text and XSD in rfc 4741 differ. In this case, I think the XSD is buggy, but the text could also be clarified. In the exmple, will go, and the encoding will be: The image acmefw-2.3 is being installed. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 04:34:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654BF3A6AEF; Tue, 26 Aug 2008 04:34:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678F928C10C for ; Tue, 26 Aug 2008 04:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOJ+si1gs84z for ; Tue, 26 Aug 2008 04:34:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 76CC33A6AF7 for ; Tue, 26 Aug 2008 04:34:15 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 08FA620FFE for ; Tue, 26 Aug 2008 13:34:16 +0200 (CEST) X-AuditID: c1b4fb3e-a5e7fbb000007a96-6e-48b3ea3756f7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DFE6420FCD for ; Tue, 26 Aug 2008 13:34:15 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 13:34:11 +0200 Received: from selic023.ki.sw.ericsson.se ([147.214.33.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 13:34:11 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 26 Aug 2008 13:34:25 +0200 User-Agent: KMail/1.9.9 References: <200808131631.m7DGV63e016696@idle.juniper.net> <48A3304F.8050603@netconfcentral.com> In-Reply-To: <48A3304F.8050603@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808261334.25963.david.partain@ericsson.com> X-OriginalArrivalTime: 26 Aug 2008 11:34:11.0106 (UTC) FILETIME=[A8C5A820:01C9076F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] YANG conformance idea -- take two X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wednesday 13 August 2008 21.04.47 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> NETCONF has no such definition of config. > > > > But it does: > > > > Configuration data is the set of writable data that is required to > > transform a system from its initial default state into its current > > state. > > > >> YANG has no concept of conformance that actually > >> accounts for the way that compromises are made in standard > >> data models. > > > > I hope we are creating such mechanisms, with the feature feature > > and device deviations. > > I am on board with the feature feature. :-) > You sold me on that already. Hi all, I've just re-re-read through this thread to see if I can get a sense of what's happened. As I see it, the discussion has been about the idea that Martin proposed at the recent IETF (see slides 2-5 of http://www3.ietf.org/proceedings/08jul/slides/netmod-7.pdf) to add a "feature" feature to allow model designers to make implementation of some things in the model conditional. Andy, Phil, and Martin are all in favor of this. So are the IPFIX folks (the idea originated with them). I think that it's a good idea as wel, but I'd like to know what the rest of the WG thinks. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 10:44:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78483A67D8; Tue, 26 Aug 2008 10:44:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D13528C1F7 for ; Tue, 26 Aug 2008 10:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSV15k121DSm for ; Tue, 26 Aug 2008 10:44:48 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 84BA93A67D8 for ; Tue, 26 Aug 2008 10:44:47 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 707T1a00A0Fqzac595kodE; Tue, 26 Aug 2008 17:44:48 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 75ko1a00F4HwxpC3U5kojM; Tue, 26 Aug 2008 17:44:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=Zrfv_BRPE-5i_JSQAh4A:9 a=ekIvKaY4-q9ir5R2T3oA:7 a=Uo4KabPIg1oVM6BHLWM12SRV674A:4 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10 From: "David Harrington" To: "'Phil Shafer'" , "'Andy Bierman'" References: <48B01267.8000305@netconfcentral.com> <200808250241.m7P2faFB051668@idle.juniper.net> Date: Tue, 26 Aug 2008 13:44:48 -0400 Message-ID: <024301c907a3$6f76f360$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200808250241.m7P2faFB051668@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckGXRwafYfueqGnS9+xjYfHyQq/8wBRkUPA Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I think "implicit" is far less understandable than agent-created or agent-aupplied. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Sunday, August 24, 2008 10:42 PM > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] various defaults discussions > > Andy Bierman writes: > >This text clearly says the defaults exist for the purpose of > >must-stmt evaluation. IMO, this text should be clarified > >to say 'all agent-created configuration nodes'. > > "agent-created" and "agent-supplied" are misleading names, since > there's no requirement for the agent to ever created these nodes. > Would "implicit nodes" be an acceptable term? > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 10:49:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C8B3A6B32; Tue, 26 Aug 2008 10:49:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AC03A6BB0 for ; Tue, 26 Aug 2008 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpF09u8LxNT9 for ; Tue, 26 Aug 2008 10:49:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B1D0B28C1EF for ; Tue, 26 Aug 2008 10:49:50 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5641520BA0; Tue, 26 Aug 2008 19:49:51 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-48-48b4423fba27 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 386222011F; Tue, 26 Aug 2008 19:49:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 19:49:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 19:49:50 +0200 Message-ID: <48B4421B.9040208@ericsson.com> Date: Tue, 26 Aug 2008 19:49:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48B2BC07.2020801@netconfcentral.com> <20080825.211738.221759182.mbj@tail-f.com> In-Reply-To: <20080825.211738.221759182.mbj@tail-f.com> X-OriginalArrivalTime: 26 Aug 2008 17:49:50.0996 (UTC) FILETIME=[2397ED40:01C907A4] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] E.1 details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > IMO, error-path is often problematic. Some time ago you clarified > that the error-path is supposed to start with the '/rpc' node. So you > might get /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server. > > But what if the operation that made the unique error was : > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > If the error-path starts w/ rpc, what would it contain? > Why does the error-path start with the RPC? From the message ID we anyway know what the RPC was. What additional info do we get? Let's say I define a custom RPC rpc reset-interface-config ; without any input or output. This may change the configuration in a way that violates a "must". Now error-path should start with /xx:reset-interface-config but should point to a list with a must that never appeared in the rpc. Strange. I always thought error-path points into the datastore independent of the rpc that caused the problem. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 11:36:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CA03A6BBC; Tue, 26 Aug 2008 11:36:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6F73A6BBC for ; Tue, 26 Aug 2008 11:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyqFC70u0C4u for ; Tue, 26 Aug 2008 11:36:12 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 8E1033A6BBD for ; Tue, 26 Aug 2008 11:36:12 -0700 (PDT) Received: (qmail 95744 invoked from network); 26 Aug 2008 18:36:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 26 Aug 2008 18:36:01 -0000 X-YMail-OSG: 5zjp9XoVM1mCbYmFc_jCGA257kTPGYzUoDMI8J5iTfaYsOMvmAzft5MzVOonrSPyXFAkaYDepRPBvo6AMYiBUmrdWpUf8hs8ahqDqV6Hlw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B44D10.3050409@netconfcentral.com> Date: Tue, 26 Aug 2008 11:36:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <48B2BC07.2020801@netconfcentral.com> <20080825.211738.221759182.mbj@tail-f.com> <48B4421B.9040208@ericsson.com> In-Reply-To: <48B4421B.9040208@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] E.1 details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > > > Martin Bjorklund wrote: >> IMO, error-path is often problematic. Some time ago you clarified >> that the error-path is supposed to start with the '/rpc' node. So you >> might get /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server. >> >> But what if the operation that made the unique error was : >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> >> >> If the error-path starts w/ rpc, what would it contain? >> It's really simple. If the element causing the error is within the input PDU, then the error-path needs to identify that element. It doesn't for this special case, where the error is not actually contained in the input. > Why does the error-path start with the RPC? From the message ID we > anyway know what the RPC was. What additional info do we get? > > Let's say I define a custom RPC > > rpc reset-interface-config ; > > without any input or output. This may change the configuration in a way > that violates a "must". > Now error-path should start with /xx:reset-interface-config but should > point to a list with a must that never appeared in the rpc. Strange. > No -- it the error is just in the config then you have to start the error-path from the top of the config. Applications should handle either form. > I always thought error-path points into the datastore independent of the > rpc that caused the problem. > No -- not if the element that caused the error can be identified in the input PDU. > Balazs > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 12:40:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722583A6405; Tue, 26 Aug 2008 12:40:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0DE3A6B42 for ; Tue, 26 Aug 2008 12:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY8DXvyHzWYs for ; Tue, 26 Aug 2008 12:40:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E41963A6405 for ; Tue, 26 Aug 2008 12:40:43 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A9BFD209C0; Tue, 26 Aug 2008 21:39:45 +0200 (CEST) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-fc-48b45c015776 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9282B20555; Tue, 26 Aug 2008 21:39:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:39:45 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:39:44 +0200 Message-ID: <48B45BDD.3010904@ericsson.com> Date: Tue, 26 Aug 2008 21:39:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <200808221050.00096.david.partain@ericsson.com> <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> In-Reply-To: <48B01267.8000305@netconfcentral.com> X-OriginalArrivalTime: 26 Aug 2008 19:39:44.0996 (UTC) FILETIME=[7DEC7A40:01C907B3] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: >> Balazs Lengyel wrote: >>> > > 7.5.2. The must Statement > > The "must" statement, which is optional, takes as an argument a > string which contains an XPath expression. It is used to formally > declare a constraint on the configuration data. When a configuration > datastore is validated, all "must" constraints are conceptually > evaluated once for each corresponding instance in the datastore's > data tree, and for all leafs with default values in effect. > > > This text clearly says the defaults exist for the purpose of > must-stmt evaluation. IMO, this text should be clarified > to say 'all agent-created configuration nodes'. > > OLD: > > o The accessible tree is made up of all nodes in the data tree, and > all leafs with default values. > > NEW: > > o The accessible tree is made up of all nodes in the data tree, and > all leafs with agent-supplied values. > > What is the difference between a default value and an agent-supplied value? Can an agent supply a value if there is no default? I though the YANG contract states that if no value is given by the manager, no YANG default is specified, then the leaf does not exist. Am I wrong? What do we know about a leaf with no default if it is not explicitly set? Nothing? Or do we have 4 types of leafs? 1) mandatory-to-set: Always exist. Mandatory, has no YANG defined default. The manager must always set a value. 2) public-default: Always has some value. Not mandatory, has YANG defined default. If the manager does not set it a YANG defined default will be used. 3) hidden-default: Always has some value. Not mandatory, has no YANG defined default. If the manager does not set it the a agent defined default will be used, its value must be read to know it. 4) optional: May or may not exists/have a value. Not mandatory, has no default. If the manager does not set it it does not exist/does not have a value For 3 we should use something like system-created/set to at least indicate there will be a value. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 12:41:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BB93A6A60; Tue, 26 Aug 2008 12:41:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF303A686B for ; Tue, 26 Aug 2008 12:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VXc4iF7as2q for ; Tue, 26 Aug 2008 12:41:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0F40B3A6B42 for ; Tue, 26 Aug 2008 12:41:51 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4E51D21072; Tue, 26 Aug 2008 21:41:37 +0200 (CEST) X-AuditID: c1b4fb3e-a8e85bb000007a96-0d-48b45c71c0c3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3581920122; Tue, 26 Aug 2008 21:41:37 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:41:36 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:41:36 +0200 Message-ID: <48B45C4D.8030407@ericsson.com> Date: Tue, 26 Aug 2008 21:41:01 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <200808221050.00096.david.partain@ericsson.com> <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <1219647340.6265.28.camel@missotis> In-Reply-To: <1219647340.6265.28.camel@missotis> X-OriginalArrivalTime: 26 Aug 2008 19:41:36.0910 (UTC) FILETIME=[C0A132E0:01C907B3] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QXMgd3JpdHRlbiBlYXJsaWVyIHRoZSBleGlzdGVuY2Ugb2YgYSBub2RlIGltcGFjdHMgdGhlIGZv bGxvd2luZzoKMSkgZ2V0LCBnZXQtY29uZmlnLCBjb3B5LWNvbmZpZwoyKSB0aGUgc3VjY2VzcyBv ciBmYWlsdXJlIG9mIHRoZSBlZGl0LWNvbmZpZyBjcmVhdGUvZGVsZXRlL25vbmUgY29tbWFuZHMK CkZvciBlZGl0LWNvbmZpZyB3ZSBuZWVkIHRvIGtub3cgd2hldGhlciBhIGxlYWYgZXhpc3RzIG9y IG5vdCwgaXQgaXMgbm90IGVub3VnaCB0byBzYXkgd2hhdCB5b3UgCmdldCBpbiBnZXQtY29uZmln LgoKQmFsYXpzCgpMYWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gTWFydGluIEJqb3JrbHVuZCBww63F oWUgdiBTbyAyMy4gMDguIDIwMDggdiAxMTo1NSArMDIwMDoKPj4gQ3VycmVudGx5IHRoZSBzcGVj IHNwZWNpZmllcyB0aGF0IGRlZmF1bHRzIGFyZSBub3QgcGFydCBvZiB0aGUKPj4gY29uY2VwdHVh bCBkYXRhIHN0b3JlLiAgQnV0IG5vdCB0aGUgd29yZCBjb25jZXB0dWFsLiAgVGhpcyBkb2VzICpu b3QqCj4+IHByZWNsdWRlIGFuIGltcGxlbWVudGF0aW9uIHRvIHN0b3JlIHRoZSBkZWZhdWx0IGlu IHRoZWlyIGRhdGFiYXNlLgo+IAo+IEkgYW0gbm90IHN1cmUgd2hldGhlciAiY29uY2VwdHVhbCBk YXRhc3RvcmUiIG1lYW5zIHRoZSBzYW1lIHRoaW5nIGFzCj4gd2hhdCBJIGNhbGxlZCAiY29uY2Vw dHVhbCBkYXRhIHRyZWUiIGluIER1Ymxpbi4gQnkgdGhlIGxhdHRlciBJIG1lYW50Cj4gZXNzZW50 aWFsbHkgdGhlIHJlcGx5IHRvIDxnZXQ+IHdpdGhvdXQgYW55IGZpbHRlcnMsIGkuZS4sIFhNTC4g SWYgWUFORwo+IG1vZGVscyBhcmUgaW50ZXJwcmV0ZWQgYXMgY29udHJhY3RzIGJldHdlZW4gdGhl IGFnZW50IGFuZCBtYW5hZ2VyIHRoZW4KPiBpdCBpcyBJTU8gdGhlIG9ubHkgdGhpbmcgdGhhdCBy ZWFsbHkgbWF0dGVycy4gV2hldGhlciB0aGUgYWdlbnQgaGFzIHRoZQo+IGRlZmF1bHQgdmFsdWUg aW4gaXRzIGRhdGFiYXNlIG9yIHdoZXRoZXIgaXQgaXMgaGFyZHdpcmVkIGV0Yy4gZG9lc24ndAo+ IHNlZW0gaW1wb3J0YW50Lgo+IAo+IEluIHRoaXMgY29udGV4dCwgd2l0aCByZXNwZWN0IHRvIGRl ZmF1bHRzIGl0IGlzIG9ubHkgbmVjZXNzYXJ5IHRvIGRlY2lkZQo+IHVuZGVyIHdoYXQgY2lyY3Vt c3RhbmNlcyBhIGxlYWYgZWxlbWVudCB0aGF0IHdvdWxkIG5vcm1hbGx5IGNvbnRhaW4gdGhlCj4g ZGVmYXVsdCB2YWx1ZSBtYXkgYmUgb21pdHRlZCBpbiB0aGUgPGdldD4gb3IgPGdldC1jb25maWc+ IHJlcGx5Lgo+IAo+IExhZGEKPiAKCi0tIApCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAg ICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuClRTUCBTeXN0ZW0gTWFuYWdlcgpFQ046IDgzMSA3 MzIwICAgICAgICAgICAgICAgICAgICAgICAgRmF4OiArMzYgMSA0Mzc3NzkyClRlbDogKzM2LTEt NDM3LTczMjAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlz dApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QK From netmod-bounces@ietf.org Tue Aug 26 12:42:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2D23A696B; Tue, 26 Aug 2008 12:42:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575513A696B for ; Tue, 26 Aug 2008 12:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZoghAkg8OIA for ; Tue, 26 Aug 2008 12:42:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7DE6E3A6A03 for ; Tue, 26 Aug 2008 12:42:15 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1F10420AD6; Tue, 26 Aug 2008 21:42:07 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-5a-48b45c8f64ea Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0929820AD3; Tue, 26 Aug 2008 21:42:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:41:43 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:41:43 +0200 Message-ID: <48B45C53.6050601@ericsson.com> Date: Tue, 26 Aug 2008 21:41:07 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka , Peter Loborg , NETMOD Working Group References: <1219647340.6265.28.camel@missotis> <20080825080420.GA23200@elstar.local> <1219653542.6265.64.camel@missotis> <20080825084702.GC23239@elstar.local> In-Reply-To: <20080825084702.GC23239@elstar.local> X-OriginalArrivalTime: 26 Aug 2008 19:41:43.0613 (UTC) FILETIME=[C49FFED0:01C907B3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Aug 25, 2008 at 10:39:02AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder p????e v Po 25. 08. 2008 v 10:04 +0200: >> >>> The main motivation (as I understand it) is to ask NETCONF servers to >>> help in hiding noise from human operators; things I did not set are >>> not part of what I consider a device's configuration. Still, in some >> But assume that in one NETCONF session you explicitly set a knob to a >> value that happens to be its default value. Then, if you or someone else >> opens another session, should the value be sent in this new session? > > I would say yes. The knob was explicitely set by a management > operation, so this becomes part of the configuration. > >> I think the handling of defaults must be defined in terms of comparing >> the actual value with the default defined in the data model, not in >> terms of the previous events that may not be known anymore. > > You don't need to remember previous events; all you need is a bit > indicating "this value was set by an explicit operation and is part of > the config". The more important question really is how to clear this > bit. But I believe recording this bit on the NETCONF server is pretty > important operationally. > There are implementations that do not have this bit in their existing datastore implementations, so this bit should be a SHOULD, not a MUST. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 13:08:17 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20F53A6BD8; Tue, 26 Aug 2008 13:08:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B87A3A6BD8 for ; Tue, 26 Aug 2008 13:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KTA8ea66yOx for ; Tue, 26 Aug 2008 13:08:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7B57E3A6849 for ; Tue, 26 Aug 2008 13:08:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C0BE020DDD; Tue, 26 Aug 2008 21:42:07 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-64-48b45c8f1224 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A910D20AC8; Tue, 26 Aug 2008 21:42:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:40:45 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:40:45 +0200 Message-ID: <48B45C19.2040405@ericsson.com> Date: Tue, 26 Aug 2008 21:40:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <200808221050.00096.david.partain@ericsson.com> <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> In-Reply-To: <48B01267.8000305@netconfcentral.com> X-OriginalArrivalTime: 26 Aug 2008 19:40:45.0427 (UTC) FILETIME=[A1F18430:01C907B3] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > > 7.6.5. XML Encoding Rules > > A leaf node is encoded as an XML element. The element's name is the > leaf's identifier, and its XML namespace is the module's XML > namespace. > > The value of the leaf node is encoded to XML according to the type, > and sent as character data in the element. > > A NETCONF server that replies to a or request MAY > choose not to send the leaf element if its value is the default > value. Thus, a client that receives an for a or > request, must be prepared to handle the case that a leaf > node with a default value is not present in the XML. In this case, > the value used by the server is known to be the default value. > > > As I noted before, I strongly object para 3 above, because it > changes NETCONF protocol behavior. Also, the last sentence > is wrong. A missing node could mean it was filtered by > access control. It could mean there is no node at all. > It could mean there is an agent-supplied value. > > It will be harmful to interoperability to assume a missing > node has a YANG specified default value. > > leaf foo { type int8; default 5; } Manager issues a get request with-defaults=false and does not receive foo. This can mean: 1) foo is set to default so I don't get it 2) foo exist but I don't have the read rights to see it 3) leaf foo exists because it was explicitly set to 5, but I do not have the read rights to see it How can you separate 1) 2) and 3) ? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 13:22:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FEA3A6BE2; Tue, 26 Aug 2008 13:22:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EA43A6B90 for ; Tue, 26 Aug 2008 13:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNlA0bljzUWP for ; Tue, 26 Aug 2008 13:22:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 99FA928C236 for ; Tue, 26 Aug 2008 13:22:02 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id A0C1176C4DF; Tue, 26 Aug 2008 22:22:03 +0200 (CEST) Date: Tue, 26 Aug 2008 22:22:00 +0200 (CEST) Message-Id: <20080826.222200.115934045.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B45BDD.3010904@ericsson.com> References: <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> <48B45BDD.3010904@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > > What is the difference between a default value and an agent-supplied > value? The agent-supplied value is present in the data tree. It cannot be filtered w/ with-defaults. > Can an agent supply a value if there is no default? The spec currently does not say if an agent can or cannot do this. Users of YANG have interpreted it as if it is allowed: leaf observationPointId { description "If omitted, the Observation Point ID is assigned by the monitoring device."; (from the ipfix model). If we add the statement "assigned-by system" then we should have more strict rules. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 15:38:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485BE3A6C21; Tue, 26 Aug 2008 15:38:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0753A68AD for ; Tue, 26 Aug 2008 15:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h41615AoUery for ; Tue, 26 Aug 2008 15:38:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F19423A6894 for ; Tue, 26 Aug 2008 15:38:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A8B4720054; Wed, 27 Aug 2008 00:38:43 +0200 (CEST) X-AuditID: c1b4fb3c-af8d1bb0000015b5-8b-48b485f3f49a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C89720045; Wed, 27 Aug 2008 00:38:43 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 00:38:43 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 00:38:43 +0200 Message-ID: <48B485D0.5050700@ericsson.com> Date: Wed, 27 Aug 2008 00:38:08 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> <48B45BDD.3010904@ericsson.com> <20080826.222200.115934045.mbj@tail-f.com> In-Reply-To: <20080826.222200.115934045.mbj@tail-f.com> X-OriginalArrivalTime: 26 Aug 2008 22:38:43.0312 (UTC) FILETIME=[7E757700:01C907CC] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I like systemCreated more and more. Could we have a systemCreated with a value as well? :-) Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> What is the difference between a default value and an agent-supplied >> value? > > The agent-supplied value is present in the data tree. It cannot be > filtered w/ with-defaults. > >> Can an agent supply a value if there is no default? > > The spec currently does not say if an agent can or cannot do this. > Users of YANG have interpreted it as if it is allowed: > > leaf observationPointId { > description "If omitted, the Observation Point ID is assigned > by the monitoring device."; > > (from the ipfix model). > > If we add the statement "assigned-by system" then we should have more > strict rules. > > > /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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 16:27:43 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F923A6BEF; Tue, 26 Aug 2008 16:27:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689873A6BEF for ; Tue, 26 Aug 2008 16:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNa-CLNF37hm for ; Tue, 26 Aug 2008 16:27:41 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 598513A6C96 for ; Tue, 26 Aug 2008 16:27:41 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7QNQgD24689; Tue, 26 Aug 2008 23:26:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 19:25:29 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B416121EEB@zcarhxm2.corp.nortel.com> In-Reply-To: <48B485D0.5050700@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] various defaults discussions Thread-Index: AckHzITEi0207bJyQ5qUkhn2wRGa6QAAyxug References: <20080823.115501.104471813.mbj@tail-f.com> <48B01267.8000305@netconfcentral.com> <48B45BDD.3010904@ericsson.com> <20080826.222200.115934045.mbj@tail-f.com> <48B485D0.5050700@ericsson.com> From: "Sharon Chisholm" To: "Balazs Lengyel" , "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Implementation-specific default values must not show up in the data specification but they will show up in the implementation via some form of a get with defaults command. The only reason to even bring them up in this discussion would be if we wanted to indicate which elements we expect implementations to provide default values for (but again, not the values themselves). I'm trying to see this if this makes sense. I suppose it would help backwards compatibility since then you can add mandatory elements with some sort of tag that says a default value needs to be provided by the implementation. Sharon -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Balazs Lengyel Sent: Tuesday, August 26, 2008 6:38 PM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions I like systemCreated more and more. Could we have a systemCreated with a value as well? :-) Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> What is the difference between a default value and an agent-supplied >> value? > > The agent-supplied value is present in the data tree. It cannot be > filtered w/ with-defaults. > >> Can an agent supply a value if there is no default? > > The spec currently does not say if an agent can or cannot do this. > Users of YANG have interpreted it as if it is allowed: > > leaf observationPointId { > description "If omitted, the Observation Point ID is assigned > by the monitoring device."; > > (from the ipfix model). > > If we add the statement "assigned-by system" then we should have more > strict rules. > > > /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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 17:02:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2083A6C5C; Tue, 26 Aug 2008 17:02:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273803A6C5C for ; Tue, 26 Aug 2008 17:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzJhJP7dhXhA for ; Tue, 26 Aug 2008 17:02:33 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 28F473A6C63 for ; Tue, 26 Aug 2008 17:02:32 -0700 (PDT) Received: (qmail 23621 invoked from network); 27 Aug 2008 00:01:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 00:01:58 -0000 X-YMail-OSG: GY.HkN0VM1kneU7yFjepjijQx7z9jvtndzQqu1kb7IJAGZyK6Nc_2fzUbAcg930jIzSEeCtyyt54SNqxFK9mnMf0LR.o_XeplTxJrQPctKhKZ1UAVbyqCKxRFroFKm4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B4996A.3000408@netconfcentral.com> Date: Tue, 26 Aug 2008 17:01:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B2C223.5070708@andybierman.com> <20080825.224259.99161198.mbj@tail-f.com> In-Reply-To: <20080825.224259.99161198.mbj@tail-f.com> Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] unique-stmt poorly defined X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Most of the YANG constructs are documented well enough >> to implement, but not the unique-stmt. According >> to the text in 7.8.3 (what there is of it), >> the following YANG is legal. Is this the >> intent of this feature? > > In our DML we could only express uniqueness for leafs within a list > entry. But consider this (simplified) case, where an interface has a > list of addresses: > > list interface { > ... > list address { > ... > leaf ip { type inet:ipv4address; } > } > } > > I want to say that all values of 'ip' must be unique across all > interfaces: > > list interface { > ... > unique "address/ip"; > ... > } This doesn't seem that useful as a general mechanism. But implementing this for list or container isn't hard. A far more likely use-case is a unique leaf-list, and YANG does not support that at all. > > > It will not be possible to refer to augmented nodes. It would violate > the rule that all references can be resolved and verified within a > module. The same is true for must expressions etc. > good > I agree that it is unclear how it will work with choice. I have to > think some more about this. > yes -- specifically, what does it mean if tuple T[i] is incomplete. Is it compared to T[j] or not? (Where T = { unique-leaf1, unique-leaf2, ... }) >> Are choice and case names supposed to be included in the >> descendant-node-id or not? In my example they are left out. > > The unique argument is a list of schema node identifiers, so choice > and case names are included. > > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 17:11:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33FF3A68A0; Tue, 26 Aug 2008 17:11:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC493A6C60 for ; Tue, 26 Aug 2008 17:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtosQ9AOYL4t for ; Tue, 26 Aug 2008 17:11:04 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 2EED03A695B for ; Tue, 26 Aug 2008 17:11:04 -0700 (PDT) Received: (qmail 34116 invoked from network); 27 Aug 2008 00:10:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 00:10:39 -0000 X-YMail-OSG: yluIYRsVM1lhoJ6XLfqcjR9iDS0UvY7ouY_IZBjQg2W0XAb7gAzTsQ.f.dddzaa7ONyNwrK9oJXL5OEeBZ91QbENm7K1KEfs6WS8QRPOZA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B49B7E.4080002@netconfcentral.com> Date: Tue, 26 Aug 2008 17:10:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Access control is not considered at all for unique tests. It is possible that a user issuing the on running, or of the candidate, is not authorized to view some objects which are identified in the elements returned by the agent. Depending on the actual access control system in place, it is possible to construct attacks on the agent by manipulating list entries which the user is allowed to edit, and then receive the values of keys, and learn the existence of unauthorized list entries through and other data within the , returned for the 'data-not-unique' error in section E.1. Is this a problem or not? Note that the 'must-stmt' is allowed in many more places than the 'unique-stmt', N entries per node, and there is no data at all returned in the 'data-restriction-violation' error in E.4. IMO, the error in E.1 should work the same way. No data. no security leak. The manager has the YANG modules. It can do a and run the unique-tests itself to find out what went wrong. (If that solution is good enough for 'must-stmt', it is good enough for 'unique-stmt'). Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 19:04:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BF63A67D2; Tue, 26 Aug 2008 19:04:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3438F3A67D2 for ; Tue, 26 Aug 2008 19:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ7wB6moizvZ for ; Tue, 26 Aug 2008 19:04:39 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 5057B28C237 for ; Tue, 26 Aug 2008 19:04:39 -0700 (PDT) Received: (qmail 17015 invoked from network); 27 Aug 2008 02:04:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 02:04:39 -0000 X-YMail-OSG: YU0NDb8VM1mVyNDkIhGWvqKKu7gS2FWabHQY2WhbusHLXFAcTffdKGp7hFaCGoBVbdSGpiMLAnbt_4eHKtsarNal7aRh3v7KyDs6_MsLdCZkt96UBFSp7ejk.BlNx6U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B4B635.40506@netconfcentral.com> Date: Tue, 26 Aug 2008 19:04:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B1B861.3060002@netconfcentral.com> <20080824.224330.107351011.mbj@tail-f.com> <48B1CE15.1060709@netconfcentral.com> <20080825.111842.263460825.mbj@tail-f.com> In-Reply-To: <20080825.111842.263460825.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Where is 'created-by-system' defined? >> I do not know the details this proposal. > > See: > > http://www.ietf.org/mail-archive/web/netmod/current/msg00692.html > http://www.ietf.org/mail-archive/web/netmod/current/msg00749.html > > There is no finished proposal with all details filled in yet. > I like it. Here's my table, updated with created-by: (1) default by data type just ignored, not an error if mandatory=true (2) the default for created-by is 'user' if not specified default | mandatory | cr-by | rule --------+-----------+-------+------------------------- no | false | user | node MAY be created by user (a) --------+-----------+-------+------------------------- no | false | sys | node MUST be created by system (b) --------+-----------+-------+------------------------- no | true | user | node MUST be created by user --------+-----------+-------+------------------------- no | true | sys | invalid YANG --------+-----------+-------+------------------------- yes | false | user | node MAY be created by user (c) --------+-----------+-------+------------------------- yes | false | sys | node MUST be created by system (d) --------+-----------+-------+------------------------- yes | true | user | invalid YANG --------+-----------+-------+------------------------- yes | true | sys | invalid YANG --------+-----------+-------+------------------------- (a) if not created by user, then agent will not use this leaf at all (b) beyond the scope of YANG what value will be picked by the agent (c) if not created by user, than agent MUST use the specified default (d) the agent MUST use the specified default value > > /martin > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Aug 26 19:29:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694893A687F; Tue, 26 Aug 2008 19:29:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE313A687F for ; Tue, 26 Aug 2008 19:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UFqPfptAUwX for ; Tue, 26 Aug 2008 19:29:22 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 942753A685E for ; Tue, 26 Aug 2008 19:29:20 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 19:28:18 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 19:27:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 19:27:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 19:25:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7R2PKu21324; Tue, 26 Aug 2008 19:25:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7R2Lkj7094588; Wed, 27 Aug 2008 02:21:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808270221.m7R2Lkj7094588@idle.juniper.net> To: Andy Bierman In-reply-to: <48B4B635.40506@netconfcentral.com> Date: Tue, 26 Aug 2008 22:21:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2008 02:25:21.0306 (UTC) FILETIME=[277EAFA0:01C907EC] Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: > default | mandatory | cr-by | rule > --------+-----------+-------+------------------------- > no | false | sys | node MUST be created by system (b) In order to save and restore configuration datasets, a "created-by system" node must be allowed to be created by the user when the instance is first created. > yes | false | sys | node MUST be created by system (d) Why would you have a default on a "created-by system" node? If the node has a fixed default value, why would the system need to create it? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 00:55:00 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7453A67A3; Wed, 27 Aug 2008 00:55:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F4D3A6B9D for ; Wed, 27 Aug 2008 00:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJCYrQIF5CXA for ; Wed, 27 Aug 2008 00:54:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7622B3A67A3 for ; Wed, 27 Aug 2008 00:54:58 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 46C3DD800C0; Wed, 27 Aug 2008 09:54:54 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <48B45C4D.8030407@ericsson.com> References: <200808221050.00096.david.partain@ericsson.com> <48AF1DAB.6080500@ericsson.com> <20080823.115501.104471813.mbj@tail-f.com> <1219647340.6265.28.camel@missotis> <48B45C4D.8030407@ericsson.com> Organization: CESNET Date: Wed, 27 Aug 2008 09:54:53 +0200 Message-Id: <1219823693.6261.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgw5p0IDI2LiAwOC4gMjAwOCB2IDIxOjQxICswMjAwOgo+ IEFzIHdyaXR0ZW4gZWFybGllciB0aGUgZXhpc3RlbmNlIG9mIGEgbm9kZSBpbXBhY3RzIHRoZSBm b2xsb3dpbmc6Cj4gMSkgZ2V0LCBnZXQtY29uZmlnLCBjb3B5LWNvbmZpZwo+IDIpIHRoZSBzdWNj ZXNzIG9yIGZhaWx1cmUgb2YgdGhlIGVkaXQtY29uZmlnIGNyZWF0ZS9kZWxldGUvbm9uZSBjb21t YW5kcwo+IAo+IEZvciBlZGl0LWNvbmZpZyB3ZSBuZWVkIHRvIGtub3cgd2hldGhlciBhIGxlYWYg ZXhpc3RzIG9yIG5vdCwgaXQgaXMgbm90IGVub3VnaCB0byBzYXkgd2hhdCB5b3UgCj4gZ2V0IGlu IGdldC1jb25maWcuCgpXaGF0IGFyZSB0aGUgbGltaXRhdGlvbnMgZm9yIGVkaXQtY29uZmlnPyBJ TU8gdGhlIGFnZW50IG11c3QgYmUgYWx3YXlzCnByZXBhcmVkIHRvIGJlaGF2ZSBhcyBpZiB0aGUg a25vYiBpcyB0aGVyZSBhbmQgaGFzIHRoZSBkZWZhdWx0IHZhbHVlLAp3aXRoIHRoZSBleGNlcHRp b24gdGhhdCBpdCBuZWVkbid0IHNlbmQgaXQgaW4gdGhlIGdldC9nZXQtY29uZmlnIG91dHB1dAph bmQgbWF5IGFsc28gZGVjbGFyZSBpdCBhcyByZWFkLW9ubHkgKGUuZy4sIGhhcmR3aXJlZCBNVFUp LiBJIHRoaW5rIGl0J3MKcmVhbGx5IGltcG9ydGFudCB0byBsaW1pdCB0aGUgbm90aW9uIG9mIGNv bXBsaWFuY2Ugd3J0IGEgZ2l2ZW4gZGF0YQptb2RlbCB0byB0aGUgY29tbXVuaWNhdGlvbiBiZXR3 ZWVuIHRoZSBhZ2VudCBhbmQgbWFuYWdlciBhbmQgYWxsb3cgZm9yCmRpZmZlcmVudCBpbXBsZW1l bnRhdGlvbnMgKG9uZSBhZ2VudCBtYXkgaGF2ZSB0aGUgZGVmYXVsdCB2YWx1ZXMgaW4gaXRzCmRh dGFiYXNlIHdoaWxlIGFub3RoZXIgZG9lc24ndCkuCgpMYWRhCiAKPiAKPiBCYWxhenMKPiAKPiBM YWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gPiBNYXJ0aW4gQmpvcmtsdW5kIHDDrcWhZSB2IFNvIDIz LiAwOC4gMjAwOCB2IDExOjU1ICswMjAwOgo+ID4+IEN1cnJlbnRseSB0aGUgc3BlYyBzcGVjaWZp ZXMgdGhhdCBkZWZhdWx0cyBhcmUgbm90IHBhcnQgb2YgdGhlCj4gPj4gY29uY2VwdHVhbCBkYXRh IHN0b3JlLiAgQnV0IG5vdCB0aGUgd29yZCBjb25jZXB0dWFsLiAgVGhpcyBkb2VzICpub3QqCj4g Pj4gcHJlY2x1ZGUgYW4gaW1wbGVtZW50YXRpb24gdG8gc3RvcmUgdGhlIGRlZmF1bHQgaW4gdGhl aXIgZGF0YWJhc2UuCj4gPiAKPiA+IEkgYW0gbm90IHN1cmUgd2hldGhlciAiY29uY2VwdHVhbCBk YXRhc3RvcmUiIG1lYW5zIHRoZSBzYW1lIHRoaW5nIGFzCj4gPiB3aGF0IEkgY2FsbGVkICJjb25j ZXB0dWFsIGRhdGEgdHJlZSIgaW4gRHVibGluLiBCeSB0aGUgbGF0dGVyIEkgbWVhbnQKPiA+IGVz c2VudGlhbGx5IHRoZSByZXBseSB0byA8Z2V0PiB3aXRob3V0IGFueSBmaWx0ZXJzLCBpLmUuLCBY TUwuIElmIFlBTkcKPiA+IG1vZGVscyBhcmUgaW50ZXJwcmV0ZWQgYXMgY29udHJhY3RzIGJldHdl ZW4gdGhlIGFnZW50IGFuZCBtYW5hZ2VyIHRoZW4KPiA+IGl0IGlzIElNTyB0aGUgb25seSB0aGlu ZyB0aGF0IHJlYWxseSBtYXR0ZXJzLiBXaGV0aGVyIHRoZSBhZ2VudCBoYXMgdGhlCj4gPiBkZWZh dWx0IHZhbHVlIGluIGl0cyBkYXRhYmFzZSBvciB3aGV0aGVyIGl0IGlzIGhhcmR3aXJlZCBldGMu IGRvZXNuJ3QKPiA+IHNlZW0gaW1wb3J0YW50Lgo+ID4gCj4gPiBJbiB0aGlzIGNvbnRleHQsIHdp dGggcmVzcGVjdCB0byBkZWZhdWx0cyBpdCBpcyBvbmx5IG5lY2Vzc2FyeSB0byBkZWNpZGUKPiA+ IHVuZGVyIHdoYXQgY2lyY3Vtc3RhbmNlcyBhIGxlYWYgZWxlbWVudCB0aGF0IHdvdWxkIG5vcm1h bGx5IGNvbnRhaW4gdGhlCj4gPiBkZWZhdWx0IHZhbHVlIG1heSBiZSBvbWl0dGVkIGluIHRoZSA8 Z2V0PiBvciA8Z2V0LWNvbmZpZz4gcmVwbHkuCj4gPiAKPiA+IExhZGEKPiA+IAo+IAotLSAKTGFk aXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0 bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k Cg== From netmod-bounces@ietf.org Wed Aug 27 01:32:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D681F3A67FD; Wed, 27 Aug 2008 01:32:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDD63A67FD for ; Wed, 27 Aug 2008 01:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8kvaYGrHTWo for ; Wed, 27 Aug 2008 01:32:22 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3D83728C128 for ; Wed, 27 Aug 2008 01:32:22 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F5EA76C4DC; Wed, 27 Aug 2008 10:32:02 +0200 (CEST) Date: Wed, 27 Aug 2008 10:32:16 +0200 (CEST) Message-Id: <20080827.103216.250207209.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B2E4F6.4020808@netconfcentral.com> References: <48B2A7B0.2040508@netconfcentral.com> <20080825.184206.52024501.mbj@tail-f.com> <48B2E4F6.4020808@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >>> Can the identifiers defined with this statement be used for something > >>> else than just error-app-tag? Is the idea that they can be used like > >>> OBJECT-IDENTITY - if so, do we also need a corresponding builtin type > >>> "identifier" (or better name) which is encoded as a QName: > >>> leaf encryption-method { > >>> type identifier; > >>> } > >>> identifier des3 { ... } > >>> identifier aes128 { ... } > >>> > >> yes -- that is the main purpose. > >> SNMP has a registration OID mechanism. > > I support this idea. > > > >> The YANG approach (keep augmenting a choice > >> with empty leafs) is pretty lame. > > I agree it's sort of not obvious. It's actually more powerful than > > OBJECT IDENTITY/OBJECT ODENTIFIER, b/c you cannot restrict the OID in > > the model; there is no formal way to know which values the > > 'encryotion-method' object above might get. E.g. there is no way to > > known that you cannot set 'encryotion-method' to 'data-not-unique'. > > If the 'encryption-method' is a choice, each value is an augment and > > thus very specific. > > > > > This is true, and these are used more often for read-only data. > In reality, the manager needs to know which module contains > the 'identify' or the 'augment', and know what it means. > > A bunch of leaf x (identifies platform x) leaf y, etc. > is no better than identifier x,y for this purpose. > An invalid-value comes back either way if you send > the ID for a chassis fan when the agent expects the ID of the > encryption method. Yes, but I tend to prefer solutions where you know as much as possible before trying. On the tools-side, a client can provide the user with e.g. a drop-down list of all available encryption methods, and this list will not include the chassis fan. With an unrestricted 'identifier', the list will either include the chassis-fan, or it will not be a list at all; just a plain string. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 08:49:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB593A6C7F; Wed, 27 Aug 2008 08:49:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1A03A6C80 for ; Wed, 27 Aug 2008 08:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UXdQXYwxy5L for ; Wed, 27 Aug 2008 08:49:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9391F3A6AD5 for ; Wed, 27 Aug 2008 08:49:03 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D29DA203F7 for ; Wed, 27 Aug 2008 17:49:03 +0200 (CEST) X-AuditID: c1b4fb3e-a9686bb000007a96-fe-48b5776f55da Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C13D12019F for ; Wed, 27 Aug 2008 17:49:03 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 17:49:03 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 17:49:03 +0200 Message-ID: <48B5774E.6060407@ericsson.com> Date: Wed, 27 Aug 2008 17:48:30 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 27 Aug 2008 15:49:03.0220 (UTC) FILETIME=[6DFED340:01C9085C] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Include question: reference to stuff in the main module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I wanted to do the following: module mymod { namespace "xxx"; prefix "model"; include submodFragment; container root { uses submodGrouping; list mainList { key mainId; leaf mainId {type string;} } } } ------------------------------------------ submodule submodFragment { belongs-to mymod; grouping submodGrouping { leaf ref2 { type keyref { path /root/mainList/mainId; } } } } This seems to me a perfectly good design pattern: A main module containing the root and submodules each adding their own stuff. However this does not work as the submodule does not see /root in the module. So I had to put the root in a separate root submodule just to be able to include it. This works however I have an unneeded extra submodule just to handle the strange behavior of YANG. Is there a way to make stuff in the module visible in the submodule Balazs? _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 10:37:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5203A6857; Wed, 27 Aug 2008 10:37:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C953A6C21 for ; Wed, 27 Aug 2008 10:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJRNM9vAtjTQ for ; Wed, 27 Aug 2008 10:37:29 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 232823A684A for ; Wed, 27 Aug 2008 10:37:18 -0700 (PDT) X-Trace: 75162052/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.197 X-SBRS: None X-RemoteIP: 213.116.52.197 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAOgstUjVdDTF/2dsb2JhbACDRziICK4kA4Fl X-IronPort-AV: E=Sophos;i="4.32,279,1217804400"; d="scan'208";a="75162052" X-IP-Direction: IN Received: from 1cust197.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.197]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Aug 2008 18:35:57 +0100 Message-ID: <002d01c90862$0bdfbfc0$0601a8c0@allison> From: "tom.petch" To: "Ladislav Lhotka" , "David Partain" References: <200808202131.m7KLVr7j003341@idle.juniper.net><200808211501.09441.david.partain@ericsson.com> <1219333763.6909.13.camel@missotis> Date: Wed, 27 Aug 2008 18:17:47 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCkZyb206ICJMYWRpc2xhdiBMaG90a2EiIDxsaG90 a2FAY2VzbmV0LmN6PgpUbzogIkRhdmlkIFBhcnRhaW4iIDxkYXZpZC5wYXJ0YWluQGVyaWNzc29u LmNvbT4KQ2M6IDxuZXRtb2RAaWV0Zi5vcmc+ClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEsIDIw MDggNTo0OSBQTQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWFBhdGggY29tcGxpYW5jZSBhbmQgcHJl Zml4IG9uICdtdXN0Jz8gKHdhcyBSZTpiZWxvbmdzLXRvKQoKCj4gRGF2aWQgUGFydGFpbiBww63F oWUgdiDEjHQgMjEuIDA4LiAyMDA4IHYgMTU6MDEgKzAyMDA6Cj4gPiBIaSwKPiA+Cj4gPiBJJ20g dmVyeSBjb25mdXNlZCBhYm91dCB0aGUgdG9waWMgYXQgaGFuZC4uLgo+ID4KPiA+IFdoYXQgaXMg dGhlIGxhc3QgaGFsZiBvZiB0aGUgJ2JlbG9uZ3MtdG8nIHRocmVhZCB0YWxraW5nIGFib3V0Pwo+ ID4KPiA+IC0gV2hldGhlciB3ZSdyZSBYUGF0aCAxLjAgY29tcGxpYW50IG9yIG5vdD8gIChtb3N0 LCBtYXliZSBhbGwsIHBlb3BsZSBzZWVtCnRvCj4gPiB0aGluayB3ZSBhcmUpCj4KPiBZQU5HIGRy YWZ0IGRlZmluZXMgdGhlIG51bGwgbmFtZXNwYWNlIHRvIGJlIHRoZSBuYW1lc3BhY2Ugb2YgdGhl IGN1cnJlbnQKPiBtb2R1bGUsIHdoaWNoIGlzIElNTyBub3QgYWNjZXB0YWJsZSAtIG51bGwgbmFt ZXNwYWNlIGhhcyBhIHZlcnkgcHJlY2lzZQo+IG1lYW5pbmcgc2ltaWxhciB0byBlbXB0eSBzZXQg aW4gdGhlIHNldCB0aGVvcnkuCj4KCkkgdGhpbmsgdGhhdCBMYWRhIGlzIHNwb3Qgb24gd2l0aCB0 aGlzLCBhbmQgaGFzIGJlZW4gdGhyb3VnaG91dCB0aGlzIHRocmVhZCBhbmQKaXRzIHByZWN1cnNv cnMuICBOdWxsIG5hbWVzcGFjZSBpcyBhIGRpZmZlcmVudCBjb25jZXB0LiAgRm9yIFlBTkcgdG8g cmVkZWZpbmUKaXRzIG1lYW5pbmcgd2lsbCBjb25mdXNlIGFueW9uZSBmYW1pbGlhciB3aXRoIFhQ YXRoIDEuMC4KCihJIGZpcnN0IHNhdyB0aGUgbGlnaHQgYWZ0ZXIgcmVhZGluZwpodHRwOi8vd3d3 LnJwYm91cnJldC5jb20veG1sL05hbWVzcGFjZXNGQVEuaHRtCikKClRvbSBQZXRjaAoKCgoKPiA+ IC0gV2hldGhlciB3ZSBoYXZlIHRvIGhhdmUgYSBwcmVmaXggb3Igbm90IG9uIGEgJ211c3QnIHN0 YXRlbWVudD8KPgo+IEkgYmVsaWV2ZSB0aGUgYW5zd2VyIGlzIHllcyAtIGFjdHVhbGx5LCBhIG5h bWVzcGFjZSBwcmVmaXggaGFzIHRvIGJlCj4gYXR0YWNoZWQgdG8gZXZlcnkgUU5hbWUgKGNvbXBv bmVudCkgb2YgdGhlIFhQYXRoIDEuMCBleHByZXNzaW9uIHRoYXQgaXMKPiBpbiB0aGUgYXJndW1l bnQgb2YgbXVzdC1zdG10Lgo+Cj4gPiAtIFNvbWV0aGluZyBlbHNlPwo+Cj4gJHRoaXMgLT4gY3Vy cmVudCgpLCBidXQgdGhlcmUgc2VlbXMgdG8gYmUgY29uc2Vuc3VzIG9uIHRoaXMuCj4KPiBMYWRh Cj4KPiAtLQo+IExhZGlzbGF2IExob3RrYSwgQ0VTTkVUCj4gUEdQIEtleSBJRDogRTc0RThDMEMK Pgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0 bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Aug 27 12:05:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23023A6933; Wed, 27 Aug 2008 12:05:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79393A6C2B for ; Wed, 27 Aug 2008 12:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNf83qaocX7e for ; Wed, 27 Aug 2008 12:05:14 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id EA2D93A6933 for ; Wed, 27 Aug 2008 12:05:13 -0700 (PDT) Received: (qmail 12772 invoked from network); 27 Aug 2008 19:05:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 19:05:13 -0000 X-YMail-OSG: TM9r.7oVM1lWI9ryV8K7Cwl24Y6.qXSK9SgJuHxBxmF3O0GGKCtNiDJRtIRbu6rJBiYJpd.X7TzPgoyBsDHUCOHFrs7WNGW3s6WscsnaTiUKhLrDGq5At7QW1K7pK0E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B5A566.50406@netconfcentral.com> Date: Wed, 27 Aug 2008 12:05:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <48B5774E.6060407@ericsson.com> In-Reply-To: <48B5774E.6060407@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] Include question: reference to stuff in the main module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > I wanted to do the following: > The whole NETMOD architecture is bit fuzzy to me. We seem to keep backing into an architecture, as decisions on the details proceed. You can just define 'root' once, in a root.yang sub-module, and include it in each fragment sub-module, but IMO this is not redundant. In each sub-module, you state precisely which definitions are visible in that sub-module (just like a module w/ imports). IMO, module/sub-module usage is OK the way it is, where each sub-module can only look down or across the tree, but not up. Andy > module mymod { > namespace "xxx"; > prefix "model"; > > include submodFragment; > > container root { > uses submodGrouping; > list mainList { > key mainId; > leaf mainId {type string;} > } > } > } > > ------------------------------------------ > > submodule submodFragment { > belongs-to mymod; > > grouping submodGrouping { > leaf ref2 { > type keyref { > path /root/mainList/mainId; > } > } > } > } > > This seems to me a perfectly good design pattern: > A main module containing the root and submodules each adding their own stuff. > However this does not work as the submodule does not see /root in the module. > So I had to put the root in a separate root submodule just to be able to include it. This works > however I have an unneeded extra submodule just to handle the strange behavior of YANG. > > Is there a way to make stuff in the module visible in the submodule > > Balazs? > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 12:09:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971113A6933; Wed, 27 Aug 2008 12:09:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3369F3A6C2B for ; Wed, 27 Aug 2008 12:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMoOzzBg2KBY for ; Wed, 27 Aug 2008 12:09:24 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 469DF3A6933 for ; Wed, 27 Aug 2008 12:09:24 -0700 (PDT) Received: (qmail 72911 invoked from network); 27 Aug 2008 19:09:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 19:09:25 -0000 X-YMail-OSG: .VTTb2EVM1mEcgTIhSdtcPgoi6ioNPCm1XEER6HYUWKDZCc2mb5w93ZmpDcaR1kQnNITJD0KU0JTX74xHwW6KeuOmWs1A4xX2gy5j9qvWKC5TMJ4eCzbpVQcPP_EnLY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B5A663.6000407@netconfcentral.com> Date: Wed, 27 Aug 2008 12:09:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B2A7B0.2040508@netconfcentral.com> <20080825.184206.52024501.mbj@tail-f.com> <48B2E4F6.4020808@netconfcentral.com> <20080827.103216.250207209.mbj@tail-f.com> In-Reply-To: <20080827.103216.250207209.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>>> Can the identifiers defined with this statement be used for something >>>>> else than just error-app-tag? Is the idea that they can be used like >>>>> OBJECT-IDENTITY - if so, do we also need a corresponding builtin type >>>>> "identifier" (or better name) which is encoded as a QName: >>>>> leaf encryption-method { >>>>> type identifier; >>>>> } >>>>> identifier des3 { ... } >>>>> identifier aes128 { ... } >>>>> >>>> yes -- that is the main purpose. >>>> SNMP has a registration OID mechanism. >>> I support this idea. >>> >>>> The YANG approach (keep augmenting a choice >>>> with empty leafs) is pretty lame. >>> I agree it's sort of not obvious. It's actually more powerful than >>> OBJECT IDENTITY/OBJECT ODENTIFIER, b/c you cannot restrict the OID in >>> the model; there is no formal way to know which values the >>> 'encryotion-method' object above might get. E.g. there is no way to >>> known that you cannot set 'encryotion-method' to 'data-not-unique'. >>> If the 'encryption-method' is a choice, each value is an augment and >>> thus very specific. >>> >> >> This is true, and these are used more often for read-only data. >> In reality, the manager needs to know which module contains >> the 'identify' or the 'augment', and know what it means. >> >> A bunch of leaf x (identifies platform x) leaf y, etc. >> is no better than identifier x,y for this purpose. >> An invalid-value comes back either way if you send >> the ID for a chassis fan when the agent expects the ID of the >> encryption method. > > Yes, but I tend to prefer solutions where you know as much as possible > before trying. On the tools-side, a client can provide the user with > e.g. a drop-down list of all available encryption methods, and this > list will not include the chassis fan. With an unrestricted > 'identifier', the list will either include the chassis-fan, or it will > not be a list at all; just a plain string. > > fine. 'foo:error-name' is valid syntax for error-app-tag, as well as just 'error-name'. Implementations can put whatever they want in there for their own error-app-tags, so no change in the spec is even needed for the use case I originally brought up. The identifier issue might come up again, like why doesn't YANG support the XSD QName data type? > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 12:16:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30D428C1FB; Wed, 27 Aug 2008 12:16:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9120328C22D for ; Wed, 27 Aug 2008 12:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2ioGbyzPmBh for ; Wed, 27 Aug 2008 12:16:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B32B328C213 for ; Wed, 27 Aug 2008 12:16:12 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id EF7B176C4DC; Wed, 27 Aug 2008 21:16:13 +0200 (CEST) Date: Wed, 27 Aug 2008 21:16:11 +0200 (CEST) Message-Id: <20080827.211611.19089442.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B5A663.6000407@netconfcentral.com> References: <48B2E4F6.4020808@netconfcentral.com> <20080827.103216.250207209.mbj@tail-f.com> <48B5A663.6000407@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] error-app-tag QName? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > fine. 'foo:error-name' is valid syntax for error-app-tag, > as well as just 'error-name'. Implementations can put whatever > they want in there for their own error-app-tags, so > no change in the spec is even needed for the use case > I originally brought up. > > The identifier issue might come up again, > like why doesn't YANG support the XSD QName data type? As I said, I support this idea. We can start with the identifier statement and require an error-app-tag statement to refer to an existing identifier, and require YANG-compatible servers to declare the prefix in the rpc-error and use prefix:identifier. You're right that no change is needed in rfc4741 for this. The other question is if we need a corresponding 'identifier' (or maybe QName) type. I would like this, b/c I agree that the current solution of augmenting choices is non-intuitive. But I also think that the current solution gives better control than a simplistic identifier solution. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 12:32:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC2A3A6C4D; Wed, 27 Aug 2008 12:32:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2943A67F4 for ; Wed, 27 Aug 2008 12:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udp35SEtGhEL for ; Wed, 27 Aug 2008 12:32:10 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 759F63A6C67 for ; Wed, 27 Aug 2008 12:32:10 -0700 (PDT) Received: (qmail 67978 invoked from network); 27 Aug 2008 19:32:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 19:32:04 -0000 X-YMail-OSG: TSSjINYVM1mqGc.TCYfNyPDtk1hpA_88BoxPWkQNemAvn7Vn7qTS0R7JGDiHX1l6tYP8oRDFF7JlKqRozSsdVulbB0z01KJ.v7O9FX0WIg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B5ABB2.5000909@netconfcentral.com> Date: Wed, 27 Aug 2008 12:32:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] import-by-revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I am trying to figure out how clever tools and change control rules can support import by revision automatically. The first CLR: all modules MUST contain a new correct revision date, each time they are published. This can be enforced in IETF data models, and should be mandated for vendor data models as well (like YANG default is mandatory, making it useful, as opposed to SMI DEFVAL and REVISION being optional and useless.) With this CLR, a tool can eliminate imports and submodules that have a newer data than the current module. The tool can look for the first revision date older than the target module. This covers most cases I think. It works better with minimal module publication churn. The revision date should be changed to a full date-and-time, (optional time) to be as precise as possible. This assumes some really strict change control rules, and does not (yet) allow for any manual overrides. Open issue: all-or-nothing import design. Can the module 'foo' import 2 different versions of the 'bar' module directly, or indirectly. The details for chained import differences needs a lot of work, especially wrt/ groupings. IMO, if foo imports B and C.n, then B MUST use <= C.n if it uses C at all. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 13:01:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0EA3A67A7; Wed, 27 Aug 2008 13:01:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC5B3A6B45 for ; Wed, 27 Aug 2008 13:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKLSi7KK2iUU for ; Wed, 27 Aug 2008 13:01:07 -0700 (PDT) Received: from chip3mo2-old.postini.com (chip3mo2-old.postini.com [64.18.14.205]) by core3.amsl.com (Postfix) with ESMTP id E94B03A69A9 for ; Wed, 27 Aug 2008 13:01:05 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob64.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 13:00:29 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 13:00:21 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 13:00:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 13:00:20 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7RK0Ku65909; Wed, 27 Aug 2008 13:00:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7RJui9U002410; Wed, 27 Aug 2008 19:56:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808271956.m7RJui9U002410@idle.juniper.net> To: "tom.petch" In-reply-to: <002d01c90862$0bdfbfc0$0601a8c0@allison> Date: Wed, 27 Aug 2008 15:56:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2008 20:00:20.0825 (UTC) FILETIME=[88F2C490:01C9087F] Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "tom.petch" writes: >Null namespace is a different concept. For YANG to redefine >its meaning will confuse anyone familiar with XPath 1.0. I'm surprised that this is considered confusing. In a YANG XPath, the null namespace (elements with no namespace URI) refers to the current module. This is simple and natural. Adding prefixes at inconsistent moments is sure to be far more confusing. Compare this is XSD, where the null namespace refers to the namespace named in the targetNamespace attribute on the element. Or XQuery, where unprefixed elements are in the default element/type namespace, which can be set in a number of ways. Or many other w3c standards that define the context in which XPath expressions are evaluated. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 13:26:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634583A6407; Wed, 27 Aug 2008 13:26:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BB83A6966 for ; Wed, 27 Aug 2008 13:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EOORqXjLfZO for ; Wed, 27 Aug 2008 13:26:04 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 5FDF03A6407 for ; Wed, 27 Aug 2008 13:26:04 -0700 (PDT) Received: (qmail 17162 invoked from network); 27 Aug 2008 20:25:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 20:25:55 -0000 X-YMail-OSG: JVlR2LwVM1nNYSxXivWk6uWlqiE..9tHFiJj_pvRBndqU7uLQSatlMjPQhqmQNGi8qItkwUVZmJjzaPUWPbwMps6giWtEaSJkBv2jpBrtg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B5B851.2020609@netconfcentral.com> Date: Wed, 27 Aug 2008 13:25:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808270221.m7R2Lkj7094588@idle.juniper.net> In-Reply-To: <200808270221.m7R2Lkj7094588@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> default | mandatory | cr-by | rule >> --------+-----------+-------+------------------------- >> no | false | sys | node MUST be created by system (b) > > In order to save and restore configuration datasets, a "created-by > system" node must be allowed to be created by the user when the > instance is first created. > OK >> yes | false | sys | node MUST be created by system (d) > > Why would you have a default on a "created-by system" node? If the > node has a fixed default value, why would the system need to create > it? > So this should be illegal YANG? It is just redundant. Seems like a harsh CLR. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 14:01:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7983A6C92; Wed, 27 Aug 2008 14:01:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E623A6C96 for ; Wed, 27 Aug 2008 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE3kE8zaxlld for ; Wed, 27 Aug 2008 14:01:51 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 56F4A3A6C7D for ; Wed, 27 Aug 2008 14:01:51 -0700 (PDT) Received: (qmail 58860 invoked from network); 27 Aug 2008 21:01:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2008 21:01:49 -0000 X-YMail-OSG: 9JQ5IjIVM1ldlEcj9R2g_57S1TQdMUVVSHOM8rORgKsozQK7w7PSvs4Sedc709U.COSmVXjwe9NtuXU9czVthU.gBbQlaQf865SBBX1jOg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B5C0BA.1060604@netconfcentral.com> Date: Wed, 27 Aug 2008 14:01:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808271956.m7RJui9U002410@idle.juniper.net> In-Reply-To: <200808271956.m7RJui9U002410@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > "tom.petch" writes: >> Null namespace is a different concept. For YANG to redefine >> its meaning will confuse anyone familiar with XPath 1.0. > > I'm surprised that this is considered confusing. In a YANG XPath, > the null namespace (elements with no namespace URI) refers to the > current module. This is simple and natural. Adding prefixes at > inconsistent moments is sure to be far more confusing. > > Compare this is XSD, where the null namespace refers to the namespace > named in the targetNamespace attribute on the element. > Or XQuery, where unprefixed elements are in the default element/type > namespace, which can be set in a number of ways. Or many other w3c > standards that define the context in which XPath expressions are > evaluated. > I know I have not helped this discussion, but I agree with Phil and Lada. (does not compute!) There has been an ongoing debate which (at its core) is really over the validity of YANG as an abstraction, as opposed to a view that the model is really the external XML instance document for the element. I strongly agree with Phil that the YANG file represents the YANG abstraction, and its constructs do not have to directly represent XML instance documents. We should just stuck with XSD if we are interested in modeling XML documents instead of network device configuration databases. It seems reasonable to require must-stmt conversion for YANG to DSDL tools, so there are no missing prefixes at all. Namespace declarations must be present for every prefix used. This would preserve the YANG abstraction and provide the expected XPath 1.0 syntax in the output files. > Thanks, > Phil > _______ Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Aug 27 21:21:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D943A68C8; Wed, 27 Aug 2008 21:21:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8AB3A68C8 for ; Wed, 27 Aug 2008 21:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN0R7qWXnKBc for ; Wed, 27 Aug 2008 21:21:46 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 793263A6913 for ; Wed, 27 Aug 2008 21:21:44 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 21:18:30 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 21:21:36 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 21:21:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 21:21:35 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7S4LYu79731; Wed, 27 Aug 2008 21:21:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7S4Hv3d005055; Thu, 28 Aug 2008 04:17:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808280417.m7S4Hv3d005055@idle.juniper.net> To: Andy Bierman In-reply-to: <48B5B851.2020609@netconfcentral.com> Date: Thu, 28 Aug 2008 00:17:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2008 04:21:35.0682 (UTC) FILETIME=[8EF5C220:01C908C5] Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >> Why would you have a default on a "created-by system" node? If the >> node has a fixed default value, why would the system need to create >> it? >So this should be illegal YANG? >It is just redundant. Seems like a harsh CLR. If it doesn't make sense, disallowing isn't a CLR. It's avoiding a situation that doesn't make sense so we don't need to make code for a scenario that should not occur. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 00:10:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586A83A6891; Thu, 28 Aug 2008 00:10:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194173A6891 for ; Thu, 28 Aug 2008 00:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sAKanHr9B+t for ; Thu, 28 Aug 2008 00:10:23 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 01B333A690D for ; Thu, 28 Aug 2008 00:10:22 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7534076C4DE; Thu, 28 Aug 2008 09:10:25 +0200 (CEST) Date: Thu, 28 Aug 2008 09:10:41 +0200 (CEST) Message-Id: <20080828.091041.60970813.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B5B851.2020609@netconfcentral.com> References: <200808270221.m7R2Lkj7094588@idle.juniper.net> <48B5B851.2020609@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> default | mandatory | cr-by | rule > >> yes | false | sys | node MUST be created by system (d) > > Why would you have a default on a "created-by system" node? If the > > node has a fixed default value, why would the system need to create > > it? > > > > So this should be illegal YANG? > It is just redundant. Seems like a harsh CLR. IMO it's not redundant, it's confusing. Which one takes precedence? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 01:02:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC823A67F1; Thu, 28 Aug 2008 01:02:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454C13A69B7 for ; Thu, 28 Aug 2008 01:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exMu51+dOxVb for ; Thu, 28 Aug 2008 01:02:36 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id D57D13A67F1 for ; Thu, 28 Aug 2008 01:02:35 -0700 (PDT) Received: from [127.0.0.1] (u-173-c224.cs.uni-tuebingen.de [134.2.173.224]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m7S81s03011903 for ; Thu, 28 Aug 2008 10:01:54 +0200 Message-ID: <48B65BAF.5010307@informatik.uni-tuebingen.de> Date: Thu, 28 Aug 2008 10:02:55 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: netmod@ietf.org X-Enigmail-Version: 0.95.6 X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.1.23; VDF: 7.0.6.82; host: mx06) Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0005368197==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0005368197== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050103020904060000080901" This is a cryptographically signed message in MIME format. --------------ms050103020904060000080901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, I've seen the following table and the corresponding discussion about created-by. > default | mandatory | cr-by | rule > --------+-----------+-------+------------------------- > no | false | user | node MAY be created by user (a) > --------+-----------+-------+------------------------- > no | false | sys | node MUST be created by system (b) > --------+-----------+-------+------------------------- > no | true | user | node MUST be created by user > --------+-----------+-------+------------------------- > no | true | sys | invalid YANG > --------+-----------+-------+------------------------- > yes | false | user | node MAY be created by user (c) > --------+-----------+-------+------------------------- > yes | false | sys | node MUST be created by system (d) > --------+-----------+-------+------------------------- > yes | true | user | invalid YANG > --------+-----------+-------+------------------------- > yes | true | sys | invalid YANG > --------+-----------+-------+------------------------- I do not really understand the meaning of created-by. Maybe you are discussing the problem in a way that goes beyond what we would like to do in IPFIX. Here is my point of view: We have the mandatory statement. In a leaf, the node must exist in a valid configuration if mandatory is true. In this case, we have two options: either the manager provides a value, or the agent chooses an appropriate one. Note that 7.6.4 of the YANG draft does not specify who is to supply a mandatory value. Probably everybody thinks of the manager. However, the draft only says that the node must exist "in a valid configuration". In IPFIX, we want to force the manager to provide a mandatory value in some cases. In other cases, we want to give the manager to opportunity to provide a mandatory value, yet if he does not want to, the device chooses an appropriate value. So, it would be nice to have two types of mandatory: - mandatory nodes which must be set by the manager - mandatory nodes which may be set by the manager. If not, they are set by the agent. If mandatory is false, the data is optionally provided by the manager. The device will not provide any values. However, it will use a default value if specified in the YANG module. A final comment: agent-supplied values for mandatory nodes should not be seen as agent-supplied default values. In our case, these values are sometimes dynamically assigned, for example in the case of identifiers. "Default" sounds like a static value. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms050103020904060000080901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDgyODA4MDI1NVowIwYJKoZIhvcNAQkEMRYEFEdMGLoM5lVR re5EYtSR16yj/1TBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBnV/+1WZrq84oYzihmCFphqr+vEDs32cbn89M8+PTneJ4jky2e7ODmlwgE ooSA5ZKHhEaD06HAgH5vwULWASEEVlDdablTVfN0Kvj5Q/FgZbr6e3S+wvE/EtO33r/3k/aP PFx2CdxWm/e0vS9dUfKIXSOOOfuYLcC63vwGacZJzuZy8uNRLnPp4SjhkGcGBXL7BYpU4XS8 HGK1PuflQRB/UnwMkEdnbVkKnkj80c+gtFPR4JWqGhE3xQ5udhY+lgHD4jc1NAxjpWZ+oKev 6zsee35GHSShF6lGLHq+rfuBJFzny0FJobupnAyZax6sRztHimbhjLUC4w7sFHl8AQVJAAAA AAAA --------------ms050103020904060000080901-- --===============0005368197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============0005368197==-- From netmod-bounces@ietf.org Thu Aug 28 01:16:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13283A6A44; Thu, 28 Aug 2008 01:16:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7FAD3A6A8D for ; Thu, 28 Aug 2008 01:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+7Oxh8pwMex for ; Thu, 28 Aug 2008 01:16:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B303B3A6A61 for ; Thu, 28 Aug 2008 01:16:28 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4012C2066D; Thu, 28 Aug 2008 10:15:17 +0200 (CEST) X-AuditID: c1b4fb3e-ab68abb000007a96-4f-48b65e9568c6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0CC5420331; Thu, 28 Aug 2008 10:15:17 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 10:15:06 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 10:15:06 +0200 Message-ID: <48B65E6B.1020904@ericsson.com> Date: Thu, 28 Aug 2008 10:14:35 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48B5774E.6060407@ericsson.com> <48B5A566.50406@netconfcentral.com> In-Reply-To: <48B5A566.50406@netconfcentral.com> X-OriginalArrivalTime: 28 Aug 2008 08:15:06.0130 (UTC) FILETIME=[2DD67720:01C908E6] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] Include question: reference to stuff in the main module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I am not happy with this situation. I think I would be more happy if everything inside a module (including submodules) would just be a flat space, where everyone can see everything. In some ways we already have that. E.g. While you can not see the root container from submodFragment you still can not define another container called root in the submodule. So root in the module is mostly invisible. Balazs Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> I wanted to do the following: >> > > The whole NETMOD architecture is bit fuzzy to me. > We seem to keep backing into an architecture, > as decisions on the details proceed. > > You can just define 'root' once, in a root.yang > sub-module, and include it in each fragment sub-module, > but IMO this is not redundant. In each sub-module, > you state precisely which definitions are visible in > that sub-module (just like a module w/ imports). > > IMO, module/sub-module usage is OK the way it is, > where each sub-module can only look down or across > the tree, but not up. > > > Andy > >> module mymod { >> namespace "xxx"; >> prefix "model"; >> >> include submodFragment; >> >> container root { >> uses submodGrouping; >> list mainList { >> key mainId; >> leaf mainId {type string;} >> } >> } >> } >> >> ------------------------------------------ >> >> submodule submodFragment { >> belongs-to mymod; >> >> grouping submodGrouping { >> leaf ref2 { >> type keyref { >> path /root/mainList/mainId; >> } >> } >> } >> } >> >> This seems to me a perfectly good design pattern: >> A main module containing the root and submodules each adding their own >> stuff. >> However this does not work as the submodule does not see /root in the >> module. >> So I had to put the root in a separate root submodule just to be able >> to include it. This works however I have an unneeded extra submodule >> just to handle the strange behavior of YANG. >> >> Is there a way to make stuff in the module visible in the submodule >> >> Balazs? >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > > -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 04:01:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895F928C1DB; Thu, 28 Aug 2008 04:01:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050A228C1E8 for ; Thu, 28 Aug 2008 04:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKuVK8U1rHQB for ; Thu, 28 Aug 2008 04:01:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D206128C1DD for ; Thu, 28 Aug 2008 04:01:09 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 2D248D800C4; Thu, 28 Aug 2008 13:01:10 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200808271956.m7RJui9U002410@idle.juniper.net> References: <200808271956.m7RJui9U002410@idle.juniper.net> Organization: CESNET Date: Thu, 28 Aug 2008 13:01:09 +0200 Message-Id: <1219921269.6293.12.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMjcuIDA4LiAyMDA4IHYgMTU6NTYgLTA0MDA6Cj4gInRv bS5wZXRjaCIgd3JpdGVzOgo+ID5OdWxsIG5hbWVzcGFjZSBpcyBhIGRpZmZlcmVudCBjb25jZXB0 LiAgRm9yIFlBTkcgdG8gcmVkZWZpbmUKPiA+aXRzIG1lYW5pbmcgd2lsbCBjb25mdXNlIGFueW9u ZSBmYW1pbGlhciB3aXRoIFhQYXRoIDEuMC4KPiAKPiBJJ20gc3VycHJpc2VkIHRoYXQgdGhpcyBp cyBjb25zaWRlcmVkIGNvbmZ1c2luZy4gIEluIGEgWUFORyBYUGF0aCwKPiB0aGUgbnVsbCBuYW1l c3BhY2UgKGVsZW1lbnRzIHdpdGggbm8gbmFtZXNwYWNlIFVSSSkgcmVmZXJzIHRvIHRoZQoKSSB0 aGluayB5b3UgYXJlIG1peGluZyBwcmVmaXhlcyB3aXRoIG5hbWVzcGFjZXMgaGVyZS4KCj4gY3Vy cmVudCBtb2R1bGUuICBUaGlzIGlzIHNpbXBsZSBhbmQgbmF0dXJhbC4gIEFkZGluZyBwcmVmaXhl cyBhdAo+IGluY29uc2lzdGVudCBtb21lbnRzIGlzIHN1cmUgdG8gYmUgZmFyIG1vcmUgY29uZnVz aW5nLgo+IAo+IENvbXBhcmUgdGhpcyBpcyBYU0QsIHdoZXJlIHRoZSBudWxsIG5hbWVzcGFjZSBy ZWZlcnMgdG8gdGhlIG5hbWVzcGFjZQo+IG5hbWVkIGluIHRoZSB0YXJnZXROYW1lc3BhY2UgYXR0 cmlidXRlIG9uIHRoZSA8eHNkOnNjaGVtYT4gZWxlbWVudC4KCk5vLiBJdCBqdXN0IHNheXMgdGhh dCBlbGVtZW50cyBuYW1lcyB3aXRoIG5vICpwcmVmaXgqIGJlbG9uZyB0byBhCmNlcnRhaW4gWE1M IG5hbWVzcGFjZS4gUkVMQVggTkcgYW5kIFNjaGVtYXRyb24gZG8gdGhlIHNhbWUuIFRoZSBwb2lu dCBpcwp0aGV5IHVzZSBqdXN0IGVsZW1lbnQgbmFtZXMsIG5vdCBYUGF0aCBleHByZXNzaW9ucy4g WUFORyBkb2VzIGl0CmFjdHVhbGx5IHRvbyAtIGlmIHlvdSBzYXkgImNvbnRhaW5lciBmb28iLCBu byBwcmVmaXggaXMgbmVlZGVkIGFuZAp0aGF0J3MgT0suIEJ1dCBYUGF0aCAxLjAgaGFzIHRoaXMg cnVsZSB0aGF0IG5vIHByZWZpeCBtZWFucyBudWxsCm5hbWVwYWNlLCBmdWxsIHN0b3AuIElmIFhT RCB1c2VkIFhQYXRoIDEuMCBhbnl3aGVyZSwgYmUgc3VyZSB0aGV5IHdvdWxkCnVzZSBleHBsaWNp dCBwcmVmaXhlcy4gCiAKPiBPciBYUXVlcnksIHdoZXJlIHVucHJlZml4ZWQgZWxlbWVudHMgYXJl IGluIHRoZSBkZWZhdWx0IGVsZW1lbnQvdHlwZQo+IG5hbWVzcGFjZSwgd2hpY2ggY2FuIGJlIHNl dCBpbiBhIG51bWJlciBvZiB3YXlzLiAgT3IgbWFueSBvdGhlciB3M2MKPiBzdGFuZGFyZHMgdGhh dCBkZWZpbmUgdGhlIGNvbnRleHQgaW4gd2hpY2ggWFBhdGggZXhwcmVzc2lvbnMgYXJlCj4gZXZh bHVhdGVkLgoKSSBhbSBub3QgYXdhcmUgb2YgYW55IHNpbmdsZSBvbmUgdGhhdCB1c2VzIFhQYXRo IDEuMCBpbiB0aGlzIHdheS4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1Ag S2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Aug 28 04:11:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26AF3A6403; Thu, 28 Aug 2008 04:11:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159AC3A67A1 for ; Thu, 28 Aug 2008 04:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLw7D0rptU22 for ; Thu, 28 Aug 2008 04:11:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 429D03A6403 for ; Thu, 28 Aug 2008 04:11:38 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 32572D800F5; Thu, 28 Aug 2008 13:11:22 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48B5C0BA.1060604@netconfcentral.com> References: <200808271956.m7RJui9U002410@idle.juniper.net> <48B5C0BA.1060604@netconfcentral.com> Organization: CESNET Date: Thu, 28 Aug 2008 13:11:21 +0200 Message-Id: <1219921881.6293.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDI3LiAwOC4gMjAwOCB2IDE0OjAxIC0wNzAwOgo+IAo+ IEkgc3Ryb25nbHkgYWdyZWUgd2l0aCBQaGlsIHRoYXQgdGhlIFlBTkcgZmlsZSByZXByZXNlbnRz Cj4gdGhlIFlBTkcgYWJzdHJhY3Rpb24sIGFuZCBpdHMgY29uc3RydWN0cyBkbyBub3QgaGF2ZSB0 byBkaXJlY3RseQo+IHJlcHJlc2VudCBYTUwgaW5zdGFuY2UgZG9jdW1lbnRzLiAgV2Ugc2hvdWxk IGp1c3Qgc3R1Y2sKPiB3aXRoIFhTRCBpZiB3ZSBhcmUgaW50ZXJlc3RlZCBpbiBtb2RlbGluZyBY TUwgZG9jdW1lbnRzCj4gaW5zdGVhZCBvZiBuZXR3b3JrIGRldmljZSBjb25maWd1cmF0aW9uIGRh dGFiYXNlcy4KCklmIFlBTkcgc3BlYyBzYXlzIHRoYXQgdGhlIG11c3QgYXJndW1lbnQgaXMgYW4g WFBhdGggMS4wIGV4cHJlc3Npb24gYW5kCnRoZW4gZXhhbXBsZXMgYXJlIHNob3duIHRoYXQgdXNl IHRoZSAibG9jYWwiIG5hbWVzcGFjZSwgSSBjYW4gZ3VhcmFudGVlCnlvdSB0aGF0IGl0IHdpbGwg cmFpc2UgcXVpdGUgYSBmZXcgZXllYnJvd3MuIEkgZG9uJ3Qga25vdyBob3cgbXVjaCB0aGlzCnNp bXBsaWZpY2F0aW9uIHdvdWxkIHJlYWxseSBoZWxwIHJlYWRlcnMgb3IgYXV0aG9ycyBvZiBZQU5H IG1vZHVsZXMsIGJ1dAppdCBjYW4gZWFzaWx5IGdpdmUgYW4gaW1wcmVzc2lvbiB0aGF0IFlBTkcg aXMgYSBzbG9wcHkgc3RhbmRhcmQuCgpZQU5HIGNvbWJpbmVzIHR3byB0ZWNobm9sb2dpZXMgd2l0 aCBzb21lIGhpc3RvcnkgYW5kIHRoZWlyIG93bgppZGlvc3ljcmFzaWVzLCBzbyBJIHRoaW5rIGl0 J3MgY3J1Y2lhbCB0byBiZSBxdWl0ZSBjb25zZXJ2YXRpdmUgYW5kIGtlZXAKYWxsIHN0YW5kYXJk cywgc2luY2Ugb3RoZXJ3aXNlIHRoZSBvdGhlciBjYW1wIG1heSBkaXNtaXNzIHRoZSB3aG9sZQp0 aGluZyBzdHJhaWdodCBhd2F5LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBH UCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Aug 28 04:33:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578C63A6975; Thu, 28 Aug 2008 04:33:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A013A6B6C for ; Thu, 28 Aug 2008 04:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlUMs0gK5uwf for ; Thu, 28 Aug 2008 04:33:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A5CC93A6975 for ; Thu, 28 Aug 2008 04:33:44 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3447476C4DE; Thu, 28 Aug 2008 13:33:40 +0200 (CEST) Date: Thu, 28 Aug 2008 13:33:56 +0200 (CEST) Message-Id: <20080828.133356.34468690.mbj@tail-f.com> To: muenz@informatik.uni-tuebingen.de From: Martin Bjorklund In-Reply-To: <48B65BAF.5010307@informatik.uni-tuebingen.de> References: <48B65BAF.5010307@informatik.uni-tuebingen.de> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Gerhard Muenz wrote: > In IPFIX, we want to force the manager to provide a mandatory value in > some cases. In other cases, we want to give the manager to opportunity > to provide a mandatory value, yet if he does not want to, the device > chooses an appropriate value. So, it would be nice to have two types of > mandatory: > > - mandatory nodes which must be set by the manager > - mandatory nodes which may be set by the manager. If not, they are set > by the agent. That is what created-by gives you. > If mandatory is false, the data is optionally provided by the > manager. There are some interaction between created-by and mandatory, and it is not clear to me which combination(s) make sense. Maybe we should allow both mandatory true and false with created-by system: default | mandatory | cr-by | rule --------+-----------+-------+------------------------- no | false | sys | node MUST be created by system | | | if not created by user --------+-----------+-------+------------------------- no | true | sys | node MUST be created by system | | | if not created by user --------+-----------+-------+------------------------- Consider this example: list x { key id; leaf id { type int32; } leaf y { type int32; created-by system; } } If a client sends an edit-config with: 1 The server will create y and give it a value, say 42. Now, what happens if the client deletes /x/y? Will it get auto-recreated? (intuitively it seems weird if it is) What happens if the client deletes /x and then recreates /x? (intuitively it seems y should be auto-created as well. but then the question is why it gets auto-recreated in this case but not in the case above). > A final comment: agent-supplied values for mandatory nodes should not be > seen as agent-supplied default values. I fully agree. They should be reported even if with-defaults is false. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 04:47:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C07728C19D; Thu, 28 Aug 2008 04:47:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F333A6975 for ; Thu, 28 Aug 2008 04:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEG1Rqoq8Kyc for ; Thu, 28 Aug 2008 04:47:17 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 371933A6B90 for ; Thu, 28 Aug 2008 04:47:16 -0700 (PDT) Received: from [127.0.0.1] (u-173-c224.cs.uni-tuebingen.de [134.2.173.224]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m7SBlGTD028893; Thu, 28 Aug 2008 13:47:16 +0200 Message-ID: <48B69081.1010503@informatik.uni-tuebingen.de> Date: Thu, 28 Aug 2008 13:48:17 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B65BAF.5010307@informatik.uni-tuebingen.de> <20080828.133356.34468690.mbj@tail-f.com> In-Reply-To: <20080828.133356.34468690.mbj@tail-f.com> X-Enigmail-Version: 0.95.6 X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.1.23; VDF: 7.0.6.84; host: mx06) Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0449551435==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0449551435== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406030102030009090309" This is a cryptographically signed message in MIME format. --------------ms070406030102030009090309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Martin Bjorklund wrote: > Gerhard Muenz wrote: >> In IPFIX, we want to force the manager to provide a mandatory value in= >> some cases. In other cases, we want to give the manager to opportunity= >> to provide a mandatory value, yet if he does not want to, the device >> chooses an appropriate value. So, it would be nice to have two types o= f >> mandatory: >> >> - mandatory nodes which must be set by the manager >> - mandatory nodes which may be set by the manager. If not, they are se= t >> by the agent. >=20 > That is what created-by gives you. Hm. Then "created-by system" is a misleading term because it is only created by the system if not provided by the manager. >> If mandatory is false, the data is optionally provided by the >> manager. >=20 > There are some interaction between created-by and mandatory, and it is > not clear to me which combination(s) make sense. >=20 > Maybe we should allow both mandatory true and false with created-by > system: >=20 > default | mandatory | cr-by | rule > --------+-----------+-------+------------------------- > no | false | sys | node MUST be created by system > | | | if not created by user > --------+-----------+-------+------------------------- > no | true | sys | node MUST be created by system > | | | if not created by user > --------+-----------+-------+------------------------- Do you mean "MUST NOT" in the first case? > Consider this example: >=20 > list x { > key id; > leaf id { type int32; } > leaf y { > type int32; > created-by system; > } > } Does created-by system imply mandatory=3Dtrue? I'm not sure if created-by system should be mixed with optional nodes. It is confusing because the node will always exist, i.e. it is not optional in the sense that it may not exist in a valid configuration. > If a client sends an edit-config with: >=20 > > 1 > >=20 > The server will create y and give it a value, say 42. >=20 > Now, what happens if the client deletes /x/y? Will it get > auto-recreated? (intuitively it seems weird if it is) > > What happens if the client deletes /x and then recreates /x? > (intuitively it seems y should be auto-created as well. but then the > question is why it gets auto-recreated in this case but not in the > case above). You do not have this problem if created-by system is restricted to mandatory nodes. But again, "created-by system" sounds strange. Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070406030102030009090309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDgyODExNDgxN1owIwYJKoZIhvcNAQkEMRYEFDgjlPSi0dUw Ir//F71LHHaCjc/FMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQDA09rs2+fKUW8gIogToPAmwRyv8XotsD8Yv5aXd6G58c1f7yzIpD6iioq0 2fXHnIT9c0mc2KJD7eiis00K5bLj94Z3xH4EGhaQ8yC3NzjJPfGkGaSeDdzNnO/tSIdxV8kL fr0oGbdBDZMuEDJ6bj5W/8/bh3UD7/LVTqONmz5S3jaBfyYzng6QswFqkI+NoFFUtzRnJULY 5XNz1Y2ELambkQEIWKIP6oDHzRlPOb1hjlQj3+9nQ6MOY/Yx5RNv8sAWbEQmG8IF+qNb7JJh PZB9LOJttvEB9GSdaxFkHwW+tgkG+hlSmGrTzayDbIklKV1FgxeGQJhkvlrhPejR7pj3AAAA AAAA --------------ms070406030102030009090309-- --===============0449551435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============0449551435==-- From netmod-bounces@ietf.org Thu Aug 28 05:05:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1773A6A91; Thu, 28 Aug 2008 05:05:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5792A3A6B1E for ; Thu, 28 Aug 2008 05:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKKCntRINPrs for ; Thu, 28 Aug 2008 05:05:17 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3EA113A68FD for ; Thu, 28 Aug 2008 05:05:17 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C94B76C4DF; Thu, 28 Aug 2008 14:04:44 +0200 (CEST) Date: Thu, 28 Aug 2008 14:05:02 +0200 (CEST) Message-Id: <20080828.140502.100536161.mbj@tail-f.com> To: muenz@informatik.uni-tuebingen.de From: Martin Bjorklund In-Reply-To: <48B69081.1010503@informatik.uni-tuebingen.de> References: <48B65BAF.5010307@informatik.uni-tuebingen.de> <20080828.133356.34468690.mbj@tail-f.com> <48B69081.1010503@informatik.uni-tuebingen.de> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Gerhard Muenz wrote: > Hm. Then "created-by system" is a misleading term because it is only > created by the system if not provided by the manager. created-by-if-not-created-by-the-other-part system; seems a bit awkward :) > > Maybe we should allow both mandatory true and false with created-by > > system: > > > > default | mandatory | cr-by | rule > > --------+-----------+-------+------------------------- > > no | false | sys | node MUST be created by system > > | | | if not created by user > > --------+-----------+-------+------------------------- > > no | true | sys | node MUST be created by system > > | | | if not created by user > > --------+-----------+-------+------------------------- > > Do you mean "MUST NOT" in the first case? No I mean that the value of mandatory doesn't really matter when created-by is system. The effect is the same when the instance is initially created. > > Consider this example: > > > > list x { > > key id; > > leaf id { type int32; } > > leaf y { > > type int32; > > created-by system; > > } > > } > > Does created-by system imply mandatory=true? > > I'm not sure if created-by system should be mixed with optional nodes. > It is confusing because the node will always exist, i.e. it is not > optional in the sense that it may not exist in a valid configuration. That's what my example below tried to illustrate. If you have the view that created-by system implies mandatory true, then if a client deletes 'y' w/o recreating it won't be valid (or it should get auto-created). If created-by system works with mandatory false, then it would be just an initial value provided by the system, which a client later can delete. > > If a client sends an edit-config with: > > > > > > 1 > > > > > > The server will create y and give it a value, say 42. > > > > Now, what happens if the client deletes /x/y? Will it get > > auto-recreated? (intuitively it seems weird if it is) > > > > What happens if the client deletes /x and then recreates /x? > > (intuitively it seems y should be auto-created as well. but then the > > question is why it gets auto-recreated in this case but not in the > > case above). > > You do not have this problem if created-by system is restricted to > mandatory nodes. So assuming we restrict created-by system to mandatory true, will /x/y get auto-recreated in the first case above? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 05:46:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCFA3A6C54; Thu, 28 Aug 2008 05:46:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E5E3A6C54 for ; Thu, 28 Aug 2008 05:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu4eU6xFOJ6q for ; Thu, 28 Aug 2008 05:46:27 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 903F33A6C1C for ; Thu, 28 Aug 2008 05:46:27 -0700 (PDT) Received: (qmail 13930 invoked from network); 28 Aug 2008 12:46:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 12:46:11 -0000 X-YMail-OSG: 7NNjmS8VM1nhbyLULTSFxpvfmbIZIWRTL56EG4pltYW4WLmboMI7xTfOeYpzTru9L8wTj8_KCnuAEaZ54ME4PljKzLJy.jgVZLq_hbmwCZ8V1EO6_Bo8PwQZUqYnexE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B69E10.2040506@netconfcentral.com> Date: Thu, 28 Aug 2008 05:46:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200808270221.m7R2Lkj7094588@idle.juniper.net> <48B5B851.2020609@netconfcentral.com> <20080828.091041.60970813.mbj@tail-f.com> In-Reply-To: <20080828.091041.60970813.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> default | mandatory | cr-by | rule > >>>> yes | false | sys | node MUST be created by system (d) > >>> Why would you have a default on a "created-by system" node? If the >>> node has a fixed default value, why would the system need to create >>> it? >>> >> So this should be illegal YANG? >> It is just redundant. Seems like a harsh CLR. > > IMO it's not redundant, it's confusing. Which one takes precedence? > The YANG definition of mandatory making 'default' illegal is also confusing people. This CLR would be consistent with that one. > > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 05:54:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B279F28C0EE; Thu, 28 Aug 2008 05:54:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ADF28C273 for ; Thu, 28 Aug 2008 05:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM-r8-YMaatp for ; Thu, 28 Aug 2008 05:54:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0BEFE28C23F for ; Thu, 28 Aug 2008 05:54:51 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0E96220479; Thu, 28 Aug 2008 14:54:12 +0200 (CEST) X-AuditID: c1b4fb3c-af8d1bb0000015b5-33-48b69ff3e51f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E4B322040E; Thu, 28 Aug 2008 14:54:11 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 14:54:11 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 14:54:11 +0200 Message-ID: <48B69FD5.8080502@ericsson.com> Date: Thu, 28 Aug 2008 14:53:41 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <200808270221.m7R2Lkj7094588@idle.juniper.net> <48B5B851.2020609@netconfcentral.com> In-Reply-To: <48B5B851.2020609@netconfcentral.com> X-OriginalArrivalTime: 28 Aug 2008 12:54:11.0557 (UTC) FILETIME=[2AE3D950:01C9090D] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, This is actually how many of our nodes work. For us all leafs with default values are actually created, so please don't make this forbidden !!! Balazs Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> yes | false | sys | node MUST be created by system (d) >> Why would you have a default on a "created-by system" node? If the >> node has a fixed default value, why would the system need to create >> it? >> > > So this should be illegal YANG? > It is just redundant. Seems like a harsh CLR. > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 06:09:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3174728C0EE; Thu, 28 Aug 2008 06:09:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABB028C2C0 for ; Thu, 28 Aug 2008 06:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQplrVjmlNG4 for ; Thu, 28 Aug 2008 06:09:07 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 2884928C0EE for ; Thu, 28 Aug 2008 06:09:07 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 7ohz1a0081HzFnQ51p9988; Thu, 28 Aug 2008 13:09:09 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 7p991a00J4HwxpC3ap99uL; Thu, 28 Aug 2008 13:09:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=XIQAHDikO16RRy9RS5AA:9 a=CX8elZWC1yT6r4hISy_EQYt7AxYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Thu, 28 Aug 2008 09:09:09 -0400 Message-ID: <035601c9090f$423838b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJD0HdYfmHJuK0TZeCf3QsWew0aA== Subject: [netmod] "with-defaults" discussion X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I doubt there are many on the netmod list that do not also subscribe to the netconf list, but just in case... please be aware that the netconf WG is discussing a "with-defaults" protocol feature. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 06:11:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B0E28C0EE; Thu, 28 Aug 2008 06:11:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB40428C0EE for ; Thu, 28 Aug 2008 06:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98mpQyoZkdB1 for ; Thu, 28 Aug 2008 06:11:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 08E1128C2C0 for ; Thu, 28 Aug 2008 06:11:51 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D7E84205C2; Thu, 28 Aug 2008 15:11:52 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-23-48b6a41881ef Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC7CE20107; Thu, 28 Aug 2008 15:11:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 15:11:52 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 15:11:52 +0200 Message-ID: <48B6A3FA.6000603@ericsson.com> Date: Thu, 28 Aug 2008 15:11:22 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200808270221.m7R2Lkj7094588@idle.juniper.net> In-Reply-To: <200808270221.m7R2Lkj7094588@idle.juniper.net> X-OriginalArrivalTime: 28 Aug 2008 13:11:52.0049 (UTC) FILETIME=[A2FE1610:01C9090F] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> default | mandatory | cr-by | rule >> --------+-----------+-------+------------------------- >> no | false | sys | node MUST be created by system (b) > > In order to save and restore configuration datasets, a "created-by > system" node must be allowed to be created by the user when the > instance is first created. > created by should just mean: the leaf is created by the system, if it is not crated by the manager, when its containing container/list-item is created. So system created should not mean the user can not create it. system-created has two values true/false false being the default. Using the values user/system would seem to imply that a system created leaf can not be created by the user, which is not our (my) intention. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 06:13:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59573A6C37; Thu, 28 Aug 2008 06:13:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D1E3A6B9F for ; Thu, 28 Aug 2008 06:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkthFyXkdWjj for ; Thu, 28 Aug 2008 06:13:09 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 1C42C3A6945 for ; Thu, 28 Aug 2008 06:13:08 -0700 (PDT) Received: from [127.0.0.1] (u-173-c224.cs.uni-tuebingen.de [134.2.173.224]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m7SCMDFg032760; Thu, 28 Aug 2008 14:22:14 +0200 Message-ID: <48B698B3.7070603@informatik.uni-tuebingen.de> Date: Thu, 28 Aug 2008 14:23:15 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B65BAF.5010307@informatik.uni-tuebingen.de> <20080828.133356.34468690.mbj@tail-f.com> <48B69081.1010503@informatik.uni-tuebingen.de> <20080828.140502.100536161.mbj@tail-f.com> In-Reply-To: <20080828.140502.100536161.mbj@tail-f.com> X-Enigmail-Version: 0.95.6 X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.1.23; VDF: 7.0.6.84; host: mx06) Cc: netmod@ietf.org Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1707629902==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1707629902== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030006040809020406000103" This is a cryptographically signed message in MIME format. --------------ms030006040809020406000103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: > Gerhard Muenz wrote: >> Hm. Then "created-by system" is a misleading term because it is only >> created by the system if not provided by the manager. > > created-by-if-not-created-by-the-other-part system; > > seems a bit awkward :) BTW: what does "created-by user" mean? Or is system the only valid parameter for created by? We could call it: auto-configurable true/false; >>> Maybe we should allow both mandatory true and false with created-by >>> system: >>> >>> default | mandatory | cr-by | rule >>> --------+-----------+-------+------------------------- >>> no | false | sys | node MUST be created by system >>> | | | if not created by user >>> --------+-----------+-------+------------------------- >>> no | true | sys | node MUST be created by system >>> | | | if not created by user >>> --------+-----------+-------+------------------------- >> Do you mean "MUST NOT" in the first case? > > No I mean that the value of mandatory doesn't really matter when > created-by is system. The effect is the same when the instance is > initially created. > >>> Consider this example: >>> >>> list x { >>> key id; >>> leaf id { type int32; } >>> leaf y { >>> type int32; >>> created-by system; >>> } >>> } >> Does created-by system imply mandatory=true? >> >> I'm not sure if created-by system should be mixed with optional nodes. >> It is confusing because the node will always exist, i.e. it is not >> optional in the sense that it may not exist in a valid configuration. > > That's what my example below tried to illustrate. If you have the > view that created-by system implies mandatory true, then if a client > deletes 'y' w/o recreating it won't be valid (or it should get > auto-created). Yes. > If created-by system works with mandatory false, then > it would be just an initial value provided by the system, which a > client later can delete. Maybe it makes sense. Yet, we do not have such a use-case in IPFIX. >>> If a client sends an edit-config with: >>> >>> >>> 1 >>> >>> >>> The server will create y and give it a value, say 42. >>> >>> Now, what happens if the client deletes /x/y? Will it get >>> auto-recreated? (intuitively it seems weird if it is) >>> >>> What happens if the client deletes /x and then recreates /x? >>> (intuitively it seems y should be auto-created as well. but then the >>> question is why it gets auto-recreated in this case but not in the >>> case above). >> You do not have this problem if created-by system is restricted to >> mandatory nodes. > > So assuming we restrict created-by system to mandatory true, will /x/y > get auto-recreated in the first case above? Yes. Remove means that the manager is not interested any more in setting a specific value. So, it is up to the agent to assign a new one - or keep using the old one. Gerhard --------------ms030006040809020406000103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDgyODEyMjMxNVowIwYJKoZIhvcNAQkEMRYEFILxw+lpY4pJ Oblsfq5+AebaIS++MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBDBZRUiikubiidwNO/B/LloIM/YkzZglrHjFO/88OsCIaS0wmBO1s+uTvb AmdYQr48l5mlXV9TBEjw7f6aAf1gN5W+lO3Xr2BTOYsM7ASDIr//dOspSeEvLKo8scZ9SOBX n3r+2Y2ozraTZnO3Jk45xkQrESf+1liuBXpADAmq25c/Hokf8MUUjkoz8TvBrIMbuVajuK2v IhEYKQs5GPup3tRJ6e+xvVjg7JFvZgP7xDz+9uxtgJwKD3lLpTJLaXr1RerwolLGDZAyOuxd wI2RWjqv2ZNgq1bn6EHQzXzuSdBua/koDlquCuxWOBWQvgrzew0SWX33gqF3hV667m0cAAAA AAAA --------------ms030006040809020406000103-- --===============1707629902== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============1707629902==-- From netmod-bounces@ietf.org Thu Aug 28 06:14:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC083A686B; Thu, 28 Aug 2008 06:14:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4CD3A686B for ; Thu, 28 Aug 2008 06:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgnHJPqCS+Am for ; Thu, 28 Aug 2008 06:14:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4F2153A6B6A for ; Thu, 28 Aug 2008 06:14:05 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31518212BD; Thu, 28 Aug 2008 15:12:26 +0200 (CEST) X-AuditID: c1b4fb3e-a8684bb000007a96-79-48b6a43a04a9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 15459211D7; Thu, 28 Aug 2008 15:12:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 15:12:25 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 15:12:25 +0200 Message-ID: <48B6A41B.1070307@ericsson.com> Date: Thu, 28 Aug 2008 15:11:55 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48B65BAF.5010307@informatik.uni-tuebingen.de> <20080828.133356.34468690.mbj@tail-f.com> In-Reply-To: <20080828.133356.34468690.mbj@tail-f.com> X-OriginalArrivalTime: 28 Aug 2008 13:12:25.0220 (UTC) FILETIME=[B6C39440:01C9090F] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org, muenz@informatik.uni-tuebingen.de Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org See below: Martin Bjorklund wrote: > > Consider this example: > > list x { > key id; > leaf id { type int32; } > leaf y { > type int32; > created-by system; > } > } > > If a client sends an edit-config with: > > > 1 > > > The server will create y and give it a value, say 42. > > Now, what happens if the client deletes /x/y? Will it get > auto-recreated? (intuitively it seems weird if it is) > > What happens if the client deletes /x and then recreates /x? > (intuitively it seems y should be auto-created as well. but then the > question is why it gets auto-recreated in this case but not in the > case above). BALAZS: I would argue that created-by system takes effect only when the containing container/list is created. > > >> A final comment: agent-supplied values for mandatory nodes should not be >> seen as agent-supplied default values. > > I fully agree. They should be reported even if with-defaults is > false. BALAZS: So once the system created "y" it behaves just as if it was set by the manager? > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 06:29:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FF63A63EC; Thu, 28 Aug 2008 06:29:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446B03A68D4 for ; Thu, 28 Aug 2008 06:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpUxPxHsSCjb for ; Thu, 28 Aug 2008 06:28:59 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 47FAB3A63EC for ; Thu, 28 Aug 2008 06:28:59 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA10.westchester.pa.mail.comcast.net with comcast id 7mlZ1a00B16LCl05ApV2fm; Thu, 28 Aug 2008 13:29:02 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 7pV11a00a4HwxpC3SpV1Eo; Thu, 28 Aug 2008 13:29:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=USJWYMnkhbEJZ9EiViEA:9 a=OFknzr9t_3pSdfFlLxcKdAloFSYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <48B65BAF.5010307@informatik.uni-tuebingen.de><20080828.133356.34468690.mbj@tail-f.com> <48B6A41B.1070307@ericsson.com> Date: Thu, 28 Aug 2008 09:29:01 -0400 Message-ID: <035f01c90912$08e3d4e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48B6A41B.1070307@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJD/jLSHHrUEMeSW6jytAlarGo1gAAZuMQ Subject: Re: [netmod] various defaults discussions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, As co-chair I have a request. Can we split this "various" thread into separate topics? That will make it much easier for the chairs to determine when consensus has been achieved on specific points. Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 06:30:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E103A68D4; Thu, 28 Aug 2008 06:30:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF153A6A61 for ; Thu, 28 Aug 2008 06:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67NFvJwhoonO for ; Thu, 28 Aug 2008 06:30:06 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 771DB3A68D4 for ; Thu, 28 Aug 2008 06:30:06 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 7mPL1a00G0xGWP854pW9gy; Thu, 28 Aug 2008 13:30:09 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 7pW71a01Z4HwxpC3YpW8Fg; Thu, 28 Aug 2008 13:30:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=T1mPfaCDnMVkdOAbQqAA:9 a=vDudNNNNxS2ewO8PzB80XS3M0MUA:4 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=3I_whO4B8K8A:10 From: "David Harrington" To: Date: Thu, 28 Aug 2008 09:30:07 -0400 Message-ID: <036001c90912$305a85f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJD/jLSHHrUEMeSW6jytAlarGo1gAAZuMQAAAfRVA= Subject: [netmod] chair request X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Just to make it more apparent ... -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Thursday, August 28, 2008 9:29 AM To: 'netmod@ietf.org' Subject: RE: [netmod] various defaults discussions Hi, As co-chair I have a request. Can we split this "various" thread into separate topics? That will make it much easier for the chairs to determine when consensus has been achieved on specific points. Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 08:50:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3433A6B48; Thu, 28 Aug 2008 08:50:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035E528C1D0 for ; Thu, 28 Aug 2008 08:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfHjeZ5PxZLc for ; Thu, 28 Aug 2008 08:50:31 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 20E5F3A6B48 for ; Thu, 28 Aug 2008 08:50:31 -0700 (PDT) Received: (qmail 37057 invoked from network); 28 Aug 2008 15:49:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 15:49:55 -0000 X-YMail-OSG: cc45tJgVM1kNmnmAFH62eWZn0KUtdrhZrbt9RzbkQSuatZG.ibRSqklnm28Be3uDcBMjSylBRXwxBWvV50xbbUSjzlXoSu1UlcC1JgaaFQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B6C91D.8020907@netconfcentral.com> Date: Thu, 28 Aug 2008 08:49:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <200808270221.m7R2Lkj7094588@idle.juniper.net> <48B5B851.2020609@netconfcentral.com> <48B69FD5.8080502@ericsson.com> In-Reply-To: <48B69FD5.8080502@ericsson.com> Cc: netmod@ietf.org Subject: [netmod] created-by statement (was Re: various defaults discussions) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > This is actually how many of our nodes work. For us all leafs with > default values are actually created, so please don't make this forbidden > !!! Phil is saying that default-stmt within the same leaf as created-by is illegal, just like default-stmt and mandatory=true on any leaf. IMO, these are CLRs which reflect one vendors implementation of the config database. If 2 clauses overlap in semantics (and they do), then setting both knobs to indicate the same semantics is just a little redundant, not an error. If you have default=3, then it is redundant to say the agent will create a value if none is provided (created-by system), since default=stmt does the same thing. Since the default for created-by is 'system', then it is implicitly set anytime default-stmt is present. But if you explicitly state 'created-by system', that turns it into a fatal error. This is barely worth a warning message, let alone a fatal error. > Balazs Andy > > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> yes | false | sys | node MUST be created by system (d) >>> Why would you have a default on a "created-by system" node? If the >>> node has a fixed default value, why would the system need to create >>> it? >>> >> >> So this should be illegal YANG? >> It is just redundant. Seems like a harsh CLR. >> > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 09:42:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4420A3A694D; Thu, 28 Aug 2008 09:42:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B653A694D for ; Thu, 28 Aug 2008 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZG0RHVSFpX8 for ; Thu, 28 Aug 2008 09:42:39 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id B33B23A6AAD for ; Thu, 28 Aug 2008 09:42:39 -0700 (PDT) Received: (qmail 24118 invoked from network); 28 Aug 2008 16:42:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 28 Aug 2008 16:42:39 -0000 X-YMail-OSG: pGo5mYoVM1m2HlA45_DCjMGJu5nOM2N4ZU_nW2Xm9P36Pc2zIB5wvFIelxrBwKZcWtwWqj75bDTwD8w8pdgdA3jIvUZzGMWZ341joVNSPw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B6D57D.1080004@netconfcentral.com> Date: Thu, 28 Aug 2008 09:42:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <200808270221.m7R2Lkj7094588@idle.juniper.net> <48B5B851.2020609@netconfcentral.com> <48B69FD5.8080502@ericsson.com> <48B6C91D.8020907@netconfcentral.com> In-Reply-To: <48B6C91D.8020907@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement (was Re: various defaults discussions) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> This is actually how many of our nodes work. For us all leafs with >> default values are actually created, so please don't make this forbidden >> !!! > > > Phil is saying that default-stmt within the same leaf > as created-by is illegal, just like default-stmt and > mandatory=true on any leaf. > > IMO, these are CLRs which reflect one vendors implementation > of the config database. > > If 2 clauses overlap in semantics (and they do), > then setting both knobs to indicate the same semantics > is just a little redundant, not an error. > If you have default=3, then it is redundant to > say the agent will create a value if none is provided > (created-by system), since default=stmt does the same thing. > > Since the default for created-by is 'system', then it is > implicitly set anytime default-stmt is present. But if you > explicitly state 'created-by system', that turns it into > a fatal error. > oops -- the default is 'user' not 'system', but 'created-by system' and 'default 7' in the same leaf are not contradictory. I agree with Phil (after 2 years trying not to) that mandatory means the user must provide a value. Period. So default and mandatory together contradict, because one says the agent will never provide a value, and the other says here's the value the agent will provide. Created-by and default together is not the same situation. > This is barely worth a warning message, let alone a fatal error. > >> Balazs > > Andy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 10:19:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5063A685F; Thu, 28 Aug 2008 10:19:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D003A685F for ; Thu, 28 Aug 2008 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haH3DP8t7+kH for ; Thu, 28 Aug 2008 10:19:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6EA973A6823 for ; Thu, 28 Aug 2008 10:18:59 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 29F232136C; Thu, 28 Aug 2008 19:18:36 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-c2-48b6ddecb80a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0B4292053D; Thu, 28 Aug 2008 19:18:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 19:18:35 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 19:18:35 +0200 Message-ID: <48B6DDCE.3080203@ericsson.com> Date: Thu, 28 Aug 2008 19:18:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200808281706.m7SH6rk1014175@idle.juniper.net> In-Reply-To: <200808281706.m7SH6rk1014175@idle.juniper.net> X-OriginalArrivalTime: 28 Aug 2008 17:18:35.0437 (UTC) FILETIME=[1A7FD5D0:01C90932] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement (was Re: various defaults discussions) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> IMO, these are CLRs which reflect one vendors implementation >> of the config database. > > I disagree. These are two rules that when combined make behavior > I don't find attractive. If a leaf is "created-by system" and has > a default, then the system is responsible for making it if the > client does not set it, but the server must must make it with a > fixed value. Instantiating a fixed default value has little > positive value and I'm happy to make a CLR that help data modelers > avoid this pitfall. Balazs: Some of our major systems already do this, so you are asking us to redesign the database behind the Netconf implementation. I don't like that. If we only need to implement a new interface (NETCONF) for our existing configuration database thats MUCH cheaper then redesigning the database as well. Our customers have a few more important requests then changing the handling of defaults. Even if you think ,this is not the best solution, we don't get complaints about it. It is simple understandable, and a tool can filter the defaults if needed. So don't make the CLR. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 10:57:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4556028C2A2; Thu, 28 Aug 2008 10:57:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86213A6C9D for ; Thu, 28 Aug 2008 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-horw1AZZbW for ; Thu, 28 Aug 2008 10:57:55 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 91B793A6CA8 for ; Thu, 28 Aug 2008 10:57:55 -0700 (PDT) X-Trace: 129201226/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.131.98 X-SBRS: None X-RemoteIP: 62.188.131.98 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAIaEtkg+vINi/2dsb2JhbACDR4hDrhQDgWc X-IronPort-AV: E=Sophos;i="4.32,287,1217804400"; d="scan'208";a="129201226" X-IP-Direction: IN Received: from 1cust98.tnt2.lnd4.gbr.da.uu.net (HELO allison) ([62.188.131.98]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Aug 2008 18:57:43 +0100 Message-ID: <009c01c9092e$3ffa8ca0$0601a8c0@allison> From: "tom.petch" To: "Phil Shafer" References: <200808271956.m7RJui9U002410@idle.juniper.net> Date: Thu, 28 Aug 2008 18:25:12 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Phil Shafer" To: "tom.petch" Cc: "Ladislav Lhotka" ; "David Partain" ; Sent: Wednesday, August 27, 2008 9:56 PM Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to) > "tom.petch" writes: > >Null namespace is a different concept. For YANG to redefine > >its meaning will confuse anyone familiar with XPath 1.0. > > I'm surprised that this is considered confusing. In a YANG XPath, > the null namespace (elements with no namespace URI) refers to the > current module. This is simple and natural. Adding prefixes at > inconsistent moments is sure to be far more confusing. > The null namespace (or no namespace) is a namespace. To redefine that namespace to be something different is likely to, as Lada suggests, diminish the standing of YANG in the eyes of those familiar with XPath(/XML/XSD...). Tom Petch > Compare this is XSD, where the null namespace refers to the namespace > named in the targetNamespace attribute on the element. > Or XQuery, where unprefixed elements are in the default element/type > namespace, which can be set in a number of ways. Or many other w3c > standards that define the context in which XPath expressions are > evaluated. > > Thanks, > Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 11:07:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645973A6819; Thu, 28 Aug 2008 11:07:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC6B28C2FC for ; Thu, 28 Aug 2008 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv+ruMjX-wBS for ; Thu, 28 Aug 2008 11:07:31 -0700 (PDT) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with ESMTP id E74D03A6A99 for ; Thu, 28 Aug 2008 11:07:02 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob57.postini.com ([64.18.6.12]) with SMTP; Thu, 28 Aug 2008 11:07:00 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 10:12:09 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 10:12:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 10:10:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7SHATu14646; Thu, 28 Aug 2008 10:10:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7SH6rk1014175; Thu, 28 Aug 2008 17:06:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808281706.m7SH6rk1014175@idle.juniper.net> To: Andy Bierman In-reply-to: <48B6C91D.8020907@netconfcentral.com> Date: Thu, 28 Aug 2008 13:06:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 28 Aug 2008 17:10:29.0440 (UTC) FILETIME=[F8D29400:01C90930] Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement (was Re: various defaults discussions) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >IMO, these are CLRs which reflect one vendors implementation >of the config database. I disagree. These are two rules that when combined make behavior I don't find attractive. If a leaf is "created-by system" and has a default, then the system is responsible for making it if the client does not set it, but the server must must make it with a fixed value. Instantiating a fixed default value has little positive value and I'm happy to make a CLR that help data modelers avoid this pitfall. >Since the default for created-by is 'system', then it is >implicitly set anytime default-stmt is present. But if you >explicitly state 'created-by system', that turns it into >a fatal error. Leafs with default values are _not_ automatically created by the system. The default value is implicit. Since both client and server know the value, it need not appear in the config database. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 11:40:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC063A6843; Thu, 28 Aug 2008 11:40:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDC83A6937 for ; Thu, 28 Aug 2008 11:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqP2Og-leuBt for ; Thu, 28 Aug 2008 11:40:46 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id DF0763A6843 for ; Thu, 28 Aug 2008 11:40:45 -0700 (PDT) Received: (qmail 15261 invoked from network); 28 Aug 2008 18:40:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 18:40:47 -0000 X-YMail-OSG: RPEPIoQVM1ldn.4e2h5N_W5yc897ZSrZLyEQGxqGB0PYhBzzeiAcrXOf8io0fT0afVqcQL4xTimzWwuGUUZBlv4xtvopXeIaUlecFXqd_g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B6F12D.40105@netconfcentral.com> Date: Thu, 28 Aug 2008 11:40:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808281706.m7SH6rk1014175@idle.juniper.net> In-Reply-To: <200808281706.m7SH6rk1014175@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement (was Re: various defaults discussions) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> IMO, these are CLRs which reflect one vendors implementation >> of the config database. > > I disagree. These are two rules that when combined make behavior > I don't find attractive. If a leaf is "created-by system" and has > a default, then the system is responsible for making it if the > client does not set it, but the server must must make it with a > fixed value. Instantiating a fixed default value has little > positive value and I'm happy to make a CLR that help data modelers > avoid this pitfall. > >> Since the default for created-by is 'system', then it is >> implicitly set anytime default-stmt is present. But if you >> explicitly state 'created-by system', that turns it into >> a fatal error. > > Leafs with default values are _not_ automatically created by the > system. The default value is implicit. Since both client and > server know the value, it need not appear in the config database. > Maybe inside your system it works that way. We need to focus on the impact of YANG statements on NETCONF PDU exchanges, and not worry about various implementation details within an agent. If I store the leaf instance-identifier, leaf type, leaf default inside the agent, or if I create a real node inside the database containing the default value, it is just an implementation detail. What difference does it make how I construct the , as long as the correct behavior for the operation is observed? > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 11:59:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368033A688D; Thu, 28 Aug 2008 11:59:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376453A6921 for ; Thu, 28 Aug 2008 11:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKKjSq7DpJhr for ; Thu, 28 Aug 2008 11:59:53 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BC5043A688D for ; Thu, 28 Aug 2008 11:59:53 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id E7C6A76C4DF; Thu, 28 Aug 2008 20:59:50 +0200 (CEST) Date: Thu, 28 Aug 2008 20:59:50 +0200 (CEST) Message-Id: <20080828.205950.152846111.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B6D57D.1080004@netconfcentral.com> References: <48B69FD5.8080502@ericsson.com> <48B6C91D.8020907@netconfcentral.com> <48B6D57D.1080004@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Andy Bierman wrote: > > Balazs Lengyel wrote: > >> Hello, > >> This is actually how many of our nodes work. For us all leafs with > >> default values are actually created, so please don't make this forbidden > >> !!! > > > > > > Phil is saying that default-stmt within the same leaf > > as created-by is illegal, just like default-stmt and > > mandatory=true on any leaf. > > > > IMO, these are CLRs which reflect one vendors implementation > > of the config database. The YANG spec does not say anything about how to implement the config database. In fact, we're trying hard to make sure that the rules we define are flexible enough to work with more than one implementation. With the addition of the with-defaults capability, I think we have managed to do that. > > If 2 clauses overlap in semantics (and they do), > > then setting both knobs to indicate the same semantics > > is just a little redundant, not an error. > > If you have default=3, then it is redundant to > > say the agent will create a value if none is provided > > (created-by system), since default=stmt does the same thing. No, they do *not* do the same thing. If a leaf is marked as created-by system, it will not be a "default" value, and thus cannot be filtered out if with-defaults=false. So having both statements is confusing. Should the server use the fixed default value in the data model and mark it as a default, or can it provide any value it wants to and not mark it as default? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 12:12:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51653A6C4B; Thu, 28 Aug 2008 12:12:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408233A681D for ; Thu, 28 Aug 2008 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8c2LPMoO20l for ; Thu, 28 Aug 2008 12:12:31 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 841B63A6CE9 for ; Thu, 28 Aug 2008 12:12:29 -0700 (PDT) Received: (qmail 68243 invoked from network); 28 Aug 2008 19:12:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 19:12:31 -0000 X-YMail-OSG: shpf_IQVM1kL2XARyLRkvkFcqgjgO6HgXNJ1E2.KhhkIz_Sfkwpx94ZNutfxn.Fx2NyF.DrdrNePNCIGCgI2rNk5YBdEgkkfXq5FsYaHhnsz_1XjR_52t42ILdtiiNwMU8Qv2OKOc9z1lTRLGQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B6F89C.30102@netconfcentral.com> Date: Thu, 28 Aug 2008 12:12:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B69FD5.8080502@ericsson.com> <48B6C91D.8020907@netconfcentral.com> <48B6D57D.1080004@netconfcentral.com> <20080828.205950.152846111.mbj@tail-f.com> In-Reply-To: <20080828.205950.152846111.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Andy Bierman wrote: >>> Balazs Lengyel wrote: >>>> Hello, >>>> This is actually how many of our nodes work. For us all leafs with >>>> default values are actually created, so please don't make this forbidden >>>> !!! >>> >>> Phil is saying that default-stmt within the same leaf >>> as created-by is illegal, just like default-stmt and >>> mandatory=true on any leaf. >>> >>> IMO, these are CLRs which reflect one vendors implementation >>> of the config database. > > The YANG spec does not say anything about how to implement the config > database. In fact, we're trying hard to make sure that the rules we > define are flexible enough to work with more than one implementation. > With the addition of the with-defaults capability, I think we have > managed to do that. > I don't. The YANG spec does not yet have a clear and contained mapping to the NETCONF protocol PDUs. >>> If 2 clauses overlap in semantics (and they do), >>> then setting both knobs to indicate the same semantics >>> is just a little redundant, not an error. >>> If you have default=3, then it is redundant to >>> say the agent will create a value if none is provided >>> (created-by system), since default=stmt does the same thing. > > No, they do *not* do the same thing. If a leaf is marked as > created-by system, it will not be a "default" value, and thus cannot > be filtered out if with-defaults=false. > > So having both statements is confusing. Should the server use the > fixed default value in the data model and mark it as a default, or can > it provide any value it wants to and not mark it as default? > Created-by system just means it is created by the agent if the manager does not provide a value. It should mean that the agent is free to choose a value based on the semantics of the leaf. If the leaf has a default, that's just another restriction, like 'uint8 (1..100)' for the data type. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 12:13:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E843A681D; Thu, 28 Aug 2008 12:13:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65043A6807 for ; Thu, 28 Aug 2008 12:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV13pzrA9m+7 for ; Thu, 28 Aug 2008 12:13:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CA8FB3A68D5 for ; Thu, 28 Aug 2008 12:13:44 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id AFB7776C4DF; Thu, 28 Aug 2008 21:13:47 +0200 (CEST) Date: Thu, 28 Aug 2008 21:13:45 +0200 (CEST) Message-Id: <20080828.211345.255648453.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B6DDCE.3080203@ericsson.com> References: <200808281706.m7SH6rk1014175@idle.juniper.net> <48B6DDCE.3080203@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > > > Phil Shafer wrote: > > Andy Bierman writes: > >> IMO, these are CLRs which reflect one vendors implementation > >> of the config database. > > > > I disagree. These are two rules that when combined make behavior > > I don't find attractive. If a leaf is "created-by system" and has > > a default, then the system is responsible for making it if the > > client does not set it, but the server must must make it with a > > fixed value. Instantiating a fixed default value has little > > positive value and I'm happy to make a CLR that help data modelers > > avoid this pitfall. > > Balazs: Some of our major systems already do this, so you are asking > us to redesign the database behind the Netconf implementation. IMO, you will still be able to instantiate default values if you want to. Nowhere do we say that an implementation MUST or MUST NOT store default values. What we *do* say is that if your device supports the new :with-defaults capability, it should be able to filter out leafs w/ default values. If your device cannot do this, don't advertise :with-defaults. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 12:19:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE02D3A68E6; Thu, 28 Aug 2008 12:19:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688903A68E6 for ; Thu, 28 Aug 2008 12:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Arb4eO1tkEA for ; Thu, 28 Aug 2008 12:19:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 973A33A6899 for ; Thu, 28 Aug 2008 12:19:01 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 7386D76C4E9; Thu, 28 Aug 2008 21:19:04 +0200 (CEST) Date: Thu, 28 Aug 2008 21:19:01 +0200 (CEST) Message-Id: <20080828.211901.172574307.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B6F89C.30102@netconfcentral.com> References: <48B6D57D.1080004@netconfcentral.com> <20080828.205950.152846111.mbj@tail-f.com> <48B6F89C.30102@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > The YANG spec does not yet have a clear and contained mapping > to the NETCONF protocol PDUs. Please raise your concerns about this. What should be improved? > >>> If 2 clauses overlap in semantics (and they do), > >>> then setting both knobs to indicate the same semantics > >>> is just a little redundant, not an error. > >>> If you have default=3, then it is redundant to > >>> say the agent will create a value if none is provided > >>> (created-by system), since default=stmt does the same thing. > > No, they do *not* do the same thing. If a leaf is marked as > > created-by system, it will not be a "default" value, and thus cannot > > be filtered out if with-defaults=false. > > So having both statements is confusing. Should the server use the > > fixed default value in the data model and mark it as a default, or can > > it provide any value it wants to and not mark it as default? > > > > Created-by system just means it is created by the agent > if the manager does not provide a value. It should mean > that the agent is free to choose a value based on the > semantics of the leaf. If the leaf has a default, > that's just another restriction, like 'uint8 (1..100)' for > the data type. Hmm. Are you saying that if the default statement is present and created-by system is present, then the default value is more like DEFVAL from SMIv2? I.e. the server must create a value, and the default valus is a hint. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 12:37:37 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FA63A680D; Thu, 28 Aug 2008 12:37:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C043A69BF for ; Thu, 28 Aug 2008 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk0R9IM+HCrh for ; Thu, 28 Aug 2008 12:37:36 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id CDA713A67EE for ; Thu, 28 Aug 2008 12:37:35 -0700 (PDT) Received: (qmail 17727 invoked from network); 28 Aug 2008 19:37:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 19:37:37 -0000 X-YMail-OSG: RyuW2zEVM1mRzSpHTcwA1GhGUFno.edX6zCVz_Dc9zKLWKCSiNX2hqhQwkSO8fLDNNjVf7DCpstRXusGoSp9i4Uu3jpWS_bFQF6Ib_gY4PO6OO.IZ1QOaeC5W8SZ634- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B6FE7F.3060708@netconfcentral.com> Date: Thu, 28 Aug 2008 12:37:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B6D57D.1080004@netconfcentral.com> <20080828.205950.152846111.mbj@tail-f.com> <48B6F89C.30102@netconfcentral.com> <20080828.211901.172574307.mbj@tail-f.com> In-Reply-To: <20080828.211901.172574307.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> The YANG spec does not yet have a clear and contained mapping >> to the NETCONF protocol PDUs. > > Please raise your concerns about this. What should be improved? > There are bits as small as single sentences scattered throughout the document which say how NETCONF works for a YANG data model. I would prefer them all collected in one section, that made it very clear what NETCONF PDU behavior is expected. >>>>> If 2 clauses overlap in semantics (and they do), >>>>> then setting both knobs to indicate the same semantics >>>>> is just a little redundant, not an error. >>>>> If you have default=3, then it is redundant to >>>>> say the agent will create a value if none is provided >>>>> (created-by system), since default=stmt does the same thing. >>> No, they do *not* do the same thing. If a leaf is marked as >>> created-by system, it will not be a "default" value, and thus cannot >>> be filtered out if with-defaults=false. >>> So having both statements is confusing. Should the server use the >>> fixed default value in the data model and mark it as a default, or can >>> it provide any value it wants to and not mark it as default? >>> >> Created-by system just means it is created by the agent >> if the manager does not provide a value. It should mean >> that the agent is free to choose a value based on the >> semantics of the leaf. If the leaf has a default, >> that's just another restriction, like 'uint8 (1..100)' for >> the data type. > > Hmm. Are you saying that if the default statement is present and > created-by system is present, then the default value is more like > DEFVAL from SMIv2? I.e. the server must create a value, and the > default valus is a hint. no -- I am saying that created-by system is just a redundant field if a default-stmt is present. We do not make the following YANG illegal (I hope!) leaf foo { type uint8 { range "0..255"; } } The draft should just suggest that DM designers not use extra YANG statements when they are not really needed. It should not be an error. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 12:50:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3E23A67AF; Thu, 28 Aug 2008 12:50:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3613A6828 for ; Thu, 28 Aug 2008 12:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyhHJTFKJVTW for ; Thu, 28 Aug 2008 12:50:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 587D53A67AF for ; Thu, 28 Aug 2008 12:50:20 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id EE61F76C4DF; Thu, 28 Aug 2008 21:49:37 +0200 (CEST) Date: Thu, 28 Aug 2008 21:49:35 +0200 (CEST) Message-Id: <20080828.214935.243711090.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B6FE7F.3060708@netconfcentral.com> References: <48B6F89C.30102@netconfcentral.com> <20080828.211901.172574307.mbj@tail-f.com> <48B6FE7F.3060708@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > > Hmm. Are you saying that if the default statement is present and > > created-by system is present, then the default value is more like > > DEFVAL from SMIv2? I.e. the server must create a value, and the > > default valus is a hint. > > no -- I am saying that created-by system is just > a redundant field if a default-stmt is present. Do you agree that if I have this: leaf foo { type int32; created-by system; } leaf bar { type int32; default 42; } and a server replies to a with with-defaults=false, then the auto-created value of 'foo' is present in the rpc-reply, but the default value of 'bar' is not present? Assuming you do agree, it means that system created values are not marked as defaults. What happens if I have leaf foobar { type int32; default 42; created-by system; } will it be present in the rpc-reply or not? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Aug 28 13:09:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C409F3A6823; Thu, 28 Aug 2008 13:09:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712143A69BF for ; Thu, 28 Aug 2008 13:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uc+4SbYKqOy for ; Thu, 28 Aug 2008 13:09:18 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id F393A3A6823 for ; Thu, 28 Aug 2008 13:09:17 -0700 (PDT) Received: (qmail 71108 invoked from network); 28 Aug 2008 20:09:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 20:09:18 -0000 X-YMail-OSG: ywOPMR8VM1nKRvj1snDI9yBc8btQPZkcOdWgU5RkmdGP4w4iJeN4DOJY2SPtMpuwseXi6mEwC53gTQdxou.QpvWdc8NM7.1ez5hBXTREEvVCT9YnhW.Yp8_cRiov0dk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B705EC.6060703@netconfcentral.com> Date: Thu, 28 Aug 2008 13:09:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B6F89C.30102@netconfcentral.com> <20080828.211901.172574307.mbj@tail-f.com> <48B6FE7F.3060708@netconfcentral.com> <20080828.214935.243711090.mbj@tail-f.com> In-Reply-To: <20080828.214935.243711090.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>> Hmm. Are you saying that if the default statement is present and >>> created-by system is present, then the default value is more like >>> DEFVAL from SMIv2? I.e. the server must create a value, and the >>> default valus is a hint. >> no -- I am saying that created-by system is just >> a redundant field if a default-stmt is present. > > Do you agree that if I have this: > > leaf foo { > type int32; > created-by system; > } > leaf bar { > type int32; > default 42; > } > > and a server replies to a with with-defaults=false, then the > auto-created value of 'foo' is present in the rpc-reply, but the default > value of 'bar' is not present? no - I much prefer Phil's interpretation of with-defaults: true == I want everything regardless of how it got there false == I want only the stuff explicitly set by operators or the startup config I think the other interpretation is also valid, but needs more clarification. > > Assuming you do agree, it means that system created values are not > marked as defaults. What happens if I have > > leaf foobar { > type int32; > default 42; > created-by system; > } > > will it be present in the rpc-reply or not? > no > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 00:28:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF993A6898; Fri, 29 Aug 2008 00:28:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FC53A69FC for ; Fri, 29 Aug 2008 00:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPgM5b4+Y0xH for ; Fri, 29 Aug 2008 00:28:24 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0B2803A69DB for ; Fri, 29 Aug 2008 00:28:20 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id C26CD76C4E7; Fri, 29 Aug 2008 09:28:18 +0200 (CEST) Date: Fri, 29 Aug 2008 09:28:17 +0200 (CEST) Message-Id: <20080829.092817.260021532.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B49B7E.4080002@netconfcentral.com> References: <48B49B7E.4080002@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > Access control is not considered at all for unique tests. [...] > Note that the 'must-stmt' is allowed in many more places than > the 'unique-stmt', N entries per node, and there is no data > at all returned in the 'data-restriction-violation' error in E.4. > > IMO, the error in E.1 should work the same way. > No data. no security leak. "bailing out near line 1" - Not very helpful, but secure. What if we specify that any instance identifiers returned in the error MUST be checked for read access control? Otherwise, I think we have the same problem in general. When you do in NETCONF, and the config is invalid, with the "no data. no security leak." approach, the reply to should just be "error". Is that what we want? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 00:30:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A43528C310; Fri, 29 Aug 2008 00:30:19 -0700 (PDT) X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 39CB23A69F9; Fri, 29 Aug 2008 00:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080829071501.39CB23A69F9@core3.amsl.com> Date: Fri, 29 Aug 2008 00:15:01 -0700 (PDT) X-Mailman-Approved-At: Fri, 29 Aug 2008 00:30:18 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-01.txt Pages : 140 Date : 2008-08-29 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-29001122.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --NextPart-- From netmod-bounces@ietf.org Fri Aug 29 01:13:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366463A67D4; Fri, 29 Aug 2008 01:13:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0833A67F6 for ; Fri, 29 Aug 2008 01:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJG6EYbx-nXc for ; Fri, 29 Aug 2008 01:13:11 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id D7C283A67D4 for ; Fri, 29 Aug 2008 01:13:10 -0700 (PDT) Received: (qmail 69347 invoked from network); 29 Aug 2008 08:13:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.139.215 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 29 Aug 2008 08:13:07 -0000 X-YMail-OSG: fefCAZ8VM1kn9NHxBri0dtFlxZLSc4P1Dm5ybCQglWMq5gI73SuICVxyTprogUF5vqbDuCrS2HymhPR6f4O0mNbE4Nt_0UMjp8qKZium_x3a6CEiKAn0hsbOQmrF9hw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B7AF8F.3000201@netconfcentral.com> Date: Fri, 29 Aug 2008 01:13:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B49B7E.4080002@netconfcentral.com> <20080829.092817.260021532.mbj@tail-f.com> In-Reply-To: <20080829.092817.260021532.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Access control is not considered at all for unique tests. > > [...] > >> Note that the 'must-stmt' is allowed in many more places than >> the 'unique-stmt', N entries per node, and there is no data >> at all returned in the 'data-restriction-violation' error in E.4. >> >> IMO, the error in E.1 should work the same way. >> No data. no security leak. > > "bailing out near line 1" - Not very helpful, but secure. > > What if we specify that any instance identifiers returned in the error > MUST be checked for read access control? > > Otherwise, I think we have the same problem in general. When you do > in NETCONF, and the config is invalid, with the "no > data. no security leak." approach, the reply to should just > be "error". Is that what we want? > Explain to me again why all this data is needed for a unique-test failure, but none at all is needed for a must-test failure? Am I missing something? This data is not really needed at all. The commit or edit-config has failed. All the access control tests have passed, which is supposedly done in order to allow the operation in the first place. Access control is not a factor, We already punted this one by saying "by some magic, all access for the commit is granted". By the same magic, the error messages are secured. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 01:32:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FAB3A682E; Fri, 29 Aug 2008 01:32:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726963A682E for ; Fri, 29 Aug 2008 01:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsGr2NqQ20ei for ; Fri, 29 Aug 2008 01:32:23 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4EA0E3A6822 for ; Fri, 29 Aug 2008 01:32:23 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 0BAB576C4DC; Fri, 29 Aug 2008 10:32:26 +0200 (CEST) Date: Fri, 29 Aug 2008 10:32:23 +0200 (CEST) Message-Id: <20080829.103223.156479567.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B7AF8F.3000201@netconfcentral.com> References: <48B49B7E.4080002@netconfcentral.com> <20080829.092817.260021532.mbj@tail-f.com> <48B7AF8F.3000201@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> Access control is not considered at all for unique tests. > > [...] > > > >> Note that the 'must-stmt' is allowed in many more places than > >> the 'unique-stmt', N entries per node, and there is no data > >> at all returned in the 'data-restriction-violation' error in E.4. > >> > >> IMO, the error in E.1 should work the same way. > >> No data. no security leak. > > "bailing out near line 1" - Not very helpful, but secure. > > What if we specify that any instance identifiers returned in the error > > MUST be checked for read access control? > > Otherwise, I think we have the same problem in general. When you do > > in NETCONF, and the config is invalid, with the "no > > data. no security leak." approach, the reply to should just > > be "error". Is that what we want? > > > > Explain to me again why all this data is needed for > a unique-test failure, but none at all is needed > for a must-test failure? Am I missing something? > This data is not really needed at all. It's needed to help the operator understand why the config is not valid, and what can be done to resolve it. For 'must' expressions, we can't do much more than letting the error-path point to the node with the failing must and give an error-app-tag. But I expect implementations to attach more data in the error-info part of the rpc-reply, for some of these errors. [I had a proposal for also defining this error-info content, but at that time we said that it could wait.] I'd rather put in more data in the errors, in order to help the operator, than removing data. Taking your logic to the extreme, why do we specify error-app-tag and error-message at all? We can just say "error", and let the operator do a , and run all validation off-line to figure out why validation failed. > The commit or edit-config has failed. > All the access control tests have passed, > which is supposedly done in order to allow the operation > in the first place. Access control is not a factor, > We already punted this one by saying "by some magic, > all access for the commit is granted". By the same magic, > the error messages are secured. Are you saying that even if we do send the instance identifiers in the unqiue-error, it is not a security problem? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 02:02:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1EC3A6783; Fri, 29 Aug 2008 02:02:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930223A67A8 for ; Fri, 29 Aug 2008 02:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.485 X-Spam-Level: X-Spam-Status: No, score=-5.485 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_05=-1.11, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9r3Ss2Qjx7H for ; Fri, 29 Aug 2008 02:01:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 00BF13A6783 for ; Fri, 29 Aug 2008 02:01:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 262E320537 for ; Fri, 29 Aug 2008 11:01:09 +0200 (CEST) X-AuditID: c1b4fb3c-b00d2bb0000015b5-b5-48b7bad5ba63 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0F00120746 for ; Fri, 29 Aug 2008 11:01:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:01:08 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:01:07 +0200 Message-ID: <48B7BAB9.9010506@ericsson.com> Date: Fri, 29 Aug 2008 11:00:41 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group References: <48B5774E.6060407@ericsson.com> <48B5A566.50406@netconfcentral.com> <48B65E6B.1020904@ericsson.com> In-Reply-To: <48B65E6B.1020904@ericsson.com> X-OriginalArrivalTime: 29 Aug 2008 09:01:07.0982 (UTC) FILETIME=[C67162E0:01C909B5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Include question: reference to stuff in the main module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, What is the reason why a submodule can not see the contents of the containing module? Is it just that our current include/import mechanisms don't handle this or is there some deeper reason behind it? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 02:07:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9653A67E9; Fri, 29 Aug 2008 02:07:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8C73A67E9 for ; Fri, 29 Aug 2008 02:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci+bkMJjN2Wf for ; Fri, 29 Aug 2008 02:07:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 25E5F3A681B for ; Fri, 29 Aug 2008 02:07:54 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 0A14A76C4DC; Fri, 29 Aug 2008 11:07:42 +0200 (CEST) Date: Fri, 29 Aug 2008 11:07:39 +0200 (CEST) Message-Id: <20080829.110739.117300659.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B7BAB9.9010506@ericsson.com> References: <48B5A566.50406@netconfcentral.com> <48B65E6B.1020904@ericsson.com> <48B7BAB9.9010506@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Include question: reference to stuff in the main module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > > What is the reason why a submodule can not see the contents of the > containing module? Is it just that our current include/import > mechanisms don't handle this or is there some deeper reason behind > it? All definitions you refer to must be resolvable by the compiler (and reader). The definitions are made availble by import/include. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 02:18:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8E03A68FF; Fri, 29 Aug 2008 02:18:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C523A6911 for ; Fri, 29 Aug 2008 02:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PzKMqLZ0D6o for ; Fri, 29 Aug 2008 02:18:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A0E833A68FF for ; Fri, 29 Aug 2008 02:18:55 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D255220F49; Fri, 29 Aug 2008 11:18:57 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-4a-48b7bf01d2c9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 79DB120AC8; Fri, 29 Aug 2008 11:18:57 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:18:55 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:18:55 +0200 Message-ID: <48B7BEE5.2010404@ericsson.com> Date: Fri, 29 Aug 2008 11:18:29 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200808281706.m7SH6rk1014175@idle.juniper.net> <48B6DDCE.3080203@ericsson.com> <20080828.211345.255648453.mbj@tail-f.com> In-Reply-To: <20080828.211345.255648453.mbj@tail-f.com> X-OriginalArrivalTime: 29 Aug 2008 09:18:55.0891 (UTC) FILETIME=[42F75E30:01C909B8] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Balazs Lengyel wrote: >> >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> IMO, these are CLRs which reflect one vendors implementation >>>> of the config database. >>> I disagree. These are two rules that when combined make behavior >>> I don't find attractive. If a leaf is "created-by system" and has >>> a default, then the system is responsible for making it if the >>> client does not set it, but the server must must make it with a >>> fixed value. Instantiating a fixed default value has little >>> positive value and I'm happy to make a CLR that help data modelers >>> avoid this pitfall. >> Balazs: Some of our major systems already do this, so you are asking >> us to redesign the database behind the Netconf implementation. > > IMO, you will still be able to instantiate default values if you want > to. Nowhere do we say that an implementation MUST or MUST NOT store > default values. What we *do* say is that if your device supports the > new :with-defaults capability, it should be able to filter out leafs > w/ default values. If your device cannot do this, don't advertise > :with-defaults. > 1) Currently the with default draft allows you to filter data that was (explicitly) set to its default value as default data. It might not be best practice but it is existing practice in some systems, so it is is allowed. I don't want to loose that. 2) If a leaf is system-created but we known a priori the specific value that the system will use (unless the manager sets something else), we should be able to include this information in YANG, is there any reason to force hiding this information? This was the case I wanted to handle with default and systemCreated=true. Do you agree with the idea? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 02:19:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10A63A67A8; Fri, 29 Aug 2008 02:19:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496893A68FF for ; Fri, 29 Aug 2008 02:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3VUozgc065M for ; Fri, 29 Aug 2008 02:19:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7D0A53A67A8 for ; Fri, 29 Aug 2008 02:19:50 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 105B720EC8; Fri, 29 Aug 2008 11:19:53 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-f7-48b7bf38dc8d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F241F20EC2; Fri, 29 Aug 2008 11:19:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:19:52 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:19:52 +0200 Message-ID: <48B7BF1D.6080107@ericsson.com> Date: Fri, 29 Aug 2008 11:19:25 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48B6D57D.1080004@netconfcentral.com> <20080828.205950.152846111.mbj@tail-f.com> <48B6F89C.30102@netconfcentral.com> <20080828.211901.172574307.mbj@tail-f.com> In-Reply-To: <20080828.211901.172574307.mbj@tail-f.com> X-OriginalArrivalTime: 29 Aug 2008 09:19:52.0458 (UTC) FILETIME=[64AECEA0:01C909B8] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > > Hmm. Are you saying that if the default statement is present and > created-by system is present, then the default value is more like > DEFVAL from SMIv2? I.e. the server must create a value, and the > default valus is a hint. > I would argue it is not a HINT, it is a strict definition. The system MUST create the leaf using the value in the default statement. If you don't know or if you are just hinting, put that into the description. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 02:28:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C649A3A6922; Fri, 29 Aug 2008 02:28:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390613A6922 for ; Fri, 29 Aug 2008 02:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKIHUHKgtQ3O for ; Fri, 29 Aug 2008 02:28:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 684553A6911 for ; Fri, 29 Aug 2008 02:28:29 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id ED31076C4DC; Fri, 29 Aug 2008 11:28:30 +0200 (CEST) Date: Fri, 29 Aug 2008 11:28:30 +0200 (CEST) Message-Id: <20080829.112830.176925208.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B7BEE5.2010404@ericsson.com> References: <48B6DDCE.3080203@ericsson.com> <20080828.211345.255648453.mbj@tail-f.com> <48B7BEE5.2010404@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > > 1) Currently the with default draft allows you to filter data that > was (explicitly) set to its default value as default data. It might > not be best practice but it is existing practice in some systems, so > it is is allowed. > I don't want to loose that. Sure. > 2) If a leaf is system-created but we known a priori the specific > value that the system will use (unless the manager sets something > else), we should be able to include this information in YANG, is > there any reason to force hiding this information? This was the case > I wanted to handle with default and systemCreated=true. Do you agree > with the idea? If the value is static, why would you mark it as system-created true when 'default' does what you want? Assume you're in a WG, defining a data model for some technology. You know that there's a static value (42) that should be used for the leaf 'foo' if the client does not specify one. Currently, you would do: leaf foo { type { int32; } default 42; } With your proposal, you can also do: leaf foo { type { int32; } default 42; system-created true; } How will a DM designer know which one of these to use? With just a 'default', my implementation will not store this in the db, but your implementation will. With both system-created and default, you force all implementations to store the value. (*if* we were to do this, which I don't want to, I'd rather not reuse the statement 'default' for this, b/c default means something else. I'd rather do: system-created true { value 42; } or somthing) /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 02:33:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C583A67E2; Fri, 29 Aug 2008 02:33:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426123A68A2 for ; Fri, 29 Aug 2008 02:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuSVO6-gGVig for ; Fri, 29 Aug 2008 02:33:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2DA663A67E2 for ; Fri, 29 Aug 2008 02:33:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D034A20E60; Fri, 29 Aug 2008 11:33:05 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-b8-48b7c251e176 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B1A4C20C57; Fri, 29 Aug 2008 11:33:05 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:33:05 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 11:33:05 +0200 Message-ID: <48B7C236.7070109@ericsson.com> Date: Fri, 29 Aug 2008 11:32:38 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48B6F89C.30102@netconfcentral.com> <20080828.211901.172574307.mbj@tail-f.com> <48B6FE7F.3060708@netconfcentral.com> <20080828.214935.243711090.mbj@tail-f.com> <48B705EC.6060703@netconfcentral.com> In-Reply-To: <48B705EC.6060703@netconfcentral.com> X-OriginalArrivalTime: 29 Aug 2008 09:33:05.0206 (UTC) FILETIME=[3D328D60:01C909BA] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>>> Hmm. Are you saying that if the default statement is present and >>>> created-by system is present, then the default value is more like >>>> DEFVAL from SMIv2? I.e. the server must create a value, and the >>>> default valus is a hint. >>> no -- I am saying that created-by system is just >>> a redundant field if a default-stmt is present. >> >> Do you agree that if I have this: >> >> leaf foo { >> type int32; >> created-by system; >> } >> leaf bar { >> type int32; >> default 42; >> } >> >> and a server replies to a with with-defaults=false, then the >> auto-created value of 'foo' is present in the rpc-reply, but the default >> value of 'bar' is not present? > > no - I much prefer Phil's interpretation of with-defaults: > > true == I want everything regardless of how it got there > false == I want only the stuff explicitly set by operators > or the startup config > > I think the other interpretation is also valid, > but needs more clarification. > This will mean we already have at least 3 types of data: - real data set by the manager - data set by the agent, that is there in the datastore, but still should not be returned for with-defaults=false - data that is no there, it's value is used as a default This is getting too complicated for me. It would be a more simple solution to say: - system-created only means that the data will be created unless the manager sets it - once it is created it is handled just the same way as data set by the manager - if you don't want to see it in your config, don't mark it system-created, make it just default - for normal default allow an unspecified value, for the case where you don't know the value a priori or where the value is not just a simple literal This way you only have 2 types of data: real data, default data. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 02:39:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7E23A6976; Fri, 29 Aug 2008 02:39:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559633A6976 for ; Fri, 29 Aug 2008 02:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBH9fjkWf-2M for ; Fri, 29 Aug 2008 02:39:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7422C3A68A2 for ; Fri, 29 Aug 2008 02:39:10 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 0560876C4E7; Fri, 29 Aug 2008 11:39:13 +0200 (CEST) Date: Fri, 29 Aug 2008 11:39:10 +0200 (CEST) Message-Id: <20080829.113910.68681234.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B7C236.7070109@ericsson.com> References: <20080828.214935.243711090.mbj@tail-f.com> <48B705EC.6060703@netconfcentral.com> <48B7C236.7070109@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] created-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > This will mean we already have at least 3 types of data: > - real data set by the manager > - data set by the agent, that is there in the datastore, but still > should not be returned for with-defaults=false > - data that is no there, it's value is used as a default > > > This is getting too complicated for me. It would be a more simple > solution to say: > - system-created only means that the data will be created unless the > manager sets it > - once it is created it is handled just the same way as data set by the manager > - if you don't want to see it in your config, don't mark it > system-created, make it just default > - for normal default allow an unspecified value, for the case where > you don't know the value a priori or where the value is not just a > simple literal > > This way you only have 2 types of data: real data, default data. No you still have three type of data: - real data set by the manager - known defaults - unknown defaults (must be read with with-defaults=true) If you want to keep it simple, stick to: - real data set (by the manager or agent; always returned) - known defaults (not returned in with-defaults=false) /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 05:58:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FA83A69B5; Fri, 29 Aug 2008 05:58:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CAD3A69DA for ; Fri, 29 Aug 2008 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhrKB-ttbqsJ for ; Fri, 29 Aug 2008 05:58:27 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 03CF93A69B5 for ; Fri, 29 Aug 2008 05:58:26 -0700 (PDT) Received: (qmail 229 invoked from network); 29 Aug 2008 12:58:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.68.4 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 29 Aug 2008 12:58:25 -0000 X-YMail-OSG: j0U3I_MVM1kWOUjpVGupSsrB5askYUSG9QNcz2KChW_W8zbtvdPm4inkHtHeZDDTDrGJAJzLMCTITbYVmju62gC82pSq1L_9ns7MvnTtksE3wQw4A_jG_2KJ8k9reXE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B7F26D.7080805@netconfcentral.com> Date: Fri, 29 Aug 2008 05:58:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B49B7E.4080002@netconfcentral.com> <20080829.092817.260021532.mbj@tail-f.com> <48B7AF8F.3000201@netconfcentral.com> <20080829.103223.156479567.mbj@tail-f.com> In-Reply-To: <20080829.103223.156479567.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> Access control is not considered at all for unique tests. >>> [...] >>> >>>> Note that the 'must-stmt' is allowed in many more places than >>>> the 'unique-stmt', N entries per node, and there is no data >>>> at all returned in the 'data-restriction-violation' error in E.4. >>>> >>>> IMO, the error in E.1 should work the same way. >>>> No data. no security leak. >>> "bailing out near line 1" - Not very helpful, but secure. >>> What if we specify that any instance identifiers returned in the error >>> MUST be checked for read access control? >>> Otherwise, I think we have the same problem in general. When you do >>> in NETCONF, and the config is invalid, with the "no >>> data. no security leak." approach, the reply to should just >>> be "error". Is that what we want? >>> >> Explain to me again why all this data is needed for >> a unique-test failure, but none at all is needed >> for a must-test failure? Am I missing something? >> This data is not really needed at all. > > It's needed to help the operator understand why the config is not > valid, and what can be done to resolve it. > > For 'must' expressions, we can't do much more than letting the > error-path point to the node with the failing must and give an > error-app-tag. But I expect implementations to attach more data in > the error-info part of the rpc-reply, for some of these errors. [I > had a proposal for also defining this error-info content, but at that > time we said that it could wait.] > > I'd rather put in more data in the errors, in order to help the > operator, than removing data. Taking your logic to the extreme, why > do we specify error-app-tag and error-message at all? We can just say > "error", and let the operator do a , and run all > validation off-line to figure out why validation failed. > > >> The commit or edit-config has failed. >> All the access control tests have passed, >> which is supposedly done in order to allow the operation >> in the first place. Access control is not a factor, >> We already punted this one by saying "by some magic, >> all access for the commit is granted". By the same magic, >> the error messages are secured. > > Are you saying that even if we do send the instance identifiers in the > unqiue-error, it is not a security problem? > You don't need to send any data to have a security problem. If I have access to 1 list entry (that uses the unique-stmt), then I can simply use a trial-and-error brute force attack, and keep setting the leaf I want to uncover to different values. As soon as I get back a data-not-unique error, I know one of the entries has that value. Further attacks may or may not be possible from that point. Returning all the data for the non-unique entries makes the hackers job much much easier. (They told us not to do that in security school ;-) If I have access to the subtree (out of the entire element) then whether I use candidate or running as the target, the 'commit tests' are designed to check all the data, even the vast subset I am not authorized to touch. An agent needs to suppress error messages for unauthorized data, but I doubt any actually do that. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 06:07:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E9A3A67AA; Fri, 29 Aug 2008 06:07:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1B83A6819 for ; Fri, 29 Aug 2008 06:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5Jc7tEEUK5Q for ; Fri, 29 Aug 2008 06:07:00 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3D8AE3A67AA for ; Fri, 29 Aug 2008 06:07:00 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 755B4204DF; Fri, 29 Aug 2008 15:07:02 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-bf-48b7f476747d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5D8B920483; Fri, 29 Aug 2008 15:07:02 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 15:07:01 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 15:07:01 +0200 Message-ID: <48B7F45B.90700@ericsson.com> Date: Fri, 29 Aug 2008 15:06:35 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , NETMOD Working Group X-OriginalArrivalTime: 29 Aug 2008 13:07:01.0791 (UTC) FILETIME=[2065FAF0:01C909D8] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Comments on draft-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Martin, From draft-01: When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule. What is the difference between: "incorporates the contents of the submodule into the node hierarchy of the module" and "the target submodule's definitions are made available to the current submodule" If I put the root container into submodule1 and include that from submodule2 which of the two am I doing? ---------------------------------------------------------------------- 7.5.2 If the node with the must statement represents configuration data, any node referenced in the XPath expression MUST also represent configuration. What is the sense of putting a must on status data? I can understand a use case for mixed state and config, but what is the use case for pure state based must. On the other hand having a must on rpc parameters (a 3rd type of data beside config and state) seems also reasonable. ------------------------------------------------------------------- 7.8.3 I think putting "unique" on state data should be forbidden following the same logic as must. Actually min-max for state type lists/leaf-lists is also more an indication then a requirement/check. ------------------------------------------------------------------ 7.9.3 "There MUST NOT be any mandatory nodes (Section 3.1) under the default case." Doesn't that forbid the following? After all name is mandatory and is under the default case. Maybe add the word "directly". choice foo { case aaa { ... } default { list bar { key id; leaf id; leaf name { mandatory true; type string; } } } } ---------------------------------------------------------- 7.13.2 "If a "config" or "must" statement is present for any node in the input tree, it is ignored." Why did we disallow must? I see it perfectly reasonable to have restrictions between the parameters of the RPC. ------------------------------------------------------- 7.1`3.5 A reply example with data would be better ------------------------------------------------------ 7.15 Can you augment an the following rpc ? rpc shortCommand ; I found this only in the change log. ------------------------------------------------------- Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 06:26:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7A23A69A8; Fri, 29 Aug 2008 06:26:10 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81F73A69CC for ; Fri, 29 Aug 2008 06:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK4faqKbV-dt for ; Fri, 29 Aug 2008 06:26:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8D82E3A69A8 for ; Fri, 29 Aug 2008 06:26:08 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 3BAC776C4DC; Fri, 29 Aug 2008 15:26:11 +0200 (CEST) Date: Fri, 29 Aug 2008 15:26:07 +0200 (CEST) Message-Id: <20080829.152607.86474461.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B7F45B.90700@ericsson.com> References: <48B7F45B.90700@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello Martin, > > From draft-01: > > When a module includes a submodule, it incorporates the contents of > the submodule into the node hierarchy of the module. When a > submodule includes another submodule, the target submodule's > definitions are made available to the current submodule. > > What is the difference between: > "incorporates the contents of the submodule into the node hierarchy > of the module" and This is what happens when the module includes a submodule - all data definitions, rpcs, notifications, etc gets "copied" / "incorporated" into the module. > "the target submodule's definitions are made available to the > current submodule" This is what happens when a submodule includes a submodule. It just gives the submodule access to the definitions so that it can refer to them. On my TODO list is also adding the proposed clarification text from Andy on submodules, but it is pending the outcome of yang-00755 (prefix on belongs-to). > If I put the root container into submodule1 and include that from > submodule2 which of the two am I doing? the latter. > ---------------------------------------------------------------------- > > 7.5.2 > > If the node with the must statement represents configuration data, > any node referenced in the XPath expression MUST also represent > configuration. > > What is the sense of putting a must on status data? I can understand > a use case for mixed state and config, but what is the use case for > pure state based must. > > On the other hand having a must on rpc parameters (a 3rd type of > data beside config and state) seems also reasonable. There are a couple of statements that may or may not make sense in different places. must might not make sense in state data. mandatory is another example. We need to work through all these, hopefully at the interim. > ------------------------------------------------------------------- > > 7.8.3 > I think putting "unique" on state data should be forbidden following > the same logic as must. Actually min-max for state type > lists/leaf-lists is also more an indication then a > requirement/check. See above. > ------------------------------------------------------------------ > > 7.9.3 > "There MUST NOT be any mandatory nodes (Section 3.1) under the default case." > > Doesn't that forbid the following? No. See the reference (3.1) for a definition of the term "mandatory node". > ---------------------------------------------------------- > > 7.13.2 > > "If a "config" or "must" statement is present for any node in the > input tree, it is ignored." > > Why did we disallow must? I see it perfectly reasonable to have > restrictions between the parameters of the RPC. This is also one of the statements we have to decide if we want to allow or not. > ------------------------------------------------------- > > 7.1`3.5 > A reply example with data would be better There is one in 4.2.9, which I now realize is wrong. I'll fix it in -02. > ------------------------------------------------------ > > 7.15 > > Can you augment an the following rpc ? > > rpc shortCommand ; Yes, this is covered in the second paragraph of 7.13, and the normal rules for augment (i.e. you can augment any existing node, and the rpc statement creates the input and output nodes). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 06:56:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E66B3A67ED; Fri, 29 Aug 2008 06:56:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C1B3A6899 for ; Fri, 29 Aug 2008 06:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbalsshsxrZ8 for ; Fri, 29 Aug 2008 06:56:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 493CA3A67ED for ; Fri, 29 Aug 2008 06:56:56 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A98E020C88; Fri, 29 Aug 2008 15:56:58 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-e1-48b8002ad09d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8792520AF1; Fri, 29 Aug 2008 15:56:58 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 15:56:57 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 15:56:57 +0200 Message-ID: <48B8000F.8020604@ericsson.com> Date: Fri, 29 Aug 2008 15:56:31 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48B7F45B.90700@ericsson.com> <20080829.152607.86474461.mbj@tail-f.com> In-Reply-To: <20080829.152607.86474461.mbj@tail-f.com> X-OriginalArrivalTime: 29 Aug 2008 13:56:57.0599 (UTC) FILETIME=[1A0A00F0:01C909DF] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Balazs Lengyel wrote: >> Hello Martin, >> >> From draft-01: >> >> When a module includes a submodule, it incorporates the contents of >> the submodule into the node hierarchy of the module. When a >> submodule includes another submodule, the target submodule's >> definitions are made available to the current submodule. >> >> What is the difference between: >> "incorporates the contents of the submodule into the node hierarchy >> of the module" and > > This is what happens when the module includes a submodule - all data > definitions, rpcs, notifications, etc gets "copied" / "incorporated" > into the module. > >> "the target submodule's definitions are made available to the >> current submodule" > > This is what happens when a submodule includes a submodule. It just > gives the submodule access to the definitions so that it can refer to > them. Sorry but I still don't see the real difference. Maybe some examples could help. > >> ------------------------------------------------------------------ >> >> 7.9.3 >> "There MUST NOT be any mandatory nodes (Section 3.1) under the default case." >> >> Doesn't that forbid the following? > > No. See the reference (3.1) for a definition of the term "mandatory > node". > Doesn't that forbid the following? After all name is mandatory and is under the default case. Maybe add the word "directly". choice foo { case aaa { ... } default { list bar { key id; leaf id; leaf name { mandatory true; type string; } } } } name is mandatory as in 3.1: "A leaf or choice node with a "mandatory" statement with the value "true". name is under the default case. The text does NOT say it has to be directly under default. So I don't agree with you " >> ------------------------------------------------------ >> >> 7.15 >> >> Can you augment an the following rpc ? >> >> rpc shortCommand ; > > Yes, this is covered in the second paragraph of 7.13, and the normal > rules for augment (i.e. you can augment any existing node, and the rpc > statement creates the input and output nodes). > > "The "rpc" statement defines an rpc node in the schema tree. Under the rpc node, an input node with the name "input", and an output node with the name "output" are also defined. The nodes "input" and "output" are defined in the module's namespace." "The "input" statement, which is optional, " These don't really tell me that the input is there even if it is not included in the YAM. Please consider rewording later. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 29 07:11:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89D53A6819; Fri, 29 Aug 2008 07:11:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D3B3A69ED for ; Fri, 29 Aug 2008 07:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVdh4Z2bty8e for ; Fri, 29 Aug 2008 07:11:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8C7F53A6819 for ; Fri, 29 Aug 2008 07:11:27 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id DF5A7616006; Fri, 29 Aug 2008 16:11:30 +0200 (CEST) Date: Fri, 29 Aug 2008 16:11:27 +0200 (CEST) Message-Id: <20080829.161127.115122930.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B8000F.8020604@ericsson.com> References: <48B7F45B.90700@ericsson.com> <20080829.152607.86474461.mbj@tail-f.com> <48B8000F.8020604@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > >> 7.9.3 > >> "There MUST NOT be any mandatory nodes (Section 3.1) under the default case." > >> > >> Doesn't that forbid the following? > > > > > No. See the reference (3.1) for a definition of the term "mandatory > > node". > Doesn't that forbid the following? After all name is mandatory and > is under the default case. Maybe add the word "directly". I'll add the word "directly", unless someone else objects. > >> ------------------------------------------------------ > >> > >> 7.15 > >> > >> Can you augment an the following rpc ? > >> > >> rpc shortCommand ; > > Yes, this is covered in the second paragraph of 7.13, and the normal > > rules for augment (i.e. you can augment any existing node, and the rpc > > statement creates the input and output nodes). > > > "The "rpc" statement defines an rpc node in the schema tree. Under > the rpc node, an input node with the name "input", and an output node > with the name "output" are also defined. The nodes "input" and > "output" are defined in the module's namespace." > > "The "input" statement, which is optional, " > > These don't really tell me that the input is there even if it is not > included in the YAM. In this text: The "rpc" statement defines an rpc node in the schema tree. Under the rpc node, an input node with the name "input", and an output node with the name "output" are also defined. isn't it clear that there is an input node called "input"? Note that the "input" statement no longer defines the input node, it merely adds nodes under the existing input node. > Please consider rewording later. I'm open to suggestions to make the text better. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Aug 30 09:28:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E52A3A67B6; Sat, 30 Aug 2008 09:28:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C926F3A67B6 for ; Sat, 30 Aug 2008 09:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpBkNSLNaOn0 for ; Sat, 30 Aug 2008 09:28:31 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 25E083A6405 for ; Sat, 30 Aug 2008 09:28:30 -0700 (PDT) Received: (qmail 10394 invoked from network); 30 Aug 2008 16:28:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.139.215 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 30 Aug 2008 16:28:31 -0000 X-YMail-OSG: idABlnsVM1nSU4a9mgPtwSEgR.h0Bra1oEd2Occklq5SDNn43R8gxztu2UgD7s0xyke7FyqaW9H946nneNCMyHCVPAKBr.cG6b.ATzKoRA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B9752D.7040900@netconfcentral.com> Date: Sat, 30 Aug 2008 09:28:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] YANG header clause order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, After some implementation experience, I changed my mind about the header clause order. There isn't any reason to force any order for the 4 individual header statement types. I like the idea of keeping the various statement types together, instead of mixing them all together. Suggested ABNF change: OLD: module-stmt = optsep module-keyword sep identifier-arg-str optsep "{" stmtsep module-header-stmts linkage-stmts meta-stmts revision-stmts body-stmts "}" optsep submodule-stmt = optsep submodule-keyword sep identifier-arg-str optsep "{" stmtsep submodule-header-stmts linkage-stmts meta-stmts revision-stmts body-stmts "}" optsep NEW: module-stmt = optsep module-keyword sep identifier-arg-str optsep "{" stmtsep module-header-stmts cmn-header-stmts body-stmts "}" optsep submodule-stmt = optsep submodule-keyword sep identifier-arg-str optsep "{" stmtsep submodule-header-stmts cmn-header-stmts body-stmts "}" optsep cmn-header-stmts = ;; these stmts can appear in any order [linkage-stmts] [meta-stmts] [revision-stmts] Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod