From netmod-bounces@ietf.org Sun Nov 2 03:51: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 70DE93A67D0; Sun, 2 Nov 2008 03:51:51 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3EF63A67D9; Sun, 2 Nov 2008 03:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 JlmDk5UbHdGS; Sun, 2 Nov 2008 03:51:50 -0800 (PST) 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 4FAD13A67D0; Sun, 2 Nov 2008 03:51:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,529,1220241600"; d="scan'208";a="126989161" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Nov 2008 06:51:45 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Nov 2008 06:51:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 2 Nov 2008 12:51:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5381 on Experience of Implementing NETCONF over SOAP Thread-Index: Ack7p6+JbUB3ATGSSe6+4/X6OyTvZwBOacnA From: "Romascanu, Dan (Dan)" To: , Subject: [netmod] FW: RFC 5381 on Experience of Implementing NETCONF over SOAP X-BeenThere: netmod@ietf.org 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: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Saturday, November 01, 2008 12:25 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: RFC 5381 on Experience of Implementing NETCONF over SOAP A new Request for Comments is now available in online RFC libraries. RFC 5381 Title: Experience of Implementing NETCONF over SOAP Author: T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita Status: Informational Date: October 2008 Mailbox: tomoyuki.iijima@alaxala.com, atarashi@alaxala.net, h-kimura@alaxala.net, makoto.kitani@alaxala.com, hideki.okita.pf@hitachi.com Pages: 22 Characters: 47724 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-iijima-netconf-soap-implementation-10.txt URL: http://www.rfc-editor.org/rfc/rfc5381.txt This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 2 14:41: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 9D11A3A68E1; Sun, 2 Nov 2008 14:41:29 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB0E3A67FA for ; Sun, 2 Nov 2008 14:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.130, 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 ijqWP-ED2vzD for ; Sun, 2 Nov 2008 14:41:27 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5FCAE3A6AD9 for ; Sun, 2 Nov 2008 14:40:49 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4A8FE76C318; Sun, 2 Nov 2008 23:40:45 +0100 (CET) Date: Sun, 02 Nov 2008 23:40:44 +0100 (CET) Message-Id: <20081102.234044.19100440.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <490B3CE7.1050007@ericsson.com> References: <200810282054.QAA18022@adminfs.snmp.com> <20081028.222710.251029462.mbj@tail-f.com> <490B3CE7.1050007@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] Proposed consensus mail on yang-00000: module update 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 Balazs Lengyel wrote: > > > Martin Bjorklund wrote: > > A definition may be revised in any of the following ways: > > - New data definition statements may be added if they do not add > > mandatory nodes (^mandatory-nodes^) to existing nodes, or if they > > are conditionally dependent on a new feature (i.e. have a > > "if-feature" statement which refers to a new feature). > BALAZS: So a new mandatory leaf at the root level is allowed? I think it must > not. That is a clear incompatible change will brake old managers. No, it should not be allowed. I will fix this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 3 00:30: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 9DF8F28C13A; Mon, 3 Nov 2008 00:30:05 -0800 (PST) X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 238AA28C13A; Mon, 3 Nov 2008 00:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103083002.238AA28C13A@core3.amsl.com> Date: Mon, 3 Nov 2008 00:30:02 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-02.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-02.txt Pages : 161 Date : 2008-11-03 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03002840.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 Mon Nov 3 10:30: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 5748D28C218; Mon, 3 Nov 2008 10:30:07 -0800 (PST) X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A11103A6BF0; Mon, 3 Nov 2008 10:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103183001.A11103A6BF0@core3.amsl.com> Date: Mon, 3 Nov 2008 10:30:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D ACTION:draft-ietf-netmod-yang-types-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 : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-ietf-netmod-yang-types-01.txt Pages : 62 Date : 2008-11-3 This document introduces a collection of common data types to be used with the YANG data modeling language. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-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-types-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3102810.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 Tue Nov 4 00:04: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 296F43A68AE; Tue, 4 Nov 2008 00:04:56 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1FB3A68AE for ; Tue, 4 Nov 2008 00:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 UsXxXV2GVwyv for ; Tue, 4 Nov 2008 00:04:54 -0800 (PST) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id 9C1A43A68B4 for ; Tue, 4 Nov 2008 00:04:53 -0800 (PST) Received: from [192.168.99.223] (unknown [192.168.99.223]) by mail.edgeware.tv (Postfix) with ESMTPSA id E527251B6077 for ; Tue, 4 Nov 2008 09:04:49 +0100 (CET) Message-ID: <49100294.4030104@edgeware.tv> Date: Tue, 04 Nov 2008 09:06:44 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netmod@ietf.org Subject: [netmod] order of modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 haven't read every word of the yang I-D but at least so far I have not found anything stating the order of elements in the schema tree. In which order modules are loaded effect the final schema tree, so my question is; what order should they be loaded in? Take the following (stripped example): module services { prefix serv; container services { } } module ssh { prefix ssh; augment /serv:services { container ssh { ... } } } module ftp { prefix ftp; augment /serv:services { container ftp { ... } } } The following snippet will only validate correctly if the ssh module was loaded prior to the ftp module: The agent can of course load the modules in a predictable way, but how will clients know how to construct the final schema tree from list of schemas provided via ? _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 4 00:17: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 D80B13A6931; Tue, 4 Nov 2008 00:17:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931DC3A6931 for ; Tue, 4 Nov 2008 00:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.271, 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 reVU1jK3rf9l for ; Tue, 4 Nov 2008 00:17:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C250B3A68A0 for ; Tue, 4 Nov 2008 00:17:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AFB8D616001; Tue, 4 Nov 2008 09:17:21 +0100 (CET) Date: Tue, 04 Nov 2008 09:17:18 +0100 (CET) Message-Id: <20081104.091718.202696497.mbj@tail-f.com> To: johan.rydberg@edgeware.tv From: Martin Bjorklund In-Reply-To: <49100294.4030104@edgeware.tv> References: <49100294.4030104@edgeware.tv> 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] order of modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Johan Rydberg wrote: > I haven't read every word of the yang I-D but at least so far > I have not found anything stating the order of elements in the > schema tree. Section 7.15.2. specifies the XML Encoding Rules for "augment". It says: When a node is augmented, the augmented child nodes are encoded after all normal child nodes. If the node is augmented more than once, the blocks of augmented child nodes are sorted (in alphanumeric order) according to their namespace URI and name of the first child node in each block. So in your example, assuming that the URI for ftp is < the URI for ssh, the ftp node would be encoded before the ssh node. /martin > In which order modules are loaded effect the final schema tree, > so my question is; what order should they be loaded in? > > Take the following (stripped example): > > module services { > prefix serv; > container services { > } > } > > module ssh { > prefix ssh; > augment /serv:services { > container ssh { > ... > } > } > } > > module ftp { > prefix ftp; > augment /serv:services { > container ftp { > ... > } > } > } > > The following snippet will only validate correctly if the ssh > module was loaded prior to the ftp module: > > > > > > > The agent can of course load the modules in a predictable way, > but how will clients know how to construct the final schema tree > from list of schemas provided via ? > > _______________________________________________ > 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 Nov 4 00:28: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 43EED3A68D8; Tue, 4 Nov 2008 00:28:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55173A6962 for ; Tue, 4 Nov 2008 00:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 Xzv4kL0z1E4f for ; Tue, 4 Nov 2008 00:28:05 -0800 (PST) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id ECACC3A68D8 for ; Tue, 4 Nov 2008 00:28:04 -0800 (PST) Received: from [192.168.99.223] (unknown [192.168.99.223]) by mail.edgeware.tv (Postfix) with ESMTPSA id C464F51B6077; Tue, 4 Nov 2008 09:28:02 +0100 (CET) Message-ID: <49100805.7080500@edgeware.tv> Date: Tue, 04 Nov 2008 09:29:57 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <49100294.4030104@edgeware.tv> <20081104.091718.202696497.mbj@tail-f.com> In-Reply-To: <20081104.091718.202696497.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] order of modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 skrev: > Section 7.15.2. specifies the XML Encoding Rules for "augment". It > says: > > When a node is augmented, the augmented child nodes are encoded after > all normal child nodes. If the node is augmented more than once, the > blocks of augmented child nodes are sorted (in alphanumeric order) > according to their namespace URI and name of the first child node in > each block. > > So in your example, assuming that the URI for ftp is < the URI for > ssh, the ftp node would be encoded before the ssh node. Perfect! Thank you! BTW, is this currently supported by pyang? And related, any plans on updating pyang to support -02 (or -01)? ~jrydberg _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 4 00:57: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 527233A68B8; Tue, 4 Nov 2008 00:57:37 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4BA3A693A for ; Tue, 4 Nov 2008 00:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.237, 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 EEK6Pb+BkscF for ; Tue, 4 Nov 2008 00:57:35 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E78283A6912 for ; Tue, 4 Nov 2008 00:57:34 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8C2E9616001; Tue, 4 Nov 2008 09:57:32 +0100 (CET) Date: Tue, 04 Nov 2008 09:57:28 +0100 (CET) Message-Id: <20081104.095728.03633899.mbj@tail-f.com> To: johan.rydberg@edgeware.tv From: Martin Bjorklund In-Reply-To: <49100805.7080500@edgeware.tv> References: <49100294.4030104@edgeware.tv> <20081104.091718.202696497.mbj@tail-f.com> <49100805.7080500@edgeware.tv> 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] order of modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Johan Rydberg wrote: > Martin Bjorklund skrev: > > > Section 7.15.2. specifies the XML Encoding Rules for "augment". It > > says: > > When a node is augmented, the augmented child nodes are encoded after > > all normal child nodes. If the node is augmented more than once, the > > blocks of augmented child nodes are sorted (in alphanumeric order) > > according to their namespace URI and name of the first child node in > > each block. > > So in your example, assuming that the URI for ftp is < the URI for > > ssh, the ftp node would be encoded before the ssh node. > > Perfect! Thank you! BTW, is this currently supported by pyang? Hmm.. Not really... I will fix it. > And related, any plans on updating pyang to support -02 (or -01)? 0.9.2 support -01, and I'm currently working on remaining -02 support. I hope to release that this week or next. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 4 04:07: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 1AD843A6972; Tue, 4 Nov 2008 04:07:51 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462083A69AA for ; Tue, 4 Nov 2008 04:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.225, 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 TkyQZAx5-C76 for ; Tue, 4 Nov 2008 04:07:49 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 895393A6972 for ; Tue, 4 Nov 2008 04:07:48 -0800 (PST) Received: (qmail 63673 invoked from network); 4 Nov 2008 12:07:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 4 Nov 2008 12:07:34 -0000 X-YMail-OSG: .PTVBV4VM1kHgU_qhCh7vs3JzdVkchBNm.u4m6lFZcOk2Q7LpuaHIhNfW9YkpQHNL2BXJcWbrNTFrzIqBwVccyk38fX3PcfwkU5e6jwc7Tfnu5gOMFY7dvRzjnzVhhi5Ssg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49103B04.3050302@netconfcentral.com> Date: Tue, 04 Nov 2008 04:07:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Johan Rydberg References: <49100294.4030104@edgeware.tv> In-Reply-To: <49100294.4030104@edgeware.tv> Cc: netmod@ietf.org Subject: Re: [netmod] order of modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Johan Rydberg wrote: > I haven't read every word of the yang I-D but at least so far > I have not found anything stating the order of elements in the > schema tree. > > In which order modules are loaded effect the final schema tree, > so my question is; what order should they be loaded in? > > Take the following (stripped example): > > module services { > prefix serv; > container services { > } > } > > module ssh { > prefix ssh; > augment /serv:services { > container ssh { > ... > } > } > } > > module ftp { > prefix ftp; > augment /serv:services { > container ftp { > ... > } > } > } > > The following snippet will only validate correctly if the ssh > module was loaded prior to the ftp module: > Every module (or submodule) lists all of its imports and includes. No matter what module you start with, the imports and includes will identify the dependencies. > > > > > > The agent can of course load the modules in a predictable way, > but how will clients know how to construct the final schema tree > from list of schemas provided via ? > Why does the relative order of top-level sibling nodes matter? The agent should accept any element order. There does not need to be any forced order of modules within the element. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 06:35: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 1B7723A68B3; Wed, 5 Nov 2008 06:35:52 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28FD3A69BD for ; Wed, 5 Nov 2008 06:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=1.429, 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 v7dl19jzU5O9 for ; Wed, 5 Nov 2008 06:35:49 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8E46A3A68B3 for ; Wed, 5 Nov 2008 06:35:49 -0800 (PST) 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 mA5EZfLN027472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2008 15:35:41 +0100 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 mA5EZf9C016720; Wed, 5 Nov 2008 15:35:41 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 15:35:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 15:35:28 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Proposed consensus on yang-01281: conformance Thread-Index: Ack5o5uIQyi7okeeTEaTc5um6amnEwABZmjAAWp5ShA= References: <200810290951.42732.david.partain@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "David Partain" , X-OriginalArrivalTime: 05 Nov 2008 14:35:34.0204 (UTC) FILETIME=[C2EEDFC0:01C93F53] Subject: Re: [netmod] Proposed consensus on yang-01281: 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 Hi David, > > Questions posed regarding this issue: > > > > 1. Should there be a formal way of describing the deviations > > of a particular device? There was rough consensus that we > > should have a formal syntax for documenting deviations. > > I support this. IIRC I wasn't very positive on this in the interim meeting, but now I think this is useful and I support it. > > 2. Should this work be done in this working group? There > > was almost complete consensus that it should (David Harrington > > opposed.) > > I support doing it in this WG as part of NETMOD definition. Support. > > 3. Should the document say anything about how to organize > > these statements in a module? A long discussion about > > whether to intermingle these statements with other language > > constructs. > > David Partain recommended that we state that one SHOULD put > > the deviations in a separate module. Should we have a > > statement that says whether this should be in a separate > > module or not? > > Juergen: this is organizational; we shouldn't go there. Editor: > > There is no documented consensus on this question. > > Having missed the 'long discussion' I am not sure I understand all the > details and arguments, but putting deviations in a separate > module makes > more sense to me. We agree that having deviations in a separate module would be a good practice. > > > > 4. Are we reasonably happy with the syntax (with caveat that > > there is tweaking and clarification to be done)? There was > > rough consensus that we start with the syntax as it currently is. > > Good starting point. We can start with the syntax as it is currently. Cheers, Mehmet > Dan > _______________________________________________ > 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 Nov 5 06:56: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 2D7933A6900; Wed, 5 Nov 2008 06:56:56 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37E13A69F5 for ; Wed, 5 Nov 2008 06:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, 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 LlGxmmRk6znQ for ; Wed, 5 Nov 2008 06:56:54 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id ACC973A6900 for ; Wed, 5 Nov 2008 06:56:53 -0800 (PST) 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 mA5EulEl009584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2008 15:56:47 +0100 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 mA5EuaxZ019933; Wed, 5 Nov 2008 15:56:46 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 15:56:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 15:48:40 +0100 Message-ID: In-Reply-To: <200810171506.11481.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Consensus call on yang-00088: new "refine" statement Thread-Index: AckwWaTrdYimsz3RTz+nE8lrYM0HtAO+rSiA References: <200810171506.11481.david.partain@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David Partain" , X-OriginalArrivalTime: 05 Nov 2008 14:56:38.0407 (UTC) FILETIME=[B474F170:01C93F56] Subject: Re: [netmod] Consensus call on yang-00088: new "refine" 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 I support all of the changes based on the condition that the top-level 'augment' should be kept. Martin B. wrote: > I pefer to keep the top-level statement called 'augment', since this > usage is most similiar to how the term is used in SMIv2. > > I suggest 'extend' for the other statement. When a grouping is used, > it can be refined and extended. I agree with Martin that the top-level statement should be called 'augment', since this is the most natural way to call it and it matches the use in SMIv2. I agree also to use 'extend' for the other statement. Cheers, Mehmet > Subject: [netmod] Consensus call on yang-00088: new "refine" statement > > 1. Should we add a refine statement (assuming we have 'augment' > inside uses) in "uses"? > > Rough Consensus from the interim: make this change > > 2. Should we have an 'augment' statement inside the 'uses' > (while keeping the top-level 'augment')? > > (very) Rough Consensus from the interim: make this change > > 3. Should we put a "when" as a substatement of a leaf? > > Rough Consensus from the interim: yes, assuming #2 is yes. > > 4. Should we have two 'augment' keywords? > > Rough Consensus from the interim: yes, assuming #2 is yes. > > More details below... > > The current way YANG does things is to use an overlay and a > conditional change. For example: > > container x > augment . { > when "..." ; > leaf a { foo } ; > } > > ------------------------------------------------------------------ > First subissue: 1. Should we add a refine statement (assuming > we have 'augment' inside uses) in 'uses'. > > That would look like this: > > uses foo { > refine "b/c" { > default 42; > ... > } > } > > First consensus call is to determine whether we're going to add > the refine statement and change the "overlay" way of doing things > that we do today (see above). The sense of the room at the > interim was that we have rough consensus to do so. > > However, adding separate keywords for refining each kind of node > (refine-leaf, refine-container, etc.) generated no support, so > that is off the table. > > ------------------------------------------------------------------ > Second subissue: 2. Should we have an 'augment' statement inside > the 'uses' (while keeping the top-level 'augment')? > > That would mean, for example: > > uses foo { > augment "b/c" { > ... > } > } > > This is 'just a syntactic change'. You cannot do more than you > could before. Advantage is that you know which node the 'uses' > come from. > > This does not disallow the top-level augment; it adds the augment > to 'uses'. 'augment' was originally written to add nodes to a > different namespace. At the top-level, 'augment' adds nodes to > someone else's namespace, whereas this 'augment' adds to the > current namespace. > > It also means we no longer have definitions spread out in > seemingly unrelated places. Moving the augments inside uses > forces you to collect related statements (the augment and the > uses). Forces model writers to collect related information > rather than spreading it around. > > The interim had very rough consensus to make this change. The > primary argument for was the clear association of the 'augment' > with the definition of the 'nodes' being augmented (clarity). > Some of the arguments against were that what we have works fine > and a worry of lost flexibility (unclear what flexibility, > though). > > ------------------------------------------------------------------ > Third subissue: 3. Should we put a "when" as a substatement of a leaf > > If we move augment to the uses statement (see previous subissue), > we need to have "when" 'everywhere' (leaf, leaf-list, container, > grouping, case, choice, notification, input, output). > > Rough concensus from the interim was that if #2 is introduced, > this should be as well. > > ------------------------------------------------------------------ > Fourth subissue: 4. Should we have two 'augment' keywords? > > Should we have two keywords (for top-level 'augment' and for > 'augment' inside uses)? For example, the 'augments' under uses > could be called "extend". > > Rough consensus in the meeting to have two different names. What > the second name should be has not been decided. > > Suggestions welcome! > _______________________________________________ > 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 Nov 5 09:08: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 A58773A6858; Wed, 5 Nov 2008 09:08:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A093A685A for ; Wed, 5 Nov 2008 09:08:25 -0800 (PST) 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 LeC+57P4vXXg for ; Wed, 5 Nov 2008 09:08:25 -0800 (PST) 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 27BF33A6864 for ; Wed, 5 Nov 2008 09:08:24 -0800 (PST) Received: (qmail 29340 invoked from network); 5 Nov 2008 17:08:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 5 Nov 2008 17:08:18 -0000 X-YMail-OSG: oG8uOfIVM1lYHCBEovpUNHClSDsff_9s3KjR5amKR.GWNE.7KHrTuteRoBLQNqQA79GI869aAFCmIriHVKEm6gZCzcYmWZejqMICUzcRD.MRPfdVa6V1f_AZxm_JcPJaqsA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4911D300.7000602@netconfcentral.com> Date: Wed, 05 Nov 2008 09:08:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] current() ABNF X-BeenThere: netmod@ietf.org 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 'current-function-invocation' is specified as 'current()'. Section 3.7 of XPath 1.0 states that an ExprWhitespace may be freely added before and after any ExprToken. Is this ABNF an oversight or intentional? Aren't 'current( )' and 'current ( )' also valid? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 09: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 F3D2B3A67D8; Wed, 5 Nov 2008 09:51:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C463A67D8 for ; Wed, 5 Nov 2008 09:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=1.111, 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 8XZiJjGBKmdw for ; Wed, 5 Nov 2008 09:51:26 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E24393A6825 for ; Wed, 5 Nov 2008 09:51:25 -0800 (PST) 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 mA5HpHCX000806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2008 18:51:17 +0100 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 mA5HpG7Q031549; Wed, 5 Nov 2008 18:51:17 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 18:51:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 18:51:03 +0100 Message-ID: In-Reply-To: <200810281612.37126.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Proposed consensus mail on yang-00413: import by revision Thread-Index: Ack5D9PUwU2r1H9zRVC5yx55irqEWwGRmVbQ References: <200810281612.37126.david.partain@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David Partain" , X-OriginalArrivalTime: 05 Nov 2008 17:51:07.0098 (UTC) FILETIME=[14486BA0:01C93F6F] Subject: Re: [netmod] Proposed consensus mail on yang-00413: 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 I support import-by-revision. I am in favor having it as mandatory but would not object if it is proposed to be optional. Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext David Partain > Sent: Tuesday, October 28, 2008 4:13 PM > To: netmod@ietf.org > Subject: [netmod] Proposed consensus mail on yang-00413: > import by revision > > Greetings, > > This is a call for consensus about issue > 'yang-00413: import by revision'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00413 > for an introduction. > > This mail documents the conversations at the interim for proposed > changes / clarifications in text in the YANG document. As such, > the question is whether you agree with the interpretation that > this text intends to document. There are no new features being > proposed. > > PLEASE speak up if you favor this consensus (including people who > attended the interim). > > Issue: Should YANG modules import specific revisions of other > modules? > > See also the discussion about update rules, which is relevant for > this issue as well. > > The interim meeting discussed whether to use import-by-revision > or whether to require changing names when changing the > groupings/typedefs in a module. > > After much discussion, we reached rough consensus to proceed with > import by revision. However, it was quite clear that further > clarification was necessary (everyone thought so). > > There was also consensus that import by revision will be > mandatory, but with exceptions. The exceptions would be for > modules that "guarantee" that they follow the rules (e.g., IANA > modules) and will not change things in non-backwardly-compatible > ways. > > David(s) > _______________________________________________ > 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 Nov 5 09:52: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 160933A67D8; Wed, 5 Nov 2008 09:52:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D473A67D8 for ; Wed, 5 Nov 2008 09:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.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 F-tMkUDx0CUI for ; Wed, 5 Nov 2008 09:52:01 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id BB7B73A69E4 for ; Wed, 5 Nov 2008 09:52:00 -0800 (PST) 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 mA5Hptjx001642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2008 18:51:55 +0100 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 mA5Hpsvt023788; Wed, 5 Nov 2008 18:51:54 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 18:51:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 18:51:29 +0100 Message-ID: In-Reply-To: <200810281613.54550.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Proposed consensus mail on yang-00755: adding a 'prefix'substatement to 'belongs-to' Thread-Index: Ack5EGdRheCnALouSnusXtfRECFLEAGRpFjg References: <200810281613.54550.david.partain@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David Partain" , X-OriginalArrivalTime: 05 Nov 2008 17:51:30.0535 (UTC) FILETIME=[22409F70:01C93F6F] Subject: Re: [netmod] Proposed consensus mail on yang-00755: adding a 'prefix'substatement to '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 Although we don't see it as very useful we don't have a problem with adding a prefix substatement to belongs-to. Cheers, Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext David Partain > Sent: Tuesday, October 28, 2008 4:14 PM > To: netmod@ietf.org > Subject: [netmod] Proposed consensus mail on yang-00755: > adding a 'prefix'substatement to 'belongs-to' > > Greetings, > > This is a call for consensus about issue 'yang-00755: adding a > 'prefix' substatement to 'belongs-to'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00755 > > PLEASE speak up if you favor or object to the proposed change, > including people who attended the interim. Silence is impossible > to interpret. > > Proposal to add a 'prefix' substatement to 'belongs-to' in order > to allow a submodule to be validated in isolation from its main > module. > > David Harrington asked what the downsides are, and none were > identified. > > David Reid asked a clarifying question about whether the purpose > is for the submodule to be self-contained? (Yes, that's the > purpose.) > > Everyone in the room at the interim agreed that this should be > added. > _______________________________________________ > 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 Nov 5 09:52: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 2C6FA3A67D8; Wed, 5 Nov 2008 09:52:36 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F27E3A6825 for ; Wed, 5 Nov 2008 09:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=0.909, 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 AWMrikUho1ul for ; Wed, 5 Nov 2008 09:52:34 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4A0EB3A67D8 for ; Wed, 5 Nov 2008 09:52:34 -0800 (PST) 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 mA5HqTs8002393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2008 18:52:30 +0100 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 mA5HqSpw032355; Wed, 5 Nov 2008 18:52:29 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 18:52:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 18:52:21 +0100 Message-ID: In-Reply-To: <49085CEB.7080701@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Proposed consensus mail on yang-00776: "Augmentable Groupings" Thread-Index: Ack5xblukJ4iPWZ3QrOaKmEwr/V24QFkiljA References: <200810290946.06001.david.partain@ericsson.com> <49085CEB.7080701@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" , "David Partain" X-OriginalArrivalTime: 05 Nov 2008 17:52:22.0488 (UTC) FILETIME=[41380580:01C93F6F] Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00776: "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 I share the same opinion but I agree not to include this change at this time. Cheers, Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Balazs Lengyel > Sent: Wednesday, October 29, 2008 1:54 PM > To: David Partain > Cc: netmod@ietf.org > Subject: Re: [netmod] Proposed consensus mail on yang-00776: > "Augmentable Groupings" > > I am sad but I agree with the consensus. > Balazs > > David Partain wrote: > > Greetings, > > > > This is a call for consensus about issue > > 'yang-00776: "Augmentable Groupings"'. See the wiki at > > > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00776 > > > > After a very brief discussion, the rough consensus of the interim > > meeting was NOT to include this change at this time. > > > > PLEASE speak up if you favor or object to this decision > > (including people who attended the interim). Silence is > > impossible to interpret. > > > > Cheers, > > > > David(s) > > _______________________________________________ > > 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 10:02: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 C73483A67A5; Wed, 5 Nov 2008 10:02:52 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071613A68C1 for ; Wed, 5 Nov 2008 10:02:51 -0800 (PST) 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 J-JSSgo7OCKx for ; Wed, 5 Nov 2008 10:02:50 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 3795D3A67A5 for ; Wed, 5 Nov 2008 10:02:50 -0800 (PST) Received: (qmail 98653 invoked from network); 5 Nov 2008 18:01:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 5 Nov 2008 18:01:14 -0000 X-YMail-OSG: Xa5_xsYVM1m8qqNeYzMYszcMs7jqOXPj7F7jA_ywPvUNHxZ0ifaCWSdGM29LZVEuN5v3UDHXC1J9gBbPUApCHapd5N1aQY0oogdsN06MxCg5vgdT0DbA6e6UwKvd8DNPcT0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4911DF68.4040706@netconfcentral.com> Date: Wed, 05 Nov 2008 10:01:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group References: <4911D300.7000602@netconfcentral.com> In-Reply-To: <4911D300.7000602@netconfcentral.com> Subject: Re: [netmod] current() ABNF X-BeenThere: netmod@ietf.org 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 'current-function-invocation' is specified as 'current()'. > Section 3.7 of XPath 1.0 states that an ExprWhitespace may > be freely added before and after any ExprToken. > > Is this ABNF an oversight or intentional? > Aren't 'current( )' and 'current ( )' also valid? > The path-stmt ABNF also contradicts the normative XPath 1.0 grammar because it does not allow whitespace between operators (see rule [28]). > > Andy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 11:55: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 D351C3A63D2; Wed, 5 Nov 2008 11:55:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D0F3A6820 for ; Wed, 5 Nov 2008 11:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.116, 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 aLDIDUXJYP+K for ; Wed, 5 Nov 2008 11:55:22 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 06F313A63D2 for ; Wed, 5 Nov 2008 11:55:21 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DEE0176C4FF; Wed, 5 Nov 2008 20:54:02 +0100 (CET) Date: Wed, 05 Nov 2008 20:53:59 +0100 (CET) Message-Id: <20081105.205359.20000211.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4911DF68.4040706@netconfcentral.com> References: <4911D300.7000602@netconfcentral.com> <4911DF68.4040706@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] current() ABNF X-BeenThere: netmod@ietf.org 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: > > Hi, > > The 'current-function-invocation' is specified as 'current()'. > > Section 3.7 of XPath 1.0 states that an ExprWhitespace may > > be freely added before and after any ExprToken. > > Is this ABNF an oversight or intentional? > > Aren't 'current( )' and 'current ( )' also valid? It's an oversight - I just happily replaced "$this" with "current()". > The path-stmt ABNF also contradicts the normative XPath 1.0 > grammar because it does not allow whitespace between > operators (see rule [28]). Section 3.7 of the XPath spec says: For readability, whitespace may be used in expressions even though not explicitly allowed by the grammar: ExprWhitespace may be freely added within patterns before or after any ExprToken. Which means that if we want to be as flexible, we need to add *WSP on a few more places, e.g. to allow pretty expressions like: ".. / .. / name" /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 13: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 00F573A6452; Wed, 5 Nov 2008 13:20:05 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD0D3A6995 for ; Wed, 5 Nov 2008 13:20:03 -0800 (PST) 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.183, 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 8eBheaLFudGp for ; Wed, 5 Nov 2008 13:20:03 -0800 (PST) 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 0DF353A6452 for ; Wed, 5 Nov 2008 13:20:02 -0800 (PST) Received: (qmail 63553 invoked from network); 5 Nov 2008 21:19:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 5 Nov 2008 21:19:26 -0000 X-YMail-OSG: jmj_3AkVM1koLgoyn4WqYKjhFYeezyGkRGMyNH6mWr8GBIPAEsU72y58o4kEAV5Mc.3zL7P1vq9lWvBwqVlkyc3qLNLToU.Qv.0nv7ShyxDJwwryS3miuW_061UI1scL9cCP.9IpmJ6mQvyq3GQjbWIA X-Yahoo-Newman-Property: ymail-3 Message-ID: <49120DDC.80805@netconfcentral.com> Date: Wed, 05 Nov 2008 13:19:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <4911D300.7000602@netconfcentral.com> <4911DF68.4040706@netconfcentral.com> <20081105.205359.20000211.mbj@tail-f.com> In-Reply-To: <20081105.205359.20000211.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] current() ABNF X-BeenThere: netmod@ietf.org 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: >> Andy Bierman wrote: >>> Hi, >>> The 'current-function-invocation' is specified as 'current()'. >>> Section 3.7 of XPath 1.0 states that an ExprWhitespace may >>> be freely added before and after any ExprToken. >>> Is this ABNF an oversight or intentional? >>> Aren't 'current( )' and 'current ( )' also valid? > > It's an oversight - I just happily replaced "$this" with "current()". > >> The path-stmt ABNF also contradicts the normative XPath 1.0 >> grammar because it does not allow whitespace between >> operators (see rule [28]). > > Section 3.7 of the XPath spec says: > > For readability, whitespace may be used in expressions even though > not explicitly allowed by the grammar: ExprWhitespace may be freely > added within patterns before or after any ExprToken. > > Which means that if we want to be as flexible, we need to add *WSP on > a few more places, e.g. to allow pretty expressions like: > > ".. / .. / name" > > Deviating from XPath 1.0 is a delicate subject. I suggest doing it only if there's a really good reason. Parsers need to follow the 'longest token match' rule anyway, e.g: foo-bar == an identifier 'foo-bar' foo -bar == string 'foo' minus string 'bar' foo - bar == string 'foo' minus string 'bar' foo- bar == 2 identifiers 'foo-' and 'bar' Whitespace is significant, but the grammar is clear where is can go. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 13:35: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 71CD23A67AC; Wed, 5 Nov 2008 13:35:33 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFB23A6784 for ; Wed, 5 Nov 2008 13:35:31 -0800 (PST) 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 L-rrWsxFdraG for ; Wed, 5 Nov 2008 13:35:31 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id EC6603A67A4 for ; Wed, 5 Nov 2008 13:35:28 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Wed, 05 Nov 2008 13:35:29 PST Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 13:34:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 13:34:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 13:34:36 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mA5LYZM50965; Wed, 5 Nov 2008 13:34:35 -0800 (PST) (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 mA5LTlSp023992; Wed, 5 Nov 2008 21:29:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811052129.mA5LTlSp023992@idle.juniper.net> To: Andy Bierman In-reply-to: <49120DDC.80805@netconfcentral.com> Date: Wed, 05 Nov 2008 16:29:47 -0500 From: Phil Shafer X-OriginalArrivalTime: 05 Nov 2008 21:34:36.0131 (UTC) FILETIME=[4CB07B30:01C93F8E] Cc: netmod@ietf.org Subject: Re: [netmod] current() ABNF X-BeenThere: netmod@ietf.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: >> Section 3.7 of the XPath spec says: >> For readability, whitespace may be used in expressions even though >> not explicitly allowed by the grammar: ExprWhitespace may be freely >> added within patterns before or after any ExprToken. >Deviating from XPath 1.0 is a delicate subject. >I suggest doing it only if there's a really good reason. Why not use the exact working from the xpath spec? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 17:57: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 557043A67ED; Wed, 5 Nov 2008 17:57:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014AA3A687C for ; Wed, 5 Nov 2008 17:57:26 -0800 (PST) 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 Puw8axGyIs7z for ; Wed, 5 Nov 2008 17:57:25 -0800 (PST) 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 5A8153A6806 for ; Wed, 5 Nov 2008 17:57:25 -0800 (PST) Received: (qmail 10739 invoked from network); 6 Nov 2008 01:57:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 6 Nov 2008 01:57:19 -0000 X-YMail-OSG: vXxU5yEVM1lpTt61tmFJDDPvxLq2FljQvU2LUnODuHt4LcpkYyQepu7Rnqa9oW2YLuMMcl3qiuEcm2QdCpmIL0eKBKRDVNHCUqiHQ73LSKW22iYDd2g_.a6VoN5CO14hv94- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49124EFE.2030901@netconfcentral.com> Date: Wed, 05 Nov 2008 17:57:18 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netmod@ietf.org References: <200811052129.mA5LTlSp023992@idle.juniper.net> In-Reply-To: <200811052129.mA5LTlSp023992@idle.juniper.net> Subject: [netmod] keyref example X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 previously thought a keyref could have references to the data model in it, but I was wrong. The examples and ABNF say otherwise. This is not allowed: leaf my-addr { type keyref { path "../../interface[name='eth0']/address/ip"; } } The example on pg 118 uses only objects and the ABNF syntax: container default-address { leaf ifname { type keyref { path "../../interface/name"; } } leaf address { type keyref { path "../../interface[name = current()/../ifname]" + "/address/ip"; } } } Note that: * the 'ifname' sibling of 'address' is needed to store the outer key 'name', as the address keyref is for the inner key 'ip'. * the following is invalid because the specific interface entry is not specified (there are N instances of 'name', not 1) leaf address { type keyref { path "../../interface[name = current()/../../interface/name]" + "/address/ip"; } } * the evaluation of 'address' is dependent on the value of 'ifname' at the time. * evaluation of address against the target config value of 'ifname' will be incorrect if the PDU value of 'ifname' is present and has a different value. This evaluation order is not obvious, but no different requirement than (e.g.) deleting the particular '/interface/address' subtree in the same PDU Questions: * Why is the 'constant-based predicate' (e.g. [name='eth0']) illegal? Are we sure there are never going to be use cases? * When is the current() function call actually needed? * It is needed in the predicate since the context node is 'interface' not 'address' (result of current() fn), but is it needed anywhere else? Perhaps a clarification in the draft would help. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 5 23:50: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 3869F3A682C; Wed, 5 Nov 2008 23:50:17 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523CE3A6956 for ; Wed, 5 Nov 2008 23:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 u6qSpbeT8yaf for ; Wed, 5 Nov 2008 23:50:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4D9693A682C for ; Wed, 5 Nov 2008 23:50:13 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AABA2C0155 for ; Thu, 6 Nov 2008 08:50:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Im96ZBG2oP+n; Thu, 6 Nov 2008 08:50:05 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95F7BC0B85; Thu, 6 Nov 2008 08:50:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0CE50852CD4; Thu, 6 Nov 2008 08:50:04 +0100 (CET) Date: Thu, 6 Nov 2008 08:50:03 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081106075003.GA29337@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] nested typedefs and 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 Hi, YANG supports nested typedefs and groupings (section 5.8) and one of the motivations given is that scoped definitions prevent naming conflicts between types in different submodules. The text also states that scoped definitions MUST NOT shadow definitions at a higher scope which I find somewhat contraditionary in the light of the first statement since this rule requires at the end again to generate names with low probability of conflict and given the name resolution procedure I fail to see that something actually breaks if I have a name clash. In other words, I would expect a parser to generate a warning if there is a name clash but not a hard error. /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 Nov 6 03:52: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 7D9A33A693C; Thu, 6 Nov 2008 03:52:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5B73A6989 for ; Thu, 6 Nov 2008 03:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 jvWGX7aFD2tV for ; Thu, 6 Nov 2008 03:52:26 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7A2A63A693C for ; Thu, 6 Nov 2008 03:52:26 -0800 (PST) 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 mA6Bq3UQ006693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 12:52:03 +0100 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 mA6Bq3WB009753; Thu, 6 Nov 2008 12:52:03 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 12:51:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 12:51:44 +0100 Message-ID: In-Reply-To: <490771DA.9060903@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Proposed consensus mail on yang-00172 Thread-Index: Ack5OavA++LHhqqGTJ+INxuFLjbrDAGxtY+Q References: <200810271100.38001.david.partain@ericsson.com> <490771DA.9060903@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "David Partain" , X-OriginalArrivalTime: 06 Nov 2008 11:51:49.0820 (UTC) FILETIME=[0D8E97C0:01C94006] Subject: Re: [netmod] Proposed consensus mail on yang-00172 X-BeenThere: netmod@ietf.org 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 Overall, the table looks good. I guess in case of RPC input ordered-by would force the manager to deliver the list elements in the requested order. Is this correct? If not, please clarify. Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Balazs Lengyel > Sent: Tuesday, October 28, 2008 9:11 PM > To: David Partain > Cc: netmod@ietf.org > Subject: Re: [netmod] Proposed consensus mail on yang-00172 > > Generally I support this with some comments: > > General statement: > Restrictions on data going to the agent must be honored, > otherwise an error is returned. > Restrictions on data coming from the agent, are promises by > the agent. If they are broken, > tough luck, but they shouldn't. > > Enforced at commit implies: not enforced during the editing > of a candidate configuration > > I am still unclear what ordered-by means on RPC input. > > Balazs > > David Partain wrote: > > Greetings, > > > > Hope the table below works. You may have to use a fixed-width font. > > > > This is a call for consensus about issue 'yang-00172: > > clarifications for ordered-by, must, unique, keyref, when, > > mandatory, minmax, etc'. See the wiki at > > > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00172 > > for an introduction. > > > > This mail documents the conversations at the interim for proposed > > changes / clarifications in text in the YANG document. As such, > > the question is whether you agree with the interpretation that > > this text intends to document. There are no new features being > > proposed. > > > > PLEASE speak up if you favor the changes or object to the text > > (including people who attended the interim). > > > > Question that started the discussion: What does 'ordered-by > > user;' mean for read-only data or RPC input or notification > > content? > > > > This question is broader and the table below says when the > > various statements are relevant or not. > > > > config config RPC RPC Notifi- Enforced > > true false input output cation at commit > > ---------------------------------------------------------------- > > ordered-by | OK | i | OK | i | i | N > > unique | OK | OK | OK | OK | OK | Y > > must(1) | OK | OK | OK | OK | OK | Y > > keyref | OK | OK | OK(2)| OK(2)| OK(2)| Y > > when(1) | OK | OK | OK | OK | OK | N > > mandatory | OK | OK | OK | OK | OK | Y > > max/max-elems | OK | OK | OK | OK | OK | Y > > > > All of these are constraints, and the question is when that > > constraint is enforced. > > > > Key: > > > > i - ignored > > > > (1) must, when - the XPath context varies, and we'll have to > > document all of this for all of the different columns. > > > > (2) restrictions: the target of the XPath expression refers to > > the running config or to status data. > > > > The interim meeting spent some time talking about the differences > > between when and must. Phil Shafer's definitions: > > > > 'when' - The parent schema node is ignored unless the 'when' > > expression is satisfied. If the expression becomes false, any > > data associated with the node is automatically deleted. > > > > (Editor: deleted from what? from the response? from the > config database? Not > > entirely sure. Phil?) > > > > 'must' - If the parent node exists in the database, the 'must' > > expression must be true. If the expression is false, an error > > condition exists. Enforced at commit time. > > > > Do you agree with the definitions above? > > > > There was a long discussion about when a 'when' expression is > > evaluated. The rough consensus of the room was that 'when' > > constraints should be enforced in the candidate configuration, > > whereas 'must' is enforced first when committing in the running > > configuration. > > > > Phil Shafer will write some text about a hierarchy of constraints > > where mandatory can be applied underneath a 'when'. Conditions > > on parents affect or negate constraints on children. > > _______________________________________________ > > 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 6 04:14: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 BAED53A67D1; Thu, 6 Nov 2008 04:14:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8DC3A699F for ; Thu, 6 Nov 2008 04:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.211, 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 FdF+1X0e8fwY for ; Thu, 6 Nov 2008 04:14:01 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5DD4E3A67D1 for ; Thu, 6 Nov 2008 04:14:01 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D85E876C318; Thu, 6 Nov 2008 13:13:26 +0100 (CET) Date: Thu, 06 Nov 2008 13:13:26 +0100 (CET) Message-Id: <20081106.131326.203230969.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: <200810271100.38001.david.partain@ericsson.com> <490771DA.9060903@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] Proposed consensus mail on yang-00172 X-BeenThere: netmod@ietf.org 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 "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > Overall, the table looks good. > > I guess in case of RPC input ordered-by would force > the manager to deliver the list elements in the requested > order. Is this correct? If not, please clarify. If a RPC input parmeter list is ordered-by user, it means that the order used by the manager has some semantic meaning. For example: rpc ping-once-until-found { input { leaf-list host { ordered-by user; type inet:ip-address; } } output { leaf found-host { type inet:ip-address; } } } The client might send: 10.0.0.1 10.0.0.3 10.0.0.2 And the server will try to ping the hosts - in the order specified by the client. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 6 08:01: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 B083E3A67D4; Thu, 6 Nov 2008 08:01:51 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353A83A6999 for ; Thu, 6 Nov 2008 08:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.83 X-Spam-Level: X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=-1.231, 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 zkUdedBQhCLC for ; Thu, 6 Nov 2008 08:01:50 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id A38203A67D4 for ; Thu, 6 Nov 2008 08:01:49 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA6Fgrwm010636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 16:42:53 +0100 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 mA6Fgq9a005497; Thu, 6 Nov 2008 16:42:52 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 16:42:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 16:42:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Proposed consensus mail on yang-00000: module update rules Thread-Index: Ack5DoNjui2be15nRJaUmU3/84XCpQGYHbHwAC21+2A= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "David Partain" , X-OriginalArrivalTime: 06 Nov 2008 15:42:39.0427 (UTC) FILETIME=[4C90E930:01C94026] Subject: [netmod] FW: Proposed consensus mail on yang-00000: module update 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org = I support the proposal from the interim meeting which has been = updated with a text paragraph by Martin. = I think it is useful that the revision of the module must be advertised = as well, as stated in the YANG-02 document. This allows a manager = to find out what exactly is supported by a particular agent. I am in favor of the text Martin wrote on change rules. In general, = it is a good idea to list what is allowed. It is not necessary to = state explicitly what is not allowed. = I also like the two design goals and support them in the document: > - Protect old clients > We want a client that uses version x of a module to be able to > function when talking to a server implementing version x+1. > = > - Protect importers > A new published module version must not break existing other > modules that imports from the module. Mehmet = (on behalf of Bernd Linowski) = > -----Original Message----- > From: netmod-bounces@ietf.org = > [mailto:netmod-bounces@ietf.org] On Behalf Of ext David Partain > Sent: Tuesday, October 28, 2008 4:03 PM > To: netmod@ietf.org > Subject: [netmod] Proposed consensus mail on yang-00000: = > module update rules > = > Greetings, > = > This is a call for consensus about issue 'yang-00000: module > update rules'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00000 > = > PLEASE speak up if you favor or object to the proposed rules, > including people who attended the interim. Silence is impossible > to interpret. > = > Issue: Need to define the rules for how modules are updated (new > revisions published). > = > The first day of the interim meeting spent a great deal of time > talking about this issue. This mail does not give a blow-by-blow > recounting of the discussion but rather tries to summarize what > was discussed and the conclusions. > = > The general principle is that when updating a module without name > changes, the module may become less constrained, but never more > constrained. > = > - Why do we need to have these rules? > = > * protect old client applications (old NETCONF clients > talking to a new NETCONF server). You're not allowed to > change something that makes a client that was previously > compliant suddenly no longer compliant. > * protect those importing a module > = > - We're talking about rules for: > = > * New building blocks (e.g., typedefs) > * New definitions > * Organizational changes (e.g., inline to named types) > * Bug fixes > = > - Rules for adding things to an existing module: > = > A proposal from Balazs Lengyel: > = > Balazs Lengyel provided a list of changes that Ericsson considers > "compatible" changes: > = > - adding new optional nodes > - adding new RPCs > - extending cardinality > - extending the data range > - change of default value of an optional attribute > - relaxing rules on semantic change (e.g., config -> > non-config, read-only -> read-write > - adding data to notifications > - updates to description clauses > - updates to extensions > = > where the policy is that if it's not on that list, it's > considered "an incompatible change" and shouldn't be done without > changing the namespace. > = > Incompatible changes: > = > - leaf order changes > = > This fed into the subsequent suggested rules... > = > Changes affecting types: > = > Martin Bj=F6rklund asked: > = > - Can you extend the value space when updating a document? > - Can you restrict the value space when updating a document? > = > For an answer, see the general principle above. > = > In the end, changes that affect storage requirements for a type > are not allowed. (Editor: the consensus here is entirely > unclear.) > = > Leaf change rules: > = > (Thanks to Balazs for his notes here!) > = > What are you allowed / not allowed to change about a leaf > definition (given the general principle above): > = > Changes that are permitted: > = > - status with the current/deprecated/obsolete progression > - new typedefs > - new groupings > - expand value range > - remove musts > - new optional non-mandatory nodes > - allow new rpc > - allow new notifications > - allow new data in existing notifications > - allow new optional parameters to rpc input(?) = > - allow new parameters to rpc output(?) = > - remove mandatory > - reference (updated) > - description (semantic equivalence) > - length > - add default (Editor: unsure of this!) > - add new bits > - add new enum values at the end of the list > - config false ->true > - (all kinds of "non-changes" as well) > = > Changes that are not permitted: > = > - delete nodes > - leaf order changes (due to strict encoding order) > - change basic type (e.g., uint8 -> int8) > - change length restriction of string > - make a type into union > - no new mandatory nodes > - change datatype of a leaf (underlying datatype at the > - base of the type hierarchy) > - add new membertypes to a union > - change units > - change default > - add if-feature > - change the value of enum or bits > - add enums in the middle > = > Typedef change rules: > = > The typedef rules discussion immediately morphed into a > discussion of "import by revision", which will be reported on > separately. However, we reached rough consensus to proceed > with "import by revision", and, by deciding this, we can use > the same rules for typedefs as we have for leafs. We have not > talked about the rules for groupings yet. > = > Martin Bj=F6rklund is going to take the lead in writing a > proposal for import by revision to cover import and include, as > well as the rules for what can change between revisions > (typedefs, groups, leafs, etc.). > _______________________________________________ > 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 Nov 7 10:42: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 66F7C3A6B63; Fri, 7 Nov 2008 10:42:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148C43A6B63 for ; Fri, 7 Nov 2008 10:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=-0.582, 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 78YuA8MnCriE for ; Fri, 7 Nov 2008 10:42:17 -0800 (PST) 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 69CC73A68A0 for ; Fri, 7 Nov 2008 10:42:17 -0800 (PST) Received: (qmail 83856 invoked from network); 7 Nov 2008 18:42:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 7 Nov 2008 18:42:11 -0000 X-YMail-OSG: lEMMLMAVM1m8NCGWOE3fKwXnWXZxSqZbbiV5KYy67HocZPq4JVLFL18ygZUNXmmSh06ZdqVMZkb3IzS2X5pGTGVUAfWmwieyJGAn88j7GuY3MiLm9QgbbMjjzn0Ct6V.Xtk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49148C01.8010908@netconfcentral.com> Date: Fri, 07 Nov 2008 10:42:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] keyref ABNF X-BeenThere: netmod@ietf.org 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 ABNF on pg. 146 doesn't look right to me: relative-path = descendant-path / (".." "/" *relative-path) relative-path leads to path constructions such as "../../". Clearly no ancestor node of 'self' is going to be a leaf, let alone a key leaf. I think this ABNF expresses the intended syntax: relative-path = *(".." "/") descendant-path Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Nov 7 17:05: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 6DF573A6BC3; Fri, 7 Nov 2008 17:05:01 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD1A3A6884 for ; Fri, 7 Nov 2008 17:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.193, 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 vD8FxhxPe8Wr for ; Fri, 7 Nov 2008 17:04:59 -0800 (PST) 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 759923A6BC3 for ; Fri, 7 Nov 2008 17:04:59 -0800 (PST) Received: (qmail 64000 invoked from network); 8 Nov 2008 01:04:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 8 Nov 2008 01:04:54 -0000 X-YMail-OSG: ZmMtMa0VM1ljYEwU8JxxpQ1JlZPOmCjaSpEtMK6FDGqk8hQ.CnuMGjLqiWXe4zaB6z.HYau2DcLSD3dmhMQEW.AXUgDAwz_QK68GJzUBGPdkH700TfhUmiVLHNA9C3cZCag- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4914E5B4.7030401@netconfcentral.com> Date: Fri, 07 Nov 2008 17:04:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group References: <49148C01.8010908@netconfcentral.com> In-Reply-To: <49148C01.8010908@netconfcentral.com> Subject: Re: [netmod] keyref ABNF X-BeenThere: netmod@ietf.org 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, > > This ABNF on pg. 146 doesn't look right to me: > > > relative-path = descendant-path / > (".." "/" > *relative-path) > > > relative-path leads to path constructions such as "../../". > Clearly no ancestor node of 'self' is going to be a leaf, > let alone a key leaf. > > I think this ABNF expresses the intended syntax: > > relative-path = *(".." "/") descendant-path > This is wrong as well: descendant-path = node-identifier *path-predicate absolute-path It should be: descendant-path = node-identifier *path-predicate [absolute-path] (e.g., ../../foo) > > Andy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 9 07:50: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 E9E033A67CC; Sun, 9 Nov 2008 07:50:29 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54333A69A6 for ; Sun, 9 Nov 2008 07:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-1.117, 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 gAyUEw2FpzSw for ; Sun, 9 Nov 2008 07:50:28 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 56BDE3A67CC for ; Sun, 9 Nov 2008 07:50:28 -0800 (PST) Received: (qmail 57990 invoked from network); 9 Nov 2008 15:50:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 9 Nov 2008 15:50:23 -0000 X-YMail-OSG: hAy9L_QVM1mMH.NmLc04dek_x3Sl0i6z.2kKnV1qSzj0DxRvSl5eWb5xj98Bb2_TE3coUAjhrmknGeBMod8PwHp0A8jH5sIY10sjGlyVmlztJ0CqS4fOL.kvT9u.dUSacd0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <491706BD.4030205@netconfcentral.com> Date: Sun, 09 Nov 2008 07:50:21 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] yang-02, typo on pg. 119 X-BeenThere: netmod@ietf.org 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 'crypto' example for identityref has the type name as 'identity-ref'. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 9 11:07: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 026E43A63D2; Sun, 9 Nov 2008 11:07:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944383A67DD for ; Sun, 9 Nov 2008 11:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.693, 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 GQOZdUwHPMoU for ; Sun, 9 Nov 2008 11:07:03 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id E5FC33A63D2 for ; Sun, 9 Nov 2008 11:07:03 -0800 (PST) Received: (qmail 90643 invoked from network); 9 Nov 2008 19:07:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.54 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 9 Nov 2008 19:06:58 -0000 X-YMail-OSG: EDvetgcVM1lpuNmXwrJqoT6QZeGKHkhTfUXe13AZ720xlPiu57y7liA.0YxBNxx7c78i83AQZuHO9gHpyAP0JgD1kq3mS96C3ZCjf9FjTqetiTK5PcRl6R.9aKAowRDhAj_HNZ3Hqt2Ug_CjaOrA_qpA9kI_7VtnVJMnf4oLk6Ej X-Yahoo-Newman-Property: ymail-3 Message-ID: <491734D1.9090205@netconfcentral.com> Date: Sun, 09 Nov 2008 11:06:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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 suppose the leafref/keyref issues need to be cleared up in general, but I just ran across a specific CLR while testing some new code. The ifStackEntry in IF-MIB.yang is indexed by ifStackHigherLayer and ifStackLowerLayer. These are non-config, because this table is built by the agent, not the manager. http://www.netconfcentral.com/modules/IF-MIB/2000-06-14#ifStackEntry.497 The ifInvStackEntry is indexed by keyrefs into the ifStackTable (also called ifStackLowerLayer and ifStackHigherLayer), but these entries are writable. (See ifInvStackStatus for more details) http://www.netconfcentral.com/modules/IF-INVERTED-STACK-MIB/2000-06-14#ifInvStackEntry.51 Either Juergen cannot do this translation in his smidump program or the CLR about a config keyref pointing at a non-config key needs to be fixed somehow. I like the s/keyref/leafref idea with sub-clauses for the properties that need to be controlled. (Or another option is to just have leafref with no constraints and no extra sub-clauses.) leaf foo { type leafref { path "..."; // T: path target must be a config leaf require-config true/false [default: false]; // T: path object must be a key leaf require-key true/false [default: false]; // T: leafref leaf can only have values matching existing // instances of the target leaf // F: leafref leaf can have any valid value for the data type // of the target leaf require-instance true/false [default: false]; } } Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 12:41: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 4FA3E28C111; Mon, 10 Nov 2008 12:41:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9E128C111 for ; Mon, 10 Nov 2008 12:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4gN7xRaWiXb for ; Mon, 10 Nov 2008 12:41:37 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2BE8128C120 for ; Mon, 10 Nov 2008 12:41:36 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C6F1616003; Mon, 10 Nov 2008 21:41:32 +0100 (CET) Date: Mon, 10 Nov 2008 21:41:28 +0100 (CET) Message-Id: <20081110.214128.132601415.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4914E5B4.7030401@netconfcentral.com> References: <49148C01.8010908@netconfcentral.com> <4914E5B4.7030401@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] keyref ABNF X-BeenThere: netmod@ietf.org 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: > > Hi, > > This ABNF on pg. 146 doesn't look right to me: > > relative-path = descendant-path / > > (".." "/" > > *relative-path) > > relative-path leads to path constructions such as "../../". > > Clearly no ancestor node of 'self' is going to be a leaf, > > let alone a key leaf. > > I think this ABNF expresses the intended syntax: > > relative-path = *(".." "/") descendant-path You are right, fixed. > This is wrong as well: > > descendant-path = node-identifier *path-predicate > absolute-path > > It should be: > > > descendant-path = node-identifier *path-predicate > [absolute-path] > > > (e.g., ../../foo) But this would also allow ../../foo[name=current()/../bar] so I think it should be descendant-path = node-identifier [*path-predicate absolute-path] /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 12:42: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 6401428C111; Mon, 10 Nov 2008 12:42:18 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E35528C195 for ; Mon, 10 Nov 2008 12:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.095, 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 srVLngE+YX+b for ; Mon, 10 Nov 2008 12:42:16 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6CC3228C181 for ; Mon, 10 Nov 2008 12:42:16 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0518B616003; Mon, 10 Nov 2008 21:42:13 +0100 (CET) Date: Mon, 10 Nov 2008 21:42:12 +0100 (CET) Message-Id: <20081110.214212.59103096.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <491706BD.4030205@netconfcentral.com> References: <491706BD.4030205@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-02, typo on pg. 119 X-BeenThere: netmod@ietf.org 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, > > The 'crypto' example for identityref has the type name > as 'identity-ref'. Thanks, fixed. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 12:48: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 215E83A696F; Mon, 10 Nov 2008 12:48:46 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777643A6A64 for ; Mon, 10 Nov 2008 12:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.087, 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 6NnHD5okVjew for ; Mon, 10 Nov 2008 12:48:43 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 81F7D3A696F for ; Mon, 10 Nov 2008 12:48:43 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1980C616003; Mon, 10 Nov 2008 21:48:40 +0100 (CET) Date: Mon, 10 Nov 2008 21:48:36 +0100 (CET) Message-Id: <20081110.214836.173271260.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <491734D1.9090205@netconfcentral.com> References: <491734D1.9090205@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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: > I like the s/keyref/leafref idea with sub-clauses for > the properties that need to be controlled. So do I. > leaf foo { > type leafref { > path "..."; > > // T: path target must be a config leaf > require-config true/false [default: false]; > > // T: path object must be a key leaf > require-key true/false [default: false]; > > // T: leafref leaf can only have values matching existing > // instances of the target leaf > // F: leafref leaf can have any valid value for the data type > // of the target leaf > require-instance true/false [default: false]; > } > } I don't understand the "require-config" and "require-key" clauses. This property will be given by the "path" argument - the leaf the path points to is either config or not, and it is a key or not. I think the "require-instance" clause is all that is needed. A config keyref can point to a non-config key, provided "require-instance" is false. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 13:53: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 8840628C11B; Mon, 10 Nov 2008 13:53:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD2528C11D for ; Mon, 10 Nov 2008 13:53:33 -0800 (PST) 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 56STX5CBR0qr for ; Mon, 10 Nov 2008 13:53:33 -0800 (PST) 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 4C90E28C11B for ; Mon, 10 Nov 2008 13:53:33 -0800 (PST) Received: (qmail 79424 invoked from network); 10 Nov 2008 21:53:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.167.173 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 10 Nov 2008 21:53:28 -0000 X-YMail-OSG: mg3IhQcVM1lVTE3ek6pheP8cuRdJjN6kAXNTEZ2xOTq7yBnjzzTvL4_49IKO2APwqZgfuK_kkIPcqmg_1ANPtwbS7ylvLgjDqUY9ZbtxJprT9dYljcnodOo03T35n_pD70X7WL1AdHzppw5Pl5WSEmzQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4918AD55.1070209@netconfcentral.com> Date: Mon, 10 Nov 2008 13:53:25 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <49148C01.8010908@netconfcentral.com> <4914E5B4.7030401@netconfcentral.com> <20081110.214128.132601415.mbj@tail-f.com> In-Reply-To: <20081110.214128.132601415.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref ABNF X-BeenThere: netmod@ietf.org 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: >> Andy Bierman wrote: >>> Hi, >>> This ABNF on pg. 146 doesn't look right to me: >>> relative-path = descendant-path / >>> (".." "/" >>> *relative-path) >>> relative-path leads to path constructions such as "../../". >>> Clearly no ancestor node of 'self' is going to be a leaf, >>> let alone a key leaf. >>> I think this ABNF expresses the intended syntax: >>> relative-path = *(".." "/") descendant-path > > You are right, fixed. > >> This is wrong as well: >> >> descendant-path = node-identifier *path-predicate >> absolute-path >> >> It should be: >> >> >> descendant-path = node-identifier *path-predicate >> [absolute-path] >> >> >> (e.g., ../../foo) > > But this would also allow ../../foo[name=current()/../bar] > > so I think it should be > > descendant-path = node-identifier > [*path-predicate absolute-path] > > OK > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 14:15: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 036EA3A6A7A; Mon, 10 Nov 2008 14:15:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F8B28C1C3 for ; Mon, 10 Nov 2008 14:15:14 -0800 (PST) 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 O2wEo1IAhBU3 for ; Mon, 10 Nov 2008 14:15:14 -0800 (PST) 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 0E62D3A6A7A for ; Mon, 10 Nov 2008 14:15:14 -0800 (PST) Received: (qmail 59021 invoked from network); 10 Nov 2008 22:15:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.167.173 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 10 Nov 2008 22:15:09 -0000 X-YMail-OSG: SxV1eGcVM1kt1wzdRZItc6TaZ5EtPzWQjbDU6UXAMB2BXEvhmut3VbNkeFdfJxOJMoSHq6g.HjF.EO4B.vL26f2Tyr.kLGPsnThJarHA393qkgzIePiLPUK1dwdDUt551gfPBOfk_.ok6mU9EVK7LssN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4918B26B.7040002@netconfcentral.com> Date: Mon, 10 Nov 2008 14:15:07 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <491734D1.9090205@netconfcentral.com> <20081110.214836.173271260.mbj@tail-f.com> In-Reply-To: <20081110.214836.173271260.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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: >> I like the s/keyref/leafref idea with sub-clauses for >> the properties that need to be controlled. > > So do I. > >> leaf foo { >> type leafref { >> path "..."; >> >> // T: path target must be a config leaf >> require-config true/false [default: false]; >> >> // T: path object must be a key leaf >> require-key true/false [default: false]; >> >> // T: leafref leaf can only have values matching existing >> // instances of the target leaf >> // F: leafref leaf can have any valid value for the data type >> // of the target leaf >> require-instance true/false [default: false]; >> } >> } > > I don't understand the "require-config" and "require-key" clauses. > This property will be given by the "path" argument - the leaf the path > points to is either config or not, and it is a key or not. > So remove the CLRs about "keyref leaf must point at a key leaf" and a "config keyref leaf must not point at a non-config key leaf"? OK > I think the "require-instance" clause is all that is needed. A config > keyref can point to a non-config key, provided "require-instance" is > false. > I don't think it has to be false. Some of the SNMP examples have writable extension tables that expect the read-only version of each row to be present. How about no CLRs? A leafref just needs to point at a leaf. The 'config T/F' or 'key T/F' flags do not matter. The 'require-instance' flag (or whatever it should be called) does not have to be set, but if it is, the agent will limit the leafref leaf to the existing values of the 'pointed-at' leaf. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 14:56: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 C6C0E3A6AC3; Mon, 10 Nov 2008 14:56:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138F73A6AC4 for ; Mon, 10 Nov 2008 14:56:00 -0800 (PST) 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.080, 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 Xy8qr5OiJz9W for ; Mon, 10 Nov 2008 14:55:58 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7253B3A6AA1 for ; Mon, 10 Nov 2008 14:55:58 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0275F616005; Mon, 10 Nov 2008 23:55:52 +0100 (CET) Date: Mon, 10 Nov 2008 23:55:52 +0100 (CET) Message-Id: <20081110.235552.251333666.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4918B26B.7040002@netconfcentral.com> References: <491734D1.9090205@netconfcentral.com> <20081110.214836.173271260.mbj@tail-f.com> <4918B26B.7040002@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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, > > Andy Bierman wrote: > >> I like the s/keyref/leafref idea with sub-clauses for > >> the properties that need to be controlled. > > So do I. > > > >> leaf foo { > >> type leafref { > >> path "..."; > >> > >> // T: path target must be a config leaf > >> require-config true/false [default: false]; > >> > >> // T: path object must be a key leaf > >> require-key true/false [default: false]; > >> > >> // T: leafref leaf can only have values matching existing > >> // instances of the target leaf > >> // F: leafref leaf can have any valid value for the data type > >> // of the target leaf > >> require-instance true/false [default: false]; > >> } > >> } > > I don't understand the "require-config" and "require-key" clauses. > > This property will be given by the "path" argument - the leaf the path > > points to is either config or not, and it is a key or not. > > > > So remove the CLRs about "keyref leaf must point at a key leaf" and > a "config keyref leaf must not point at a non-config key leaf"? No I meant that if the path doesn't point to a key, what does it mean if it has "require-key true"? > > I think the "require-instance" clause is all that is needed. A config > > keyref can point to a non-config key, provided "require-instance" is > > false. > > > > I don't think it has to be false. > Some of the SNMP examples have writable extension tables that > expect the read-only version of each row to be present. So what happens if, at some time after commit, the read-only version of the row is no longer present? Is that an error? The agent MUST NOT remove any non-config key/leafs that config keyrefs points to?? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 15: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 A873A3A6A38; Mon, 10 Nov 2008 15:26:28 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0253A6AA4 for ; Mon, 10 Nov 2008 15:26:27 -0800 (PST) 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 VEyYxJO0RpGK for ; Mon, 10 Nov 2008 15:26:26 -0800 (PST) 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 3EB553A6A38 for ; Mon, 10 Nov 2008 15:26:25 -0800 (PST) Received: (qmail 90681 invoked from network); 10 Nov 2008 23:26:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.167.173 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 10 Nov 2008 23:26:20 -0000 X-YMail-OSG: Y2Z6.tgVM1n.ftwRt1iEAUMgfzNyD1T9VY6NfpLgpwMxYm_QZRKM2s2HQ5zg_anH_BA1nEcHqKwORoXHX3L7S62352I7LxzMwvhgyx3vm77NqXxXEQsZwBdpYLjz7mHVyscBuaKVWITa7Xh4MQkgAtU8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4918C31A.3020003@netconfcentral.com> Date: Mon, 10 Nov 2008 15:26:18 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <491734D1.9090205@netconfcentral.com> <20081110.214836.173271260.mbj@tail-f.com> <4918B26B.7040002@netconfcentral.com> <20081110.235552.251333666.mbj@tail-f.com> In-Reply-To: <20081110.235552.251333666.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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, >>> Andy Bierman wrote: >>>> I like the s/keyref/leafref idea with sub-clauses for >>>> the properties that need to be controlled. >>> So do I. >>> >>>> leaf foo { >>>> type leafref { >>>> path "..."; >>>> >>>> // T: path target must be a config leaf >>>> require-config true/false [default: false]; >>>> >>>> // T: path object must be a key leaf >>>> require-key true/false [default: false]; >>>> >>>> // T: leafref leaf can only have values matching existing >>>> // instances of the target leaf >>>> // F: leafref leaf can have any valid value for the data type >>>> // of the target leaf >>>> require-instance true/false [default: false]; >>>> } >>>> } >>> I don't understand the "require-config" and "require-key" clauses. >>> This property will be given by the "path" argument - the leaf the path >>> points to is either config or not, and it is a key or not. >>> >> So remove the CLRs about "keyref leaf must point at a key leaf" and >> a "config keyref leaf must not point at a non-config key leaf"? > > No I meant that if the path doesn't point to a key, what does it mean > if it has "require-key true"? > >>> I think the "require-instance" clause is all that is needed. A config >>> keyref can point to a non-config key, provided "require-instance" is >>> false. >>> >> I don't think it has to be false. >> Some of the SNMP examples have writable extension tables that >> expect the read-only version of each row to be present. > > So what happens if, at some time after commit, the read-only version > of the row is no longer present? Is that an error? The agent MUST > NOT remove any non-config key/leafs that config keyrefs points to?? > One way of looking at it is that the schema nodes are always present and there may or may not be any instances of the pointed-at leaf. If the require-instance flag is true, then deleting the instance of the pointed-at leaf set in the leafref makes the leafref node invalid and a commit will fail. There is no MUST NOT REMOVE rule, any more than a manager messing up a config in other ways. It just won't commit (or edit-config on will fail right away). It require-instance is false, then the agent just needs to know about the pointed-at object (to get its typedef). The leafrefs will still validate if they contain a value valid for the data type, but not a value actually in use as an instance of the pointed-at leaf. The problem is not 'instance T/F', but rather that the config and the operation have no notion of mixing non-config from into the validation procedures. That is a pure YANG-ism, and needs special code to work. I prefer a 'no CLR' approach. The agent has to figure out what to do if nodes in any XPath expression (must, when, path) reference a non-config node. If validation fails, then it fails. We should avoid rules that say "you MUST NOT saw off the branch you are sitting on." > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 10 23:57: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 4BE6D3A68AD; Mon, 10 Nov 2008 23:57:43 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C2C3A68AD for ; Mon, 10 Nov 2008 23:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUgtEuMVqRjT for ; Mon, 10 Nov 2008 23:57:41 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F2FA33A6861 for ; Mon, 10 Nov 2008 23:57:37 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9428D76C312; Tue, 11 Nov 2008 08:57:34 +0100 (CET) Date: Tue, 11 Nov 2008 08:57:32 +0100 (CET) Message-Id: <20081111.085732.75907088.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4918C31A.3020003@netconfcentral.com> References: <4918B26B.7040002@netconfcentral.com> <20081110.235552.251333666.mbj@tail-f.com> <4918C31A.3020003@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] keyref CLRs X-BeenThere: netmod@ietf.org 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 way of looking at it is > that the schema nodes are always present and > there may or may not be any instances of the pointed-at leaf. > > If the require-instance flag is true, then deleting > the instance of the pointed-at leaf set in the leafref > makes the leafref node invalid and a commit will fail. > > There is no MUST NOT REMOVE rule, any more than a manager > messing up a config in other ways. It just won't commit > (or edit-config on will fail right away). It's not the manager that messes things up if the agent removes the read-only row. The problem is that when you set the keyref which points to non-config data, the non-config data might exist, and the config commits. Then, for some reason, the agent removes the non-config data. At this point, no manager is involved, and the running config is invalid. (IMO, this in itself is the real issue - the invariant is that running is always valid). Now, some other manager might change some innocent parameter and try to commit. This will fail b/c of a missing leafref. > It require-instance is false, then the agent just needs > to know about the pointed-at object (to get its typedef). > The leafrefs will still validate if they contain > a value valid for the data type, but not a value > actually in use as an instance of the pointed-at leaf. Yes. I like this. > The problem is not 'instance T/F', but rather that > the config and the operation > have no notion of mixing non-config from > into the validation procedures. That is a pure YANG-ism, > and needs special code to work. See above. I don't think it's a YANG issue. running is always valid. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 11 06:42: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 439533A6840; Tue, 11 Nov 2008 06:42:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0B93A6B1B for ; Tue, 11 Nov 2008 06:42:05 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhsBQFHLRtEH for ; Tue, 11 Nov 2008 06:42:04 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 179C428C11A for ; Tue, 11 Nov 2008 06:42:03 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 294B8210DC; Tue, 11 Nov 2008 15:42:03 +0100 (CET) X-AuditID: c1b4fb3e-ab77fbb00000537b-26-491999bbc837 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0CACA20F95; Tue, 11 Nov 2008 15:42:03 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 15:42:02 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 15:42:02 +0100 Message-ID: <491999B9.3090908@ericsson.com> Date: Tue, 11 Nov 2008 15:42:01 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4918B26B.7040002@netconfcentral.com> <20081110.235552.251333666.mbj@tail-f.com> <4918C31A.3020003@netconfcentral.com> <20081111.085732.75907088.mbj@tail-f.com> In-Reply-To: <20081111.085732.75907088.mbj@tail-f.com> X-OriginalArrivalTime: 11 Nov 2008 14:42:02.0256 (UTC) FILETIME=[A8B56900:01C9440B] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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 also like to cut down on little rules. Someone had earlier the proposed: --------------------- leafref foo { path ... strict true/false; } If strict=true, foo must point to configuration data that must also exist. (might or might not be key) If strict=false then foo can point to config or non-config, it can point at existing or non-existing, the only requirements are that the path specified exists in the schema tree and that the value of foo conforms to the pointed to datatype. --------------------- Both cases are simple, easy to understand. One gives strict control, one gives freedom. Some middle cases are not handled (e.g. pointer to strictly existing stuff which can be non-config), but we don't have to handle every little corner case. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> One way of looking at it is >> that the schema nodes are always present and >> there may or may not be any instances of the pointed-at leaf. >> >> If the require-instance flag is true, then deleting >> the instance of the pointed-at leaf set in the leafref >> makes the leafref node invalid and a commit will fail. >> >> There is no MUST NOT REMOVE rule, any more than a manager >> messing up a config in other ways. It just won't commit >> (or edit-config on will fail right away). > > It's not the manager that messes things up if the agent removes the > read-only row. > > The problem is that when you set the keyref which points to non-config > data, the non-config data might exist, and the config commits. Then, > for some reason, the agent removes the non-config data. At this > point, no manager is involved, and the running config is invalid. > (IMO, this in itself is the real issue - the invariant is that running > is always valid). Now, some other manager might change some innocent > parameter and try to commit. This will fail b/c of a missing > leafref. > >> It require-instance is false, then the agent just needs >> to know about the pointed-at object (to get its typedef). >> The leafrefs will still validate if they contain >> a value valid for the data type, but not a value >> actually in use as an instance of the pointed-at leaf. > > Yes. I like this. > >> The problem is not 'instance T/F', but rather that >> the config and the operation >> have no notion of mixing non-config from >> into the validation procedures. That is a pure YANG-ism, >> and needs special code to work. > > See above. I don't think it's a YANG issue. running is always > valid. > > > /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 Tue Nov 11 07:59: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 481DD3A6B27; Tue, 11 Nov 2008 07:59:35 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA433A6B29 for ; Tue, 11 Nov 2008 07:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oymQ2nm0Pp5Z for ; Tue, 11 Nov 2008 07:59:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 96AEB3A6B27 for ; Tue, 11 Nov 2008 07:59:32 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4878C007A; Tue, 11 Nov 2008 16:59:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LbA0xaRz1UJU; Tue, 11 Nov 2008 16:59:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF838C0004; Tue, 11 Nov 2008 16:59:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5FB968594F4; Tue, 11 Nov 2008 16:59:27 +0100 (CET) Date: Tue, 11 Nov 2008 16:59:27 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20081111155927.GA10786@elstar.local> Mail-Followup-To: Balazs Lengyel , Martin Bjorklund , netmod@ietf.org References: <4918B26B.7040002@netconfcentral.com> <20081110.235552.251333666.mbj@tail-f.com> <4918C31A.3020003@netconfcentral.com> <20081111.085732.75907088.mbj@tail-f.com> <491999B9.3090908@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <491999B9.3090908@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs 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, Nov 11, 2008 at 03:42:01PM +0100, Balazs Lengyel wrote: > Someone had earlier the proposed: > > --------------------- > leafref foo { > path ... > strict true/false; > } > > If strict=true, foo must point to configuration data that must also > exist. (might or might not be key) > > If strict=false then foo can point to config or non-config, it can point > at existing or non-existing, the only requirements are that the path > specified exists in the schema tree and that the value of foo conforms to > the pointed to datatype. > --------------------- > > Both cases are simple, easy to understand. One gives strict control, one > gives freedom. Some middle cases are not handled (e.g. pointer to > strictly existing stuff which can be non-config), but we don't have to > handle every little corner case. What does "must also exist" mean? Does this imply that any attempt to remove ... fails? And if yes, which error can be expected if an application tries to remove ...? /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 Nov 11 08:34: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 A9D5B28C18D; Tue, 11 Nov 2008 08:34:29 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC9028C1AD for ; Tue, 11 Nov 2008 08:34:27 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZk+sTiCZxHC for ; Tue, 11 Nov 2008 08:34:23 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A81F028C18D for ; Tue, 11 Nov 2008 08:34:22 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 444C0214A5; Tue, 11 Nov 2008 17:34:22 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-b0-4919b40ec792 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2D327214D3; Tue, 11 Nov 2008 17:34:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 17:34:21 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 17:34:21 +0100 Message-ID: <4919B40D.4000407@ericsson.com> Date: Tue, 11 Nov 2008 17:34:21 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , Martin Bjorklund , netmod@ietf.org References: <4918B26B.7040002@netconfcentral.com> <20081110.235552.251333666.mbj@tail-f.com> <4918C31A.3020003@netconfcentral.com> <20081111.085732.75907088.mbj@tail-f.com> <491999B9.3090908@ericsson.com> <20081111155927.GA10786@elstar.local> In-Reply-To: <20081111155927.GA10786@elstar.local> X-OriginalArrivalTime: 11 Nov 2008 16:34:21.0598 (UTC) FILETIME=[59AB63E0:01C9441B] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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, Yes removal leads to an error, as the leafref constraint would be violated (just as for todays keyref). Error code could be: error-tag: missing-element (if we are allowed to mean "missing in the datastore") error-app-tag: referenced-data-can-not-be-removed or error-tag: operation-failed error-app-tag: referenced-data-can-not-be-removed Balazs Juergen Schoenwaelder wrote: > On Tue, Nov 11, 2008 at 03:42:01PM +0100, Balazs Lengyel wrote: > >> Someone had earlier the proposed: >> >> --------------------- >> leafref foo { >> path ... >> strict true/false; >> } >> >> If strict=true, foo must point to configuration data that must also >> exist. (might or might not be key) >> >> If strict=false then foo can point to config or non-config, it can point >> at existing or non-existing, the only requirements are that the path >> specified exists in the schema tree and that the value of foo conforms to >> the pointed to datatype. >> --------------------- >> >> Both cases are simple, easy to understand. One gives strict control, one >> gives freedom. Some middle cases are not handled (e.g. pointer to >> strictly existing stuff which can be non-config), but we don't have to >> handle every little corner case. > > What does "must also exist" mean? Does this imply that any attempt to > remove ... fails? And if yes, which error can be expected if an > application tries to remove ...? > > /js > -- 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 Nov 11 08:59: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 8D9463A6851; Tue, 11 Nov 2008 08:59:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF5A28C163 for ; Tue, 11 Nov 2008 08:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QRXpIbqS1qd for ; Tue, 11 Nov 2008 08:59:26 -0800 (PST) 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 2DDA63A6851 for ; Tue, 11 Nov 2008 08:59:26 -0800 (PST) Received: (qmail 10289 invoked from network); 11 Nov 2008 16:59:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.248.94 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 11 Nov 2008 16:59:25 -0000 X-YMail-OSG: RaEXrgkVM1l23pBRuqwS63CaDHjVPekBIwkjNsXF.y5Ar4yCZoxf68oj_KnbeIqOSvbzHbdBSAi08L5Qh.vMuq78_5psTLlFlK_TpApYKMFYjlrsNIq5kW9yOoJ9hAIJlqaC9extUrBL6ecbcwCpe7o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4919B9EC.7000406@netconfcentral.com> Date: Tue, 11 Nov 2008 08:59:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <4918B26B.7040002@netconfcentral.com> <20081110.235552.251333666.mbj@tail-f.com> <4918C31A.3020003@netconfcentral.com> <20081111.085732.75907088.mbj@tail-f.com> <491999B9.3090908@ericsson.com> <20081111155927.GA10786@elstar.local> <4919B40D.4000407@ericsson.com> In-Reply-To: <4919B40D.4000407@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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, > Yes removal leads to an error, as the leafref constraint would be > violated (just as for todays keyref). > Error code could be: > error-tag: missing-element (if we are allowed to mean "missing in the > datastore") > error-app-tag: referenced-data-can-not-be-removed > or > error-tag: operation-failed > error-app-tag: referenced-data-can-not-be-removed > This is too complicated on the agent, and does not fit with current practice. If an ATM line card gets pulled, and the agent is designed to remove the ATM data model with the read-only table in it, then this CLR is going to get in the way. The SNMP examples I have looked at do not make sense if the 'pointed-at' object goes away. In every case, the leafref object must go away too (or the notification will not be generated anymore, etc.) Instead of preventing the r/o leafs from getting deleted, the agent could issue a notification and delete all the leafrefs that point at the deleted r/o leafs. What if a manager sets the enableAtmStatistics knob to false? Is that supposed to fail in the validation phase? A centralized agent is not going to know that setting this knob to false will cause an agent callback to remove/disable other r/o nodes from the object tree (after validatation). There are lots of corner cases here. The only things that can really be counted on: 1) the agent MUST keep the config valid 2) a commit operation MUST fail if (1) cannot be met There is a significant agent resource increase incurred in order to replicate all of the config, not just the 'config true' nodes. Are we sure there isn't a better way to handle these corner cases? > Balazs Andy > > Juergen Schoenwaelder wrote: >> On Tue, Nov 11, 2008 at 03:42:01PM +0100, Balazs Lengyel wrote: >> >>> Someone had earlier the proposed: >>> >>> --------------------- >>> leafref foo { >>> path ... >>> strict true/false; >>> } >>> >>> If strict=true, foo must point to configuration data that must also >>> exist. (might or might not be key) >>> >>> If strict=false then foo can point to config or non-config, it can >>> point at existing or non-existing, the only requirements are that the >>> path specified exists in the schema tree and that the value of foo >>> conforms to the pointed to datatype. >>> --------------------- >>> >>> Both cases are simple, easy to understand. One gives strict control, >>> one gives freedom. Some middle cases are not handled (e.g. pointer to >>> strictly existing stuff which can be non-config), but we don't have >>> to handle every little corner case. >> >> What does "must also exist" mean? Does this imply that any attempt to >> remove ... fails? And if yes, which error can be expected if an >> application tries to remove ...? >> >> /js >> > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 11 13:15: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 9A0E63A67A5; Tue, 11 Nov 2008 13:15:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B4A3A67A5 for ; Tue, 11 Nov 2008 13:15:15 -0800 (PST) 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 aLhlwYnzY6Xu for ; Tue, 11 Nov 2008 13:15:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3F4823A6925 for ; Tue, 11 Nov 2008 13:15:14 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7937A76C312; Tue, 11 Nov 2008 22:15:12 +0100 (CET) Date: Tue, 11 Nov 2008 22:15:08 +0100 (CET) Message-Id: <20081111.221508.196131558.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4919B9EC.7000406@netconfcentral.com> References: <20081111155927.GA10786@elstar.local> <4919B40D.4000407@ericsson.com> <4919B9EC.7000406@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] keyref CLRs X-BeenThere: netmod@ietf.org 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, > > Yes removal leads to an error, as the leafref constraint would be violated > > (just as for todays keyref). > > Error code could be: > > error-tag: missing-element (if we are allowed to mean "missing in the > > datastore") > > error-app-tag: referenced-data-can-not-be-removed > > or > > error-tag: operation-failed > > error-app-tag: referenced-data-can-not-be-removed > > > > This is too complicated on the agent, and does not fit > with current practice. If an ATM line card gets pulled, > and the agent is designed to remove the ATM data model > with the read-only table in it, then this CLR is going > to get in the way. Things gets too complicated if we allow config leafrefs with "require-instance true" to point to non-config leafs. If config points to config with "require-instance true", then it is just a normal validation rule to handle at commit time. > There is a significant agent resource increase incurred > in order to replicate all of the config, > not just the 'config true' nodes. Are we sure there isn't > a better way to handle these corner cases? I think the following rule is simple to understand , easy to implement, and does not break the invariant that running MUST always be valid. A config leafref with require-instance true MUST NOT point to a non-config leaf. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 11 14:20: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 878F028C150; Tue, 11 Nov 2008 14:20:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B266828C15D for ; Tue, 11 Nov 2008 14:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 O0Bw070RRG7X for ; Tue, 11 Nov 2008 14:20:13 -0800 (PST) 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 115DE28C150 for ; Tue, 11 Nov 2008 14:20:12 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA01.westchester.pa.mail.comcast.net with comcast id dq9f1a0041HzFnQ51yLDHf; Tue, 11 Nov 2008 22:20:13 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id dyL01a00R4HwxpC3ayL0qT; Tue, 11 Nov 2008 22:20:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=uy9cWEW4VbiTy4gnt9sA:9 a=J7DseNv9f_SYFSlq4NYA:7 a=g2KHydtPz1d9fStqulTmU8OZ4mYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Tue, 11 Nov 2008 17:20:13 -0500 Message-ID: <091c01c9444b$aac4ccf0$0500a8c0@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: AclES6pXf3900pbYRjuwz92Xgr8hSQ== Subject: [netmod] review of -arch X-BeenThere: netmod@ietf.org 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 a review of the netmod-arch document. 1) YANG is to netconf as SMI is to SNMP. I recommend starting the arch document by putting YANG into perspective. I recommend fashioning the Introduction on the Introductions to RFC2578, RFC2579, and RFC2580. The follow that with the current Introduction. 2) The document should present its description of the architecture without blatant marketing. Most notbaly, section 6 should be eliminated. section 2.1 s/nearly perfectly// I think it is important to discuss the fact that Netconf has a PDU format that is an XML document (or a fragment of an XML document). YANG is a language for standardizing how to write XML documents for use with Netconf. I am not sure I understand why we need an example of modeling ospf in XML as an introduction to YANG as a modeling language. If XML matches nearly perfectly the data needs of networking devices, then remind me again why we need YANG?? section 2.2 So this is the part that explains YANG. Except that it actually doesn't mention the relationship between YANG and the "nearly perfect" XML of the previous section, and why YANG is needed. The example does not look simpler than the XML example. I don't think it mad every clear that YANG is a description of the XML model, including the constraints. I think a very quick discussion of the parts (container, key, range) that have specific purposes would be helpful. Something like "the key field identifies an instance of the area; the range show the legal values of the XML priority field, ..." 2.2.1 There is some discussion of YANG modules, but no discussion of why YANG is modular. In the MIB world, there is "the MIB" and then there are modular parts of "the MIB", to make it easier to develop pieces of the MIB. I think such a discussion might be helpful here. I strongly recommend the WG choose a term for their MIB and their MIB modules, so the documents can be consistent internally and across documents. Just pick a term and go with it. ", introducing elements from that models' hierarchy ...". I think this clause might be better as a separate sentence using example names for each module. "Elements from model B's namespace may augment model A's hierarchy." I think the document jumps too early into examples. By the time you get into the proprietary extension example, you are showing syntax that has not yet been defined. Explain the motivations for having a YANG language. Explain about the motiviation for defining types, and modules, and submodules, and groups, and supporting reuse, and so on. No exmaples; no syntax discussions - motivations. Why do we need YANG? "Extensions are seamlessly integrated" - I don't see this in the example. I don't think readers who are not XML experts or YANG experts will see that from this example. You might do well to use ASCII art a lot at this point, to explain some of the concepts without delving into syntax and examples. section 3. The MIB is defined as a virtual database of managed objects. I think similar terminology would be helpful here. After you introduce a virtual database, then discuss the fact that modules might be standard or proprietary, and they fit together in the virtual database. Throguhout the document, you seem to struggle with describing device functionality device specific behavior and so on. Just call it "instrumentation" - people already know that term. Or make a distinction between the virtual database and the actual database (or the instrumentation database or the configuration database). You seem to use applicatiion to refer to different things, and I find it confusing. You really need to standarize your use of terminology. I recommend having a "Conventions" section right after the first Introduction portion (i.e. section 2.1), to define the terms you will use throughout. I would move the "Key words" section into that Conventions section, and start the document wiht the Introduction. You might want to consider using "manager" and "agent" since those are well understood. Or you can use client and server terminology, which is also well-understood. "application" and "device" are less clear, since not all managed entities are devices, and "applications" can exist both on the device and off the device. What is the difference between a module and a schema? YANG allows you to define modules, and support for those modules is discovered using "schema" discovery. We need to be much more consistent in our terminology usage. The four paragraphs starting with "The schema discovery for standard YANG modules ..." is about netconf, not about YANG. During discussion of schema discovery, you talk about location of schemas. Then, later in this section, you give an example that models "location" using longitude and latitiude. Gee, does that mean when I do a schema discovery, I discover the latitude and longitude of where the schema can be found? ;-) You might want to use a different example at this point. "When the application interacts with a device, it ..."; s/it/the application/ "For a popular application, the vendor ..." which vendor? the device vendor or the application vendor? "uptake" - slang. The actual English meaning doesn't match the sentence meaning. I think the picture does add to comprehension. It would be better with terminology consistent throughout the YANG environment. The spacing before section 4 can be eliminated by using the xml2rfc command to compact. I recommend the following switches in xml2rfc: "Difficult as it is to believe, ..." is great when you are delivering a presentation, but really does not belong in a standards document. Can you clean up this paragraph, and can we lose the Sierra Madre while we're at it? "The complete standard mapping ... is implemented in "off the shelf" open source and commercial software." Since we haven't defined this yet, I have strong doubts that this statement is true. Let's not make predictions of what will be. "Many DSDL engines offer ...". I didn't know there were many DSDL engines, never mind ones that offer ... section 4.1 s/in the YANG module/in a YANG module/ 4.1.2 This section wanders, talking about validation, and generation, and serializers. Section 4.1.3 also talks about validation. I think this section really needs to be about a particular use case, just as the others sections are. "generating and receiving XML content" - I suggest generating and receiving "Netconf XML documents" or "Netconf PDUs" or "Netconf content". But is this different than 4.1.3? And 4.1.3 mentions "ascertian ... obeying the rules" which is the same as validation, right? "The YANG-based toolset" - we are not standardizing a toolset. We are standardizing a language. If there are tools out there, we probably should not be discussing them in this document, and claiming what they can do. I also did not understand what this paragraph even said - "generate support material", extensibility, augments? Is there a point to this paragraph? 4.1.5 s/data in without/data without/ s/without understanding any specifics/without understanding any semantics/ s/need only understand the YANG/need only understand the YANG syntax/ s/, but will have better information at its disposal with YANG.// (If you want to make such a claim, you will need to qualify what "better" means. If I wrote a YANG module with the same infoamrtion available in a MIB, it is not better information just because it is written in YANG, and more than a sentence with identical meaning written in English and French would make one better than the other.) 4.1.5.1 s/In contrast to the generic approach/In contrast to the bottom-up approach/ "the application transforms the application data into device data ... allowing the transformation to be changed and updated without affecting the device." - I find this unclear as to what you mean to say. If you modify the contract that both application and device follow, then changing the contract does affect the device. I think your examples would be much more useful to show network modelers how useful YANG could be to model their network, if you used a network example rather than hotdogs. Cute doesn't necessarily make things clearer, and our goal is to write clear and unambiguous documents. "The model may opt for a more complex model" - should be the modeler who opts? s/but applications that do not continue/but applications that do not discover such behavior continue/ s/do their best to be explicit/be explicit/ s/But both server and client/Both server and client/ section 7 ""The SSH transport for NETCONF provies such facilities." - Ummm, no it doesn't. The SSH transport doesn't mention RADIUS or local passwords. I think this section should discuss security considerations for YANG. RFC2578 simply says: This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet. Hope this helps, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com 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 Tue Nov 11 14:22: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 2207028C163; Tue, 11 Nov 2008 14:22:55 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69D328C167 for ; Tue, 11 Nov 2008 14:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.600, 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 zGY4-EtXlR6E for ; Tue, 11 Nov 2008 14:22:53 -0800 (PST) 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 4E52828C163 for ; Tue, 11 Nov 2008 14:22:53 -0800 (PST) Received: (qmail 17870 invoked from network); 11 Nov 2008 22:22:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.248.94 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 11 Nov 2008 22:22:52 -0000 X-YMail-OSG: lCYI6BQVM1kDiTL5L0WL6ZquR79Vm0C7sqgcxszu6KRFvJ7ExAcXxU8Gw0UNJcCKYI0RYqPcNQrdf_l60LNNsBNS.7FMvSs2nS8M5reEwmr1SrXx_XO58fjOyi6NKaHZrFTqCFc4S0I.HP8kfyqHx5mS X-Yahoo-Newman-Property: ymail-3 Message-ID: <491A05BB.6040908@netconfcentral.com> Date: Tue, 11 Nov 2008 14:22:51 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <20081111155927.GA10786@elstar.local> <4919B40D.4000407@ericsson.com> <4919B9EC.7000406@netconfcentral.com> <20081111.221508.196131558.mbj@tail-f.com> In-Reply-To: <20081111.221508.196131558.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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: >> Balazs Lengyel wrote: >>> Hello, >>> Yes removal leads to an error, as the leafref constraint would be violated >>> (just as for todays keyref). >>> Error code could be: >>> error-tag: missing-element (if we are allowed to mean "missing in the >>> datastore") >>> error-app-tag: referenced-data-can-not-be-removed >>> or >>> error-tag: operation-failed >>> error-app-tag: referenced-data-can-not-be-removed >>> >> This is too complicated on the agent, and does not fit >> with current practice. If an ATM line card gets pulled, >> and the agent is designed to remove the ATM data model >> with the read-only table in it, then this CLR is going >> to get in the way. > > Things gets too complicated if we allow config leafrefs with > "require-instance true" to point to non-config leafs. If config > points to config with "require-instance true", then it is just a > normal validation rule to handle at commit time. > >> There is a significant agent resource increase incurred >> in order to replicate all of the config, >> not just the 'config true' nodes. Are we sure there isn't >> a better way to handle these corner cases? > > I think the following rule is simple to understand , easy to > implement, and does not break the invariant that running MUST always > be valid. > > A config leafref with require-instance true MUST NOT > point to a non-config leaf. > OK > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 11 23:16: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 088ED3A682B; Tue, 11 Nov 2008 23:16:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E104B3A681D for ; Tue, 11 Nov 2008 23:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, 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 Mbad31fhhr3k for ; Tue, 11 Nov 2008 23:16:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1BBDB3A67B3 for ; Tue, 11 Nov 2008 23:16:28 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8CCB776C507; Wed, 12 Nov 2008 08:16:27 +0100 (CET) Date: Wed, 12 Nov 2008 08:16:27 +0100 (CET) Message-Id: <20081112.081627.173464632.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20081111155927.GA10786@elstar.local> References: <20081111.085732.75907088.mbj@tail-f.com> <491999B9.3090908@ericsson.com> <20081111155927.GA10786@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] keyref CLRs X-BeenThere: netmod@ietf.org 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 Tue, Nov 11, 2008 at 03:42:01PM +0100, Balazs Lengyel wrote: > > > Someone had earlier the proposed: > > > > --------------------- > > leafref foo { > > path ... > > strict true/false; > > } [...] > What does "must also exist" mean? Does this imply that any attempt to > remove ... fails? And if yes, which error can be expected if an > application tries to remove ...? This is how keyref works currently. The reference is always enforced. The same effect would be achieved by setting "require-instance" (or "strict") to "true". In the YANG spec there is no special error message defined. In our code (both client and server side) we use the generic "operation-failed" with special error-info: ... ... I'm all for putting detailed info in the errors - this means that the manager application can give much better help to the user when things go wrong. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 12 02:07: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 A0D483A6930; Wed, 12 Nov 2008 02:07:29 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6972A3A699E for ; Wed, 12 Nov 2008 02:07:29 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAC7lxwq4lrw for ; Wed, 12 Nov 2008 02:07:28 -0800 (PST) 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 B559F3A6930 for ; Wed, 12 Nov 2008 02:07:28 -0800 (PST) Received: (qmail 21883 invoked from network); 12 Nov 2008 10:07:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.248.94 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 12 Nov 2008 10:07:27 -0000 X-YMail-OSG: uXEzdtcVM1kQBu7fov2hsAkNrPyY0daWZRFRdnzLpVDp1iQdu9bccxBB3f5fMJFcNteucpJB4JbHSRt1wF4Ra.VBVwCmYa5o.IMafrZYyja3XWI.ZoARGnUCJ5C0BhJC7WdmkyW6DOppZqCGNnBFqhrM X-Yahoo-Newman-Property: ymail-3 Message-ID: <491AAADD.2000704@netconfcentral.com> Date: Wed, 12 Nov 2008 02:07:25 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <20081111155927.GA10786@elstar.local> <4919B40D.4000407@ericsson.com> <4919B9EC.7000406@netconfcentral.com> <20081111.221508.196131558.mbj@tail-f.com> <491A05BB.6040908@netconfcentral.com> In-Reply-To: <491A05BB.6040908@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Balazs Lengyel wrote: >>>> Hello, >>>> Yes removal leads to an error, as the leafref constraint would be >>>> violated >>>> (just as for todays keyref). >>>> Error code could be: >>>> error-tag: missing-element (if we are allowed to mean "missing in the >>>> datastore") >>>> error-app-tag: referenced-data-can-not-be-removed >>>> or >>>> error-tag: operation-failed >>>> error-app-tag: referenced-data-can-not-be-removed >>>> >>> This is too complicated on the agent, and does not fit >>> with current practice. If an ATM line card gets pulled, >>> and the agent is designed to remove the ATM data model >>> with the read-only table in it, then this CLR is going >>> to get in the way. >> >> Things gets too complicated if we allow config leafrefs with >> "require-instance true" to point to non-config leafs. If config >> points to config with "require-instance true", then it is just a >> normal validation rule to handle at commit time. >> >>> There is a significant agent resource increase incurred >>> in order to replicate all of the config, >>> not just the 'config true' nodes. Are we sure there isn't >>> a better way to handle these corner cases? >> >> I think the following rule is simple to understand , easy to >> implement, and does not break the invariant that running MUST always >> be valid. >> >> A config leafref with require-instance true MUST NOT >> point to a non-config leaf. >> > > OK > almost OK... The NETCONF protocol does not actually support the concept on non-config nodes in the . There is only a operation (and no operation) for this target database. Pretending that non-config nodes exist for the purpose of must, when, and keyref expressions, but you can never actually see them -- is a hack. Once the starts to differ significantly from the config, there is no way to tell what non-config nodes are really supposed to be present anyway. This is a fragile hack that isn't going to work in the long run. >> >> /martin >> >> >> > > Andy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 12 02: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 CFC733A67AE; Wed, 12 Nov 2008 02:23:43 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18663A6930 for ; Wed, 12 Nov 2008 02:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.465, 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 YkSy2loDiJE2 for ; Wed, 12 Nov 2008 02:23:42 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E31C33A67AE for ; Wed, 12 Nov 2008 02:23:41 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 91C2876C506; Wed, 12 Nov 2008 11:23:41 +0100 (CET) Date: Wed, 12 Nov 2008 11:23:39 +0100 (CET) Message-Id: <20081112.112339.54714676.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <491AAADD.2000704@netconfcentral.com> References: <20081111.221508.196131558.mbj@tail-f.com> <491A05BB.6040908@netconfcentral.com> <491AAADD.2000704@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] keyref CLRs X-BeenThere: netmod@ietf.org 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 the following rule is simple to understand , easy to > >> implement, and does not break the invariant that running MUST always > >> be valid. > >> > >> A config leafref with require-instance true MUST NOT > >> point to a non-config leaf. > >> > > OK > > > > almost OK... > > Pretending that non-config nodes exist for the purpose > of must, when, and keyref expressions, but you can never > actually see them -- is a hack. I don't get this. What do you mean by pretending? If a config points to non-config, no validation checks will be done. As yu wrote earlier, the only check will be the type check. I don't understand what your conclusion is. Are you suggesting that we should keep keyref/leafref as is and NOT let config point to non-config? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 12 03:39: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 5AB453A6784; Wed, 12 Nov 2008 03:39:03 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06033A68CC for ; Wed, 12 Nov 2008 03:39:02 -0800 (PST) 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 CVnYkGYKj6Rv for ; Wed, 12 Nov 2008 03:39:01 -0800 (PST) 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 042E33A6784 for ; Wed, 12 Nov 2008 03:39:01 -0800 (PST) Received: (qmail 79776 invoked from network); 12 Nov 2008 11:39:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.248.94 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 12 Nov 2008 11:39:00 -0000 X-YMail-OSG: nIpbxI0VM1lg1jH38UL.NL2ntQXZAhZuxq_SRLKbW2DpswVWaIb79tn_DfAnRGOI6xgbGmCDJspCqyIo0aKo0IV8zAz3Ldp0TheNTPPpKBbGwTjm3t.adzNSpLg_h8h3mb86So1_Tnf0AfRzI43Cjrqd X-Yahoo-Newman-Property: ymail-3 Message-ID: <491AC051.8000100@netconfcentral.com> Date: Wed, 12 Nov 2008 03:38:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <20081111.221508.196131558.mbj@tail-f.com> <491A05BB.6040908@netconfcentral.com> <491AAADD.2000704@netconfcentral.com> <20081112.112339.54714676.mbj@tail-f.com> In-Reply-To: <20081112.112339.54714676.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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: >>>> I think the following rule is simple to understand , easy to >>>> implement, and does not break the invariant that running MUST always >>>> be valid. >>>> >>>> A config leafref with require-instance true MUST NOT >>>> point to a non-config leaf. >>>> >>> OK >>> >> almost OK... >> >> Pretending that non-config nodes exist for the purpose >> of must, when, and keyref expressions, but you can never >> actually see them -- is a hack. > > I don't get this. What do you mean by pretending? If a config > points to non-config, no validation checks will be done. As yu wrote > earlier, the only check will be the type check. > As the manager adds, deletes, and modifies nodes in the , there is no protocol support for examining the non-config contents of the . I don't like solutions that assume the agent implements exactly what the documentation says it will, therefore why bother retrieving the data, since the manager "knows" exactly what will happen. This is fragile. A manager needs to retrieve the actual config contents from the agent, and that is not possible if the cannot report the existence of non-config nodes. > I don't understand what your conclusion is. Are you suggesting that > we should keep keyref/leafref as is and NOT let config point to > non-config? > I want an operationally robust solution. I suspect there are more elegant and robust solutions than what YANG has so far, but I don't have any suggestions at this time. The notification content use-case can be solved more directly. The oddball SNMP table constructions can also be thought of as configuration that only the agent (or the CLI) can set. Perhaps the config T/F flag needs more work. The 'create-only' enum got dropped for example. IMO, the pointed-at SNMP stuff is really 'out-of-band-created' and not 'config false' at all. Perhaps we have not specified the problem correctly. > > /martin > > > Andy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 12 10:01: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 982FF28C105; Wed, 12 Nov 2008 10:01:02 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9495528C10A for ; Wed, 12 Nov 2008 10:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGM89KTTMsYW for ; Wed, 12 Nov 2008 10:01:00 -0800 (PST) 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 B9C8D28C105 for ; Wed, 12 Nov 2008 10:01:00 -0800 (PST) Received: (qmail 9820 invoked from network); 12 Nov 2008 18:01:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.248.94 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 12 Nov 2008 18:00:59 -0000 X-YMail-OSG: 4xIRjkIVM1lRaowGT_9d.pXV0Bn8nc42uao_gVv3jBtwSVhnfJcbvsl2U6n7EF8Ldxe8W5JkLRpbNN_YwBuqVrrBAZcZDtpTD5ZNdYL_oaJr66DJjmTzdUioDDQuza246JwHCIvVIaWLjVQYdA6k21Y0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <491B19D9.7090105@netconfcentral.com> Date: Wed, 12 Nov 2008 10:00:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <20081111.221508.196131558.mbj@tail-f.com> <491A05BB.6040908@netconfcentral.com> <491AAADD.2000704@netconfcentral.com> <20081112.112339.54714676.mbj@tail-f.com> In-Reply-To: <20081112.112339.54714676.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref CLRs X-BeenThere: netmod@ietf.org 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: >>>> I think the following rule is simple to understand , easy to >>>> implement, and does not break the invariant that running MUST always >>>> be valid. >>>> >>>> A config leafref with require-instance true MUST NOT >>>> point to a non-config leaf. >>>> >>> OK >>> >> almost OK... >> >> Pretending that non-config nodes exist for the purpose >> of must, when, and keyref expressions, but you can never >> actually see them -- is a hack. > > I don't get this. What do you mean by pretending? If a config > points to non-config, no validation checks will be done. As yu wrote > earlier, the only check will be the type check. > > I don't understand what your conclusion is. Are you suggesting that > we should keep keyref/leafref as is and NOT let config point to > non-config? > > I'm starting to think the rule about a config leafref cannot point at a non-config leaf is correct. The classification of config as true/false is the part that may not be correct. Perhaps the original model used in the inverse IF stack table (and other MIBs) is not valid. It was a very common MIB practice to define config objects read-only because (of course) the WG agrees there will never be any standard configuration in the future. So even though these objects should be writable configuration, they are defined as read-only, and just used to report the configuration. Perhaps an architectural decision (oh no!) is needed about the very concept of 'report-only' configuration. Just calling it state info is not good enough. Is this category ignored? Handled with existing rules? Handled with special rules? Do some SMIv2 'features' need to be banned, and converted to the 'NETCONF' view of config, or simply not translatable to NETMOD at all? I like the concepts of config=true means a manager can edit it and do all the other NETCONF operations, and config=false means the manager cannot do any of the 'write' operations to it. There should only be config=false nodes in the database. > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 13 04: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 53ED33A681D; Thu, 13 Nov 2008 04:50:22 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55E13A6944 for ; Thu, 13 Nov 2008 04:50:20 -0800 (PST) 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=[AWL=0.600, 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 QPY0uIOph8jE for ; Thu, 13 Nov 2008 04:50:20 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E93433A681D for ; Thu, 13 Nov 2008 04:50:19 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 26C2020F27 for ; Thu, 13 Nov 2008 13:50:19 +0100 (CET) X-AuditID: c1b4fb3c-af0d0bb0000015b5-5a-491c228b4d1f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0734120CD5 for ; Thu, 13 Nov 2008 13:50:19 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 13:50:18 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 13:50:18 +0100 Message-ID: <491C228A.3050304@ericsson.com> Date: Thu, 13 Nov 2008 13:50:18 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 13 Nov 2008 12:50:18.0859 (UTC) FILETIME=[61FFB3B0:01C9458E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Can a key value be changed? X-BeenThere: netmod@ietf.org 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, Is it possible to change a key value? IMHO No. How would one address the key leaf in edit config? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 13 05:32: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 ABCA33A68E6; Thu, 13 Nov 2008 05:32:08 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB183A6904 for ; Thu, 13 Nov 2008 05:32:07 -0800 (PST) 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 gxl0twbvWBnE for ; Thu, 13 Nov 2008 05:32:06 -0800 (PST) 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 DF9093A68E6 for ; Thu, 13 Nov 2008 05:32:06 -0800 (PST) Received: (qmail 4388 invoked from network); 13 Nov 2008 13:32:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.248.94 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 13 Nov 2008 13:32:06 -0000 X-YMail-OSG: eBc4HfQVM1nRIYa.A2ldADPoAZdqRpMLBnlqwzcZapyvn36gozj8XLQXPMkBN8HWR3y37fy.CAgNTvKm41dxM4PcTD4rprAwgujpZsqgjp9_YxIqNjkacvdsXEs69kHxerE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <491C2C53.1060108@netconfcentral.com> Date: Thu, 13 Nov 2008 05:32:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <491C228A.3050304@ericsson.com> In-Reply-To: <491C228A.3050304@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] Can a key value be changed? X-BeenThere: netmod@ietf.org 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, > Is it possible to change a key value? IMHO No. > How would one address the key leaf in edit config? You cannot say "/interface[name='foo']/name = bar" in XML. You cannot rename entries using the NETCONF protocol. It only supports delete and re-create. > Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 13 06:43: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 1B4193A68E6; Thu, 13 Nov 2008 06:43:56 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821323A6997 for ; Thu, 13 Nov 2008 06:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.400, 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 rDuWSw1fpcWg for ; Thu, 13 Nov 2008 06:43:53 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B78C93A68E6 for ; Thu, 13 Nov 2008 06:43:53 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B763E20209 for ; Thu, 13 Nov 2008 15:43:52 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-cd-491c3d251651 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AC6332045F for ; Thu, 13 Nov 2008 15:43:50 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 15:43:16 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 15:43:16 +0100 Message-ID: <491C3C81.1080606@ericsson.com> Date: Thu, 13 Nov 2008 15:41:05 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 13 Nov 2008 14:43:16.0144 (UTC) FILETIME=[29935300:01C9459E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Write-once leafs X-BeenThere: netmod@ietf.org 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 our models we have a quite a lot of configuration data that can be written only once typically when you would create the enclosing list entry. afterwards it is read-only. How can you model this in YANG? I see the need for a new "write-once " statement in YANG. Opinions? Martin, can you include this in your Friday presentation? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 13 06:49: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 CA1563A68AF; Thu, 13 Nov 2008 06:49:53 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099AE3A68E6 for ; Thu, 13 Nov 2008 06:49:53 -0800 (PST) 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 xlkEjZHbzWX9 for ; Thu, 13 Nov 2008 06:49:52 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id B13AD3A68AF for ; Thu, 13 Nov 2008 06:49:51 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSRw+jc+c6jJYDQX0RL8+k9JDL4UD87tx@postini.com; Thu, 13 Nov 2008 06:49:52 PST Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 06:48:20 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 06:48:20 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 06:48:19 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mADEmIM27490; Thu, 13 Nov 2008 06:48:19 -0800 (PST) (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 mADEhOsB007174; Thu, 13 Nov 2008 14:43:24 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811131443.mADEhOsB007174@idle.juniper.net> To: Andy Bierman In-reply-to: <491C2C53.1060108@netconfcentral.com> Date: Thu, 13 Nov 2008 09:43:24 -0500 From: Phil Shafer X-OriginalArrivalTime: 13 Nov 2008 14:48:19.0586 (UTC) FILETIME=[DE70E620:01C9459E] Cc: NETMOD Working Group Subject: Re: [netmod] Can a key value be changed? X-BeenThere: netmod@ietf.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: >You cannot say "/interface[name='foo']/name = bar" in XML. Well, in YANG, no, but in XML, sure: foo bar >You cannot rename entries using the NETCONF protocol. >It only supports delete and re-create. FWIW, we've supported this in JUNOS forever in both the JUNOScript and NETCONF APIs. http://www.juniper.net/techpubs/software/junos/junos92/junoscript-guide/rename.html IMHO delete and re-create won't cut it. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 13 06:59: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 DD9B83A6806; Thu, 13 Nov 2008 06:59:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217F53A6826 for ; Thu, 13 Nov 2008 06:59:15 -0800 (PST) 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 F+BGuzhLi-xq for ; Thu, 13 Nov 2008 06:59:14 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5095D3A6806 for ; Thu, 13 Nov 2008 06:59:14 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B4F672212B; Thu, 13 Nov 2008 15:59:13 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-08-491c40c17488 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 96CA52100D; Thu, 13 Nov 2008 15:59:13 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 15:59:13 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 15:59:12 +0100 Message-ID: <491C40C0.4020401@ericsson.com> Date: Thu, 13 Nov 2008 15:59:12 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200811131443.mADEhOsB007174@idle.juniper.net> In-Reply-To: <200811131443.mADEhOsB007174@idle.juniper.net> X-OriginalArrivalTime: 13 Nov 2008 14:59:12.0963 (UTC) FILETIME=[63E25130:01C945A0] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] Can a key value be changed? X-BeenThere: netmod@ietf.org 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: >> You cannot say "/interface[name='foo']/name = bar" in XML. > > Well, in YANG, no, but in XML, sure: > > > foo > bar > Could you provide the full edit-config because I don't get the idea. Won't the above replace the complete list entry? > >> You cannot rename entries using the NETCONF protocol. >> It only supports delete and re-create. > > FWIW, we've supported this in JUNOS forever in both the > JUNOScript and NETCONF APIs. > > http://www.juniper.net/techpubs/software/junos/junos92/junoscript-guide/rename.html But you use a proprietary rename attribute. Can the same be done in standard Netconf? > > IMHO delete and re-create won't cut it. > > Thanks, > Phil -- 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 Nov 13 07:02: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 03C053A6806; Thu, 13 Nov 2008 07:02:20 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BF03A6806 for ; Thu, 13 Nov 2008 07:02:19 -0800 (PST) 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 Nu-ReIuxLkuM for ; Thu, 13 Nov 2008 07:02:18 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9AF1D3A6826 for ; Thu, 13 Nov 2008 07:02:17 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSRxBeEsEMUXAG2L8SypEH7FS9qS6sYPa@postini.com; Thu, 13 Nov 2008 07:02:18 PST Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 07:02:10 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 07:02:09 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 07:02:09 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mADF28M34924; Thu, 13 Nov 2008 07:02:08 -0800 (PST) (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 mADEvEmh007467; Thu, 13 Nov 2008 14:57:14 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811131457.mADEvEmh007467@idle.juniper.net> To: Balazs Lengyel In-reply-to: <491C40C0.4020401@ericsson.com> Date: Thu, 13 Nov 2008 09:57:14 -0500 From: Phil Shafer X-OriginalArrivalTime: 13 Nov 2008 15:02:09.0596 (UTC) FILETIME=[CD2A5FC0:01C945A0] Cc: NETMOD Working Group Subject: Re: [netmod] Can a key value be changed? X-BeenThere: netmod@ietf.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: >But you use a proprietary rename attribute. Can the same be done in standard N >etconf? Yes, via proprietary data model operations. ;^)/2 NETCONF's lobotomy left it with very few operations. YANG fixes this somewhat (insert), so adding rename would be another nice-to-have feature. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Nov 14 13:06: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 53B203A68EC; Fri, 14 Nov 2008 13:06:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB803A6907 for ; Fri, 14 Nov 2008 13:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 zjcDenkp2m+z for ; Fri, 14 Nov 2008 13:06:40 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id AE5C13A68EC for ; Fri, 14 Nov 2008 13:06:40 -0800 (PST) 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 QAA27992 for ; Fri, 14 Nov 2008 16:06:39 -0500 (EST) 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 QAA27836 for ; Fri, 14 Nov 2008 16:06:39 -0500 (EST) Message-Id: <200811142106.QAA27836@adminfs.snmp.com> To: netmod@ietf.org Date: Fri, 14 Nov 2008 16:06:39 -0500 From: David Reid Subject: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.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 If I have 2 different augments in the same module, do the leaf identifiers have to be unique? Below is an example, where ChannelNumber is used twice. I don't think that is legal, but I'm not sure what rule tells me it is not. module if { namespace "http://example.com/schema/interfaces" prefix "if"; container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } } } augment "/if:interfaces/if:ifEntry" { when "if:ifType='ds0'"; leaf ChannelNumber { type ChannelNumber; } } augment "/if:interfaces/if:ifEntry" { when "if:ifDescr='xyz'"; leaf ChannelNumber { type ChannelNumber; } } } -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Nov 14 16:44: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 9C1DB3A6870; Fri, 14 Nov 2008 16:44:08 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D013A6870 for ; Fri, 14 Nov 2008 16:44:08 -0800 (PST) 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 Xj0gPKwPveeK for ; Fri, 14 Nov 2008 16:44:07 -0800 (PST) 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 D0E023A6AB1 for ; Fri, 14 Nov 2008 16:44:07 -0800 (PST) Received: (qmail 86915 invoked from network); 15 Nov 2008 00:44:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.129.168 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 15 Nov 2008 00:44:06 -0000 X-YMail-OSG: 6N1H86wVM1lbFFabw0BDpIGqkwD9ENaetGx9dEyS4I8SsPQdY9s9UmdPJ2MfepT77OpvukAcUjahJ.o_VmUNfXVDdmC3OVC63J0XYDWsXMrn5mk9cMphZL02Vv7VkNOOPgVMxFd5Wgjif4Xw.VmcQvYY X-Yahoo-Newman-Property: ymail-3 Message-ID: <491E1B54.3030301@netconfcentral.com> Date: Fri, 14 Nov 2008 16:44:04 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: David Reid References: <200811142106.QAA27836@adminfs.snmp.com> In-Reply-To: <200811142106.QAA27836@adminfs.snmp.com> Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org 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 Reid wrote: > If I have 2 different augments in the same module, do the leaf identifiers > have to be unique? Below is an example, where ChannelNumber is used twice. > I don't think that is legal, but I'm not sure what rule tells me it is not. > good question. It applies to any usage of thew 'when' statement, not just augment. IMO, no -- otherwise you can end up with an invalid schema based on the value of arbitrary leaf value. All QName siblings need to be unique, regardless of when and if-feature values. Andy > module if { > namespace "http://example.com/schema/interfaces" > prefix "if"; > > container interfaces { > list ifEntry { > key "ifIndex"; > > leaf ifIndex { type uint32; } > leaf ifDescr { type string; } > leaf ifType { type iana:IfType; } > leaf ifMtu { type int32; } > } > } > > augment "/if:interfaces/if:ifEntry" { > when "if:ifType='ds0'"; > leaf ChannelNumber { > type ChannelNumber; > } > } > > augment "/if:interfaces/if:ifEntry" { > when "if:ifDescr='xyz'"; > leaf ChannelNumber { > type ChannelNumber; > } > } > } > > -David Reid > _______________________________________________ > 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 Nov 16 07:53: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 AD97F3A6783; Sun, 16 Nov 2008 07:53:38 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F35D3A681D for ; Sun, 16 Nov 2008 07:53:37 -0800 (PST) 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 osVzqpJVNHZs for ; Sun, 16 Nov 2008 07:53:37 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D49113A6783 for ; Sun, 16 Nov 2008 07:53:36 -0800 (PST) Received: from localhost (unknown [12.104.246.2]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F21876C310; Sun, 16 Nov 2008 16:53:32 +0100 (CET) Date: Sun, 16 Nov 2008 09:53:24 -0600 (CST) Message-Id: <20081116.095324.194469202.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200811142106.QAA27836@adminfs.snmp.com> References: <200811142106.QAA27836@adminfs.snmp.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] duplicate leaf names in augments X-BeenThere: netmod@ietf.org 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 Reid wrote: > If I have 2 different augments in the same module, do the leaf identifiers > have to be unique? Below is an example, where ChannelNumber is used twice. > I don't think that is legal, but I'm not sure what rule tells me it is not. You're right that it is not supposed to be legal and also that some text is missing. I think we need a new rule in 6.2.1. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 20 14:57: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 031FB3A6984; Thu, 20 Nov 2008 14:57:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA19F3A6984 for ; Thu, 20 Nov 2008 14:57:37 -0800 (PST) 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 W2Xyh6GqZHmn for ; Thu, 20 Nov 2008 14:57:37 -0800 (PST) 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 F2D6C3A6A01 for ; Thu, 20 Nov 2008 14:57:36 -0800 (PST) Received: (qmail 93999 invoked from network); 20 Nov 2008 22:57:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 Nov 2008 22:57:34 -0000 X-YMail-OSG: z6tIfOkVM1kBUPyusqKeos90tje.aBPuXaq6.WYjtCQgTMwiA1ygRry9bKrNnz7NDN.wglb.TQCvlisZMH_OJ0w2fmoew3S6M0W_iJefO28gKLvh8F7WuimvcapvVL_XKnqTVa90L.ReT0Ql4ZKpVwPp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4925EB5C.7000201@andybierman.com> Date: Thu, 20 Nov 2008 14:57:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/mixed; boundary="------------090005070507010101070604" Subject: [netmod] simple example of XSD-based modular augments X-BeenThere: netmod@ietf.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. --------------090005070507010101070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This is how yangdump handles the modular augment problem. Can the same sort of hack be done in RelaxNG? Andy --------------090005070507010101070604 Content-Type: text/plain; name="test5.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test5.yang" module test5 { namespace "urn:ietf:params:xml:ns:yang:test5"; prefix "t5"; revision 2008-11-20 { description "Initial revision."; } container test5 { list a { key g1; leaf g1 { type string; } leaf g2 { type string; } } } } --------------090005070507010101070604 Content-Type: text/plain; name="test6.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test6.yang" module test6 { namespace "urn:ietf:params:xml:ns:yang:test6"; prefix "t6"; import test5 { prefix t5; } revision 2008-11-20 { description "Initial revision."; } augment /t5:test5/t5:a { leaf g3 { type int32; } } } --------------090005070507010101070604 Content-Type: text/xml; name="test5_2008-11-20.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test5_2008-11-20.xsd" Converted from YANG file 'test5.yang' by yangdump version 0.9.4 Module: test5 Version: 2008-11-20 /home/andy/modules/test5.yang 2008-11-20 Initial revision. true system --------------090005070507010101070604 Content-Type: text/xml; name="test6_2008-11-20.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test6_2008-11-20.xsd" Converted from YANG file 'test6.yang' by yangdump version 0.9.4 Module: test6 Version: 2008-11-20 /home/andy/modules/test6.yang 2008-11-20 Initial revision. --------------090005070507010101070604 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 --------------090005070507010101070604-- From netmod-bounces@ietf.org Thu Nov 20 15:16: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 88B693A6A2A; Thu, 20 Nov 2008 15:16:53 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C572C28C148 for ; Thu, 20 Nov 2008 15:16:52 -0800 (PST) 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 9rd0WmyOwjy4 for ; Thu, 20 Nov 2008 15:16:52 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E31F83A6A2A for ; Thu, 20 Nov 2008 15:16:51 -0800 (PST) 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 mAKNGlj26398 for ; Thu, 20 Nov 2008 23:16:48 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 18:16:16 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41755DAE3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Client-side conformance Thread-Index: AclLZf0MHe5Joi1xSS2LB7pBqWhBSw== From: "Sharon Chisholm" To: Subject: [netmod] Client-side 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 Hi I said I would raise this on the mailing list during the working group meeting. How do we specify client-side conformance in yang? I.e., how to a specify that the client must provide certain fields to create a data instances, for example. This is different from what fields the server-side must support to claim conformance. This has proved to be a critical thing to understand in CLI and I think it is important in NETCONF as well. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 20 15:23: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 D7A213A677D; Thu, 20 Nov 2008 15:23:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B5F3A6935 for ; Thu, 20 Nov 2008 15:23:15 -0800 (PST) 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 pzkUSX1NqzYG for ; Thu, 20 Nov 2008 15:23:15 -0800 (PST) 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 00E0F3A677D for ; Thu, 20 Nov 2008 15:23:14 -0800 (PST) Received: (qmail 45203 invoked from network); 20 Nov 2008 23:23:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 Nov 2008 23:23:12 -0000 X-YMail-OSG: fB4Slt4VM1n0a3qW0MTzy57H4PEssTpr550pxZfBHE8Uj3enMVKjTJ1RiwSRwWvLKbiIyaQFdJ3YgFgGIqvS.4qPNFs04FzQVIjWKphT9bzTkMwYiOrOALdKt6fDIdbmyg4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4925F15E.4020309@netconfcentral.com> Date: Thu, 20 Nov 2008 15:23:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41755DAE3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41755DAE3@zcarhxm2.corp.nortel.com> Cc: netmod@ietf.org Subject: Re: [netmod] Client-side 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 Sharon Chisholm wrote: > Hi > > I said I would raise this on the mailing list during the working group > meeting. > > How do we specify client-side conformance in yang? I.e., how to a > specify that the client must provide certain fields to create a data > instances, for example. This is different from what fields the > server-side must support to claim conformance. This has proved to be a > critical thing to understand in CLI and I think it is important in > NETCONF as well. > the YANG module describes what a valid configuration database (or RPC input) must contain. A CM application must make sure it configures all mandatory=true, obeys all must, unique clauses, min-elements, max-elements, etc. > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > __ Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 20 16:31: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 EA4433A6873; Thu, 20 Nov 2008 16:31:46 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189083A6898 for ; Thu, 20 Nov 2008 16:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 hrkPdt5y+x06 for ; Thu, 20 Nov 2008 16:31:45 -0800 (PST) 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 4F1E03A6873 for ; Thu, 20 Nov 2008 16:31:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220241600"; d="scan'208";a="151878163" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 20 Nov 2008 19:31:43 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 Nov 2008 19:31:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 01:31:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: David is replaced by David Thread-Index: AclLcIYWPdR4ya6QT2eHoeVRiF3pug== From: "Romascanu, Dan (Dan)" To: Cc: Ron Bonica , David B Harrington , David Kessens Subject: [netmod] David is replaced by David X-BeenThere: netmod@ietf.org 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 Harrington is focusing on some new and interesting work and decided to give up the position of co-chair of the NETMOD WG. David H. had a tremendous contribution in starting this WG and put it on the right track. Thanks, David H. David Kessens is replacing him, effective immediately after the IETF meeting is over. Thanks David K. for accepting this challenging position and good luck. Dan and Ron _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Nov 20 16:34: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 3C7E83A68BD; Thu, 20 Nov 2008 16:34:58 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8543A6935 for ; Thu, 20 Nov 2008 16:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsaFii99GRBs for ; Thu, 20 Nov 2008 16:34:56 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 37DB43A68BD for ; Thu, 20 Nov 2008 16:34:56 -0800 (PST) Received: from [130.129.78.155] (unknown [130.129.78.155]) by office2.cesnet.cz (Postfix) with ESMTP id 01A55D800C8 for ; Fri, 21 Nov 2008 01:34:52 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4925EB5C.7000201@andybierman.com> References: <4925EB5C.7000201@andybierman.com> Organization: CESNET Date: Thu, 20 Nov 2008 18:34:51 -0600 Message-Id: <1227227691.6414.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] simple example of XSD-based modular augments X-BeenThere: netmod@ietf.org 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 SGkgQW5keSwKCnNvIHRoaXMgbWVhbnMgbGVhdmluZyBhICJiYWNrZG9vciIgaW4gZXZlcnkgcG9z c2libGUgcGxhY2UsIHdoZXJlCmV4dGVybmFsIGF1Z21lbnQgY2FuIGJlIGFwcGxpZWQsIHJpZ2h0 PyBUaGlzIHdvdWxkIGJlIGluIHByaW5jaXBsZQpwb3NzaWJsZSBpbiBSRUxBWCBORywgdG9vLCBi dXQgSSB0aGluayBpdCBjb3VsZCBlYXNpbHkgYnJlYWsuIFF1ZXN0aW9uczoKCjEuIEluIFhTRCwg aG93IHRoZSB0d28gc2NoZW1hcyBnZXQgYXNzb2NpYXRlZCB0b2dldGhlciBpZiBib3RoIG1vZHVs ZXMKYXBwZWFyIGluIDxoZWxsbz4/IHRlc3Q1LnhzZCBieSBpdHNlbGYgaGFzIG5vIHBvaW50ZXIg dG8gdGVzdDYueHNkLgoKMi4gV291bGQgaXQgd29yayBpZiBhIHRoaXJkIG1vZHVsZSBhcHBsaWVz IGEgZGlmZmVyZW50IGF1Z21lbnQgdG8gdGhlCnNhbWUgcGxhY2U/CgpMYWRhCgpBbmR5IEJpZXJt YW4gcMOtxaFlIHYgxIx0IDIwLiAxMS4gMjAwOCB2IDE0OjU3IC0wODAwOgo+IEhpLAo+IAo+IFRo aXMgaXMgaG93IHlhbmdkdW1wIGhhbmRsZXMgdGhlIG1vZHVsYXIgYXVnbWVudCBwcm9ibGVtLgo+ IENhbiB0aGUgc2FtZSBzb3J0IG9mIGhhY2sgYmUgZG9uZSBpbiBSZWxheE5HPwo+IAo+IAo+IEFu ZHkKPiBQcm9zdMO9IHRleHRvdsO9IGRva3VtZW50IHDFmcOtbG9oYSAodGVzdDUueWFuZykKPiBt b2R1bGUgdGVzdDUgewo+IAo+ICAgICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzp0ZXN0NSI7Cj4gICAgIHByZWZpeCAidDUiOwo+IAo+ICAgICByZXZpc2lvbiAyMDA4LTEx LTIwIHsKPiAgICAgICAgIGRlc2NyaXB0aW9uICJJbml0aWFsIHJldmlzaW9uLiI7Cj4gICAgIH0K PiAKPiAgICAgY29udGFpbmVyIHRlc3Q1IHsKPiAgICAgICBsaXN0IGEgewo+ICAgICAgICAga2V5 IGcxOwo+ICAgICAgICAgbGVhZiBnMSB7IHR5cGUgc3RyaW5nOyB9Cj4gICAgICAgICBsZWFmIGcy IHsgdHlwZSBzdHJpbmc7IH0KPiAgICAgICB9Cj4gICAgfQo+IH0KPiBQcm9zdMO9IHRleHRvdsO9 IGRva3VtZW50IHDFmcOtbG9oYSAodGVzdDYueWFuZykKPiBtb2R1bGUgdGVzdDYgewo+IAo+ICAg ICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzp0ZXN0NiI7Cj4gICAgIHBy ZWZpeCAidDYiOwo+ICAgICBpbXBvcnQgdGVzdDUgeyBwcmVmaXggdDU7IH0KPiAKPiAgICAgcmV2 aXNpb24gMjAwOC0xMS0yMCB7Cj4gICAgICAgICBkZXNjcmlwdGlvbiAiSW5pdGlhbCByZXZpc2lv bi4iOwo+ICAgICB9Cj4gCj4gICAgIGF1Z21lbnQgL3Q1OnRlc3Q1L3Q1OmEgewo+ICAgICAgIGxl YWYgZzMgeyB0eXBlIGludDMyOyB9Cj4gICAgIH0KPiB9Cj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9k QGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK LS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Thu Nov 20 16:56: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 A695028C194; Thu, 20 Nov 2008 16:56:46 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582E028C1DF for ; Thu, 20 Nov 2008 16:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efNu-8NLVixz for ; Thu, 20 Nov 2008 16:56:44 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7ADFC28C1AF for ; Thu, 20 Nov 2008 16:56:44 -0800 (PST) Received: from [130.129.78.155] (unknown [130.129.78.155]) by office2.cesnet.cz (Postfix) with ESMTP id D7C13D800E8 for ; Fri, 21 Nov 2008 01:56:41 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Thu, 20 Nov 2008 18:56:40 -0600 Message-Id: <1227229000.6414.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] modularity X-BeenThere: netmod@ietf.org 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, section 4.2 in dsdl-map draft summarizes differences in modularity features between YANG and RELAX NG and explains why it is difficult to have the same modular structure in both, without any assumptions on what the individual modules contain. I am still not getting why it is such a big problem to compile an ad hoc schema from YANG modules every time it is needed. If an agent wants to run an XML validator with all the bloated libraries, a poor little Python interpreter should be a piece of cake. 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 Thu Nov 20 17:14: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 C31553A6A7D; Thu, 20 Nov 2008 17:14:36 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948763A6A48 for ; Thu, 20 Nov 2008 17:14:35 -0800 (PST) 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 rYXS+3SEti1c for ; Thu, 20 Nov 2008 17:14:34 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id C77153A6A35 for ; Thu, 20 Nov 2008 17:14:34 -0800 (PST) Received: (qmail 57983 invoked from network); 21 Nov 2008 01:14:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 21 Nov 2008 01:14:31 -0000 X-YMail-OSG: ughdDxAVM1mHl9PIzWRXzzWHLLOVOP3YgBZELBbajeD5NG30ZZbQirWnXyeqNcCDLqHf7lWXEF7fE1ann6Ods9S_0w4tUMhANcS_Oios_LJQNzW6FM8ECpm39wYkMRIWWYzMgIozt2QZiwK_7fa6GvDY X-Yahoo-Newman-Property: ymail-3 Message-ID: <49260B75.5020807@netconfcentral.com> Date: Thu, 20 Nov 2008 17:14:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <4925EB5C.7000201@andybierman.com> <1227227691.6414.18.camel@missotis> In-Reply-To: <1227227691.6414.18.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] simple example of XSD-based modular augments X-BeenThere: netmod@ietf.org 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+IEhpIEFuZHksCj4gCj4gc28gdGhpcyBtZWFucyBsZWF2 aW5nIGEgImJhY2tkb29yIiBpbiBldmVyeSBwb3NzaWJsZSBwbGFjZSwgd2hlcmUKPiBleHRlcm5h bCBhdWdtZW50IGNhbiBiZSBhcHBsaWVkLCByaWdodD8gVGhpcyB3b3VsZCBiZSBpbiBwcmluY2lw bGUKPiBwb3NzaWJsZSBpbiBSRUxBWCBORywgdG9vLCBidXQgSSB0aGluayBpdCBjb3VsZCBlYXNp bHkgYnJlYWsuIFF1ZXN0aW9uczoKPiAKPiAxLiBJbiBYU0QsIGhvdyB0aGUgdHdvIHNjaGVtYXMg Z2V0IGFzc29jaWF0ZWQgdG9nZXRoZXIgaWYgYm90aCBtb2R1bGVzCj4gYXBwZWFyIGluIDxoZWxs bz4/IHRlc3Q1LnhzZCBieSBpdHNlbGYgaGFzIG5vIHBvaW50ZXIgdG8gdGVzdDYueHNkLgo+IAoK dGhhdCB3b3VsZCBiZSBicm9rZW4uCnRlc3Q2IG11c3QgaW1wb3J0IHRlc3Q1IHRvIGFjY2VzcyB0 aGUgc3Vic3RpdHV0aW9uR3JvdXAgUU5hbWUuCgogRnJvbSB0NjoKCiAgPHhzOmVsZW1lbnQgbmFt ZT0iZzMiIHR5cGU9InhzOmludCIgbWluT2NjdXJzPSIwIgogICAgICAgc3Vic3RpdHV0aW9uR3Jv dXA9InQ1Ol9fLnRlc3Q1LmEuQV9fIi8+CiAgICAgICAgICAgICAgICAgICAgICAgICAgXl4KClRo aXMgd2lsbCBjcmVhdGUgYSAndDY6ZzMnIGVsZW1lbnQgaW4gdGhlICcvdDU6dGVzdDUvdDU6YScg bGlzdC4KCj4gMi4gV291bGQgaXQgd29yayBpZiBhIHRoaXJkIG1vZHVsZSBhcHBsaWVzIGEgZGlm ZmVyZW50IGF1Z21lbnQgdG8gdGhlCj4gc2FtZSBwbGFjZT8KPiAKCnllcy4gIHRoZXkgd2lsbCBl YWNoIGNyZWF0ZSBlbGVtZW50cyBpbiB0aGVpciBvd24gbmFtZXNwYWNlLAphcyBzdWJzdGl0dXRp b24gZWxlbWVudHMgZm9yIHRoZSB0YXJnZXQgb2YgdGhlIGF1Z21lbnQuCgoKPiBMYWRhCj4gCgpB bmR5CgoKPiBBbmR5IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDIwLiAxMS4gMjAwOCB2IDE0OjU3IC0w ODAwOgo+PiBIaSwKPj4KPj4gVGhpcyBpcyBob3cgeWFuZ2R1bXAgaGFuZGxlcyB0aGUgbW9kdWxh ciBhdWdtZW50IHByb2JsZW0uCj4+IENhbiB0aGUgc2FtZSBzb3J0IG9mIGhhY2sgYmUgZG9uZSBp biBSZWxheE5HPwo+Pgo+Pgo+PiBBbmR5Cj4+IFByb3N0w70gdGV4dG92w70gZG9rdW1lbnQgcMWZ w61sb2hhICh0ZXN0NS55YW5nKQo+PiBtb2R1bGUgdGVzdDUgewo+Pgo+PiAgICAgbmFtZXNwYWNl ICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6dGVzdDUiOwo+PiAgICAgcHJlZml4ICJ0NSI7 Cj4+Cj4+ICAgICByZXZpc2lvbiAyMDA4LTExLTIwIHsKPj4gICAgICAgICBkZXNjcmlwdGlvbiAi SW5pdGlhbCByZXZpc2lvbi4iOwo+PiAgICAgfQo+Pgo+PiAgICAgY29udGFpbmVyIHRlc3Q1IHsK Pj4gICAgICAgbGlzdCBhIHsKPj4gICAgICAgICBrZXkgZzE7Cj4+ICAgICAgICAgbGVhZiBnMSB7 IHR5cGUgc3RyaW5nOyB9Cj4+ICAgICAgICAgbGVhZiBnMiB7IHR5cGUgc3RyaW5nOyB9Cj4+ICAg ICAgIH0KPj4gICAgfQo+PiB9Cj4+IFByb3N0w70gdGV4dG92w70gZG9rdW1lbnQgcMWZw61sb2hh ICh0ZXN0Ni55YW5nKQo+PiBtb2R1bGUgdGVzdDYgewo+Pgo+PiAgICAgbmFtZXNwYWNlICJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6dGVzdDYiOwo+PiAgICAgcHJlZml4ICJ0NiI7Cj4+ICAg ICBpbXBvcnQgdGVzdDUgeyBwcmVmaXggdDU7IH0KPj4KPj4gICAgIHJldmlzaW9uIDIwMDgtMTEt MjAgewo+PiAgICAgICAgIGRlc2NyaXB0aW9uICJJbml0aWFsIHJldmlzaW9uLiI7Cj4+ICAgICB9 Cj4+Cj4+ICAgICBhdWdtZW50IC90NTp0ZXN0NS90NTphIHsKPj4gICAgICAgbGVhZiBnMyB7IHR5 cGUgaW50MzI7IH0KPj4gICAgIH0KPj4gfQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+IG5ldG1vZEBpZXRm Lm9yZwo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWls aW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri Nov 21 06:34: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 733173A679C; Fri, 21 Nov 2008 06:34:14 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48EE23A69F0 for ; Fri, 21 Nov 2008 06:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=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 l5wmZXFKGBcR for ; Fri, 21 Nov 2008 06:34:12 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 18E763A679C for ; Fri, 21 Nov 2008 06:34:12 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mALEY7G19088 for ; Fri, 21 Nov 2008 14:34:08 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 09:34:03 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41755DF1C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Overriding maxAccess Thread-Index: AclL5jM/6a2ZcidfTRmJk+353DdAAw== From: "Sharon Chisholm" To: Subject: [netmod] Overriding 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 Hi I may have raised back this on the list during the Dublin meeting, but here is another potential gaps in Yang that we identified during the DSDL work. Overriding maxAccess on config/non-config >From some hallways discussions, there is some interest in this. While we have the following defaults +---------------+-----------+--------------------------+ | Data Category | minAccess | maxAccess | +---------------+-----------+--------------------------+ | config | read | read,write,create,delete | | | | | | non-config | read | read | +---------------+-----------+--------------------------+ These can be overwritten with an option maxAccess attribute: true Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Nov 21 07:05: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 5DBE83A68D3; Fri, 21 Nov 2008 07:05:18 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73ADF3A69F5 for ; Fri, 21 Nov 2008 07:05:17 -0800 (PST) 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_45=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 8uYKCz34aMnm for ; Fri, 21 Nov 2008 07:05:16 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 869643A68D3 for ; Fri, 21 Nov 2008 07:05:16 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 30AA8223ED; Fri, 21 Nov 2008 16:05:14 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-5f-4926ce2a77b7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1341C2066D; Fri, 21 Nov 2008 16:05:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 16:05:13 +0100 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 16:05:12 +0100 Message-ID: <4926CE39.7000706@ericsson.com> Date: Fri, 21 Nov 2008 16:05:29 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41755DF1C@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41755DF1C@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 21 Nov 2008 15:05:12.0754 (UTC) FILETIME=[8DA41120:01C94BEA] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Overriding maxAccess X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com 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, We also have in the Ericsson modeling language config data that is read-only or create-only so it would be nice to see a feature like this fit into YANG. Balazs Sharon Chisholm wrote: > Hi > > I may have raised back this on the list during the Dublin meeting, but > here is another potential gaps in Yang that we identified during the > DSDL work. > > Overriding maxAccess on config/non-config > > From some hallways discussions, there is some interest in this. While we > have the following defaults > > +---------------+-----------+--------------------------+ > | Data Category | minAccess | maxAccess | > +---------------+-----------+--------------------------+ > | config | read | read,write,create,delete | > | | | | > | non-config | read | read | > +---------------+-----------+--------------------------+ > > These can be overwritten with an option maxAccess attribute: > > true > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 Nov 21 08:04: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 3C6E03A692A; Fri, 21 Nov 2008 08:04:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972373A692A for ; Fri, 21 Nov 2008 08:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 s0Q44E6PTGkg for ; Fri, 21 Nov 2008 08:04:28 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 903F43A6A10 for ; Fri, 21 Nov 2008 08:04:28 -0800 (PST) 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 mALG4Mq23003; Fri, 21 Nov 2008 16:04:23 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 11:04:02 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4175A4AF2@zcarhxm2.corp.nortel.com> In-Reply-To: <4925F15E.4020309@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Client-side conformance Thread-Index: AclLZvb7dWd5sij5Tm6CECh6E+gu8QAiMlVA References: <713043CE8B8E1348AF3C546DBE02C1B41755DAE3@zcarhxm2.corp.nortel.com> <4925F15E.4020309@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netmod@ietf.org Subject: Re: [netmod] Client-side 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 Hi This seems very complicated. Consider that I'm an operator or tool developer reading a Yam trying to decide what is required to create a new foo. I remember the nightmare of trying to create new notification receivers using those standard MIBs. It was a lot of trial and error to determine what was the minimum required to create this (it didn't help it was spread out across 5 tables, but anyways). The reasons I wanted minimum since I really only had 2 real values to set and felt it best if the device made up values for the other fields. Note that default values defined in the Schema also does not cover this since most default values won't be defined that way since they may change between implementations and releases. Hence the get with defaults work. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Thursday, November 20, 2008 6:23 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netmod@ietf.org Subject: Re: [netmod] Client-side conformance Sharon Chisholm wrote: > Hi > > I said I would raise this on the mailing list during the working group > meeting. > > How do we specify client-side conformance in yang? I.e., how to a > specify that the client must provide certain fields to create a data > instances, for example. This is different from what fields the > server-side must support to claim conformance. This has proved to be a > critical thing to understand in CLI and I think it is important in > NETCONF as well. > the YANG module describes what a valid configuration database (or RPC input) must contain. A CM application must make sure it configures all mandatory=true, obeys all must, unique clauses, min-elements, max-elements, etc. > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > __ Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Nov 21 08:10: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 301E43A692A; Fri, 21 Nov 2008 08:10:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38253A6933 for ; Fri, 21 Nov 2008 08:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.641 X-Spam-Level: X-Spam-Status: No, score=-5.641 tagged_above=-999 required=5 tests=[AWL=0.608, 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 OiET11YBFpMi for ; Fri, 21 Nov 2008 08:10:14 -0800 (PST) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id AE1853A692A for ; Fri, 21 Nov 2008 08:10:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 230983BF87 for ; Fri, 21 Nov 2008 17:10:11 +0100 (CET) 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 32271-01-47 for ; Fri, 21 Nov 2008 17:10:10 +0100 (CET) Received: from k2.local (unknown [130.129.95.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 67B3E3BE41 for ; Fri, 21 Nov 2008 17:10:09 +0100 (CET) From: Leif Johansson To: NETMOD Working Group Date: Fri, 21 Nov 2008 17:09:56 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200811211710.00343.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Subject: [netmod] review of yang 02 X-BeenThere: netmod@ietf.org 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="===============0168350423==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --===============0168350423== Content-Type: multipart/signed; boundary="nextPart28551687.gQlvkHu4Dr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart28551687.gQlvkHu4Dr Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have reviewed yang-02 focusing on the specification, not the language.=20 My observations below may seem not communicate the fact that I am=20 quite impressed with how far the yang community has come in such a relatively short time. The document shows definite signs of having=20 revised too many times and I think at this point a rewrite should be considered. I'll get back to why/how later on. The major "beef" I have with the text is that there is too much mix-up=20 between introductory and normative language. There are several layers of introductory text and I have to go to section 7 for the real normative text. Often the introduction is just a rewording of the specification that comes later in the document making it a redundant addition to the=20 document. The text needs a revision of all RFC 2119 terms - There are several=20 examples where I suspect the normative upper-case version of a word=20 is actually implied. Another major problem is that there are several examples of undefined terms. For instance "node", "cardinality" and "root node". The problem defining a language (especially if you are trying to avoid being just anoth= er object oriented language where you can rely on common understanding of certain concepts) is that you have to be _extremely_ careful to keep the number of fundamental terms (stuff you don't define) as small as possible. There are some hints in the document that there may be a runtime/ compiletime model for yang but that is never spelled out. In fact this is part of a larger problem which also need work: There is=20 no discussion of the underlying conceptual model of yang; i.e where=20 does yang fit in among netconf clients and servers, managed entities, management data, management agents, management data models etc.=20 There is some introductory text around trees and such but for an outsider=20 it isn't clear what relationships trees bear to anything netconf cares abou= t. My suggestion is that the yang core document be divided into a clean minimal specification document where extreme care is taken not to=20 duplicate text and a separate information document which explains how to read the specification, the underlying assumptions, basic terminology, runtime/compiletime models and advise for implementers. Cheers Leif --nextPart28551687.gQlvkHu4Dr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJJt1Y8Jx8FtbMZncRAsGtAJ9D9nS+6tmBAZyT2tG6zeChtnd4MACgyX7f VMSwP8OSy6GreICOYd6CBGc= =94On -----END PGP SIGNATURE----- --nextPart28551687.gQlvkHu4Dr-- --===============0168350423== 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 --===============0168350423==-- From netmod-bounces@ietf.org Fri Nov 21 08:11: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 5CDC13A692A; Fri, 21 Nov 2008 08:11:19 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB71D3A692A for ; Fri, 21 Nov 2008 08:11:17 -0800 (PST) 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 4yYghlLBYe5q for ; Fri, 21 Nov 2008 08:11:16 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 93ECB3A679C for ; Fri, 21 Nov 2008 08:11:13 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSSbdk9SiuS56mUEUVt1PSDoVPJ8TTHkB@postini.com; Fri, 21 Nov 2008 08:11:15 PST Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 08:09:55 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 08:09:55 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 08:09:55 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mALG9sM92752; Fri, 21 Nov 2008 08:09:54 -0800 (PST) (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 mALG4qmU089936; Fri, 21 Nov 2008 16:04:52 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811211604.mALG4qmU089936@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1227229000.6414.38.camel@missotis> Date: Fri, 21 Nov 2008 11:04:52 -0500 From: Phil Shafer X-OriginalArrivalTime: 21 Nov 2008 16:09:55.0261 (UTC) FILETIME=[97CB9ED0:01C94BF3] Cc: NETMOD Working Group Subject: Re: [netmod] modularity X-BeenThere: netmod@ietf.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: >section 4.2 in dsdl-map draft summarizes differences in modularity >features between YANG and RELAX NG and explains why it is difficult to >have the same modular structure in both, without any assumptions on what >the individual modules contain. You can map the YANG module into two dsdl files, one which needs to be included with a namespace and one which does not. >I am still not getting why it is such a big problem to compile an ad hoc >schema from YANG modules every time it is needed. If an agent wants to >run an XML validator with all the bloated libraries, a poor little >Python interpreter should be a piece of cake. Compare this with a set of C files that belong in a library. You don't want to recompile all the files in libc everytime you want to compile your "hello world" program. We should be able to find a way to do the mapping once and reuse the generated files, even if we need to resort to building a small "driver" dsdl file to include the dsdl files generated by the mapping process. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Nov 21 08: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 0A8113A679C; Fri, 21 Nov 2008 08:16:14 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAD43A6851 for ; Fri, 21 Nov 2008 08:16:13 -0800 (PST) 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 XJJ3LRyCuP3j for ; Fri, 21 Nov 2008 08:16:12 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3B3403A679C for ; Fri, 21 Nov 2008 08:16:11 -0800 (PST) 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 mALGFfq25484; Fri, 21 Nov 2008 16:15:41 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 11:15:36 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4175A4B58@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4175A4AF2@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Client-side conformance Thread-Index: AclLZvb7dWd5sij5Tm6CECh6E+gu8QAiMlVAAAEl1aA= References: <713043CE8B8E1348AF3C546DBE02C1B41755DAE3@zcarhxm2.corp.nortel.com><4925F15E.4020309@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B4175A4AF2@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netmod@ietf.org Subject: Re: [netmod] Client-side 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 Hi Isn't this the assigned-by that Martin is currently talking about? Sharon -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Friday, November 21, 2008 11:04 AM To: Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] Client-side conformance Hi This seems very complicated. Consider that I'm an operator or tool developer reading a Yam trying to decide what is required to create a new foo. I remember the nightmare of trying to create new notification receivers using those standard MIBs. It was a lot of trial and error to determine what was the minimum required to create this (it didn't help it was spread out across 5 tables, but anyways). The reasons I wanted minimum since I really only had 2 real values to set and felt it best if the device made up values for the other fields. Note that default values defined in the Schema also does not cover this since most default values won't be defined that way since they may change between implementations and releases. Hence the get with defaults work. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Thursday, November 20, 2008 6:23 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netmod@ietf.org Subject: Re: [netmod] Client-side conformance Sharon Chisholm wrote: > Hi > > I said I would raise this on the mailing list during the working group > meeting. > > How do we specify client-side conformance in yang? I.e., how to a > specify that the client must provide certain fields to create a data > instances, for example. This is different from what fields the > server-side must support to claim conformance. This has proved to be a > critical thing to understand in CLI and I think it is important in > NETCONF as well. > the YANG module describes what a valid configuration database (or RPC input) must contain. A CM application must make sure it configures all mandatory=true, obeys all must, unique clauses, min-elements, max-elements, etc. > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > __ 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 Nov 21 12:12: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 30A6C3A67A7; Fri, 21 Nov 2008 12:12:10 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9518B3A67A7 for ; Fri, 21 Nov 2008 12:12:07 -0800 (PST) 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 ghwaXEu5aMZL for ; Fri, 21 Nov 2008 12:12:06 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8D46A3A688B for ; Fri, 21 Nov 2008 12:12:05 -0800 (PST) Received: from localhost (unknown [130.129.24.246]) by mail.tail-f.com (Postfix) with ESMTPSA id 72C7376C548; Fri, 21 Nov 2008 21:12:01 +0100 (CET) Date: Fri, 21 Nov 2008 14:11:59 -0600 (CST) Message-Id: <20081121.141159.177214175.mbj@tail-f.com> To: leifj@it.su.se From: Martin Bjorklund In-Reply-To: <200811211710.00343.leifj@it.su.se> References: <200811211710.00343.leifj@it.su.se> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] review of yang 02 X-BeenThere: netmod@ietf.org 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 Leif, Thanks for your comments! Leif Johansson wrote: > The major "beef" I have with the text is that there is too much mix-up > between introductory and normative language. There are several layers > of introductory text and I have to go to section 7 for the real normative > text. Often the introduction is just a rewording of the specification that > comes later in the document making it a redundant addition to the > document. In fact, it's just section 4, YANG Overview, that is introductory. We will add some text to try to communicate the intention better. > The text needs a revision of all RFC 2119 terms - There are several > examples where I suspect the normative upper-case version of a word > is actually implied. Agreed. We will go through occurences of these terms for the next revision. > Another major problem is that there are several examples of undefined > terms. For instance "node", "cardinality" and "root node". Ok. If anyone has a proposal for definitions of the terms 'node', 'tree', etc, please let me know. > There are some hints in the document that there may be a runtime/ > compiletime model for yang but that is never spelled out. If you refer to things like 'must' and 'when' constraints etc, we are adding text that describes when and how the different constraints are enforced. > In fact this is part of a larger problem which also need work: There is > no discussion of the underlying conceptual model of yang; i.e where > does yang fit in among netconf clients and servers, managed entities, > management data, management agents, management data models etc. This disussion is done in the NETMOD architecure document (which is not yet published as a WG document). > There is some introductory text around trees and such but for an outsider > it isn't clear what relationships trees bear to anything netconf cares about. Currently we say: YANG models the hierarchical organization of data as a tree in which each node has a name, and either a value or a set of child nodes. Do we need more text? > My suggestion is that the yang core document be divided into a clean > minimal specification document where extreme care is taken not to > duplicate text and a separate information document which explains how > to read the specification, the underlying assumptions, basic terminology, > runtime/compiletime models and advise for implementers. Ok. We have also heard from other readers of the spec that they like the introductory text, and they like having the examples in the text. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Nov 21 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 958B03A6814; Fri, 21 Nov 2008 12:30:54 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388433A6814 for ; Fri, 21 Nov 2008 12:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=0.456, 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 twS+4I+PrLIZ for ; Fri, 21 Nov 2008 12:30:52 -0800 (PST) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 071A23A67A7 for ; Fri, 21 Nov 2008 12:30:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 0D7403BE7E; Fri, 21 Nov 2008 21:30:49 +0100 (CET) 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 13300-03-12; Fri, 21 Nov 2008 21:30:48 +0100 (CET) Received: from k2.local (unknown [130.129.95.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 445AA3BE5B; Fri, 21 Nov 2008 21:30:48 +0100 (CET) From: Leif Johansson To: Martin Bjorklund Date: Fri, 21 Nov 2008 21:30:45 +0100 User-Agent: KMail/1.9.10 References: <200811211710.00343.leifj@it.su.se> <20081121.141159.177214175.mbj@tail-f.com> In-Reply-To: <20081121.141159.177214175.mbj@tail-f.com> MIME-Version: 1.0 Message-Id: <200811212130.45239.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: netmod@ietf.org Subject: Re: [netmod] review of yang 02 X-BeenThere: netmod@ietf.org 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="===============1139440363==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --===============1139440363== Content-Type: multipart/signed; boundary="nextPart1242136.g4mpOtHXek"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1242136.g4mpOtHXek Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 21 November 2008 21:11:59 Martin Bjorklund wrote: > Hi Leif, > > Thanks for your comments! > > Leif Johansson wrote: > > The major "beef" I have with the text is that there is too much mix-up > > between introductory and normative language. There are several layers > > of introductory text and I have to go to section 7 for the real normati= ve > > text. Often the introduction is just a rewording of the specification > > that comes later in the document making it a redundant addition to the > > document. > > In fact, it's just section 4, YANG Overview, that is introductory. > We will add some text to try to communicate the intention better. > > > The text needs a revision of all RFC 2119 terms - There are several > > examples where I suspect the normative upper-case version of a word > > is actually implied. > > Agreed. We will go through occurences of these terms for the next > revision. > > > Another major problem is that there are several examples of undefined > > terms. For instance "node", "cardinality" and "root node". > > Ok. If anyone has a proposal for definitions of the terms 'node', > 'tree', etc, please let me know. > They need definitions in the context of the yang/netconf/netmod ! > > There are some hints in the document that there may be a runtime/ > > compiletime model for yang but that is never spelled out. > > If you refer to things like 'must' and 'when' constraints etc, we are > adding text that describes when and how the different constraints are > enforced. I don't understand that statement. > > > In fact this is part of a larger problem which also need work: There is > > no discussion of the underlying conceptual model of yang; i.e where > > does yang fit in among netconf clients and servers, managed entities, > > management data, management agents, management data models etc. > > This disussion is done in the NETMOD architecure document (which is > not yet published as a WG document). Good. > > > There is some introductory text around trees and such but for an outsid= er > > it isn't clear what relationships trees bear to anything netconf cares > > about. > > Currently we say: > > YANG models the hierarchical organization of data as a tree in which > each node has a name, and either a value or a set of child nodes. > > Do we need more text? I should say so. That is a definition of a tree which I think we all share.= =20 What I'm missing is what the role of trees is in netconf and netmod and in the models that underlie these protocols. Maybe this is the architecture document again ... > Ok. We have also heard from other readers of the spec that they like > the introductory text, and they like having the examples in the text. Right but i think the text needs to clearly separate introduction from=20 specification. Cheers Leif --nextPart1242136.g4mpOtHXek Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJJxp18Jx8FtbMZncRAitvAKC1cD99tcPPF2TOHcF39IKTfl0FVwCggrpC IUefVLbGKuPnYhkPWF3ELek= =PlMX -----END PGP SIGNATURE----- --nextPart1242136.g4mpOtHXek-- --===============1139440363== 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 --===============1139440363==-- From netmod-bounces@ietf.org Fri Nov 21 21:05: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 8BBE93A68E4; Fri, 21 Nov 2008 21:05:49 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B065E3A6AA3 for ; Fri, 21 Nov 2008 21:05:48 -0800 (PST) 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 BibhygMDQVH2 for ; Fri, 21 Nov 2008 21:05:47 -0800 (PST) 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 D92B03A68E4 for ; Fri, 21 Nov 2008 21:05:47 -0800 (PST) Received: (qmail 96925 invoked from network); 22 Nov 2008 05:05:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 22 Nov 2008 05:05:44 -0000 X-YMail-OSG: 74mqa3AVM1laLIVZ2AGileijx3Pn0J45W1tHkv7AlC1AiFxUsMtiUdwjdGvib967kUFQ5bLcyw4PgJgB7wWr3wWk7yK9FhrQyQIBx4B_ZUECKEmV2e7S.0AK.f9fJAFJ4wep5uOyVOoi51pVTsxA.gWv X-Yahoo-Newman-Property: ymail-3 Message-ID: <49279326.7070604@netconfcentral.com> Date: Fri, 21 Nov 2008 21:05:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <200811211710.00343.leifj@it.su.se> <20081121.141159.177214175.mbj@tail-f.com> In-Reply-To: <20081121.141159.177214175.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] review of yang 02 X-BeenThere: netmod@ietf.org 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 Leif, > > Thanks for your comments! > > Leif Johansson wrote: >> The major "beef" I have with the text is that there is too much mix-up >> between introductory and normative language. There are several layers >> of introductory text and I have to go to section 7 for the real normative >> text. Often the introduction is just a rewording of the specification that >> comes later in the document making it a redundant addition to the >> document. > > In fact, it's just section 4, YANG Overview, that is introductory. > We will add some text to try to communicate the intention better. > >> The text needs a revision of all RFC 2119 terms - There are several >> examples where I suspect the normative upper-case version of a word >> is actually implied. > > Agreed. We will go through occurences of these terms for the next > revision. > >> Another major problem is that there are several examples of undefined >> terms. For instance "node", "cardinality" and "root node". > > Ok. If anyone has a proposal for definitions of the terms 'node', > 'tree', etc, please let me know. > Add to list: complete mapping of XPath concepts to YANG database. We must always distinguish schema nodes from database nodes and PDU nodes. E.g., choice and case are schema nodes that have names and take up a layer in the augment or refine target, but they do not exist in the config database or PDUs. Augment and uses nodes do not have names and do not show up anywhere (in XPath). The 'document root node' (/) for database XPath evaluation is mapped to the conceptual container. Lists and containers generate complex content elements. Leaf and leaf-list nodes generate simple content elements. There are no comment, processing-instruction, or attribute nodes in a YANG database. >> There are some hints in the document that there may be a runtime/ >> compiletime model for yang but that is never spelled out. > > If you refer to things like 'must' and 'when' constraints etc, we are > adding text that describes when and how the different constraints are > enforced. > >> In fact this is part of a larger problem which also need work: There is >> no discussion of the underlying conceptual model of yang; i.e where >> does yang fit in among netconf clients and servers, managed entities, >> management data, management agents, management data models etc. > > This disussion is done in the NETMOD architecure document (which is > not yet published as a WG document). > >> There is some introductory text around trees and such but for an outsider >> it isn't clear what relationships trees bear to anything netconf cares about. > > Currently we say: > > YANG models the hierarchical organization of data as a tree in which > each node has a name, and either a value or a set of child nodes. > > Do we need more text? How about changing 'name' to 'QName' and borrowing the definition from XPath? Is there text in the draft that says all NETCONF (or is it just YANG?) content MUST use XML namespaces? And the NULL namespace MUST NOT be used (i.e., namespace ""; in a YANG file not allowed)? Is this a NETCONF 1.1 issue? > >> My suggestion is that the yang core document be divided into a clean >> minimal specification document where extreme care is taken not to >> duplicate text and a separate information document which explains how >> to read the specification, the underlying assumptions, basic terminology, >> runtime/compiletime models and advise for implementers. > > Ok. We have also heard from other readers of the spec that they like > the introductory text, and they like having the examples in the text. > I agree. IMO, learning XSD was harder because the details were spread out in 3 specs instead of 1. I prefer 1 YANG RFC. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 23 09:39: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 B24303A67B5; Sun, 23 Nov 2008 09:39:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0053A6912 for ; Sun, 23 Nov 2008 09:39:29 -0800 (PST) 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 NwEtDfiJwa0w for ; Sun, 23 Nov 2008 09:39:28 -0800 (PST) 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 744DC3A67B5 for ; Sun, 23 Nov 2008 09:39:28 -0800 (PST) Received: (qmail 839 invoked from network); 23 Nov 2008 17:39:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 23 Nov 2008 17:39:24 -0000 X-YMail-OSG: MZopIAoVM1lxOLW_JnzRY5GE1IQ40U9NpzDqlJhBdrXaUhdmQtzXwpFWj8xX1MPR3zOLVpgerFx86Nwo8evS0A5qa8pJcdZkFEmiRHjfzThiwISwCGGi5ctAjpNMs3YENa0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4929954A.6020004@netconfcentral.com> Date: Sun, 23 Nov 2008 09:39:22 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] features and capabilities X-BeenThere: netmod@ietf.org 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 is not clear at all in the YANG draft how NETCONF capabilities are managed. Actually, they are ignored completely and features are introduced instead. Yet NETCONF has already defined many capabilities for protocol behavior which may impact data model design, and none of them are visible in NETMOD. This leaf is not possible in YANG because capabilities are ignored: leaf rollback-scope { if-capability nc:rollback-on-error; description "Protection scope for edit-config rollback-on-error"; type enumeration { enum immediate; enum parent; enum root; enum namespace; } default parent; } Since module features can be imported into other modules for 'if-feature' statements, they are no longer a way of partitioning modules (as originally billed) but rather a complete duplication of capabilities, except in encoding. By changing the URI encoding in the element, NETMOD not only adds complexity to the NETCONF protocol exchange, it also removes functionality. The encoding 'foo-mod?features=a,b,c,d' does not provide any extensibility for features (a,b,c,d). This is the reason we use elements instead of attributes in NETMOD, and it is just as valid for capability URIs (as demonstrated by the features addition to the capability URI in the first place). By saving some bytes in 1 NETCONF PDU, the WG is giving up the ability (forever) to extend the feature advertisement. This seems rather shortsighted to me. Just like ignoring capabilities and inventing features instead. IMO, there should be a global substitution: * s/feature/capability * s/if-feature/if-capability * remove special capability encoding, just use This would: * allow modules to declare capabilities so they can be used in conditional schema definitions, including the standard capabilities such as 'validate' or 'startup'. * allow feature advertisements to include additional data, which could be vendor-defined or future standards * remove complexity and redundancy from the architecture Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 23 10:47: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 1C3873A67DB; Sun, 23 Nov 2008 10:47:13 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB003A690E for ; Sun, 23 Nov 2008 10:47:12 -0800 (PST) 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 9jy0BH5OICvI for ; Sun, 23 Nov 2008 10:47:11 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 7900E3A67DB for ; Sun, 23 Nov 2008 10:47:11 -0800 (PST) Received: (qmail 13006 invoked from network); 23 Nov 2008 18:47:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 23 Nov 2008 18:47:07 -0000 X-YMail-OSG: N7LLxCYVM1niAbZcDZTdjMhxsX1pL_fJhADF8u27ysEzHaeGqWx.sMoUi_zUF3xyrohgLxthk5_CJ28GuttTDt_MTk9A3dzLigL4BfeWEnRNNZAS1fvCZBIWl43O3Cmux80- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4929A52A.6070905@netconfcentral.com> Date: Sun, 23 Nov 2008 10:47:06 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] keyword rule X-BeenThere: netmod@ietf.org 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 do not think this ABNF rule on pg. 148 is used: keyword = [prefix ":"] identifier Maybe it was used with unknown-statement, but that got changed when we decided prefixes on extension keywords are not optional: unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" *unknown-statement "}") The 'keyword' rule should be removed since it contradicts the normative text and is not even used. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 23 13:03: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 280133A67D2; Sun, 23 Nov 2008 13:03:15 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45443A68E6 for ; Sun, 23 Nov 2008 13:03:14 -0800 (PST) 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 kKhKjcpGwEDl for ; Sun, 23 Nov 2008 13:03:14 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id AFE0E3A67D2 for ; Sun, 23 Nov 2008 13:03:13 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSSnFCy1pVvMiViPWWuPsvXfuUBsd2oMq@postini.com; Sun, 23 Nov 2008 13:03:12 PST Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Nov 2008 13:01:34 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Nov 2008 13:01:34 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Nov 2008 13:01:34 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mANL1XM68216; Sun, 23 Nov 2008 13:01:33 -0800 (PST) (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 mANKuNMW020600; Sun, 23 Nov 2008 20:56:24 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811232056.mANKuNMW020600@idle.juniper.net> To: Andy Bierman In-reply-to: <4929954A.6020004@netconfcentral.com> Date: Sun, 23 Nov 2008 15:56:23 -0500 From: Phil Shafer X-OriginalArrivalTime: 23 Nov 2008 21:01:34.0086 (UTC) FILETIME=[AABBEA60:01C94DAE] Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.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 not clear at all in the YANG draft how NETCONF capabilities >are managed. Actually, they are ignored completely and features >are introduced instead. Capabilites are discuseed in the draft. There's a one-to-one mapping between modules and capabilities. Features allow a more granular approach than capabilities. They are a mechanism for introducing hiearchy into the mix. IMHO if features were available during the NETCONF design, we would have used them for many of the feature-like capabilties in NETCONF's base operations. >IMO, there should be a global substitution: > * s/feature/capability > * s/if-feature/if-capability > * remove special capability encoding, just use Wasn't this suggested (and rejected) previously? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 23 13:57: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 879523A6967; Sun, 23 Nov 2008 13:57:35 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB853A69E0 for ; Sun, 23 Nov 2008 13:57:34 -0800 (PST) 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 uUU-EqkxdzjV for ; Sun, 23 Nov 2008 13:57:33 -0800 (PST) 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 ACB5D3A6967 for ; Sun, 23 Nov 2008 13:57:33 -0800 (PST) Received: (qmail 23107 invoked from network); 23 Nov 2008 21:57:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 23 Nov 2008 21:57:30 -0000 X-YMail-OSG: JyNLXNkVM1nRgfWR3fk5XFc0TrpbUE5bO1IXVFt6HcpHrCbvhkENR.XMNe0EzdiWKM58hhOkctsBj9_Qyb7iZ_72BFgOu5O9HOwnZDtWRabs5ZITNUwm.wXDJ_Swv6kEXVc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4929D1C8.2090000@netconfcentral.com> Date: Sun, 23 Nov 2008 13:57:28 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200811232056.mANKuNMW020600@idle.juniper.net> In-Reply-To: <200811232056.mANKuNMW020600@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] features and capabilities X-BeenThere: netmod@ietf.org 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 not clear at all in the YANG draft how NETCONF capabilities >> are managed. Actually, they are ignored completely and features >> are introduced instead. > > Capabilites are discuseed in the draft. There's a one-to-one mapping > between modules and capabilities. > But this ignores protocol and vendor capabilities completely. It leads to hacks like: feature rollback-on-error { description "This feature is enabled if the rollback-on-error capability in RFC 4741 is advertised."; } > Features allow a more granular approach than capabilities. They > are a mechanism for introducing hiearchy into the mix. IMHO if > features were available during the NETCONF design, we would have > used them for many of the feature-like capabilties in NETCONF's > base operations. > They are not more granular at all. There is a flat QName list of features that are exported to other modules like typedefs or objects. There is a trivial 2 level hierarchy provided, which duplicates the namespace:identifier hierarchy already supported. >> IMO, there should be a global substitution: >> * s/feature/capability >> * s/if-feature/if-capability >> * remove special capability encoding, just use > > Wasn't this suggested (and rejected) previously? > I don't know -- I will consider it closed then, but I don't think anything except redundancy has been added to the mix. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 24 01:49: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 8BA9B3A6B78; Mon, 24 Nov 2008 01:49:41 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8E43A6B97 for ; Mon, 24 Nov 2008 01:49:40 -0800 (PST) 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 nGo5QHG-apUx for ; Mon, 24 Nov 2008 01:49:39 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B9DF83A6B78 for ; Mon, 24 Nov 2008 01:49:39 -0800 (PST) Received: from [147.251.13.123] (dhcp13-123.ics.muni.cz [147.251.13.123]) by office2.cesnet.cz (Postfix) with ESMTP id CFE09D800CC; Mon, 24 Nov 2008 10:49:34 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200811211604.mALG4qmU089936@idle.juniper.net> References: <200811211604.mALG4qmU089936@idle.juniper.net> Organization: CESNET Date: Mon, 24 Nov 2008 10:49:34 +0100 Message-Id: <1227520174.6259.11.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] modularity X-BeenThere: netmod@ietf.org 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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgUMOhIDIxLiAxMS4gMjAwOCB2IDExOjA0IC0wNTAwOgoKPiA+ SSBhbSBzdGlsbCBub3QgZ2V0dGluZyB3aHkgaXQgaXMgc3VjaCBhIGJpZyBwcm9ibGVtIHRvIGNv bXBpbGUgYW4gYWQgaG9jCj4gPnNjaGVtYSBmcm9tIFlBTkcgbW9kdWxlcyBldmVyeSB0aW1lIGl0 IGlzIG5lZWRlZC4gSWYgYW4gYWdlbnQgd2FudHMgdG8KPiA+cnVuIGFuIFhNTCB2YWxpZGF0b3Ig d2l0aCBhbGwgdGhlIGJsb2F0ZWQgbGlicmFyaWVzLCBhIHBvb3IgbGl0dGxlCj4gPlB5dGhvbiBp bnRlcnByZXRlciBzaG91bGQgYmUgYSBwaWVjZSBvZiBjYWtlLgo+IAo+IENvbXBhcmUgdGhpcyB3 aXRoIGEgc2V0IG9mIEMgZmlsZXMgdGhhdCBiZWxvbmcgaW4gYSBsaWJyYXJ5LiAgWW91Cj4gZG9u J3Qgd2FudCB0byByZWNvbXBpbGUgYWxsIHRoZSBmaWxlcyBpbiBsaWJjIGV2ZXJ5dGltZSB5b3Ug d2FudAo+IHRvIGNvbXBpbGUgeW91ciAiaGVsbG8gd29ybGQiIHByb2dyYW0uICBXZSBzaG91bGQg YmUgYWJsZSB0byBmaW5kCgpUaGlzIGlzIHZlcnkgZGlmZmVyZW50LiBPdXIgY2FzZSBpcyBtb3Jl IGxpa2UgYSBzb3VyY2UgY29kZSB0cmFuc2xhdG9yCmJldHdlZW4gc2F5IFB5dGhvbiBhbmQgQy4g SWYgeW91IGhhdmUgYSBQeXRob24gYXBwbGljYXRpb24gZGl2aWRlZCBpbnRvCm1vZHVsZXMsIHlv dSBjYW5ub3QgaW4gZ2VuZXJhbCBleHBlY3QgdG8gYmUgYWJsZSB0byB0cmFuc2xhdGUgZWFjaApt b2R1bGUgc2VwYXJhdGVseSBhbmQgc3RpbGwgYmUgYWJsZSB0byBjb21waWxlIGFuZCBsaW5rIHRo ZW0gY29ycmVjdGx5CmluIEMgYmVjYXVzZSB0aGUgc2NvcGluZyBydWxlcyBhcmUgZGlmZmVyZW50 LCBpbiBQeXRob24geW91IGNhbgpzZWxlY3RpdmVseSBpbXBvcnQganVzdCBjZXJ0YWluIHN5bWJv bHMgZXRjLiBZb3UgY2FuIGluZGVlZCBoYXZlIGEKdXNlZnVsIG1vZHVsYXIgc3RydWN0dXJlIGlu IGJvdGggbGFuZ3VhZ2VzLCBpdCBpcyBob3dldmVyIG5vdCBpZGVudGljYWwuCgpMYWRhCgotLSAK TGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QK bmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kCg== From netmod-bounces@ietf.org Mon Nov 24 06:17: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 329DA3A683A; Mon, 24 Nov 2008 06:17:06 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2183A687D for ; Mon, 24 Nov 2008 06:17:04 -0800 (PST) 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 ZfAmXX88mc2L for ; Mon, 24 Nov 2008 06:17:03 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id AE9F53A683A for ; Mon, 24 Nov 2008 06:17:03 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSSq3XLkyiGDKjyK5sq26QILyz/myoPQ/@postini.com; Mon, 24 Nov 2008 06:17:02 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 24 Nov 2008 06:13:49 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 06:13:48 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 06:13:48 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 06:13:47 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAOEDkM64583; Mon, 24 Nov 2008 06:13:46 -0800 (PST) (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 mAOE8dHU027087; Mon, 24 Nov 2008 14:08:39 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811241408.mAOE8dHU027087@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1227520174.6259.11.camel@missotis> Date: Mon, 24 Nov 2008 09:08:39 -0500 From: Phil Shafer X-OriginalArrivalTime: 24 Nov 2008 14:13:47.0620 (UTC) FILETIME=[DDFF3A40:01C94E3E] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] modularity X-BeenThere: netmod@ietf.org 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 writes: >This is very different.... I guess my expectation is based on the ability to do this reasonably well in XSD. But if it just isn't possible, I'll stop whining and face reality. Bummer... Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 24 14:28: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 A0E0A3A682C; Mon, 24 Nov 2008 14:28:45 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D583A6A1A for ; Mon, 24 Nov 2008 14:28:44 -0800 (PST) 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 vAl74vyk+cut for ; Mon, 24 Nov 2008 14:28:43 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9DE293A682C for ; Mon, 24 Nov 2008 14:28:43 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id ED86D76C310; Mon, 24 Nov 2008 23:28:39 +0100 (CET) Date: Mon, 24 Nov 2008 23:28:29 +0100 (CET) Message-Id: <20081124.232829.62905623.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4929A52A.6070905@netconfcentral.com> References: <4929A52A.6070905@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] keyword rule X-BeenThere: netmod@ietf.org 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 do not think this ABNF rule on pg. 148 is used: > > keyword = [prefix ":"] identifier > > Maybe it was used with unknown-statement, but that > got changed when we decided prefixes on extension > keywords are not optional: > > unknown-statement = prefix ":" identifier [sep string] optsep > (";" / "{" *unknown-statement "}") > > > The 'keyword' rule should be removed since it contradicts > the normative text and is not even used. Removed. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Nov 24 14:39: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 A4CB83A6A1A; Mon, 24 Nov 2008 14:39:31 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F663A6A64 for ; Mon, 24 Nov 2008 14:39:30 -0800 (PST) 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 KUYcc38Q08EX for ; Mon, 24 Nov 2008 14:39:30 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 13B0D3A6A1A for ; Mon, 24 Nov 2008 14:39:30 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8774276C521; Mon, 24 Nov 2008 23:39:27 +0100 (CET) Date: Mon, 24 Nov 2008 23:39:27 +0100 (CET) Message-Id: <20081124.233927.146339301.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4175A4B58@zcarhxm2.corp.nortel.com> References: <4925F15E.4020309@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B4175A4AF2@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4175A4B58@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Client-side 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 "Sharon Chisholm" wrote: > Hi > > Isn't this the assigned-by that Martin is currently talking about? [...] > This seems very complicated. Consider that I'm an operator or tool > developer reading a Yam trying to decide what is required to create a > new foo. With assigned-by there are 3 cases: list foo { key "name"; leaf name { .. .} leaf a { ... } leaf b { mandatory true; ... } leaf c { assigned-by system; } } When a new 'foo' is created, the client knows that it MUST provide values for 'name' (since it is the key) and 'b' (since it is mandatory). 'a' is completely optional, it may or may not exist in the db. 'c' is assigned by the system if the client does not create it. There are some details to work out re. assigned-by, but I hope this is not a nightmare for the client. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 06:59: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 7AF7A28C190; Tue, 25 Nov 2008 06:59:23 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9E928C195 for ; Tue, 25 Nov 2008 06:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=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 G6fyAJgMcPes for ; Tue, 25 Nov 2008 06:59:21 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 157F928C190 for ; Tue, 25 Nov 2008 06:59:20 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DDD93D800EE for ; Tue, 25 Nov 2008 15:59:15 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4925EB5C.7000201@andybierman.com> References: <4925EB5C.7000201@andybierman.com> Content-Type: multipart/mixed; boundary="=-iHJ4TOsmf3QeqV8zG7qw" Organization: CESNET Date: Tue, 25 Nov 2008 15:59:15 +0100 Message-Id: <1227625156.6288.93.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] simple example of XSD-based modular augments X-BeenThere: netmod@ietf.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 --=-iHJ4TOsmf3QeqV8zG7qw Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, attached are two schemas that show how the modular augment could be handled in RELAX NG, based on Andy's test modules (also included). To use the combined schema, the following "driver" schema is needed: --------------------------------------------------- namespace ns1 = "urn:ietf:params:xml:ns:yang:test5" include "test5.rnc" inherit = ns1 include "test6.rnc" inherit = ns1 --------------------------------------------------- While it looks pretty simple, the following points are important to note: 1. The RELAX NG schema must be made completely flat, having contents of each non-leaf element defined as a separate pattern with a name that encodes the element's full path. 2. One difference from YANG that cannot be avoided is that the items in the "a" list can appear interleaved in XML, for example in the order "g1", "g3", "g2". 3. If test6.yang contained any data tree of its own, this tree would have to be mapped to a separate schema (file). Stuff augmenting every individual module must always be put in a separate schema. 4. Also, if there were any top-level groupings and typedefs that can be imported by another module, they would have to be put in yet another special schema with the "native" namespace of groupings' content removed so that it can inherit the namespace of the importing module. 5. "Internal" augments of imported groupings can be handled in the same way as for the external ones, using "de-namespaced" version of the imported schema (sse 4). Caveat 2 also applies here. 6. I still don't know how to handle refinements of imported groupings and multi-level derivation of modular types and tend to believe it is not possible. Cheers, Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --=-iHJ4TOsmf3QeqV8zG7qw Content-Disposition: attachment; filename=test5.rnc Content-Type: text/plain; name=test5.rnc; charset=UTF-8 Content-Transfer-Encoding: 7bit default namespace = "urn:ietf:params:xml:ns:yang:test5" namespace dc = "http://purl.org/dc/terms" namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" dc:issued [ "2008-11-20" ] dc:source [ "YANG module 'test5' (automatic translation)" ] start = __start-content __start-content = element test5 { test5-content } test5-content = [ nm:key = "g1" ] element a { test5__a-content }* test5__a-content = element g1 { xsd:string }, element g2 { xsd:string }? --=-iHJ4TOsmf3QeqV8zG7qw Content-Disposition: attachment; filename=test5.yang Content-Type: text/plain; name=test5.yang; charset=UTF-8 Content-Transfer-Encoding: 7bit module test5 { namespace "urn:ietf:params:xml:ns:yang:test5"; prefix "t5"; revision 2008-11-20 { description "Initial revision."; } container test5 { list a { key g1; leaf g1 { type string; } leaf g2 { type string; } } } } --=-iHJ4TOsmf3QeqV8zG7qw Content-Disposition: attachment; filename=test6.yang Content-Type: text/plain; name=test6.yang; charset=UTF-8 Content-Transfer-Encoding: 7bit module test6 { namespace "urn:ietf:params:xml:ns:yang:test6"; prefix "t6"; import test5 { prefix t5; } revision 2008-11-20 { description "Initial revision."; } augment /t5:test5/t5:a { leaf g3 { type int32; } } } --=-iHJ4TOsmf3QeqV8zG7qw Content-Disposition: attachment; filename=test6-augment-test5.rnc Content-Type: text/plain; name=test6-augment-test5.rnc; charset=UTF-8 Content-Transfer-Encoding: 7bit default namespace = "urn:ietf:params:xml:ns:yang:test6" test5__a-content &= element g3 { xsd:int }? --=-iHJ4TOsmf3QeqV8zG7qw 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 --=-iHJ4TOsmf3QeqV8zG7qw-- From netmod-bounces@ietf.org Tue Nov 25 07:15: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 461F328C1A8; Tue, 25 Nov 2008 07:15:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457AB28C1AD for ; Tue, 25 Nov 2008 07:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.157 X-Spam-Level: * X-Spam-Status: No, score=1.157 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 vhi6bjBaEwle for ; Tue, 25 Nov 2008 07:14:58 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 83F0528C1A8 for ; Tue, 25 Nov 2008 07:14:58 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 3C87BD800EE for ; Tue, 25 Nov 2008 16:14:56 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <1227625156.6288.93.camel@missotis> References: <4925EB5C.7000201@andybierman.com> <1227625156.6288.93.camel@missotis> Organization: CESNET Date: Tue, 25 Nov 2008 16:14:56 +0100 Message-Id: <1227626096.6288.99.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] simple example of XSD-based modular augments X-BeenThere: netmod@ietf.org 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 TGFkaXNsYXYgTGhvdGthIHDDrcWhZSB2IMOadCAyNS4gMTEuIDIwMDggdiAxNTo1OSArMDEwMDoK PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBu YW1lc3BhY2UgbnMxID0gInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzp0ZXN0NSIKPiAKPiBp bmNsdWRlICJ0ZXN0NS5ybmMiIGluaGVyaXQgPSBuczEKPiBpbmNsdWRlICJ0ZXN0Ni5ybmMiIGlu aGVyaXQgPSBuczEKClNvcnJ5LCB0aGlzIGxhc3QgbGluZSBzaG91bGQgYmUgCgppbmNsdWRlICJ0 ZXN0Ni1hdWdtZW50LXRlc3Q1LnJuYyIgaW5oZXJpdCA9IG5zMQoKTGFkYQoKPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCi0tIApMYWRpc2xhdiBM aG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Tue Nov 25 08:29: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 6086A28C0E5; Tue, 25 Nov 2008 08:29:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7174928C181 for ; Tue, 25 Nov 2008 08:29:33 -0800 (PST) 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 QCfgvd9KVE8A for ; Tue, 25 Nov 2008 08:29:32 -0800 (PST) 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 B81BD28C0E5 for ; Tue, 25 Nov 2008 08:29:32 -0800 (PST) Received: (qmail 59268 invoked from network); 25 Nov 2008 16:29:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 25 Nov 2008 16:29:27 -0000 X-YMail-OSG: 7ilaIVgVM1lFH8owvPm1VxJ7wUI61zUEOrRGgRGuNGWpe29avPu2V3tc5h0tmwEUwZZL8amiqxa0icOqFts060E_nvlMmKXifVp.6HPcyl77B7QIGco7jA1zuqYGhm7Qgt8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492C27E5.3040200@netconfcentral.com> Date: Tue, 25 Nov 2008 08:29:25 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <200811211604.mALG4qmU089936@idle.juniper.net> <1227520174.6259.11.camel@missotis> In-Reply-To: <1227520174.6259.11.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] modularity X-BeenThere: netmod@ietf.org 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+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IFDDoSAyMS4gMTEu IDIwMDggdiAxMTowNCAtMDUwMDoKPiAKPj4+IEkgYW0gc3RpbGwgbm90IGdldHRpbmcgd2h5IGl0 IGlzIHN1Y2ggYSBiaWcgcHJvYmxlbSB0byBjb21waWxlIGFuIGFkIGhvYwo+Pj4gc2NoZW1hIGZy b20gWUFORyBtb2R1bGVzIGV2ZXJ5IHRpbWUgaXQgaXMgbmVlZGVkLiBJZiBhbiBhZ2VudCB3YW50 cyB0bwo+Pj4gcnVuIGFuIFhNTCB2YWxpZGF0b3Igd2l0aCBhbGwgdGhlIGJsb2F0ZWQgbGlicmFy aWVzLCBhIHBvb3IgbGl0dGxlCj4+PiBQeXRob24gaW50ZXJwcmV0ZXIgc2hvdWxkIGJlIGEgcGll Y2Ugb2YgY2FrZS4KPj4gQ29tcGFyZSB0aGlzIHdpdGggYSBzZXQgb2YgQyBmaWxlcyB0aGF0IGJl bG9uZyBpbiBhIGxpYnJhcnkuICBZb3UKPj4gZG9uJ3Qgd2FudCB0byByZWNvbXBpbGUgYWxsIHRo ZSBmaWxlcyBpbiBsaWJjIGV2ZXJ5dGltZSB5b3Ugd2FudAo+PiB0byBjb21waWxlIHlvdXIgImhl bGxvIHdvcmxkIiBwcm9ncmFtLiAgV2Ugc2hvdWxkIGJlIGFibGUgdG8gZmluZAo+IAo+IFRoaXMg aXMgdmVyeSBkaWZmZXJlbnQuIE91ciBjYXNlIGlzIG1vcmUgbGlrZSBhIHNvdXJjZSBjb2RlIHRy YW5zbGF0b3IKPiBiZXR3ZWVuIHNheSBQeXRob24gYW5kIEMuIElmIHlvdSBoYXZlIGEgUHl0aG9u IGFwcGxpY2F0aW9uIGRpdmlkZWQgaW50bwo+IG1vZHVsZXMsIHlvdSBjYW5ub3QgaW4gZ2VuZXJh bCBleHBlY3QgdG8gYmUgYWJsZSB0byB0cmFuc2xhdGUgZWFjaAo+IG1vZHVsZSBzZXBhcmF0ZWx5 IGFuZCBzdGlsbCBiZSBhYmxlIHRvIGNvbXBpbGUgYW5kIGxpbmsgdGhlbSBjb3JyZWN0bHkKPiBp biBDIGJlY2F1c2UgdGhlIHNjb3BpbmcgcnVsZXMgYXJlIGRpZmZlcmVudCwgaW4gUHl0aG9uIHlv dSBjYW4KPiBzZWxlY3RpdmVseSBpbXBvcnQganVzdCBjZXJ0YWluIHN5bWJvbHMgZXRjLiBZb3Ug Y2FuIGluZGVlZCBoYXZlIGEKPiB1c2VmdWwgbW9kdWxhciBzdHJ1Y3R1cmUgaW4gYm90aCBsYW5n dWFnZXMsIGl0IGlzIGhvd2V2ZXIgbm90IGlkZW50aWNhbC4KPiAKClRoZSBhbmFsb2d5IHRvIHJl YWwgY29kZSBvbmx5IGdvZXMgc28gZmFyLgpJbiBmYWN0LCB3aGVuIHlvdSByZWNvbXBpbGUgZm9v LmMsIHlvdSBkbyByZS1jb21waWxlIHN0ZGlvLmgKYW5kIHN0ZGxpYi5oIGFuZCBmb28uaCBhbmQg d2hhdGV2ZXIgZmlsZXMgYXJlIG5hbWVkIGluIHRoZSAjaW5jbHVkZQpkaXJlY3RpdmVzLgoKTGV0 J3Mgbm90IGNvbmZ1c2UgdGhlIGNvbXBpbGVyIGFuZCB0aGUgbGlua2VyIChldmVuIGlmIHRoZXkK YXJlIGJvdGggbmFtZWQgZ2NjIDotKQoKQSBjb21waWxlciBuZWVkcyB0byBiZSB0b2xkIHRoZSBz dGFydCBmaWxlIGFuZCBob3cKdG8gZmluZCAjaW5jbHVkZSBmaWxlcywgYW5kIHRoZSBkZXRlcm1p bmlzdGljIGxhbmd1YWdlCmRvZXMgbm90IGFsbG93ICNpbmNsdWRlIGxvb3BzLiAgSnVzdCBsaWtl IEMgb3IgUHl0aG9uLCBldmVyeQpzeW1ib2wgdXNlZCBpbiB0aGUgc3RhcnQgZmlsZSBtdXN0IGJl IGFjY291bnRlZCBmb3Igd2l0aApsb2NhbCBkZWZpbml0aW9ucyBvciBpbmNsdWRlL2ltcG9ydCBk aXJlY3RpdmVzLgoKQSBsaW5rZXIgbmVlZHMgdG8gYmUgdG9sZCBhbGwgdGhlIGZpbGVzIHRvIGxp bmsgdG9nZXRoZXIsCmFuZCBpdCBpcyBwb3NzaWJsZSB0aGF0ICdkdXBsaWNhdGUgc3ltYm9sJyBl cnJvcnMgY2FuCnNob3cgdXAgdGhhdCB3ZXJlIG5vdCBkZXRlY3RhYmxlIGJ5IGNvbXBpbGluZyBh bnkgZ2l2ZW4Kc3RhcnQgZmlsZSAgKGUuZy4sIGR1cGxpY2F0ZSBuYW1lc3BhY2UgVVJJIHZhbHVl cykuCgoKPiBMYWRhCj4gCgoKQW5keQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Tue Nov 25 09:15: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 AE7743A6808; Tue, 25 Nov 2008 09:15:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A1D3A692A for ; Tue, 25 Nov 2008 09:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=1.204, 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 FrgX5PVa2oHz for ; Tue, 25 Nov 2008 09:15:25 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D36AF3A6808 for ; Tue, 25 Nov 2008 09:15:24 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id F3E51D800CE for ; Tue, 25 Nov 2008 18:15:21 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Tue, 25 Nov 2008 18:15:22 +0100 Message-Id: <1227633322.6288.112.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] augment target X-BeenThere: netmod@ietf.org 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, YANG draft says this about the target of "augment": "The target node MUST be either a container, list, choice, case, input, output, or notification node." But is the following legal? module foo { namespace "urn:foo"; prefix foo; grouping g { container c { leaf a { type string; } } } container root { uses g; } } module bar { namespace "urn:bar"; prefix bar; import foo { prefix foo; } augment foo:root/foo:c { leaf b { type int32; } } } 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 Nov 25 09:38: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 589B43A695E; Tue, 25 Nov 2008 09:38:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7126D3A69B3 for ; Tue, 25 Nov 2008 09:38:49 -0800 (PST) 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 mbgwqJKqdgMV for ; Tue, 25 Nov 2008 09:38:48 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id CA61F3A695E for ; Tue, 25 Nov 2008 09:38:48 -0800 (PST) Received: (qmail 53717 invoked from network); 25 Nov 2008 17:28:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 25 Nov 2008 17:28:11 -0000 X-YMail-OSG: BuxrrkcVM1kgz6w1a1sLUvj5vyiGCsY_KBtLgVuTA2AAs0zlv9RAK0GXZfg5uTP6QO.HrUH9ispULNWEgF3pKU2EQHeN5YLIq0i45zawmDsCx3hAJZXI9P2bJ3LtMmqh0fI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492C35A9.4040902@netconfcentral.com> Date: Tue, 25 Nov 2008 09:28:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1227633322.6288.112.camel@missotis> In-Reply-To: <1227633322.6288.112.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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, > > YANG draft says this about the target of "augment": "The target node > MUST be either a container, list, choice, case, input, output, or > notification node." But is the following legal? > yes > module foo { > namespace "urn:foo"; > prefix foo; > grouping g { > container c { > leaf a { type string; } > } > } > container root { > uses g; > } > } > > module bar { > namespace "urn:bar"; > prefix bar; > import foo { prefix foo; } > augment foo:root/foo:c { > leaf b { type int32; } > } > } > > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 09:48: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 838703A6C1C; Tue, 25 Nov 2008 09:48:21 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDA73A6C2B for ; Tue, 25 Nov 2008 09:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=0.802, 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 aHxtp1APb83I for ; Tue, 25 Nov 2008 09:48:19 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6BA043A6C1C for ; Tue, 25 Nov 2008 09:48:19 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C947FD800CE; Tue, 25 Nov 2008 18:48:16 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <492C35A9.4040902@netconfcentral.com> References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> Organization: CESNET Date: Tue, 25 Nov 2008 18:48:17 +0100 Message-Id: <1227635297.6288.119.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 QW5keSBCaWVybWFuIHDDrcWhZSB2IMOadCAyNS4gMTEuIDIwMDggdiAwOToyOCAtMDgwMDoKPiBM YWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gPiBIaSwKPiA+IAo+ID4gWUFORyBkcmFmdCBzYXlzIHRo aXMgYWJvdXQgdGhlIHRhcmdldCBvZiAiYXVnbWVudCI6ICJUaGUgdGFyZ2V0IG5vZGUKPiA+IE1V U1QgYmUgZWl0aGVyIGEgY29udGFpbmVyLCBsaXN0LCBjaG9pY2UsIGNhc2UsIGlucHV0LCBvdXRw dXQsIG9yCj4gPiBub3RpZmljYXRpb24gbm9kZS4iIEJ1dCBpcyB0aGUgZm9sbG93aW5nIGxlZ2Fs Pwo+ID4gCj4gCj4geWVzCj4gCgpIb3cgYWJvdXQgdGhpcz8KCm1vZHVsZSBmb28gewogIG5hbWVz cGFjZSAidXJuOmZvbyI7CiAgcHJlZml4IGZvbzsKICBpbmNsdWRlIHN1YmZvbzsKICBjb250YWlu ZXIgcm9vdCB7CiAgICBsZWFmIGR1bW15IHsgdHlwZSBlbXB0eTsgfQogIH0KfQoKc3VibW9kdWxl IHN1YmZvbyB7CiAgYmVsb25ncy10byBmb287CiAgYXVnbWVudCAvZm9vOnJvb3QgewogICAgY29u dGFpbmVyIGMgewogICAgICBsZWFmIGEgeyB0eXBlIHN0cmluZzsgfQogICAgfQogIH0KCm1vZHVs ZSBiYXIgewogIG5hbWVzcGFjZSAidXJuOmJhciI7CiAgcHJlZml4IGJhcjsKICBpbXBvcnQgZm9v IHsgcHJlZml4IGZvbzsgfQogIGF1Z21lbnQgL2Zvbzpyb290L2ZvbzpjIHsKICAgIGxlYWYgYiB7 IHR5cGUgaW50MzI7IH0KICB9Cn0KCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5 IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Tue Nov 25 09:53: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 4526D3A6C35; Tue, 25 Nov 2008 09:53:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FA43A6C37 for ; Tue, 25 Nov 2008 09:53:25 -0800 (PST) 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 aqf3caDkB6-C for ; Tue, 25 Nov 2008 09:53:25 -0800 (PST) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 2F2DC3A6C35 for ; Tue, 25 Nov 2008 09:53:25 -0800 (PST) Received: (qmail 68507 invoked from network); 25 Nov 2008 17:40:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 25 Nov 2008 17:40:30 -0000 X-YMail-OSG: cbdsuvsVM1mIp6tS0wiYMp.5q5srujO5H6wygvH3ZDlPdIvE2iBsCKjfFAtmYuVxEuWi.55V.jQaxEMQrrH54A9GeX4YTbUIzf1ymARYadPHHsbZqOPAGBW2XzaEFZxg0xQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492C388C.1000205@andybierman.com> Date: Tue, 25 Nov 2008 09:40:28 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] 7.19.5. The 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 Hi, The context node definition for XPath evaluation of when statements is not clear to me, and certainly not intuitive. These are defined in para 2, bullets 1-3. It is clear that the schema nodes defined in an augment which have XPath clauses (keyref, must, when) need to be evaluated in the context of the augment target, not within the body of the augment statement. It is not intuitive that a when sub-statement of an augment is evaluated in the context of the target as well. The when-stmt for the augment itself says "Add the augment payload only if this XPath expr is true". There should be examples of when expressions in data nodes and each type of non-data node, showing how the context node moves from the current node. (bullet 3, line 2 has a typo: s/teh/the) Why is 'anyxml' considered a data node, which can be confusing, since it cannot be the target of an augment? Can must/when/leafref expressions refer to anyxml nodes? What about unnamed child nodes of anyxml? They are not present in a schema, so that should not be allowed. Is a key leaf allowed to be conditional at all (any ancestor-or-self node with a when or if-feature clause)? What about a mandatory node? Do all nodes have to compile as if no conditionals are present? This seems right, since the revision rules allow if-feature and when to be removed but not added. What happens if must or when XPath expressions refer to nodes which are not present because they are part of an 'if-feature' block which happens to be false for a given implementation? If it happens in a must-stmt, then the config cannot ever be committed. Oh well. All this conditional schema plus conditional runtime can get complicated, and be a source of errors, maybe even automated errors, which are the worst kind. Just use the chainsaw carefully....read the owners manual...practice on 2x4s before attempting to fell a tree... Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 10:59: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 4C01F3A67C1; Tue, 25 Nov 2008 10:59:40 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF6D3A69AF for ; Tue, 25 Nov 2008 10:59:39 -0800 (PST) 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 VCP2M0e3qaC2 for ; Tue, 25 Nov 2008 10:59:39 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 50EE23A67C1 for ; Tue, 25 Nov 2008 10:59:39 -0800 (PST) Received: (qmail 29154 invoked from network); 25 Nov 2008 18:19:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 25 Nov 2008 18:19:51 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <492C41C6.3060604@netconfcentral.com> Date: Tue, 25 Nov 2008 10:19:50 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227635297.6288.119.camel@missotis> In-Reply-To: <1227635297.6288.119.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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+IEFuZHkgQmllcm1hbiBww63FoWUgdiDDmnQgMjUuIDEx LiAyMDA4IHYgMDk6MjggLTA4MDA6Cj4+IExhZGlzbGF2IExob3RrYSB3cm90ZToKPj4+IEhpLAo+ Pj4KPj4+IFlBTkcgZHJhZnQgc2F5cyB0aGlzIGFib3V0IHRoZSB0YXJnZXQgb2YgImF1Z21lbnQi OiAiVGhlIHRhcmdldCBub2RlCj4+PiBNVVNUIGJlIGVpdGhlciBhIGNvbnRhaW5lciwgbGlzdCwg Y2hvaWNlLCBjYXNlLCBpbnB1dCwgb3V0cHV0LCBvcgo+Pj4gbm90aWZpY2F0aW9uIG5vZGUuIiBC dXQgaXMgdGhlIGZvbGxvd2luZyBsZWdhbD8KPj4+Cj4+IHllcwo+Pgo+IAo+IEhvdyBhYm91dCB0 aGlzPwo+IAoKbm8gLS0gbm90aGluZyB0byBkbyB3aXRoIGF1Z21lbnQuClRoZSBpZGVudGlmaWVy ICdmb286cm9vdCcgY2Fubm90IGJlIHZpc2libGUgaW4gYW55IHN1Ym1vZHVsZQpiZWNhdXNlIGl0 IGlzIGluIHRoZSBtYWluIG1vZHVsZS4gVGhlIGJlbG9uZ3MtdG8gY2xhdXNlCmFsc28gY2hhbmdl ZC4KCgo+IG1vZHVsZSBmb28gewo+ICAgbmFtZXNwYWNlICJ1cm46Zm9vIjsKPiAgIHByZWZpeCBm b287Cj4gICBpbmNsdWRlIHN1YmZvbzsKPiAgIGNvbnRhaW5lciByb290IHsKPiAgICAgbGVhZiBk dW1teSB7IHR5cGUgZW1wdHk7IH0KPiAgIH0KPiB9Cj4gCj4gc3VibW9kdWxlIHN1YmZvbyB7Cj4g ICBiZWxvbmdzLXRvIGZvbzsKPiAgIGF1Z21lbnQgL2Zvbzpyb290IHsKPiAgICAgY29udGFpbmVy IGMgewo+ICAgICAgIGxlYWYgYSB7IHR5cGUgc3RyaW5nOyB9Cj4gICAgIH0KPiAgIH0KPiAKPiBt b2R1bGUgYmFyIHsKPiAgIG5hbWVzcGFjZSAidXJuOmJhciI7Cj4gICBwcmVmaXggYmFyOwo+ICAg aW1wb3J0IGZvbyB7IHByZWZpeCBmb287IH0KPiAgIGF1Z21lbnQgL2Zvbzpyb290L2ZvbzpjIHsK PiAgICAgbGVhZiBiIHsgdHlwZSBpbnQzMjsgfQo+ICAgfQo+IH0KPiAKClRoaXMgd291bGQgYmUg ZmluZSBJIHRoaW5rOgoKbW9kdWxlIGZvbyB7CiAgIG5hbWVzcGFjZSAidXJuOmZvbyI7CiAgIHBy ZWZpeCBmb287CiAgIGluY2x1ZGUgc3Vicm9vdDsKICAgaW5jbHVkZSBzdWJmb287Cn0KCnN1Ym1v ZHVsZSBzdWJyb290IHsKICAgYmVsb25ncy10byBmb287CiAgIGNvbnRhaW5lciByb290IHsKICAg ICBsZWFmIGR1bW15IHsgdHlwZSBlbXB0eTsgfQogICB9Cn0KCnN1Ym1vZHVsZSBzdWJmb28gewog ICBiZWxvbmdzLXRvIGZvbyB7IHByZWZpeCBmb287IH0KICAgaW5jbHVkZSBzdWJyb290OwogICBh dWdtZW50IC9mb286cm9vdCB7CiAgICAgY29udGFpbmVyIGMgewogICAgICAgbGVhZiBhIHsgdHlw ZSBzdHJpbmc7IH0KICAgICB9CiAgIH0KfQoKbW9kdWxlIGJhciB7CiAgIG5hbWVzcGFjZSAidXJu OmJhciI7CiAgIHByZWZpeCBiYXI7CiAgIGltcG9ydCBmb28geyBwcmVmaXggZm9vOyB9CiAgIGF1 Z21lbnQgL2Zvbzpyb290L2ZvbzpjIHsKICAgICBsZWFmIGIgeyB0eXBlIGludDMyOyB9CiAgIH0K fQoKCkp1c3QgZm9yIGZ1biwgbGV0J3MgYWRkIGEgd2hlbi1zdG10IHRvIGNvbnRhaW5lciAnYyc6 CgpzdWJtb2R1bGUgc3ViZm9vIHsKICAgYmVsb25ncy10byBmb28geyBwcmVmaXggZm9vOyB9CiAg IGluY2x1ZGUgc3Vicm9vdDsKICAgYXVnbWVudCAvZm9vOnJvb3QgewogICAgIGNvbnRhaW5lciBj IHsKICAgICAgIHdoZW4gIi4uL2ZvbzpkdW1teSI7CiAgICAgICBsZWFmIGEgeyB0eXBlIHN0cmlu ZzsgfQogICAgIH0KICAgfQp9CgoKSWYgdGhlIGVtcHR5IGxlYWYgL3Jvb3QvZHVtbXkgaXMgcHJl c2VudCBhdCBydW50aW1lLAp0aGVuIHRoZSAvcm9vdC9jIGNvbnRhaW5lciB3aWxsIGV4aXN0IGlu IHRoZSBzY2hlbWEsCmFsbG93aW5nIGxlYWYgJ2InIGZyb20gbW9kdWxlIGJhciB0byBhbHNvIGV4 aXN0LgpJZiAvcm9vdC9kdW1teSBnZXRzIGRlbGV0ZWQsIHRoZW4gdGhlIGVudGlyZSAnYycKY29u dGFpbmVyIGdldHMgbWFnaWNhbGx5IGRlbGV0ZWQgYXQgdGhlIHNhbWUgdGltZS4KCgpBbmR5Cgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Nov 25 11:43: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 B27043A6A9F; Tue, 25 Nov 2008 11:43:03 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECB73A6AA7 for ; Tue, 25 Nov 2008 11:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 afHKjcGhrZbR for ; Tue, 25 Nov 2008 11:43:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D21003A6A9F for ; Tue, 25 Nov 2008 11:43:01 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DBBA4D800C0; Tue, 25 Nov 2008 20:42:58 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <492C35A9.4040902@netconfcentral.com> References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> Organization: CESNET Date: Tue, 25 Nov 2008 20:42:59 +0100 Message-Id: <1227642179.14326.2.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 OK, after correcting belongs-to, is this valid? module foo { namespace "urn:foo"; prefix foo; include subfoo; container root { leaf dummy { type empty; } } } submodule subfoo { belongs-to foo { prefix foo; } augment /foo:root { container c { leaf a { type string; } } } module bar { namespace "urn:bar"; prefix bar; import foo { prefix foo; } augment /foo:root/foo:c { leaf b { type int32; } } } -- 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 Nov 25 11:52: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 3587F28C0E4; Tue, 25 Nov 2008 11:52:52 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D4128C0E4 for ; Tue, 25 Nov 2008 11:52:50 -0800 (PST) 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 tgdgc1lEzoXC for ; Tue, 25 Nov 2008 11:52:50 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 5119328C0E1 for ; Tue, 25 Nov 2008 11:52:50 -0800 (PST) Received: (qmail 98180 invoked from network); 25 Nov 2008 19:52:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 25 Nov 2008 19:52:46 -0000 X-YMail-OSG: sBZ12iEVM1mdkimnb6UekZuhk9BfsTonuLJOT82_oMTMpKa6jHoeazISgy5sCNwU.dE9yXcZJO9ZtUJkxjcT9NBKIP2rGdrFIkXpmIAjLAe06fP6EsAbmn4DRc0gjF_uyFg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492C578D.6010407@netconfcentral.com> Date: Tue, 25 Nov 2008 11:52:45 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> In-Reply-To: <1227642179.14326.2.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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: > OK, after correcting belongs-to, is this valid? > No, because 'root' is not visible in 'subfoo'. Only the prefix is available for mapping, in case you want to use it in places where an optional prefix is allowed, like XPath expressions. Stuff in the main module is not visible in submodules at all. Even with submodules, you have to be careful to avoid loops (e.g., submodule subroot includes subfoo). Of course, a good compiler will detect any definition loops, and there are a lot of them possible in YANG. > > module foo { > namespace "urn:foo"; > prefix foo; > include subfoo; > container root { > leaf dummy { type empty; } > } > } > > submodule subfoo { > belongs-to foo { prefix foo; } > augment /foo:root { > container c { > leaf a { type string; } > } > } > > module bar { > namespace "urn:bar"; > prefix bar; > import foo { prefix foo; } > augment /foo:root/foo:c { > leaf b { type int32; } > } > } > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 12:11: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 6077A3A6AA7; Tue, 25 Nov 2008 12:11:24 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89903A6C25 for ; Tue, 25 Nov 2008 12:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[AWL=0.630, 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 STzWzHfsG6YD for ; Tue, 25 Nov 2008 12:11:22 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DD5253A6AA7 for ; Tue, 25 Nov 2008 12:11:21 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 8F12BD800C0; Tue, 25 Nov 2008 21:11:19 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <492C578D.6010407@netconfcentral.com> References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> <492C578D.6010407@netconfcentral.com> Organization: CESNET Date: Tue, 25 Nov 2008 21:11:20 +0100 Message-Id: <1227643880.14326.8.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 QW5keSBCaWVybWFuIHDDrcWhZSB2IMOadCAyNS4gMTEuIDIwMDggdiAxMTo1MiAtMDgwMDoKPiBM YWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gPiBPSywgYWZ0ZXIgY29ycmVjdGluZyBiZWxvbmdzLXRv LCBpcyB0aGlzIHZhbGlkPwo+ID4gCj4gCj4gTm8sIGJlY2F1c2UgJ3Jvb3QnIGlzIG5vdCB2aXNp YmxlIGluICdzdWJmb28nLgo+IE9ubHkgdGhlIHByZWZpeCBpcyBhdmFpbGFibGUgZm9yIG1hcHBp bmcsCj4gaW4gY2FzZSB5b3Ugd2FudCB0byB1c2UgaXQgaW4gcGxhY2VzIHdoZXJlIGFuIG9wdGlv bmFsCj4gcHJlZml4IGlzIGFsbG93ZWQsIGxpa2UgWFBhdGggZXhwcmVzc2lvbnMuCgpIb3cgY2Fu IHRoZW4gYmUgdGhlIHN1Ym1vZHVsZSB0cmVlIGF0dGFjaGVkIHRvIGEgbm9uLXJvb3QgbGV2ZWwg aW4gdGhlCm1haW4gbW9kdWxlPyBJIHJlbWVtYmVyIGFuIGV4YW1wbGUgZnJvbSB0aGUgaW50ZXJp bSB3aGVyZSBhdWdtZW50IGluIGEKc3VibW9kdWxlIHdhcyB1c2VkIGp1c3QgZm9yIHRoaXMuCgpM YWRhCiAKPiAKPiBTdHVmZiBpbiB0aGUgbWFpbiBtb2R1bGUgaXMgbm90IHZpc2libGUgaW4gc3Vi bW9kdWxlcyBhdCBhbGwuCj4gRXZlbiB3aXRoIHN1Ym1vZHVsZXMsIHlvdSBoYXZlIHRvIGJlIGNh cmVmdWwgdG8gYXZvaWQgbG9vcHMKPiAoZS5nLiwgc3VibW9kdWxlIHN1YnJvb3QgaW5jbHVkZXMg c3ViZm9vKS4gIE9mIGNvdXJzZSwgYQo+IGdvb2QgY29tcGlsZXIgd2lsbCBkZXRlY3QgYW55IGRl ZmluaXRpb24gbG9vcHMsIGFuZCB0aGVyZQo+IGFyZSBhIGxvdCBvZiB0aGVtIHBvc3NpYmxlIGlu IFlBTkcuCj4gCj4gCj4gPiAKPiA+IG1vZHVsZSBmb28gewo+ID4gICBuYW1lc3BhY2UgInVybjpm b28iOwo+ID4gICBwcmVmaXggZm9vOwo+ID4gICBpbmNsdWRlIHN1YmZvbzsKPiA+ICAgY29udGFp bmVyIHJvb3Qgewo+ID4gICAgIGxlYWYgZHVtbXkgeyB0eXBlIGVtcHR5OyB9Cj4gPiAgIH0KPiA+ IH0KPiA+IAo+ID4gc3VibW9kdWxlIHN1YmZvbyB7Cj4gPiAgIGJlbG9uZ3MtdG8gZm9vIHsgcHJl Zml4IGZvbzsgfQo+ID4gICBhdWdtZW50IC9mb286cm9vdCB7Cj4gPiAgICAgY29udGFpbmVyIGMg ewo+ID4gICAgICAgbGVhZiBhIHsgdHlwZSBzdHJpbmc7IH0KPiA+ICAgICB9Cj4gPiAgIH0KPiA+ IAo+ID4gbW9kdWxlIGJhciB7Cj4gPiAgIG5hbWVzcGFjZSAidXJuOmJhciI7Cj4gPiAgIHByZWZp eCBiYXI7Cj4gPiAgIGltcG9ydCBmb28geyBwcmVmaXggZm9vOyB9Cj4gPiAgIGF1Z21lbnQgL2Zv bzpyb290L2ZvbzpjIHsKPiA+ICAgICBsZWFmIGIgeyB0eXBlIGludDMyOyB9Cj4gPiAgIH0KPiA+ IH0KPiA+IAo+IAo+IAo+IEFuZHkKPiAKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBL ZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Nov 25 12: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 809743A67FD; Tue, 25 Nov 2008 12:29:32 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12583A6C5F for ; Tue, 25 Nov 2008 12:29:31 -0800 (PST) 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 SUpbzaSEbZ67 for ; Tue, 25 Nov 2008 12:29:30 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C395C3A67FD for ; Tue, 25 Nov 2008 12:29:30 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A76276C30E; Tue, 25 Nov 2008 21:29:27 +0100 (CET) Date: Tue, 25 Nov 2008 21:29:26 +0100 (CET) Message-Id: <20081125.212926.140885891.mbj@tail-f.com> To: andy@andybierman.com From: Martin Bjorklund In-Reply-To: <492C388C.1000205@andybierman.com> References: <492C388C.1000205@andybierman.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] 7.19.5. The 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 Andy Bierman wrote: > It is not intuitive that a when sub-statement of an augment > is evaluated in the context of the target as well. [...] > There should be examples of when expressions in data nodes > and each type of non-data node, showing how the context node > moves from the current node. I hope that an example will help. I will add one or two examples. > (bullet 3, line 2 has a typo: s/teh/the) Fixed. > Why is 'anyxml' considered a data node, which can be confusing, > since it cannot be the target of an augment? Can must/when/leafref > expressions refer to anyxml nodes? must and when, yes. leafreaf no, since anyxml is not a leaf. > What about unnamed child nodes > of anyxml? They are not present in a schema, so that should > not be allowed. Agreed. Since the anyxml is an unknown chunk of XML, how could it be possible to name an unknown node...? > Is a key leaf allowed to be conditional at all (any ancestor-or-self > node with a when or if-feature clause)? No, and it needs to be clarified. > What about a mandatory node? Yes it can be conditional. If the condition is true, then the node is mandatory. > Do all nodes have to compile as if no conditionals are present? I don't know what "have to compile" means. They have to be valid YANG if that's what you meant. > What happens if must or when XPath expressions refer to nodes > which are not present because they are part of an 'if-feature' > block which happens to be false for a given implementation? > If it happens in a must-stmt, then the config cannot ever > be committed. Oh well. We could say that it should be handled just as a must ref to non-config from config, i.e. that any reference in the must/when MUST NOT refer to a node which has a if-feature, unless the node with the must also has the same if-feature. But I don't think it's worth it. A clever compiler can warn about this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 13:22: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 702973A6C46; Tue, 25 Nov 2008 13:22:51 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF243A6C5C for ; Tue, 25 Nov 2008 13:22:50 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urd2f2YpFJFU for ; Tue, 25 Nov 2008 13:22:49 -0800 (PST) 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 8EF0E3A6C46 for ; Tue, 25 Nov 2008 13:22:49 -0800 (PST) Received: (qmail 75719 invoked from network); 25 Nov 2008 21:22:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 25 Nov 2008 21:22:44 -0000 X-YMail-OSG: lhPZCjEVM1l15wSGmL.xT26hT4f1vX.gfe91Rt4wAhg1H1seziniuxHU5DAIUeOG_QA8alnzh72KZkjrZpENHl6rdRM_Gvw8jsMUXt46bCIpgeJRH31oo6VqZ6AEOaDfkIEP4mPOI9cCA6iGNcUkVQGa X-Yahoo-Newman-Property: ymail-3 Message-ID: <492C6CA2.1070905@netconfcentral.com> Date: Tue, 25 Nov 2008 13:22:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492C388C.1000205@andybierman.com> <20081125.212926.140885891.mbj@tail-f.com> In-Reply-To: <20081125.212926.140885891.mbj@tail-f.com> Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] 7.19.5. The 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: > Andy Bierman wrote: >> It is not intuitive that a when sub-statement of an augment >> is evaluated in the context of the target as well. > > [...] > >> There should be examples of when expressions in data nodes >> and each type of non-data node, showing how the context node >> moves from the current node. > > I hope that an example will help. I will add one or two examples. > good -- there is no text that specifies the context node for when evaluation if the when-stmt is a child of a uses-stmt. Since I'm trying to code this at the moment, some guidance would help. I still think this is all too complicated, but the DM designer has to be careful, and never make any XPath errors. It seems that each cooked node (what I call a final-position data node after all augment and uses have been expanded) will have up to 3 when statements, each evaluated in its own context: 1) from the object itself 2) from a uses-stmt that causes the grouping expansion 3) from an augment-stmt that causes the augment expansion Perhaps an example with an augment inside a uses, showing when-stmts in the augment, uses, original grouping objects, and target schema node tree, showing how the XPath evaluation is done, and the evaluation order as well. Andy >> (bullet 3, line 2 has a typo: s/teh/the) > > Fixed. > >> Why is 'anyxml' considered a data node, which can be confusing, >> since it cannot be the target of an augment? Can must/when/leafref >> expressions refer to anyxml nodes? > > must and when, yes. leafreaf no, since anyxml is not a leaf. > >> What about unnamed child nodes >> of anyxml? They are not present in a schema, so that should >> not be allowed. > > Agreed. Since the anyxml is an unknown chunk of XML, how could it be > possible to name an unknown node...? > >> Is a key leaf allowed to be conditional at all (any ancestor-or-self >> node with a when or if-feature clause)? > > No, and it needs to be clarified. > >> What about a mandatory node? > > Yes it can be conditional. If the condition is true, then the node is > mandatory. > >> Do all nodes have to compile as if no conditionals are present? > > I don't know what "have to compile" means. They have to be valid YANG > if that's what you meant. > > >> What happens if must or when XPath expressions refer to nodes >> which are not present because they are part of an 'if-feature' >> block which happens to be false for a given implementation? >> If it happens in a must-stmt, then the config cannot ever >> be committed. Oh well. > > We could say that it should be handled just as a must ref to > non-config from config, i.e. that any reference in the must/when MUST > NOT refer to a node which has a if-feature, unless the node with the > must also has the same if-feature. > > But I don't think it's worth it. A clever compiler can warn about > this. > > > /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 Tue Nov 25 18:12: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 255FA3A6B1E; Tue, 25 Nov 2008 18:12:26 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B899A3A6C86 for ; Tue, 25 Nov 2008 18:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 QsTCJIzI4QGS for ; Tue, 25 Nov 2008 18:12:23 -0800 (PST) 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 2CF723A6B1E for ; Tue, 25 Nov 2008 18:12:22 -0800 (PST) Received: (qmail 38853 invoked from network); 26 Nov 2008 02:12:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 02:12:18 -0000 X-YMail-OSG: sXi.0LsVM1mNFraowJlHykrUi0yTtJJsKr2KGsz_lVOfskMdNQMlcjo4uc9XxHTACnRPI5d9Xb.YUbMiFmsy.fDJNNq42wAoSue3pPzRvVIgljTRRU7Bzw7vEaUya6GEOrE9ys5bK7w6aXSiebu5nnuK X-Yahoo-Newman-Property: ymail-3 Message-ID: <492CB081.4030408@netconfcentral.com> Date: Tue, 25 Nov 2008 18:12:17 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492C388C.1000205@andybierman.com> <20081125.212926.140885891.mbj@tail-f.com> In-Reply-To: <20081125.212926.140885891.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.19.5. The 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: > Andy Bierman wrote: >> It is not intuitive that a when sub-statement of an augment >> is evaluated in the context of the target as well. > > [...] > >> There should be examples of when expressions in data nodes >> and each type of non-data node, showing how the context node >> moves from the current node. > > I hope that an example will help. I will add one or two examples. > >> (bullet 3, line 2 has a typo: s/teh/the) > > Fixed. > >> Why is 'anyxml' considered a data node, which can be confusing, >> since it cannot be the target of an augment? Can must/when/leafref >> expressions refer to anyxml nodes? > > must and when, yes. leafreaf no, since anyxml is not a leaf. > >> What about unnamed child nodes >> of anyxml? They are not present in a schema, so that should >> not be allowed. > > Agreed. Since the anyxml is an unknown chunk of XML, how could it be > possible to name an unknown node...? > >> Is a key leaf allowed to be conditional at all (any ancestor-or-self >> node with a when or if-feature clause)? > > No, and it needs to be clarified. > >> What about a mandatory node? > > Yes it can be conditional. If the condition is true, then the node is > mandatory. > >> Do all nodes have to compile as if no conditionals are present? > > I don't know what "have to compile" means. They have to be valid YANG > if that's what you meant. > > So this is never allowed: container dummy { uses G { when "some-expr"; } uses G { when "not(some-expr)"; refine x {...} } } OR container dummy { leaf x { when "some-expr"; type string; } leaf x { when "not(some-expr)"; type float32; } } There are more scenarios like this, and I want to make sure this sort of thing is invalid YANG. We really should avoid YANG modules that magically become invalid because runtime values on the agent change. That would be really bad design. >> What happens if must or when XPath expressions refer to nodes >> which are not present because they are part of an 'if-feature' >> block which happens to be false for a given implementation? >> If it happens in a must-stmt, then the config cannot ever >> be committed. Oh well. > > We could say that it should be handled just as a must ref to > non-config from config, i.e. that any reference in the must/when MUST > NOT refer to a node which has a if-feature, unless the node with the > must also has the same if-feature. > > But I don't think it's worth it. A clever compiler can warn about > this. Clever compilers are going to be mandatory, because YANG is way too complicated now for even clever humans to debug by inspection. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 19:27: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 A5DE43A68B7; Tue, 25 Nov 2008 19:27:16 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A927E3A6918 for ; Tue, 25 Nov 2008 19:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-1.097, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 54oThmH2XoIZ for ; Tue, 25 Nov 2008 19:27:15 -0800 (PST) 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 199F13A68B7 for ; Tue, 25 Nov 2008 19:27:15 -0800 (PST) Received: (qmail 56430 invoked from network); 26 Nov 2008 03:27:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 03:27:10 -0000 X-YMail-OSG: sYt3YsYVM1l0BEOxajhHCoeYz5DenuSq36.lyaqHc4SgbJktz9cl0mRIc7C7nbNTWuiPwZdRoaei40SpWvQf9UBRwokFovLIoH2nnTyG0.5O8o1J8Sq1M1tRCe7WdjhKAoI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492CC20D.20904@netconfcentral.com> Date: Tue, 25 Nov 2008 19:27:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] floating point math X-BeenThere: netmod@ietf.org 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 am somewhat surprised that nobody has complained that must-stmt expression syntax requires agents to support IEEE 754 floating point numbers for basic math operations, not just storage and retrieval. Maybe this is a sign that vendors have really advanced since floating point numbers were forcefully rejected by the EOS and SMIng WGs several years ago. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 22:26: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 888EE3A6B34; Tue, 25 Nov 2008 22:26:07 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2A03A6B38 for ; Tue, 25 Nov 2008 22:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 zsGQTjW9licW for ; Tue, 25 Nov 2008 22:26:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8716B3A6B34 for ; Tue, 25 Nov 2008 22:26:00 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAB8EC004E; Wed, 26 Nov 2008 07:25:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NCsfgD2qSse8; Wed, 26 Nov 2008 07:25:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 183A8C0045; Wed, 26 Nov 2008 07:25:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 031DC883618; Wed, 26 Nov 2008 07:25:50 +0100 (CET) Date: Wed, 26 Nov 2008 07:25:50 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081126062550.GA4646@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <492CC20D.20904@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <492CC20D.20904@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] floating point math 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, Nov 25, 2008 at 07:27:09PM -0800, Andy Bierman wrote: > I am somewhat surprised that nobody has complained that > must-stmt expression syntax requires agents to support > IEEE 754 floating point numbers for basic math operations, > not just storage and retrieval. > > Maybe this is a sign that vendors have really advanced > since floating point numbers were forcefully rejected > by the EOS and SMIng WGs several years ago. Supporting floating point numbers in a data modeling language does not imply all data models have to use floating point numbers. I can write perfect C code that never uses floating point numbers. What I think has changed is that the old approach of "lets design CLRs for a data modeling language that help data model writers to not shoot themself into the foot" is not followed anymore and this is goodness because many of these CLRs did fire back badly. Data model writers should enjoy the freedom to decide whether they need floats or not. /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 Nov 25 23:01: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 4A1033A6903; Tue, 25 Nov 2008 23:01:50 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225E73A6A0D for ; Tue, 25 Nov 2008 23:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 8Mv9jq-7MOLu for ; Tue, 25 Nov 2008 23:01:48 -0800 (PST) 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 65CA83A6903 for ; Tue, 25 Nov 2008 23:01:48 -0800 (PST) Received: (qmail 13477 invoked from network); 26 Nov 2008 07:01:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 07:01:43 -0000 X-YMail-OSG: htNgmlEVM1mUrB_7hsTiCxMIdAkp6vtaQZir5Zxj6WAjYCafy8xRRDQy9avRrMV0yb.BmgGy.X0gJUVa.2bD_n4GAHje9t3chzXxwdhu23jN3bUYoH4HoNNKi0j9L3pjTtY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492CF456.8010104@netconfcentral.com> Date: Tue, 25 Nov 2008 23:01:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Andy Bierman , NETMOD Working Group References: <492CC20D.20904@netconfcentral.com> <20081126062550.GA4646@elstar.local> In-Reply-To: <20081126062550.GA4646@elstar.local> Subject: Re: [netmod] floating point math X-BeenThere: netmod@ietf.org 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, Nov 25, 2008 at 07:27:09PM -0800, Andy Bierman wrote: > >> I am somewhat surprised that nobody has complained that >> must-stmt expression syntax requires agents to support >> IEEE 754 floating point numbers for basic math operations, >> not just storage and retrieval. >> >> Maybe this is a sign that vendors have really advanced >> since floating point numbers were forcefully rejected >> by the EOS and SMIng WGs several years ago. > > Supporting floating point numbers in a data modeling language does not > imply all data models have to use floating point numbers. I can write > perfect C code that never uses floating point numbers. > > What I think has changed is that the old approach of "lets design CLRs > for a data modeling language that help data model writers to not shoot > themself into the foot" is not followed anymore and this is goodness > because many of these CLRs did fire back badly. Data model writers > should enjoy the freedom to decide whether they need floats or not. > That would only work for a vendor if they never need to implement a standard DM with float32 or float64 objects. But actually, all numbers in XPath expressions are floating point, and functions like round, floor, ceiling, and especially the 'div' operator are mandatory to support in the agent. The vendor would need to avoid any data model with a must-stmt or when-stmt that used any of these constructs. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 23:14: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 EA0F53A6903; Tue, 25 Nov 2008 23:14:53 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1643A6B33 for ; Tue, 25 Nov 2008 23:14:52 -0800 (PST) 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 rVJtF-FAQ78d for ; Tue, 25 Nov 2008 23:14:51 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B25533A6903 for ; Tue, 25 Nov 2008 23:14:51 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 23B5776C310; Wed, 26 Nov 2008 08:14:48 +0100 (CET) Date: Wed, 26 Nov 2008 08:14:47 +0100 (CET) Message-Id: <20081126.081447.259313141.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492CC20D.20904@netconfcentral.com> References: <492CC20D.20904@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] floating point math X-BeenThere: netmod@ietf.org 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 am somewhat surprised that nobody has complained that > must-stmt expression syntax requires agents to support > IEEE 754 floating point numbers for basic math operations, > not just storage and retrieval. We should point out that this requirement comes from XPath 1.0, and our design decision to use XPath 1.0 as-is. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Nov 25 23:47: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 16C5A3A6B3C; Tue, 25 Nov 2008 23:47:33 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605BD3A6B3B for ; Tue, 25 Nov 2008 23:47:31 -0800 (PST) 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.421, 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 MdCnxa3HRdsM for ; Tue, 25 Nov 2008 23:47:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6F0EE3A6B3A for ; Tue, 25 Nov 2008 23:47:30 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4745C004C; Wed, 26 Nov 2008 08:47:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yLNFzuW+-aps; Wed, 26 Nov 2008 08:47:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A85A8C0048; Wed, 26 Nov 2008 08:47:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6C62688370B; Wed, 26 Nov 2008 08:47:21 +0100 (CET) Date: Wed, 26 Nov 2008 08:47:21 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081126074721.GA4734@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <492CC20D.20904@netconfcentral.com> <20081126062550.GA4646@elstar.local> <492CF456.8010104@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <492CF456.8010104@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] floating point math 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, Nov 25, 2008 at 11:01:42PM -0800, Andy Bierman wrote: > But actually, all numbers in XPath expressions are floating point, > and functions like round, floor, ceiling, and especially the 'div' > operator are mandatory to support in the agent. The vendor > would need to avoid any data model with a must-stmt or when-stmt > that used any of these constructs. If the data model designer uses these functions and in addition I think Yang says that the implementation of the condition checks does not necessarily require to use a full XPath implementation on the device as long as the device does the right thing. In other words, I do not think that floating point functions are mandatory to implement as you suggest above. /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 Nov 25 23:57: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 A857B3A67F2; Tue, 25 Nov 2008 23:57:18 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8113A67F2 for ; Tue, 25 Nov 2008 23:57:17 -0800 (PST) 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 eaDrVFQ9mUYC for ; Tue, 25 Nov 2008 23:57:16 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 67CC43A657C for ; Tue, 25 Nov 2008 23:57:16 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A2EC176C310; Wed, 26 Nov 2008 08:57:13 +0100 (CET) Date: Wed, 26 Nov 2008 08:57:10 +0100 (CET) Message-Id: <20081126.085710.179992347.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20081126074721.GA4734@elstar.local> References: <20081126062550.GA4646@elstar.local> <492CF456.8010104@netconfcentral.com> <20081126074721.GA4734@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] floating point math X-BeenThere: netmod@ietf.org 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: > If the data model designer uses these functions and in addition I > think Yang says that the implementation of the condition checks does > not necessarily require to use a full XPath implementation on the > device as long as the device does the right thing. In other words, I > do not think that floating point functions are mandatory to implement > as you suggest above. It does not require an XPath implementation, but if the must expression is: "round(.) = '1'" the device must implement the round() function (somehow). But as you stated, YANG provides the means for writing such data models. It does not mean that modellers MUST use everything available, and it definitely does not mean that devices that can't do floating point arithmetic will implement data models that require them to do just that. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 26 05: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 7AE723A6B35; Wed, 26 Nov 2008 05:04:53 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808D328C12E for ; Wed, 26 Nov 2008 05:04:51 -0800 (PST) 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 ZGgVtI9uOoUM for ; Wed, 26 Nov 2008 05:04:50 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 756EF3A69A4 for ; Wed, 26 Nov 2008 05:04:50 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EC7B4203D6; Wed, 26 Nov 2008 14:04:46 +0100 (CET) X-AuditID: c1b4fb3e-ac781bb00000537b-c3-492d496e53ee Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D2E0D201CE; Wed, 26 Nov 2008 14:04:46 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:04:46 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:04:46 +0100 Message-ID: <492D496D.9070707@ericsson.com> Date: Wed, 26 Nov 2008 14:04:45 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> <492C578D.6010407@netconfcentral.com> In-Reply-To: <492C578D.6010407@netconfcentral.com> X-OriginalArrivalTime: 26 Nov 2008 13:04:46.0613 (UTC) FILETIME=[8E973450:01C94FC7] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 always found it ugly and surprising that there is no way to make stuff in the module visible to submodules. I think this will lead to quite a number of near empty (main) modules. As Andy has shown there is a workaround, but it is a workaround. Balazs Andy Bierman wrote: > Ladislav Lhotka wrote: >> OK, after correcting belongs-to, is this valid? >> > > No, because 'root' is not visible in 'subfoo'. > Only the prefix is available for mapping, > in case you want to use it in places where an optional > prefix is allowed, like XPath expressions. > > Stuff in the main module is not visible in submodules at all. > Even with submodules, you have to be careful to avoid loops > (e.g., submodule subroot includes subfoo). Of course, a > good compiler will detect any definition loops, and there > are a lot of them possible in YANG. > > >> >> module foo { >> namespace "urn:foo"; >> prefix foo; >> include subfoo; >> container root { >> leaf dummy { type empty; } >> } >> } >> >> submodule subfoo { >> belongs-to foo { prefix foo; } >> augment /foo:root { >> container c { >> leaf a { type string; } >> } >> } >> >> module bar { >> namespace "urn:bar"; >> prefix bar; >> import foo { prefix foo; } >> augment /foo:root/foo:c { >> leaf b { type int32; } >> } >> } >> > > > 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 Wed Nov 26 06:48: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 9F3113A687E; Wed, 26 Nov 2008 06:48:30 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7F23A69F2 for ; Wed, 26 Nov 2008 06:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.143, 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 l2Q5JMuPjGeY for ; Wed, 26 Nov 2008 06:48:28 -0800 (PST) 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 97A0C3A687E for ; Wed, 26 Nov 2008 06:48:28 -0800 (PST) Received: (qmail 57893 invoked from network); 26 Nov 2008 14:48:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 14:48:24 -0000 X-YMail-OSG: .N6E5usVM1ldqMhq4ER5.VQ4H.GAf5QeKZSVlyWxLEr48.9Ko4xKercjKD.8Pd2XDwHU87HjXeSCw6xryKfWsQAGFk94MwaT0937wyATWiv3tglCF5hm928BOzYrxkJBEre3K8kjUTUR6lkKPVZPkkog X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D61B6.2080909@netconfcentral.com> Date: Wed, 26 Nov 2008 06:48:22 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Balazs Lengyel References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> <492C578D.6010407@netconfcentral.com> <492D496D.9070707@ericsson.com> In-Reply-To: <492D496D.9070707@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 always found it ugly and surprising that there is no way to make stuff > in the module visible to submodules. I think this will lead to quite a > number of near empty (main) modules. > As Andy has shown there is a workaround, but it is a workaround. It is the way submodules work. I think the current rules are OK. If foo includes sub-foo, and sub-foo can include its parent 'foo', that is no different than module A importing B and B importing A. It creates an import loop and it is a fatal error in YANG. > Balazs Andy > > Andy Bierman wrote: >> Ladislav Lhotka wrote: >>> OK, after correcting belongs-to, is this valid? >>> >> >> No, because 'root' is not visible in 'subfoo'. >> Only the prefix is available for mapping, >> in case you want to use it in places where an optional >> prefix is allowed, like XPath expressions. >> >> Stuff in the main module is not visible in submodules at all. >> Even with submodules, you have to be careful to avoid loops >> (e.g., submodule subroot includes subfoo). Of course, a >> good compiler will detect any definition loops, and there >> are a lot of them possible in YANG. >> >> >>> >>> module foo { >>> namespace "urn:foo"; >>> prefix foo; >>> include subfoo; >>> container root { >>> leaf dummy { type empty; } >>> } >>> } >>> >>> submodule subfoo { >>> belongs-to foo { prefix foo; } >>> augment /foo:root { >>> container c { >>> leaf a { type string; } >>> } >>> } >>> >>> module bar { >>> namespace "urn:bar"; >>> prefix bar; >>> import foo { prefix foo; } >>> augment /foo:root/foo:c { >>> leaf b { type int32; } >>> } >>> } >>> >> >> >> 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 Wed Nov 26 07:03: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 86A8F3A6403; Wed, 26 Nov 2008 07:03:39 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921423A6811 for ; Wed, 26 Nov 2008 07:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.133, 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 bptY-txtQ4Q4 for ; Wed, 26 Nov 2008 07:03:37 -0800 (PST) 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 E46943A6403 for ; Wed, 26 Nov 2008 07:03:37 -0800 (PST) Received: (qmail 454 invoked from network); 26 Nov 2008 15:03:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 15:03:34 -0000 X-YMail-OSG: _N19ROEVM1lTB_zzDSOGgiCeUHl5f8KwAKlCe094S1rGrULvf6bfj5m7WoyIrXiFwpB30pvY1KXf6kJ3EX1T6vYcwaHN8c.U1RMtuNewdUeHtwKVPQrq36zAixilm0dKP85b7PyGQHf1QrrnKZrHXkxl X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D6544.5000000@netconfcentral.com> Date: Wed, 26 Nov 2008 07:03:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <20081126062550.GA4646@elstar.local> <492CF456.8010104@netconfcentral.com> <20081126074721.GA4734@elstar.local> <20081126.085710.179992347.mbj@tail-f.com> In-Reply-To: <20081126.085710.179992347.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] floating point math X-BeenThere: netmod@ietf.org 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: >> If the data model designer uses these functions and in addition I >> think Yang says that the implementation of the condition checks does >> not necessarily require to use a full XPath implementation on the >> device as long as the device does the right thing. In other words, I >> do not think that floating point functions are mandatory to implement >> as you suggest above. > > It does not require an XPath implementation, but if the must > expression is: "round(.) = '1'" the device must implement the round() > function (somehow). > > There really isn't any way to fake the 'div' operator. Perhaps a warning to DM designers about the use of floating point in XPath would help. Don't use it unless it is the 'natural' thing to do. Even so, MIB developers usually use hacks to avoid needing real FP math in SNMP agents. > But as you stated, YANG provides the means for writing such data > models. It does not mean that modellers MUST use everything > available, and it definitely does not mean that devices that can't do > floating point arithmetic will implement data models that require > them to do just that. > > > > /martin > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 26 15:02: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 5577F3A6A11; Wed, 26 Nov 2008 15:02:00 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDB53A6A55 for ; Wed, 26 Nov 2008 15:01:59 -0800 (PST) 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 ncLUGFk--rTM for ; Wed, 26 Nov 2008 15:01:59 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 46A553A6813 for ; Wed, 26 Nov 2008 15:01:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSS3VQQ3hpxM3qdP3BODVZUbdk9vug0w/@postini.com; Wed, 26 Nov 2008 15:01:26 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 14:58:32 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:58:31 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:58:31 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:58:31 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQMwUM30098; Wed, 26 Nov 2008 14:58:30 -0800 (PST) (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 mAQMrMH5051721; Wed, 26 Nov 2008 22:53:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811262253.mAQMrMH5051721@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20081126.085710.179992347.mbj@tail-f.com> Date: Wed, 26 Nov 2008 17:53:22 -0500 From: Phil Shafer X-OriginalArrivalTime: 26 Nov 2008 22:58:31.0047 (UTC) FILETIME=[80687170:01C9501A] MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] floating point math X-BeenThere: netmod@ietf.org 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 writes: >It does not require an XPath implementation, but if the must >expression is: "round(.) = '1'" the device must implement the round() >function (somehow). Sort of, but not really. If "." is an int, the device-side coder that implements this can read the YANG, realize that rounding an int is meaningless and ignore it completely. There's no requirement that the device implement a generic YANG modeling engine. Only that it abide by the rules in the model. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Nov 26 23:19: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 A6C043A6B77; Wed, 26 Nov 2008 23:19:34 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9463A6CCA for ; Wed, 26 Nov 2008 23:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=0.525, 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 KQchfsPJ4yxp for ; Wed, 26 Nov 2008 23:19:33 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 322253A6CC9 for ; Wed, 26 Nov 2008 23:19:32 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 29226D800C0; Thu, 27 Nov 2008 08:19:27 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <492D61B6.2080909@netconfcentral.com> References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> <492C578D.6010407@netconfcentral.com> <492D496D.9070707@ericsson.com> <492D61B6.2080909@netconfcentral.com> Organization: CESNET Date: Thu, 27 Nov 2008 08:19:26 +0100 Message-Id: <1227770366.7128.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDI2LiAxMS4gMjAwOCB2IDA2OjQ4IC0wODAwOgo+IEJh bGF6cyBMZW5neWVsIHdyb3RlOgo+ID4gSGVsbG8sCj4gPiBJIGFsd2F5cyBmb3VuZCBpdCB1Z2x5 IGFuZCBzdXJwcmlzaW5nIHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIG1ha2Ugc3R1ZmYgCj4gPiBp biB0aGUgbW9kdWxlIHZpc2libGUgdG8gc3VibW9kdWxlcy4gSSB0aGluayB0aGlzIHdpbGwgbGVh ZCB0byBxdWl0ZSBhIAo+ID4gbnVtYmVyIG9mIG5lYXIgZW1wdHkgKG1haW4pIG1vZHVsZXMuCj4g PiBBcyBBbmR5IGhhcyBzaG93biB0aGVyZSBpcyBhIHdvcmthcm91bmQsIGJ1dCBpdCBpcyBhIHdv cmthcm91bmQuCj4gCj4gCj4gSXQgaXMgdGhlIHdheSBzdWJtb2R1bGVzIHdvcmsuCj4gCj4gSSB0 aGluayB0aGUgY3VycmVudCBydWxlcyBhcmUgT0suCj4gSWYgZm9vIGluY2x1ZGVzIHN1Yi1mb28s IGFuZCBzdWItZm9vIGNhbiBpbmNsdWRlIGl0cyBwYXJlbnQgJ2ZvbycsCj4gdGhhdCBpcyBubyBk aWZmZXJlbnQgdGhhbiBtb2R1bGUgQSBpbXBvcnRpbmcgQiBhbmQgQiBpbXBvcnRpbmcgQS4KClRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHN1Ym1vZHVsZSBhbmQgaXRzIHBhcmVudCBtb2R1bGUg aXMgZml4ZWQgaW4KYm90aCBkaXJlY3Rpb25zICh2aWEgaW5jbHVkZSBhbmQgYmVsb25ncy10byks IHNvIEkgc2VlIG5vIHJlYXNvbiB3aHkgdGhlCnN1Ym1vZHVsZSBjYW5ub3QgdXNlIHRoZSB0b3At bGV2ZWwgc3ltYm9scyBkZWZpbmVkIGluIHRoZSBwYXJlbnQgbW9kdWxlCnJpZ2h0IGF3YXkuIFRo ZSBzdWJtb2R1bGUgZXZlbiBub3cgY2Fubm90IG92ZXJyaWRlIGRlZmluaXRpb25zIGFwcGVhcmlu ZwppbiB0aGUgcGFyZW50IG1vZHVsZSBiZWNhdXNlIHRoZXkgd291bGQgY2xhc2ggd2hlbiB0aGUg c3VibW9kdWxlIGlzCmluY2x1ZGVkLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVU ClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Sun Nov 30 08:37: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 377B33A6940; Sun, 30 Nov 2008 08:37:14 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8B73A6945 for ; Sun, 30 Nov 2008 08:37:13 -0800 (PST) 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 AHXUY4-so2ky for ; Sun, 30 Nov 2008 08:37:12 -0800 (PST) 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 741803A6940 for ; Sun, 30 Nov 2008 08:37:12 -0800 (PST) Received: (qmail 15319 invoked from network); 30 Nov 2008 16:37:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2008 16:37:07 -0000 X-YMail-OSG: fb8qd.sVM1lWfyuSURU4qOCb7njEfe_39gGiPt7R6LIpZN_VHYyX49ivZNnpd2fOPTnF2cOaZxN4SDttgLyNySCroUr6YOCStZMosP5QqJkvGXW9kd6yS1e21xp_0Jcpdmk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4932C131.5070400@netconfcentral.com> Date: Sun, 30 Nov 2008 08:37:05 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ladislav Lhotka References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> <492C578D.6010407@netconfcentral.com> <492D496D.9070707@ericsson.com> <492D61B6.2080909@netconfcentral.com> <1227770366.7128.22.camel@missotis> In-Reply-To: <1227770366.7128.22.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTdCAyNi4gMTEu IDIwMDggdiAwNjo0OCAtMDgwMDoKPj4gQmFsYXpzIExlbmd5ZWwgd3JvdGU6Cj4+PiBIZWxsbywK Pj4+IEkgYWx3YXlzIGZvdW5kIGl0IHVnbHkgYW5kIHN1cnByaXNpbmcgdGhhdCB0aGVyZSBpcyBu byB3YXkgdG8gbWFrZSBzdHVmZiAKPj4+IGluIHRoZSBtb2R1bGUgdmlzaWJsZSB0byBzdWJtb2R1 bGVzLiBJIHRoaW5rIHRoaXMgd2lsbCBsZWFkIHRvIHF1aXRlIGEgCj4+PiBudW1iZXIgb2YgbmVh ciBlbXB0eSAobWFpbikgbW9kdWxlcy4KPj4+IEFzIEFuZHkgaGFzIHNob3duIHRoZXJlIGlzIGEg d29ya2Fyb3VuZCwgYnV0IGl0IGlzIGEgd29ya2Fyb3VuZC4KPj4KPj4gSXQgaXMgdGhlIHdheSBz dWJtb2R1bGVzIHdvcmsuCj4+Cj4+IEkgdGhpbmsgdGhlIGN1cnJlbnQgcnVsZXMgYXJlIE9LLgo+ PiBJZiBmb28gaW5jbHVkZXMgc3ViLWZvbywgYW5kIHN1Yi1mb28gY2FuIGluY2x1ZGUgaXRzIHBh cmVudCAnZm9vJywKPj4gdGhhdCBpcyBubyBkaWZmZXJlbnQgdGhhbiBtb2R1bGUgQSBpbXBvcnRp bmcgQiBhbmQgQiBpbXBvcnRpbmcgQS4KPiAKPiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBz dWJtb2R1bGUgYW5kIGl0cyBwYXJlbnQgbW9kdWxlIGlzIGZpeGVkIGluCj4gYm90aCBkaXJlY3Rp b25zICh2aWEgaW5jbHVkZSBhbmQgYmVsb25ncy10byksIHNvIEkgc2VlIG5vIHJlYXNvbiB3aHkg dGhlCj4gc3VibW9kdWxlIGNhbm5vdCB1c2UgdGhlIHRvcC1sZXZlbCBzeW1ib2xzIGRlZmluZWQg aW4gdGhlIHBhcmVudCBtb2R1bGUKPiByaWdodCBhd2F5LiBUaGUgc3VibW9kdWxlIGV2ZW4gbm93 IGNhbm5vdCBvdmVycmlkZSBkZWZpbml0aW9ucyBhcHBlYXJpbmcKPiBpbiB0aGUgcGFyZW50IG1v ZHVsZSBiZWNhdXNlIHRoZXkgd291bGQgY2xhc2ggd2hlbiB0aGUgc3VibW9kdWxlIGlzCj4gaW5j bHVkZWQuCj4gCgpJIHByZWZlciB0aGUgY3VycmVudCBhcHByb2FjaCwgd2hpY2ggaXMgdGhhdCBl dmVyeSBzeW1ib2wKZXh0ZXJuYWwgdG8gdGhlIGZpbGUgbXVzdCBiZSBpbXBvcnRlZCwgaW5jbHVk ZWQsIG9yIGEKWUFORyBrZXl3b3JkIG9yIGJ1aWx0aW4gdHlwZSBuYW1lLgoKSSBwcmVmZXIgbm90 IHRvIGFkZCBhbnkgbW9yZSBjb21wbGV4aXR5IGZvciByZWR1bmRhbnQgb3IgcmFyZSB1c2UgY2Fz ZXMuCllvdSBqdXN0IGhhdmUgdG8gdG8gZGVmaW5lIHRoZSBkYXRhIHN0cnVjdHVyZSBpbiBhIHN1 Ym1vZHVsZS4gIFlvdSBjYW4KbW92ZSBhbiBvYmplY3QgZnJvbSB0aGUgbWFpbiBtb2R1bGUgdG8g YSBzdWJtb2R1bGUgYXMgd2VsbCAocmV2aXNpb24Kc2VjLiBzaG91bGQgYWxsb3cgdGhpcykuCgpU aGUgb3RoZXIgb3B0aW9uczoKCiAgIDEpIGxldCBtYWluIG1vZHVsZSBzeW1ib2xzIG1hZ2ljYWxs eSBhcHBlYXIgaW4gc3VibW9kdWxlcwogICAyKSBpbnZlbnQgYSBuZXcgJ2luY2x1ZGUtZnJvbS1t YWluLW1vZHVsZScgbWVjaGFuaXNtCgphcmUgbm90IGFjY2VwdGFibGUsIElNTy4KCgoKCj4gTGFk YQo+IAoKQW5keQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sun Nov 30 10:05: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 8C8CA28C163; Sun, 30 Nov 2008 10:05:38 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491EF28C163 for ; Sun, 30 Nov 2008 10:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 f0WoUTQalPD2 for ; Sun, 30 Nov 2008 10:05:36 -0800 (PST) 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 97DA628C15E for ; Sun, 30 Nov 2008 10:05:36 -0800 (PST) Received: (qmail 55455 invoked from network); 30 Nov 2008 18:05:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.95 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2008 18:05:31 -0000 X-YMail-OSG: MdztbnUVM1n1ZkGhP6hskekG7NoJ6XN8bTMYPzBOKMWBJnbDsw2MXysDmeb0KTqfS.O4dFLeGiri5MdMQrfkYlseFB1PdzZt5g.9rSXuBMfMzdj7sVMjBd3y0zjKsVpmL_s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4932D5E9.1090104@netconfcentral.com> Date: Sun, 30 Nov 2008 10:05:29 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] yang-02 examples nits X-BeenThere: netmod@ietf.org 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, These are nits, but we all know many people in a hurry learn from the examples, and (!) skip some of the normative text. 1) pg 91.: augment example uses type ChannelNumber, which is not defined anywhere 2) sec. 9.4.5: 2nd and 3rd constructs should be legal YANG. The type clause cannot appear alone, and this example is confusing. E.g., OLD: type my-base-str-type { // legal length refinement length "11 | 42..max"; // 11 | 42..255 } NEW: typedef my-legal-refinement { type my-base-str-type { // legal length refinement length "11 | 42..max"; // 11 | 42..255 } } 3) sec. 9.6.5: it would be good to show an enumeration example that has complex identifiers, to point out how different they are from bit names. e.g.: typedef my-display-duplex { type enumeration { enum 'half duplex'; enum 'full duplex'; enum 'unknown duplex'; } } Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 30 11:45: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 D9F9228C164; Sun, 30 Nov 2008 11:45:42 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81EF128C166 for ; Sun, 30 Nov 2008 11:45:41 -0800 (PST) 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 xuotRN1Y1S4C for ; Sun, 30 Nov 2008 11:45:40 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id E9F9528C164 for ; Sun, 30 Nov 2008 11:45:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSTLtWAO4ec7CiM2N2WMez4JeQ1W8NnO1@postini.com; Sun, 30 Nov 2008 11:45:36 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Sun, 30 Nov 2008 11:42:49 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 11:42:48 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 11:42:48 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 11:42:48 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAUJglM46376; Sun, 30 Nov 2008 11:42:47 -0800 (PST) (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 mAUJbZbK085399; Sun, 30 Nov 2008 19:37:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811301937.mAUJbZbK085399@idle.juniper.net> To: Andy Bierman In-Reply-To: <4932D5E9.1090104@netconfcentral.com> Date: Sun, 30 Nov 2008 14:37:35 -0500 From: Phil Shafer X-OriginalArrivalTime: 30 Nov 2008 19:42:48.0067 (UTC) FILETIME=[D2B2E530:01C95323] MIME-Version: 1.0 Cc: NETMOD Working Group Subject: Re: [netmod] yang-02 examples nits X-BeenThere: netmod@ietf.org 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 writes: > 1) pg 91.: augment example uses type ChannelNumber, which is not > defined anywhere Given that examples are not meant to be fully self-contained, I'm not sure I see an issue here. ChannelNumber may be defined elsewhere in the module, not all of which is included in the example. > 2) sec. 9.4.5: 2nd and 3rd constructs should be legal YANG. > The type clause cannot appear alone, and this example is confusing. This type clause can appear inside a leaf or a typedef. The examples aren't meant to be self-contained, so the enclosing statements are not included. > 3) sec. 9.6.5: it would be good to show an enumeration example > that has complex identifiers, to point out how different > they are from bit names. > typedef my-display-duplex { > type enumeration { > enum 'half duplex'; > enum 'full duplex'; > enum 'unknown duplex'; > } > } If we need this, we should use a better example, since half is a better encoding. Personally I think this (the ability of a enum to contain a space) is a minor point nor worthy of an example. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Nov 30 23: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 09CFC3A6826; Sun, 30 Nov 2008 23:02:03 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35673A6896 for ; Sun, 30 Nov 2008 23:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.450, 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 c5sH273Isqg8 for ; Sun, 30 Nov 2008 23:02:01 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F11773A6826 for ; Sun, 30 Nov 2008 23:02:00 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BD630D800BD; Mon, 1 Dec 2008 08:01:56 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4932C131.5070400@netconfcentral.com> References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> <492C578D.6010407@netconfcentral.com> <492D496D.9070707@ericsson.com> <492D61B6.2080909@netconfcentral.com> <1227770366.7128.22.camel@missotis> <4932C131.5070400@netconfcentral.com> Organization: CESNET Date: Mon, 01 Dec 2008 08:01:56 +0100 Message-Id: <1228114916.6259.14.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 QW5keSBCaWVybWFuIHDDrcWhZSB2IE5lIDMwLiAxMS4gMjAwOCB2IDA4OjM3IC0wODAwOgo+IExh ZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IEFuZHkgQmllcm1hbiBww63FoWUgdiBTdCAyNi4gMTEu IDIwMDggdiAwNjo0OCAtMDgwMDoKPiA+PiBCYWxhenMgTGVuZ3llbCB3cm90ZToKPiA+Pj4gSGVs bG8sCj4gPj4+IEkgYWx3YXlzIGZvdW5kIGl0IHVnbHkgYW5kIHN1cnByaXNpbmcgdGhhdCB0aGVy ZSBpcyBubyB3YXkgdG8gbWFrZSBzdHVmZiAKPiA+Pj4gaW4gdGhlIG1vZHVsZSB2aXNpYmxlIHRv IHN1Ym1vZHVsZXMuIEkgdGhpbmsgdGhpcyB3aWxsIGxlYWQgdG8gcXVpdGUgYSAKPiA+Pj4gbnVt YmVyIG9mIG5lYXIgZW1wdHkgKG1haW4pIG1vZHVsZXMuCj4gPj4+IEFzIEFuZHkgaGFzIHNob3du IHRoZXJlIGlzIGEgd29ya2Fyb3VuZCwgYnV0IGl0IGlzIGEgd29ya2Fyb3VuZC4KPiA+Pgo+ID4+ IEl0IGlzIHRoZSB3YXkgc3VibW9kdWxlcyB3b3JrLgo+ID4+Cj4gPj4gSSB0aGluayB0aGUgY3Vy cmVudCBydWxlcyBhcmUgT0suCj4gPj4gSWYgZm9vIGluY2x1ZGVzIHN1Yi1mb28sIGFuZCBzdWIt Zm9vIGNhbiBpbmNsdWRlIGl0cyBwYXJlbnQgJ2ZvbycsCj4gPj4gdGhhdCBpcyBubyBkaWZmZXJl bnQgdGhhbiBtb2R1bGUgQSBpbXBvcnRpbmcgQiBhbmQgQiBpbXBvcnRpbmcgQS4KPiA+IAo+ID4g VGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgc3VibW9kdWxlIGFuZCBpdHMgcGFyZW50IG1vZHVs ZSBpcyBmaXhlZCBpbgo+ID4gYm90aCBkaXJlY3Rpb25zICh2aWEgaW5jbHVkZSBhbmQgYmVsb25n cy10byksIHNvIEkgc2VlIG5vIHJlYXNvbiB3aHkgdGhlCj4gPiBzdWJtb2R1bGUgY2Fubm90IHVz ZSB0aGUgdG9wLWxldmVsIHN5bWJvbHMgZGVmaW5lZCBpbiB0aGUgcGFyZW50IG1vZHVsZQo+ID4g cmlnaHQgYXdheS4gVGhlIHN1Ym1vZHVsZSBldmVuIG5vdyBjYW5ub3Qgb3ZlcnJpZGUgZGVmaW5p dGlvbnMgYXBwZWFyaW5nCj4gPiBpbiB0aGUgcGFyZW50IG1vZHVsZSBiZWNhdXNlIHRoZXkgd291 bGQgY2xhc2ggd2hlbiB0aGUgc3VibW9kdWxlIGlzCj4gPiBpbmNsdWRlZC4KPiA+IAo+IAo+IEkg cHJlZmVyIHRoZSBjdXJyZW50IGFwcHJvYWNoLCB3aGljaCBpcyB0aGF0IGV2ZXJ5IHN5bWJvbAo+ IGV4dGVybmFsIHRvIHRoZSBmaWxlIG11c3QgYmUgaW1wb3J0ZWQsIGluY2x1ZGVkLCBvciBhCj4g WUFORyBrZXl3b3JkIG9yIGJ1aWx0aW4gdHlwZSBuYW1lLgo+IAo+IEkgcHJlZmVyIG5vdCB0byBh ZGQgYW55IG1vcmUgY29tcGxleGl0eSBmb3IgcmVkdW5kYW50IG9yIHJhcmUgdXNlIGNhc2VzLgo+ IFlvdSBqdXN0IGhhdmUgdG8gdG8gZGVmaW5lIHRoZSBkYXRhIHN0cnVjdHVyZSBpbiBhIHN1Ym1v ZHVsZS4gIFlvdSBjYW4KPiBtb3ZlIGFuIG9iamVjdCBmcm9tIHRoZSBtYWluIG1vZHVsZSB0byBh IHN1Ym1vZHVsZSBhcyB3ZWxsIChyZXZpc2lvbgo+IHNlYy4gc2hvdWxkIGFsbG93IHRoaXMpLgo+ IAo+IFRoZSBvdGhlciBvcHRpb25zOgo+IAo+ICAgIDEpIGxldCBtYWluIG1vZHVsZSBzeW1ib2xz IG1hZ2ljYWxseSBhcHBlYXIgaW4gc3VibW9kdWxlcwoKSSBkb24ndCB0aGluayB0aGVyZSBpcyBh bnkgbWFnaWMgaW4gZG9pbmcgc28sIGJlY2F1c2Ugb2YgdGhlIGJlbG9uZ3MtdG8Kc3RhdGVtZW50 LiBUaGUgaXNvbGF0aW9uIGJldHdlZW4gdGhlIG1haW4gbW9kdWxlIGFuZCBzdWJtb2R1bGUgaXMg d2Vhawphbnl3YXkgaW4gdGhhdCBzeW1ib2xzIGZyb20gYSBzdWJtb2R1bGUgY2FuIGNsYXNoIHdp dGggdGhvc2UgaW4gdGhlIG1haW4KbW9kdWxlLCBzbyBub3QgYmVpbmcgYWJsZSB0byB1c2UgZGVm aW5pdGlvbnMgZnJvbSB0aGUgbWFpbiBtb2R1bGUgaXMKanVzdCBhbiBhcnRpZmljaWFsIGFubm95 YW5jZSB3aXRob3V0IGFueSBiZW5lZml0LgoKTGFkYQoKPiAgICAyKSBpbnZlbnQgYSBuZXcgJ2lu Y2x1ZGUtZnJvbS1tYWluLW1vZHVsZScgbWVjaGFuaXNtCj4gCj4gYXJlIG5vdCBhY2NlcHRhYmxl LCBJTU8uCj4gCj4gCj4gCj4gCj4gPiBMYWRhCj4gPiAKPiAKPiBBbmR5Cj4gCi0tIApMYWRpc2xh diBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Dec 1 00:24: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 7341D3A6909; Mon, 1 Dec 2008 00:24:27 -0800 (PST) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9563A3A691C for ; Mon, 1 Dec 2008 00:24:26 -0800 (PST) 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 4T4LMMayCYEv for ; Mon, 1 Dec 2008 00:24:25 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 81ABC3A6909 for ; Mon, 1 Dec 2008 00:24:25 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 88675204FC; Mon, 1 Dec 2008 09:24:20 +0100 (CET) X-AuditID: c1b4fb3e-aef86bb00000537b-01-49339f346d85 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71B1E200ED; Mon, 1 Dec 2008 09:24:20 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 09:24:16 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 09:24:16 +0100 Message-ID: <49339F30.5060905@ericsson.com> Date: Mon, 01 Dec 2008 09:24:16 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <1227633322.6288.112.camel@missotis> <492C35A9.4040902@netconfcentral.com> <1227642179.14326.2.camel@missotis> <492C578D.6010407@netconfcentral.com> <492D496D.9070707@ericsson.com> <492D61B6.2080909@netconfcentral.com> <1227770366.7128.22.camel@missotis> <4932C131.5070400@netconfcentral.com> In-Reply-To: <4932C131.5070400@netconfcentral.com> X-OriginalArrivalTime: 01 Dec 2008 08:24:16.0553 (UTC) FILETIME=[33289990:01C9538E] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] augment target X-BeenThere: netmod@ietf.org 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 CgpBbmR5IEJpZXJtYW4gd3JvdGU6Cj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+PiBBbmR5IEJp ZXJtYW4gcMOtxaFlIHYgU3QgMjYuIDExLiAyMDA4IHYgMDY6NDggLTA4MDA6Cj4+PiBCYWxhenMg TGVuZ3llbCB3cm90ZToKPj4+PiBIZWxsbywKPj4+PiBJIGFsd2F5cyBmb3VuZCBpdCB1Z2x5IGFu ZCBzdXJwcmlzaW5nIHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIG1ha2UgCj4+Pj4gc3R1ZmYgaW4g dGhlIG1vZHVsZSB2aXNpYmxlIHRvIHN1Ym1vZHVsZXMuIEkgdGhpbmsgdGhpcyB3aWxsIGxlYWQg dG8gCj4+Pj4gcXVpdGUgYSBudW1iZXIgb2YgbmVhciBlbXB0eSAobWFpbikgbW9kdWxlcy4KPj4+ PiBBcyBBbmR5IGhhcyBzaG93biB0aGVyZSBpcyBhIHdvcmthcm91bmQsIGJ1dCBpdCBpcyBhIHdv cmthcm91bmQuCj4+Pgo+Pj4gSXQgaXMgdGhlIHdheSBzdWJtb2R1bGVzIHdvcmsuCj4+Pgo+Pj4g SSB0aGluayB0aGUgY3VycmVudCBydWxlcyBhcmUgT0suCj4+PiBJZiBmb28gaW5jbHVkZXMgc3Vi LWZvbywgYW5kIHN1Yi1mb28gY2FuIGluY2x1ZGUgaXRzIHBhcmVudCAnZm9vJywKPj4+IHRoYXQg aXMgbm8gZGlmZmVyZW50IHRoYW4gbW9kdWxlIEEgaW1wb3J0aW5nIEIgYW5kIEIgaW1wb3J0aW5n IEEuCj4+Cj4+IFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHN1Ym1vZHVsZSBhbmQgaXRzIHBh cmVudCBtb2R1bGUgaXMgZml4ZWQgaW4KPj4gYm90aCBkaXJlY3Rpb25zICh2aWEgaW5jbHVkZSBh bmQgYmVsb25ncy10byksIHNvIEkgc2VlIG5vIHJlYXNvbiB3aHkgdGhlCj4+IHN1Ym1vZHVsZSBj YW5ub3QgdXNlIHRoZSB0b3AtbGV2ZWwgc3ltYm9scyBkZWZpbmVkIGluIHRoZSBwYXJlbnQgbW9k dWxlCj4+IHJpZ2h0IGF3YXkuIFRoZSBzdWJtb2R1bGUgZXZlbiBub3cgY2Fubm90IG92ZXJyaWRl IGRlZmluaXRpb25zIGFwcGVhcmluZwo+PiBpbiB0aGUgcGFyZW50IG1vZHVsZSBiZWNhdXNlIHRo ZXkgd291bGQgY2xhc2ggd2hlbiB0aGUgc3VibW9kdWxlIGlzCj4+IGluY2x1ZGVkLgo+Pgo+IAo+ IEkgcHJlZmVyIHRoZSBjdXJyZW50IGFwcHJvYWNoLCB3aGljaCBpcyB0aGF0IGV2ZXJ5IHN5bWJv bAo+IGV4dGVybmFsIHRvIHRoZSBmaWxlIG11c3QgYmUgaW1wb3J0ZWQsIGluY2x1ZGVkLCBvciBh Cj4gWUFORyBrZXl3b3JkIG9yIGJ1aWx0aW4gdHlwZSBuYW1lLgo+IAo+IEkgcHJlZmVyIG5vdCB0 byBhZGQgYW55IG1vcmUgY29tcGxleGl0eSBmb3IgcmVkdW5kYW50IG9yIHJhcmUgdXNlIGNhc2Vz Lgo+IFlvdSBqdXN0IGhhdmUgdG8gdG8gZGVmaW5lIHRoZSBkYXRhIHN0cnVjdHVyZSBpbiBhIHN1 Ym1vZHVsZS4gIFlvdSBjYW4KPiBtb3ZlIGFuIG9iamVjdCBmcm9tIHRoZSBtYWluIG1vZHVsZSB0 byBhIHN1Ym1vZHVsZSBhcyB3ZWxsIChyZXZpc2lvbgo+IHNlYy4gc2hvdWxkIGFsbG93IHRoaXMp Lgo+IApJTUhPIHRoaXMgaXMgbm90IHN1Y2ggYSByYXJlIGNhc2UuIE91ciBkZXNpZ25lcnMgaGF2 ZSBiZWVuIGFza2luZyBmb3IgaXQgYWxyZWFkeS4KV2UgY2FuIGxpdmUgd2l0aCB0aGUgY3VycmVu dCBzb2x1dGlvbiwgYnV0IGl0J3Mgbm90IG5pY2UuCkJhbGF6cwpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBp ZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo=