From netmod-bounces@ietf.org Tue Sep 2 04:30: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 E26913A69F9; Tue, 2 Sep 2008 04:30:10 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FEF3A69FB for ; Tue, 2 Sep 2008 04:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+2Wr8xp5Jxe for ; Tue, 2 Sep 2008 04:30:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3B0C13A69F9 for ; Tue, 2 Sep 2008 04:30:08 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 260E920D69 for ; Tue, 2 Sep 2008 13:30:13 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-d0-48bd23c5704b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 17AE520D01 for ; Tue, 2 Sep 2008 13:30:13 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 13:30:03 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 13:30:03 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 2 Sep 2008 13:30:02 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200809021330.03163.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Sep 2008 11:30:03.0426 (UTC) FILETIME=[3E08F020:01C90CEF] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Experiment: FAQ jabber "sprint" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, We'd like to try a little experiment as a different way of working within the working group. This initial experiment will _not_ be on chartered work, since we want to see how it goes before we try to apply it to chartered work. We will meet in the IETF's NETMOD Jabber room (jabber.ietf.org is the server, netmod is the room) and work on the FAQs listed at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/YANG_FAQ The meeting will be one week from today (September 9) at 12:30 (California)/15:30 (East Coast)/21:30 (Central Europe)/ 03:30 (on the 3rd) (Tokyo) The idea is to discuss the questions "live" and fill in the answers as well as potentially asking new FAQs. Jabber logs will be available after-the-fact for anyone who wishes to see what happened. Those are available at http://jabber.ietf.org/logs/netmod/ (look for the appropriate date... fascinating that there are logs from LONG before there was a working group). I've tried to maximize the ability of people from all over to participate, but that's not easy. I'm keenly aware that this time is not good for everyone when we're spread out all over the globe. I'm also aware that this means that some people cannot participate since their corporate policies do not allow them to use jabber. Both of these are issues when considering using this for "official" working group business. Hope to see a great many of you there! Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 2 14:58:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCFD3A6AB3; Tue, 2 Sep 2008 14:58:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEE63A6AB3 for ; Tue, 2 Sep 2008 14:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt14RVx9WIlA for ; Tue, 2 Sep 2008 14:58:19 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id EE9B83A6A07 for ; Tue, 2 Sep 2008 14:58:18 -0700 (PDT) Received: (qmail 80655 invoked from network); 2 Sep 2008 21:58:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 2 Sep 2008 21:58:20 -0000 X-YMail-OSG: ix3UzhgVM1krHaT1fIi7WZW22RFrEdSqpWd9dMmHAX.I76xBJo_OnSZurrPJVJtR9tPh0TJ8e_.Kb4hFas1lDG9xDddQxTO4c2NEfOm2Yw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BDB6FA.3020904@netconfcentral.com> Date: Tue, 02 Sep 2008 14:58:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I noticed that the ipfix-psamp module is using the revision-stmt differently than envisioned. Each new draft is updating the same revision-stmt instead of adding new ones. Although this seems like just a stylistic choice, it has an impact on import-by-revision. The WG needs to understand the inter-module dependency issues at some point, and make some decisions how its going to work. (At the interim I guess.) Here are some questions I have... Does 1 YANG file represent 1 revision or N revisions? If 1, how do inter-operable applications manage all the YANG files, and know about all the older versions? If not, how are multiple revisions identified within a module? How are the contents of module M.n locked forever, such that any developer will easily understand what definition versions are part of version n, even if the current module version is M.n+i? How are the contents of a grouping G.n locked forever when used in different modules, such that version G.n+i does not impact a module that is using G.n? What does it mean to change the revision of a sub-module but not the main module? Are sub-module versions part of the module version capabilities? If not, why are they needed? Clearly, all forms on semantic 'non-changes' are allowed (e.g., change from inline to named type or typedef default to a leaf default with the same value). What types of actual semantic changes are allowed from V.n to V.n+1, if any? The module containing the augmenting objects tracks the conformance and version info, not the module that contains the augmented objects. How are version dependencies between the two modules expressed and managed? What role does the SMI notion of status (current/deprecated/obsolete) really play in the YANG module framework? Is it really even relevant if revision dates are used explicitly within the framework? If so, then what are all the impacts of mixing current, deprecated, and obsolete objects for all aspects of YANG data modeling? If an object is declared deprecated or obsolete, does than mean all versions of the module that include that object are also deprecated or obsolete? What about modules that use groupings with such objects? What about modules that augment such objects? How does this status ripple through the versions? It is assumed a module is 'safe' using old versions until and unless it is ever updated? How will this really work? What if the changes are through imports which the organization has no change control for? Are there any rules for multiple versions of the same module within the same agent? Is this significant increase in agent complexity really what the WG wants? (e.g., foo.n for every definition instead of just foo) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 00:03: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 308723A68FE; Wed, 3 Sep 2008 00:03:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9FE3A6BFD for ; Wed, 3 Sep 2008 00:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.149, 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 tGNdu+bStV4x for ; Wed, 3 Sep 2008 00:03:55 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A4D633A68FE for ; Wed, 3 Sep 2008 00:03:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 467CC76C2AB; Wed, 3 Sep 2008 09:04:01 +0200 (CEST) Date: Wed, 03 Sep 2008 09:04:31 +0200 (CEST) Message-Id: <20080903.090431.95309092.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48BDB6FA.3020904@netconfcentral.com> References: <48BDB6FA.3020904@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] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 noticed that the ipfix-psamp module is using the revision-stmt > differently than envisioned. Each new draft is updating the > same revision-stmt instead of adding new ones. > Although this seems like just a stylistic choice, it has > an impact on import-by-revision. But isn't this perfectly fine for work in progress? Once it's published, the revision statement must not change, and the not-yet-defined version control rules must be followed. Doesn't this happen with MIBs in drafts as well? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 00:37:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D89E3A6A59; Wed, 3 Sep 2008 00:37:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97533A6C07 for ; Wed, 3 Sep 2008 00:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iyhyHRJ8rUZ for ; Wed, 3 Sep 2008 00:37:47 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 2990C3A6A59 for ; Wed, 3 Sep 2008 00:37:47 -0700 (PDT) Received: (qmail 48262 invoked from network); 3 Sep 2008 07:35:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2008 07:35:36 -0000 X-YMail-OSG: TxCmJzQVM1l2qYKjigE1nytP0dOflxwYVSn12uHuJ8_w2k.gAcpkCo66flrHEIQI9IBRcqvqO3SHMDJubhVhxZ0Hktyx_PIeyUdWZnmWKiWgboze_ppdd9SXUOOwvvk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BE3E46.1050303@netconfcentral.com> Date: Wed, 03 Sep 2008 00:35:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48BDB6FA.3020904@netconfcentral.com> <20080903.090431.95309092.mbj@tail-f.com> In-Reply-To: <20080903.090431.95309092.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> I noticed that the ipfix-psamp module is using the revision-stmt >> differently than envisioned. Each new draft is updating the >> same revision-stmt instead of adding new ones. >> Although this seems like just a stylistic choice, it has >> an impact on import-by-revision. > > But isn't this perfectly fine for work in progress? Once it's > published, the revision statement must not change, and the > not-yet-defined version control rules must be followed. Doesn't this > happen with MIBs in drafts as well? > sort of. This assumes nobody will implement an Internet Draft and everybody will always wait for the RFC before placing the module in any sort of real system. I question the robustness of this assumption, as reality does not concur wrt/ MIB deployment. > > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 00:51: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 684FD3A6C55; Wed, 3 Sep 2008 00:51:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254693A6A59 for ; Wed, 3 Sep 2008 00:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 rbUi6DPAZZ1X for ; Wed, 3 Sep 2008 00:51:35 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id D9CD83A6C3A for ; Wed, 3 Sep 2008 00:50:57 -0700 (PDT) Received: (qmail 34982 invoked from network); 3 Sep 2008 07:50:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2008 07:50:07 -0000 X-YMail-OSG: R4Ot9MsVM1mK5A_UF.DneK3WMwV6VVn3nPJsqA4q5I4M53xId3S6cEznGW9LLoNRQGHlqBTrzHZqRennuaC1Z8sJ93MfpRZZczi8OyreW6piBTse5KHqXzxUTFxGANo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BE41AD.60608@netconfcentral.com> Date: Wed, 03 Sep 2008 00:50:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48BDB6FA.3020904@netconfcentral.com> <20080903.090431.95309092.mbj@tail-f.com> In-Reply-To: <20080903.090431.95309092.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> I noticed that the ipfix-psamp module is using the revision-stmt >> differently than envisioned. Each new draft is updating the >> same revision-stmt instead of adding new ones. >> Although this seems like just a stylistic choice, it has >> an impact on import-by-revision. > > But isn't this perfectly fine for work in progress? Once it's > published, the revision statement must not change, and the > not-yet-defined version control rules must be followed. Doesn't this > happen with MIBs in drafts as well? > > This also is not really a problem in SMIv2 because there are no YANG-style groupings, and conformance is explicit (i.e., every object enumerated), not implied like YANG. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 01:05: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 5C7C83A6B85; Wed, 3 Sep 2008 01:05:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB7C3A6C3F for ; Wed, 3 Sep 2008 01:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-0.799, 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 39H7YXH3eiwk for ; Wed, 3 Sep 2008 01:05:30 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 738133A6C30 for ; Wed, 3 Sep 2008 01:05:30 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E8FFD76C4D8; Wed, 3 Sep 2008 10:05:35 +0200 (CEST) Date: Wed, 03 Sep 2008 10:06:08 +0200 (CEST) Message-Id: <20080903.100608.11667281.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48B7F26D.7080805@netconfcentral.com> References: <48B7AF8F.3000201@netconfcentral.com> <20080829.103223.156479567.mbj@tail-f.com> <48B7F26D.7080805@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > You don't need to send any data to have a security problem. > > If I have access to 1 list entry (that uses the unique-stmt), > then I can simply use a trial-and-error brute force attack, > and keep setting the leaf I want to uncover to different > values. As soon as I get back a data-not-unique error, > I know one of the entries has that value. Further attacks > may or may not be possible from that point. This logic can be applied to other constraints as well. For example, if there's a constraint that a > b, and the user has access to b, but not a, he can try to set b to different values and note when validate fails to figure out the value of a. So is the conclusion that no data models should contain constraints? I hope not. Is the conclusion that when validation fails, we should not try to help the operator by giving precise error messages? I hope not. Or is the conclusion that implementations should apply access control to the errors? This might be tricky. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 01:07: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 865C33A693A; Wed, 3 Sep 2008 01:07:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECFF3A6C30 for ; Wed, 3 Sep 2008 01:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.219, 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 ypA6xuKz5cBn for ; Wed, 3 Sep 2008 01:07:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B14503A693A for ; Wed, 3 Sep 2008 01:07:12 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3831376C2AB; Wed, 3 Sep 2008 10:07:19 +0200 (CEST) Date: Wed, 03 Sep 2008 10:07:49 +0200 (CEST) Message-Id: <20080903.100749.168125879.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48BE41AD.60608@netconfcentral.com> References: <48BDB6FA.3020904@netconfcentral.com> <20080903.090431.95309092.mbj@tail-f.com> <48BE41AD.60608@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] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 noticed that the ipfix-psamp module is using the revision-stmt > >> differently than envisioned. Each new draft is updating the > >> same revision-stmt instead of adding new ones. > >> Although this seems like just a stylistic choice, it has > >> an impact on import-by-revision. > > But isn't this perfectly fine for work in progress? Once it's > > published, the revision statement must not change, and the > > not-yet-defined version control rules must be followed. Doesn't this > > happen with MIBs in drafts as well? > > > > This also is not really a problem in SMIv2 because > there are no YANG-style groupings, and conformance > is explicit (i.e., every object enumerated), not > implied like YANG. An object might be defined in the -00 MIB, and simply removed before published as an RFC. It's not marked as obsolete, is it? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 05:41: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 0F6153A6980; Wed, 3 Sep 2008 05:41:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A423A6A58 for ; Wed, 3 Sep 2008 05:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjZLZCAHUQSN for ; Wed, 3 Sep 2008 05:41:32 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id CE5BE3A6980 for ; Wed, 3 Sep 2008 05:41:32 -0700 (PDT) Received: (qmail 7911 invoked from network); 3 Sep 2008 12:40:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2008 12:40:53 -0000 X-YMail-OSG: zwU9SAAVM1knJwaOhTawImofb1fLXpGbddYv..1casujb.N3PoZw5MzRMgoXAZdwekigwVzGaLp9O9LqmF9Ahxt69GZSAOUw.NweGytGEFR8HNrSAAGEccgDWS8HGI8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BE85D4.6030105@netconfcentral.com> Date: Wed, 03 Sep 2008 05:40:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48B7AF8F.3000201@netconfcentral.com> <20080829.103223.156479567.mbj@tail-f.com> <48B7F26D.7080805@netconfcentral.com> <20080903.100608.11667281.mbj@tail-f.com> In-Reply-To: <20080903.100608.11667281.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> You don't need to send any data to have a security problem. >> >> If I have access to 1 list entry (that uses the unique-stmt), >> then I can simply use a trial-and-error brute force attack, >> and keep setting the leaf I want to uncover to different >> values. As soon as I get back a data-not-unique error, >> I know one of the entries has that value. Further attacks >> may or may not be possible from that point. > > This logic can be applied to other constraints as well. For example, > if there's a constraint that a > b, and the user has access to b, but > not a, he can try to set b to different values and note when validate > fails to figure out the value of a. > > So is the conclusion that no data models should contain constraints? > I hope not. of course not > > Is the conclusion that when validation fails, we should not try to > help the operator by giving precise error messages? I hope not. > > Or is the conclusion that implementations should apply access control > to the errors? This might be tricky. > yes, but it needs to be considered eventually. I agree that punting access control completely provides some cover for now (not that I agreed with punting the ACM ;-). So it may be good enough for YANG to say "do not leak any unauthorized data via XPath expressions, such as the predicates defining key/value pairs". If part of the target config is not accessible by the user, and the validate-before-commit is going to fail, then does the user even have access to the part that failed? Is it possible, or is this a variant of Wes's shared buffer deadlock (2 users edit the config, each w/different access, and suddenly neither can commit.) Getting code to actually comply with access control on error messages may be another story. It's just not gonna happen. Nobody will bother pushing their access control code that far down into rpc-error code. When an ACM is standardized, the conceptual procedure can be broken into steps, and if the user does not have enough access to do the commit (or edit-config on running), then the must and unique tests will never even get run. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 05:42: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 3689B3A67B2; Wed, 3 Sep 2008 05:42:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91DC3A686B for ; Wed, 3 Sep 2008 05:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=0.021, 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 MhHMkcr3-ALr for ; Wed, 3 Sep 2008 05:42:28 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id B192D3A67B2 for ; Wed, 3 Sep 2008 05:42:28 -0700 (PDT) Received: (qmail 8881 invoked from network); 3 Sep 2008 12:42:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2008 12:42:09 -0000 X-YMail-OSG: D8n7BAUVM1n9169is3aLtmdvwB9MH9H0kC60vNc0zB83H08wYz3rjQ9.nJDgr1aBPJHLcIJWECPYHae2aMn3KSJblThnFwCWbRorZXex6N92OFxB9xh32fmyKRTeOF4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BE8620.1030302@netconfcentral.com> Date: Wed, 03 Sep 2008 05:42:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48BDB6FA.3020904@netconfcentral.com> <20080903.090431.95309092.mbj@tail-f.com> <48BE41AD.60608@netconfcentral.com> <20080903.100749.168125879.mbj@tail-f.com> In-Reply-To: <20080903.100749.168125879.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> Andy Bierman wrote: >>>> I noticed that the ipfix-psamp module is using the revision-stmt >>>> differently than envisioned. Each new draft is updating the >>>> same revision-stmt instead of adding new ones. >>>> Although this seems like just a stylistic choice, it has >>>> an impact on import-by-revision. >>> But isn't this perfectly fine for work in progress? Once it's >>> published, the revision statement must not change, and the >>> not-yet-defined version control rules must be followed. Doesn't this >>> happen with MIBs in drafts as well? >>> >> This also is not really a problem in SMIv2 because >> there are no YANG-style groupings, and conformance >> is explicit (i.e., every object enumerated), not >> implied like YANG. > > An object might be defined in the -00 MIB, and simply removed before > published as an RFC. It's not marked as obsolete, is it? > no, but every version of the MIB module conformance statements clearly identifies everything in that version. YANG has nothing like that. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 05:45: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 AF8463A6901; Wed, 3 Sep 2008 05:45:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95ED03A6A1D for ; Wed, 3 Sep 2008 05:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 yupz8OCTjtUJ for ; Wed, 3 Sep 2008 05:44:58 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id AE35E3A6901 for ; Wed, 3 Sep 2008 05:44:56 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Wed, 03 Sep 2008 05:41:45 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 05:42:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 05:42:46 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Sep 2008 05:42:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id m83Cgjf77595; Wed, 3 Sep 2008 05:42:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m83CcwKw063301; Wed, 3 Sep 2008 12:38:58 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809031238.m83CcwKw063301@idle.juniper.net> To: Andy Bierman In-reply-to: <48BE3E46.1050303@netconfcentral.com> Date: Wed, 03 Sep 2008 08:38:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Sep 2008 12:42:46.0107 (UTC) FILETIME=[90CEFAB0:01C90DC2] Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >This assumes nobody will implement an Internet Draft and >everybody will always wait for the RFC before placing the module in >any sort of real system. I question the robustness of this >assumption, as reality does not concur wrt/ MIB deployment. Actually this would be where import-by-revision shines, since if someone mungs the revision statement, my import will fail and the problem will be immediately detected. Given the axiom: cost(build-time-error) < cost(run-time-error) this means import-by-revision is a savings. >This also is not really a problem in SMIv2 because >there are no YANG-style groupings, and conformance >is explicit (i.e., every object enumerated), not >implied like YANG. Sure, but there are instance identifiers which could refer to objects that are deleted from newer drafts of the mib, and lots of other ways to hurt oneself. But import-by-revision means you will detect all these issues at build time, when the compiler tells you there's no such revision of some module. Your build fails until you fix the problem. Or your application tells the user something evil is afoot and asks if they want to get the right module or just pretend that things are a-o-kay. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 06:21:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D123A6983; Wed, 3 Sep 2008 06:21:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338FC3A6983 for ; Wed, 3 Sep 2008 06:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=0.764, 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 jxETce-iFgIl for ; Wed, 3 Sep 2008 06:21:23 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 68E0D3A6B34 for ; Wed, 3 Sep 2008 06:21:07 -0700 (PDT) Received: (qmail 38318 invoked from network); 3 Sep 2008 13:20:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2008 13:20:52 -0000 X-YMail-OSG: OylQetUVM1nBNwCxNQrxE4GJvDDBycKLxS6EZ7i9jY03sKz.PbSFoG56ESQY_ABiRfnHf6zwhIIxWlpZ.ffZQ0s.e.s66rISaVLu52caqg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BE8F32.703@netconfcentral.com> Date: Wed, 03 Sep 2008 06:20:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809031238.m83CcwKw063301@idle.juniper.net> In-Reply-To: <200809031238.m83CcwKw063301@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> This assumes nobody will implement an Internet Draft and >> everybody will always wait for the RFC before placing the module in >> any sort of real system. I question the robustness of this >> assumption, as reality does not concur wrt/ MIB deployment. > > Actually this would be where import-by-revision shines, since if > someone mungs the revision statement, my import will fail and the > problem will be immediately detected. Given the axiom: > > cost(build-time-error) < cost(run-time-error) > > this means import-by-revision is a savings. > I don't see how import-by-revision has anything to do with with detecting errors at runtime. The issue is whether the compiler uses deterministic machine-readable mechanisms built into YANG to do the job, or whether the programmer does it manually by reading the description clauses. If the contents of a previous revision are only captured in a description clause, if at all, it is unclear how the compiler accomplishes this task. >> This also is not really a problem in SMIv2 because >> there are no YANG-style groupings, and conformance >> is explicit (i.e., every object enumerated), not >> implied like YANG. > > Sure, but there are instance identifiers which could refer to objects > that are deleted from newer drafts of the mib, and lots of other > ways to hurt oneself. > > But import-by-revision means you will detect all these issues at > build time, when the compiler tells you there's no such revision > of some module. Your build fails until you fix the problem. Or > your application tells the user something evil is afoot and asks > if they want to get the right module or just pretend that things > are a-o-kay. That's great. I'm just a bit fuzzy on some details. Like all of them. How does the whole thing work? Exactly? What are the answers to all the other questions raised in my first mail? > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 07:33:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBC43A6873; Wed, 3 Sep 2008 07:33:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEB13A6873 for ; Wed, 3 Sep 2008 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksQGUzM9pvM9 for ; Wed, 3 Sep 2008 07:33:09 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 1F7E53A6A61 for ; Wed, 3 Sep 2008 07:33:09 -0700 (PDT) Received: (qmail 21288 invoked from network); 3 Sep 2008 14:33:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2008 14:33:15 -0000 X-YMail-OSG: qFHth4oVM1n_5gG6OpZ73u155TtceR4uOcVbzS03CEHtLa.Gs6WVWhaLtMiMezOXSG.6SbDaW5CaOZJz1jMAgKS8s3I.6dmrl83jHuoHFw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BEA029.5040109@netconfcentral.com> Date: Wed, 03 Sep 2008 07:33:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809031238.m83CcwKw063301@idle.juniper.net> In-Reply-To: <200809031238.m83CcwKw063301@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: ... > Actually this would be where import-by-revision shines, I support import-by-revision in concept. I agree with you that we should avoid enumerating all the object identifiers by hand. We cannot rely on the output of free tools in a standard, and must assume any SMIv2-like GROUP construct would be input manually. Even if machine-generated, verbosity becomes an issue. IMO, this new approach can only work with the following rules: 1) Versioning MUST be built into the framework, like it is for Python or any other modern programming language. 2) A revision date (or some new mechanism) MUST be present to serve as a revision identifier in every YANG module (but optional in submodules?). 3) An IETF document containing a YANG module MUST update the revision identifier every time it is published. All other documents: SHOULD instead of MUST. The identifier semantics must provide deterministic cardinality. Strict change controls will also be needed, very TBD, in order to support 'import >= min-version'. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 08:37: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 0A8F23A6A91; Wed, 3 Sep 2008 08:37:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3183A6BE1 for ; Wed, 3 Sep 2008 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_31=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 HJ7n7orHezaV for ; Wed, 3 Sep 2008 08:37:50 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 369FB3A67D9 for ; Wed, 3 Sep 2008 08:37:48 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 03 Sep 2008 08:37:27 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 08:36:39 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 08:36:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 08:36:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m83Fabu18182; Wed, 3 Sep 2008 08:36:37 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m83FWrKC065155; Wed, 3 Sep 2008 15:32:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809031532.m83FWrKC065155@idle.juniper.net> To: Andy Bierman In-reply-to: <48BE8F32.703@netconfcentral.com> Date: Wed, 03 Sep 2008 11:32:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Sep 2008 15:36:38.0977 (UTC) FILETIME=[DB489B10:01C90DDA] Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I don't see how import-by-revision has anything >to do with with detecting errors at runtime. >The issue is whether the compiler uses deterministic >machine-readable mechanisms built into YANG to do >the job, or whether the programmer does it manually >by reading the description clauses. Scenario: On Sept 1st, I make revision 2008-08-01 of the "foo" module containing "grouping foober". The next week, I add a new leaf to "foober" and change the revision to "2008-08-08". You have a module that includes my FOO, so when you recompile, you'll get an error saying the "cannot find revision 2008-08-01 of module foo". You must update your module with the new import, and (hopefully) vet the new version to know that it's sane and works with your module. >What are the answers to all the other questions raised >in my first mail? Sorry, I answered the reply. Here you go: >Does 1 YANG file represent 1 revision or N revisions? Each YANG file is a specific revision of the module. >If 1, how do inter-operable applications manage all the >YANG files, and know about all the older versions? An application may need a full catalog of all revisions of a module. These revisions should be available at locations returned from the data model discovery mechanism (in the monitoring draft). If the application has a cached copy of the specific revision of the module, it can use it, but if it doesn't it just downloads it as directed. >How are the contents of module M.n locked forever, >such that any developer will easily understand >what definition versions are part of version n, >even if the current module version is M.n+i? We need change rules for published standards, but these rules are unlikely to apply to work-in-progress modules. Applications and tool sets may need mechanisms to clear or "unlearn" the contents of a module, since one wouldn't want to be forced to change the revision during debugging and development. >How are the contents of a grouping G.n locked forever >when used in different modules, such that version G.n+i does >not impact a module that is using G.n? These change rules are not defined yet, and again the w-i-p issues remain. >What does it mean to change the revision of a sub-module but >not the main module? Are sub-module versions part of the >module version capabilities? If not, why are they needed? I hadn't wanted to do "include by revision", but if the client downloads multiple revisions of submodules as part of supporting multiple revisions of modules, it forces us to have modules specify the revision of the module that is being used. Ugly, but unavoidable. >Clearly, all forms on semantic 'non-changes' are allowed >(e.g., change from inline to named type or typedef default >to a leaf default with the same value). What types of >actual semantic changes are allowed from V.n to V.n+1, if any? Open question. Given that the revisions allow the application to discover the specifics of the modules supported, semantic changes are more an issue of "I want my app to be ignorant" than "my app can't learn". I want simple ignorant apps, but how do we weigh their benefit against the cost of our change rules? >The module containing the augmenting objects tracks >the conformance and version info, not the module >that contains the augmented objects. How are version >dependencies between the two modules expressed and managed? If I implement the augmenting module, it specifies the revision of the module being augmented, forcing a 1:1 mapping. >What role does the SMI notion of status (current/deprecated/obsolete) >really play in the YANG module framework? Is it really >even relevant if revision dates are used explicitly >within the framework? If so, then what are all the >impacts of mixing current, deprecated, and obsolete >objects for all aspects of YANG data modeling? "deprecated" and "obsolete" are giant warning flags saying "do not go here". Apps should avoid, but devices should implement. That said, my guess is that most of the device deviations will be of the form "I didn't bother implementing that obsolete stuff". >If an object is declared deprecated or obsolete, >does than mean all versions of the module that >include that object are also deprecated or obsolete? No. It's a warning to app developers. It's like saying your grandparents are old and shouldn't be working on the farm. It doesn't stop 'em from working, but you shouldn't depend on 'em. They make work fine for years, but, well, okay the analogy falls apart pretty quick. >What about modules that use groupings with such objects? Nope. >What about modules that augment such objects? Nope. >How does this status ripple through the versions? It doesn't. Can a WG deprecate something, but then make it current after chasing out the members that deprecated it? >It is assumed a module is 'safe' using old versions >until and unless it is ever updated? Safe? Unknown. Static? Yes, which is often enough. If I augment fooV1 and no one implements it (implementing fooV2 instead), no one will care about my module. If I use types/groupings from fooV1, it doesn't matter if everyone jumps on fooV2, since my module will still work. But if fooV1 is a loser, I'm still stuck choosing between going my own way and rejoining the herd on fooV2. >How will this >really work? What if the changes are through imports >which the organization has no change control for? This gives motivation to examine the organizations which make modules upon which your module depends. Are they suitable in terms of process, stability, and longevity? >Are there any rules for multiple versions of the >same module within the same agent? Multiple revisions of the same module are permitted, since I make make a base-internet-types module, on which ospf is based, but then add a type for isis. Devices can implement both ospf and isis without waiting for ospf to revised with the new revision of the base-internet-types module. >Is this significant >increase in agent complexity really what the WG wants? >(e.g., foo.n for every definition instead of just foo) I think the cost on the device is small and fixed. The cost on the app side is worse, but I'd rather concentrate my complexity on the app side, where resources are less constrained and updates, fixes, and downloads are simpler. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 3 09:03:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD503A6CA6; Wed, 3 Sep 2008 09:03:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5218A3A6CAD for ; Wed, 3 Sep 2008 09:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgjIrUN-L9P6 for ; Wed, 3 Sep 2008 09:03:42 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 175C33A6CA6 for ; Wed, 3 Sep 2008 09:03:42 -0700 (PDT) Received: (qmail 79614 invoked from network); 3 Sep 2008 16:03:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2008 16:03:04 -0000 X-YMail-OSG: XusEdEEVM1mYN3YM6DXnmwx.LgV8oam17jO6Gv_87yCnw0sUCP.02pydhbRgJRmNJblpA3V9OFohz6Add0Nen1thmiqMCd5OTFgLxLYLfA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BEB537.6080001@netconfcentral.com> Date: Wed, 03 Sep 2008 09:03:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809031532.m83FWrKC065155@idle.juniper.net> In-Reply-To: <200809031532.m83FWrKC065155@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I don't see how import-by-revision has anything >> to do with with detecting errors at runtime. >> The issue is whether the compiler uses deterministic >> machine-readable mechanisms built into YANG to do >> the job, or whether the programmer does it manually >> by reading the description clauses. > > Scenario: On Sept 1st, I make revision 2008-08-01 of the "foo" > module containing "grouping foober". The next week, I add a new > leaf to "foober" and change the revision to "2008-08-08". You have > a module that includes my FOO, so when you recompile, you'll get > an error saying the "cannot find revision 2008-08-01 of module foo". > You must update your module with the new import, and (hopefully) > vet the new version to know that it's sane and works with your > module. > >> What are the answers to all the other questions raised >> in my first mail? > > Sorry, I answered the reply. Here you go: > OK -- Im in, but there is still a lot of hand-waving that needs to be filled in. We all emphasize various parts of the project, and my pet peeve is that pesky IETF goal: "multiple independent inter-operating implementations" Coming up with super-cool features is only half the battle. Writing them down so that interoperability is achieved is the the rest of the battle. Ignoring the actual realization of the conceptual revision library sounds good on standards paper, but not in reality. SNMP experience has shown that ignoring simple practical matters, such as file naming conventions and file formats, has led to little or no cross-toolset interoperability. No mix-and-match, unless scripted or by hand. Other WGs are addressing these issues in their solution space, and so should NETMOD WG. (e.g., the NETMOD WG should define a top-level element, for reusable storage of or output, as XML instance documents. This was never done by the NETCONF WG. Everybody does this with different proprietary top-level elements now.) Andy >> Does 1 YANG file represent 1 revision or N revisions? > > Each YANG file is a specific revision of the module. > >> If 1, how do inter-operable applications manage all the >> YANG files, and know about all the older versions? > > An application may need a full catalog of all revisions of a module. > These revisions should be available at locations returned from the > data model discovery mechanism (in the monitoring draft). If the > application has a cached copy of the specific revision of the module, > it can use it, but if it doesn't it just downloads it as directed. > >> How are the contents of module M.n locked forever, >> such that any developer will easily understand >> what definition versions are part of version n, >> even if the current module version is M.n+i? > > We need change rules for published standards, but these rules are > unlikely to apply to work-in-progress modules. Applications and > tool sets may need mechanisms to clear or "unlearn" the contents > of a module, since one wouldn't want to be forced to change the > revision during debugging and development. > >> How are the contents of a grouping G.n locked forever >> when used in different modules, such that version G.n+i does >> not impact a module that is using G.n? > > These change rules are not defined yet, and again the w-i-p issues > remain. > >> What does it mean to change the revision of a sub-module but >> not the main module? Are sub-module versions part of the >> module version capabilities? If not, why are they needed? > > I hadn't wanted to do "include by revision", but if the client > downloads multiple revisions of submodules as part of supporting > multiple revisions of modules, it forces us to have modules specify > the revision of the module that is being used. Ugly, but unavoidable. > >> Clearly, all forms on semantic 'non-changes' are allowed >> (e.g., change from inline to named type or typedef default >> to a leaf default with the same value). What types of >> actual semantic changes are allowed from V.n to V.n+1, if any? > > Open question. Given that the revisions allow the application to > discover the specifics of the modules supported, semantic changes > are more an issue of "I want my app to be ignorant" than "my app > can't learn". I want simple ignorant apps, but how do we weigh > their benefit against the cost of our change rules? > >> The module containing the augmenting objects tracks >> the conformance and version info, not the module >> that contains the augmented objects. How are version >> dependencies between the two modules expressed and managed? > > If I implement the augmenting module, it specifies the revision > of the module being augmented, forcing a 1:1 mapping. > >> What role does the SMI notion of status (current/deprecated/obsolete) >> really play in the YANG module framework? Is it really >> even relevant if revision dates are used explicitly >> within the framework? If so, then what are all the >> impacts of mixing current, deprecated, and obsolete >> objects for all aspects of YANG data modeling? > > "deprecated" and "obsolete" are giant warning flags saying "do not > go here". Apps should avoid, but devices should implement. > > That said, my guess is that most of the device deviations will be > of the form "I didn't bother implementing that obsolete stuff". > >> If an object is declared deprecated or obsolete, >> does than mean all versions of the module that >> include that object are also deprecated or obsolete? > > No. It's a warning to app developers. It's like saying your > grandparents are old and shouldn't be working on the farm. It > doesn't stop 'em from working, but you shouldn't depend on 'em. > They make work fine for years, but, well, okay the analogy falls > apart pretty quick. > >> What about modules that use groupings with such objects? > > Nope. > >> What about modules that augment such objects? > > Nope. > >> How does this status ripple through the versions? > > It doesn't. Can a WG deprecate something, but then make it > current after chasing out the members that deprecated it? > >> It is assumed a module is 'safe' using old versions >> until and unless it is ever updated? > > Safe? Unknown. Static? Yes, which is often enough. If I augment > fooV1 and no one implements it (implementing fooV2 instead), no one > will care about my module. If I use types/groupings from fooV1, > it doesn't matter if everyone jumps on fooV2, since my module will > still work. But if fooV1 is a loser, I'm still stuck choosing > between going my own way and rejoining the herd on fooV2. > >> How will this >> really work? What if the changes are through imports >> which the organization has no change control for? > > This gives motivation to examine the organizations which make > modules upon which your module depends. Are they suitable in > terms of process, stability, and longevity? > >> Are there any rules for multiple versions of the >> same module within the same agent? > > Multiple revisions of the same module are permitted, since I make > make a base-internet-types module, on which ospf is based, but then > add a type for isis. Devices can implement both ospf and isis > without waiting for ospf to revised with the new revision of the > base-internet-types module. > >> Is this significant >> increase in agent complexity really what the WG wants? >> (e.g., foo.n for every definition instead of just foo) > > I think the cost on the device is small and fixed. The cost on the > app side is worse, but I'd rather concentrate my complexity on the > app side, where resources are less constrained and updates, fixes, > and downloads are simpler. > > Thanks, > Phil > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 05:22: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 AC7B33A6922; Thu, 4 Sep 2008 05:22:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510FC3A6A34 for ; Thu, 4 Sep 2008 05:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgJl17-sioIy for ; Thu, 4 Sep 2008 05:22:33 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 11FFF3A6B75 for ; Thu, 4 Sep 2008 05:22:32 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 18F1E616001; Thu, 4 Sep 2008 14:22:39 +0200 (CEST) Date: Thu, 04 Sep 2008 14:23:12 +0200 (CEST) Message-Id: <20080904.142312.15300961.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200809031532.m83FWrKC065155@idle.juniper.net> References: <48BE8F32.703@netconfcentral.com> <200809031532.m83FWrKC065155@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >How are the contents of module M.n locked forever, > >such that any developer will easily understand > >what definition versions are part of version n, > >even if the current module version is M.n+i? Is this really a problem we want to solve? IMO, if you need to know what version n looks like, you have to find M.n. You cannot deduce this info from M.n+i. > >How are the contents of a grouping G.n locked forever > >when used in different modules, such that version G.n+i does > >not impact a module that is using G.n? If a module uses the grouping from G.n, it doesn't matter what the grouping looks like in G.n+i. However, from a client perspective it matters. > These change rules are not defined yet, and again the w-i-p issues > remain. Right, but I think you will be allowed to add non-mandatory nodes to a grouping in a new revision. > >What does it mean to change the revision of a sub-module but > >not the main module? Are sub-module versions part of the > >module version capabilities? If not, why are they needed? > > I hadn't wanted to do "include by revision", but if the client > downloads multiple revisions of submodules as part of supporting > multiple revisions of modules, it forces us to have modules specify > the revision of the module that is being used. Ugly, but unavoidable. :( But you're right. > >The module containing the augmenting objects tracks > >the conformance and version info, not the module > >that contains the augmented objects. How are version > >dependencies between the two modules expressed and managed? > > If I implement the augmenting module, it specifies the revision > of the module being augmented, forcing a 1:1 mapping. Do you mean that if A.k imports and augments M.n, then a device that announces A.k MUST announce M.n, even if there is a M.n+i which the device really wants to support? IMO, if A.k imports and augments M.n, the a device that announces A.k can announce any M.n+i i>= 0. This will work if you cannot remove things from a module, which is what we're looking at anyway. > >It is assumed a module is 'safe' using old versions > >until and unless it is ever updated? > > Safe? Unknown. Static? Yes, which is often enough. If I augment > fooV1 and no one implements it (implementing fooV2 instead), no one > will care about my module. So in my view, your module will work just fine with fooV2 (unless the stuff you augement is obsolete in foov2 of course). > >Are there any rules for multiple versions of the > >same module within the same agent? > > Multiple revisions of the same module are permitted, since I make > make a base-internet-types module, on which ospf is based, but then > add a type for isis. Devices can implement both ospf and isis > without waiting for ospf to revised with the new revision of the > base-internet-types module. Right, but the agent will implement data-definitions and rpcs and notifications from *one* version of the module, which is announced. It might have to implement groupings and typedefs from older versions as well, but these versions are not announced in hello (but present in the monitoring model). > >Is this significant > >increase in agent complexity really what the WG wants? > >(e.g., foo.n for every definition instead of just foo) > > I think the cost on the device is small and fixed. The cost on the > app side is worse, but I'd rather concentrate my complexity on the > app side, where resources are less constrained and updates, fixes, > and downloads are simpler. +1 /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 07:14: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 1B13C3A68FD; Thu, 4 Sep 2008 07:14:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC82B3A6A9B for ; Thu, 4 Sep 2008 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yePLsdsikDWU for ; Thu, 4 Sep 2008 07:14:26 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 2534A3A68FD for ; Thu, 4 Sep 2008 07:14:26 -0700 (PDT) Received: (qmail 22470 invoked from network); 4 Sep 2008 14:13:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 4 Sep 2008 14:13:56 -0000 X-YMail-OSG: fUcwbWoVM1l7W37p3Yn.65VTrqOTBaj1km489N1xedSxza80FBD6vJMhOIXskLUr6I5zto8QLqqhdpOj7DnmNc_79HBSjhYTa__mIhDyNaVK1p6LQHfxzriK5SPDx_I- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BFED23.5020900@netconfcentral.com> Date: Thu, 04 Sep 2008 07:13:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48BE8F32.703@netconfcentral.com> <200809031532.m83FWrKC065155@idle.juniper.net> <20080904.142312.15300961.mbj@tail-f.com> In-Reply-To: <20080904.142312.15300961.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> How are the contents of module M.n locked forever, >>> such that any developer will easily understand >>> what definition versions are part of version n, >>> even if the current module version is M.n+i? > > Is this really a problem we want to solve? IMO, if you need to know > what version n looks like, you have to find M.n. You cannot deduce > this info from M.n+i. Sure, but will M.n+i identify the revision dates of previous versions or not? That is all I think is really needed. It is OK to lose all the prior version info for I-Ds, but not for previous versions in RFCs. IMO, a revision statement for each RFC version of the DM should be retained. > >>> How are the contents of a grouping G.n locked forever >>> when used in different modules, such that version G.n+i does >>> not impact a module that is using G.n? > > If a module uses the grouping from G.n, it doesn't matter what the > grouping looks like in G.n+i. However, from a client perspective it > matters. I do not agree, especially if the agent has some common code for handling groupings. The change control rules for groupings will impact this issue quite a bit. What if module foo, which imports G.n, does not specify an optional revision date for the import? Then the compiler and user has no way of knowing that G.n+i MUST NOT be used when compiling foo. IMO, import-by-revision needs a lot of work to be ready for the IETF to use. There are way too many loopholes in the design now. > >> These change rules are not defined yet, and again the w-i-p issues >> remain. > > Right, but I think you will be allowed to add non-mandatory nodes to a > grouping in a new revision. > >>> What does it mean to change the revision of a sub-module but >>> not the main module? Are sub-module versions part of the >>> module version capabilities? If not, why are they needed? >> I hadn't wanted to do "include by revision", but if the client >> downloads multiple revisions of submodules as part of supporting >> multiple revisions of modules, it forces us to have modules specify >> the revision of the module that is being used. Ugly, but unavoidable. > > :( But you're right. I do not really like submodules at all. They do not add any value to the standard, just complexity. IMO they must not alter the interface presented to the manager, which is defined by the module, not the submodule. The module revision-stmts are what counts -- the author needs to keep them up-to-date. Let's say acme.com decides it would be a really great idea to put all 12000 XML knobs in the same namespace, in 697 separate sub-modules. Is the poor DM reader supposed to track down every file by hand to determine the module version, to determine the module changed? What if a WG decides to be clever, and publish a main module in 1 RFC and submodules in another RFC. Then it updates the sub-modules, publishes a new RFC to replace the sub-module RFC. Now the main module RFC revision date is wrong. How does an implementor know which version is implied by the main module RFC at this point? > > >>> The module containing the augmenting objects tracks >>> the conformance and version info, not the module >>> that contains the augmented objects. How are version >>> dependencies between the two modules expressed and managed? >> If I implement the augmenting module, it specifies the revision >> of the module being augmented, forcing a 1:1 mapping. > > Do you mean that if A.k imports and augments M.n, then a device that > announces A.k MUST announce M.n, even if there is a M.n+i which the > device really wants to support? > > IMO, if A.k imports and augments M.n, the a device that announces A.k > can announce any M.n+i i>= 0. This will work if you cannot remove > things from a module, which is what we're looking at anyway. > I agree that we want to support an 'import >= n' model, not an 'import == n' model. >>> It is assumed a module is 'safe' using old versions >>> until and unless it is ever updated? >> Safe? Unknown. Static? Yes, which is often enough. If I augment >> fooV1 and no one implements it (implementing fooV2 instead), no one >> will care about my module. > > So in my view, your module will work just fine with fooV2 (unless the > stuff you augement is obsolete in foov2 of course). > >>> Are there any rules for multiple versions of the >>> same module within the same agent? >> Multiple revisions of the same module are permitted, since I make >> make a base-internet-types module, on which ospf is based, but then >> add a type for isis. Devices can implement both ospf and isis >> without waiting for ospf to revised with the new revision of the >> base-internet-types module. > > Right, but the agent will implement data-definitions and rpcs and > notifications from *one* version of the module, which is announced. > It might have to implement groupings and typedefs from older versions > as well, but these versions are not announced in hello (but present in > the monitoring model). > I want to make sure that module foo upgrades ALL of its definitions from module bar, each time module foo is published. I do not want to apply a partial module update -- mix and match from all versions G.n to G.n+i within the foo module. I do not understand how they are identified either. How does the DM reader know that one 'uses' bar' is different than another 'uses bar' that gets expanded in the same module? That seems like a really bad idea. >>> Is this significant >>> increase in agent complexity really what the WG wants? >>> (e.g., foo.n for every definition instead of just foo) >> I think the cost on the device is small and fixed. The cost on the >> app side is worse, but I'd rather concentrate my complexity on the >> app side, where resources are less constrained and updates, fixes, >> and downloads are simpler. > > +1 > > > /martin > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 07:50: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 F3BD83A6BD5; Thu, 4 Sep 2008 07:50:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830203A680F for ; Thu, 4 Sep 2008 07:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAzh7NBZxKjZ for ; Thu, 4 Sep 2008 07:50:34 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E9C3C3A685A for ; Thu, 4 Sep 2008 07:50:33 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BB512616004; Thu, 4 Sep 2008 16:49:47 +0200 (CEST) Date: Thu, 04 Sep 2008 16:50:23 +0200 (CEST) Message-Id: <20080904.165023.71226779.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48BFED23.5020900@netconfcentral.com> References: <200809031532.m83FWrKC065155@idle.juniper.net> <20080904.142312.15300961.mbj@tail-f.com> <48BFED23.5020900@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] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > Sure, but will M.n+i identify the revision dates of previous versions > or not? That is all I think is really needed. > > It is OK to lose all the prior version info for I-Ds, > but not for previous versions in RFCs. IMO, a revision > statement for each RFC version of the DM should be retained. I agree. > >>> How are the contents of a grouping G.n locked forever > >>> when used in different modules, such that version G.n+i does > >>> not impact a module that is using G.n? > > If a module uses the grouping from G.n, it doesn't matter what the > > grouping looks like in G.n+i. However, from a client perspective it > > matters. > > I do not agree, especially if the agent has some common code > for handling groupings. The change control rules for groupings > will impact this issue quite a bit. >From a logical pow, if a module uses a grouping from G.n, the grouping is fixed, so how can it matter what happens to the grouping in G.n+i? I agree that depending on the change rules, an implementation might be able to take advantage of how groupings are upgraded, and it can do some clever stuff. But that's an implementation choice. > What if module foo, which imports G.n, does not specify an > optional revision date for the import? Then foo doesn't import G.n, it imports G., and foo is on his own. > Then the compiler and > user has no way of knowing that G.n+i MUST NOT be used > when compiling foo. The compiler will use whatever version of G it is given, when foo is compiled. I assume that IETF modules MUST always import by revision. > IMO, import-by-revision needs a lot > of work to be ready for the IETF to use. There are > way too many loopholes in the design now. Sure, the design is not written down yet. > What if a WG decides to be clever, and publish a main > module in 1 RFC and submodules in another RFC. > Then it updates the sub-modules, publishes a new RFC > to replace the sub-module RFC. Now the main module RFC > revision date is wrong. How does an implementor > know which version is implied by the main module RFC > at this point? If sub-modules are used within the IETF, I suspect the main module will be controlled by IANA, and IANA will update the main module whenever a new submodule is published. > >>> Are there any rules for multiple versions of the > >>> same module within the same agent? > >> Multiple revisions of the same module are permitted, since I make > >> make a base-internet-types module, on which ospf is based, but then > >> add a type for isis. Devices can implement both ospf and isis > >> without waiting for ospf to revised with the new revision of the > >> base-internet-types module. > > Right, but the agent will implement data-definitions and rpcs and > > notifications from *one* version of the module, which is announced. > > It might have to implement groupings and typedefs from older versions > > as well, but these versions are not announced in hello (but present in > > the monitoring model). > > > > > I want to make sure that module foo upgrades ALL of its definitions > from module bar, each time module foo is published. I do not > want to apply a partial module update -- mix and match from all > versions G.n to G.n+i within the foo module. I do not understand > how they are identified either. How does the DM reader know > that one 'uses' bar' is different than another 'uses bar' > that gets expanded in the same module? That seems like a really > bad idea. I fully agree with you, and that's not the intention. When foo 'uses G:bar' in multiple places, it will be the same version of G:bar. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 08:52: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 E365D3A6943; Thu, 4 Sep 2008 08:52:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49B83A6943 for ; Thu, 4 Sep 2008 08:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 6sRodfNmA+9j for ; Thu, 4 Sep 2008 08:52:29 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id CB58C3A6BFD for ; Thu, 4 Sep 2008 08:52:29 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 04 Sep 2008 08:50:45 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 08:51:45 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 08:51:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 08:51:45 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m84FpiM92831 for ; Thu, 4 Sep 2008 08:51:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m84Fm14x077507 for ; Thu, 4 Sep 2008 15:48:02 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809041548.m84Fm14x077507@idle.juniper.net> To: netmod@ietf.org Date: Thu, 04 Sep 2008 11:48:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Sep 2008 15:51:45.0267 (UTC) FILETIME=[21E33C30:01C90EA6] Subject: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.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 Please give feedback. Thanks, Phil ------- Forwarded Message From: IETF I-D Submission Tool To: phil@juniper.net Subject: New Version Notification for draft-shafer-netmod-arch-00 Date: Thu, 4 Sep 2008 08:49:49 -0700 (PDT) X-pstn-neptune: 0/0/0.00/0 X-pstn-levels: (S: 7.42583/99.90000 CV:99.9999 R:95.9108 P:95.9108 M:97.0282 C: ***98.6951 ) X-pstn-settings: 3 (1.0000:1.0000) s cv gt3 gt2 gt1 r p m c X-pstn-addresses: from [db-null] A new version of I-D, draft-shafer-netmod-arch-00.txt has been successfuly subm itted by Philip Shafer and posted to the IETF repository. Filename: draft-shafer-netmod-arch Revision: 00 Title: An Architecture for Network Management Creation_date: 2008-09-04 WG ID: Independent Submission Number_of_pages: 23 Abstract: NETCONF and YANG are pieces of an ambitious plan to improve network management. NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content trafficked via NETCONF, both data and operations. Using both technologies, the standards modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network services providers. An architecture is described which is friendly to both devices and applications, to vendors and standards bodies, to young and to old, to red states and to blue states. It's a startling vision, coming to networks near you starting August, 2009. The IETF Secretariat. ------- End of Forwarded Message _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 09:00: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 AA4843A6C47; Thu, 4 Sep 2008 09:00:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F423A6C36 for ; Thu, 4 Sep 2008 09:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkfDbLwm+Fej for ; Thu, 4 Sep 2008 09:00:00 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 2DD673A6943 for ; Thu, 4 Sep 2008 09:00:00 -0700 (PDT) Received: (qmail 42149 invoked from network); 4 Sep 2008 16:00:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 4 Sep 2008 16:00:06 -0000 X-YMail-OSG: 26hgIyQVM1nshbm4ajgANkzPe59zCNP7Gpzzof3TPFPl6ssPPX0dMN8e4xTF2MWu2QzjeEvueCylxJ9Af42EabG5VuIWa4kPQBbk94Ni5ePWT0AgGQxBSno9foTHeHA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C00604.7000100@netconfcentral.com> Date: Thu, 04 Sep 2008 09:00:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200809031532.m83FWrKC065155@idle.juniper.net> <20080904.142312.15300961.mbj@tail-f.com> <48BFED23.5020900@netconfcentral.com> <20080904.165023.71226779.mbj@tail-f.com> In-Reply-To: <20080904.165023.71226779.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: ... >> What if a WG decides to be clever, and publish a main >> module in 1 RFC and submodules in another RFC. >> Then it updates the sub-modules, publishes a new RFC >> to replace the sub-module RFC. Now the main module RFC >> revision date is wrong. How does an implementor >> know which version is implied by the main module RFC >> at this point? > > If sub-modules are used within the IETF, I suspect the main module > will be controlled by IANA, and IANA will update the main module > whenever a new submodule is published. > .... IMO, the contract between the manager and the agent is the module, not the sub-module. The submodules need to be invisible to the NETCONF protocol. IMO, there should be a new 'module-version' field, only in the main module, or just use the newest main module revision date, rather than advertise submodule revision dates. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 11:48:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A94C3A6CA7; Thu, 4 Sep 2008 11:48:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C233A6874 for ; Thu, 4 Sep 2008 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJVqCtHi2TxF for ; Thu, 4 Sep 2008 11:48:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9F12A3A6CD7 for ; Thu, 4 Sep 2008 11:46:14 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 3829C616008; Thu, 4 Sep 2008 20:45:42 +0200 (CEST) Date: Thu, 04 Sep 2008 20:45:44 +0200 (CEST) Message-Id: <20080904.204544.93831086.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48C00604.7000100@netconfcentral.com> References: <48BFED23.5020900@netconfcentral.com> <20080904.165023.71226779.mbj@tail-f.com> <48C00604.7000100@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] version control questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > IMO, the contract between the manager and > the agent is the module, not the sub-module. > > The submodules need to be invisible to the NETCONF protocol. > > IMO, there should be a new 'module-version' field, > only in the main module, or just use the newest > main module revision date, rather than advertise submodule > revision dates. Yes this is how it works. The module's latest revision is advertised. The submodules are invisible on this level. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 13:40: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 AD88A3A6D7B; Thu, 4 Sep 2008 13:40:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2833A6D7B for ; Thu, 4 Sep 2008 13:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[AWL=-0.511, 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 NnaOd0hseMBr for ; Thu, 4 Sep 2008 13:40:50 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 7058E3A6D86 for ; Thu, 4 Sep 2008 13:40:50 -0700 (PDT) Received: (qmail 30066 invoked from network); 4 Sep 2008 20:40:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 4 Sep 2008 20:40:57 -0000 X-YMail-OSG: VubthlgVM1nfBmpXNSTYQUm3Qwj7ZcObhCU.4wHapSB_X5py4pGjfFwI1QM_g27E18SUAuMikmvss.jI2G1fPFVatXCpOwYXNLwgmzqqLw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C047D7.80700@netconfcentral.com> Date: Thu, 04 Sep 2008 13:40:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809041548.m84Fm14x077507@idle.juniper.net> In-Reply-To: <200809041548.m84Fm14x077507@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Please give feedback. > I did a first pass, so I probably missed a lot. The parts about XML namespaces and augment are what I would expect to see in an NETMOD Arch document, but most major sections I would expect to see are not there: 1) Big picture summary of the NETCONF/NETMOD problem space - Evolve from CLI screen-scraping to programmatic device control - Take advantage of XML technologies - Learn from SMIng and other work already done in the IETF 2) System Components - Manager entity - Agent entity - NETCONF protocol - Transport mappings - YANG language - configuration data - rpc operations - notifications - YANG to YIN translation - YANG to DSDL translation 3) Sessions - User identity - Multi-session interactions 4) Databases - Editing - Locking - Filtered retrieval - Validation 5) Security 6) Life-cycle Management 7) Capabilities 8) Module Conformance I do not really agree with the architecture behind the picture on page 11. If there is any sort of 'transform' between the standard and the device, it is part of the agent implementation, not the architecture. An agent may use all sorts of tools to get from YANG modules to internal data structures, including none -- code by hand. I understand there is going to be a need to migrate from older proprietary DMs to newer standard DMs -- and that will always be the case, but it is just an implementation detail. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 4 14:15: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 1AFA93A67FC; Thu, 4 Sep 2008 14:15:03 -0700 (PDT) X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B3F93A68E4; Thu, 4 Sep 2008 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080904211501.9B3F93A68E4@core3.amsl.com> Date: Thu, 4 Sep 2008 14:15:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D ACTION:draft-ietf-netmod-yang-types-00.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-00.txt Pages : 62 Date : 2008-9-4 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-9-4140842.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --NextPart-- From netmod-bounces@ietf.org Fri Sep 5 08:47: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 98FFB3A6A22; Fri, 5 Sep 2008 08:47:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982763A6A94 for ; Fri, 5 Sep 2008 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[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 9AYiVE-rdiTc for ; Fri, 5 Sep 2008 08:47:40 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id DE2C53A6A70 for ; Fri, 5 Sep 2008 08:47:40 -0700 (PDT) Received: (qmail 79960 invoked from network); 5 Sep 2008 15:47:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.172.12 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 5 Sep 2008 15:47:30 -0000 X-YMail-OSG: meDlWAcVM1kZzBuy2JUEiogWBg.1600cANqM_jbdfPweEzz.Q0TVU2XzybrmH9pm8p0WDeyVcr9JZ3P4p_s9ycjT1RoEE6TxtDb_OwfFgw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C15491.4070700@netconfcentral.com> Date: Fri, 05 Sep 2008 08:47:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I think YANG needs one more built-in type, called object-identifier. It is just like instance-identifier, except no predicates ([key='value']) can be present. Sometimes you really want the leaf the indicate an object node in the conceptual tree (e.g. ACM), and not any particular instance. There is no easy way to auto-validate object-identifier, like there is for instance-identifier. The compiler does not automatically know the string is an absolute XPath expression, which must match some real path in the internal configuration database target. Just change 'string' to 'object-identifier', and that problem goes away. I also prefer not to overload instance-identifier. It should always refer to 1 particular instance of an object. That way, the compiler can check that the instance is specified correctly. A 3rd category, the XPath filter expression, may need its own data type as well. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 5 12:35:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F353A6808; Fri, 5 Sep 2008 12:35:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A793A6784 for ; Fri, 5 Sep 2008 12:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=0.402, 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 esNx-aU1G0FR for ; Fri, 5 Sep 2008 12:35:13 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 243CF3A6808 for ; Fri, 5 Sep 2008 12:35:13 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9C8D5D800C0 for ; Fri, 5 Sep 2008 21:35:11 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200809041548.m84Fm14x077507@idle.juniper.net> References: <200809041548.m84Fm14x077507@idle.juniper.net> Organization: CESNET Date: Fri, 05 Sep 2008 21:35:12 +0200 Message-Id: <1220643312.6352.46.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SGkgUGhpbCwKCnRoZSBwYXJ0IGFib3V0IERTREwgaXMgYW11c2luZyBidXQgSSB0aGluayBpdCBy YWlzZXMgYSBiaWcgcXVlc3Rpb24Kd2hldGhlciBpdCBtYWtlcyBzZW5zZSBhdCBhbGwgdG8gc3Bl bmQgY3ljbGVzIG9uIGl0LiBJIGRvbid0IGFncmVlIHdpdGgKdGhlIHZpZXcgdGhhdCBpdCBpcyBv bmx5IGdvb2QgZm9yIG1hbmFnZXJzIGFuZC9vciBwZW9wbGUgaW4gZW52aXJvbm1lbnRzCnRoYXQg aGF2ZW4ndCBiZWVuIGJsZXNzZWQgd2l0aCBZQU5HIHlldC4KCk15IHN1Z2dlc3Rpb24gaXMgdG8g ZGV2ZWxvcCB0aGUgWUFORy10by1EU0RMIG1hcHBpbmcgYXMgYSBtZWFucyBmb3IKc3BlY2lmeWlu ZyBmb3JtYWxseSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBZQU5HIG1vZGVsIGFuZApjb3Jy ZXNwb25kaW5nIE5FVENPTkYgUERVcy4gSW4gdGhlIFlBTkcgZHJhZnQsIHRoaXMgaXMgb25seSBz cGVjaWZpZWQgaW4KcHJvc2Ugb3IgYnkgZXhhbXBsZXMsIHNvIEkgdGhpbmsgdGhpcyB3b3VsZCBh Y3R1YWxseSBiZSBxdWl0ZSBhbgppbXBvcnRhbnQgc3BlY2lmaWNhdGlvbi4KCldoYXQgZG8geW91 IGZvbGtzIHRoaW5rIGFib3V0IGl0PwoKTGFkYQoKUGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDA0 LiAwOS4gMjAwOCB2IDExOjQ4IC0wNDAwOgo+IFBsZWFzZSBnaXZlIGZlZWRiYWNrLgo+IAo+IFRo YW5rcywKPiAgUGhpbAo+IAo+IAo+IC0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UKPiAKPiBGcm9t OiAgICAgSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIDxpZHN1Ym1pc3Npb25AaWV0Zi5vcmc+Cj4g VG86ICAgICAgIHBoaWxAanVuaXBlci5uZXQKPiBTdWJqZWN0OiAgTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1zaGFmZXItbmV0bW9kLWFyY2gtMDAgCj4gRGF0ZTogICAgIFRodSwg IDQgU2VwIDIwMDggMDg6NDk6NDkgLTA3MDAgKFBEVCkKPiBYLXBzdG4tbmVwdHVuZTogMC8wLzAu MDAvMAo+IFgtcHN0bi1sZXZlbHM6IChTOiA3LjQyNTgzLzk5LjkwMDAwIENWOjk5Ljk5OTkgUjo5 NS45MTA4IFA6OTUuOTEwOCBNOjk3LjAyODIgQzoKPiAgICAgICoqKjk4LjY5NTEgKQo+IFgtcHN0 bi1zZXR0aW5nczogMyAoMS4wMDAwOjEuMDAwMCkgcyBjdiBndDMgZ3QyIGd0MSByIHAgbSBjIAo+ IFgtcHN0bi1hZGRyZXNzZXM6IGZyb20gPGlkc3VibWlzc2lvbkBpZXRmLm9yZz4gW2RiLW51bGxd IAo+IAo+IAo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zaGFmZXItbmV0bW9kLWFyY2gt MDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWx5IHN1Ym0KPiBpdHRlZCBieSBQaGlsaXAgU2hhZmVy IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4KPiAKPiBGaWxlbmFtZToJIGRyYWZ0 LXNoYWZlci1uZXRtb2QtYXJjaAo+IFJldmlzaW9uOgkgMDAKPiBUaXRsZToJCSBBbiBBcmNoaXRl Y3R1cmUgZm9yIE5ldHdvcmsgTWFuYWdlbWVudAo+IENyZWF0aW9uX2RhdGU6CSAyMDA4LTA5LTA0 Cj4gV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbgo+IE51bWJlcl9vZl9wYWdlczogMjMK PiAKPiBBYnN0cmFjdDoKPiBORVRDT05GIGFuZCBZQU5HIGFyZSBwaWVjZXMgb2YgYW4gYW1iaXRp b3VzIHBsYW4gdG8gaW1wcm92ZSBuZXR3b3JrCj4gbWFuYWdlbWVudC4gIE5FVENPTkYgZ2l2ZXMg YWNjZXNzIHRvIG5hdGl2ZSBjYXBhYmlsaXRpZXMgb2YgdGhlCj4gZGV2aWNlcyB3aXRoaW4gYSBu ZXR3b3JrLCBkZWZpbmluZyBtZXRob2RzIGZvciBtYW5pcHVsYXRpbmcKPiBjb25maWd1cmF0aW9u IGRhdGFiYXNlcywgcmV0cmlldmluZyBvcGVyYXRpb25hbCBkYXRhLCBhbmQgaW52b2tpbmcKPiBz cGVjaWZpYyBvcGVyYXRpb25zLiAgWUFORyBwcm92aWRlcyB0aGUgbWVhbnMgdG8gZGVmaW5lIHRo ZSBjb250ZW50Cj4gdHJhZmZpY2tlZCB2aWEgTkVUQ09ORiwgYm90aCBkYXRhIGFuZCBvcGVyYXRp b25zLiAgVXNpbmcgYm90aAo+IHRlY2hub2xvZ2llcywgdGhlIHN0YW5kYXJkcyBtb2R1bGVzIGNh biBiZSBkZWZpbmVkIHRvIGdpdmUKPiBpbnRlcm9wZXJhYmlsaXR5IGFuZCBjb21tb25hbGl0eSB0 byBkZXZpY2VzLCB3aGlsZSBzdGlsbCBhbGxvd2luZwo+IGRldmljZXMgdG8gZXhwcmVzcyB0aGVp ciB1bmlxdWUgY2FwYWJpbGl0aWVzLgo+IAo+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBO RVRDT05GIGFuZCBZQU5HIGhlbHAgYnVpbGQgbmV0d29yawo+IG1hbmFnZW1lbnQgYXBwbGljYXRp b25zIHRoYXQgbWVldCB0aGUgbmVlZHMgb2YgbmV0d29yayBzZXJ2aWNlcwo+IHByb3ZpZGVycy4g IEFuIGFyY2hpdGVjdHVyZSBpcyBkZXNjcmliZWQgd2hpY2ggaXMgZnJpZW5kbHkgdG8gYm90aAo+ IGRldmljZXMgYW5kIGFwcGxpY2F0aW9ucywgdG8gdmVuZG9ycyBhbmQgc3RhbmRhcmRzIGJvZGll cywgdG8geW91bmcKPiBhbmQgdG8gb2xkLCB0byByZWQgc3RhdGVzIGFuZCB0byBibHVlIHN0YXRl cy4gIEl0J3MgYSBzdGFydGxpbmcKPiB2aXNpb24sIGNvbWluZyB0byBuZXR3b3JrcyBuZWFyIHlv dSBzdGFydGluZyBBdWd1c3QsIDIwMDkuCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo+ICAgIAo+ IAo+IAo+IFRoZSBJRVRGIFNlY3JldGFyaWF0Lgo+IAo+IAo+IC0tLS0tLS0gRW5kIG9mIEZvcndh cmRlZCBNZXNzYWdlCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3Rr YSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri Sep 5 12:49: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 93E5A3A6784; Fri, 5 Sep 2008 12:49:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598413A6978 for ; Fri, 5 Sep 2008 12:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQDNW4bOEfVn for ; Fri, 5 Sep 2008 12:49:01 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 66F0B3A6784 for ; Fri, 5 Sep 2008 12:49:00 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 05 Sep 2008 12:48:02 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Sep 2008 12:48:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Sep 2008 12:48:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Sep 2008 12:46:40 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m85JkdM00935; Fri, 5 Sep 2008 12:46:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m85JgtQD089220; Fri, 5 Sep 2008 19:42:55 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809051942.m85JgtQD089220@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1220643312.6352.46.camel@missotis> Date: Fri, 05 Sep 2008 15:42:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 Sep 2008 19:46:40.0025 (UTC) FILETIME=[1D6E6090:01C90F90] Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.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: >the part about DSDL is amusing but I think it raises a big question >whether it makes sense at all to spend cycles on it. I don't agree with >the view that it is only good for managers and/or people in environments >that haven't been blessed with YANG yet. I see your point re: the posibility of using DSDL on the device, but not the second point. If your tools supported YANG natively, when would you need the DSDL mapping? >My suggestion is to develop the YANG-to-DSDL mapping as a means for >specifying formally the relationship between a YANG model and >corresponding NETCONF PDUs. So the DSDL mapping should cover the PDUs, not the database we are building? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 5 13:02:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A471A3A6AA0; Fri, 5 Sep 2008 13:02:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7436E3A6B28 for ; Fri, 5 Sep 2008 13:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 fhAsfuXFPVC8 for ; Fri, 5 Sep 2008 13:02:55 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 808CF3A6AA0 for ; Fri, 5 Sep 2008 13:02:55 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Fri, 05 Sep 2008 13:00:24 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Sep 2008 13:01:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Sep 2008 13:01:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Sep 2008 13:01:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m85K1fM07828; Fri, 5 Sep 2008 13:01:41 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m85JvuYu089374; Fri, 5 Sep 2008 19:57:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809051957.m85JvuYu089374@idle.juniper.net> To: Andy Bierman In-reply-to: <48C047D7.80700@netconfcentral.com> Date: Fri, 05 Sep 2008 15:57:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 Sep 2008 20:01:43.0607 (UTC) FILETIME=[38020C70:01C90F92] Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.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: > 1) Big picture summary of the NETCONF/NETMOD problem space > - Evolve from CLI screen-scraping to programmatic device control > - Take advantage of XML technologies > - Learn from SMIng and other work already done in the IETF I was told to avoid "how we got here" and "marketing oriented" discussions. > 2) System Components > - Manager entity > - Agent entity > - NETCONF protocol > - Transport mappings So this should cover NETCONF architecture also? I discuss it a bit under the "NETCONF" section, but don't get into protocol operations and transport mappings. > - YANG language > - configuration data > - rpc operations > - notifications Will add some words on these. > - YANG to YIN translation > - YANG to DSDL translation I think this is there. > 3) Sessions > - User identity > - Multi-session interactions > 4) Databases > - Editing > - Locking > - Filtered retrieval > - Validation > 5) Security These are all NETCONF. Should I be doing a tutorial on NETCONF features? I'm not sure "filterer retrieval" is an architectural issue. > 6) Life-cycle Management Life cycle of what? YANG module, device, app? > 7) Capabilities I think these are covered. > 8) Module Conformance This should be stressed more. >I do not really agree with the architecture behind the picture >on page 11. If there is any sort of 'transform' between the >standard and the device, it is part of the agent implementation, >not the architecture. An agent may use all sorts of tools to >get from YANG modules to internal data structures, including >none -- code by hand. As an application writer, you'll talk to two sorts of boxes. Those that support the standard, and those that don't. If you don't have some mechanism to transform the standard dialect into a device-specific dialect, you cannot configure boxes that don't implement the standard. For emerging standards, this will lose a large percentage of boxes. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Sep 6 00:19: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 719833A67B6; Sat, 6 Sep 2008 00:19:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921243A67B6 for ; Sat, 6 Sep 2008 00:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.042 X-Spam-Level: X-Spam-Status: No, score=0.042 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_20=-0.74, 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 jJ2batH5oAlG for ; Sat, 6 Sep 2008 00:19:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B40DA3A679F for ; Sat, 6 Sep 2008 00:19:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id CEB14D800CB; Sat, 6 Sep 2008 09:19:37 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200809051942.m85JgtQD089220@idle.juniper.net> References: <200809051942.m85JgtQD089220@idle.juniper.net> Organization: CESNET Date: Sat, 06 Sep 2008 09:19:36 +0200 Message-Id: <1220685576.6251.15.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgUMOhIDA1LiAwOS4gMjAwOCB2IDE1OjQyIC0wNDAwOgo+IExh ZGlzbGF2IExob3RrYSB3cml0ZXM6Cj4gPnRoZSBwYXJ0IGFib3V0IERTREwgaXMgYW11c2luZyBi dXQgSSB0aGluayBpdCByYWlzZXMgYSBiaWcgcXVlc3Rpb24KPiA+d2hldGhlciBpdCBtYWtlcyBz ZW5zZSBhdCBhbGwgdG8gc3BlbmQgY3ljbGVzIG9uIGl0LiBJIGRvbid0IGFncmVlIHdpdGgKPiA+ dGhlIHZpZXcgdGhhdCBpdCBpcyBvbmx5IGdvb2QgZm9yIG1hbmFnZXJzIGFuZC9vciBwZW9wbGUg aW4gZW52aXJvbm1lbnRzCj4gPnRoYXQgaGF2ZW4ndCBiZWVuIGJsZXNzZWQgd2l0aCBZQU5HIHll dC4KPiAKPiBJIHNlZSB5b3VyIHBvaW50IHJlOiB0aGUgcG9zaWJpbGl0eSBvZiB1c2luZyBEU0RM IG9uIHRoZSBkZXZpY2UsCj4gYnV0IG5vdCB0aGUgc2Vjb25kIHBvaW50LiAgSWYgeW91ciB0b29s cyBzdXBwb3J0ZWQgWUFORyBuYXRpdmVseSwKPiB3aGVuIHdvdWxkIHlvdSBuZWVkIHRoZSBEU0RM IG1hcHBpbmc/CgpZQU5HIGRlYWxzIHdpdGggbWFueSB0aGluZ3MsIG5vdCBhbGwgb2YgdGhlbSBh cmUgcmVsZXZhbnQgZm9yIHRoZSBQRFVzCmFuZCBvbiB0aGUgb3RoZXIgaGFuZCB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gYSBnaXZlbiBZQU5HIG1vZGVsIGFuZApjb3JyZXNwb25kaW5nIFBEVXMg aXMgbm90IGZvcm1hbGx5IGRlc2NyaWJlZCBpbiB0aGUgWUFORyBkcmFmdCBvcgplbHNld2hlcmUu IFNvIHRoZSBEU0RMIGRyYWZ0IGFkZHJlc3NpbmcgdGhpcyByZWxhdGlvbnNoaXAgd291bGQgYmUg SU1PIGEKdXNlZnVsIGNvbXBsZW1lbnQgdG8gdGhlIFlBTkcgZHJhZnQuCgo+IAo+ID5NeSBzdWdn ZXN0aW9uIGlzIHRvIGRldmVsb3AgdGhlIFlBTkctdG8tRFNETCBtYXBwaW5nIGFzIGEgbWVhbnMg Zm9yCj4gPnNwZWNpZnlpbmcgZm9ybWFsbHkgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgWUFO RyBtb2RlbCBhbmQKPiA+Y29ycmVzcG9uZGluZyBORVRDT05GIFBEVXMuCj4gCj4gU28gdGhlIERT REwgbWFwcGluZyBzaG91bGQgY292ZXIgdGhlIFBEVXMsIG5vdCB0aGUgZGF0YWJhc2Ugd2UgYXJl Cj4gYnVpbGRpbmc/CgpZZXMuIElmIFlBTkcgbW9kZWxzIGFyZSBpbnRlcnByZXRlZCBhcyBjb250 cmFjdHMsIHRoZSBQRFVzIGFyZSB0aGUgb25seQp0aGluZyB0aGF0IHJlYWxseSBtYXR0ZXJzIGJl Y2F1c2UgdGhlIE5FVENPTkYgc2Vzc2lvbiBpcyBwcmVzdW1hYmx5IHRoZQpvbmx5IGNvbW11bmlj YXRpb24gY2hhbm5lbCBiZXR3ZWVuIHRoZSBhZ2VudCBhbmQgbWFuYWdlci4gSWYgdHdvCmRpZmZl cmVudCBhZ2VudHMgYmVoYXZlIGluIHRoZSBzYW1lIHdheSAoaW4gdGVybXMgb2YgUERVcyksIHdo eSBzaG91bGQKYW55b25lIGNhcmUgYWJvdXQgd2hhdCB0aGUgYWdlbnRzIGRvIHVuZGVyIHRoZSBo b29kPyBBbm90aGVyIGFkdmFudGFnZQpvZiB0aGUgUERVIHZpZXcgaXMgdGhhdCB0aGUgcmVwcmVz ZW50YXRpb24gb2YgZGF0YSBpcyBmaXhlZCB0aGVyZSAtIGl0CmlzIFhNTCwgYW5kIHNvIHVzaW5n IFhNTCBzY2hlbWEgbGFuZ3VhZ2VzIGZvciBkZXNjcmliaW5nIHRoZSBjb25zdHJhaW50cwppcyBh IG5hdHVyYWwgY2hvaWNlLiBJbiBjb250cmFzdCwgdGhlIHJlcHJlc2VudGF0aW9uIG9mIGFuICJh Z2VudApkYXRhYmFzZSIgaXMgcmF0aGVyIGZ1enp5IC0gSSBzdXNwZWN0IHRoYXQgZm9yIGRpZmZl cmVudCB2ZW5kb3JzIGl0IG1heQptZWFuIHdpZGVseSBkaWZmZXJlbnQgdGhpbmdzLgoKTGFkYQoK LS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Sat Sep 6 01:27: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 65DFE3A6869; Sat, 6 Sep 2008 01:27:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD31E3A6897 for ; Sat, 6 Sep 2008 01:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=0.801, 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 angt0TPKNxmb for ; Sat, 6 Sep 2008 01:26:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 437F53A6869 for ; Sat, 6 Sep 2008 01:26:58 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 716A6C0148; Sat, 6 Sep 2008 10:26:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DSMhK0I0VeBI; Sat, 6 Sep 2008 10:26:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36308C0140; Sat, 6 Sep 2008 10:26:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ADD6B6BCEE8; Sat, 6 Sep 2008 10:26:50 +0200 (CEST) Date: Sat, 6 Sep 2008 10:26:50 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080906082650.GA15989@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , netmod@ietf.org References: <200809051942.m85JgtQD089220@idle.juniper.net> <1220685576.6251.15.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1220685576.6251.15.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sat, Sep 06, 2008 at 09:19:36AM +0200, Ladislav Lhotka wrote: > Yes. If YANG models are interpreted as contracts, the PDUs are the only > thing that really matters because the NETCONF session is presumably the > only communication channel between the agent and manager. If two > different agents behave in the same way (in terms of PDUs), why should > anyone care about what the agents do under the hood? Another advantage > of the PDU view is that the representation of data is fixed there - it > is XML, and so using XML schema languages for describing the constraints > is a natural choice. In contrast, the representation of an "agent > database" is rather fuzzy - I suspect that for different vendors it may > mean widely different things. If I write a program, then the program must compile and make sense. It does not matter how beautiful and complete a single patch is that I am applying to the program's source code. After applying a patch, I better check that the program still compiles and makes sense. The NETCONF edit-config operations essentially applies a patch to a configuration. While the patch (= PDU) needs to be well formed to be recognized and applied to the config, what counts after applying the patch is that the configuration still is valid. YANG pretty much gets the focus on the configuration datastore right if you ask me. How a conceptual configuration datastore is implemented is the implementor's choice. /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 Sat Sep 6 02:27: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 EE30328C12F; Sat, 6 Sep 2008 02:27:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8BC3A6BB6 for ; Sat, 6 Sep 2008 02:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.331, 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 au+pGFMe1yM7 for ; Sat, 6 Sep 2008 02:27:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4F15B3A6BAD for ; Sat, 6 Sep 2008 02:27:52 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A2BE7D800CB; Sat, 6 Sep 2008 11:27:50 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080906082650.GA15989@elstar.local> References: <200809051942.m85JgtQD089220@idle.juniper.net> <1220685576.6251.15.camel@missotis> <20080906082650.GA15989@elstar.local> Organization: CESNET Date: Sat, 06 Sep 2008 11:27:48 +0200 Message-Id: <1220693268.6251.69.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFNvIDA2LiAwOS4gMjAwOCB2IDEwOjI2ICsw MjAwOgo+IAo+IElmIEkgd3JpdGUgYSBwcm9ncmFtLCB0aGVuIHRoZSBwcm9ncmFtIG11c3QgY29t cGlsZSBhbmQgbWFrZSBzZW5zZS4gSXQKPiBkb2VzIG5vdCBtYXR0ZXIgaG93IGJlYXV0aWZ1bCBh bmQgY29tcGxldGUgYSBzaW5nbGUgcGF0Y2ggaXMgdGhhdCBJIGFtCj4gYXBwbHlpbmcgdG8gdGhl IHByb2dyYW0ncyBzb3VyY2UgY29kZS4gQWZ0ZXIgYXBwbHlpbmcgYSBwYXRjaCwgSQo+IGJldHRl ciBjaGVjayB0aGF0IHRoZSBwcm9ncmFtIHN0aWxsIGNvbXBpbGVzIGFuZCBtYWtlcyBzZW5zZS4K PiAKPiBUaGUgTkVUQ09ORiBlZGl0LWNvbmZpZyBvcGVyYXRpb25zIGVzc2VudGlhbGx5IGFwcGxp ZXMgYSBwYXRjaCB0byBhCj4gY29uZmlndXJhdGlvbi4gV2hpbGUgdGhlIHBhdGNoICg9IFBEVSkg bmVlZHMgdG8gYmUgd2VsbCBmb3JtZWQgdG8gYmUKPiByZWNvZ25pemVkIGFuZCBhcHBsaWVkIHRv IHRoZSBjb25maWcsIHdoYXQgY291bnRzIGFmdGVyIGFwcGx5aW5nIHRoZQo+IHBhdGNoIGlzIHRo YXQgdGhlIGNvbmZpZ3VyYXRpb24gc3RpbGwgaXMgdmFsaWQuCgpNeSBpZGVhIGlzIHRvIG9idGFp biBEU0RMIHNjaGVtYXMgdGhhdCBzcGVjaWZ5IGNvbnN0cmFpbnRzIGZvciB0aGUgZnVsbAoodW5m aWx0ZXJlZCkgZ2V0IHJlcGx5IC0gd2hpY2ggaXMgZXNzZW50aWFsbHkgd2hhdCB0aGUgRFNETCBt b2R1bGUgZm9yCnB5YW5nIGRvZXMgbm93LCBidXQgYWxzbyBmb3IgYWxsIFJQQ3MgYW5kIG5vdGlm aWNhdGlvbnMgZGVmaW5lZCBpbiBhCllBTkcgbW9kZWwuIFRoZSBhc3N1bXB0aW9uIGlzIHRoYXQg Y29uc3RyYWludHMgZm9yIG90aGVyIFBEVXMgKGZpbHRlcmVkCmdldCByZXBsaWVzLCBlZGl0LWNv bmZpZykgY2FuIGJlIGRlcml2ZWQgZnJvbSB0aGVzZSBmdWxsIHNjaGVtYXMgaW4gYQpzdHJhaWdo dGZvcndhcmQgd2F5IC0gYnV0IHRoaXMgc3RlcCB3aWxsIGJlIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoZQpEU0RMIGRyYWZ0LCBhdCBsZWFzdCBmb3IgdGhlIHRpbWUgYmVpbmcuCj4gCj4gWUFORyBw cmV0dHkgbXVjaCBnZXRzIHRoZSBmb2N1cyBvbiB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUg cmlnaHQKPiBpZiB5b3UgYXNrIG1lLiBIb3cgYSBjb25jZXB0dWFsIGNvbmZpZ3VyYXRpb24gZGF0 YXN0b3JlIGlzIGltcGxlbWVudGVkCj4gaXMgdGhlIGltcGxlbWVudG9yJ3MgY2hvaWNlLgoKVGhh dCdzIGZpbmUsIEkgYW0gbm90IHF1ZXN0aW9uaW5nIHRoZSBmb2N1cyBvZiBZQU5HIGl0c2VsZiwg YnV0IGlmCnNvbWVvbmUgYXNrcyAiSXMgdGhpcyBQRFUgdmFsaWQgdW5kZXIgdGhhdCBZQU5HIG1v ZGVsPyIgb3IgIkhvdyBzaG91bGQKdGhlIGRhdGEgZnJvbSBteSBkYXRhYmFzZSBhcHBlYXIgaW4g Z2V0IHJlcGxpZXM/IiwgaXQncyBnb29kIHRvIGJlIGFibGUKdG8gb2J0YWluIGFuIGV4YWN0IGFu c3dlciwgZWl0aGVyIGJ5IGluc3BlY3RpbmcgdGhlIG1hcHBpbmcKc3BlY2lmaWNhdGlvbiBvciBi eSBtYWNoaW5lIHZhbGlkYXRpb24uCgpPZiBjb3Vyc2UsIGluIHRoZSBjYXNlIG9mIFBEVXMgY29u dGFpbmluZyBwYXJ0aWFsIGRhdGEgKGVkaXQtY29uZmlnLApmaWx0ZXJlZCBnZXQgcmVwbHkpIHNv bWUgY29uc3RyYWludHMgbWF5IG5vdCBiZSB2ZXJpZmlhYmxlIGFuZCB0aGUKcmVzdWx0IG9mIGFw cGx5aW5nIGFuIGVkaXQtY29uZmlnIGhhcyB0byBiZSB2YWxpZGF0ZWQgaW50ZXJuYWxseSBieSB0 aGUKYWdlbnQgaW4gYW55IGNhc2UuCgpMYWRhCgoKPiAKPiAvanMKPiAKLS0gCkxhZGlzbGF2IExo b3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Sat Sep 6 03:26: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 AB6303A6BBD; Sat, 6 Sep 2008 03:26:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC0F3A6BD0 for ; Sat, 6 Sep 2008 03:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.771, 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 d3y-wQt1dXYv for ; Sat, 6 Sep 2008 03:26:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9D91A3A6BCB for ; Sat, 6 Sep 2008 03:26:14 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B082C0158; Sat, 6 Sep 2008 12:26:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23I9cPXqizDy; Sat, 6 Sep 2008 12:26:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C6D5C0154; Sat, 6 Sep 2008 12:26:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D0A606BD0AE; Sat, 6 Sep 2008 12:26:05 +0200 (CEST) Date: Sat, 6 Sep 2008 12:26:05 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080906102605.GA16279@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , netmod@ietf.org References: <200809051942.m85JgtQD089220@idle.juniper.net> <1220685576.6251.15.camel@missotis> <20080906082650.GA15989@elstar.local> <1220693268.6251.69.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1220693268.6251.69.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sat, Sep 06, 2008 at 11:27:48AM +0200, Ladislav Lhotka wrote: > > YANG pretty much gets the focus on the configuration datastore right > > if you ask me. How a conceptual configuration datastore is implemented > > is the implementor's choice. > > That's fine, I am not questioning the focus of YANG itself, but if > someone asks "Is this PDU valid under that YANG model?" or "How should > the data from my database appear in get replies?", it's good to be able > to obtain an exact answer, either by inspecting the mapping > specification or by machine validation. > > Of course, in the case of PDUs containing partial data (edit-config, > filtered get reply) some constraints may not be verifiable and the > result of applying an edit-config has to be validated internally by the > agent in any case. I expect/hope that filtered gets and edit-configs will be pretty widely used and perhaps that is why I do personally not see the same value as you do in partial PDU validation. /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 Sat Sep 6 03:59:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F97A3A68F4; Sat, 6 Sep 2008 03:59:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8053A69B7 for ; Sat, 6 Sep 2008 03:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_20=-0.74, 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 bmK26xF9CzvD for ; Sat, 6 Sep 2008 03:59:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8145D3A67EF for ; Sat, 6 Sep 2008 03:59:17 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A52C5D800D1; Sat, 6 Sep 2008 12:59:17 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080906102605.GA16279@elstar.local> References: <200809051942.m85JgtQD089220@idle.juniper.net> <1220685576.6251.15.camel@missotis> <20080906082650.GA15989@elstar.local> <1220693268.6251.69.camel@missotis> <20080906102605.GA16279@elstar.local> Organization: CESNET Date: Sat, 06 Sep 2008 12:59:17 +0200 Message-Id: <1220698757.6251.93.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFNvIDA2LiAwOS4gMjAwOCB2IDEyOjI2ICsw MjAwOgo+IAo+IEkgZXhwZWN0L2hvcGUgdGhhdCBmaWx0ZXJlZCBnZXRzIGFuZCBlZGl0LWNvbmZp Z3Mgd2lsbCBiZSBwcmV0dHkKPiB3aWRlbHkgdXNlZCBhbmQgcGVyaGFwcyB0aGF0IGlzIHdoeSBJ IGRvIHBlcnNvbmFsbHkgbm90IHNlZSB0aGUgc2FtZQo+IHZhbHVlIGFzIHlvdSBkbyBpbiBwYXJ0 aWFsIFBEVSB2YWxpZGF0aW9uLgoKTmVpdGhlciBkbyBJLiBNeSBwb2ludCBoZXJlIGlzIHRoYXQg aXQgaXMgbmVjZXNzYXJ5IHRvIGtub3cgaG93IHRoZQpyZXBseSB0byBnZXQgd2l0aG91dCBmaWx0 ZXJzIG1heSBleGFjdGx5IGxvb2sgbGlrZSBmb3IgYSBnaXZlbiBZQU5HCm1vZGVsLiBSYXRoZXIg dGhhbiBkZXNjcmliaW5nIGl0IGluIEVuZ2xpc2ggYW5kIGdpdmluZyBhIGNvbmNyZXRlCmV4YW1w bGUgb2Ygc2VyaWFsaXNlZCBYTUwgYXMgWUFORyBkcmFmdCBkb2VzLCBpdCBpcyBJTU8gbW9yZSBn ZW5lcmFsIGFuZApwcmVjaXNlIHRvIHByb3ZpZGUgWE1MIHNjaGVtYXMuIEZvciBpbnN0YW5jZSwg YW4gZXhhbXBsZSBYTUwgZG9jdW1lbnQKZG9lc24ndCB0ZWxsIHdoZXRoZXIgdGhlIG9yZGVyIG9m IGNoaWxkcmVuIGlzIGZpeGVkIG9yIG5vdCwgd2hlcmVhcyB0aGUKKFJFTEFYIE5HKSBzY2hlbWEg ZG9lcy4gVGhpcyBzaG91bGQgYmUgdXNlZnVsIGZvciBpbXBsZW1lbnRvcnMgdG8gbWFrZQpzdXJl IHRoYXQgdGhlIFBEVXMgdGhhdCB0aGVpciBhZ2VudCBnZW5lcmF0ZXMgd2lsbCBiZSBwcm9wZXJs eQp1bmRlcnN0b29kLgoKSSB0aGluayBpdCBpcyBPSyBmb3IgdGhlIFlBTkcgZHJhZnQgdG8gZGVz Y3JpYmUgWE1MIGVuY29kaW5nIHJ1bGVzIHVzaW5nCnByb3NlIGFuZCBleGFtcGxlcyB0byBtYWtl IGl0IG1vcmUgYWNjZXNzaWJsZSwgYnV0IHRoaXMgd2F5IGl0IGlzCmRpZmZpY3VsdCB0byBjYXB0 dXJlIGFsbCBwb3NzaWJsZSBjYXNlcyBhbmQgY29tYmluYXRpb25zLCBzbyBhIGZvcm1hbApzY2hl bWEgc2hvdWxkIGJlIHRoZSB1bHRpbWF0ZSBub3JtLgoKTGFkYQoKPiAKPiAvanMKPiAKLS0gCkxh ZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5l dG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZAo= From netmod-bounces@ietf.org Sat Sep 6 06:10: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 57DFC3A6850; Sat, 6 Sep 2008 06:10:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4DA3A69D5 for ; Sat, 6 Sep 2008 06:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.744, 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 PK574sFJ-ybU for ; Sat, 6 Sep 2008 06:10:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47A803A69EE for ; Sat, 6 Sep 2008 06:10:16 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E75CC0158; Sat, 6 Sep 2008 15:10:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5TCxzEY7Yabz; Sat, 6 Sep 2008 15:10:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50993C015C; Sat, 6 Sep 2008 15:10:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EC8A66BD14E; Sat, 6 Sep 2008 15:10:04 +0200 (CEST) Date: Sat, 6 Sep 2008 15:10:04 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080906131004.GA16413@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , netmod@ietf.org References: <200809051942.m85JgtQD089220@idle.juniper.net> <1220685576.6251.15.camel@missotis> <20080906082650.GA15989@elstar.local> <1220693268.6251.69.camel@missotis> <20080906102605.GA16279@elstar.local> <1220698757.6251.93.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1220698757.6251.93.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sat, Sep 06, 2008 at 12:59:17PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v So 06. 09. 2008 v 12:26 +0200: > > > > I expect/hope that filtered gets and edit-configs will be pretty > > widely used and perhaps that is why I do personally not see the same > > value as you do in partial PDU validation. > > Neither do I. My point here is that it is necessary to know how the > reply to get without filters may exactly look like for a given YANG > model. Rather than describing it in English and giving a concrete > example of serialised XML as YANG draft does, it is IMO more general and > precise to provide XML schemas. For instance, an example XML document > doesn't tell whether the order of children is fixed or not, whereas the > (RELAX NG) schema does. This should be useful for implementors to make > sure that the PDUs that their agent generates will be properly > understood. I think the YANG mappings to XML should be precise enough to create interoperable implementations. If there are things and are ambiguous and where more precision is needed, please tell us so we can fix it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Sep 7 20:02: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 3A00B3A6B32; Sun, 7 Sep 2008 20:02:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E473A6B32 for ; Sun, 7 Sep 2008 20:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.244 X-Spam-Level: X-Spam-Status: No, score=-5.244 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzoed4P2z9Fr for ; Sun, 7 Sep 2008 20:02:40 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 58C933A6B77 for ; Sun, 7 Sep 2008 20:02:31 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Sun, 07 Sep 2008 19:53:44 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Sep 2008 20:02:17 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Sep 2008 20:02:17 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Sep 2008 20:02:16 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8832GM59047; Sun, 7 Sep 2008 20:02:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m882wS5O002206; Mon, 8 Sep 2008 02:58:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809080258.m882wS5O002206@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1220698757.6251.93.camel@missotis> Date: Sun, 07 Sep 2008 22:58:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Sep 2008 03:02:16.0983 (UTC) FILETIME=[4D192A70:01C9115F] Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.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: >Neither do I. My point here is that it is necessary to know how the >reply to get without filters may exactly look like for a given YANG >model. Rather than describing it in English and giving a concrete >example of serialised XML as YANG draft does, it is IMO more general and >precise to provide XML schemas. For instance, an example XML document >doesn't tell whether the order of children is fixed or not, whereas the >(RELAX NG) schema does. This should be useful for implementors to make >sure that the PDUs that their agent generates will be properly >understood. We started down this thread asking "If your tools supported YANG natively, when would you need the DSDL mapping?". Your answer is that you need DSDL for validating PDUs, but I don't see this. If you have YANG-enabled tools, you can pass them a PDU and say "is this valid?" and get back an answer. If don't need DSDL to do this. A YANG library will understand the XML encoding rules for YANG. >I think it is OK for the YANG draft to describe XML encoding rules using >prose and examples to make it more accessible, but this way it is >difficult to capture all possible cases and combinations, so a formal >schema should be the ultimate norm. If you have to understand DSDL and read the DSDL mapping to understand how YANG works, we have serious problems in the YANG spec. The prose in the YANG spec MUST stand on their own. If they are weak, we cannot expect the DSDL mapping document to fix them. So do we need a formal content spec in the YANG draft? Do we need to make an ABNF for YANG content? leaf = "<" leaf-name leaf-attributes ">" leaf-content "" leaf-attributes = leaf-op-attribute leaf-op-attribute = "op" "=" op-attribute-value op-attribute-value = "delete" | "create" ... etc ... Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 8 00:12: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 5BC6D3A6943; Mon, 8 Sep 2008 00:12:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929B03A6943 for ; Mon, 8 Sep 2008 00:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[AWL=0.479, 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 MZfALdbkT6JE for ; Mon, 8 Sep 2008 00:12:56 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A26CC3A6BF9 for ; Mon, 8 Sep 2008 00:12:56 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 772B5D800C0; Mon, 8 Sep 2008 09:12:56 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200809080258.m882wS5O002206@idle.juniper.net> References: <200809080258.m882wS5O002206@idle.juniper.net> Organization: CESNET Date: Mon, 08 Sep 2008 09:12:56 +0200 Message-Id: <1220857976.13110.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgTmUgMDcuIDA5LiAyMDA4IHYgMjI6NTggLTA0MDA6Cgo+IAo+ IFdlIHN0YXJ0ZWQgZG93biB0aGlzIHRocmVhZCBhc2tpbmcgIklmIHlvdXIgdG9vbHMgc3VwcG9y dGVkIFlBTkcKPiBuYXRpdmVseSwgd2hlbiB3b3VsZCB5b3UgbmVlZCB0aGUgRFNETCBtYXBwaW5n PyIuICBZb3VyIGFuc3dlciBpcwo+IHRoYXQgeW91IG5lZWQgRFNETCBmb3IgdmFsaWRhdGluZyBQ RFVzLCBidXQgSSBkb24ndCBzZWUgdGhpcy4gIElmCj4geW91IGhhdmUgWUFORy1lbmFibGVkIHRv b2xzLCB5b3UgY2FuIHBhc3MgdGhlbSBhIFBEVSBhbmQgc2F5ICJpcwo+IHRoaXMgdmFsaWQ/IiBh bmQgZ2V0IGJhY2sgYW4gYW5zd2VyLiAgSWYgZG9uJ3QgbmVlZCBEU0RMIHRvIGRvIHRoaXMuCgpO b3RlIHRoYXQgbm90aGluZyBsaWtlIHRoaXMgaXMgYW55d2hlcmUgbmVhciBob3Jpem9uLCBBRkFJ Sy4gQW5kIEkgdGhpbmsKaXQgd291bGQgYmUganVzdCB3YXN0ZSBvZiBjeWNsZXMgdG8gd3JpdGUg YW4gWE1MIHZhbGlkYXRvciBiYXNlZCBvbgpZQU5HLiBJZiB3ZSBnZXQgdGhlIFlBTkctPkRTREwg bWFwcGluZyByaWdodCwgd2UgbmVlZG4ndCBpbXBsZW1lbnQgYSBuZXcKdmFsaWRhdG9yIGZvciBY TUwgKHdoaWNoIGlzIGZhciBmcm9tIGVhc3kpLiBUaGUgWE1MIHNjaGVtYSBsYW5ndWFnZXMKaGF2 ZSBiZWVuIGRlc2lnbmVkIGZvciB0aGlzLCBzbyB3aHkgc2hvdWxkIHdlIHJlaW52ZW50IHRoZSB3 aGVlbD8gUGVvcGxlCmluIHRoaXMgZ3JvdXAgb2Z0ZW4gc3RyZXNzIHRoZSBuZWVkIGZvciByZXVz aW5nIHRoZSBrbm93LWhvdyBvZgpTTk1QL1NNSSwgYnV0IGlzbid0IGl0IHRoZSBzYW1lIGNhc2Ug d2l0aCBYTUw/Cgo+IEEgWUFORyBsaWJyYXJ5IHdpbGwgdW5kZXJzdGFuZCB0aGUgWE1MIGVuY29k aW5nIHJ1bGVzIGZvciBZQU5HLgo+IAo+ID5JIHRoaW5rIGl0IGlzIE9LIGZvciB0aGUgWUFORyBk cmFmdCB0byBkZXNjcmliZSBYTUwgZW5jb2RpbmcgcnVsZXMgdXNpbmcKPiA+cHJvc2UgYW5kIGV4 YW1wbGVzIHRvIG1ha2UgaXQgbW9yZSBhY2Nlc3NpYmxlLCBidXQgdGhpcyB3YXkgaXQgaXMKPiA+ ZGlmZmljdWx0IHRvIGNhcHR1cmUgYWxsIHBvc3NpYmxlIGNhc2VzIGFuZCBjb21iaW5hdGlvbnMs IHNvIGEgZm9ybWFsCj4gPnNjaGVtYSBzaG91bGQgYmUgdGhlIHVsdGltYXRlIG5vcm0uCj4gCj4g SWYgeW91IGhhdmUgdG8gdW5kZXJzdGFuZCBEU0RMIGFuZCByZWFkIHRoZSBEU0RMIG1hcHBpbmcg dG8gdW5kZXJzdGFuZAo+IGhvdyBZQU5HIHdvcmtzLCB3ZSBoYXZlIHNlcmlvdXMgcHJvYmxlbXMg aW4gdGhlIFlBTkcgc3BlYy4gIFRoZSBwcm9zZQo+IGluIHRoZSBZQU5HIHNwZWMgTVVTVCBzdGFu ZCBvbiB0aGVpciBvd24uICBJZiB0aGV5IGFyZSB3ZWFrLCB3ZSBjYW5ub3QKPiBleHBlY3QgdGhl IERTREwgbWFwcGluZyBkb2N1bWVudCB0byBmaXggdGhlbS4KPiAKCkkga25vdyBteXNlbGYgaG93 IG1hbnkgdGltZXMgSSd2ZSBoYWQgdG8gbG9vayB0byB0aGUgQUJORiBmb3IgWUFORywgZXZlbgp0 aG91Z2ggdGhlIHN0YXRlbWVudHMgYXJlIHN1cHBvc2VkIHRvIGJlIGRlc2NyaWJlZCBmdWxseSBp biB0aGUgdGV4dC4KSXQncyB0aGUgc2FtZSBoZXJlOiBYTUwgc2NoZW1hcyBwcm92aWRlIGEgY29u Y2lzZSBhbmQgZm9ybWFsCnNwZWNpZmljYXRpb24sIGFwYXJ0IGZyb20gdGhlIGZhY3QgdGhhdCB0 aGV5IGNhbiBiZSB1c2VkIGZvciBtYWNoaW5lCnZhbGlkYXRpb24uIEEgZm9ybWFsIHNwZWMgbGVh dmVzIHlvdSBubyBzcGFjZSBmb3IgaGFuZC13YXZpbmcgYXJndW1lbnRzCndoZXJlYXMgcHJvc2Ug YW5kIHNpbXBsaXN0aWMgZXhhbXBsZXMgZG8uCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBD RVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Sep 8 00:38:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7830C3A680B; Mon, 8 Sep 2008 00:38:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7046D3A680B for ; Mon, 8 Sep 2008 00:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.292, 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 lxj2l-HAwjTS for ; Mon, 8 Sep 2008 00:38:00 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A34C63A6B61 for ; Mon, 8 Sep 2008 00:38:00 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 72A4A76C250; Mon, 8 Sep 2008 09:38:02 +0200 (CEST) Date: Mon, 08 Sep 2008 09:38:15 +0200 (CEST) Message-Id: <20080908.093815.149594810.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48C15491.4070700@netconfcentral.com> References: <48C15491.4070700@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] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > > I think YANG needs one more built-in type, called object-identifier. > It is just like instance-identifier, except no predicates ([key='value']) > can be present. I think the name "object-identifier" can be confusing, since people might think we mean "OBJECT IDENTIFIER" or maybe think that "object-identifier" is YANG's version of "OBJECT IDENTIFIER". In the current spec we call this "schema node identifier". > Sometimes you really want the leaf the indicate an > object node in the conceptual tree (e.g. ACM), Can you provide a use case for this? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 8 05:46: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 221383A67A7; Mon, 8 Sep 2008 05:46:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA343A67A7 for ; Mon, 8 Sep 2008 05:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 h4UUFD5uMuvY for ; Mon, 8 Sep 2008 05:46:52 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id C90BC3A686D for ; Mon, 8 Sep 2008 05:46:45 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 08 Sep 2008 05:46:47 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Sep 2008 05:43:12 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Sep 2008 05:43:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Sep 2008 05:43:11 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m88ChAM28258; Mon, 8 Sep 2008 05:43:11 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m88CdMkv005539; Mon, 8 Sep 2008 12:39:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809081239.m88CdMkv005539@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1220857976.13110.25.camel@missotis> Date: Mon, 08 Sep 2008 08:39:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Sep 2008 12:43:11.0427 (UTC) FILETIME=[73F74130:01C911B0] Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.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: >Note that nothing like this is anywhere near horizon, AFAIK. And I think >it would be just waste of cycles to write an XML validator based on >YANG. If we get the YANG->DSDL mapping right, we needn't implement a new >validator for XML (which is far from easy). The XML schema languages >have been designed for this, so why should we reinvent the wheel? In many (most?) cases, building a configuration engine based on YANG will involve making a validator. For my engine, we talk XML elements while traversing the meta-data (built from our proprietary YANG equivalent now) so the list of valid element names for any point in the hierarchy is known, as well as the supported attributes, etc. This metadata is needed to build the database, so using an external XML-based schema is a waste of time. Using DSDL (or XSD) in an environment where you don't have YANG-based tools may make sense, but YANG-based tools should handle validation natively without the need for an external schema language. More directly: the YANG spec must give complete details about the encoding of XML content. If prose is not sufficient, more direct mechanisms may be needed, but the YANG spec should not rely on the DSDL mapping spec to define the XML content mapping for a YANG module. >I know myself how many times I've had to look to the ABNF for YANG, even >though the statements are supposed to be described fully in the text. >It's the same here: XML schemas provide a concise and formal >specification, apart from the fact that they can be used for machine >validation. A formal spec leaves you no space for hand-waving arguments >whereas prose and simplistic examples do. But work on the NETCONF draft showed that no one reads XSD and I think our experience with relax-ng is even weaker. A formal spec in a langauge no one reads is worse than worthless. The YANG spec needs to stand on it own, fully describing the configuration database contents and the contents of the NETCONF PDUs. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 8 06:25: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 BDD4B3A6A49; Mon, 8 Sep 2008 06:25:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD2D3A6A81 for ; Mon, 8 Sep 2008 06:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=0.445, 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 U-iMlcwhSrtG for ; Mon, 8 Sep 2008 06:25:04 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2F0AB3A68C8 for ; Mon, 8 Sep 2008 06:25:04 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 78577D800C4; Mon, 8 Sep 2008 15:24:57 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200809081239.m88CdMkv005539@idle.juniper.net> References: <200809081239.m88CdMkv005539@idle.juniper.net> Organization: CESNET Date: Mon, 08 Sep 2008 15:24:58 +0200 Message-Id: <1220880298.13110.73.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgUG8gMDguIDA5LiAyMDA4IHYgMDg6MzkgLTA0MDA6Cj4gSW4g bWFueSAobW9zdD8pIGNhc2VzLCBidWlsZGluZyBhIGNvbmZpZ3VyYXRpb24gZW5naW5lIGJhc2Vk IG9uCj4gWUFORyB3aWxsIGludm9sdmUgbWFraW5nIGEgdmFsaWRhdG9yLiAgRm9yIG15IGVuZ2lu ZSwgd2UgdGFsayBYTUwKPiBlbGVtZW50cyB3aGlsZSB0cmF2ZXJzaW5nIHRoZSBtZXRhLWRhdGEg KGJ1aWx0IGZyb20gb3VyIHByb3ByaWV0YXJ5Cj4gWUFORyBlcXVpdmFsZW50IG5vdykgc28gdGhl IGxpc3Qgb2YgdmFsaWQgZWxlbWVudCBuYW1lcyBmb3IgYW55Cj4gcG9pbnQgaW4gdGhlIGhpZXJh cmNoeSBpcyBrbm93biwgYXMgd2VsbCBhcyB0aGUgc3VwcG9ydGVkIGF0dHJpYnV0ZXMsCj4gZXRj LiAgVGhpcyBtZXRhZGF0YSBpcyBuZWVkZWQgdG8gYnVpbGQgdGhlIGRhdGFiYXNlLCBzbyB1c2lu ZyBhbgo+IGV4dGVybmFsIFhNTC1iYXNlZCBzY2hlbWEgaXMgYSB3YXN0ZSBvZiB0aW1lLgoKQXMg YSBkZXZlbG9wZXIsIGhvdyBjYW4geW91IHRlbGwgdGhhdCB0aGUgWE1MIHlvdXIgZGV2aWNlIHBy b2R1Y2VzIGlzCnZhbGlkPyBJIHRoaW5rIGl0J3MgdXNlZnVsIHRvIGhhdmUgYSBmb3JtYWwgd2F5 IGZvciBjaGVja2luZyBpdCwgZWl0aGVyCm1hbnVhbGx5IG9yIGF1dG9tYXRpY2FsbHkuIFdoeSB3 b3VsZCBiZSB0aGVuIFhNTCBzY2hlbWFzIHVzZWQgYXQgYWxsPyBXZQpoYXZlIHNlZW4gZmV3IHRp bWVzIGFscmVhZHkgdGhhdCB0aGUgInByb3NlIiBpbiB0aGUgWUFORyBzcGVjIGNhbiBiZQppbnRl cnByZXRlZCBpbiBkaWZmZXJlbnQgd2F5cyBhbmQgSSB0aGluayBpdCdzIGFuIGluaGVyZW50IHBy b3BlcnR5IG9mCnZlcmJhbCBkZXNjcmlwdGlvbnMuCgpXaGV0aGVyIHlvdSB1c2UgdGhlIHNjaGVt YSBkaXJlY3RseSBpbiBhIHByb2R1Y3Rpb24gc3lzdGVtIG9yIG5vdCBpcyBhCmRpZmZlcmVudCBz dG9yeSwgYnV0IElNTyBpdCdzIGFsc28gcG9zc2libGUgYXBwcm9hY2guCgoKPiBCdXQgd29yayBv biB0aGUgTkVUQ09ORiBkcmFmdCBzaG93ZWQgdGhhdCBubyBvbmUgcmVhZHMgWFNEIGFuZCBJCgpO byB3b25kZXIgLSB0aGF0IFhTRCBpcyBicm9rZW4gYW5kIG9mIG5vIHVzZS4gSXQgbWl4ZXMgdG9n ZXRoZXIgbWVzc2FnZXMKb2YgdGhlIGNsaWVudCBhbmQgc2VydmVyLCBkb2Vzbid0IHRha2UgaW50 byBhY2NvdW50IGNhcGFiaWxpdGllcyBldGMuCkEgc2NoZW1hIHRoYXQgY2FuIGJlIHJlYWxseSB1 c2VkIGZvciB2YWxpZGF0aW5nIE5FVENPTkYgUERVcyBtdXN0IGJlCnVzZWZ1bCBmb3IgZGV2ZWxv cGVycyBhbG1vc3QgYnkgZGVmaW5pdGlvbi4KCj4gdGhpbmsgb3VyIGV4cGVyaWVuY2Ugd2l0aCBy ZWxheC1uZyBpcyBldmVuIHdlYWtlci4gIEEgZm9ybWFsIHNwZWMKPiBpbiBhIGxhbmdhdWdlIG5v IG9uZSByZWFkcyBpcyB3b3JzZSB0aGFuIHdvcnRobGVzcy4gIFRoZSBZQU5HIHNwZWMKPiBuZWVk cyB0byBzdGFuZCBvbiBpdCBvd24sIGZ1bGx5IGRlc2NyaWJpbmcgdGhlIGNvbmZpZ3VyYXRpb24g ZGF0YWJhc2UKPiBjb250ZW50cyBhbmQgdGhlIGNvbnRlbnRzIG9mIHRoZSBORVRDT05GIFBEVXMu CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBt YWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Sep 8 07:04: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 74AC13A6A81; Mon, 8 Sep 2008 07:04:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666F53A6A81 for ; Mon, 8 Sep 2008 07:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 UwC29q1Jlr6j for ; Mon, 8 Sep 2008 07:04:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2EABA3A6A1E for ; Mon, 8 Sep 2008 07:04:31 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E0A8920A8D; Mon, 8 Sep 2008 16:04:32 +0200 (CEST) X-AuditID: c1b4fb3c-af0d0bb0000015b5-e5-48c530f02382 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C528A20864; Mon, 8 Sep 2008 16:04:32 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 16:04:32 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 16:04:31 +0200 Message-ID: <48C530F4.3000400@ericsson.com> Date: Mon, 08 Sep 2008 16:04:36 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200809081239.m88CdMkv005539@idle.juniper.net> In-Reply-To: <200809081239.m88CdMkv005539@idle.juniper.net> X-OriginalArrivalTime: 08 Sep 2008 14:04:31.0813 (UTC) FILETIME=[D0E70F50:01C911BB] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Phil, Thanks for the draft, nice sometimes even entertaining reading. Some comments: General: I 100% agree that the YANG draft MUST be able to define for a given datastore and a given PDU if it is valid or not. Naturally validity near always depends on the content of the datastore, so as I see it we can not get away from describing the datastore. OTOH this is one point I would like to see in the DSDL draft: What is it describing. It will be interesting to reach agreement on that. I would emphasize that YANG is both for defining standard modules AND for allowing vendors to define proprietary modules. I am missing the latter part. I would emphasize that YANG tries to be consumable for both humans and applications. We don't want something complicated as people wont learn it, but we want something powerful. I would emphasize that YANG aims to describe more about the devices behavior in a formal way compared to earlier stuff e.g. SMI, plain XML or LDAP Schemas. I would emphasize that we are trying to strike a balance between having one interoperable standard and being able to describe the complexities and many options that exist in the real world. I would mention that while officially YANG only defines NETCONF managed data, in practice it is and it will be used to define CLI, GUI, documentation aspects, code generation aspects and to drive Netconf/YANG toolkits. IMHO some times the language is a bit too cordial. That is fun too a certain level, ... Title: Is this really about Network management or just configuration management or YANG/Netconf based management. I don't see much fault or performance management in the draft. Chapter 3. I would like to know whether capabilities/supported models/features can change during run-time of a node or just at upgrade/restart ? Adding new stuff, removing it, changing to a new version? This must be described either here or in the YANG main draft!!! Figure: Didn't you mix up the caption for the two sides? It is possible that there is no standard view at all anywhere. I would say that will be quite common. At least mention it. Chapter 4. The parser is just one XML tool that could be mentioned. I would say XSLT is much more important e.g. for producing HTML documents, code etc. Chapter 6. Is this chapter really needed. Chapter 7. I would make this shorter. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 8 07:19: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 C2C5A3A68FF; Mon, 8 Sep 2008 07:19:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2EF228C14A for ; Mon, 8 Sep 2008 07:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.981, 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 ybb+d203wMWh for ; Mon, 8 Sep 2008 07:19:44 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id D1B7128C149 for ; Mon, 8 Sep 2008 07:19:43 -0700 (PDT) Received: (qmail 89176 invoked from network); 8 Sep 2008 14:19:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.231.130 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 8 Sep 2008 14:19:44 -0000 X-YMail-OSG: 3fvkQe0VM1mWZJkhD1.t7Hlw4V_ekLvCY1AGy3RKXsa0Tq077_cqjD2l0VUGj825MIPC6xEwwpXKpAdE3.eIumdFq6NCGmsZo_5oiFxqyw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C5347E.7010202@netconfcentral.com> Date: Mon, 08 Sep 2008 07:19:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809080258.m882wS5O002206@idle.juniper.net> In-Reply-To: <200809080258.m882wS5O002206@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Initial version of the arch draft is available X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> Neither do I. My point here is that it is necessary to know how the >> reply to get without filters may exactly look like for a given YANG >> model. Rather than describing it in English and giving a concrete >> example of serialised XML as YANG draft does, it is IMO more general and >> precise to provide XML schemas. For instance, an example XML document >> doesn't tell whether the order of children is fixed or not, whereas the >> (RELAX NG) schema does. This should be useful for implementors to make >> sure that the PDUs that their agent generates will be properly >> understood. > > We started down this thread asking "If your tools supported YANG > natively, when would you need the DSDL mapping?". Your answer is > that you need DSDL for validating PDUs, but I don't see this. If > you have YANG-enabled tools, you can pass them a PDU and say "is > this valid?" and get back an answer. If don't need DSDL to do this. > A YANG library will understand the XML encoding rules for YANG. > Some people seem to think YANG by itself accomplishes something. It does not. Some people think that the ability to generate a 'pass/fail' validation response is useful. Since I am interested in using YANG within a NETCONF implementation, unless the validation tool generates compliant elements in every possible NETCONF PDU scenario, it is of no use to me. Simply generating some blanket "config had errors" response is not only useless to the manager, it does not comply with NETCONF. I also strongly object to the notion that DSDL is needed to define the YANG to XML mapping for YANG. That belongs in the YANG spec, written in text. >> I think it is OK for the YANG draft to describe XML encoding rules using >> prose and examples to make it more accessible, but this way it is >> difficult to capture all possible cases and combinations, so a formal >> schema should be the ultimate norm. > > If you have to understand DSDL and read the DSDL mapping to understand > how YANG works, we have serious problems in the YANG spec. The prose > in the YANG spec MUST stand on their own. If they are weak, we cannot > expect the DSDL mapping document to fix them. > > So do we need a formal content spec in the YANG draft? Do we need > to make an ABNF for YANG content? > > leaf = "<" leaf-name leaf-attributes ">" leaf-content "" > leaf-attributes = leaf-op-attribute > leaf-op-attribute = "op" "=" op-attribute-value > op-attribute-value = "delete" | "create" > ... etc ... > > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 8 07:50:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D773A68A2; Mon, 8 Sep 2008 07:50:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADDD03A6955 for ; Mon, 8 Sep 2008 07:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmOyrcvbaxYw for ; Mon, 8 Sep 2008 07:50:57 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 57D1A3A68A2 for ; Mon, 8 Sep 2008 07:50:57 -0700 (PDT) Received: (qmail 24445 invoked from network); 8 Sep 2008 14:50:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.231.130 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 8 Sep 2008 14:50:58 -0000 X-YMail-OSG: QyBvR_IVM1mwM.UkRah1ndj.PRHI2b3_VWrkMC_uDKm2mctBT5mLji2jTjkfwxvzEi_JpbePPKUc_QoPAH0dy.HvOR7Id_qQryX7_9dpt_jqXqOtKfsaa8Bb2KR8XFc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C53BD0.9020401@netconfcentral.com> Date: Mon, 08 Sep 2008 07:50:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48C15491.4070700@netconfcentral.com> <20080908.093815.149594810.mbj@tail-f.com> In-Reply-To: <20080908.093815.149594810.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> >> I think YANG needs one more built-in type, called object-identifier. >> It is just like instance-identifier, except no predicates ([key='value']) >> can be present. > > I think the name "object-identifier" can be confusing, since people > might think we mean "OBJECT IDENTIFIER" or maybe think that > "object-identifier" is YANG's version of "OBJECT IDENTIFIER". > How about 'node-identifier'? > In the current spec we call this "schema node identifier". > >> Sometimes you really want the leaf the indicate an >> object node in the conceptual tree (e.g. ACM), > > Can you provide a use case for this? > This is all the text there is in the draft: The instance-identifier built-in type is used to uniquely identify a particular instance node in the data tree. The syntax for an instance-identifier is a subset of the XPath syntax, which is used to uniquely identify a node in the data tree. It is an absolute XPath location path in abbreviated syntax, where axes are not permitted, and predicates are used only for specifying the values for the key nodes for list entries, or a value of a leaf- list. Each predicate consists of one equality test per key. Each key MUST have a corresponding predicate. An instance-identifier can represent exactly 1 instance. It is very constrained. There is no data type that can be used to represent any instance or N instances, of a an object. An example might be an object within an access control table that is used to limit access to all or some instances of a particular object. Another example would be a 'safe' implementation of the partial lock draft. Currently, the 'select' element is just a string, and can represent any arbitrary XPath expression. IMO, it would be much better to restrict the partial lock select statement to a node-identifier (0 to N partial or full instance identifiers). There is also no indication to the compiler that 'select' has some structure beyond 'string'. YANG has 10 different forms of numbers, yet no help whatsoever for this rather complex aspect of YANG data modeling. If a user enters -17 wrong, the YANG compiler is all over it, but when it comes to complex XPath expressions, 'string' is good enough. No help needed here. Seems rather inconsistent to me. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 8 07:59: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 9D8D93A6A41; Mon, 8 Sep 2008 07:59:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914A63A6ADF for ; Mon, 8 Sep 2008 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.269, 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 DwAcMr42X3Ft for ; Mon, 8 Sep 2008 07:59:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5D5BF3A6A41 for ; Mon, 8 Sep 2008 07:59:47 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B150876C250; Mon, 8 Sep 2008 16:59:47 +0200 (CEST) Date: Mon, 08 Sep 2008 17:00:09 +0200 (CEST) Message-Id: <20080908.170009.243369534.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48C53BD0.9020401@netconfcentral.com> References: <48C15491.4070700@netconfcentral.com> <20080908.093815.149594810.mbj@tail-f.com> <48C53BD0.9020401@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] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > An instance-identifier can represent exactly 1 instance. > It is very constrained. There is no data type that > can be used to represent any instance or N instances, of a an object. So maybe I don't understand how your 'node-identifier' would work. You said: >> Sometimes you really want the leaf the indicate an >> object node in the conceptual tree (e.g. ACM), When you say "conceptual tree" do tou mean the "data tree" or "schema tree", as defined in the YANG draft? > An example might be an object within an access control table > that is used to limit access to all or some instances of a particular > object. > > Another example would be a 'safe' implementation of the partial > lock draft. Currently, the 'select' element is just a string, > and can represent any arbitrary XPath expression. IMO, > it would be much better to restrict the partial lock > select statement to a node-identifier > (0 to N partial or full instance identifiers). But you also said that the node-identifier would have no predicates. Here I think you're talking about an instance-identifier with "wildcards". > There is also no indication to the compiler that 'select' has some > structure beyond 'string'. YANG has 10 different forms of > numbers, yet no help whatsoever for this rather complex > aspect of YANG data modeling. If a user enters -17 wrong, > the YANG compiler is all over it, but when it comes > to complex XPath expressions, 'string' is good enough. > No help needed here. Seems rather inconsistent to me. I agree. I just don't understand your proposal. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 8 08:05:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387C13A68E0; Mon, 8 Sep 2008 08:05:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198EC3A68A2 for ; Mon, 8 Sep 2008 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.767, 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 QW5+R3kff3jn for ; Mon, 8 Sep 2008 08:05:22 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 2DD723A68E0 for ; Mon, 8 Sep 2008 08:05:22 -0700 (PDT) Received: (qmail 9085 invoked from network); 8 Sep 2008 15:05:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.231.130 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 8 Sep 2008 15:05:24 -0000 X-YMail-OSG: fDjBnkYVM1lK.Xs005Hq7TqLbnOkCY9pUd9lnl8dEH4O7kIn7l9ZuWtLoRCuborB9Mv0PbX_bT26VhmJElMpfDNseKHH6H.DmPOqKn7KmRTvWtzDVEHUhkB3JnvjwQs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C53F32.8040701@netconfcentral.com> Date: Mon, 08 Sep 2008 08:05:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48C15491.4070700@netconfcentral.com> <20080908.093815.149594810.mbj@tail-f.com> <48C53BD0.9020401@netconfcentral.com> <20080908.170009.243369534.mbj@tail-f.com> In-Reply-To: <20080908.170009.243369534.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >> An instance-identifier can represent exactly 1 instance. >> It is very constrained. There is no data type that >> can be used to represent any instance or N instances, of a an object. > > So maybe I don't understand how your 'node-identifier' would work. > > You said: > >>> Sometimes you really want the leaf the indicate an >>> object node in the conceptual tree (e.g. ACM), > > When you say "conceptual tree" do tou mean the "data tree" or "schema > tree", as defined in the YANG draft? > >> An example might be an object within an access control table >> that is used to limit access to all or some instances of a particular >> object. >> >> Another example would be a 'safe' implementation of the partial >> lock draft. Currently, the 'select' element is just a string, >> and can represent any arbitrary XPath expression. IMO, >> it would be much better to restrict the partial lock >> select statement to a node-identifier >> (0 to N partial or full instance identifiers). > > But you also said that the node-identifier would have no predicates. > Here I think you're talking about an instance-identifier with > "wildcards". > >> There is also no indication to the compiler that 'select' has some >> structure beyond 'string'. YANG has 10 different forms of >> numbers, yet no help whatsoever for this rather complex >> aspect of YANG data modeling. If a user enters -17 wrong, >> the YANG compiler is all over it, but when it comes >> to complex XPath expressions, 'string' is good enough. >> No help needed here. Seems rather inconsistent to me. > > I agree. I just don't understand your proposal. > I think YANG needs an unconstrained instance-identifier data type. That means it is just like instance-identifier, but with 1 word changed. Last sentence: instance-identifier: Each key MUST have a corresponding predicate. Last sentence: node-identifier: Each key MAY have a corresponding predicate. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 9 00:12: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 797EB3A63D2; Tue, 9 Sep 2008 00:12:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76533A6C58 for ; Tue, 9 Sep 2008 00:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+vN+GTOHELS for ; Tue, 9 Sep 2008 00:12:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CA1FA3A63D2 for ; Tue, 9 Sep 2008 00:12:48 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6ACBFC0022 for ; Tue, 9 Sep 2008 09:12:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V6I6BtgJSKpY; Tue, 9 Sep 2008 09:12:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 399BAC0005; Tue, 9 Sep 2008 09:12:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 26D7D6BEF74; Tue, 9 Sep 2008 09:12:46 +0200 (CEST) Date: Tue, 9 Sep 2008 09:12:46 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20080909071246.GA20440@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] architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I think we need to agree what the purpose and scope of the architecture document is. The NETMOD charter says: 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) This is rather fuzzy. While the input is clear (data models written in YANG), the output is less clear since at the end of the day we want YANG models to be implemented in NETCONF servers as the output. How you get there is tool dependent. For me, it would make more sense to have an architecture document describing the big picture behind NETCONF plus YANG. Since YANG is a domain specific language for NETCONF, I would even argue that a YANG architecture has to reference NETCONF architectural concepts and since we do not have a NETCONF architecture, we need to address this anyhow. What is the WGs opinion? /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 Sep 9 02:47: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 8072B3A6ABE; Tue, 9 Sep 2008 02:47:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309C43A6ABE for ; Tue, 9 Sep 2008 02:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.098, 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 ceOxswDqe-Xq for ; Tue, 9 Sep 2008 02:47:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 23C263A6D0E for ; Tue, 9 Sep 2008 02:47:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 239DC2106C for ; Tue, 9 Sep 2008 11:47:17 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-f1-48c64625e284 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 070C920B96 for ; Tue, 9 Sep 2008 11:47:17 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:47:05 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:47:04 +0200 Message-ID: <48C6461F.1090900@ericsson.com> Date: Tue, 09 Sep 2008 11:47:11 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org References: <20080909071246.GA20440@elstar.local> In-Reply-To: <20080909071246.GA20440@elstar.local> X-OriginalArrivalTime: 09 Sep 2008 09:47:04.0558 (UTC) FILETIME=[0408C0E0:01C91261] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Jurgen, While I basically agree with you, this could open up long debates about access control, relation to SNMP, non-YANG based usage of Netconf etc. Balazs Juergen Schoenwaelder wrote: > Hi, > > I think we need to agree what the purpose and scope of the > architecture document is. The NETMOD charter says: > > 1. An architecture document explaining the relationship > between YANG and its inputs and outputs. (informational) > > This is rather fuzzy. While the input is clear (data models written in > YANG), the output is less clear since at the end of the day we want > YANG models to be implemented in NETCONF servers as the output. How > you get there is tool dependent. > > For me, it would make more sense to have an architecture document > describing the big picture behind NETCONF plus YANG. Since YANG is a > domain specific language for NETCONF, I would even argue that a YANG > architecture has to reference NETCONF architectural concepts and since > we do not have a NETCONF architecture, we need to address this anyhow. > > What is the WGs opinion? > > /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 Sep 9 02:54: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 C27673A6BB6; Tue, 9 Sep 2008 02:54:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B1B3A6BB6 for ; Tue, 9 Sep 2008 02:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuhCINoJmU71 for ; Tue, 9 Sep 2008 02:54:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8830A3A67F8 for ; Tue, 9 Sep 2008 02:54:30 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C2AF2095F; Tue, 9 Sep 2008 11:54:19 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-a0-48c647cbade9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6BA4C20834; Tue, 9 Sep 2008 11:54:19 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:54:19 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:54:18 +0200 Message-ID: <48C647D1.1070908@ericsson.com> Date: Tue, 09 Sep 2008 11:54:25 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48C15491.4070700@netconfcentral.com> <20080908.093815.149594810.mbj@tail-f.com> <48C53BD0.9020401@netconfcentral.com> <20080908.170009.243369534.mbj@tail-f.com> <48C53F32.8040701@netconfcentral.com> In-Reply-To: <48C53F32.8040701@netconfcentral.com> X-OriginalArrivalTime: 09 Sep 2008 09:54:18.0736 (UTC) FILETIME=[06D30F00:01C91262] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, Do you want to point out a node in the schema-tree or do you want a kind of wildcard that points out all elements of a list in the data-tree (or a leaf in all list elements etc.)? Balazs Andy Bierman wrote: > I think YANG needs an unconstrained instance-identifier data type. > That means it is just like instance-identifier, but with 1 word changed. > > Last sentence: instance-identifier: > > Each key MUST have a corresponding predicate. > > Last sentence: node-identifier: > > Each key MAY have a corresponding predicate. > >> /martin > > > 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 Tue Sep 9 03:12:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB693A67FB; Tue, 9 Sep 2008 03:12:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A0828C0ED for ; Tue, 9 Sep 2008 03:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 fIFnxZsCw8-l for ; Tue, 9 Sep 2008 03:12:43 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 97E3F3A67FB for ; Tue, 9 Sep 2008 03:12:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,364,1217822400"; d="scan'208";a="142797436" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 09 Sep 2008 06:12:09 -0400 X-IronPort-AV: E=Sophos;i="4.32,364,1217822400"; d="scan'208";a="268394798" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Sep 2008 06:12:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Sep 2008 12:11:03 +0200 Message-ID: In-Reply-To: <20080909071246.GA20440@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] architecture document scope Thread-Index: AckSS36sKZriJbcbQc60eI5+NXY44AAFz+QQ References: <20080909071246.GA20440@elstar.local> From: "Romascanu, Dan (Dan)" To: , Subject: Re: [netmod] architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, I would not spend too much time looking strictly at the words in the charter - especially when we deal with architecture. I do understand - I think - what we had in mind when we put the YANG architecture document in the charter, and this was related to clarification of specific issues that were discussed during the formation of the WG about how the flow of models in different languages will work and what is in-between. I agree with your observation that part of the output is tools dependent - but this is part of the clarification. What would a 'big picture' architecture for NETCONF include in your opinion? What NETCONF architectural concepts are missing to provide for the NETMOD architecture? I do not hide that I am somehow concerned that when we would get to the NETCONF architecture we would need to refer a broader architecture view of the IETF management architecture. From boiling a cup of tea we got to boiling a lake and we then get close to boiling the ocean. Dan (speaking as a contributor) > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, September 09, 2008 10:13 AM > To: netmod@ietf.org > Subject: [netmod] architecture document scope > > Hi, > > I think we need to agree what the purpose and scope of the > architecture document is. The NETMOD charter says: > > 1. An architecture document explaining the relationship > between YANG and its inputs and outputs. (informational) > > This is rather fuzzy. While the input is clear (data models > written in YANG), the output is less clear since at the end > of the day we want YANG models to be implemented in NETCONF > servers as the output. How you get there is tool dependent. > > For me, it would make more sense to have an architecture > document describing the big picture behind NETCONF plus YANG. > Since YANG is a domain specific language for NETCONF, I would > even argue that a YANG architecture has to reference NETCONF > architectural concepts and since we do not have a NETCONF > architecture, we need to address this anyhow. > > What is the WGs opinion? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 9 05:26:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FD13A6452; Tue, 9 Sep 2008 05:26:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297FF3A6452 for ; Tue, 9 Sep 2008 05:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUezGwLZVkr0 for ; Tue, 9 Sep 2008 05:26:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E91E93A6A0C for ; Tue, 9 Sep 2008 05:26:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C565E20866 for ; Tue, 9 Sep 2008 14:26:08 +0200 (CEST) X-AuditID: c1b4fb3c-af8d1bb0000015b5-72-48c66b6072a3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B119720597 for ; Tue, 9 Sep 2008 14:26:08 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 14:26:08 +0200 Received: from selic023.ki.sw.ericsson.se ([147.214.33.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 14:26:08 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 9 Sep 2008 14:26:19 +0200 User-Agent: KMail/1.9.10 References: <200809021330.03163.david.partain@ericsson.com> In-Reply-To: <200809021330.03163.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200809091426.19140.david.partain@ericsson.com> X-OriginalArrivalTime: 09 Sep 2008 12:26:08.0320 (UTC) FILETIME=[3C8F4400:01C91277] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Experiment: FAQ jabber "sprint" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tuesday 02 September 2008 13.30.02 David Partain wrote: > Hi, > > We'd like to try a little experiment as a different way of working within > the working group. This initial experiment will _not_ be on chartered > work, since we want to see how it goes before we try to apply it to > chartered work. > > We will meet in the IETF's NETMOD Jabber room (jabber.ietf.org is the > server, netmod is the room) and work on the FAQs listed at > > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/YANG_FAQ > > The meeting will be one week from today (September 9) at 12:30 > (California)/15:30 (East Coast)/21:30 (Central Europe)/ > 03:30 (on the 3rd) (Tokyo) > > The idea is to discuss the questions "live" and fill in the answers as well > as potentially asking new FAQs. Jabber logs will be available > after-the-fact for anyone who wishes to see what happened. Those are > available at http://jabber.ietf.org/logs/netmod/ (look for the appropriate > date... fascinating that there are logs from LONG before there was a > working group). > > I've tried to maximize the ability of people from all over to participate, > but that's not easy. I'm keenly aware that this time is not good for > everyone when we're spread out all over the globe. I'm also aware that > this means that some people cannot participate since their corporate > policies do not allow them to use jabber. Both of these are issues when > considering using this for "official" working group business. > > Hope to see a great many of you there! Hi all, Don't forget that this is today (or tomorrow morning if you're in Japan). See you there in 7 hours. David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 9 05:42: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 E08B028C17D; Tue, 9 Sep 2008 05:42:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AB428C183 for ; Tue, 9 Sep 2008 05:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.750, 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 BRnHHjJqCxdb for ; Tue, 9 Sep 2008 05:42:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 745E028C19E for ; Tue, 9 Sep 2008 05:42:36 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 761D6C005A; Tue, 9 Sep 2008 14:42:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j3GJ5607UV4E; Tue, 9 Sep 2008 14:42:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C355AC005C; Tue, 9 Sep 2008 14:42:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A66826BF6CC; Tue, 9 Sep 2008 14:42:33 +0200 (CEST) Date: Tue, 9 Sep 2008 14:42:33 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080909124233.GA21509@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , netmod@ietf.org References: <20080909071246.GA20440@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] architecture document scope 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, Sep 09, 2008 at 12:11:03PM +0200, Romascanu, Dan (Dan) wrote: > What would a 'big picture' architecture for NETCONF include in your > opinion? What NETCONF architectural concepts are missing to provide for > the NETMOD architecture? The big picture requires to explain how the twins NETCONF and YANG fit into the overall picture from the viewpoint of device manufacturers, management application writers, and operators. And there are some fundamental assumptions underlying the design of NETCONF and YANG that are not really spelled out. Andy once called some of them axioms on the mailing list and he also once had an ID with some good relevant material. > I do not hide that I am somehow concerned that when we would get to the > NETCONF architecture we would need to refer a broader architecture view > of the IETF management architecture. From boiling a cup of tea we got to > boiling a lake and we then get close to boiling the ocean. Yes, I am aware of the risks. /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 Sep 9 08:02: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 0D1883A6D17; Tue, 9 Sep 2008 08:02:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605E028C0F5 for ; Tue, 9 Sep 2008 08:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=0.901, 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 n09A++YbiPFu for ; Tue, 9 Sep 2008 08:02:38 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 52F223A6D17 for ; Tue, 9 Sep 2008 08:02:38 -0700 (PDT) Received: (qmail 98798 invoked from network); 9 Sep 2008 15:02:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.231.130 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 9 Sep 2008 15:02:40 -0000 X-YMail-OSG: t7UEj3YVM1mMJOJBgzCoIB6jSz0F_AT8rFUhca12s8MXX5pcHhqQcIuENvGlIHV.s50AfVDQMfIcMGqXhD0TnUD1.9Bs3zy4mUROAm0FigpOH5XUPOk3fg6S6XBTQbg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C6900E.8090703@netconfcentral.com> Date: Tue, 09 Sep 2008 08:02:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <48C15491.4070700@netconfcentral.com> <20080908.093815.149594810.mbj@tail-f.com> <48C53BD0.9020401@netconfcentral.com> <20080908.170009.243369534.mbj@tail-f.com> <48C53F32.8040701@netconfcentral.com> <48C647D1.1070908@ericsson.com> In-Reply-To: <48C647D1.1070908@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > Do you want to point out a node in the schema-tree or do you want a kind > of wildcard that points out all elements of a list in the data-tree (or > a leaf in all list elements etc.)? I think the latter. The entire usage of XPath within YANG needs more thought. Maybe a generic 'xpath-string' for 'select' type of nodes is more useful and simpler. I am looking at the keyref data type and its path statement again. I still cannot understand why the example shown in 8.8.4 is of any relevance to real data models. Is the 'mgmt-interface' object supposed to be more config? Are there any real-world data models that use this sort of construct? The examples that actually make sense to me are well-documented: - foreign key (no usage example) - notification by-reference content (4.2.10 example needs work) It seems to me that 'keyref' is YANG's version of the SMIv2 Counter64. Instead of the useful, robust, complete approach -- i.e., define Unsigned64 and Signed64 data types -- SMIv2 defined only an esoteric, derived data type (Counter64) instead. As a result, 64 bit numbers have been a nightmare in SNMP ever since. I do not understand why the keyref and instance-identifier data types (specialized derived data types) are present in YANG, but not a generic data node pointer (ala OBJECT IDENTIFIER in SMIv2). BTW, the ABNF for 'path-key-expr' still lists 'this-variable-keyword'. It should be changed to 'current-function-invocation' or something like that. > Balazs Andy > > Andy Bierman wrote: >> I think YANG needs an unconstrained instance-identifier data type. >> That means it is just like instance-identifier, but with 1 word changed. >> >> Last sentence: instance-identifier: >> >> Each key MUST have a corresponding predicate. >> >> Last sentence: node-identifier: >> >> Each key MAY have a corresponding predicate. >> >>> /martin >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 9 08:03: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 6018E3A6D17; Tue, 9 Sep 2008 08:03:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD0A3A6D17 for ; Tue, 9 Sep 2008 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIkb3sCJ8Ylt for ; Tue, 9 Sep 2008 08:03:47 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id CC1863A6D27 for ; Tue, 9 Sep 2008 08:03:46 -0700 (PDT) Received: (qmail 57495 invoked from network); 9 Sep 2008 15:03:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.231.130 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 9 Sep 2008 15:03:49 -0000 X-YMail-OSG: Cgf0UxsVM1lQK4BS1V_Sglr_vHTyb_yXjIt6hF1KmH0e4a3u.Zoqd3XuLFe8lZfYSi6ptQMbALPQufAL85OF9M_GrMYxqD.TNjBY2DGD9A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C69053.2030609@netconfcentral.com> Date: Tue, 09 Sep 2008 08:03:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: netmod@ietf.org References: <20080909071246.GA20440@elstar.local> In-Reply-To: <20080909071246.GA20440@elstar.local> Subject: Re: [netmod] architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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: > Hi, > > I think we need to agree what the purpose and scope of the > architecture document is. The NETMOD charter says: > > 1. An architecture document explaining the relationship > between YANG and its inputs and outputs. (informational) > > This is rather fuzzy. While the input is clear (data models written in > YANG), the output is less clear since at the end of the day we want > YANG models to be implemented in NETCONF servers as the output. How > you get there is tool dependent. > > For me, it would make more sense to have an architecture document > describing the big picture behind NETCONF plus YANG. Since YANG is a > domain specific language for NETCONF, I would even argue that a YANG > architecture has to reference NETCONF architectural concepts and since > we do not have a NETCONF architecture, we need to address this anyhow. > > What is the WGs opinion? > I agree with your assessment. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 9 14:30: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 C893D3A6829; Tue, 9 Sep 2008 14:30:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CA53A683C for ; Tue, 9 Sep 2008 14:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.153, 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 ab4zE50kPlWL for ; Tue, 9 Sep 2008 14:30:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F2F6A3A6829 for ; Tue, 9 Sep 2008 14:30:41 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id CE97076C326; Tue, 9 Sep 2008 23:30:45 +0200 (CEST) Date: Tue, 09 Sep 2008 23:31:16 +0200 (CEST) Message-Id: <20080909.233116.159876484.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48C6900E.8090703@netconfcentral.com> References: <48C53F32.8040701@netconfcentral.com> <48C647D1.1070908@ericsson.com> <48C6900E.8090703@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] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 am looking at the keyref data type and its path statement > again. I still cannot understand why the example shown in 8.8.4 > is of any relevance to real data models. Is the 'mgmt-interface' > object supposed to be more config? Are there any real-world > data models that use this sort of construct? Do you mean keyref in general? For an example of how keyrefs are used, see http://www.yang-central.org/twiki/bin/view/Main/YangExamplesExecdNtp. > The examples that actually make sense to me are well-documented: > - foreign key (no usage example) > - notification by-reference content (4.2.10 example needs work) Ok. In 4.2.10, do you mean remove the if-index and send e.g. the if-admin-status? > I do not understand why the keyref and instance-identifier > data types (specialized derived data types) are present in > YANG, but not a generic data node pointer (ala OBJECT IDENTIFIER > in SMIv2). instance-identifier *is* a generic data node pointer. It can point to any node in the data tree: /interfaces/interafce[name="eth0"]/mtu /interfaces/interafce[name="eth0"] /interfaces are all valid instance-identifiers. What do think is missing? > BTW, the ABNF for 'path-key-expr' still lists 'this-variable-keyword'. > It should be changed to 'current-function-invocation' or something > like that. Fixed, thanks. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 9 18:14: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 C6AB428C0E2; Tue, 9 Sep 2008 18:14:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB9A28C0E2 for ; Tue, 9 Sep 2008 18:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.692, 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 zg8XMEvU4xzV for ; Tue, 9 Sep 2008 18:14:03 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id B35153A683C for ; Tue, 9 Sep 2008 18:14:02 -0700 (PDT) Received: (qmail 50500 invoked from network); 10 Sep 2008 01:14:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.231.130 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 10 Sep 2008 01:14:01 -0000 X-YMail-OSG: 8xw7qxgVM1kGimcoqcQNJj7gp6OnRFGIIDOtpIZvra_2fSSe2OsGuCdWrW7S82v5jUR8c8gDwn1QZj1j.PuyAegpzL3y4mKwPRVDpi.6yJ3nXvnS3bxa4EFFmtvKRdw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C71F57.5050304@netconfcentral.com> Date: Tue, 09 Sep 2008 18:13:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48C53F32.8040701@netconfcentral.com> <48C647D1.1070908@ericsson.com> <48C6900E.8090703@netconfcentral.com> <20080909.233116.159876484.mbj@tail-f.com> In-Reply-To: <20080909.233116.159876484.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] object-identifier data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> I am looking at the keyref data type and its path statement >> again. I still cannot understand why the example shown in 8.8.4 >> is of any relevance to real data models. Is the 'mgmt-interface' >> object supposed to be more config? Are there any real-world >> data models that use this sort of construct? > > Do you mean keyref in general? For an example of how keyrefs are > used, see > http://www.yang-central.org/twiki/bin/view/Main/YangExamplesExecdNtp. > not sure what I'm supposed to notice there >> The examples that actually make sense to me are well-documented: >> - foreign key (no usage example) >> - notification by-reference content (4.2.10 example needs work) > > Ok. In 4.2.10, do you mean remove the if-index and send e.g. the > if-admin-status? > both should be external reference, but YANG does not have a leafref, so the if-index is a cut-and-paste clone. The example says to me "Why bother with keyref, if cut-and-paste is supposedly good enough for non-key leafs". >> I do not understand why the keyref and instance-identifier >> data types (specialized derived data types) are present in >> YANG, but not a generic data node pointer (ala OBJECT IDENTIFIER >> in SMIv2). > > instance-identifier *is* a generic data node pointer. It can point to > any node in the data tree: > > /interfaces/interafce[name="eth0"]/mtu > /interfaces/interafce[name="eth0"] > /interfaces > > are all valid instance-identifiers. What do think is missing? > object identifier: /interfaces/interface/mtu >> BTW, the ABNF for 'path-key-expr' still lists 'this-variable-keyword'. >> It should be changed to 'current-function-invocation' or something >> like that. > > Fixed, thanks. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 03:47:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FAA73A6D65; Wed, 10 Sep 2008 03:47:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F78C3A6D56 for ; Wed, 10 Sep 2008 03:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.234, 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 tP4exkNbAoZj for ; Wed, 10 Sep 2008 03:47:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7BB163A6D0A for ; Wed, 10 Sep 2008 03:47:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 96FE676C250 for ; Wed, 10 Sep 2008 12:47:49 +0200 (CEST) Date: Wed, 10 Sep 2008 12:48:19 +0200 (CEST) Message-Id: <20080910.124819.11409118.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, At the FAQ sprint yesterday the question came up why leafs of type empty are not allowed as keys. It was late and obviously I wasn't thinking properly when I said that it should be allowed... The reason this is not allowed is that an empty leaf has no extra information than its existance; an empty leaf can exist or not exist. If it exists, there is no additional data associated with it. And key leafs MUST exist. So if we allow empty leafs in keys, we add no information at all to the key - the empty leaf must be present in all instances, it cannot be deleted, and it contains no info. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 04:31: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 B411E3A6890; Wed, 10 Sep 2008 04:31:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018163A6A97 for ; Wed, 10 Sep 2008 04:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=0.415, 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 ao-Rajm1qQnG for ; Wed, 10 Sep 2008 04:31:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 21B3F3A6890 for ; Wed, 10 Sep 2008 04:31:32 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D282CD800C7; Wed, 10 Sep 2008 13:31:25 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080910.124819.11409118.mbj@tail-f.com> References: <20080910.124819.11409118.mbj@tail-f.com> Organization: CESNET Date: Wed, 10 Sep 2008 13:31:26 +0200 Message-Id: <1221046286.9589.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAxMC4gMDkuIDIwMDggdiAxMjo0OCArMDIwMDoK PiBIaSwKPiAKPiBBdCB0aGUgRkFRIHNwcmludCB5ZXN0ZXJkYXkgdGhlIHF1ZXN0aW9uIGNhbWUg dXAgd2h5IGxlYWZzIG9mIHR5cGUKPiBlbXB0eSBhcmUgbm90IGFsbG93ZWQgYXMga2V5cy4KPiAK PiBJdCB3YXMgbGF0ZSBhbmQgb2J2aW91c2x5IEkgd2Fzbid0IHRoaW5raW5nIHByb3Blcmx5IHdo ZW4gSSBzYWlkIHRoYXQKPiBpdCBzaG91bGQgYmUgYWxsb3dlZC4uLgo+IAo+IFRoZSByZWFzb24g dGhpcyBpcyBub3QgYWxsb3dlZCBpcyB0aGF0IGFuIGVtcHR5IGxlYWYgaGFzIG5vIGV4dHJhCj4g aW5mb3JtYXRpb24gdGhhbiBpdHMgZXhpc3RhbmNlOyBhbiBlbXB0eSBsZWFmIGNhbiBleGlzdCBv ciBub3QgZXhpc3QuCj4gSWYgaXQgZXhpc3RzLCB0aGVyZSBpcyBubyBhZGRpdGlvbmFsIGRhdGEg YXNzb2NpYXRlZCB3aXRoIGl0LiAgQW5kIGtleQo+IGxlYWZzIE1VU1QgZXhpc3QuICBTbyBpZiB3 ZSBhbGxvdyBlbXB0eSBsZWFmcyBpbiBrZXlzLCB3ZSBhZGQgbm8KPiBpbmZvcm1hdGlvbiBhdCBh bGwgdG8gdGhlIGtleSAtIHRoZSBlbXB0eSBsZWFmIG11c3QgYmUgcHJlc2VudCBpbiBhbGwKPiBp bnN0YW5jZXMsIGl0IGNhbm5vdCBiZSBkZWxldGVkLCBhbmQgaXQgY29udGFpbnMgbm8gaW5mby4K CkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyB2ZXJ5IGltcG9ydGFudCBidXQgYW55d2F5OgoKMS4gWW91 IGNhbiB1c2Uga2V5cyB3aG9zZSBkYXRhdHlwZXMgYXJlIHJlc3RyaWN0ZWQgdG8gYSBzaW5nbGUg dmFsdWUsIHNvCmluIHByYWN0aWNlIGl0IGlzIHRoZSBzYW1lIGNhc2UuIEl0IGp1c3QgbWVhbnMg dGhlIGxpc3QgY2FuIGhhdmUgbm8gbW9yZQp0aGFuIG9uZSBpdGVtLiBJZiBvbmUgdXNlcyBhIGJv b2xlYW4ga2V5LCBpdCBjYW4gaGF2ZSBvbmx5IHR3byBpdGVtcywgc28Kd2hhdD8KCjIuIER1cmlu ZyB0aGUgZGV2ZWxvcG1lbnQgYW5kIHRlc3RzIG9mIGEgbW9kdWxlIGFuZCBhcHBsaWNhdGlvbiwg aXQKbWlnaHQgYmUgaGFuZHkgdG8gZGVmaW5lIHRoZSBrZXkgdGVtcG9yYXJpbHkgYXMgZW1wdHkg YXMgYSBwbGFjZWhvbGRlcgpzbyB0aGF0IGl0IGV4aXN0cyBhbmQgY2FuIGJlIHJlZmVycmVkIHRv IGluIGtleXJlZnMuCgozLiBObyBjb25mdXNpb24gY2FuIGFyaXNlIGZvciBib3RoIHRoZSB1c2Vy IGFuZCBzeXN0ZW0sIHNvIEkgZG9uJ3Qgc2VlIGEKcmVhc29uIGZvciBiYW5uaW5nIGl0IGV4cGxp Y2l0bHkuCgpMYWRhCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRF OEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0 bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Sep 10 05:23: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 6BB1428C226; Wed, 10 Sep 2008 05:23:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B458928C1F3 for ; Wed, 10 Sep 2008 05:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 KQKx55cFT1kH for ; Wed, 10 Sep 2008 05:23:38 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id BADEB28C227 for ; Wed, 10 Sep 2008 05:23:34 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Wed, 10 Sep 2008 05:23:32 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 05:22:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 05:22:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 05:22:36 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8ACMZM33565; Wed, 10 Sep 2008 05:22:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8ACIkh4038663; Wed, 10 Sep 2008 12:18:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809101218.m8ACIkh4038663@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1221046286.9589.70.camel@missotis> Date: Wed, 10 Sep 2008 08:18:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Sep 2008 12:22:36.0414 (UTC) FILETIME=[E8AAB9E0:01C9133F] Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >I don't think this is very important but anyway: If it's not important, can we just leave it as it? >1. You can use keys whose datatypes are restricted to a single value, so >in practice it is the same case. It just means the list can have no more >than one item. If one uses a boolean key, it can have only two items, so >what? We try to design the language to help people to the right thing and keep them from doing the wrong thing. An empty key is never the right thing, so we don't allow it. >2. During the development and tests of a module and application, it >might be handy to define the key temporarily as empty as a placeholder >so that it exists and can be referred to in keyrefs. Use "type string" as a placeholder. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 06:41:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063B03A69F6; Wed, 10 Sep 2008 06:41:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DA13A6D53 for ; Wed, 10 Sep 2008 06:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=0.389, 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 v-ohi6ctNaaf for ; Wed, 10 Sep 2008 06:41:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2974B3A682F for ; Wed, 10 Sep 2008 06:41:54 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 477DFD800C7; Wed, 10 Sep 2008 15:41:59 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200809101218.m8ACIkh4038663@idle.juniper.net> References: <200809101218.m8ACIkh4038663@idle.juniper.net> Organization: CESNET Date: Wed, 10 Sep 2008 15:41:59 +0200 Message-Id: <1221054119.9589.95.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMTAuIDA5LiAyMDA4IHYgMDg6MTggLTA0MDA6Cj4gTGFk aXNsYXYgTGhvdGthIHdyaXRlczoKPiA+SSBkb24ndCB0aGluayB0aGlzIGlzIHZlcnkgaW1wb3J0 YW50IGJ1dCBhbnl3YXk6Cj4gCj4gSWYgaXQncyBub3QgaW1wb3J0YW50LCBjYW4gd2UganVzdCBs ZWF2ZSBpdCBhcyBpdD8KClllcywgYnV0IHRoZSBGQVEgcXVlc3Rpb24gaGFzIHRvIGJlIGFuc3dl cmVkLiBPdGhlcndpc2UgaXQgY291bGQgYmUKZGVsZXRlZC4KCj4gCj4gPjEuIFlvdSBjYW4gdXNl IGtleXMgd2hvc2UgZGF0YXR5cGVzIGFyZSByZXN0cmljdGVkIHRvIGEgc2luZ2xlIHZhbHVlLCBz bwo+ID5pbiBwcmFjdGljZSBpdCBpcyB0aGUgc2FtZSBjYXNlLiBJdCBqdXN0IG1lYW5zIHRoZSBs aXN0IGNhbiBoYXZlIG5vIG1vcmUKPiA+dGhhbiBvbmUgaXRlbS4gSWYgb25lIHVzZXMgYSBib29s ZWFuIGtleSwgaXQgY2FuIGhhdmUgb25seSB0d28gaXRlbXMsIHNvCj4gPndoYXQ/Cj4gCj4gV2Ug dHJ5IHRvIGRlc2lnbiB0aGUgbGFuZ3VhZ2UgdG8gaGVscCBwZW9wbGUgdG8gdGhlIHJpZ2h0IHRo aW5nIGFuZAo+IGtlZXAgdGhlbSBmcm9tIGRvaW5nIHRoZSB3cm9uZyB0aGluZy4gICBBbiBlbXB0 eSBrZXkgaXMgbmV2ZXIgdGhlCj4gcmlnaHQgdGhpbmcsIHNvIHdlIGRvbid0IGFsbG93IGl0LgoK SWYgZW1wdHkgd2FzIGFsbG93ZWQgYW5kIHRoZSBkcmFmdCBkaWRuJ3QgbWVudGlvbiBpdCwgSSBh bSBhYnNvbHV0ZWx5CnN1cmUgaXQgd291bGQgbmV2ZXIgcG9wIHVwIGFzIGEgcHJvYmxlbSBvciBG QVEgcXVlc3Rpb24uIEJ5IG1lbnRpb25pbmcKaXQsIHRoaXMgdHJpdmlhbCBpc3N1ZSBnYWlucyBp bXBvcnRhbmNlLiBJIHNlZSBpdCBhcyBhIHByZW1hdHVyZQpvcHRpbWl6YXRpb24sIG9yIENMUi4K CkJUVywgdGhlIGRyYWZ0IHNheXM6ICdBIGxlYWYgdGhhdCBpcyBwYXJ0IG9mIHRoZSBrZXkgY2Fu IGJlIG9mIGFueQpidWlsdC1pbiBvciBkZXJpdmVkIHR5cGUsIGV4Y2VwdCBpdCBNVVNUIE5PVCBi ZSB0aGUgYnVpbHQtaW4gdHlwZQoiZW1wdHkiLicgU28gaXMgaXQgT0sgaWYgSSB1c2UgYSB0eXBl IGRlcml2ZWQgZnJvbSBlbXB0eSBhcyBhIGtleT8KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2Es IENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Sep 10 07:19: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 E7A953A67D8; Wed, 10 Sep 2008 07:19:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCD93A68E1 for ; Wed, 10 Sep 2008 07:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.727, 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 bqhqngC24ytA for ; Wed, 10 Sep 2008 07:19:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ED76F3A67D8 for ; Wed, 10 Sep 2008 07:19:15 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD0DAC0071; Wed, 10 Sep 2008 16:19:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jJulKb8Bxl7n; Wed, 10 Sep 2008 16:19:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77D4CC0080; Wed, 10 Sep 2008 16:19:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 78A4F6C0B36; Wed, 10 Sep 2008 16:19:13 +0200 (CEST) Date: Wed, 10 Sep 2008 16:19:13 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080910141913.GA23369@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1221054119.9589.95.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 10, 2008 at 03:41:59PM +0200, Ladislav Lhotka wrote: OLD: A leaf that is part of the key can be of any built-in or derived type, except it MUST NOT be the built-in type "empty". NEW 1: A leaf that is part of the key can be of any built-in or derived type. Note that leafs using a type allowing only a single value (e.g. the built-in type empty) are not useful as part of a key. NEW 2: A leaf that is part of the key can be of any built-in or derived type. Which do you want Lada? /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 Wed Sep 10 07:35:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A463D3A6783; Wed, 10 Sep 2008 07:35:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A103A688E for ; Wed, 10 Sep 2008 07:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=0.366, 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 YVLrmsQJqMMT for ; Wed, 10 Sep 2008 07:35:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 07D683A6783 for ; Wed, 10 Sep 2008 07:35:24 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5D556D800D1; Wed, 10 Sep 2008 16:35:26 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080910141913.GA23369@elstar.local> References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> Organization: CESNET Date: Wed, 10 Sep 2008 16:35:27 +0200 Message-Id: <1221057327.9589.105.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFN0IDEwLiAwOS4gMjAwOCB2IDE2OjE5ICsw MjAwOgo+IE9uIFdlZCwgU2VwIDEwLCAyMDA4IGF0IDAzOjQxOjU5UE0gKzAyMDAsIExhZGlzbGF2 IExob3RrYSB3cm90ZToKPiAKPiBPTEQ6Cj4gCj4gICAgQSBsZWFmIHRoYXQgaXMgcGFydCBvZiB0 aGUga2V5IGNhbiBiZSBvZiBhbnkgYnVpbHQtaW4gb3IgZGVyaXZlZAo+ICAgIHR5cGUsIGV4Y2Vw dCBpdCBNVVNUIE5PVCBiZSB0aGUgYnVpbHQtaW4gdHlwZSAiZW1wdHkiLgo+IAo+IE5FVyAxOgo+ ICAgIEEgbGVhZiB0aGF0IGlzIHBhcnQgb2YgdGhlIGtleSBjYW4gYmUgb2YgYW55IGJ1aWx0LWlu IG9yIGRlcml2ZWQKPiAgICB0eXBlLiBOb3RlIHRoYXQgbGVhZnMgdXNpbmcgYSB0eXBlIGFsbG93 aW5nIG9ubHkgYSBzaW5nbGUgdmFsdWUKPiAgICAoZS5nLiB0aGUgYnVpbHQtaW4gdHlwZSBlbXB0 eSkgYXJlIG5vdCB1c2VmdWwgYXMgcGFydCBvZiBhIGtleS4KPiAKPiBORVcgMjoKPiAgICBBIGxl YWYgdGhhdCBpcyBwYXJ0IG9mIHRoZSBrZXkgY2FuIGJlIG9mIGFueSBidWlsdC1pbiBvciBkZXJp dmVkCj4gICAgdHlwZS4KPiAKPiBXaGljaCBkbyB5b3Ugd2FudCBMYWRhPwoKQm90aCBORVcgMSBh bmQgMiBhcmUgZmluZSwgSSBzbGlnaHRseSBwcmVmZXIgMiBzaW5jZSBpdCBpcyBzaW1wbGUgYW5k CnN0cmFpZ2h0Zm9yd2FyZCBhbmQgZXZlcnl0aGluZyB3aWxsIHdvcmsgcXVpdGUgcHJlZGljdGFi bHkuCgpMYWRhCiAKPiAKPiAvanMKPiAKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBL ZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Sep 10 08:10: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 342823A6B7C; Wed, 10 Sep 2008 08:10:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0E828C1C9 for ; Wed, 10 Sep 2008 08:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nSwIaUGg6s6 for ; Wed, 10 Sep 2008 08:10:22 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 85F063A6B7C for ; Wed, 10 Sep 2008 08:10:22 -0700 (PDT) Received: (qmail 11088 invoked from network); 10 Sep 2008 15:10:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 10 Sep 2008 15:10:25 -0000 X-YMail-OSG: hQ7pWW4VM1nwIdtLXoLXzJHhMxz7UoKKOavXVtQcnTzCdlHlzMjghhlHifLBjuCyi4e21NKN4E1PBRp9Kx96ztu9IwJWaBIZqGr8A4XQ.w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C7E35F.2000005@netconfcentral.com> Date: Wed, 10 Sep 2008 08:10:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> In-Reply-To: <1221057327.9589.105.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBww63FoWUgdiBT dCAxMC4gMDkuIDIwMDggdiAxNjoxOSArMDIwMDoKPj4gT24gV2VkLCBTZXAgMTAsIDIwMDggYXQg MDM6NDE6NTlQTSArMDIwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+Pgo+PiBPTEQ6Cj4+Cj4+ ICAgIEEgbGVhZiB0aGF0IGlzIHBhcnQgb2YgdGhlIGtleSBjYW4gYmUgb2YgYW55IGJ1aWx0LWlu IG9yIGRlcml2ZWQKPj4gICAgdHlwZSwgZXhjZXB0IGl0IE1VU1QgTk9UIGJlIHRoZSBidWlsdC1p biB0eXBlICJlbXB0eSIuCj4+Cj4+IE5FVyAxOgo+PiAgICBBIGxlYWYgdGhhdCBpcyBwYXJ0IG9m IHRoZSBrZXkgY2FuIGJlIG9mIGFueSBidWlsdC1pbiBvciBkZXJpdmVkCj4+ICAgIHR5cGUuIE5v dGUgdGhhdCBsZWFmcyB1c2luZyBhIHR5cGUgYWxsb3dpbmcgb25seSBhIHNpbmdsZSB2YWx1ZQo+ PiAgICAoZS5nLiB0aGUgYnVpbHQtaW4gdHlwZSBlbXB0eSkgYXJlIG5vdCB1c2VmdWwgYXMgcGFy dCBvZiBhIGtleS4KPj4KCgpUaGVyZSBpcyBhIGJpZyBkaWZmZXJlbmNlIGJldHdlZW4gYW4gZW51 bWVyYXRpb24gYXMgYSBrZXkKd2hpY2ggaGFwcGVucyB0byBvbmx5IGhhdmUgb25lIGVudW0gdmFs dWUgYXNzaWduZWQgc28gZmFyLAphbmQgYW4gJ2VtcHR5JyBhcyBhIGtleSwgd2hpY2ggY2FuIG5l dmVyIGhhdmUgYSAybmQgdmFsdWUgYWRkZWQuCgpJTU8sIHRoZSBmaXggaXMgc2ltcGx5OgoKT0xE OgoKICAuLi4gTVVTVCBOT1QgYmUgdGhlIGJ1aWx0LWluIHR5cGUgImVtcHR5Ii4KCk5FVzoKCiAg Li4uIE1VU1QgTk9UIGJlIHRoZSBidWlsdC1pbiB0eXBlICJlbXB0eSIsIG9yIGFueSB0eXBlCiAg ZGVyaXZlZCBmcm9tIHRoZSBidWlsdC1pbiB0eXBlICJlbXB0eSIuCgoKPj4gTkVXIDI6Cj4+ICAg IEEgbGVhZiB0aGF0IGlzIHBhcnQgb2YgdGhlIGtleSBjYW4gYmUgb2YgYW55IGJ1aWx0LWluIG9y IGRlcml2ZWQKPj4gICAgdHlwZS4KPj4KPj4gV2hpY2ggZG8geW91IHdhbnQgTGFkYT8KPiAKPiBC b3RoIE5FVyAxIGFuZCAyIGFyZSBmaW5lLCBJIHNsaWdodGx5IHByZWZlciAyIHNpbmNlIGl0IGlz IHNpbXBsZSBhbmQKPiBzdHJhaWdodGZvcndhcmQgYW5kIGV2ZXJ5dGhpbmcgd2lsbCB3b3JrIHF1 aXRlIHByZWRpY3RhYmx5Lgo+IAo+IExhZGEKPiAgCj4+IC9qcwo+PgoKQW5keQoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlz dApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QK From netmod-bounces@ietf.org Wed Sep 10 08:30: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 5C1E93A67D8; Wed, 10 Sep 2008 08:30:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670093A6863 for ; Wed, 10 Sep 2008 08:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=-0.260, 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 vs7VNvVytoCE for ; Wed, 10 Sep 2008 08:30:39 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id A53763A67D8 for ; Wed, 10 Sep 2008 08:30:39 -0700 (PDT) Received: (qmail 42454 invoked from network); 10 Sep 2008 15:30:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 10 Sep 2008 15:30:43 -0000 X-YMail-OSG: U9pjP0kVM1lAypHtyT5EcRjwoEv0pdhbAdtn6Rfe4kUFu16ZjBeDtOfi68jwrwyA.48tRVV71D8blI9n1fLq_0QzsPY2pBvLN0cTtQV25A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C7E822.5050703@andybierman.com> Date: Wed, 10 Sep 2008 08:30:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, The draft should highlight the differences between XPath strings and YANG strings, and which applies. All strings in a YANG file are YANG strings. The compiler will follow the rules for YANG quoting and string concatenation, not XPath rules. (BTW, you should always use single-quotes for pattern strings unless you really know what you are doing.) So how does the user include a double quote within a must-expr? Is it the character entity "? Is it the YANG escaped quote \"? In order to use the escaped quote, the entire string must be double-quoted, which means all the whitespace trimming will be done as well. This may or may not matter to the XPath expression. What about other character entities, like < and >? IMO, YANG should define specific processing steps, so that all YANG modules will be interpreted exactly the same way by a compliant compiler. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 08:42: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 A19603A6C92; Wed, 10 Sep 2008 08:42:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DD73A6C92 for ; Wed, 10 Sep 2008 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 4NHRzGPEkjCl for ; Wed, 10 Sep 2008 08:42:26 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id C96EA3A6D9A for ; Wed, 10 Sep 2008 08:42:21 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Wed, 10 Sep 2008 08:39:35 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 08:41:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 08:41:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 08:41:54 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8AFfrM21327; Wed, 10 Sep 2008 08:41:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8AFc4Gg040578; Wed, 10 Sep 2008 15:38:04 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809101538.m8AFc4Gg040578@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1221054119.9589.95.camel@missotis> Date: Wed, 10 Sep 2008 11:38:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Sep 2008 15:41:54.0261 (UTC) FILETIME=[C0196050:01C9135B] Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >If empty was allowed and the draft didn't mention it, I am absolutely >sure it would never pop up as a problem or FAQ question. By mentioning >it, this trivial issue gains importance. I see it as a premature >optimization, or CLR. I see it as a code path I don't need to write/test/maintain, as a mistake a compiler can catch, and as a source of incompatibilities between tools sets (where many tools won't test such an odd scenario). Making it illegal hurts no one. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 09:46: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 6343B3A6DA2; Wed, 10 Sep 2008 09:46:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26FD28C26F for ; Wed, 10 Sep 2008 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 sKgJLBma33JP for ; Wed, 10 Sep 2008 09:46:19 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id CD24D3A6DA2 for ; Wed, 10 Sep 2008 09:46:18 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 10 Sep 2008 09:46:23 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 09:46:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 09:46:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 09:46:19 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8AGkJM52941; Wed, 10 Sep 2008 09:46:19 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8AGgRZK041410; Wed, 10 Sep 2008 16:42:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809101642.m8AGgRZK041410@idle.juniper.net> To: Andy Bierman In-reply-to: <48C7E822.5050703@andybierman.com> Date: Wed, 10 Sep 2008 12:42:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Sep 2008 16:46:19.0856 (UTC) FILETIME=[C02C5D00:01C91364] Cc: NETMOD Working Group Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.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: >(BTW, you should always use single-quotes for pattern strings > unless you really know what you are doing.) Why do you say that? >So how does the user include a double quote within a must-expr? Use single quotes or escape the double quote. >Is it the character entity "? " is a UTF-8 character entity, so your parser should parse this into '"'. Since the entire file is UTF-8, you can say voodoo like: leaf "test" { description '"' + "\"" + " <-- look! two quotes"; } and the right thing should happen. >Is it the YANG escaped quote \"? This should work. >In order to use the escaped quote, the entire string must be >double-quoted, which means all the whitespace trimming will >be done as well. This may or may not matter to the XPath expression. And you can mix single and double quotes using "+". >What about other character entities, like < and >? These keep their normal UTF-8 magic, but get no other magic, so "" and "<foo>" are identical. >IMO, YANG should define specific processing steps, >so that all YANG modules will be interpreted exactly >the same way by a compliant compiler. Does this need to be detailed in the spec, in the FAQ, or in "The YANG Book"? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 10:24: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 47D5D3A69FC; Wed, 10 Sep 2008 10:24:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078973A6D0A for ; Wed, 10 Sep 2008 10:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 241AQYK1X5W2 for ; Wed, 10 Sep 2008 10:24:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E88DD3A69FC for ; Wed, 10 Sep 2008 10:24:39 -0700 (PDT) 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 m8AHOgKI010139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 19:24:42 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8AHOfGE000497; Wed, 10 Sep 2008 19:24:41 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 19:24:39 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 19:24:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Sep 2008 20:24:45 +0300 Message-ID: <210412A63D60154898B7CDC3C7172BDE5F23C1@FIESEXC007.nsn-intra.net> In-Reply-To: <200809101642.m8AGgRZK041410@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] YANG strings vs XPath strings Thread-Index: AckTZMlUqPnDZpgiQleujSz1w49gRwAAWRWQ References: <48C7E822.5050703@andybierman.com> <200809101642.m8AGgRZK041410@idle.juniper.net> From: "Lahdensivu, Mikko (NSN - FI/Tampere)" To: "ext Phil Shafer" X-OriginalArrivalTime: 10 Sep 2008 17:24:39.0218 (UTC) FILETIME=[1AB32920:01C9136A] Cc: NETMOD Working Group , Andy Bierman Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, >-----Original Message----- >From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] >On Behalf Of ext Phil Shafer >Sent: 10.09.2008 19:42 >To: Andy Bierman >Cc: NETMOD Working Group >Subject: Re: [netmod] YANG strings vs XPath strings > >Andy Bierman writes: >>(BTW, you should always use single-quotes for pattern strings >> unless you really know what you are doing.) > >>Is it the character entity "? > >" is a UTF-8 character entity, so your parser should >parse this into '"'. Since the entire file is UTF-8, you can >say voodoo >like: > > leaf "test" { > description '"' + "\"" + " > <-- look! two quotes"; > } >>What about other character entities, like < and >? > >These keep their normal UTF-8 magic, but get no other magic, >so "" and "<foo>" are identical. " or other such entity references (which not same as character references i.e. ) are not part of UTF-8 encoding, but are just part of XML. Some other UTF-8 reader would not necessarily interpret them as entity references like an XML parser would. If the idea is that entity references (or even character references) from XML can be used in Yang, then it must be explictly specified in Yang. Yin gets these of course from XML. Regards, Mikko _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 10:34:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588D93A6DA4; Wed, 10 Sep 2008 10:34:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340BC3A6DA3 for ; Wed, 10 Sep 2008 10:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spp3yQCqfrCr for ; Wed, 10 Sep 2008 10:34:45 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 79B8F3A6DA2 for ; Wed, 10 Sep 2008 10:34:45 -0700 (PDT) Received: (qmail 30668 invoked from network); 10 Sep 2008 17:34:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 10 Sep 2008 17:34:49 -0000 X-YMail-OSG: jmi4PJ0VM1mDp_KFCSLg0d2nneyL2wGDbHnM.tM7.Xn4m.BDeS0gHBqKSdbpVVXCVWaObn67pfLZqSADRJCtRpQ73iCLekh53OaL6jGCag-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C80537.7050202@netconfcentral.com> Date: Wed, 10 Sep 2008 10:34:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809101642.m8AGgRZK041410@idle.juniper.net> In-Reply-To: <200809101642.m8AGgRZK041410@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> (BTW, you should always use single-quotes for pattern strings >> unless you really know what you are doing.) > > Why do you say that? > Double quoted strings get processed, like replacing escape-chars and trimming whitespace. Single-quoted strings do not get touched. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 13:33:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D252A3A6DAA; Wed, 10 Sep 2008 13:33:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15C928C295 for ; Wed, 10 Sep 2008 13:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.148, 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 OV1zKkfyfIRR for ; Wed, 10 Sep 2008 13:33:24 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C7E023A6DA5 for ; Wed, 10 Sep 2008 13:33:24 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id E946C76C250; Wed, 10 Sep 2008 22:33:27 +0200 (CEST) Date: Wed, 10 Sep 2008 22:33:58 +0200 (CEST) Message-Id: <20080910.223358.88603079.mbj@tail-f.com> To: andy@andybierman.com From: Martin Bjorklund In-Reply-To: <48C7E822.5050703@andybierman.com> References: <48C7E822.5050703@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 draft should highlight the differences between XPath strings > and YANG strings, and which applies. I think it might be confusing to do so, but maybe you can propose some text that we can discuss? > All strings in a YANG file are YANG strings. > The compiler will follow the rules for YANG quoting and > string concatenation, not XPath rules. What XPath rules? (Should we really list all rules we don't follow??) > (BTW, you should always use single-quotes for pattern strings > unless you really know what you are doing.) > > So how does the user include a double quote within a must-expr? > Is it the character entity "? No we never say that in the draft. That's an XML thing. If you write YIN models, you can use this. > Is it the YANG escaped quote \"? If you're in a double quoted string, yes. > In order to use the escaped quote, the entire string must be > double-quoted, which means all the whitespace trimming will > be done as well. This may or may not matter to the XPath expression. Sure. > What about other character entities, like < and >? Useful in YIN only since it's XML. > IMO, YANG should define specific processing steps, > so that all YANG modules will be interpreted exactly > the same way by a compliant compiler. Are you saying that we need something more than the rules in 6.1.3? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 15:25: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 BEB993A67CC; Wed, 10 Sep 2008 15:25:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02753A67CC for ; Wed, 10 Sep 2008 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.704, 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 ToNtsP+mAxBg for ; Wed, 10 Sep 2008 15:25:51 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id E6F193A67F1 for ; Wed, 10 Sep 2008 15:25:51 -0700 (PDT) Received: (qmail 6644 invoked from network); 10 Sep 2008 22:25:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 10 Sep 2008 22:25:55 -0000 X-YMail-OSG: YdvAUOMVM1lB1RVbr0q5oykVHyrs2Dtw1SZcnYlRt0GbfqvYRhx34jbSeD5cC09yOcx4ECBvX3nlj29ERl.UNM3frDXDn1CFFhdk37jDLXrqcApkmgHV3omvdwXZtPA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C84970.6070807@netconfcentral.com> Date: Wed, 10 Sep 2008 15:25:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48C7E822.5050703@andybierman.com> <20080910.223358.88603079.mbj@tail-f.com> In-Reply-To: <20080910.223358.88603079.mbj@tail-f.com> Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The draft should highlight the differences between XPath strings >> and YANG strings, and which applies. > > I think it might be confusing to do so, but maybe you can propose some > text that we can discuss? > >> All strings in a YANG file are YANG strings. >> The compiler will follow the rules for YANG quoting and >> string concatenation, not XPath rules. > > What XPath rules? (Should we really list all rules we don't follow??) > >> (BTW, you should always use single-quotes for pattern strings >> unless you really know what you are doing.) >> >> So how does the user include a double quote within a must-expr? >> Is it the character entity "? > > No we never say that in the draft. That's an XML thing. If you write > YIN models, you can use this. > >> Is it the YANG escaped quote \"? > > If you're in a double quoted string, yes. > >> In order to use the escaped quote, the entire string must be >> double-quoted, which means all the whitespace trimming will >> be done as well. This may or may not matter to the XPath expression. > > Sure. > >> What about other character entities, like < and >? > > Useful in YIN only since it's XML. > >> IMO, YANG should define specific processing steps, >> so that all YANG modules will be interpreted exactly >> the same way by a compliant compiler. > > Are you saying that we need something more than the rules in 6.1.3? > It is now clear to me that character entities are NOT converted when they are inside a quoted string. These do not follow the same rules as a select attribute, encoded inside a NETCONF PDU (XML document). Instead, they will be treated as errors and not converted, since the must-stmt strings are in YANG documents, not XML documents. YANG does not recognize any character entities inside quotes strings. C-style escape char sequences are used in YANG instead. As for character entities peppered throughout the YANG document: I was not aware that was a requirement for YANG compilers. It should be made more clear in the draft. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 15:52: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 0C3EF3A6A06; Wed, 10 Sep 2008 15:52:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A223A6A64 for ; Wed, 10 Sep 2008 15:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.705, 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 g1hWu2blXpZf for ; Wed, 10 Sep 2008 15:52:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9F73F3A6A06 for ; Wed, 10 Sep 2008 15:52:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DEBDC0084; Thu, 11 Sep 2008 00:52:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EEXYyWsP+k99; Thu, 11 Sep 2008 00:52:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25363C0086; Thu, 11 Sep 2008 00:52:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D60786C5444; Thu, 11 Sep 2008 00:52:00 +0200 (CEST) Date: Thu, 11 Sep 2008 00:52:00 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080910225200.GA500@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48C7E35F.2000005@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 10, 2008 at 08:10:23AM -0700, Andy Bierman wrote: > Ladislav Lhotka wrote: >> Juergen Schoenwaelder p????e v St 10. 09. 2008 v 16:19 +0200: >>> On Wed, Sep 10, 2008 at 03:41:59PM +0200, Ladislav Lhotka wrote: >>> >>> OLD: >>> >>> A leaf that is part of the key can be of any built-in or derived >>> type, except it MUST NOT be the built-in type "empty". >>> >>> NEW 1: >>> A leaf that is part of the key can be of any built-in or derived >>> type. Note that leafs using a type allowing only a single value >>> (e.g. the built-in type empty) are not useful as part of a key. >>> > > > There is a big difference between an enumeration as a key > which happens to only have one enum value assigned so far, > and an 'empty' as a key, which can never have a 2nd value added. > > IMO, the fix is simply: > > OLD: > > ... MUST NOT be the built-in type "empty". > > NEW: > > ... MUST NOT be the built-in type "empty", or any type > derived from the built-in type "empty". Well, this is still kind of arbitrary. There are other ways to define leafs that do not make sense as keys in YANG: leaf a { type string { length 0; } } leaf b { type int32 { range "0..0"; } } Right now all of these definitions seem to be legal but they are also pretty pointless. Shall we now add language for all these constructs that are pointless to forbid them? I don't think so - it is way too risky to screw this up. I would leave it to implementations to catch such things and to produce proper warnings. So I am slowly moving into Lada's camp: A leaf that is part of the key can be of any built-in or derived type. /js PS: I am not sure whether 8.1.3 allows this or not: typedef c { type int32 { range "0..1"; } } leaf d { type c { range "1..2"; } } I also do not see why the third example in 8.1.4 is illegal. -- 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 Wed Sep 10 16:51: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 BABDF3A6921; Wed, 10 Sep 2008 16:51:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890363A69D9 for ; Wed, 10 Sep 2008 16:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 7AqvHQhZxr9l for ; Wed, 10 Sep 2008 16:51:03 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id D36973A6921 for ; Wed, 10 Sep 2008 16:51:03 -0700 (PDT) Received: (qmail 45719 invoked from network); 10 Sep 2008 23:51:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 10 Sep 2008 23:51:08 -0000 X-YMail-OSG: RO0ZxDsVM1nqwqp8vQ_vJDXstuv4h0RWK4EsN7yFOmsZR255CU3vDaDiGGVPaKQOnbsJq2iw.W95IO9gZjXgORnaJfOq.pbNFhU0YD3oEA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C85D69.1040806@netconfcentral.com> Date: Wed, 10 Sep 2008 16:51:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> In-Reply-To: <20080910225200.GA500@elstar.local> Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 Wed, Sep 10, 2008 at 08:10:23AM -0700, Andy Bierman wrote: >> Ladislav Lhotka wrote: >>> Juergen Schoenwaelder p????e v St 10. 09. 2008 v 16:19 +0200: >>>> On Wed, Sep 10, 2008 at 03:41:59PM +0200, Ladislav Lhotka wrote: >>>> >>>> OLD: >>>> >>>> A leaf that is part of the key can be of any built-in or derived >>>> type, except it MUST NOT be the built-in type "empty". >>>> >>>> NEW 1: >>>> A leaf that is part of the key can be of any built-in or derived >>>> type. Note that leafs using a type allowing only a single value >>>> (e.g. the built-in type empty) are not useful as part of a key. >>>> >> >> There is a big difference between an enumeration as a key >> which happens to only have one enum value assigned so far, >> and an 'empty' as a key, which can never have a 2nd value added. >> >> IMO, the fix is simply: >> >> OLD: >> >> ... MUST NOT be the built-in type "empty". >> >> NEW: >> >> ... MUST NOT be the built-in type "empty", or any type >> derived from the built-in type "empty". > > Well, this is still kind of arbitrary. There are other ways to define > leafs that do not make sense as keys in YANG: > > leaf a { type string { length 0; } } > > leaf b { type int32 { range "0..0"; } } > > Right now all of these definitions seem to be legal but they are also > pretty pointless. Shall we now add language for all these constructs > that are pointless to forbid them? I don't think so - it is way too > risky to screw this up. I would leave it to implementations to catch > such things and to produce proper warnings. So I am slowly moving into > Lada's camp: > > A leaf that is part of the key can be of any built-in or derived > type. > I disagree with you and Lada, and agree with Phil instead ;-) There are lots of rules/decisions in YANG that are intended to yield better data modeling practices. The problem with 'NEW 1' above is that tools MUST support empty as a key. Saying that an empty leaf is not useful as a key does not help very much. A leaf specified in the key must always be present, and any default is ignored. Therefore, a key which can only ever have 1 value seems to be a waste of space. This is a pretty big pile of "garbage-in/garbage-out" to add to the language. How do I specify empty in a predicate in an instance-identifier? It it just '' (e.g., /foo[emptykey='']/bar), even though the empty data type is not a string? (so maybe a tool that sees 'emptykey=value' will trigger an error since any value for 'emptykey' is an error?) > /js Andy > > PS: I am not sure whether 8.1.3 allows this or not: > > typedef c { type int32 { range "0..1"; } } > leaf d { type c { range "1..2"; } } > > I also do not see why the third example in 8.1.4 is illegal. > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 18:17: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 B725F3A685B; Wed, 10 Sep 2008 18:17:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0023A6994 for ; Wed, 10 Sep 2008 18:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.283 X-Spam-Level: X-Spam-Status: No, score=-0.283 tagged_above=-999 required=5 tests=[AWL=-0.618, 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 7JvWj5WSKC84 for ; Wed, 10 Sep 2008 18:17:03 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id D82683A685B for ; Wed, 10 Sep 2008 18:17:03 -0700 (PDT) Received: (qmail 20975 invoked from network); 11 Sep 2008 01:16:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Sep 2008 01:16:57 -0000 X-YMail-OSG: P1JCcioVM1kSYQUDDQt1Ag5UtO0BnbQA469NYvZhtgTFSF5N9IhtleBVU.LoI8DGt8W9RZEtGgCUuV6V1zPxVNzLozn4wp3VF3ARKExvhA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C87187.3060503@netconfcentral.com> Date: Wed, 10 Sep 2008 18:16:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> In-Reply-To: <20080910225200.GA500@elstar.local> Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 >.. > PS: I am not sure whether 8.1.3 allows this or not: > > typedef c { type int32 { range "0..1"; } } > leaf d { type c { range "1..2"; } } > this is not allowed. you can only refine a range (8.1.3, para 2, s3) > I also do not see why the third example in 8.1.4 is illegal. > probably because it isn't :-) there's a bug in the example: OLD: type int32 { // illegal range restriction range "11..100"; } NEW: type my-base-int32-type { // illegal range restriction range "11..100"; } Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 10 23:22: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 E9D9A3A63C9; Wed, 10 Sep 2008 23:22:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9043A6B6A for ; Wed, 10 Sep 2008 23:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppwRDhprWONP for ; Wed, 10 Sep 2008 23:22:16 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6C3443A63C9 for ; Wed, 10 Sep 2008 23:22:16 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 39294D800C5; Thu, 11 Sep 2008 08:22:19 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48C85D69.1040806@netconfcentral.com> References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C85D69.1040806@netconfcentral.com> Organization: CESNET Date: Thu, 11 Sep 2008 08:22:18 +0200 Message-Id: <1221114138.6242.30.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDEwLiAwOS4gMjAwOCB2IDE2OjUxIC0wNzAwOgo+IEkg ZGlzYWdyZWUgd2l0aCB5b3UgYW5kIExhZGEsIGFuZCBhZ3JlZSB3aXRoIFBoaWwgaW5zdGVhZCA7 LSkKPiBUaGVyZSBhcmUgbG90cyBvZiBydWxlcy9kZWNpc2lvbnMgaW4gWUFORyB0aGF0IGFyZSBp bnRlbmRlZAo+IHRvIHlpZWxkIGJldHRlciBkYXRhIG1vZGVsaW5nIHByYWN0aWNlcy4KPiAKPiBU aGUgcHJvYmxlbSB3aXRoICdORVcgMScgYWJvdmUgaXMgdGhhdCB0b29scyBNVVNUIHN1cHBvcnQK PiBlbXB0eSBhcyBhIGtleS4gIFNheWluZyB0aGF0IGFuIGVtcHR5IGxlYWYgaXMgbm90IHVzZWZ1 bAo+IGFzIGEga2V5IGRvZXMgbm90IGhlbHAgdmVyeSBtdWNoLgo+IAo+IEEgbGVhZiBzcGVjaWZp ZWQgaW4gdGhlIGtleSBtdXN0IGFsd2F5cyBiZSBwcmVzZW50LAo+IGFuZCBhbnkgZGVmYXVsdCBp cyBpZ25vcmVkLiAgVGhlcmVmb3JlLCBhIGtleSB3aGljaAo+IGNhbiBvbmx5IGV2ZXIgaGF2ZSAx IHZhbHVlIHNlZW1zIHRvIGJlIGEgd2FzdGUgb2Ygc3BhY2UuCgpUaGlzIGlzIGFsbCB0cnVlLCBi dXQgd2h5IGlzIGl0IGEgcHJvYmxlbSB0aGF0IFlBTkcgb3IgYW55IHRvb2xzIG11c3QKZXhwbGlj aXRseSBhdm9pZD8gVGhlIGVtcHR5IGtleSBsZWFmIHdpbGwgYmUgcHJlc2VudCBhbmQgYWRkcyBu bwp2YXJpYWJpbGl0eSB0byB0aGUga2V5LCBzbyBpdCBpcyBwb2ludGxlc3MgYnV0IGNvbnNpc3Rl bnQuCgpJIHVuZGVyc3RhbmQgdGhhdCBwcm9ncmFtbWluZyBhbmQgZGF0YWJhc2UgbGFuZ3VhZ2Vz IG1heSBub3QgaGF2ZSBhbgplbXB0eSB0eXBlIGJ1dCBpdCBzaG91bGQgYmUgZWFzeSB0byBlbXVs YXRlIGl0IGlmIG5lY2Vzc2FyeS4KCj4gCj4gVGhpcyBpcyBhIHByZXR0eSBiaWcgcGlsZSBvZiAi Z2FyYmFnZS1pbi9nYXJiYWdlLW91dCIKPiB0byBhZGQgdG8gdGhlIGxhbmd1YWdlLgoKSSBhY3R1 YWxseSBzZWUgbGVzcyBnYXJiYWdlIGluIHRoZSBsYW5ndWFnZSBkZWZpbml0aW9uLgoKPiAKPiBI b3cgZG8gSSBzcGVjaWZ5IGVtcHR5IGluIGEgcHJlZGljYXRlIGluIGFuIGluc3RhbmNlLWlkZW50 aWZpZXI/Cj4gSXQgaXQganVzdCAnJyAoZS5nLiwgL2Zvb1tlbXB0eWtleT0nJ10vYmFyKSwgZXZl bgoKVGhpcyB3aWxsIHdvcmsgaW4gWFBhdGggKGJ1dCB3aXRoIGFsbCB0aHJlZSBRTmFtZXMgaGF2 aW5nIG5hbWVzcGFjZQpwcmVmaXhlcyE6LSkgc2luY2UgaW4gWE1MIGEgbGVhZiB3aXRoIGVtcHR5 IHR5cGUgaW4gaW5kaXN0aW5ndWlzaGFibGUKZnJvbSAndHlwZSBzdHJpbmcgeyBsZW5ndGggMDsg fScuIE9yIHlvdSBjYW4gdXNlIAoKL2Zvb1tlbXB0eWtleV0vYmFyIAoKTGFkYQoKLS0gCkxhZGlz bGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1v ZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Sep 10 23:35:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE2D3A6880; Wed, 10 Sep 2008 23:35:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1D13A69C7 for ; Wed, 10 Sep 2008 23:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=0.684, 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 WMLlve7uQi5b for ; Wed, 10 Sep 2008 23:35:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D98A03A6880 for ; Wed, 10 Sep 2008 23:35:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A44F5C0093; Thu, 11 Sep 2008 08:35:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sTBx2BsJFiun; Thu, 11 Sep 2008 08:35:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B94CCC0098; Thu, 11 Sep 2008 08:35:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9B2B16C56FE; Thu, 11 Sep 2008 08:35:05 +0200 (CEST) Date: Thu, 11 Sep 2008 08:35:05 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080911063505.GA736@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48C87187.3060503@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 10, 2008 at 06:16:55PM -0700, Andy Bierman wrote: > >.. > > PS: I am not sure whether 8.1.3 allows this or not: > > > > typedef c { type int32 { range "0..1"; } } > > leaf d { type c { range "1..2"; } } > > this is not allowed. > you can only refine a range (8.1.3, para 2, s3) > > > I also do not see why the third example in 8.1.4 is illegal. So is the following valid then? typedef d { type int32 { range "0..3|5..7"; } } typedef e { type d { range "3..6"; } } /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 Wed Sep 10 23:45: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 911623A659B; Wed, 10 Sep 2008 23:45:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8FB3A659B for ; Wed, 10 Sep 2008 23:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=0.665, 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 5F0SURvbuFkk for ; Wed, 10 Sep 2008 23:45:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 38DC33A63C9 for ; Wed, 10 Sep 2008 23:45:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CADDAC0093; Thu, 11 Sep 2008 08:44:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FO4liQQjqMtQ; Thu, 11 Sep 2008 08:44:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65695C0091; Thu, 11 Sep 2008 08:44:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 443246C573B; Thu, 11 Sep 2008 08:44:45 +0200 (CEST) Date: Thu, 11 Sep 2008 08:44:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080911064445.GB736@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C85D69.1040806@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48C85D69.1040806@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 10, 2008 at 04:51:05PM -0700, Andy Bierman wrote: > The problem with 'NEW 1' above is that tools MUST support > empty as a key. Saying that an empty leaf is not useful > as a key does not help very much. But the handling of empty as a key should fall out naturally. You can always emulate empty with string { length 0; } anyways so I am not sure what the code saving is here. > A leaf specified in the key must always be present, > and any default is ignored. Therefore, a key which > can only ever have 1 value seems to be a waste of space. No question about that. But there are many ways to do stupid things in YANG and trying to catch everything and marking things as an _error_ makes a language complicated and you take a serious risk to shoot yourself into the foot by putting in a rule with best intentions that later bites you. For me, simplicity usually comes from orthogonality where things fall out naturally. /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 Sep 11 00:00: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 41CD53A67BD; Thu, 11 Sep 2008 00:00:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D483B3A69C7 for ; Thu, 11 Sep 2008 00:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.219, 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 nW0-6D5jyh7U for ; Thu, 11 Sep 2008 00:00:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 109323A6D71 for ; Thu, 11 Sep 2008 00:00:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8101476C250; Thu, 11 Sep 2008 09:00:29 +0200 (CEST) Date: Thu, 11 Sep 2008 09:01:09 +0200 (CEST) Message-Id: <20080911.090109.137930693.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48C87187.3060503@netconfcentral.com> References: <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@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] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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: > >.. > probably because it isn't :-) there's a bug in the example: > > > OLD: > > type int32 { > // illegal range restriction > range "11..100"; > } > > NEW: > > type my-base-int32-type { > // illegal range restriction > range "11..100"; > } Thanks, fixed. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 00:17: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 7DEF03A67F2; Thu, 11 Sep 2008 00:17:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614C53A67F2 for ; Thu, 11 Sep 2008 00:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=0.328, 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 HYuwsTLin18O for ; Thu, 11 Sep 2008 00:17:05 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 76F8C3A6914 for ; Thu, 11 Sep 2008 00:17:05 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 937F8D800EF; Thu, 11 Sep 2008 09:16:27 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48C84970.6070807@netconfcentral.com> References: <48C7E822.5050703@andybierman.com> <20080910.223358.88603079.mbj@tail-f.com> <48C84970.6070807@netconfcentral.com> Organization: CESNET Date: Thu, 11 Sep 2008 09:16:27 +0200 Message-Id: <1221117387.6242.47.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SGksCgpJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHRoaXMgZGlzY3Vzc2lvbi4gQSBzdHJpbmcg aW4gdGhlIHZhbHVlIHNwYWNlCm11c3QgaGF2ZSB0aGUgc2FtZSBtZWFuaW5nIGV2ZXJ5d2hlcmUs IGl0IGlzIG9ubHkgaXRzIHJlcHJlc2VudGF0aW9uIGluCnRoZSBsZXhpY2FsIHNwYWNlcyB3aGVy ZSBZQU5HIGRpZmZlcnMgZnJvbSBYTUwuCgpJZiB3ZSBhZ3JlZSB0aGF0IFlBTkcgbWFwcGluZyBm cm9tIHRoZSBsZXhpY2FsIHRvIHZhbHVlIHNwYWNlIGlzCndlbGwtZGVmaW5lZCwgdGhlcmUgc2hv dWxkIGJlIG5vIGRvdWJ0IGFib3V0IGFueSB2YWx1ZSBzcGFjZSB2YWx1ZSBhbmQKdGhpcyBpcyB3 aGF0IGlzIHVzZWQgaW4gWFBhdGggZXZhbHVhdGlvbiBvciB3aGF0ZXZlci4KCklmIGEgdmFsdWUg c3BhY2Ugc3RyaW5nIGlzIGNvbnZlcnRlZCB0byBzZXJpYWxpemVkIFhNTCAoZS5nLiwgWUlOKSwg aXQKbXVzdCBmb2xsb3cgdGhlIFhNTCBlbmNvZGluZyBydWxlcy4gU28KCiAgICAgICcmcXVvdDsn ICAgICAgIC0tPiAgPHN0cmluZyBvZiBsZW5ndGggNj4gIC0tPiAgICAgICZhbXA7cXVvdDsKIFlB TkcgbGV4aWNhbCBzcGFjZSAgICAgICAgICAgdmFsdWUgc3BhY2UgICAgICAgICAgICBYTUwgbGV4 aWNhbCBzcGFjZQoKTGFkYQoKQW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDEwLiAwOS4gMjAwOCB2 IDE1OjI1IC0wNzAwOgoKPiBJdCBpcyBub3cgY2xlYXIgdG8gbWUgdGhhdCBjaGFyYWN0ZXIgZW50 aXRpZXMgYXJlIE5PVCBjb252ZXJ0ZWQKPiB3aGVuIHRoZXkgYXJlIGluc2lkZSBhIHF1b3RlZCBz dHJpbmcuICBUaGVzZSBkbyBub3QgZm9sbG93Cj4gdGhlIHNhbWUgcnVsZXMgYXMgYSBzZWxlY3Qg YXR0cmlidXRlLCBlbmNvZGVkIGluc2lkZSBhCj4gTkVUQ09ORiBQRFUgKFhNTCBkb2N1bWVudCku Cj4gCj4gSW5zdGVhZCwgdGhleSB3aWxsIGJlIHRyZWF0ZWQgYXMgZXJyb3JzIGFuZCBub3QgY29u dmVydGVkLAo+IHNpbmNlIHRoZSBtdXN0LXN0bXQgc3RyaW5ncyBhcmUgaW4gWUFORyBkb2N1bWVu dHMsCj4gbm90IFhNTCBkb2N1bWVudHMuICBZQU5HIGRvZXMgbm90IHJlY29nbml6ZSBhbnkgY2hh cmFjdGVyCj4gZW50aXRpZXMgaW5zaWRlIHF1b3RlcyBzdHJpbmdzLiAgQy1zdHlsZSBlc2NhcGUg Y2hhciBzZXF1ZW5jZXMKPiBhcmUgdXNlZCBpbiBZQU5HIGluc3RlYWQuCj4gCj4gQXMgZm9yIGNo YXJhY3RlciBlbnRpdGllcyBwZXBwZXJlZCB0aHJvdWdob3V0IHRoZSBZQU5HIGRvY3VtZW50Ogo+ IEkgd2FzIG5vdCBhd2FyZSB0aGF0IHdhcyBhIHJlcXVpcmVtZW50IGZvciBZQU5HIGNvbXBpbGVy cy4KPiBJdCBzaG91bGQgYmUgbWFkZSBtb3JlIGNsZWFyIGluIHRoZSBkcmFmdC4KPiAKPiAKPiA+ IAo+ID4gL21hcnRpbgo+IAo+IEFuZHkKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5v cmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAotLSAKTGFk aXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0 bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k Cg== From netmod-bounces@ietf.org Thu Sep 11 00:28: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 C1D8B3A67F2; Thu, 11 Sep 2008 00:28:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C303A67F2 for ; Thu, 11 Sep 2008 00:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.646, 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 ClQgQqoHjW-o for ; Thu, 11 Sep 2008 00:28:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D37393A67BD for ; Thu, 11 Sep 2008 00:28:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5C0FC009C; Thu, 11 Sep 2008 09:27:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 83p+BW6c2gV3; Thu, 11 Sep 2008 09:27:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6B11C0097; Thu, 11 Sep 2008 09:27:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B6646C5806; Thu, 11 Sep 2008 09:27:22 +0200 (CEST) Date: Thu, 11 Sep 2008 09:27:22 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080911072722.GA858@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , netmod@ietf.org, andy@andybierman.com References: <48C7E822.5050703@andybierman.com> <20080910.223358.88603079.mbj@tail-f.com> <48C84970.6070807@netconfcentral.com> <1221117387.6242.47.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1221117387.6242.47.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org, andy@andybierman.com Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Sep 11, 2008 at 09:16:27AM +0200, Ladislav Lhotka wrote: > Hi, > > I don't really understand this discussion. A string in the value space > must have the same meaning everywhere, it is only its representation in > the lexical spaces where YANG differs from XML. > > If we agree that YANG mapping from the lexical to value space is > well-defined, there should be no doubt about any value space value and > this is what is used in XPath evaluation or whatever. > > If a value space string is converted to serialized XML (e.g., YIN), it > must follow the XML encoding rules. So > > '"' --> --> &quot; > YANG lexical space value space XML lexical space I agree. /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 Sep 11 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 E7FE93A6AD9; Thu, 11 Sep 2008 00:30:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA803A6AEA for ; Thu, 11 Sep 2008 00:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0AKBMTI+MjN for ; Thu, 11 Sep 2008 00:30:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 799653A67BD for ; Thu, 11 Sep 2008 00:30:03 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2419D2189B; Thu, 11 Sep 2008 09:28:34 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-d1-48c8c8a1b833 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF45B21874; Thu, 11 Sep 2008 09:28:33 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 09:27:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 09:27:51 +0200 Message-ID: <48C8C884.30405@ericsson.com> Date: Thu, 11 Sep 2008 09:28:04 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> In-Reply-To: <20080911063505.GA736@elstar.local> X-OriginalArrivalTime: 11 Sep 2008 07:27:51.0154 (UTC) FILETIME=[E5D7F520:01C913DF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 Wed, Sep 10, 2008 at 06:16:55PM -0700, Andy Bierman wrote: >> >.. >>> PS: I am not sure whether 8.1.3 allows this or not: >>> >>> typedef c { type int32 { range "0..1"; } } >>> leaf d { type c { range "1..2"; } } >> this is not allowed. >> you can only refine a range (8.1.3, para 2, s3) >> >>> I also do not see why the third example in 8.1.4 is illegal. > > So is the following valid then? > > typedef d { type int32 { range "0..3|5..7"; } } > typedef e { type d { range "3..6"; } } > IMO it is invalid. Any construct that adds even one single additional value to the value-space of a type is illegal (here the value 4). You should be able to be more restrictive but never to allow new values. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 00:42: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 4C88B3A659B; Thu, 11 Sep 2008 00:42:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A3B3A6835 for ; Thu, 11 Sep 2008 00:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.702, 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 hFGhrnv9PuEY for ; Thu, 11 Sep 2008 00:42:50 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 84BAA3A659B for ; Thu, 11 Sep 2008 00:42:50 -0700 (PDT) Received: (qmail 97764 invoked from network); 11 Sep 2008 07:42:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 11 Sep 2008 07:42:25 -0000 X-YMail-OSG: 9yB6F2gVM1lCCASVOuLW9pcTF.DJvyuYcq4OUq37hAcigwgzhH4edLxcn5j5gh.W9JxByc7sLGAdSSMgbGsZrGQG..YnuWURC6N7NR7mAQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C8CBDF.60501@netconfcentral.com> Date: Thu, 11 Sep 2008 00:42:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> In-Reply-To: <20080911063505.GA736@elstar.local> Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 Wed, Sep 10, 2008 at 06:16:55PM -0700, Andy Bierman wrote: >> >.. >>> PS: I am not sure whether 8.1.3 allows this or not: >>> >>> typedef c { type int32 { range "0..1"; } } >>> leaf d { type c { range "1..2"; } } >> this is not allowed. >> you can only refine a range (8.1.3, para 2, s3) >> >>> I also do not see why the third example in 8.1.4 is illegal. > > So is the following valid then? > > typedef d { type int32 { range "0..3|5..7"; } } > typedef e { type d { range "3..6"; } } > no - read sec 8.1.3, 2nd paragraph, 3rd sentence > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 00:52: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 D94FB3A659B; Thu, 11 Sep 2008 00:52:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BD23A67F2 for ; Thu, 11 Sep 2008 00:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.629, 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 eGZDFf+d2eLO for ; Thu, 11 Sep 2008 00:52:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4A5353A659B for ; Thu, 11 Sep 2008 00:52:19 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1159C008D; Thu, 11 Sep 2008 09:51:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qjpLe0jt5TrC; Thu, 11 Sep 2008 09:51:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA8BAC0086; Thu, 11 Sep 2008 09:51:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A56F6C5860; Thu, 11 Sep 2008 09:51:31 +0200 (CEST) Date: Thu, 11 Sep 2008 09:51:31 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080911075131.GA890@elstar.local> Mail-Followup-To: Balazs Lengyel , Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> <48C8C884.30405@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48C8C884.30405@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Sep 11, 2008 at 09:28:04AM +0200, Balazs Lengyel wrote: > > So is the following valid then? > > > > typedef d { type int32 { range "0..3|5..7"; } } > > typedef e { type d { range "3..6"; } } > IMO it is invalid. Any construct that adds even one single > additional value to the value-space of a type is illegal (here the > value 4). You should be able to be more restrictive but never to > allow new values. I agree - but then the example is not adding something according to my interpretation - I assumed the resulting value set is {3, 5, 6}. With pattern, we can effectively do the same - a pattern of a sub-type must be satisfied in addition to the pattern of the parent type. The question is whether the above is illegal and I would be forced to write "3|5..6". And I note again that with pattern we do not have constraints how they must be formed relative to each other when we apply them. The point really is that the value space can't increase by subtyping. But instead of saying that, we try to restrict the ranges syntax one is allowed to use and since this is hard to do and not really useful for pattern we don't do this for pattern. This is not very consistent. The other question is how we deal with restrictions that lead to an empty value set, e.g.: typedef f { type string { pattern "a"; } } typedef g { type f { pattern "b"; } } typedef h { type f { length 2; } } [With real world pattern that are several lines long, things like this might not always be obvious and easy to spot.] I think we need to spell out constraints in terms of the value set rather than the syntactic means of the restrictions. And I don't think we will succeed to mark all these things illegal by adding language rules to YANG without causing damage to the language. So we have to leave some of this to implementations to figure out what they can catch as warnings. /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 Sep 11 01:32: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 372743A68DE; Thu, 11 Sep 2008 01:32:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46E43A68DE for ; Thu, 11 Sep 2008 01:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 5x-sRNuFDnTs for ; Thu, 11 Sep 2008 01:32:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 955253A6A6A for ; Thu, 11 Sep 2008 01:32:17 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 69D1A20C9A; Thu, 11 Sep 2008 10:31:49 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-eb-48c8d775ab87 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 449DF20D28; Thu, 11 Sep 2008 10:31:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 10:31:49 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 10:31:48 +0200 Message-ID: <48C8D782.2020301@ericsson.com> Date: Thu, 11 Sep 2008 10:32:02 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> <48C8C884.30405@ericsson.com> <20080911075131.GA890@elstar.local> In-Reply-To: <20080911075131.GA890@elstar.local> X-OriginalArrivalTime: 11 Sep 2008 08:31:48.0875 (UTC) FILETIME=[D54DB5B0:01C913E8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 agree that we should state "the value space can't increase by subtyping" as a basic rule. However we must also explicitly state whether this 3..6 will include 4 or not, (not trivial), so are all constraints in the type chain to be considered or just the last one which must be valid according to the basic rule. I would not be too worried about empty value spaces. They are just one of the ways to shoot yourself. Maybe add: "An implementation MAY consider a data type that has an empty value space as a YANG error." Balazs Juergen Schoenwaelder wrote: > On Thu, Sep 11, 2008 at 09:28:04AM +0200, Balazs Lengyel wrote: > >>> So is the following valid then? >>> >>> typedef d { type int32 { range "0..3|5..7"; } } >>> typedef e { type d { range "3..6"; } } > >> IMO it is invalid. Any construct that adds even one single >> additional value to the value-space of a type is illegal (here the >> value 4). You should be able to be more restrictive but never to >> allow new values. > > I agree - but then the example is not adding something according to my > interpretation - I assumed the resulting value set is {3, 5, 6}. With > pattern, we can effectively do the same - a pattern of a sub-type must > be satisfied in addition to the pattern of the parent type. > > The question is whether the above is illegal and I would be forced to > write "3|5..6". And I note again that with pattern we do not have > constraints how they must be formed relative to each other when we > apply them. > > The point really is that the value space can't increase by subtyping. > But instead of saying that, we try to restrict the ranges syntax one > is allowed to use and since this is hard to do and not really useful > for pattern we don't do this for pattern. This is not very consistent. > > The other question is how we deal with restrictions that lead to an > empty value set, e.g.: > > typedef f { type string { pattern "a"; } } > typedef g { type f { pattern "b"; } } > typedef h { type f { length 2; } } > > [With real world pattern that are several lines long, things like this > might not always be obvious and easy to spot.] > > I think we need to spell out constraints in terms of the value set > rather than the syntactic means of the restrictions. And I don't think > we will succeed to mark all these things illegal by adding language > rules to YANG without causing damage to the language. So we have to > leave some of this to implementations to figure out what they can > catch as warnings. > > /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 Thu Sep 11 04:00: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 ECB303A69C8; Thu, 11 Sep 2008 04:00:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B223A6B6A for ; Thu, 11 Sep 2008 04:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.206, 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 kPPUF7kdX+xp for ; Thu, 11 Sep 2008 04:00:41 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C0A923A69C8 for ; Thu, 11 Sep 2008 04:00:41 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EF37376C250; Thu, 11 Sep 2008 13:00:04 +0200 (CEST) Date: Thu, 11 Sep 2008 13:00:45 +0200 (CEST) Message-Id: <20080911.130045.190527319.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080911075131.GA890@elstar.local> References: <20080911063505.GA736@elstar.local> <48C8C884.30405@ericsson.com> <20080911075131.GA890@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] range restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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: > The point really is that the value space can't increase by subtyping. > But instead of saying that, we try to restrict the ranges syntax one > is allowed to use and since this is hard to do and not really useful > for pattern we don't do this for pattern. This is not very consistent. I agree, it's not consistent. The text for range handling comes from SMIng, which didn't have patterns. From a reader's perspective I think it would be better if both ranges and patterns were restricted this way. But you're right that it is difficult to check. > The other question is how we deal with restrictions that lead to an > empty value set, e.g.: > > typedef f { type string { pattern "a"; } } > typedef g { type f { pattern "b"; } } > typedef h { type f { length 2; } } > > [With real world pattern that are several lines long, things like this > might not always be obvious and easy to spot.] > > I think we need to spell out constraints in terms of the value set > rather than the syntactic means of the restrictions. Yes, unfortunately. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 05:11: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 1020D3A689C; Thu, 11 Sep 2008 05:11:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360F33A6930 for ; Thu, 11 Sep 2008 05:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=0.612, 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 BViLb0Anqrjb for ; Thu, 11 Sep 2008 05:11:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3905F3A689C for ; Thu, 11 Sep 2008 05:11:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFBC0C00B4; Thu, 11 Sep 2008 14:10:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CRtLVU64DPom; Thu, 11 Sep 2008 14:10:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D908CC00A4; Thu, 11 Sep 2008 14:10:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C24B66C5F32; Thu, 11 Sep 2008 14:10:19 +0200 (CEST) Date: Thu, 11 Sep 2008 14:10:19 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080911121019.GC1810@elstar.local> Mail-Followup-To: Balazs Lengyel , Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> <48C8C884.30405@ericsson.com> <20080911075131.GA890@elstar.local> <48C8D782.2020301@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48C8D782.2020301@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Sep 11, 2008 at 10:32:02AM +0200, Balazs Lengyel wrote: > I agree that we should state "the value space can't increase by > subtyping" as a basic rule. However we must also explicitly state > whether this 3..6 will include 4 or not, (not trivial), so are all > constraints in the type chain to be considered or just the last one > which must be valid according to the basic rule. I think all restrictions on the type chain must be considered and be valid. This is what we assume for pattern. /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 Sep 11 07:10:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0DEB3A67CF; Thu, 11 Sep 2008 07:10:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1444D3A6BB7 for ; Thu, 11 Sep 2008 07:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 jMpfjpZx4nwf for ; Thu, 11 Sep 2008 07:10:06 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id DADEC3A67CF for ; Thu, 11 Sep 2008 07:10:05 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Thu, 11 Sep 2008 07:10:05 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 07:09:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 07:09:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 07:09:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8BE9rM12745; Thu, 11 Sep 2008 07:09:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8BE62la058439; Thu, 11 Sep 2008 14:06:03 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809111406.m8BE62la058439@idle.juniper.net> To: Andy Bierman In-reply-to: <48C80537.7050202@netconfcentral.com> Date: Thu, 11 Sep 2008 10:06:02 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Sep 2008 14:09:53.0727 (UTC) FILETIME=[10047CF0:01C91418] Cc: NETMOD Working Group Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.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: >Double quoted strings get processed, >like replacing escape-chars and trimming whitespace. >Single-quoted strings do not get touched. The intent was that double quoted string would be more useful, since are more flexible. You only need single quotes when you want to avoid the need to use escapes. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 07:13: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 827F13A6BB7; Thu, 11 Sep 2008 07:13:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDD33A6BD9 for ; Thu, 11 Sep 2008 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 jTDa-zLTj3kq for ; Thu, 11 Sep 2008 07:13:01 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id B9F003A6BC5 for ; Thu, 11 Sep 2008 07:12:57 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 11 Sep 2008 07:12:56 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 07:12:35 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 07:12:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 07:12:34 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8BECXM14496; Thu, 11 Sep 2008 07:12:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8BE8haC058470; Thu, 11 Sep 2008 14:08:43 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809111408.m8BE8haC058470@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080910225200.GA500@elstar.local> Date: Thu, 11 Sep 2008 10:08:42 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Sep 2008 14:12:34.0475 (UTC) FILETIME=[6FD4AFB0:01C91418] Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >Right now all of these definitions seem to be legal but they are also >pretty pointless. Shall we now add language for all these constructs >that are pointless to forbid them? I don't think so - it is way too >risky to screw this up. We can't stop people from going down paths that are broken or pointless, but we can certainly stop them when their very first step is pointless. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 07:25: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 1406C3A635F; Thu, 11 Sep 2008 07:25:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E507A3A6BA9 for ; Thu, 11 Sep 2008 07:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 UzjmN4xMKvn9 for ; Thu, 11 Sep 2008 07:25:32 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 1D5FC3A635F for ; Thu, 11 Sep 2008 07:25:26 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Thu, 11 Sep 2008 07:21:31 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 07:23:01 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 07:23:00 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 07:23:00 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8BEMxM19774; Thu, 11 Sep 2008 07:22:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8BEJ9G1058589; Thu, 11 Sep 2008 14:19:09 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809111419.m8BEJ9G1058589@idle.juniper.net> To: Andy Bierman Date: Thu, 11 Sep 2008 10:19:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Sep 2008 14:23:00.0170 (UTC) FILETIME=[E4C62AA0:01C91419] Cc: NETMOD Working Group Subject: Re: [netmod] YANG strings vs XPath strings X-BeenThere: netmod@ietf.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 Phil Shafer writes: >" is a UTF-8 character entity, so your parser should parse >this into '"'. Since the entire file is UTF-8, you can say voodoo >like: Okay, this is complete rubbish. Character entities are XML, not UTF-8. Sorry for the misinformation. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 11:11: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 278FB3A693C; Thu, 11 Sep 2008 11:11:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8531F3A6A40 for ; Thu, 11 Sep 2008 11:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.596, 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 TJTh+1VBfGrV for ; Thu, 11 Sep 2008 11:11:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F02E23A693C for ; Thu, 11 Sep 2008 11:11:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EED29C00AD; Thu, 11 Sep 2008 20:10:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Y8FHshIZAufV; Thu, 11 Sep 2008 20:10:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7FA9C00A9; Thu, 11 Sep 2008 20:10:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF7086C62B8; Thu, 11 Sep 2008 20:10:39 +0200 (CEST) Date: Thu, 11 Sep 2008 20:10:39 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080911181039.GA2473@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , netmod@ietf.org References: <20080910225200.GA500@elstar.local> <200809111408.m8BE8haC058470@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200809111408.m8BE8haC058470@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Sep 11, 2008 at 10:08:42AM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Right now all of these definitions seem to be legal but they are also > >pretty pointless. Shall we now add language for all these constructs > >that are pointless to forbid them? I don't think so - it is way too > >risky to screw this up. > > We can't stop people from going down paths that are broken or > pointless, but we can certainly stop them when their very first > step is pointless. But you make assumptions that they are _always_ pointless and this is where the risk it. Let me try to make a hypothetical argument: Suppose someone needs to translate to/from some proprietary language which always requires that keys have three components. In cases where the key is a simple value, you would love to use type empty leafs to fill the other two required elements but you can't; you have to hack away with something that is an empty string. Perhaps this isn't a very convincing example. But the risk that special rules invented with the best intentions can back fire is there. /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 Sep 11 11:43: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 CCFA23A67B4; Thu, 11 Sep 2008 11:43:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09C83A6ACA for ; Thu, 11 Sep 2008 11:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 F7dYP2yGOYe0 for ; Thu, 11 Sep 2008 11:43:28 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 7CAFA3A68EB for ; Thu, 11 Sep 2008 11:43:26 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 11 Sep 2008 11:43:21 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 11:42:56 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 11:42:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 11:42:55 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8BIgtM60570; Thu, 11 Sep 2008 11:42:55 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8BId4Rl061259; Thu, 11 Sep 2008 18:39:04 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809111839.m8BId4Rl061259@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080911181039.GA2473@elstar.local> Date: Thu, 11 Sep 2008 14:39:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Sep 2008 18:42:55.0503 (UTC) FILETIME=[345121F0:01C9143E] Cc: netmod@ietf.org Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >Perhaps this isn't a very convincing example. But the risk that >special rules invented with the best intentions can back fire is >there. Sure. I'm just all for helping the user (the modeler) do the right thing the first time. It will help their experience with YANG and help the quality of YANG models. Yes, compilers can give warnings for errors like this, but warnings are largely ignored until someone decides to turn on -Werror. I'd like to have -Werror set from the start. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 11 11:56: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 0AF463A69CC; Thu, 11 Sep 2008 11:56:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46EEC3A69CC for ; Thu, 11 Sep 2008 11:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.311, 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 T02SO0XXpFZt for ; Thu, 11 Sep 2008 11:56:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 683803A69DC for ; Thu, 11 Sep 2008 11:56:44 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 599F7D800CC for ; Thu, 11 Sep 2008 20:56:41 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <200809111839.m8BId4Rl061259@idle.juniper.net> References: <200809111839.m8BId4Rl061259@idle.juniper.net> Organization: CESNET Date: Thu, 11 Sep 2008 20:56:42 +0200 Message-Id: <1221159402.6242.74.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDExLiAwOS4gMjAwOCB2IDE0OjM5IC0wNDAwOgo+IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciB3cml0ZXM6Cj4gPlBlcmhhcHMgdGhpcyBpc24ndCBhIHZlcnkg Y29udmluY2luZyBleGFtcGxlLiBCdXQgdGhlIHJpc2sgdGhhdAo+ID5zcGVjaWFsIHJ1bGVzIGlu dmVudGVkIHdpdGggdGhlIGJlc3QgaW50ZW50aW9ucyBjYW4gYmFjayBmaXJlIGlzCj4gPnRoZXJl Lgo+IAo+IFN1cmUuIEknbSBqdXN0IGFsbCBmb3IgaGVscGluZyB0aGUgdXNlciAodGhlIG1vZGVs ZXIpIGRvIHRoZSByaWdodAo+IHRoaW5nIHRoZSBmaXJzdCB0aW1lLiAgSXQgd2lsbCBoZWxwIHRo ZWlyIGV4cGVyaWVuY2Ugd2l0aCBZQU5HIGFuZAoKSSBjYW5ub3QgaW1hZ2luZSBob3cgYSBwb29y IHVzZXIgY291bGQgZXZlciBjb21lIHVwIHdpdGggdGhlIGlkZWEgb2YKdXNpbmcgZW1wdHkgdHlw ZSBmb3IgYSBrZXkgbGVhZi4gV2h5IGNvdWxkIGhlIGFzc3VtZSB0aGF0IGl0IGNvdWxkIGJlCnVz ZWZ1bCBpbiBhbnkgd2F5PyBJdCBjYW4gYmUgb25seSBiZWNhdXNlIGl0J3MgZm9yYmlkZGVuIGlu IHRoZSBkcmFmdAp0aGF0IGhlIG1pZ2h0IGJlIHRlbXB0ZWQgdG8gdGVzdCBpdC4gT3RoZXJ3aXNl LCB0aGUgZW1wdHkga2V5IGNhbiBJTU8Kb25seSBhcHBlYXIgaW4gdGVzdCBzdWl0ZXMgYW5kIHVy YmFuIGxlZ2VuZHMuCgpPciwgbWF5YmUsIHRoZXJlIGFjdHVhbGx5IGlzIGEgcmVhc29uYWJsZSBj YXNlIHRoYXQgd2UgZmFpbCB0byBzZWUgbm93LAphcyBKdWVyZ2VuIHBvaW50cyBvdXQuCgpMYWRh Cgo+IGhlbHAgdGhlIHF1YWxpdHkgb2YgWUFORyBtb2RlbHMuICBZZXMsIGNvbXBpbGVycyBjYW4g Z2l2ZSB3YXJuaW5ncwo+IGZvciBlcnJvcnMgbGlrZSB0aGlzLCBidXQgd2FybmluZ3MgYXJlIGxh cmdlbHkgaWdub3JlZCB1bnRpbCBzb21lb25lCj4gZGVjaWRlcyB0byB0dXJuIG9uIC1XZXJyb3Iu ICBJJ2QgbGlrZSB0byBoYXZlIC1XZXJyb3Igc2V0IGZyb20gdGhlCj4gc3RhcnQuCj4gCj4gVGhh bmtzLAo+ICBQaGlsCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwg Q0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Sep 11 12:46: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 97D613A699F; Thu, 11 Sep 2008 12:46:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EF33A6A2E for ; Thu, 11 Sep 2008 12:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.024 X-Spam-Level: X-Spam-Status: No, score=-0.024 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_20=-0.74, 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 AJXTsSYhQjrT for ; Thu, 11 Sep 2008 12:46:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E00FF3A6A2B for ; Thu, 11 Sep 2008 12:46:32 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A27E3D800C8 for ; Thu, 11 Sep 2008 21:46:28 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <200809111906.m8BJ6u8P061670@idle.juniper.net> References: <200809111906.m8BJ6u8P061670@idle.juniper.net> Organization: CESNET Date: Thu, 11 Sep 2008 21:46:30 +0200 Message-Id: <1221162390.6242.123.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDExLiAwOS4gMjAwOCB2IDE1OjA2IC0wNDAwOgo+IExh ZGlzbGF2IExob3RrYSB3cml0ZXM6Cj4gPkkgY2Fubm90IGltYWdpbmUgaG93IGEgcG9vciB1c2Vy IGNvdWxkIGV2ZXIgY29tZSB1cCB3aXRoIHRoZSBpZGVhIG9mCj4gPnVzaW5nIGVtcHR5IHR5cGUg Zm9yIGEga2V5IGxlYWYuIFdoeSBjb3VsZCBoZSBhc3N1bWUgdGhhdCBpdCBjb3VsZCBiZQo+ID51 c2VmdWwgaW4gYW55IHdheT8gSXQgY2FuIGJlIG9ubHkgYmVjYXVzZSBpdCdzIGZvcmJpZGRlbiBp biB0aGUgZHJhZnQKPiA+dGhhdCBoZSBtaWdodCBiZSB0ZW1wdGVkIHRvIHRlc3QgaXQuIE90aGVy d2lzZSwgdGhlIGVtcHR5IGtleSBjYW4gSU1PCj4gPm9ubHkgYXBwZWFyIGluIHRlc3Qgc3VpdGVz IGFuZCB1cmJhbiBsZWdlbmRzLgo+IAo+IElmIGl0IG9ubHkgYXBwZWFycyBpbiB0ZXN0IHN1aXRl cyBhbmQgdXJiYW4gbGVnZW5kcywgd2h5IG5vdCBmb3JiaWQKPiBpdD8gIElmIG5vIG9uZSBjb3Vs ZCBhc3N1bWUgaXQgdG8gYmUgdXNlZnVsLCB3aHkgaGF2ZSBpdD8gIElmIGl0J3MKPiBub3QgaW1w b3J0YW50LCB3aHkgYnVybiB0aW1lIG9uIGl0PwoKSU1PIHRoZSBzaXR1YXRpb24gaXMgZXhhY3Rs eSByZXZlcnNlOiBXaHkgYnVybiB0aW1lIG9uIHNwZWNpZnlpbmcgKGFuZApleHBsYWluaW5nKSBl eGNlcHRpb25zIHRoYXQgYXJlIG5vdCBuZWVkZWQgYW5kIGp1c3QgYWltZWQgYXQgaGVscGluZyB0 aGUKbW9kZWxsZXIgdG8gYXZvaWQgc29tZXRoaW5nIHRoYXQgaGUgd291bGQgbmV2ZXIgaW50ZW5k IHRvIGRvIGluIHRoZQpmaXJzdCBwbGFjZS4gQW5kIGlmIGhlIGRvZXMsIGl0IGlzIGNvbXBsZXRl bHkgYmVuaWduIC0gdGhlIGRhdGEgbW9kZWwKd2lsbCBqdXN0IGFsbG93IG5vIG1vcmUgdGhhbiBv bmUgbGlzdCBpdGVtLCBhcyB0aGUgbW9kZWxsZXIgbXVzdCBoYXZlCmV4cGVjdGVkLgoKTGFkYQog Cj4gCj4gVGhhbmtzLAo+ICBQaGlsCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5 IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Sep 11 13:20: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 17FCF28C143; Thu, 11 Sep 2008 13:20:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B1128C143 for ; Thu, 11 Sep 2008 13:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SILhzTRoCejF for ; Thu, 11 Sep 2008 13:20:32 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 72A5028C2CE for ; Thu, 11 Sep 2008 13:19:40 -0700 (PDT) Received: (qmail 50310 invoked from network); 11 Sep 2008 20:19:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 11 Sep 2008 20:19:45 -0000 X-YMail-OSG: WIlWg8EVM1mQQTUCsQwugmItDz0mAW_a5mPhwi5Fn_oJSXmokRtn0Yjo4KnnQX0KlA0asv6A0cwxw9YVt2LMvh6hHBn1ghfpvtIKMbcZQA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C97D60.3050600@netconfcentral.com> Date: Thu, 11 Sep 2008 13:19:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200809111906.m8BJ6u8P061670@idle.juniper.net> <1221162390.6242.123.camel@missotis> In-Reply-To: <1221162390.6242.123.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] empty leaf as key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IMSMdCAxMS4gMDku IDIwMDggdiAxNTowNiAtMDQwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyaXRlczoKPj4+IEkgY2Fu bm90IGltYWdpbmUgaG93IGEgcG9vciB1c2VyIGNvdWxkIGV2ZXIgY29tZSB1cCB3aXRoIHRoZSBp ZGVhIG9mCj4+PiB1c2luZyBlbXB0eSB0eXBlIGZvciBhIGtleSBsZWFmLiBXaHkgY291bGQgaGUg YXNzdW1lIHRoYXQgaXQgY291bGQgYmUKPj4+IHVzZWZ1bCBpbiBhbnkgd2F5PyBJdCBjYW4gYmUg b25seSBiZWNhdXNlIGl0J3MgZm9yYmlkZGVuIGluIHRoZSBkcmFmdAo+Pj4gdGhhdCBoZSBtaWdo dCBiZSB0ZW1wdGVkIHRvIHRlc3QgaXQuIE90aGVyd2lzZSwgdGhlIGVtcHR5IGtleSBjYW4gSU1P Cj4+PiBvbmx5IGFwcGVhciBpbiB0ZXN0IHN1aXRlcyBhbmQgdXJiYW4gbGVnZW5kcy4KPj4gSWYg aXQgb25seSBhcHBlYXJzIGluIHRlc3Qgc3VpdGVzIGFuZCB1cmJhbiBsZWdlbmRzLCB3aHkgbm90 IGZvcmJpZAo+PiBpdD8gIElmIG5vIG9uZSBjb3VsZCBhc3N1bWUgaXQgdG8gYmUgdXNlZnVsLCB3 aHkgaGF2ZSBpdD8gIElmIGl0J3MKPj4gbm90IGltcG9ydGFudCwgd2h5IGJ1cm4gdGltZSBvbiBp dD8KPiAKPiBJTU8gdGhlIHNpdHVhdGlvbiBpcyBleGFjdGx5IHJldmVyc2U6IFdoeSBidXJuIHRp bWUgb24gc3BlY2lmeWluZyAoYW5kCj4gZXhwbGFpbmluZykgZXhjZXB0aW9ucyB0aGF0IGFyZSBu b3QgbmVlZGVkIGFuZCBqdXN0IGFpbWVkIGF0IGhlbHBpbmcgdGhlCj4gbW9kZWxsZXIgdG8gYXZv aWQgc29tZXRoaW5nIHRoYXQgaGUgd291bGQgbmV2ZXIgaW50ZW5kIHRvIGRvIGluIHRoZQo+IGZp cnN0IHBsYWNlLiBBbmQgaWYgaGUgZG9lcywgaXQgaXMgY29tcGxldGVseSBiZW5pZ24gLSB0aGUg ZGF0YSBtb2RlbAo+IHdpbGwganVzdCBhbGxvdyBubyBtb3JlIHRoYW4gb25lIGxpc3QgaXRlbSwg YXMgdGhlIG1vZGVsbGVyIG11c3QgaGF2ZQo+IGV4cGVjdGVkLgo+IAoKSXQgZG9lc24ndCB3b3Jr IHRoYXQgd2F5IGluIGEgc3RhbmRhcmQuCklmIHRoZSBzdGFuZGFyZCBzYXlzIGFsbCB0eXBlcyBh cmUgdmFsaWQgYXMga2V5cywKdGhlbiBhbGwgaW1wbGVtZW50YXRpb25zIHdpbGwgYmUgZXhwZWN0 ZWQgdG8gc3VwcG9ydAphbGwgdHlwZXMgYXMga2V5cy4KCkFuIGVtcHR5IG9yIGtleXJlZiBpcyBu b3QgYWxsb3dlZCBpbiBhIHVuaW9uLCBmb3IgdmFyaW91cyByZWFzb25zLgpBIGtleSBtdXN0IGJl IHByZXNlbnQgb24gY29uZmlnIGxpc3QsIGJ1dCBpcyBvcHRpb25hbCBvbgphIG5vbi1jb25maWcg bGlzdC4gS2V5IGxlYWZzIGFyZSBlbmNvZGVkIGZpcnN0IGluIFhNTCwKcmVnYXJkbGVzcyBvZiB0 aGVpciBwb3NpdGlvbiBpbiB0aGUgWUFORyBsaXN0IGRlZmluaXRpb24uCgpZQU5HIGhhcyBhbGwg a2luZHMgb2YgcnVsZXMgaW50ZW5kZWQgdG8gc2ltcGxpZnkgaW1wbGVtZW50YXRpb25zCmFuZCBt YXhpbWl6ZSB1c2VyIGZlYXR1cmVzLgoKSU1PIHdlIGFyZSBtb3ZpbmcgaW4gdGhlIHdyb25nIGRp cmVjdGlvbiB3aGVuIHdlIHN0YXJ0Cm1heGltaXppbmcgaW1wbGVtZW50YXRpb24gY29tcGxleGl0 eSB3aXRoIG5vIGluY3JlYXNlCmluIHVzZXIgZmVhdHVyZXMuICBJdCBpcyBub3QgYSBidXJkZW4g b24gaW1wbGVtZW50ZXJzCnRvIHJlYWQgdGhlIGRldGFpbHMuICBJdCBpcyBub3QgYSBidXJkZW4g b24gbW9kZWxlcnMKdG8gdXNlICd0eXBlIHN0cmluZzsnIGluc3RlYWQgb2YgJ3R5cGUgZW1wdHk7 JyBmb3Iga2V5CnBsYWNlaG9sZGVycyAod2hhdGV2ZXIgZmVhdHVyZSB0aGF0IGlzKS4KCgo+IExh ZGEKPiAgCj4+IFRoYW5rcywKPj4gIFBoaWwKCkFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri Sep 12 10:20: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 9F92328C101; Fri, 12 Sep 2008 10:20:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F7628C151 for ; Fri, 12 Sep 2008 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.523, 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 8XKxt9YxWD4V for ; Fri, 12 Sep 2008 10:20:02 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 2EFB628C0F5 for ; Fri, 12 Sep 2008 10:20:02 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Dq4s1a00S0Fqzac53tKhvT; Fri, 12 Sep 2008 17:19:41 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id DtKf1a0174HwxpC3UtKgZw; Fri, 12 Sep 2008 17:19:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=vvoU6SaGYS5h0m2rz7sA:9 a=mfNSYk8RpEsvF9zMxK0A:7 a=a2_n85NUSBD1VlZpnTIkV2_ebdUA:4 a=lZB815dzVvQA:10 a=chC_agHSu74A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , Date: Fri, 12 Sep 2008 13:19:39 -0400 Message-ID: <02f401c914fb$bdbfcbe0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckU+UOUEPgryPeoRYOD5uHir7pLkQAAnJ4A Subject: [netmod] FW: Nomcom call for candidates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Friday, September 12, 2008 12:48 PM To: Working Group Chairs Subject: Nomcom call for candidates The message below was just sent to the IETF-Annoucne list. However, it order to get to as many people as possible, I am asking WG chairs a favor. Please forward the message to your working groups. Thank you, Joel M. Halpern The 2008-9 IETF Nominating Committee needs your help. We have started getting candidates. If we are going to do our job in time, we have only 3 more weeks to get enough candidates to have a reasonable pool for all the jobs. At the moment, we do not have a reasonable pool for any jobs. If you are willing to serve, please nominate yourself. If there is someone you think would do a good job, please nominate them. The web site at: http://wiki.tools.ietf.org/group/nomcom/08 Has the list of positions we are seeking people for, as well as tools for providing both nominations and feedback. Alternatively, you can submit nominations by sending email to me. Please help us. Thank you, Joel M. Halpern jmh@joelhalpern.com nomcom-chair@ietf.org _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 12 17:25:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612AB3A691D; Fri, 12 Sep 2008 17:25:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1AC3A69B7 for ; Fri, 12 Sep 2008 17:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-0.625, 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 MM1Ks1wicoSv for ; Fri, 12 Sep 2008 17:25:57 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id AC0F33A691D for ; Fri, 12 Sep 2008 17:25:57 -0700 (PDT) Received: (qmail 49120 invoked from network); 13 Sep 2008 00:26:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 13 Sep 2008 00:26:03 -0000 X-YMail-OSG: LP.LQNMVM1kiHZ3sM0CsGc2VzB.2aNeoqN83OF1zQyQkKjpOg6lIi6AItKQz4sSfraL1Oti4rmEfr3xJNwmxxqROVV.NTpwjcphK9wM2pw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48CB0899.7090606@netconfcentral.com> Date: Fri, 12 Sep 2008 17:26:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel , Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <200809101218.m8ACIkh4038663@idle.juniper.net> <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> <48C8C884.30405@ericsson.com> <20080911075131.GA890@elstar.local> In-Reply-To: <20080911075131.GA890@elstar.local> Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 Thu, Sep 11, 2008 at 09:28:04AM +0200, Balazs Lengyel wrote: > >>> So is the following valid then? >>> >>> typedef d { type int32 { range "0..3|5..7"; } } >>> typedef e { type d { range "3..6"; } } > The agreement reached in the YANG design team was that the new range cannot add values, just restrict values, so 'e' is invalid because it adds '4' to the range. Unlike patterns which are ANDed together, only the 'closest' range to the leaf definition is used. The user has to type 'range "3 | 5..6"' for this definition to be valid. >> IMO it is invalid. Any construct that adds even one single >> additional value to the value-space of a type is illegal (here the >> value 4). You should be able to be more restrictive but never to >> allow new values. > > I agree - but then the example is not adding something according to my > interpretation - I assumed the resulting value set is {3, 5, 6}. With > pattern, we can effectively do the same - a pattern of a sub-type must > be satisfied in addition to the pattern of the parent type. It could be interpreted differently for a range because it is a true restriction, not 1 term in an AND expression. All the numbers in the new range must be valid within its parent range (if any). IMO this is easy to implement, and easy to understand. > >... > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 12 21:12:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF503A683C; Fri, 12 Sep 2008 21:12:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4C23A687A for ; Fri, 12 Sep 2008 21:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y22WrhKPZDV9 for ; Fri, 12 Sep 2008 21:12:57 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 5C7123A683C for ; Fri, 12 Sep 2008 21:12:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Sqk2k9ebVJieKuGwBZ1DZ2gXgJbTgWkHJhth74QfUb9GFe/3A5GyEP2FHk4P/WOA; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.144.221] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KeMVJ-0003Hq-7P for netmod@ietf.org; Sat, 13 Sep 2008 00:13:01 -0400 Message-ID: <002801c91557$50dd7ac0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48B7AF8F.3000201@netconfcentral.com> <20080829.103223.156479567.mbj@tail-f.com> <48B7F26D.7080805@netconfcentral.com><20080903.100608.11667281.mbj@tail-f.com> <48BE85D4.6030105@netconfcentral.com> Date: Fri, 12 Sep 2008 21:15:10 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e405b5d8c6aa85380cd4897f9ef1f0f45e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.221 Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Martin Bjorklund" > Cc: > Sent: Wednesday, September 03, 2008 5:40 AM > Subject: Re: [netmod] data-not-unique not secure > > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> You don't need to send any data to have a security problem. > >> > >> If I have access to 1 list entry (that uses the unique-stmt), > >> then I can simply use a trial-and-error brute force attack, > >> and keep setting the leaf I want to uncover to different > >> values. As soon as I get back a data-not-unique error, > >> I know one of the entries has that value. Further attacks > >> may or may not be possible from that point. > > > > This logic can be applied to other constraints as well. For example, > > if there's a constraint that a > b, and the user has access to b, but > > not a, he can try to set b to different values and note when validate > > fails to figure out the value of a. > > > > So is the conclusion that no data models should contain constraints? > > I hope not. > > of course not > > > > > Is the conclusion that when validation fails, we should not try to > > help the operator by giving precise error messages? I hope not. > > > > Or is the conclusion that implementations should apply access control > > to the errors? This might be tricky. > > > > yes, but it needs to be considered eventually. > > I agree that punting access control completely provides some > cover for now (not that I agreed with punting the ACM ;-). > So it may be good enough for YANG to say "do not leak any > unauthorized data via XPath expressions, such as the > predicates defining key/value pairs". ... IF constraints, including those involving multiple configuration parameters, are machine-readable, then an access control model can defend against these attacks by stipulating that the client needs at least "read" access for the information needed to compute the constraints as well as to evaluate whatever XPath expressions were used to find it. This nicely side-steps the problem of applying access control to errors, and keeps the sensitive information under wraps. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 12 23:56: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 910B33A68DD; Fri, 12 Sep 2008 23:56:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4403A696F for ; Fri, 12 Sep 2008 23:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.561, 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 MWFgT+5t35ba for ; Fri, 12 Sep 2008 23:56:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 22FD13A68DD for ; Fri, 12 Sep 2008 23:56:51 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 104B1C002B; Sat, 13 Sep 2008 08:56:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v5anPgZC4apQ; Sat, 13 Sep 2008 08:56:53 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B576BC0003; Sat, 13 Sep 2008 08:56:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D76DF6C7D06; Sat, 13 Sep 2008 08:56:51 +0200 (CEST) Date: Sat, 13 Sep 2008 08:56:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080913065651.GA6438@elstar.local> Mail-Followup-To: Andy Bierman , Balazs Lengyel , Ladislav Lhotka , netmod@ietf.org References: <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> <48C8C884.30405@ericsson.com> <20080911075131.GA890@elstar.local> <48CB0899.7090606@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48CB0899.7090606@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Sep 12, 2008 at 05:26:01PM -0700, Andy Bierman wrote: > It could be interpreted differently for a range because > it is a true restriction, not 1 term in an AND expression. > All the numbers in the new range must be valid within > its parent range (if any). IMO this is easy to implement, > and easy to understand. So you think it is a design feature to treat range restrictions different than other type restrictions, e.g. combinations of length and pattern or pattern and pattern restrictions? /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 Sat Sep 13 02:06: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 594D43A67E9; Sat, 13 Sep 2008 02:06:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0D93A6A53 for ; Sat, 13 Sep 2008 02:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpVbT5dqMKnQ for ; Sat, 13 Sep 2008 02:06:04 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 627033A67E9 for ; Sat, 13 Sep 2008 02:06:04 -0700 (PDT) Received: (qmail 16383 invoked from network); 13 Sep 2008 09:06:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 13 Sep 2008 09:06:10 -0000 X-YMail-OSG: wO92i3YVM1kJ0kAzjsIKd0OoYCqIqJQpt8UWDBpPREqbPRxkYzNZH8KYWa83Ler0l_d7GX6YVc0WG6OeIn.JbI.3.nfIZ7XjgYLETdflNA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48CB8280.5010805@netconfcentral.com> Date: Sat, 13 Sep 2008 02:06:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Balazs Lengyel , Ladislav Lhotka , netmod@ietf.org References: <1221054119.9589.95.camel@missotis> <20080910141913.GA23369@elstar.local> <1221057327.9589.105.camel@missotis> <48C7E35F.2000005@netconfcentral.com> <20080910225200.GA500@elstar.local> <48C87187.3060503@netconfcentral.com> <20080911063505.GA736@elstar.local> <48C8C884.30405@ericsson.com> <20080911075131.GA890@elstar.local> <48CB0899.7090606@netconfcentral.com> <20080913065651.GA6438@elstar.local> In-Reply-To: <20080913065651.GA6438@elstar.local> Subject: Re: [netmod] range restrictions (was empty leaf as key) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Sep 12, 2008 at 05:26:01PM -0700, Andy Bierman wrote: > >> It could be interpreted differently for a range because >> it is a true restriction, not 1 term in an AND expression. >> All the numbers in the new range must be valid within >> its parent range (if any). IMO this is easy to implement, >> and easy to understand. > > So you think it is a design feature to treat range restrictions > different than other type restrictions, e.g. combinations of length > and pattern or pattern and pattern restrictions? > There are lots of properties that are determined in lots of ways, like default and mandatory and config and min-elements, etc. The AND expression for patterns is the exception, not the rule. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 15 00:41: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 5B42F3A679F; Mon, 15 Sep 2008 00:41:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DAC3A6A20 for ; Mon, 15 Sep 2008 00:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9JuHpx4gBH2 for ; Mon, 15 Sep 2008 00:41:05 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A84013A679F for ; Mon, 15 Sep 2008 00:41:05 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CCB6076C4DF; Mon, 15 Sep 2008 09:41:14 +0200 (CEST) Date: Mon, 15 Sep 2008 09:42:21 +0200 (CEST) Message-Id: <20080915.094221.244090784.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48CB0899.7090606@netconfcentral.com> References: <48C8C884.30405@ericsson.com> <20080911075131.GA890@elstar.local> <48CB0899.7090606@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] range restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Thu, Sep 11, 2008 at 09:28:04AM +0200, Balazs Lengyel wrote: > > > >>> So is the following valid then? > >>> > >>> typedef d { type int32 { range "0..3|5..7"; } } > >>> typedef e { type d { range "3..6"; } } > > > > The agreement reached in the YANG design team was that > the new range cannot add values, just restrict values, I don't think this principle is questioned in this thread. > so 'e' is invalid because it adds '4' to the range. Since 'd' defines the value space { 0 1 2 3 5 6 7 }, 'e' above restricts this to the subset { 3 5 6 } Compare with typedef ds { type string { pattern "[0-3]|[5-7]"; } } typedef es { type ds { pattern "[3-6]"; } } which is legal YANG. Why should range and pattern behave differently? This is just confusing to the user. (when do I have to repeat the restrictions?) I like the current way of handling ranges, since it is very explicit. The user just has to read one range expression to understand the type. With patterns, the user has to follow the type chain. It would be nicest if we could use the same rule for patterns, but since this is very difficult (impossible?) for tools to check, we can't do that. But I prefer to have consistent rules. The user should know what to expect from a type derivation. So I think we should change the rules for range to match the rules for pattern. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 15 07:35:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBC73A699A; Mon, 15 Sep 2008 07:35:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70163A6B4B for ; Mon, 15 Sep 2008 07:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 5SJ0xeD3-m4k for ; Mon, 15 Sep 2008 07:35:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6BF173A699A for ; Mon, 15 Sep 2008 07:35:57 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8FEa6EO030159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 16:36:06 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8FEa3wU005584; Mon, 15 Sep 2008 16:36:06 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Sep 2008 16:36:01 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Sep 2008 16:35:59 +0200 Message-ID: In-Reply-To: <48C69053.2030609@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] architecture document scope Thread-Index: AckSjUlmkfJSYNojReibYf54c2x0TgCgeBtA References: <20080909071246.GA20440@elstar.local> <48C69053.2030609@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , X-OriginalArrivalTime: 15 Sep 2008 14:36:01.0427 (UTC) FILETIME=[60178630:01C91740] Subject: Re: [netmod] architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > Hi, > > > > I think we need to agree what the purpose and scope of the > > architecture document is. The NETMOD charter says: > > > > 1. An architecture document explaining the relationship > > between YANG and its inputs and outputs. (informational) > > > > This is rather fuzzy. While the input is clear (data models > written in > > YANG), the output is less clear since at the end of the day we want > > YANG models to be implemented in NETCONF servers as the output. How > > you get there is tool dependent. > > > > For me, it would make more sense to have an architecture document > > describing the big picture behind NETCONF plus YANG. Since YANG is a > > domain specific language for NETCONF, I would even argue that a YANG > > architecture has to reference NETCONF architectural concepts and since > > we do not have a NETCONF architecture, we need to address this anyhow. > > > > What is the WGs opinion? This is true. We should show in the draft that the two architectures are related to each other and give at basic information on the NETCONF architecture. Currently chapter 2.1 NETCONF gives only two arguments for XML usage. > > > > I agree with your assessment. > > > > /js > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 15 14:08:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DB63A6B13; Mon, 15 Sep 2008 14:08:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140C03A6C09 for ; Mon, 15 Sep 2008 14:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 SeTctyD1Stcw for ; Mon, 15 Sep 2008 14:08:17 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 11A663A6B13 for ; Mon, 15 Sep 2008 14:08:16 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id F8s91a03Z0vyq2s5898U9G; Mon, 15 Sep 2008 21:08:28 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id F98S1a00d4HwxpC3R98SXH; Mon, 15 Sep 2008 21:08:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=Rv5Dx_vpcR4A:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=Y_3fb-FGDGEmz9VfpcoA:9 a=xMTIeNWyG4bVEza-V1oA:7 a=Zh29HtUw_Mw8XC3IJi6Qi0Xj0IQA:4 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=uZQnKKD9fRsA:10 From: "David B Harrington" To: Date: Mon, 15 Sep 2008 17:08:26 -0400 Message-ID: <041001c91777$329459e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckSS36sKZriJbcbQc60eI5+NXY44AAFz+QQABVi7RABJlpt4A== Subject: [netmod] FW: architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 [speaking as co-chair] The IETF debated the charter and the purpose of the WG, and agreed to a charter that called for an architecture that describes the inputs and outputs of YANG. The architecture document should not make any claims that YANG is **THE** language for Netconf. That is not what the IETF agreed to when this WG was chartered, and it was obvious that IETF consensus was that some people wanted to use the existing XML-based tools to do their modeling. As co-chair, I am trying to make sure we keep the architecture document limited to the scope we are authorized to address by the charter. [speaking as individual contributor] I do not believe this document should be a "Netconf architecture" document - that should be the responsibility of the Netconf WG. Many of the items in Andy's list of things to include should not be included here, since they are about netconf, not netmod. I certainly have no objection to explaining that YANG is designed to work within a Netconf architecture. But it should NOT be our job to define what a Netconf architecture is. Since Netconf WG has not published an architecture document, this makes our job harder, but I think it is pretty simple to say that Netconf can carry any valid XML, and that YANG defines a schema language for specifying an XML format that can be used as Netconf content. The important part is that YANG is designed to be a user-friendly schema langauge, and then to describe the purpose of the other documents we will produce from YANG. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, September 09, 2008 6:11 AM > To: j.schoenwaelder@jacobs-university.de; netmod@ietf.org > Subject: Re: [netmod] architecture document scope > > Juergen, > > I would not spend too much time looking strictly at the words in the > charter - especially when we deal with architecture. > > I do understand - I think - what we had in mind when we put the YANG > architecture document in the charter, and this was related to > clarification of specific issues that were discussed during the > formation of the WG about how the flow of models in different > languages > will work and what is in-between. I agree with your observation that > part of the output is tools dependent - but this is part of the > clarification. > > What would a 'big picture' architecture for NETCONF include in your > opinion? What NETCONF architectural concepts are missing to > provide for > the NETMOD architecture? > > I do not hide that I am somehow concerned that when we would > get to the > NETCONF architecture we would need to refer a broader > architecture view > of the IETF management architecture. From boiling a cup of > tea we got to > boiling a lake and we then get close to boiling the ocean. > > Dan > > (speaking as a contributor) > > > > > -----Original Message----- > > From: netmod-bounces@ietf.org > > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, September 09, 2008 10:13 AM > > To: netmod@ietf.org > > Subject: [netmod] architecture document scope > > > > Hi, > > > > I think we need to agree what the purpose and scope of the > > architecture document is. The NETMOD charter says: > > > > 1. An architecture document explaining the relationship > > between YANG and its inputs and outputs. (informational) > > > > This is rather fuzzy. While the input is clear (data models > > written in YANG), the output is less clear since at the end > > of the day we want YANG models to be implemented in NETCONF > > servers as the output. How you get there is tool dependent. > > > > For me, it would make more sense to have an architecture > > document describing the big picture behind NETCONF plus YANG. > > Since YANG is a domain specific language for NETCONF, I would > > even argue that a YANG architecture has to reference NETCONF > > architectural concepts and since we do not have a NETCONF > > architecture, we need to address this anyhow. > > > > What is the WGs opinion? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 15 16:22:52 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322383A6872; Mon, 15 Sep 2008 16:22:52 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703BD3A6881 for ; Mon, 15 Sep 2008 16:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=0.703, 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 ZiXvH91TOxLL for ; Mon, 15 Sep 2008 16:22:49 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 2C5CA3A6872 for ; Mon, 15 Sep 2008 16:22:48 -0700 (PDT) Received: (qmail 16770 invoked from network); 15 Sep 2008 23:23:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 15 Sep 2008 23:22:58 -0000 X-YMail-OSG: nbaSFq8VM1mFFJHcB69BNV.koEQcXEINtc8TmofyTp3702AHoMb_PHt2GhBfs3QullsJD7OYQ7y2JAlTu26P3KJxv23PKfUpCTveAT3vamJMHRYZQYdy3ozgwwK.XKg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48CEEE50.4070308@netconfcentral.com> Date: Mon, 15 Sep 2008 16:22:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David B Harrington References: <041001c91777$329459e0$0600a8c0@china.huawei.com> In-Reply-To: <041001c91777$329459e0$0600a8c0@china.huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] FW: architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 B Harrington wrote: > [speaking as co-chair] > > The IETF debated the charter and the purpose of the WG, and agreed to > a charter that called for an architecture that describes the inputs > and outputs of YANG. The architecture document should not make any > claims that YANG is **THE** language for Netconf. That is not what the > IETF agreed to when this WG was chartered, and it was obvious that > IETF consensus was that some people wanted to use the existing > XML-based tools to do their modeling. > > As co-chair, I am trying to make sure we keep the architecture > document limited to the scope we are authorized to address by the > charter. > The phrase "inputs and outputs of YANG" is fairly vague. There are all kinds of NETCONF-isms throughout the YANG document. This is fine with me, since I plan to use YANG to define NETCONF protocol content. It's not clear to me what else YANG should be used for, but I would like to make sure it is useful for that protocol. The YANG input is a sequence of UTF-8 characters, probably typed into a file by a human. The output are supposedly DSDL files. This sounds great, wrt/ the IETF view of the problem space, but it doesn't seem to address the real problem space. Andy > [speaking as individual contributor] > > I do not believe this document should be a "Netconf architecture" > document - that should be the responsibility of the Netconf WG. Many > of the items in Andy's list of things to include should not be > included here, since they are about netconf, not netmod. > > I certainly have no objection to explaining that YANG is > designed to work within a Netconf architecture. But it should NOT be > our job to define what a Netconf architecture is. Since Netconf WG has > not published an architecture document, this makes our job harder, but > I think it is pretty simple to say that Netconf can carry any valid > XML, and that YANG defines a schema language for specifying an XML > format that can be used as Netconf content. The important part is that > YANG is designed to be a user-friendly schema langauge, and then to > describe the purpose of the other documents we will produce from YANG. > > dbh > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) >> Sent: Tuesday, September 09, 2008 6:11 AM >> To: j.schoenwaelder@jacobs-university.de; netmod@ietf.org >> Subject: Re: [netmod] architecture document scope >> >> Juergen, >> >> I would not spend too much time looking strictly at the words in the >> charter - especially when we deal with architecture. >> >> I do understand - I think - what we had in mind when we put the YANG >> architecture document in the charter, and this was related to >> clarification of specific issues that were discussed during the >> formation of the WG about how the flow of models in different >> languages >> will work and what is in-between. I agree with your observation that >> part of the output is tools dependent - but this is part of the >> clarification. >> >> What would a 'big picture' architecture for NETCONF include in your >> opinion? What NETCONF architectural concepts are missing to >> provide for >> the NETMOD architecture? >> >> I do not hide that I am somehow concerned that when we would >> get to the >> NETCONF architecture we would need to refer a broader >> architecture view >> of the IETF management architecture. From boiling a cup of >> tea we got to >> boiling a lake and we then get close to boiling the ocean. >> >> Dan >> >> (speaking as a contributor) >> >> >> >>> -----Original Message----- >>> From: netmod-bounces@ietf.org >>> [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder >>> Sent: Tuesday, September 09, 2008 10:13 AM >>> To: netmod@ietf.org >>> Subject: [netmod] architecture document scope >>> >>> Hi, >>> >>> I think we need to agree what the purpose and scope of the >>> architecture document is. The NETMOD charter says: >>> >>> 1. An architecture document explaining the relationship >>> between YANG and its inputs and outputs. (informational) >>> >>> This is rather fuzzy. While the input is clear (data models >>> written in YANG), the output is less clear since at the end >>> of the day we want YANG models to be implemented in NETCONF >>> servers as the output. How you get there is tool dependent. >>> >>> For me, it would make more sense to have an architecture >>> document describing the big picture behind NETCONF plus YANG. >>> Since YANG is a domain specific language for NETCONF, I would >>> even argue that a YANG architecture has to reference NETCONF >>> architectural concepts and since we do not have a NETCONF >>> architecture, we need to address this anyhow. >>> >>> What is the WGs opinion? >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > Germany >>> Fax: +49 421 200 3103 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 15 23: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 DF0723A6A1C; Mon, 15 Sep 2008 23:53:34 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA693A6A1C for ; Mon, 15 Sep 2008 23:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.536, 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 R2hIZrdQ7r7j for ; Mon, 15 Sep 2008 23:53:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6AB673A68A6 for ; Mon, 15 Sep 2008 23:53:31 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E075BC0030; Tue, 16 Sep 2008 08:53:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fIdqWBVhzhQx; Tue, 16 Sep 2008 08:53:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12AF6C002C; Tue, 16 Sep 2008 08:53:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BBE4B6CB35C; Tue, 16 Sep 2008 08:53:35 +0200 (CEST) Date: Tue, 16 Sep 2008 08:53:35 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080916065335.GA8187@elstar.local> Mail-Followup-To: Andy Bierman , David B Harrington , netmod@ietf.org References: <041001c91777$329459e0$0600a8c0@china.huawei.com> <48CEEE50.4070308@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48CEEE50.4070308@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: David B Harrington , netmod@ietf.org Subject: Re: [netmod] FW: architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Sep 15, 2008 at 04:22:56PM -0700, Andy Bierman wrote: > The YANG input is a sequence of UTF-8 characters, > probably typed into a file by a human. The output > are supposedly DSDL files. This sounds great, wrt/ > the IETF view of the problem space, but it doesn't > seem to address the real problem space. Yes. Perhaps we should take the charter literally as DBH suggests and produce a 1-2 pages document along the paragraph above and be done with this deliverable quickly. /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 Sep 16 17:44:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55D53A698C; Tue, 16 Sep 2008 17:44:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9F93A698C for ; Tue, 16 Sep 2008 17:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 Vw5XP3i1s22Z for ; Tue, 16 Sep 2008 17:44:45 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 77CE73A67AD for ; Tue, 16 Sep 2008 17:44:45 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA03.westchester.pa.mail.comcast.net with comcast id FYPA1a01W0vyq2s53ckw1A; Wed, 17 Sep 2008 00:44:56 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id Fcku1a0024HwxpC3Rckuqx; Wed, 17 Sep 2008 00:44:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=-OJq2QfNcNcA:10 a=Wm4xPKxFQX0A:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=1o1X5p3H-JMk99r5xSgA:9 a=NwAEbhsyKPT4iGV2aPsA:7 a=DbbUZofGwxxBWE7xtl20I-e3nlsA:4 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Andy Bierman'" , "'David B Harrington'" References: <041001c91777$329459e0$0600a8c0@china.huawei.com> <48CEEE50.4070308@netconfcentral.com> Date: Tue, 16 Sep 2008 20:44:54 -0400 Message-ID: <04ef01c9185e$99e676e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <48CEEE50.4070308@netconfcentral.com> Thread-Index: AckXigE1w0YECKQFQySljqVc3VXPkQA06WYA Cc: netmod@ietf.org Subject: Re: [netmod] FW: architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 > The phrase "inputs and outputs of YANG" is fairly vague. > There are all kinds of NETCONF-isms throughout > the YANG document. This is fine with me, since I plan > to use YANG to define NETCONF protocol content. > It's not clear to me what else YANG should be used for, > but I would like to make sure it is useful for that protocol. As I said, YANG is designed to be used within a Netconf environment. > > The YANG input is a sequence of UTF-8 characters, > probably typed into a file by a human. The output > are supposedly DSDL files. This sounds great, wrt/ > the IETF view of the problem space, but it doesn't > seem to address the real problem space. YANG input can also yield YIN output YANG input can also yield on-the-wire XML In the future, work might be done to provide translations to other formats, but those are not part of the charter of the netmod WG In the future, work might be done to provide translations from other formats, but those are not part of the charter of the netmod WG The purpose of the architecture document is to explain what the different document types are and their use cases: YANG is meant to be user-friendly YIN is meant to represent in an XML-tools friendly format. on-the-wire XML is meant to meet certain requirements for readability on the sire requested by operators. DSDL is meant to represent YANG models in DSDL-tools friendly format. > > > Andy > > > > [speaking as individual contributor] > > > > I do not believe this document should be a "Netconf architecture" > > document - that should be the responsibility of the Netconf WG. Many > > of the items in Andy's list of things to include should not be > > included here, since they are about netconf, not netmod. > > > > I certainly have no objection to explaining that YANG is > > designed to work within a Netconf architecture. But it should NOT be > > our job to define what a Netconf architecture is. Since > Netconf WG has > > not published an architecture document, this makes our job > harder, but > > I think it is pretty simple to say that Netconf can carry any valid > > XML, and that YANG defines a schema language for specifying an XML > > format that can be used as Netconf content. The important > part is that > > YANG is designed to be a user-friendly schema langauge, and then to > > describe the purpose of the other documents we will produce > from YANG. > > > > dbh > > > > > >> -----Original Message----- > >> From: netmod-bounces@ietf.org > >> [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > >> Sent: Tuesday, September 09, 2008 6:11 AM > >> To: j.schoenwaelder@jacobs-university.de; netmod@ietf.org > >> Subject: Re: [netmod] architecture document scope > >> > >> Juergen, > >> > >> I would not spend too much time looking strictly at the > words in the > >> charter - especially when we deal with architecture. > >> > >> I do understand - I think - what we had in mind when we > put the YANG > >> architecture document in the charter, and this was related to > >> clarification of specific issues that were discussed during the > >> formation of the WG about how the flow of models in different > >> languages > >> will work and what is in-between. I agree with your > observation that > >> part of the output is tools dependent - but this is part of the > >> clarification. > >> > >> What would a 'big picture' architecture for NETCONF include in your > >> opinion? What NETCONF architectural concepts are missing to > >> provide for > >> the NETMOD architecture? > >> > >> I do not hide that I am somehow concerned that when we would > >> get to the > >> NETCONF architecture we would need to refer a broader > >> architecture view > >> of the IETF management architecture. From boiling a cup of > >> tea we got to > >> boiling a lake and we then get close to boiling the ocean. > >> > >> Dan > >> > >> (speaking as a contributor) > >> > >> > >> > >>> -----Original Message----- > >>> From: netmod-bounces@ietf.org > >>> [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > >>> Sent: Tuesday, September 09, 2008 10:13 AM > >>> To: netmod@ietf.org > >>> Subject: [netmod] architecture document scope > >>> > >>> Hi, > >>> > >>> I think we need to agree what the purpose and scope of the > >>> architecture document is. The NETMOD charter says: > >>> > >>> 1. An architecture document explaining the relationship > >>> between YANG and its inputs and outputs. (informational) > >>> > >>> This is rather fuzzy. While the input is clear (data models > >>> written in YANG), the output is less clear since at the end > >>> of the day we want YANG models to be implemented in NETCONF > >>> servers as the output. How you get there is tool dependent. > >>> > >>> For me, it would make more sense to have an architecture > >>> document describing the big picture behind NETCONF plus YANG. > >>> Since YANG is a domain specific language for NETCONF, I would > >>> even argue that a YANG architecture has to reference NETCONF > >>> architectural concepts and since we do not have a NETCONF > >>> architecture, we need to address this anyhow. > >>> > >>> What is the WGs opinion? > >>> > >>> /js > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > > Germany > >>> Fax: +49 421 200 3103 > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > > > > _______________________________________________ > > 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 16 19: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 EAEDD3A69A9; Tue, 16 Sep 2008 19:05:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45343A69D0 for ; Tue, 16 Sep 2008 19:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 s0TIGQgUVeA0 for ; Tue, 16 Sep 2008 19:05:17 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 23BB13A6781 for ; Tue, 16 Sep 2008 19:05:17 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 16 Sep 2008 19:04:15 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Sep 2008 19:04:52 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Sep 2008 19:04:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Sep 2008 19:04:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8H24oM60393; Tue, 16 Sep 2008 19:04:51 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8H20tEC000843; Wed, 17 Sep 2008 02:00:55 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809170200.m8H20tEC000843@idle.juniper.net> To: "David Harrington" In-reply-to: <04ef01c9185e$99e676e0$0600a8c0@china.huawei.com> Date: Tue, 16 Sep 2008 22:00:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Sep 2008 02:04:51.0342 (UTC) FILETIME=[C50DD2E0:01C91869] Cc: 'David B Harrington' , netmod@ietf.org Subject: Re: [netmod] FW: architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" writes: >The purpose of the architecture document is to explain what the >different document types are and their use cases: >YANG is meant to be user-friendly >YIN is meant to represent in an XML-tools friendly format. >on-the-wire XML is meant to meet certain requirements for readability >on the sire requested by operators. >DSDL is meant to represent YANG models in DSDL-tools friendly format. Is this missing in the current draft? Am I going into too much detail? I readily admit I have no clue what the target zone is or if I'm even pointing down range. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 16 23:21: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 2871D3A682D; Tue, 16 Sep 2008 23:21:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15223A6998 for ; Tue, 16 Sep 2008 23:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k534Ykn5b05 for ; Tue, 16 Sep 2008 23:21:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0C4073A6927 for ; Tue, 16 Sep 2008 23:21:25 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D19F1D800C5 for ; Wed, 17 Sep 2008 08:21:37 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <04ef01c9185e$99e676e0$0600a8c0@china.huawei.com> References: <041001c91777$329459e0$0600a8c0@china.huawei.com> <48CEEE50.4070308@netconfcentral.com> <04ef01c9185e$99e676e0$0600a8c0@china.huawei.com> Organization: CESNET Date: Wed, 17 Sep 2008 08:21:37 +0200 Message-Id: <1221632497.6255.3.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] FW: architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 RGF2aWQgSGFycmluZ3RvbiBww63FoWUgdiDDmnQgMTYuIDA5LiAyMDA4IHYgMjA6NDQgLTA0MDA6 Cgo+IFlBTkcgaW5wdXQgY2FuIGFsc28geWllbGQgb24tdGhlLXdpcmUgWE1MCgpZQU5HIGlucHV0 IGNhbiB5aWVsZCAqY29uc3RyYWludHMqIGZvciBvbi10aGUtd2lyZSBYTUwgYW5kIGludGVncmF0 aW9uCmludG8gTkVUQ09ORiBQRFVzLiBUaGlzIGlzIElNTyB0aGUgbWFpbiByb2xlIG9mIHRoZSBE U0RMIHRyYW5zbGF0aW9uLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBL ZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Sep 17 06:07:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22F53A6C81; Wed, 17 Sep 2008 06:07:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28E53A6C81 for ; Wed, 17 Sep 2008 06:07:14 -0700 (PDT) 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.560, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkPC7lsZxKup for ; Wed, 17 Sep 2008 06:07:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 396333A6C2A for ; Wed, 17 Sep 2008 06:07:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 47BCB76C4D7; Wed, 17 Sep 2008 15:07:26 +0200 (CEST) Date: Wed, 17 Sep 2008 15:08:47 +0200 (CEST) Message-Id: <20080917.150847.51733345.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48BE85D4.6030105@netconfcentral.com> References: <48B7F26D.7080805@netconfcentral.com> <20080903.100608.11667281.mbj@tail-f.com> <48BE85D4.6030105@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] data-not-unique not secure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > So it may be good enough for YANG to say "do not leak any > unauthorized data via XPath expressions, such as the > predicates defining key/value pairs". I just realized that this case is handled in RFC 4741, section 4.3: A server MUST NOT return application-level- or data-model-specific error information in an element for which the client does not have sufficient access rights. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 19 05:35: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 5492B3A6B37; Fri, 19 Sep 2008 05:35:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9E33A6B52 for ; Fri, 19 Sep 2008 05:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 q3ZuYPiMzVOE for ; Fri, 19 Sep 2008 05:35:56 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A021F3A6B37 for ; Fri, 19 Sep 2008 05:35:55 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8JCa9ME007208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Sep 2008 14:36:09 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8JCa9Pc022527 for ; Fri, 19 Sep 2008 14:36:09 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 14:36:04 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 14:36:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 15:36:07 +0300 Message-ID: <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> In-Reply-To: <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: Acj9V9FFql5wX0k4QaatA67fhFnTAQBk3f0QBs+tKBA= References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: X-OriginalArrivalTime: 19 Sep 2008 12:36:04.0073 (UTC) FILETIME=[47C97590:01C91A54] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080919143609-4E160BB0-D3C01E39/0-0/0-15 X-purgate-size: 4351/0 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Sorry for the late reply, I was four weeks on vacation ;-) > -----Original Message----- > From: Linowski Bernd (EXT-Other - DE/Dusseldorf) > Sent: 15 August, 2008 17:43 > To: netmod@ietf.org; ext Andy Bierman > Subject: RE: [netmod] Augmentable Groupings > > > Hi, > > Andy Bierman andy@netconfcentral.com wrote: > > -----Original Message----- > > From: ext Andy Bierman [mailto:andy@netconfcentral.com] > > Sent: 13 August, 2008 17:18 > > To: Linowski Bernd (EXT-Other - DE/Dusseldorf) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Augmentable Groupings > > > > bernd.linowski.ext@nsn.com wrote: > > > > > > Hi, > > > > > > Andy Bierman andy@netconfcentral.com wrote: > > > > Actually groupings are not in the same namespace as objects, > > > > so this Xpath is broken. > > > > > > > > > > > > grouping foo; > > > > > > > > container foo; > > > > > > > > Both of these are legal YANG. > > > > > > That is not in line what is stated in section 7.11 of the > > > YANG specification: > > > " If the grouping is defined at the top level of a YANG module or > > > submodule, the grouping's identifier MUST be unique within the > > > module." > > > Name "foo" is not unqiue within the module. > > > > > > > Here is the text from the draft: > > > > 6.2.1. Identifiers and their namespaces > > > > .... > > > > o All groupings defined within a parent node or at the > > top-level of > > the module or its submodules share the same grouping > identifier > > namespace. This namespace is scoped to the parent > > node or module. > > > > .... > > > > All identifiers defined in a namespace MUST be unique. > > > > I agree, there could be an ambiguity as there is a separate grouping > identifier namespace. > > Let me reconsider the options how to address this. > In order to address this issue, I suggest that groupings are put in the same namespace as data nodes, rpc's and notifications. As mentioned in an earlier mail from Andy Bierman, collapsing the grouping namespace into the object namespace is in practice no problem. Since YANG identifiers are case sensitive unique naming of objects still remains easy. Other advantages of this solution are that a new statement is not needed and that namespace handling is simplified. In summary, introducing augmentable groupings means: - A grouping can be the target (node) of an augment statement. - Augmentation of a grouping becomes only effective in case the module containing the augment statement is advertized. - The nodes added to the grouping are therefore implicitly added to all places the grouping is used in the set of modules supported by an agent. - The augmented nodes are in the XML namespace of the module of the augment statement. - Groupings share the same namespace with data nodes, rpc's and notification in order to address them unambiguously in an augment statement. - In general, it is not allowed to augment mandatory nodes to a grouping. I think augmentable groupings are a powerful tool, which has different advantages for optimizing reuse but should only be utilized if appropriate. BR, Bernd > > > > > > > > > > > > If I nest the groupings, then what happens to the augment: > > > > > > > > module C { > > > > > > > > grouping new-concepts { > > > > uses concepts; > > > > } > > > > > > > > Does new-concepts contain the augmentations from concepts? > > > > > > > > > > Yes. > > > > > > > > > Yes, well this makes it an NP-complete problem to resolve all the > > uses statements in all the modules. > > > > Even if that did not matter (just implementation!), the NETCONF > > vendors have to deal with a pool of modules for which > > they have no change control whatsoever. And what about their own > > modules already out there in shipping code? > > > > This 'write once, and it shows up everywhere' feature is not > > actually usable in the operational environment that YANG > must address. > > > > > > Andy > > > > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 19 06:10: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 5E30D3A6887; Fri, 19 Sep 2008 06:10:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC4B3A6918 for ; Fri, 19 Sep 2008 06:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.851, 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 Ftftd6g-lBBp for ; Fri, 19 Sep 2008 06:10:51 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 564063A6B40 for ; Fri, 19 Sep 2008 06:10:51 -0700 (PDT) Received: (qmail 52233 invoked from network); 19 Sep 2008 13:10:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.229.223 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 19 Sep 2008 13:10:38 -0000 X-YMail-OSG: LDxBkjIVM1kPmSQvjsP4_TQZB7MgDOsdZVKdZrxVeGuiEbAdGidu15k24D3GtwPdkJQ1GwEuFYFrPjaOJkcbr3H4Miz.XXp9NrEmMlqOiRl0.1wOh0Qwq2MHr3ZOT7MfNmjFWOdrHs8Lxok4SuycgZiSVlPtGQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48D3A4CC.2090906@netconfcentral.com> Date: Fri, 19 Sep 2008 06:10:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > Hi, > > Sorry for the late reply, I was four weeks on vacation ;-) > The YANG namespace issue is trivial, and not the real problem. As mentioned by several people, this is not how OO works for derived classes. I do not think YANG should be OO at all, but if I did, I would want to follow the class hierarchy model. Specifically, you should create a new class with a new name if you want to add some new data to an existing class. This allows all instances of the old class to continue working as instances of the new class are also created. Andy > >> -----Original Message----- >> From: Linowski Bernd (EXT-Other - DE/Dusseldorf) >> Sent: 15 August, 2008 17:43 >> To: netmod@ietf.org; ext Andy Bierman >> Subject: RE: [netmod] Augmentable Groupings >> >> >> Hi, >> >> Andy Bierman andy@netconfcentral.com wrote: >>> -----Original Message----- >>> From: ext Andy Bierman [mailto:andy@netconfcentral.com] >>> Sent: 13 August, 2008 17:18 >>> To: Linowski Bernd (EXT-Other - DE/Dusseldorf) >>> Cc: netmod@ietf.org >>> Subject: Re: [netmod] Augmentable Groupings >>> >>> bernd.linowski.ext@nsn.com wrote: >>>> Hi, >>>> >>>> Andy Bierman andy@netconfcentral.com wrote: >>>> > Actually groupings are not in the same namespace as objects, >>>> > so this Xpath is broken. >>>> > >>>> > >>>> > grouping foo; >>>> > >>>> > container foo; >>>> > >>>> > Both of these are legal YANG. >>>> >>>> That is not in line what is stated in section 7.11 of the >>>> YANG specification: >>>> " If the grouping is defined at the top level of a YANG module or >>>> submodule, the grouping's identifier MUST be unique within the >>>> module." >>>> Name "foo" is not unqiue within the module. >>>> >>> Here is the text from the draft: >>> >>> 6.2.1. Identifiers and their namespaces >>> >>> .... >>> >>> o All groupings defined within a parent node or at the >>> top-level of >>> the module or its submodules share the same grouping >> identifier >>> namespace. This namespace is scoped to the parent >>> node or module. >>> >>> .... >>> >>> All identifiers defined in a namespace MUST be unique. >>> >> I agree, there could be an ambiguity as there is a separate grouping >> identifier namespace. >> >> Let me reconsider the options how to address this. >> > > In order to address this issue, I suggest that groupings > are put in the same namespace as data nodes, rpc's and > notifications. > As mentioned in an earlier mail from Andy Bierman, collapsing > the grouping namespace into the object namespace is in > practice no problem. Since YANG identifiers are case sensitive > unique naming of objects still remains easy. > Other advantages of this solution are that a new statement > is not needed and that namespace handling is simplified. > > > In summary, introducing augmentable groupings means: > > - A grouping can be the target (node) of > an augment statement. > - Augmentation of a grouping becomes only > effective in case the module containing > the augment statement is advertized. > - The nodes added to the grouping are therefore > implicitly added to all places the grouping > is used in the set of modules supported > by an agent. > - The augmented nodes are in the XML namespace > of the module of the augment statement. > - Groupings share the same namespace with > data nodes, rpc's and notification in order > to address them unambiguously in an augment > statement. > - In general, it is not allowed to augment > mandatory nodes to a grouping. > > > I think augmentable groupings are a powerful tool, which has > different advantages for optimizing reuse but should only be > utilized if appropriate. > > BR, > Bernd > > > >>> >>>> > >>>> > If I nest the groupings, then what happens to the augment: >>>> > >>>> > module C { >>>> > >>>> > grouping new-concepts { >>>> > uses concepts; >>>> > } >>>> > >>>> > Does new-concepts contain the augmentations from concepts? >>>> > >>>> >>>> Yes. >>>> >>> >>> Yes, well this makes it an NP-complete problem to resolve all the >>> uses statements in all the modules. >>> >>> Even if that did not matter (just implementation!), the NETCONF >>> vendors have to deal with a pool of modules for which >>> they have no change control whatsoever. And what about their own >>> modules already out there in shipping code? >>> >>> This 'write once, and it shows up everywhere' feature is not >>> actually usable in the operational environment that YANG >> must address. >>> >>> Andy >> >> >> >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 19 06:39:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AC23A68DE; Fri, 19 Sep 2008 06:39:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E813A68F6 for ; Fri, 19 Sep 2008 06:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.828, 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 cCSkCJaXJGkq for ; Fri, 19 Sep 2008 06:39:56 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 0062E3A68DE for ; Fri, 19 Sep 2008 06:39:55 -0700 (PDT) Received: (qmail 603 invoked from network); 19 Sep 2008 13:40:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.229.223 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 19 Sep 2008 13:40:04 -0000 X-YMail-OSG: B2mJwgAVM1mtr0DC7ozTPYdN9P1THwo3X3hSuzd.36EFQUmgKlsEiDm1yUxgWZKbC8d5FScvIiPjvuPKzeoarSAit5s4.eVZspAK.TJupDo1THwIuC1B3q0EIaK6elHmxx0Z6FGC X-Yahoo-Newman-Property: ymail-3 Message-ID: <48D3ABB1.1050708@netconfcentral.com> Date: Fri, 19 Sep 2008 06:40:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809170200.m8H20tEC000843@idle.juniper.net> In-Reply-To: <200809170200.m8H20tEC000843@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] FW: architecture document scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > "David Harrington" writes: >> The purpose of the architecture document is to explain what the >> different document types are and their use cases: >> YANG is meant to be user-friendly >> YIN is meant to represent in an XML-tools friendly format. >> on-the-wire XML is meant to meet certain requirements for readability >> on the sire requested by operators. >> DSDL is meant to represent YANG models in DSDL-tools friendly format. > > Is this missing in the current draft? Am I going into too much > detail? I readily admit I have no clue what the target zone is or > if I'm even pointing down range. > Apparently the NETMOD architecture is supposed to heavily depend on the NETCONF architecture, which doesn't exist. I think what Juergen is suggesting is a very generic NETMOD arch, which I support as well: NETCONF content is defined in 1 or more collections of UTF-8 characters, called YANG modules. An XML encoding of the YANG language is supported via the YANG to YIN mapping specification. This allows tools which manipulate XML to be used to process YANG modules. Conceptual NETCONF operations and configuration database data structures can be associated with the YANG language mechanisms, and is supported via the YANG to XML mapping rules within the YANG specification. The syntax and constraints for XML documents representing NETCONF PDUs containing YANG data structures can be specified with various XML modeling languages. The DSDL standard is supported for this purpose, via the YANG to DSDL mapping specification. Without NETCONF details out of scope, how much more can you say about NETMOD? > Thanks, > Phil > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 19 11:32: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 B628E3A69A2; Fri, 19 Sep 2008 11:32:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2F73A6B28 for ; Fri, 19 Sep 2008 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.501, 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 0SU1s5RyzFBZ for ; Fri, 19 Sep 2008 11:32:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7C0A13A69A2 for ; Fri, 19 Sep 2008 11:32:33 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71F2DC0061; Fri, 19 Sep 2008 20:32:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kkdUew2DBLWB; Fri, 19 Sep 2008 20:32:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9F30C005D; Fri, 19 Sep 2008 20:32:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 998567B201F; Fri, 19 Sep 2008 20:32:40 +0200 (CEST) Date: Fri, 19 Sep 2008 20:32:40 +0200 From: Juergen Schoenwaelder To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" Message-ID: <20080919183240.GA1601@elstar.local> Mail-Followup-To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Sep 19, 2008 at 03:36:07PM +0300, Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > In summary, introducing augmentable groupings means: > > - A grouping can be the target (node) of > an augment statement. > - Augmentation of a grouping becomes only > effective in case the module containing > the augment statement is advertized. What does "advertized" mean? If you have the NETCONF hello exchange in mind, then I believe this is broken as long as we assume modular implementations where some parts of the data model use the augmented grouping while others do not. > - The nodes added to the grouping are therefore > implicitly added to all places the grouping > is used in the set of modules supported > by an agent. See above, I doubt this works in general. [...] > I think augmentable groupings are a powerful tool, which has > different advantages for optimizing reuse but should only be > utilized if appropriate. I think it would help us if someone can (a) spell out the "different advantages", (b) how augmentable groupings "optimize reuse", and (c) when it is "appropriate" to utilize them and when 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 Mon Sep 22 01:38:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDC53A68CE; Mon, 22 Sep 2008 01:38:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C80D3A68D6 for ; Mon, 22 Sep 2008 01:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auzswP5ereD0 for ; Mon, 22 Sep 2008 01:38:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EC5053A68CF for ; Mon, 22 Sep 2008 01:38:34 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 13BAF76C4F7 for ; Mon, 22 Sep 2008 10:38:30 +0200 (CEST) Date: Mon, 22 Sep 2008 10:39:53 +0200 (CEST) Message-Id: <20080922.103953.69288811.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, Given this list list interface { key "name"; leaf name { type string; } list address { key "ip"; leaf ip { type yang:ip-address; } leaf broadcast { type yang:ip-address; } } } I think it would make sense for a client to replace all addresses on a paticular interface with an edit-config like this: eth0
10.0.0.1
172.0.0.1
I.e. by specifying "delete" on a list node, but not giving any keys, all list entries are deleted. But suppose we have this: leaf-list domain-search { type string; ordered-by user; description "List of domain names to search"; } A client might want to set the same domain-search list (say foo.com, bar.com) on all devices in the network. But how does he do that? He cannot do: foo.com bar.com since this will just append foo.com and bar.com to the end of the domain-search list. We could do as in the list example above: foo.com bar.com but since the delete operation is used to delete a single leaf-list entry if a value is given, and an empty XML element is the same as giving an empty value, this means that a leaf-list entry cannot contain the empty string. This seems to be an odd CLR. In YANG we currently specify the semantics of the "delete" operation from RFC 4741 to say that for lists, all keys MUST be present and are used to select one entry, and for leaf-list the value is used to select one entry. An alternative which solves this problem, could be that when the operation is "delete", then EITHER the keys/value are present as XML elements, OR an XML attribute "scope='all'" (or something similar) is present: foo.com bar.com /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 22 02:18: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 31B403A6846; Mon, 22 Sep 2008 02:18:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A2C3A684B for ; Mon, 22 Sep 2008 02:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 Kng2sGAKI-Ty for ; Mon, 22 Sep 2008 02:18:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1808B3A6846 for ; Mon, 22 Sep 2008 02:18:50 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 6C734D800BD for ; Mon, 22 Sep 2008 11:18:50 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080922.103953.69288811.mbj@tail-f.com> References: <20080922.103953.69288811.mbj@tail-f.com> Organization: CESNET Date: Mon, 22 Sep 2008 11:18:50 +0200 Message-Id: <1222075130.6243.50.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SGksCgpJIHRoaW5rIHRoZSBtZXJnZSBvcGVyYXRpb24gaW4gUkZDIDQ3NDEgaXMgc2VyaW91c2x5 IHVuZGVyc3BlY2lmaWVkLiBJbgpwYXJ0aWN1bGFyLCBpdCBkb2Vzbid0IHNheSB3aGF0IGhhcHBl bnMgaWYgPGVkaXQtY29uZmlnPiBjb250YWlucyBsZWFmCmRhdGEgdGhhdCBhcmUgYWxyZWFkeSBw cmVzZW50IGluIHRoZSB0YXJnZXQgY29uZmlndXJhdGlvbiAtIGl0IGNhbid0IGRvCnNvIHdpdGhv dXQgaW50cm9kdWNpbmcgdGhlIGNvbmNlcHQgb2YgYSBsaXN0IGtleSwgc2VtYW50aWNzIG9mIGRl ZmF1bHQKdmFsdWVzIChkbyB0aGV5IGV4aXN0IGluIHRoZSBjb25maWd1cmF0aW9uPykgZXRjLgoK T24gdGhlIG90aGVyIGhhbmQsIHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgdGhhdCBSRkMgNDc0 MSBkb2VzIGRlZmluZQpjYW4gaW50ZXJmZXJlIHdpdGggWUFORyBzZW1hbnRpY3MgaW4gdmFyaW91 cyB1Z2x5IHdheXMuCgpMYWRhCgpNYXJ0aW4gQmpvcmtsdW5kIHDDrcWhZSB2IFBvIDIyLiAwOS4g MjAwOCB2IDEwOjM5ICswMjAwOgo+IEhpLAo+IAo+IEdpdmVuIHRoaXMgbGlzdAo+IAo+ICAgbGlz dCBpbnRlcmZhY2Ugewo+ICAgICAgIGtleSAibmFtZSI7Cj4gICAgICAgbGVhZiBuYW1lIHsKPiAg ICAgICAgICAgdHlwZSBzdHJpbmc7Cj4gICAgICAgfQo+ICAgICAgIGxpc3QgYWRkcmVzcyB7Cj4g ICAgICAgICAgIGtleSAiaXAiOwo+ICAgICAgICAgICBsZWFmIGlwIHsKPiAgICAgICAgICAgICAg IHR5cGUgeWFuZzppcC1hZGRyZXNzOwo+ICAgICAgICAgICB9Cj4gICAgICAgICAgIGxlYWYgYnJv YWRjYXN0IHsKPiAgICAgICAgICAgICAgIHR5cGUgeWFuZzppcC1hZGRyZXNzOwo+ICAgICAgICAg ICB9Cj4gICAgICAgfQo+ICAgfQo+IAo+IEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSBmb3Ig YSBjbGllbnQgdG8gcmVwbGFjZSBhbGwgYWRkcmVzc2VzIG9uIGEKPiBwYXRpY3VsYXIgaW50ZXJm YWNlIHdpdGggYW4gZWRpdC1jb25maWcgbGlrZSB0aGlzOgo+IAo+ICAgPGVkaXQtY29uZmlnPgo+ ICAgICA8dGFyZ2V0Pgo+ICAgICAgIDxydW5uaW5nLz4KPiAgICAgPC90YXJnZXQ+Cj4gICAgIDxj b25maWc+Cj4gICAgICAgPGludGVyZmFjZSB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2ludGVy ZmFjZSI+Cj4gICAgICAgICA8bmFtZT5ldGgwPC9uYW1lPgo+ICAgICAgICAgPGFkZHJlc3MgbmM6 b3BlcmF0aW9uPSJkZWxldGUiLz4KPiAgICAgICAgIDxhZGRyZXNzPgo+ICAgICAgICAgICA8aXA+ MTAuMC4wLjE8L2lwPgo+ICAgICAgICAgPC9hZGRyZXNzPgo+ICAgICAgICAgPGFkZHJlc3M+Cj4g ICAgICAgICAgIDxpcD4xNzIuMC4wLjE8L2lwPgo+ICAgICAgICAgPC9hZGRyZXNzPgo+ICAgICAg IDwvaW50ZXJmYWNlPgo+ICAgICA8L2NvbmZpZz4KPiAgIDwvZWRpdC1jb25maWc+Cj4gCj4gSS5l LiBieSBzcGVjaWZ5aW5nICJkZWxldGUiIG9uIGEgbGlzdCBub2RlLCBidXQgbm90IGdpdmluZyBh bnkga2V5cywKPiBhbGwgbGlzdCBlbnRyaWVzIGFyZSBkZWxldGVkLgo+IAo+IAo+IEJ1dCBzdXBw b3NlIHdlIGhhdmUgdGhpczoKPiAKPiAgICAgbGVhZi1saXN0IGRvbWFpbi1zZWFyY2ggewo+ICAg ICAgICAgdHlwZSBzdHJpbmc7Cj4gICAgICAgICBvcmRlcmVkLWJ5IHVzZXI7Cj4gICAgICAgICBk ZXNjcmlwdGlvbiAiTGlzdCBvZiBkb21haW4gbmFtZXMgdG8gc2VhcmNoIjsKPiAgICAgfQo+IAo+ IEEgY2xpZW50IG1pZ2h0IHdhbnQgdG8gc2V0IHRoZSBzYW1lIGRvbWFpbi1zZWFyY2ggbGlzdCAo c2F5IGZvby5jb20sCj4gYmFyLmNvbSkgb24gYWxsIGRldmljZXMgaW4gdGhlIG5ldHdvcmsuICBC dXQgaG93IGRvZXMgaGUgZG8gdGhhdD8gIEhlCj4gY2Fubm90IGRvOgo+IAo+ICAgPGVkaXQtY29u ZmlnPgo+ICAgICA8dGFyZ2V0Pgo+ICAgICAgIDxydW5uaW5nLz4KPiAgICAgPC90YXJnZXQ+Cj4g ICAgIDxjb25maWc+Cj4gICAgICAgPHN5c3RlbSB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3N5 c3RlbSI+Cj4gICAgICAgICA8ZG9tYWluLXNlYXJjaD5mb28uY29tPC9kb21haW4tc2VhcmNoPgo+ ICAgICAgICAgPGRvbWFpbi1zZWFyY2g+YmFyLmNvbTwvZG9tYWluLXNlYXJjaD4KPiAgICAgICA8 L3N5c3RlbT4KPiAgICAgPC9jb25maWc+Cj4gICA8L2VkaXQtY29uZmlnPgo+IAo+IHNpbmNlIHRo aXMgd2lsbCBqdXN0IGFwcGVuZCBmb28uY29tIGFuZCBiYXIuY29tIHRvIHRoZSBlbmQgb2YgdGhl Cj4gZG9tYWluLXNlYXJjaCBsaXN0Lgo+IAo+IFdlIGNvdWxkIGRvIGFzIGluIHRoZSBsaXN0IGV4 YW1wbGUgYWJvdmU6Cj4gCj4gICA8ZWRpdC1jb25maWc+Cj4gICAgIDx0YXJnZXQ+Cj4gICAgICAg PHJ1bm5pbmcvPgo+ICAgICA8L3RhcmdldD4KPiAgICAgPGNvbmZpZz4KPiAgICAgICA8c3lzdGVt IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc3lzdGVtIj4KPiAgICAgICAgIDxkb21haW4tc2Vh cmNoIG5jOm9wZXJhdGlvbj0iZGVsZXRlIi8+Cj4gICAgICAgICA8ZG9tYWluLXNlYXJjaD5mb28u Y29tPC9kb21haW4tc2VhcmNoPgo+ICAgICAgICAgPGRvbWFpbi1zZWFyY2g+YmFyLmNvbTwvZG9t YWluLXNlYXJjaD4KPiAgICAgICA8L3N5c3RlbT4KPiAgICAgPC9jb25maWc+Cj4gICA8L2VkaXQt Y29uZmlnPgo+IAo+IGJ1dCBzaW5jZSB0aGUgZGVsZXRlIG9wZXJhdGlvbiBpcyB1c2VkIHRvIGRl bGV0ZSBhIHNpbmdsZSBsZWFmLWxpc3QKPiBlbnRyeSBpZiBhIHZhbHVlIGlzIGdpdmVuLCBhbmQg YW4gZW1wdHkgWE1MIGVsZW1lbnQgaXMgdGhlIHNhbWUgYXMKPiBnaXZpbmcgYW4gZW1wdHkgdmFs dWUsIHRoaXMgbWVhbnMgdGhhdCBhIGxlYWYtbGlzdCBlbnRyeSBjYW5ub3QKPiBjb250YWluIHRo ZSBlbXB0eSBzdHJpbmcuICBUaGlzIHNlZW1zIHRvIGJlIGFuIG9kZCBDTFIuCj4gCj4gSW4gWUFO RyB3ZSBjdXJyZW50bHkgc3BlY2lmeSB0aGUgc2VtYW50aWNzIG9mIHRoZSAiZGVsZXRlIiBvcGVy YXRpb24KPiBmcm9tIFJGQyA0NzQxIHRvIHNheSB0aGF0IGZvciBsaXN0cywgYWxsIGtleXMgTVVT VCBiZSBwcmVzZW50IGFuZCBhcmUKPiB1c2VkIHRvIHNlbGVjdCBvbmUgZW50cnksIGFuZCBmb3Ig bGVhZi1saXN0IHRoZSB2YWx1ZSBpcyB1c2VkIHRvCj4gc2VsZWN0IG9uZSBlbnRyeS4KPiAKPiBB biBhbHRlcm5hdGl2ZSB3aGljaCBzb2x2ZXMgdGhpcyBwcm9ibGVtLCBjb3VsZCBiZSB0aGF0IHdo ZW4gdGhlCj4gb3BlcmF0aW9uIGlzICJkZWxldGUiLCB0aGVuIEVJVEhFUiB0aGUga2V5cy92YWx1 ZSBhcmUgcHJlc2VudCBhcyBYTUwKPiBlbGVtZW50cywgT1IgYW4gWE1MIGF0dHJpYnV0ZSAic2Nv cGU9J2FsbCciIChvciBzb21ldGhpbmcgc2ltaWxhcikgaXMKPiBwcmVzZW50Ogo+IAo+ICAgICAg ICAgPGRvbWFpbi1zZWFyY2ggbmM6b3BlcmF0aW9uPSJkZWxldGUiIHlhbmc6c2NvcGU9ImFsbCIv Pgo+ICAgICAgICAgPGRvbWFpbi1zZWFyY2g+Zm9vLmNvbTwvZG9tYWluLXNlYXJjaD4KPiAgICAg ICAgIDxkb21haW4tc2VhcmNoPmJhci5jb208L2RvbWFpbi1zZWFyY2g+Cj4gCj4gCj4gL21hcnRp bgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0 bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1Ag S2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Sep 22 05:03: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 724353A68D6; Mon, 22 Sep 2008 05:03:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20DC3A6912 for ; Mon, 22 Sep 2008 05:03:11 -0700 (PDT) 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 Nr2Xp0N8pnWC for ; Mon, 22 Sep 2008 05:03:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 24B943A68D6 for ; Mon, 22 Sep 2008 05:03:08 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id AEE2B76C4DF; Mon, 22 Sep 2008 14:02:18 +0200 (CEST) Date: Mon, 22 Sep 2008 14:03:42 +0200 (CEST) Message-Id: <20080922.140342.122069051.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1222075130.6243.50.camel@missotis> References: <20080922.103953.69288811.mbj@tail-f.com> <1222075130.6243.50.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > I think the merge operation in RFC 4741 is seriously underspecified. You're hijacking my thread ;-) I'll reply to your posting in a new thread. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 22 05:05: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 BA89E3A68D6; Mon, 22 Sep 2008 05:05:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC423A697A for ; Mon, 22 Sep 2008 05:05:38 -0700 (PDT) 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 GH4hTC5HcCWH for ; Mon, 22 Sep 2008 05:05:37 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A0BEE3A6912 for ; Mon, 22 Sep 2008 05:05:37 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C5DC76C4DF; Mon, 22 Sep 2008 14:05:19 +0200 (CEST) Date: Mon, 22 Sep 2008 14:06:43 +0200 (CEST) Message-Id: <20080922.140643.144876265.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: [netmod] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, [replying in a new thread to edit-config concerns raised in "delete in list and leaf-list"] Ladislav Lhotka wrote: > Hi, > > I think the merge operation in RFC 4741 is seriously underspecified. In > particular, it doesn't say what happens if contains leaf > data that are already present in the target configuration - it can't do > so without introducing the concept of a list key, semantics of default > values (do they exist in the configuration?) etc. Section 5.2 of RFC 4741 excplicitly state: Data modeling and content issues are outside the scope of the NETCONF protocol. An assumption is made that the device's data model is well-known to the application and that both parties are aware of issues such as the layout, containment, keying, lookup, replacement, and management of the data, as well as any other constraints imposed by the data model. Since the protocol is data model agnostic, it has to be pretty vague in talking about keys etc. It is important though that the YANG specification is very clear how edit-config works with data models defined in YANG. > On the other hand, the "operation" attribute that RFC 4741 does define > can interfere with YANG semantics in various ugly ways. Can you give an example? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 22 05:39:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708943A6A7E; Mon, 22 Sep 2008 05:39:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB713A6A7E for ; Mon, 22 Sep 2008 05:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.929, 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 dn3jtthmwrZn for ; Mon, 22 Sep 2008 05:39:41 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9AC7F3A6A77 for ; Mon, 22 Sep 2008 05:39:41 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D0D96D800C0 for ; Mon, 22 Sep 2008 14:39:31 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080922.103953.69288811.mbj@tail-f.com> References: <20080922.103953.69288811.mbj@tail-f.com> Organization: CESNET Date: Mon, 22 Sep 2008 14:39:32 +0200 Message-Id: <1222087172.6243.122.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 T0ssIEkgaG9wZSB0aGlzIGlzIG5vdCBjb25zaWRlcmVkIGhpamFja2luZzogOl4pCgpNYXJ0aW4g QmpvcmtsdW5kIHDDrcWhZSB2IFBvIDIyLiAwOS4gMjAwOCB2IDEwOjM5ICswMjAwOgoKPiAgIDxl ZGl0LWNvbmZpZz4KPiAgICAgPHRhcmdldD4KPiAgICAgICA8cnVubmluZy8+Cj4gICAgIDwvdGFy Z2V0Pgo+ICAgICA8Y29uZmlnPgo+ICAgICAgIDxpbnRlcmZhY2UgeG1sbnM9Imh0dHA6Ly9leGFt cGxlLmNvbS9pbnRlcmZhY2UiPgo+ICAgICAgICAgPG5hbWU+ZXRoMDwvbmFtZT4KPiAgICAgICAg IDxhZGRyZXNzIG5jOm9wZXJhdGlvbj0iZGVsZXRlIi8+CgpSRkMgNDc0MTogIlRoZSBjb25maWd1 cmF0aW9uIGRhdGEgaWRlbnRpZmllZCBieSB0aGUgZWxlbWVudCBjb250YWluaW5nCnRoaXMgYXR0 cmlidXRlIGlzIGRlbGV0ZWQgLi4uIi4gRG9lcyBpdCBtZWFuIGhlcmUgOiAoaSkgb25lL2ZpcnN0 CiJhZGRyZXNzIiBlbGVtZW50IG9yIChpaSkgYWxsIG9mIHRoZW0/IFlvdXIgZXhhbXBsZSBzZWVt cyB0byBhc3N1bWUgKGlpKQpidXQgdGhlIHZhZ3VlIGZvcm11bGF0aW9uIGluIFJGQyA0NzQxIG1h eSBiZSBpbnRlcnByZXRlZCBhcyAgKGkpLCB0b28uCgpUaGUgb3RoZXIgZWRpdC1jb25maWcgb3Bl cmF0aW9ucyBhcmUgc2ltaWxhcmx5IGlsbC1kZWZpbmVkLCBlc3BlY2lhbGx5CmZvciBsaXN0cyBh bmQgbGVhZi1saXN0cy4gSSBkb24ndCB0aGluayBZQU5HIG9yIGFueSBvdGhlciBETUwgY2FuIGZ1 bGx5CnJlcGFpciBzdWNoIGNyYWNrcyBpbiB0aGUgUkZDIDQ3NDEgZm91bmRhdGlvbi4KCkxhZGEK Cj4gICAgICAgICA8YWRkcmVzcz4KPiAgICAgICAgICAgPGlwPjEwLjAuMC4xPC9pcD4KPiAgICAg ICAgIDwvYWRkcmVzcz4KPiAgICAgICAgIDxhZGRyZXNzPgo+ICAgICAgICAgICA8aXA+MTcyLjAu MC4xPC9pcD4KPiAgICAgICAgIDwvYWRkcmVzcz4KPiAgICAgICA8L2ludGVyZmFjZT4KPiAgICAg PC9jb25maWc+Cj4gICA8L2VkaXQtY29uZmlnPgo+IAo+IEkuZS4gYnkgc3BlY2lmeWluZyAiZGVs ZXRlIiBvbiBhIGxpc3Qgbm9kZSwgYnV0IG5vdCBnaXZpbmcgYW55IGtleXMsCj4gYWxsIGxpc3Qg ZW50cmllcyBhcmUgZGVsZXRlZC4KPiAKPiAKPiBCdXQgc3VwcG9zZSB3ZSBoYXZlIHRoaXM6Cj4g Cj4gICAgIGxlYWYtbGlzdCBkb21haW4tc2VhcmNoIHsKPiAgICAgICAgIHR5cGUgc3RyaW5nOwo+ ICAgICAgICAgb3JkZXJlZC1ieSB1c2VyOwo+ICAgICAgICAgZGVzY3JpcHRpb24gIkxpc3Qgb2Yg ZG9tYWluIG5hbWVzIHRvIHNlYXJjaCI7Cj4gICAgIH0KPiAKPiBBIGNsaWVudCBtaWdodCB3YW50 IHRvIHNldCB0aGUgc2FtZSBkb21haW4tc2VhcmNoIGxpc3QgKHNheSBmb28uY29tLAo+IGJhci5j b20pIG9uIGFsbCBkZXZpY2VzIGluIHRoZSBuZXR3b3JrLiAgQnV0IGhvdyBkb2VzIGhlIGRvIHRo YXQ/ICBIZQo+IGNhbm5vdCBkbzoKPiAKPiAgIDxlZGl0LWNvbmZpZz4KPiAgICAgPHRhcmdldD4K PiAgICAgICA8cnVubmluZy8+Cj4gICAgIDwvdGFyZ2V0Pgo+ICAgICA8Y29uZmlnPgo+ICAgICAg IDxzeXN0ZW0geG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zeXN0ZW0iPgo+ICAgICAgICAgPGRv bWFpbi1zZWFyY2g+Zm9vLmNvbTwvZG9tYWluLXNlYXJjaD4KPiAgICAgICAgIDxkb21haW4tc2Vh cmNoPmJhci5jb208L2RvbWFpbi1zZWFyY2g+Cj4gICAgICAgPC9zeXN0ZW0+Cj4gICAgIDwvY29u ZmlnPgo+ICAgPC9lZGl0LWNvbmZpZz4KPiAKPiBzaW5jZSB0aGlzIHdpbGwganVzdCBhcHBlbmQg Zm9vLmNvbSBhbmQgYmFyLmNvbSB0byB0aGUgZW5kIG9mIHRoZQo+IGRvbWFpbi1zZWFyY2ggbGlz dC4KPiAKPiBXZSBjb3VsZCBkbyBhcyBpbiB0aGUgbGlzdCBleGFtcGxlIGFib3ZlOgo+IAo+ICAg PGVkaXQtY29uZmlnPgo+ICAgICA8dGFyZ2V0Pgo+ICAgICAgIDxydW5uaW5nLz4KPiAgICAgPC90 YXJnZXQ+Cj4gICAgIDxjb25maWc+Cj4gICAgICAgPHN5c3RlbSB4bWxucz0iaHR0cDovL2V4YW1w bGUuY29tL3N5c3RlbSI+Cj4gICAgICAgICA8ZG9tYWluLXNlYXJjaCBuYzpvcGVyYXRpb249ImRl bGV0ZSIvPgo+ICAgICAgICAgPGRvbWFpbi1zZWFyY2g+Zm9vLmNvbTwvZG9tYWluLXNlYXJjaD4K PiAgICAgICAgIDxkb21haW4tc2VhcmNoPmJhci5jb208L2RvbWFpbi1zZWFyY2g+Cj4gICAgICAg PC9zeXN0ZW0+Cj4gICAgIDwvY29uZmlnPgo+ICAgPC9lZGl0LWNvbmZpZz4KPiAKPiBidXQgc2lu Y2UgdGhlIGRlbGV0ZSBvcGVyYXRpb24gaXMgdXNlZCB0byBkZWxldGUgYSBzaW5nbGUgbGVhZi1s aXN0Cj4gZW50cnkgaWYgYSB2YWx1ZSBpcyBnaXZlbiwgYW5kIGFuIGVtcHR5IFhNTCBlbGVtZW50 IGlzIHRoZSBzYW1lIGFzCj4gZ2l2aW5nIGFuIGVtcHR5IHZhbHVlLCB0aGlzIG1lYW5zIHRoYXQg YSBsZWFmLWxpc3QgZW50cnkgY2Fubm90Cj4gY29udGFpbiB0aGUgZW1wdHkgc3RyaW5nLiAgVGhp cyBzZWVtcyB0byBiZSBhbiBvZGQgQ0xSLgo+IAo+IEluIFlBTkcgd2UgY3VycmVudGx5IHNwZWNp ZnkgdGhlIHNlbWFudGljcyBvZiB0aGUgImRlbGV0ZSIgb3BlcmF0aW9uCj4gZnJvbSBSRkMgNDc0 MSB0byBzYXkgdGhhdCBmb3IgbGlzdHMsIGFsbCBrZXlzIE1VU1QgYmUgcHJlc2VudCBhbmQgYXJl Cj4gdXNlZCB0byBzZWxlY3Qgb25lIGVudHJ5LCBhbmQgZm9yIGxlYWYtbGlzdCB0aGUgdmFsdWUg aXMgdXNlZCB0bwo+IHNlbGVjdCBvbmUgZW50cnkuCj4gCj4gQW4gYWx0ZXJuYXRpdmUgd2hpY2gg c29sdmVzIHRoaXMgcHJvYmxlbSwgY291bGQgYmUgdGhhdCB3aGVuIHRoZQo+IG9wZXJhdGlvbiBp cyAiZGVsZXRlIiwgdGhlbiBFSVRIRVIgdGhlIGtleXMvdmFsdWUgYXJlIHByZXNlbnQgYXMgWE1M Cj4gZWxlbWVudHMsIE9SIGFuIFhNTCBhdHRyaWJ1dGUgInNjb3BlPSdhbGwnIiAob3Igc29tZXRo aW5nIHNpbWlsYXIpIGlzCj4gcHJlc2VudDoKPiAKPiAgICAgICAgIDxkb21haW4tc2VhcmNoIG5j Om9wZXJhdGlvbj0iZGVsZXRlIiB5YW5nOnNjb3BlPSJhbGwiLz4KPiAgICAgICAgIDxkb21haW4t c2VhcmNoPmZvby5jb208L2RvbWFpbi1zZWFyY2g+Cj4gICAgICAgICA8ZG9tYWluLXNlYXJjaD5i YXIuY29tPC9kb21haW4tc2VhcmNoPgo+IAo+IAo+IC9tYXJ0aW4KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPiBu ZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWls aW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Sep 22 06:04:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB9A3A696A; Mon, 22 Sep 2008 06:04:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59E33A696A for ; Mon, 22 Sep 2008 06:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6F2F5Z8T2sA for ; Mon, 22 Sep 2008 06:04:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B546F3A6836 for ; Mon, 22 Sep 2008 06:04:38 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DC0C7209A7; Mon, 22 Sep 2008 15:04:37 +0200 (CEST) X-AuditID: c1b4fb3c-af0d0bb0000015b5-f6-48d797e5235c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C6CC620781; Mon, 22 Sep 2008 15:04:37 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 15:04:37 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 15:04:37 +0200 Message-ID: <48D79811.9030109@ericsson.com> Date: Mon, 22 Sep 2008 15:05:21 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20080922.103953.69288811.mbj@tail-f.com> In-Reply-To: <20080922.103953.69288811.mbj@tail-f.com> X-OriginalArrivalTime: 22 Sep 2008 13:04:37.0305 (UTC) FILETIME=[C4312A90:01C91CB3] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, Martin Bjorklund wrote: > Hi, > > Given this list > > list interface { > key "name"; > leaf name { > type string; > } > list address { > key "ip"; > leaf ip { > type yang:ip-address; > } > leaf broadcast { > type yang:ip-address; > } > } > } > > I think it would make sense for a client to replace all addresses on a > paticular interface with an edit-config like this: > > > > > > > > eth0 >
>
> 10.0.0.1 >
>
> 172.0.0.1 >
> > > > > I.e. by specifying "delete" on a list node, but not giving any keys, > all list entries are deleted. BALAZS: IMHO there is no such thing as a "list" in the data model, there are just a set of list entries. So
is just an incorrectly specified list entry, which should result in an error response. This is a by-product of YANG not cleanly separating a list and a list entry. For what you want I would rather introduce some kind of wildcard for the key. It would be a cleaner structure then adding little attributes to NETCONF.
This achieves the same thing, but we still handle a series of entries and do not have to introduce operations on the non-existing "list" entity itself. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 22 06:12: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 38DD83A6AD1; Mon, 22 Sep 2008 06:12:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312D93A6A77 for ; Mon, 22 Sep 2008 06:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[AWL=0.465, 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 lXACch7HWGjP for ; Mon, 22 Sep 2008 06:12:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C0BD03A688C for ; Mon, 22 Sep 2008 06:12:49 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 392DFD800C0; Mon, 22 Sep 2008 15:12:50 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080922.140643.144876265.mbj@tail-f.com> References: <20080922.140643.144876265.mbj@tail-f.com> Organization: CESNET Date: Mon, 22 Sep 2008 15:12:50 +0200 Message-Id: <1222089170.6243.148.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAyMi4gMDkuIDIwMDggdiAxNDowNiArMDIwMDoK PiAKPiBTaW5jZSB0aGUgcHJvdG9jb2wgaXMgZGF0YSBtb2RlbCBhZ25vc3RpYywgaXQgaGFzIHRv IGJlIHByZXR0eSB2YWd1ZQo+IGluIHRhbGtpbmcgYWJvdXQga2V5cyBldGMuCgpUaGVuIGl0IHNo b3VsZCBoYXZlIGF2b2lkZWQgImRlZmluaW5nIiB0aGUgZWRpdC1jb25maWcgb3BlcmF0aW9ucywg YW5kCnBlcmhhcHMgdGhlIHN1YnRyZWUgZmlsdGVycywgdG9vLgoKPiAKPiBJdCBpcyBpbXBvcnRh bnQgdGhvdWdoIHRoYXQgdGhlIFlBTkcgc3BlY2lmaWNhdGlvbiBpcyB2ZXJ5IGNsZWFyIGhvdwo+ IGVkaXQtY29uZmlnIHdvcmtzIHdpdGggZGF0YSBtb2RlbHMgZGVmaW5lZCBpbiBZQU5HLgo+IAo+ IAo+ID4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgdGhhdCBS RkMgNDc0MSBkb2VzIGRlZmluZQo+ID4gY2FuIGludGVyZmVyZSB3aXRoIFlBTkcgc2VtYW50aWNz IGluIHZhcmlvdXMgdWdseSB3YXlzLgo+IAo+IENhbiB5b3UgZ2l2ZSBhbiBleGFtcGxlPwoKMS4K Cmxpc3QgZm9vIHsga2V5ICJjbGVmIHNjaGx1ZXNzZWwiOyAuLi4gfQoKPGZvbz4KICAgIDxjbGVm IG5jOm9wZXJhdGlvbjoicmVwbGFjZSI+bmV3a2V5PC9jbGVmPgo8L2Zvbz4KCkRvZXMgaXQgcmVw bGFjZSB0aGUgJ2NsZWYnIHBhcnQgb2YgdGhlIGtleSBpbiBhbGwgbGlzdCBpdGVtcz8KCjIuCgps ZWFmLWxpc3QgYmF6IHsgdHlwZSBzdHJpbmc7IH0KCjxiYXogbmM6b3BlcmF0aW9uPSJyZXBsYWNl Ij5zb21ldmFsdWU8L2Jhej4KCkhvdyBjYW4gdGhpcyBiZSBpbnRlcnByZXRlZD8KClRoZSBnZW5l cmFsIHByb2JsZW0gaXMgdGhhdCB0aGUgc2VsZWN0aW9uIHN0ZXAgaXMgbWl4ZWQgd2l0aCB0aGUg YWN0aW9uCnN0ZXAuIFRoZXkgc2hvdWxkIGJlIHNlcGFyYXRlLgoKTGFkYQoKICAKPiAKPiAKPiAv bWFydGluCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1h aWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Sep 22 07: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 789C03A69E8; Mon, 22 Sep 2008 07:04:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973CC3A69E8 for ; Mon, 22 Sep 2008 07:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=0.310, 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 VPrME6pIlPwA for ; Mon, 22 Sep 2008 07:04:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AB5203A6B5E for ; Mon, 22 Sep 2008 07:04:28 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 234DED800C0; Mon, 22 Sep 2008 16:04:25 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <48D79811.9030109@ericsson.com> References: <20080922.103953.69288811.mbj@tail-f.com> <48D79811.9030109@ericsson.com> Organization: CESNET Date: Mon, 22 Sep 2008 16:04:25 +0200 Message-Id: <1222092265.6243.156.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgUG8gMjIuIDA5LiAyMDA4IHYgMTU6MDUgKzAyMDA6Cgo+ ID4gCj4gPiAgIDxlZGl0LWNvbmZpZz4KPiA+ICAgICA8dGFyZ2V0Pgo+ID4gICAgICAgPHJ1bm5p bmcvPgo+ID4gICAgIDwvdGFyZ2V0Pgo+ID4gICAgIDxjb25maWc+Cj4gPiAgICAgICA8aW50ZXJm YWNlIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vaW50ZXJmYWNlIj4KPiA+ICAgICAgICAgPG5h bWU+ZXRoMDwvbmFtZT4KPiA+ICAgICAgICAgPGFkZHJlc3MgbmM6b3BlcmF0aW9uPSJkZWxldGUi Lz4KPiA+ICAgICAgICAgPGFkZHJlc3M+Cj4gPiAgICAgICAgICAgPGlwPjEwLjAuMC4xPC9pcD4K PiA+ICAgICAgICAgPC9hZGRyZXNzPgo+ID4gICAgICAgICA8YWRkcmVzcz4KPiA+ICAgICAgICAg ICA8aXA+MTcyLjAuMC4xPC9pcD4KPiA+ICAgICAgICAgPC9hZGRyZXNzPgo+ID4gICAgICAgPC9p bnRlcmZhY2U+Cj4gPiAgICAgPC9jb25maWc+Cj4gPiAgIDwvZWRpdC1jb25maWc+Cj4gPiAKPiA+ IEkuZS4gYnkgc3BlY2lmeWluZyAiZGVsZXRlIiBvbiBhIGxpc3Qgbm9kZSwgYnV0IG5vdCBnaXZp bmcgYW55IGtleXMsCj4gPiBhbGwgbGlzdCBlbnRyaWVzIGFyZSBkZWxldGVkLgo+IEJBTEFaUzog SU1ITyB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzICBhICJsaXN0IiBpbiB0aGUgZGF0YSBtb2Rl bCwgdGhlcmUgYXJlIGp1c3QgYSBzZXQgb2YgCj4gbGlzdCBlbnRyaWVzLiBTbyA8YWRkcmVzcyBu YzpvcGVyYXRpb249ImRlbGV0ZSIvPiBpcyBqdXN0IGFuIGluY29ycmVjdGx5IHNwZWNpZmllZCBs aXN0IGVudHJ5LCAKCldoeSBpcyBpdCBpbmNvcnJlY3Q/IFRoZSAiYWRkcmVzcyIgZWxlbWVudCBp cyByZWFsLgoKTGFkYQoKPiB3aGljaCBzaG91bGQgcmVzdWx0IGluIGFuIGVycm9yIHJlc3BvbnNl LiBUaGlzIGlzIGEgYnktcHJvZHVjdCBvZiBZQU5HIG5vdCBjbGVhbmx5IHNlcGFyYXRpbmcgYSAK PiBsaXN0IGFuZCBhIGxpc3QgZW50cnkuCj4gRm9yIHdoYXQgeW91IHdhbnQgSSB3b3VsZCByYXRo ZXIgaW50cm9kdWNlIHNvbWUga2luZCBvZiB3aWxkY2FyZCBmb3IgdGhlIGtleS4gSXQgd291bGQg YmUgYSAKPiBjbGVhbmVyIHN0cnVjdHVyZSB0aGVuIGFkZGluZyBsaXR0bGUgYXR0cmlidXRlcyB0 byBORVRDT05GLgo+IDxhZGRyZXNzIG5jOm9wZXJhdGlvbj0iZGVsZXRlIj4KPiAgICA8bmFtZSB5 YW5nOndpbGRjYXJkPSJ0cnVlIi8+Cj4gPC9hZGRyZXNzPgo+IAo+IFRoaXMgYWNoaWV2ZXMgdGhl IHNhbWUgdGhpbmcsIGJ1dCB3ZSBzdGlsbCBoYW5kbGUgYSBzZXJpZXMgb2YgZW50cmllcyBhbmQg ZG8gbm90IGhhdmUgdG8gCj4gaW50cm9kdWNlIG9wZXJhdGlvbnMgb24gdGhlIG5vbi1leGlzdGlu ZyAibGlzdCIgZW50aXR5IGl0c2VsZi4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcK PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAotLSAKTGFkaXNs YXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9k QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Sep 22 08:06: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 23AD63A697A; Mon, 22 Sep 2008 08:06:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918F53A6A4A for ; Mon, 22 Sep 2008 08:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYaDzHs2oSJT for ; Mon, 22 Sep 2008 08:06:07 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D367B3A6BAA for ; Mon, 22 Sep 2008 08:05:17 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BD36C20BB5; Mon, 22 Sep 2008 17:04:38 +0200 (CEST) X-AuditID: c1b4fb3c-b00d2bb0000015b5-3d-48d7b4068491 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 93F7620AF4; Mon, 22 Sep 2008 17:04:38 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 17:03:54 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 17:03:53 +0200 Message-ID: <48D7B406.1000305@ericsson.com> Date: Mon, 22 Sep 2008 17:04:38 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <20080922.103953.69288811.mbj@tail-f.com> <48D79811.9030109@ericsson.com> <1222092265.6243.156.camel@missotis> In-Reply-To: <1222092265.6243.156.camel@missotis> X-OriginalArrivalTime: 22 Sep 2008 15:03:54.0057 (UTC) FILETIME=[6DF2DB90:01C91CC4] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org 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 SGVsbG8gTGFkYSwKVGhlIG9yaWdpbmFsIG1vZGVsIHdhcwogICBsaXN0IGludGVyZmFjZSB7CiAg ICAgICBrZXkgIm5hbWUiOwogICAgICAgbGVhZiBuYW1lIHsKICAgICAgICAgICB0eXBlIHN0cmlu ZzsKICAgICAgIH0KICAgICAgIGxpc3QgYWRkcmVzcyB7CiAgICAgICAgICAga2V5ICJpcCI7CiAg ICAgICAgICAgbGVhZiBpcCB7CiAgICAgICAgICAgICAgIHR5cGUgeWFuZzppcC1hZGRyZXNzOwog ICAgICAgICAgIH0KICAgICAgICAgICBsZWFmIGJyb2FkY2FzdCB7CiAgICAgICAgICAgICAgIHR5 cGUgeWFuZzppcC1hZGRyZXNzOwogICAgICAgICAgIH0KICAgICAgIH0KICAgfQoKU28gdG8gcG9p bnQgdG8gYW4gImFkZHJlc3MiIGl0ZW0geW91IGhhdmUgdG8gc3BlY2lmeSBpdCdzIGtleSAoaXAp LiBXaXRob3V0IHRoYXQgSSB3b3VsZCBhc3N1bWUgCiAgIHRoZSBleHByZXNzaW9uIGlzIGluY29y cmVjdC4gV2UgbmV2ZXIgc3RvcmUgYW4gZW1wdHkgYWRkcmVzcywgaW4gdGhlIGRhdGFzdG9yZSBp dCBhbHdheXMgaGFzIAphIGtleSAoaXApLiBBRkFJSyBpbiBYcGF0aCA8YWRkcmVzcy8+IHdvdWxk IHNlbGVjdCBhbGwgbm9kZXMsIGJ1dCBkbyB3ZSB3YW50IHRvIGFsbG93IHN1Y2ggClhQYXRoLWxp a2UgYWRkcmVzc2luZyBvZiB0aGUgbWFuYWdlZCBpdGVtcz8gV2UgbmV2ZXIgc2FkIHRoYXQgdGls bCBub3csIHNvIEkgd291bGQga2VlcCBpdCAKc2ltcGxlLiBJZiB5b3Ugd2FudCBzb21ldGhpbmcg YWRkcmVzcyBpdCB3aXRoIGl0J3Mga2V5LgpBdCBsZWFzdCB0aGF0IGlzIG15IHZpZXcsIGJ1dCB0 aGlzIGlzIHNvbWV0aGluZyB0aGF0IHRoZSBZQU5HIGRyYWZ0IHNob3VsZCBjZXJ0YWlubHkgZGVz Y3JpYmUhCkJhbGF6cwoKTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEJhbGF6cyBMZW5neWVsIHDD rcWhZSB2IFBvIDIyLiAwOS4gMjAwOCB2IDE1OjA1ICswMjAwOgo+IAo+Pj4gICA8ZWRpdC1jb25m aWc+Cj4+PiAgICAgPHRhcmdldD4KPj4+ICAgICAgIDxydW5uaW5nLz4KPj4+ICAgICA8L3Rhcmdl dD4KPj4+ICAgICA8Y29uZmlnPgo+Pj4gICAgICAgPGludGVyZmFjZSB4bWxucz0iaHR0cDovL2V4 YW1wbGUuY29tL2ludGVyZmFjZSI+Cj4+PiAgICAgICAgIDxuYW1lPmV0aDA8L25hbWU+Cj4+PiAg ICAgICAgIDxhZGRyZXNzIG5jOm9wZXJhdGlvbj0iZGVsZXRlIi8+Cj4+PiAgICAgICAgIDxhZGRy ZXNzPgo+Pj4gICAgICAgICAgIDxpcD4xMC4wLjAuMTwvaXA+Cj4+PiAgICAgICAgIDwvYWRkcmVz cz4KPj4+ICAgICAgICAgPGFkZHJlc3M+Cj4+PiAgICAgICAgICAgPGlwPjE3Mi4wLjAuMTwvaXA+ Cj4+PiAgICAgICAgIDwvYWRkcmVzcz4KPj4+ICAgICAgIDwvaW50ZXJmYWNlPgo+Pj4gICAgIDwv Y29uZmlnPgo+Pj4gICA8L2VkaXQtY29uZmlnPgo+Pj4KPj4+IEkuZS4gYnkgc3BlY2lmeWluZyAi ZGVsZXRlIiBvbiBhIGxpc3Qgbm9kZSwgYnV0IG5vdCBnaXZpbmcgYW55IGtleXMsCj4+PiBhbGwg bGlzdCBlbnRyaWVzIGFyZSBkZWxldGVkLgo+PiBCQUxBWlM6IElNSE8gdGhlcmUgaXMgbm8gc3Vj aCB0aGluZyBhcyAgYSAibGlzdCIgaW4gdGhlIGRhdGEgbW9kZWwsIHRoZXJlIGFyZSBqdXN0IGEg c2V0IG9mIAo+PiBsaXN0IGVudHJpZXMuIFNvIDxhZGRyZXNzIG5jOm9wZXJhdGlvbj0iZGVsZXRl Ii8+IGlzIGp1c3QgYW4gaW5jb3JyZWN0bHkgc3BlY2lmaWVkIGxpc3QgZW50cnksIAo+IAo+IFdo eSBpcyBpdCBpbmNvcnJlY3Q/IFRoZSAiYWRkcmVzcyIgZWxlbWVudCBpcyByZWFsLgo+IAo+IExh ZGEKPiAKPj4gd2hpY2ggc2hvdWxkIHJlc3VsdCBpbiBhbiBlcnJvciByZXNwb25zZS4gVGhpcyBp cyBhIGJ5LXByb2R1Y3Qgb2YgWUFORyBub3QgY2xlYW5seSBzZXBhcmF0aW5nIGEgCj4+IGxpc3Qg YW5kIGEgbGlzdCBlbnRyeS4KPj4gRm9yIHdoYXQgeW91IHdhbnQgSSB3b3VsZCByYXRoZXIgaW50 cm9kdWNlIHNvbWUga2luZCBvZiB3aWxkY2FyZCBmb3IgdGhlIGtleS4gSXQgd291bGQgYmUgYSAK Pj4gY2xlYW5lciBzdHJ1Y3R1cmUgdGhlbiBhZGRpbmcgbGl0dGxlIGF0dHJpYnV0ZXMgdG8gTkVU Q09ORi4KPj4gPGFkZHJlc3MgbmM6b3BlcmF0aW9uPSJkZWxldGUiPgo+PiAgICA8bmFtZSB5YW5n OndpbGRjYXJkPSJ0cnVlIi8+Cj4+IDwvYWRkcmVzcz4KPj4KPj4gVGhpcyBhY2hpZXZlcyB0aGUg c2FtZSB0aGluZywgYnV0IHdlIHN0aWxsIGhhbmRsZSBhIHNlcmllcyBvZiBlbnRyaWVzIGFuZCBk byBub3QgaGF2ZSB0byAKPj4gaW50cm9kdWNlIG9wZXJhdGlvbnMgb24gdGhlIG5vbi1leGlzdGlu ZyAibGlzdCIgZW50aXR5IGl0c2VsZi4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+PiBuZXRtb2RAaWV0Zi5v cmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5n IGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Sep 22 08:08: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 ECFA73A69E8; Mon, 22 Sep 2008 08:08:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DB128C130; Fri, 19 Sep 2008 06:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 dz6yfy67JCOV; Fri, 19 Sep 2008 06:45:45 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E6A7D3A6AC8; Fri, 19 Sep 2008 06:45:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,429,1217822400"; d="scan'208";a="144274844" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 19 Sep 2008 09:45:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 19 Sep 2008 09:45:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 15:45:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail Problems Thread-Index: AckaXfJaz1KltMUORmq3BbOwrj8wBQ== From: "Romascanu, Dan (Dan)" To: undisclosed-recipients:; X-Mailman-Approved-At: Mon, 22 Sep 2008 08:08:38 -0700 Subject: [netmod] Mail Problems X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org My company mail servers were in trouble for about thirteen hours starting around 7PM ET yesterday 9/18. All mails sent to me during this time got lost. If you believe that you sent me something important during this time please resend. Thanks and Regards, Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 22 08:08: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 079CA3A6A78; Mon, 22 Sep 2008 08:08:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC00F3A6802; Fri, 19 Sep 2008 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 i3Fkqwvn+g7h; Fri, 19 Sep 2008 07:15:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id F3AAB3A6862; Fri, 19 Sep 2008 07:14:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,429,1217822400"; d="scan'208";a="122286925" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Sep 2008 10:14:55 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 19 Sep 2008 10:14:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 16:14:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail Problems Thread-Index: AckaXfJaz1KltMUORmq3BbOwrj8wBQ== From: "Romascanu, Dan (Dan)" To: "IESG" , "IAB" , , "ops-area (IETF)" , , , , , , "IETF DNS Directorate" , , , "MIB Doctors (E-mail)" , X-Mailman-Approved-At: Mon, 22 Sep 2008 08:08:38 -0700 Subject: [netmod] Mail Problems X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org My company mail servers were in trouble for about thirteen hours starting around 7PM ET yesterday 9/18. All mails sent to me during this time got lost. If you believe that you sent me something important during this time please resend. Thanks and Regards, Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 22 13:28: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 5EBB43A67D2; Mon, 22 Sep 2008 13:28:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7DC3A67D2 for ; Mon, 22 Sep 2008 13:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=0.372, 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 AVcKsErzp7Xu for ; Mon, 22 Sep 2008 13:28:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B7ADB3A69D0 for ; Mon, 22 Sep 2008 13:28:38 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 27E39D800BD; Mon, 22 Sep 2008 22:28:40 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <48D7B406.1000305@ericsson.com> References: <20080922.103953.69288811.mbj@tail-f.com> <48D79811.9030109@ericsson.com> <1222092265.6243.156.camel@missotis> <48D7B406.1000305@ericsson.com> Organization: CESNET Date: Mon, 22 Sep 2008 22:28:42 +0200 Message-Id: <1222115322.32313.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgUG8gMjIuIDA5LiAyMDA4IHYgMTc6MDQgKzAyMDA6Cgo+ IFNvIHRvIHBvaW50IHRvIGFuICJhZGRyZXNzIiBpdGVtIHlvdSBoYXZlIHRvIHNwZWNpZnkgaXQn cyBrZXkgKGlwKS4gV2l0aG91dCB0aGF0IEkgd291bGQgYXNzdW1lIAo+ICAgIHRoZSBleHByZXNz aW9uIGlzIGluY29ycmVjdC4gV2UgbmV2ZXIgc3RvcmUgYW4gZW1wdHkgYWRkcmVzcywgaW4gdGhl IGRhdGFzdG9yZSBpdCBhbHdheXMgaGFzIAo+IGEga2V5IChpcCkuIEFGQUlLIGluIFhwYXRoIDxh ZGRyZXNzLz4gd291bGQgc2VsZWN0IGFsbCBub2RlcywgYnV0IGRvIHdlIHdhbnQgdG8gYWxsb3cg c3VjaCAKPiBYUGF0aC1saWtlIGFkZHJlc3Npbmcgb2YgdGhlIG1hbmFnZWQgaXRlbXM/IFdlIG5l dmVyIHNhZCB0aGF0IHRpbGwgbm93LCBzbyBJIHdvdWxkIGtlZXAgaXQgCj4gc2ltcGxlLiBJZiB5 b3Ugd2FudCBzb21ldGhpbmcgYWRkcmVzcyBpdCB3aXRoIGl0J3Mga2V5LgoKVGhlIGFwcHJvYWNo IG9mIFJGQyA1MjYxIGxvb2tzIGJldHRlciAodGhvdWdoIEkgaGF2ZW4ndCByZWFkIGl0IHZlcnkK Y2FyZWZ1bGx5IHlldCkuIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgZmVhciBvZiBYUGF0aCwgaXQg c2hvdWxkbid0IGJlIGEKdGVycmlibGUgcHJvYmxlbSBmb3IgYW55IGFnZW50IHRvIGltcGxlbWVu dCBpdC4gVGhlc2UgInNpbXBsZSIKYXBwcm9hY2hlcyBzZWVtIHRvIGxlYWQgdG8gaW5jb25zaXN0 ZW5jaWVzLgoKPiBBdCBsZWFzdCB0aGF0IGlzIG15IHZpZXcsIGJ1dCB0aGlzIGlzIHNvbWV0aGlu ZyB0aGF0IHRoZSBZQU5HIGRyYWZ0IHNob3VsZCBjZXJ0YWlubHkgZGVzY3JpYmUhCgpZZXMsIHN1 Y2ggcnVsZXMgc2hvdWxkIGJlIHNwZWNpZmllZCBpbiB0aGUgWUFORyBkcmFmdCwgYnV0IHNpbmNl IHRoZQplZGl0LWNvbmZpZyBvcGVyYXRpb25zIGFyZSBpbnRyb2R1Y2VkIGluIFJGQyA0NzQxLCBv bmUgd291bGQgYXNzdW1lIHRoYXQKdGhleSBhcmUgaW5kZXBlbmRlbnQgb2YgWUFORy4gT3RoZXJ3 aXNlIGl0IGNhbiBlYXNpbHkgaGFwcGVuIHRoYXQgdGhlCm9wZXJhdGlvbnMgaGF2ZSBkaWZmZXJl bnQgc2VtYW50aWNzIGluIGRpZmZlcmVudCBETSBsYW5ndWFnZXMuCgpMYWRhCgotLSAKTGFkaXNs YXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9k QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Tue Sep 23 05:21:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265BB3A69D8; Tue, 23 Sep 2008 05:21:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0793A696C for ; Tue, 23 Sep 2008 05:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0K4qbhp+6BX for ; Tue, 23 Sep 2008 05:21:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DA4EC28C1C9 for ; Tue, 23 Sep 2008 05:21:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8NCLABk024935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 14:21:10 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8NCL9Qj022051; Tue, 23 Sep 2008 14:21:09 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Sep 2008 14:21:09 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Sep 2008 14:21:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 15:21:02 +0300 Message-ID: <84028E2C0BD7D44F8308A6E7FF659CDB633EBF@FIESEXC015.nsn-intra.net> In-Reply-To: <48D3A4CC.2090906@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: AckaWSAN9Q5fc9zRQXiwU3J/apqhVwDHRvxg References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <48D3A4CC.2090906@netconfcentral.com> From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: , "ext Andy Bierman" X-OriginalArrivalTime: 23 Sep 2008 12:21:06.0720 (UTC) FILETIME=[DA934200:01C91D76] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080923142110-322E4BB0-1A45DA83/0-0/0-15 X-purgate-size: 5761/0 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman andy@netconfcentral.com wrote: > > The YANG namespace issue is trivial, and not the real problem. I agree with you. The aim is to make the augmentation of groupings as simple as possible. So I think using the same namespace for groupings and data nodes, is an unambiguous solution for addressing groupings in augment statements. > As mentioned by several people, this is not how OO works > for derived classes. I do not think YANG should be OO at all, > but if I did, I would want to follow the class hierarchy model. > I think augmentable groupings and OO are different things. I agree that OO features should be better based on complex types or class hierarchies. We should talk on this in the interim meeting if there is interest. BR, Bernd > Specifically, you should create a new class with a new name > if you want to add some new data to an existing class. > This allows all instances of the old class to continue > working as instances of the new class are also created. > > Andy > > > >> -----Original Message----- > >> From: Linowski Bernd (EXT-Other - DE/Dusseldorf) > >> Sent: 15 August, 2008 17:43 > >> To: netmod@ietf.org; ext Andy Bierman > >> Subject: RE: [netmod] Augmentable Groupings > >> > >> > >> Hi, > >> > >> Andy Bierman andy@netconfcentral.com wrote: > >>> -----Original Message----- > >>> From: ext Andy Bierman [mailto:andy@netconfcentral.com] > >>> Sent: 13 August, 2008 17:18 > >>> To: Linowski Bernd (EXT-Other - DE/Dusseldorf) > >>> Cc: netmod@ietf.org > >>> Subject: Re: [netmod] Augmentable Groupings > >>> > >>> bernd.linowski.ext@nsn.com wrote: > >>>> Hi, > >>>> > >>>> Andy Bierman andy@netconfcentral.com wrote: > >>>> > Actually groupings are not in the same namespace as objects, > >>>> > so this Xpath is broken. > >>>> > > >>>> > > >>>> > grouping foo; > >>>> > > >>>> > container foo; > >>>> > > >>>> > Both of these are legal YANG. > >>>> > >>>> That is not in line what is stated in section 7.11 of the > >>>> YANG specification: > >>>> " If the grouping is defined at the top level of a YANG module or > >>>> submodule, the grouping's identifier MUST be unique within the > >>>> module." > >>>> Name "foo" is not unqiue within the module. > >>>> > >>> Here is the text from the draft: > >>> > >>> 6.2.1. Identifiers and their namespaces > >>> > >>> .... > >>> > >>> o All groupings defined within a parent node or at the > >>> top-level of > >>> the module or its submodules share the same grouping > >> identifier > >>> namespace. This namespace is scoped to the parent > >>> node or module. > >>> > >>> .... > >>> > >>> All identifiers defined in a namespace MUST be unique. > >>> > >> I agree, there could be an ambiguity as there is a > separate grouping > >> identifier namespace. > >> > >> Let me reconsider the options how to address this. > >> > > > > In order to address this issue, I suggest that groupings > > are put in the same namespace as data nodes, rpc's and > > notifications. > > As mentioned in an earlier mail from Andy Bierman, collapsing > > the grouping namespace into the object namespace is in > > practice no problem. Since YANG identifiers are case sensitive > > unique naming of objects still remains easy. > > Other advantages of this solution are that a new statement > > is not needed and that namespace handling is simplified. > > > > > > In summary, introducing augmentable groupings means: > > > > - A grouping can be the target (node) of > > an augment statement. > > - Augmentation of a grouping becomes only > > effective in case the module containing > > the augment statement is advertized. > > - The nodes added to the grouping are therefore > > implicitly added to all places the grouping > > is used in the set of modules supported > > by an agent. > > - The augmented nodes are in the XML namespace > > of the module of the augment statement. > > - Groupings share the same namespace with > > data nodes, rpc's and notification in order > > to address them unambiguously in an augment > > statement. > > - In general, it is not allowed to augment > > mandatory nodes to a grouping. > > > > > > I think augmentable groupings are a powerful tool, which has > > different advantages for optimizing reuse but should only be > > utilized if appropriate. > > > > BR, > > Bernd > > > > > > > >>> > >>>> > > >>>> > If I nest the groupings, then what happens to the augment: > >>>> > > >>>> > module C { > >>>> > > >>>> > grouping new-concepts { > >>>> > uses concepts; > >>>> > } > >>>> > > >>>> > Does new-concepts contain the augmentations from concepts? > >>>> > > >>>> > >>>> Yes. > >>>> > >>> > >>> Yes, well this makes it an NP-complete problem to resolve all the > >>> uses statements in all the modules. > >>> > >>> Even if that did not matter (just implementation!), the NETCONF > >>> vendors have to deal with a pool of modules for which > >>> they have no change control whatsoever. And what about their own > >>> modules already out there in shipping code? > >>> > >>> This 'write once, and it shows up everywhere' feature is not > >>> actually usable in the operational environment that YANG > >> must address. > >>> > >>> Andy > >> > >> > >> > >> > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 23 07:20: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 3F68028C215; Tue, 23 Sep 2008 07:20:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E6828C21A for ; Tue, 23 Sep 2008 07:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y504K73GoqFi for ; Tue, 23 Sep 2008 07:20:26 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id F29AE28C215 for ; Tue, 23 Sep 2008 07:20:25 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA19732; Tue, 23 Sep 2008 10:20:29 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA19400; Tue, 23 Sep 2008 10:20:28 -0400 (EDT) Message-Id: <200809231420.KAA19400@adminfs.snmp.com> To: Ladislav Lhotka From: David Reid In-reply-to: Your message of Mon, 22 Sep 2008 15:12:50 +0200. <1222089170.6243.148.camel@missotis> Date: Tue, 23 Sep 2008 10:20:28 -0400 Cc: netmod@ietf.org Subject: Re: [netmod] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > 1. > > list foo { key "clef schluessel"; ... } > > > newkey > > > Does it replace the 'clef' part of the key in all list items? Does the XML encoding of a list entry have to include all of the keys? I thought that the above example would be invalid since the key schluessel is not specified. Am I missing something? > > 2. > > leaf-list baz { type string; } > > somevalue > > How can this be interpreted? > > The general problem is that the selection step is mixed with the action > step. They should be separate. I would expect this example also to generate an error based on section 7.7.6: Leaf-list entries can be created and deleted, but not modified, through , by using the "operation" attribute in the leaf-list entry's XML element. When the spec says "created and deleted, but not modified", does that mean I can do a netconf create or delete operation but not a netconf merge or replace operation on a leaf-list? -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 23 08:18: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 2553A3A67CC; Tue, 23 Sep 2008 08:18:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6513A67AF for ; Tue, 23 Sep 2008 08:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN9bRyeyDz0A for ; Tue, 23 Sep 2008 08:18:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id A00493A6A3C for ; Tue, 23 Sep 2008 08:18:29 -0700 (PDT) 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 m8NFIVTh002768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Sep 2008 17:18:31 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8NFIU0q001796; Tue, 23 Sep 2008 17:18:31 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Sep 2008 17:18:31 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Sep 2008 17:18:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 18:18:28 +0300 Message-ID: <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> In-Reply-To: <20080919183240.GA1601@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: AckahiDhC/QbMzURTN+UObzDrtnwiAC8efvA References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: , X-OriginalArrivalTime: 23 Sep 2008 15:18:30.0479 (UTC) FILETIME=[A2BFFDF0:01C91D8F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080923171831-322EABB0-B4BC1173/0-0/0-15 X-purgate-size: 2204/0 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Juergen Schoenwaelder (schoenwaelder@jacobs-university.de) wrote: > > In summary, introducing augmentable groupings means: > > > > - A grouping can be the target (node) of > > an augment statement. > > - Augmentation of a grouping becomes only > > effective in case the module containing > > the augment statement is advertized. > > What does "advertized" mean? The namespace URI of the module that contains the augment statement is advertized as a capability in the NETCONF hello-message. >If you have the NETCONF hello exchange in > mind, then I believe this is broken as long as we assume modular > implementations where some parts of the data model use the augmented > grouping while others do not. If that is the case, you have to "bite the bullet" and augment all the places one by one where the additions make sense. Imo, an augmenting module should only be advertized if the augmentations of groupings and data nodes it contains make sense in all other advertized modules. > > > - The nodes added to the grouping are therefore > > implicitly added to all places the grouping > > is used in the set of modules supported > > by an agent. > > See above, I doubt this works in general. > > [...] > > > I think augmentable groupings are a powerful tool, which has > > different advantages for optimizing reuse but should only be > > utilized if appropriate. > > I think it would help us if someone can (a) spell out the "different > advantages", (b) how augmentable groupings "optimize reuse", and (c) > when it is "appropriate" to utilize them and when not. The interesting add-on of augmentable groupings is that the new elements are available wherever the grouping is used. An appropriate usage of the augmentable groupings is given imo if the augmented grouping is defined and used with "augmentation in mind". BR, Bernd > > /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 Sep 23 09:14: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 1E7E43A67CC; Tue, 23 Sep 2008 09:14:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB6528C175 for ; Tue, 23 Sep 2008 09:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g8ov5MkJdx2 for ; Tue, 23 Sep 2008 09:14:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4292C3A6975 for ; Tue, 23 Sep 2008 09:14:12 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BCBE720AB1; Tue, 23 Sep 2008 18:14:14 +0200 (CEST) X-AuditID: c1b4fb3c-af8d1bb0000015b5-84-48d915d6db41 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C9B0203BD; Tue, 23 Sep 2008 18:14:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Sep 2008 18:14:14 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Sep 2008 18:14:13 +0200 Message-ID: <48D91606.60206@ericsson.com> Date: Tue, 23 Sep 2008 18:15:02 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> X-OriginalArrivalTime: 23 Sep 2008 16:14:14.0048 (UTC) FILETIME=[6BAC2200:01C91D97] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > > The interesting add-on of augmentable groupings is that the new > elements are available wherever the grouping is used. > An appropriate usage of the augmentable groupings is given imo > if the augmented grouping is defined and used with > "augmentation in mind". > "Defining with augmentation in mind" For me this means that groupings should be explicitly marked as augmentable, so users can be prepared for augmentation. This also has the advantage that simple (non-marked) groupings are not augmentable, so you don't have to consider the any unintended complications. grouping interfaceAttributes { augmentable true; // default would be false leafs, other content ... } Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 23 09:24:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EB63A69AA; Tue, 23 Sep 2008 09:24:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E231A3A69AA for ; Tue, 23 Sep 2008 09:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WnKGtd6r9lX for ; Tue, 23 Sep 2008 09:24:05 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 1248B3A6936 for ; Tue, 23 Sep 2008 09:24:05 -0700 (PDT) Received: (qmail 34177 invoked from network); 23 Sep 2008 16:24:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.153 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 23 Sep 2008 16:24:04 -0000 X-YMail-OSG: _ZBYwPwVM1l32a_FM0V8rTvOqboWmraY7k7XgeHVODAJ1G0JyMvWZHQyDNxUg3zPVsgSc_cn0O3QCZUmlSFAvJ6IsPpjgSGtyJn18fYgb63KlM1_Wx9j89Hycful8Y6ucSAigNdk8XGLaSi8yCvokze9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48D91822.9040105@netconfcentral.com> Date: Tue, 23 Sep 2008 09:24:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <48D3A4CC.2090906@netconfcentral.com> <84028E2C0BD7D44F8308A6E7FF659CDB633EBF@FIESEXC015.nsn-intra.net> In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB633EBF@FIESEXC015.nsn-intra.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > Hi, > > Andy Bierman andy@netconfcentral.com wrote: >> The YANG namespace issue is trivial, and not the real problem. > > I agree with you. > > The aim is to make the augmentation of groupings as simple as possible. > So I think using the same namespace for groupings and data nodes, > is an unambiguous solution for addressing groupings in augment > statements. > > >> As mentioned by several people, this is not how OO works >> for derived classes. I do not think YANG should be OO at all, >> but if I did, I would want to follow the class hierarchy model. >> > > I think augmentable groupings and OO are different things. > I agree that OO features should be better based on complex types > or class hierarchies. > We should talk on this in the interim meeting if there is interest. > I think we have discussed augmentable groupings enough. I would like to see the issue closed by the WG co-Chairs. YANG is not OO, so class hierarchies are out of scope. YANG needs to be used in multi-publisher environments, and a mechanism that extends any arbitrary grouping in arbitrary module cannot be properly controlled and restricted. IMO, it is not implementable either, since an entire set of modules must be processed 'as if simultaneously'. (We know how well that worked out for SNMP Set ;-) It is not consistent with the modular architecture of YANG, since there is no indication whatsoever within module 'foo' that it is being extended and modified by module 'bar'. In every instance, the DM reader (or compiler) can determine the exact contents of any data structure, from explicit information within the 'starting module'. You can follow imports and includes in a deterministic manner. This is not the case with augmented groupings. > > BR, > Bernd Andy > >> Specifically, you should create a new class with a new name >> if you want to add some new data to an existing class. >> This allows all instances of the old class to continue >> working as instances of the new class are also created. >> >> Andy >>>> -----Original Message----- >>>> From: Linowski Bernd (EXT-Other - DE/Dusseldorf) >>>> Sent: 15 August, 2008 17:43 >>>> To: netmod@ietf.org; ext Andy Bierman >>>> Subject: RE: [netmod] Augmentable Groupings >>>> >>>> >>>> Hi, >>>> >>>> Andy Bierman andy@netconfcentral.com wrote: >>>>> -----Original Message----- >>>>> From: ext Andy Bierman [mailto:andy@netconfcentral.com] >>>>> Sent: 13 August, 2008 17:18 >>>>> To: Linowski Bernd (EXT-Other - DE/Dusseldorf) >>>>> Cc: netmod@ietf.org >>>>> Subject: Re: [netmod] Augmentable Groupings >>>>> >>>>> bernd.linowski.ext@nsn.com wrote: >>>>>> Hi, >>>>>> >>>>>> Andy Bierman andy@netconfcentral.com wrote: >>>>>> > Actually groupings are not in the same namespace as objects, >>>>>> > so this Xpath is broken. >>>>>> > >>>>>> > >>>>>> > grouping foo; >>>>>> > >>>>>> > container foo; >>>>>> > >>>>>> > Both of these are legal YANG. >>>>>> >>>>>> That is not in line what is stated in section 7.11 of the >>>>>> YANG specification: >>>>>> " If the grouping is defined at the top level of a YANG module or >>>>>> submodule, the grouping's identifier MUST be unique within the >>>>>> module." >>>>>> Name "foo" is not unqiue within the module. >>>>>> >>>>> Here is the text from the draft: >>>>> >>>>> 6.2.1. Identifiers and their namespaces >>>>> >>>>> .... >>>>> >>>>> o All groupings defined within a parent node or at the >>>>> top-level of >>>>> the module or its submodules share the same grouping >>>> identifier >>>>> namespace. This namespace is scoped to the parent >>>>> node or module. >>>>> >>>>> .... >>>>> >>>>> All identifiers defined in a namespace MUST be unique. >>>>> >>>> I agree, there could be an ambiguity as there is a >> separate grouping >>>> identifier namespace. >>>> >>>> Let me reconsider the options how to address this. >>>> >>> In order to address this issue, I suggest that groupings >>> are put in the same namespace as data nodes, rpc's and >>> notifications. >>> As mentioned in an earlier mail from Andy Bierman, collapsing >>> the grouping namespace into the object namespace is in >>> practice no problem. Since YANG identifiers are case sensitive >>> unique naming of objects still remains easy. >>> Other advantages of this solution are that a new statement >>> is not needed and that namespace handling is simplified. >>> >>> >>> In summary, introducing augmentable groupings means: >>> >>> - A grouping can be the target (node) of >>> an augment statement. >>> - Augmentation of a grouping becomes only >>> effective in case the module containing >>> the augment statement is advertized. >>> - The nodes added to the grouping are therefore >>> implicitly added to all places the grouping >>> is used in the set of modules supported >>> by an agent. >>> - The augmented nodes are in the XML namespace >>> of the module of the augment statement. >>> - Groupings share the same namespace with >>> data nodes, rpc's and notification in order >>> to address them unambiguously in an augment >>> statement. >>> - In general, it is not allowed to augment >>> mandatory nodes to a grouping. >>> >>> >>> I think augmentable groupings are a powerful tool, which has >>> different advantages for optimizing reuse but should only be >>> utilized if appropriate. >>> >>> BR, >>> Bernd >>> >>> >>> >>>>>> > >>>>>> > If I nest the groupings, then what happens to the augment: >>>>>> > >>>>>> > module C { >>>>>> > >>>>>> > grouping new-concepts { >>>>>> > uses concepts; >>>>>> > } >>>>>> > >>>>>> > Does new-concepts contain the augmentations from concepts? >>>>>> > >>>>>> >>>>>> Yes. >>>>>> >>>>> Yes, well this makes it an NP-complete problem to resolve all the >>>>> uses statements in all the modules. >>>>> >>>>> Even if that did not matter (just implementation!), the NETCONF >>>>> vendors have to deal with a pool of modules for which >>>>> they have no change control whatsoever. And what about their own >>>>> modules already out there in shipping code? >>>>> >>>>> This 'write once, and it shows up everywhere' feature is not >>>>> actually usable in the operational environment that YANG >>>> must address. >>>>> Andy >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> >> >> > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 23 09:33:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525213A6CD5; Tue, 23 Sep 2008 09:33:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30963A6CD5 for ; Tue, 23 Sep 2008 09:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=0.310, 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 cIVPJPCRqTha for ; Tue, 23 Sep 2008 09:33:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3A0DD3A6C1D for ; Tue, 23 Sep 2008 09:33:09 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 36C91D800C0; Tue, 23 Sep 2008 18:33:12 +0200 (CEST) From: Ladislav Lhotka To: David Reid In-Reply-To: <200809231420.KAA19400@adminfs.snmp.com> References: <200809231420.KAA19400@adminfs.snmp.com> Organization: CESNET Date: Tue, 23 Sep 2008 18:33:12 +0200 Message-Id: <1222187592.6242.61.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 RGF2aWQgUmVpZCBww63FoWUgdiDDmnQgMjMuIDA5LiAyMDA4IHYgMTA6MjAgLTA0MDA6Cj4gPiAx Lgo+ID4gCj4gPiBsaXN0IGZvbyB7IGtleSAiY2xlZiBzY2hsdWVzc2VsIjsgLi4uIH0KPiA+IAo+ ID4gPGZvbz4KPiA+ICAgICA8Y2xlZiBuYzpvcGVyYXRpb246InJlcGxhY2UiPm5ld2tleTwvY2xl Zj4KPiA+IDwvZm9vPgo+ID4gCj4gPiBEb2VzIGl0IHJlcGxhY2UgdGhlICdjbGVmJyBwYXJ0IG9m IHRoZSBrZXkgaW4gYWxsIGxpc3QgaXRlbXM/Cj4gCj4gRG9lcyB0aGUgWE1MIGVuY29kaW5nIG9m IGEgbGlzdCBlbnRyeSBoYXZlIHRvIGluY2x1ZGUgYWxsIG9mIHRoZSBrZXlzPwo+IEkgdGhvdWdo dCB0aGF0IHRoZSBhYm92ZSBleGFtcGxlIHdvdWxkIGJlIGludmFsaWQgc2luY2UgdGhlIGtleSBz Y2hsdWVzc2VsCj4gaXMgbm90IHNwZWNpZmllZC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8KCk5v LCB5b3UgYXJlIHJpZ2h0LCB0aGlzIGlzIHdoYXQgU2VjLiA3LjguNiBzYXlzLiBUaGUgZWRpdC1j b25maWcKb3BlcmF0aW9ucyAoaW5jbHVkaW5nIGRlZmF1bHQtb3BlcmF0aW9uKSBwcm9iYWJseSBt dXN0IG5vdCBiZSBhcHBsaWVkIHRvCmtleXMgaW4gYW55IHdheS4gQnV0IGl0IGFsc28gbWVhbnMg dGhlcmUgaXMgbm8gd2F5IGZvciBjaGFuZ2luZyB2YWx1ZXMKb2YgbGVhZnMgdGhhdCBoYXBwZW4g dG8gYmUgcGFydCBvZiB0aGUga2V5LgoKPiAKPiA+IAo+ID4gMi4KPiA+IAo+ID4gbGVhZi1saXN0 IGJheiB7IHR5cGUgc3RyaW5nOyB9Cj4gPiAKPiA+IDxiYXogbmM6b3BlcmF0aW9uPSJyZXBsYWNl Ij5zb21ldmFsdWU8L2Jhej4KPiA+IAo+ID4gSG93IGNhbiB0aGlzIGJlIGludGVycHJldGVkPwo+ ID4gCj4gPiBUaGUgZ2VuZXJhbCBwcm9ibGVtIGlzIHRoYXQgdGhlIHNlbGVjdGlvbiBzdGVwIGlz IG1peGVkIHdpdGggdGhlIGFjdGlvbgo+ID4gc3RlcC4gVGhleSBzaG91bGQgYmUgc2VwYXJhdGUu Cj4gCj4gSSB3b3VsZCBleHBlY3QgdGhpcyBleGFtcGxlIGFsc28gdG8gZ2VuZXJhdGUgYW4gZXJy b3IgYmFzZWQgb24gc2VjdGlvbiA3LjcuNjoKPiAKPiAgICBMZWFmLWxpc3QgZW50cmllcyBjYW4g YmUgY3JlYXRlZCBhbmQgZGVsZXRlZCwgYnV0IG5vdCBtb2RpZmllZCwKPiAgICB0aHJvdWdoIDxl ZGl0LWNvbmZpZz4sIGJ5IHVzaW5nIHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgaW4gdGhlCj4g ICAgbGVhZi1saXN0IGVudHJ5J3MgWE1MIGVsZW1lbnQuCj4gCj4gV2hlbiB0aGUgc3BlYyBzYXlz ICJjcmVhdGVkIGFuZCBkZWxldGVkLCBidXQgbm90IG1vZGlmaWVkIiwgZG9lcyB0aGF0IG1lYW4g SSAKPiBjYW4gZG8gYSBuZXRjb25mIGNyZWF0ZSBvciBkZWxldGUgb3BlcmF0aW9uIGJ1dCBub3Qg YSBuZXRjb25mIG1lcmdlIG9yIHJlcGxhY2UgCj4gb3BlcmF0aW9uIG9uIGEgbGVhZi1saXN0PwoK RnVydGhlciBpbiBTZWMuIDcuNy42OiAnSWYgdGhlIG9wZXJhdGlvbiBpcyAibWVyZ2UiIG9yICJy ZXBsYWNlIiB0aGUKbGVhZi1saXN0IGVudHJ5IGlzIGNyZWF0ZWQgaWYgaXQgZG9lcyBub3QgZXhp c3QuJyBJdCBpcyBub3QgY2xlYXIgdGhvdWdoCndoZXRoZXIgaXQgaXMgYW4gZXJyb3Igb3Igbm90 IGlmIHRoZSBlbnRyeSBleGlzdHMuIEZvciAiY3JlYXRlIiBpdCBoYXMKdG8gYmUgYW4gZXJyb3Ig YWNjb3JkaW5nIHRvIFJGQyA0NzQxLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVU ClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Sep 23 11:32:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804223A68A6; Tue, 23 Sep 2008 11:32:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B243A6975 for ; Tue, 23 Sep 2008 11:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.310, 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 NxTeibHyrQ9J for ; Tue, 23 Sep 2008 11:32:09 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 442143A6781 for ; Tue, 23 Sep 2008 11:32:09 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id E39FA616001; Tue, 23 Sep 2008 20:32:11 +0200 (CEST) Date: Tue, 23 Sep 2008 20:33:43 +0200 (CEST) Message-Id: <20080923.203343.258277597.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200809231420.KAA19400@adminfs.snmp.com> References: <1222089170.6243.148.camel@missotis> <200809231420.KAA19400@adminfs.snmp.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] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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: > > 2. > > > > leaf-list baz { type string; } > > > > somevalue > > > > How can this be interpreted? > > > > The general problem is that the selection step is mixed with the action > > step. They should be separate. > > I would expect this example also to generate an error based on section 7.7.6: > > Leaf-list entries can be created and deleted, but not modified, > through , by using the "operation" attribute in the > leaf-list entry's XML element. > > When the spec says "created and deleted, but not modified", does that mean I > can do a netconf create or delete operation but not a netconf merge or replace > operation on a leaf-list? No. You can do replace and merge, as specified later in that section. But remember that a leaf-list entry has just one value, and each entry is identified by its value. So if we have a leaf-list: a c what would it mean to modify the entry "c"? If you change its value to say "b", the entry is now identified as "b". There is no way you can, in one edit-config operation, change the value of "c" to "b". You would have to delete "c" and create "b". /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 23 11:34: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 7F01F3A68A6; Tue, 23 Sep 2008 11:34:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681CF3A695E for ; Tue, 23 Sep 2008 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.232, 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 NnIKaoLYlRZc for ; Tue, 23 Sep 2008 11:34:33 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A67733A68A6 for ; Tue, 23 Sep 2008 11:34:33 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E17D616001; Tue, 23 Sep 2008 20:34:37 +0200 (CEST) Date: Tue, 23 Sep 2008 20:36:07 +0200 (CEST) Message-Id: <20080923.203607.198714918.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1222187592.6242.61.camel@missotis> References: <200809231420.KAA19400@adminfs.snmp.com> <1222187592.6242.61.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Further in Sec. 7.7.6: 'If the operation is "merge" or "replace" the > leaf-list entry is created if it does not exist.' It is not clear though > whether it is an error or not if the entry exists. For "create" it has > to be an error according to RFC 4741. Right, and "merge" or "replace" on an existing entry in an ordered-by system leaf-list, but the entry might be moved in an ordered-by user leaf-list. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 23 13:26:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E498A28C205; Tue, 23 Sep 2008 13:26:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD5628C235 for ; Tue, 23 Sep 2008 13:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 a3ddRNiB-uhY for ; Tue, 23 Sep 2008 13:26:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 978CE28C205 for ; Tue, 23 Sep 2008 13:26:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6554C0008; Tue, 23 Sep 2008 22:26:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iLsE8CJ2F3Nh; Tue, 23 Sep 2008 22:26:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52457C0004; Tue, 23 Sep 2008 22:26:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD8AF7B601B; Tue, 23 Sep 2008 22:26:47 +0200 (CEST) Date: Tue, 23 Sep 2008 22:26:47 +0200 From: Juergen Schoenwaelder To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" Message-ID: <20080923202647.GB10970@elstar.local> Mail-Followup-To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Sep 23, 2008 at 06:18:28PM +0300, Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > An appropriate usage of the augmentable groupings is given imo if > the augmented grouping is defined and used with "augmentation in > mind". This sounds like magic to me or a circular argument or hand-waving or a combination of all of this. If we can't write things down in clear technical terms, then how can we expect that people use it right? /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 Sep 23 13:30: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 A71B028C222; Tue, 23 Sep 2008 13:30:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C9528C25C for ; Tue, 23 Sep 2008 13:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 5jguYKbOD0YG for ; Tue, 23 Sep 2008 13:30:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 88EE328C25A for ; Tue, 23 Sep 2008 13:30:45 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83EBFC0008; Tue, 23 Sep 2008 22:30:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MpSfQHEdnL5r; Tue, 23 Sep 2008 22:30:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8259AC0004; Tue, 23 Sep 2008 22:30:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C07947B6055; Tue, 23 Sep 2008 22:30:42 +0200 (CEST) Date: Tue, 23 Sep 2008 22:30:42 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080923203042.GC10970@elstar.local> Mail-Followup-To: Balazs Lengyel , "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48D91606.60206@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Sep 23, 2008 at 06:15:02PM +0200, Balazs Lengyel wrote: > "Defining with augmentation in mind" > > For me this means that groupings should be explicitly marked as > augmentable, so users can be prepared for augmentation. This also has the > advantage that simple (non-marked) groupings are not augmentable, so you > don't have to consider the any unintended complications. > > grouping interfaceAttributes { > augmentable true; // default would be false > leafs, other content > ... > } But the underlying question then remains: How does a model writer determine whether the augmentable bit of a grouping should be on or off? And if the augmentable bit is on, all the other questions remain the same - adding a knob does not answer any of those questions... /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 Sep 23 23:47: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 E86813A68EE; Tue, 23 Sep 2008 23:47:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4EB3A6B79 for ; Tue, 23 Sep 2008 23:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_20=-0.74, 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 sa4g1vjBVPJs for ; Tue, 23 Sep 2008 23:47:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 676EE3A68EE for ; Tue, 23 Sep 2008 23:47:43 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 3FEB3D800C0 for ; Wed, 24 Sep 2008 08:47:48 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 24 Sep 2008 08:47:47 +0200 Message-Id: <1222238867.6253.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, related to the discussion of edit-config behaviour on lists and leaf-list is the following question: Is the equality of list keys or leaf-list items decided in the value or lexical space? The correct answer is probably "value space" but this could be problematic for types that do not define what equality in value space means. An example are IP addresses: how do we know that '::1' is the same as '::0:1' if the ipv6-address type is defined just using regular expressions? 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 Sep 23 23:59:12 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BFC03A6D3F; Tue, 23 Sep 2008 23:59:12 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB563A6D40 for ; Tue, 23 Sep 2008 23:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.349, 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 LO7Rd6duhGLG for ; Tue, 23 Sep 2008 23:59:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1F8753A6D3F for ; Tue, 23 Sep 2008 23:59:11 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 70FC5D800BD; Wed, 24 Sep 2008 08:59:16 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080923.203607.198714918.mbj@tail-f.com> References: <200809231420.KAA19400@adminfs.snmp.com> <1222187592.6242.61.camel@missotis> <20080923.203607.198714918.mbj@tail-f.com> Organization: CESNET Date: Wed, 24 Sep 2008 08:59:15 +0200 Message-Id: <1222239555.6253.19.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDDmnQgMjMuIDA5LiAyMDA4IHYgMjA6MzYgKzAyMDA6 Cj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToKPiA+IEZ1cnRoZXIg aW4gU2VjLiA3LjcuNjogJ0lmIHRoZSBvcGVyYXRpb24gaXMgIm1lcmdlIiBvciAicmVwbGFjZSIg dGhlCj4gPiBsZWFmLWxpc3QgZW50cnkgaXMgY3JlYXRlZCBpZiBpdCBkb2VzIG5vdCBleGlzdC4n IEl0IGlzIG5vdCBjbGVhciB0aG91Z2gKPiA+IHdoZXRoZXIgaXQgaXMgYW4gZXJyb3Igb3Igbm90 IGlmIHRoZSBlbnRyeSBleGlzdHMuIEZvciAiY3JlYXRlIiBpdCBoYXMKPiA+IHRvIGJlIGFuIGVy cm9yIGFjY29yZGluZyB0byBSRkMgNDc0MS4KPiAKPiBSaWdodCwgYW5kICJtZXJnZSIgb3IgInJl cGxhY2UiIG9uIGFuIGV4aXN0aW5nIGVudHJ5IGluIGFuIG9yZGVyZWQtYnkKPiBzeXN0ZW0gbGVh Zi1saXN0LCBidXQgdGhlIGVudHJ5IG1pZ2h0IGJlIG1vdmVkIGluIGFuIG9yZGVyZWQtYnkgdXNl cgo+IGxlYWYtbGlzdC4KClNvIGl0IGlzIGEgTk9PUCBpZiAibmM6bWVyZ2UiIG9yICJuYzpyZXBs YWNlIiBpcyB1c2VkIHdpdGhvdXQKInlhbmc6aW5zZXJ0IiBhbmQgInlhbmc6dmFsdWUiIGF0dHJp YnV0ZXMgZm9yIGxlYWYtbGlzdHMgb3JkZXJlZCBieSBib3RoCnVzZXIgYW5kIHN5c3RlbT8KCkxh ZGEKCj4gCj4gCj4gL21hcnRpbgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJ RDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Sep 24 00:08: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 0B5533A680B; Wed, 24 Sep 2008 00:08:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C163A6D44 for ; Wed, 24 Sep 2008 00:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjX16-u3JdTl for ; Wed, 24 Sep 2008 00:08:49 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6C1AB3A6992 for ; Wed, 24 Sep 2008 00:08:49 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C7F9376C4DD; Wed, 24 Sep 2008 09:08:53 +0200 (CEST) Date: Wed, 24 Sep 2008 09:11:00 +0200 (CEST) Message-Id: <20080924.091100.130804951.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1222239555.6253.19.camel@missotis> References: <1222187592.6242.61.camel@missotis> <20080923.203607.198714918.mbj@tail-f.com> <1222239555.6253.19.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] edit-config semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMjMuIDA5LiAyMDA4IHYgMjA6MzYgKzAyMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IEZ1cnRoZXIgaW4gU2Vj LiA3LjcuNjogJ0lmIHRoZSBvcGVyYXRpb24gaXMgIm1lcmdlIiBvciAicmVwbGFjZSIgdGhlDQo+ ID4gPiBsZWFmLWxpc3QgZW50cnkgaXMgY3JlYXRlZCBpZiBpdCBkb2VzIG5vdCBleGlzdC4nIEl0 IGlzIG5vdCBjbGVhciB0aG91Z2gNCj4gPiA+IHdoZXRoZXIgaXQgaXMgYW4gZXJyb3Igb3Igbm90 IGlmIHRoZSBlbnRyeSBleGlzdHMuIEZvciAiY3JlYXRlIiBpdCBoYXMNCj4gPiA+IHRvIGJlIGFu IGVycm9yIGFjY29yZGluZyB0byBSRkMgNDc0MS4NCj4gPiANCj4gPiBSaWdodCwgYW5kICJtZXJn ZSIgb3IgInJlcGxhY2UiIG9uIGFuIGV4aXN0aW5nIGVudHJ5IGluIGFuIG9yZGVyZWQtYnkNCj4g PiBzeXN0ZW0gbGVhZi1saXN0LCBidXQgdGhlIGVudHJ5IG1pZ2h0IGJlIG1vdmVkIGluIGFuIG9y ZGVyZWQtYnkgdXNlcg0KPiA+IGxlYWYtbGlzdC4NCj4gDQo+IFNvIGl0IGlzIGEgTk9PUCBpZiAi bmM6bWVyZ2UiIG9yICJuYzpyZXBsYWNlIiBpcyB1c2VkIHdpdGhvdXQNCj4gInlhbmc6aW5zZXJ0 IiBhbmQgInlhbmc6dmFsdWUiIGF0dHJpYnV0ZXMgZm9yIGxlYWYtbGlzdHMgb3JkZXJlZCBieSBi b3RoDQo+IHVzZXIgYW5kIHN5c3RlbT8NCg0KWWVzLCBpdCBpcyBub29wIGlmIHRoZSBlbnRyeSBl eGlzdHMuICBUaGUgc3BlYyBhbHJlYWR5IHNheXMgdGhhdCB0aGUNCmVudHJ5IGlzIGNyZWF0ZWQg aWYgaXQgZG9lcyBub3QgZXhpc3QuDQoNCg0KL21hcnRpbg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Sep 24 00:11: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 939A13A6D51; Wed, 24 Sep 2008 00:11:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84DE3A6992 for ; Wed, 24 Sep 2008 00:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 OJRDjGlOm3BJ for ; Wed, 24 Sep 2008 00:11:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 716983A6D51 for ; Wed, 24 Sep 2008 00:11:11 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29D8AC0002; Wed, 24 Sep 2008 09:11:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NlsQQl46lM6Q; Wed, 24 Sep 2008 09:11:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 366DEC0003; Wed, 24 Sep 2008 09:11:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE6F07B64AE; Wed, 24 Sep 2008 09:11:04 +0200 (CEST) Date: Wed, 24 Sep 2008 09:11:04 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080924071104.GA11402@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1222238867.6253.10.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1222238867.6253.10.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 24, 2008 at 08:47:47AM +0200, Ladislav Lhotka wrote: > Hi, > > related to the discussion of edit-config behaviour on lists and > leaf-list is the following question: Is the equality of list keys or > leaf-list items decided in the value or lexical space? The correct > answer is probably "value space" but this could be problematic for types > that do not define what equality in value space means. An example are IP > addresses: how do we know that '::1' is the same as '::0:1' if the > ipv6-address type is defined just using regular expressions? There is hopefully a description statement explaining that this is an IPv6 address. In my view, a pattern augments a description but does not replace it. A pattern may allow for multiple lexical representations of the same value - and perhaps this needs to be spelled out with a recommendation that in such cases the description clause needs to define what the canonical representation is and whether conversions are allowed, that is whether an implementation has to maintain '::0:1' as supplied by the user or it can convert silently to '::1'. Perhaps this also scares people away from allowing multiple representations of the same value in the first place... /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 Wed Sep 24 00:36: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 5C1333A6D42; Wed, 24 Sep 2008 00:36:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C2A3A6D45 for ; Wed, 24 Sep 2008 00:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSFSbh1SLK5j for ; Wed, 24 Sep 2008 00:35:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E84DC3A6D3C for ; Wed, 24 Sep 2008 00:35:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 37F1520E44; Wed, 24 Sep 2008 09:36:02 +0200 (CEST) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-b9-48d9ede231cb Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 189CB20B1B; Wed, 24 Sep 2008 09:36:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 09:36:00 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 09:36:00 +0200 Message-ID: <48D9EE13.8080307@ericsson.com> Date: Wed, 24 Sep 2008 09:36:51 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka , NETMOD Working Group References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> In-Reply-To: <20080924071104.GA11402@elstar.local> X-OriginalArrivalTime: 24 Sep 2008 07:36:00.0618 (UTC) FILETIME=[30F4FCA0:01C91E18] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org In my naive view when you define something as an IPv6 address you don't just mean it conforms to a pattern. It really means it is an IPv6 address meaning that if a router would consider two addresses equivalent then they are the same (independent of how many zeros are abbreviated). So for me you don't even need a description, just by saying type inet:ipv6address; you sad it all. I strongly believe that the equality must be in the value space. The node might not even know which exact lexical format the address was in in Netconf. Comparing in the lexical space would force the node to store the string format of the IPv6 address as well, additional hassle. Imagine an IPv4 address that can be configured as a patterned string on Netconf, but on another interface as a simple int32. Comparing in the lexical space could mean that a value set as an int32 would never be equal to anything on Netconf. Comparing in lexical space would mean that 1.0 and 1.00 are different numbers. What problems do you foresee with comparing in value space? Do we need something about this in the draft? Maybe one general statement valid for all data types? Balazs Juergen Schoenwaelder wrote: > On Wed, Sep 24, 2008 at 08:47:47AM +0200, Ladislav Lhotka wrote: >> Hi, >> >> related to the discussion of edit-config behaviour on lists and >> leaf-list is the following question: Is the equality of list keys or >> leaf-list items decided in the value or lexical space? The correct >> answer is probably "value space" but this could be problematic for types >> that do not define what equality in value space means. An example are IP >> addresses: how do we know that '::1' is the same as '::0:1' if the >> ipv6-address type is defined just using regular expressions? > > There is hopefully a description statement explaining that this is an > IPv6 address. In my view, a pattern augments a description but does > not replace it. > > A pattern may allow for multiple lexical representations of the same > value - and perhaps this needs to be spelled out with a recommendation > that in such cases the description clause needs to define what the > canonical representation is and whether conversions are allowed, that > is whether an implementation has to maintain '::0:1' as supplied by > the user or it can convert silently to '::1'. Perhaps this also scares > people away from allowing multiple representations of the same value > in the first place... > > /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 Wed Sep 24 00:54:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AC03A6833; Wed, 24 Sep 2008 00:54:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25603A6833 for ; Wed, 24 Sep 2008 00:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=0.310, 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 PGVCGHnAJco7 for ; Wed, 24 Sep 2008 00:54:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 102943A6D61 for ; Wed, 24 Sep 2008 00:54:05 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2A7B1D800C0; Wed, 24 Sep 2008 09:54:01 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080924071104.GA11402@elstar.local> References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> Organization: CESNET Date: Wed, 24 Sep 2008 09:54:00 +0200 Message-Id: <1222242840.6253.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFN0IDI0LiAwOS4gMjAwOCB2IDA5OjExICsw MjAwOgo+IE9uIFdlZCwgU2VwIDI0LCAyMDA4IGF0IDA4OjQ3OjQ3QU0gKzAyMDAsIExhZGlzbGF2 IExob3RrYSB3cm90ZToKPiA+IEhpLAo+ID4gCj4gPiByZWxhdGVkIHRvIHRoZSBkaXNjdXNzaW9u IG9mIGVkaXQtY29uZmlnIGJlaGF2aW91ciBvbiBsaXN0cyBhbmQKPiA+IGxlYWYtbGlzdCBpcyB0 aGUgZm9sbG93aW5nIHF1ZXN0aW9uOiBJcyB0aGUgZXF1YWxpdHkgb2YgbGlzdCBrZXlzIG9yCj4g PiBsZWFmLWxpc3QgaXRlbXMgZGVjaWRlZCBpbiB0aGUgdmFsdWUgb3IgbGV4aWNhbCBzcGFjZT8g VGhlIGNvcnJlY3QKPiA+IGFuc3dlciBpcyBwcm9iYWJseSAidmFsdWUgc3BhY2UiIGJ1dCB0aGlz IGNvdWxkIGJlIHByb2JsZW1hdGljIGZvciB0eXBlcwo+ID4gdGhhdCBkbyBub3QgZGVmaW5lIHdo YXQgZXF1YWxpdHkgaW4gdmFsdWUgc3BhY2UgbWVhbnMuIEFuIGV4YW1wbGUgYXJlIElQCj4gPiBh ZGRyZXNzZXM6IGhvdyBkbyB3ZSBrbm93IHRoYXQgJzo6MScgaXMgdGhlIHNhbWUgYXMgJzo6MDox JyBpZiB0aGUKPiA+IGlwdjYtYWRkcmVzcyB0eXBlIGlzIGRlZmluZWQganVzdCB1c2luZyByZWd1 bGFyIGV4cHJlc3Npb25zPwo+IAo+IFRoZXJlIGlzIGhvcGVmdWxseSBhIGRlc2NyaXB0aW9uIHN0 YXRlbWVudCBleHBsYWluaW5nIHRoYXQgdGhpcyBpcyBhbgo+IElQdjYgYWRkcmVzcy4gSW4gbXkg dmlldywgYSBwYXR0ZXJuIGF1Z21lbnRzIGEgZGVzY3JpcHRpb24gYnV0IGRvZXMKPiBub3QgcmVw bGFjZSBpdC4KPiAKPiBBIHBhdHRlcm4gbWF5IGFsbG93IGZvciBtdWx0aXBsZSBsZXhpY2FsIHJl cHJlc2VudGF0aW9ucyBvZiB0aGUgc2FtZQo+IHZhbHVlIC0gYW5kIHBlcmhhcHMgdGhpcyBuZWVk cyB0byBiZSBzcGVsbGVkIG91dCB3aXRoIGEgcmVjb21tZW5kYXRpb24KPiB0aGF0IGluIHN1Y2gg Y2FzZXMgdGhlIGRlc2NyaXB0aW9uIGNsYXVzZSBuZWVkcyB0byBkZWZpbmUgd2hhdCB0aGUKPiBj YW5vbmljYWwgcmVwcmVzZW50YXRpb24gaXMgYW5kIHdoZXRoZXIgY29udmVyc2lvbnMgYXJlIGFs bG93ZWQsIHRoYXQKPiBpcyB3aGV0aGVyIGFuIGltcGxlbWVudGF0aW9uIGhhcyB0byBtYWludGFp biAnOjowOjEnIGFzIHN1cHBsaWVkIGJ5Cj4gdGhlIHVzZXIgb3IgaXQgY2FuIGNvbnZlcnQgc2ls ZW50bHkgdG8gJzo6MScuIFBlcmhhcHMgdGhpcyBhbHNvIHNjYXJlcwo+IHBlb3BsZSBhd2F5IGZy b20gYWxsb3dpbmcgbXVsdGlwbGUgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBzYW1lIHZhbHVlCj4g aW4gdGhlIGZpcnN0IHBsYWNlLi4uCgpTaW5jZSBZQU5HIG1vZHVsZXMgbWF5IHBvdGVudGlhbGx5 IHVzZSBtYW55IHNwZWNpZmljIGRhdGF0eXBlcywgd291bGRuJ3QKaXQgbWFrZSBzZW5zZSB0byBj b25zaWRlciBpbXBsZW1lbnRpbmcgYSBiZXR0ZXIgZGF0YXR5cGUgc3lzdGVtIGluIFlBTkc/ClBl cmhhcHMgc29tZXRoaW5nIHNpbWlsYXIgdG8gRFRMTDoKaHR0cDovL3d3dy5pZGVhbGxpYW5jZS5v cmcvcGFwZXJzL2V4dHJlbWUvcHJvY2VlZGluZ3MvaHRtbC8yMDA2L1Rlbm5pc29uMDEvRU1MMjAw NlRlbm5pc29uMDEuaHRtbAoKRFRMTCBoYW5kbGVzIHRoZSB2YWx1ZSBzcGFjZSBlcXVhbGl0eSwg YnV0IGFsc28gb3JkZXJpbmcgb2YgdmFsdWVzIGV0Yy4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90 a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5v cmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Sep 24 01:11: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 2ABB53A6A48; Wed, 24 Sep 2008 01:11:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA84F3A6A48 for ; Wed, 24 Sep 2008 01:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 xLHtAIlTFsc4 for ; Wed, 24 Sep 2008 01:11:10 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id CA3003A6D5E for ; Wed, 24 Sep 2008 01:11:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,299,1220241600"; d="scan'208";a="144802169" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 24 Sep 2008 04:11:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Sep 2008 04:11:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Sep 2008 10:11:05 +0200 Message-ID: In-Reply-To: <48D9EE13.8080307@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] equality of keys Thread-Index: AckeGEQ2Y8TPoylZReOG6vdl24pW7gABLS8A References: <1222238867.6253.10.camel@missotis><20080924071104.GA11402@elstar.local> <48D9EE13.8080307@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Ladislav Lhotka" , "NETMOD Working Group" Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 would add to this that relying on text in the description clauses means duplication and a possible source of errors. Dan > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Balazs Lengyel > Sent: Wednesday, September 24, 2008 10:37 AM > To: Ladislav Lhotka; NETMOD Working Group > Subject: Re: [netmod] equality of keys > > In my naive view when you define something as an IPv6 address > you don't just mean it conforms to a pattern. It really means > it is an IPv6 address meaning that if a router would consider > two addresses equivalent then they are the same (independent > of how many zeros are abbreviated). So for me you don't even > need a description, just by saying > > type inet:ipv6address; > > you sad it all. > > I strongly believe that the equality must be in the value > space. The node might not even know which exact lexical > format the address was in in Netconf. Comparing in the > lexical space would force the node to store the string format > of the IPv6 address as well, additional hassle. > > Imagine an IPv4 address that can be configured as a patterned > string on Netconf, but on another interface as a simple > int32. Comparing in the lexical space could mean that a value > set as an > int32 would never be equal to anything on Netconf. > > Comparing in lexical space would mean that 1.0 and 1.00 are > different numbers. > > What problems do you foresee with comparing in value space? > Do we need something about this in the draft? Maybe one > general statement valid for all data types? > > Balazs > > Juergen Schoenwaelder wrote: > > On Wed, Sep 24, 2008 at 08:47:47AM +0200, Ladislav Lhotka wrote: > >> Hi, > >> > >> related to the discussion of edit-config behaviour on lists and > >> leaf-list is the following question: Is the equality of > list keys or > >> leaf-list items decided in the value or lexical space? The correct > >> answer is probably "value space" but this could be problematic for > >> types that do not define what equality in value space means. An > >> example are IP > >> addresses: how do we know that '::1' is the same as '::0:1' if the > >> ipv6-address type is defined just using regular expressions? > > > > There is hopefully a description statement explaining that > this is an > > IPv6 address. In my view, a pattern augments a description but does > > not replace it. > > > > A pattern may allow for multiple lexical representations of > the same > > value - and perhaps this needs to be spelled out with a > recommendation > > that in such cases the description clause needs to define what the > > canonical representation is and whether conversions are > allowed, that > > is whether an implementation has to maintain '::0:1' as supplied by > > the user or it can convert silently to '::1'. Perhaps this > also scares > > people away from allowing multiple representations of the > same value > > in the first place... > > > > /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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 01:19: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 185E83A6D3A; Wed, 24 Sep 2008 01:19:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26AB3A6D3A for ; Wed, 24 Sep 2008 01:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeTzL2eSxiWc for ; Wed, 24 Sep 2008 01:19:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 04CA53A6A17 for ; Wed, 24 Sep 2008 01:19:17 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 3113DD800BD; Wed, 24 Sep 2008 10:19:22 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <48D9EE13.8080307@ericsson.com> References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> <48D9EE13.8080307@ericsson.com> Organization: CESNET Date: Wed, 24 Sep 2008 10:19:22 +0200 Message-Id: <1222244362.6253.60.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgU3QgMjQuIDA5LiAyMDA4IHYgMDk6MzYgKzAyMDA6Cj4g SW4gbXkgbmFpdmUgdmlldyB3aGVuIHlvdSBkZWZpbmUgc29tZXRoaW5nIGFzIGFuIElQdjYgYWRk cmVzcyB5b3UgZG9uJ3QganVzdCBtZWFuIGl0IGNvbmZvcm1zIAo+IHRvIGEgcGF0dGVybi4gSXQg cmVhbGx5IG1lYW5zIGl0IGlzIGFuIElQdjYgYWRkcmVzcyBtZWFuaW5nIHRoYXQgaWYgYSByb3V0 ZXIgd291bGQgY29uc2lkZXIgdHdvIAo+IGFkZHJlc3NlcyBlcXVpdmFsZW50IHRoZW4gdGhleSBh cmUgdGhlIHNhbWUgKGluZGVwZW5kZW50IG9mIGhvdyBtYW55IHplcm9zIGFyZSBhYmJyZXZpYXRl ZCkuIFNvIAo+IGZvciBtZSB5b3UgZG9uJ3QgZXZlbiBuZWVkIGEgZGVzY3JpcHRpb24sIGp1c3Qg Ynkgc2F5aW5nCj4gCj4gdHlwZSBpbmV0OmlwdjZhZGRyZXNzOwo+IAo+IHlvdSBzYWQgaXQgYWxs LgoKSWYgaXQgd2FzIHNvLCB0aGUgJ3R5cGVkZWYgaXB2Ni1hZGRyZXNzJyBjb3VsZCBjb250YWlu IG9ubHkgdGhlCmRlc2NyaXB0aW9uIHN0YXRlbWVudCBzYXlpbmcgdGhhdCBpdCBpcyBhbiBJUHY2 IGFkZHJlc3MuIEkgYmVsaWV2ZSBhCmZvcm1hbCBzcGVjaWZpY2F0aW9uIGlzIGltcG9ydGFudCwg ZXNwZWNpYWxseSBmb3IgbmV3IHR5cGVzIHRoYXQgYXJlIG5vdApzbyB1YmlxdWl0b3VzIGFzIElQ IGFkZHJlc3Nlcy4KIAo+IENvbXBhcmluZyBpbiBsZXhpY2FsIHNwYWNlIHdvdWxkIG1lYW4gdGhh dCAxLjAgYW5kIDEuMDAgYXJlIGRpZmZlcmVudCBudW1iZXJzLgoKVGhpcyBpcyBhIGJ1aWx0LWlu IHR5cGUsIHNvIGVxdWFsaXR5IGluIHZhbHVlIHNwYWNlIGlzIHdlbGwtZGVmaW5lZCBmb3IKaXQu IEl0IGlzIGEgcHJvYmxlbSBvZiBkZXJpdmVkIHR5cGVzIGRlZmluZWQgYnkgWUFORywgc3VjaCBh cyBJUAphZGRyZXNzZXMsIGRhdGUtYW5kLXRpbWUsIGNvdW50ZXIgZXRjLgoKPiAKPiBXaGF0IHBy b2JsZW1zIGRvIHlvdSBmb3Jlc2VlIHdpdGggY29tcGFyaW5nIGluIHZhbHVlIHNwYWNlPwoKVGhh dCB0aGUgY29uY2VwdHMgb2YgZXF1YWxpdHkgYW5kIG9yZGVyaW5nIGluIHRoZSB2YWx1ZSBzcGFj ZSBhbmQKbXVsdGlwbGUgcmVwcmVzZW50YXRpb25zIGNhbiBiZSBhZGRyZXNzZWQgb25seSBpbiBk ZXNjcmlwdGlvbnMuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJ RDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Sep 24 02:49: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 E876A3A6B0F; Wed, 24 Sep 2008 02:49:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A21B3A6B0F for ; Wed, 24 Sep 2008 02:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 DmgAgsXqrNln for ; Wed, 24 Sep 2008 02:49:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1C3563A6A6B for ; Wed, 24 Sep 2008 02:49:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D490C0048; Wed, 24 Sep 2008 11:49:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JiBhEBNjU-0t; Wed, 24 Sep 2008 11:49:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 951FEC0029; Wed, 24 Sep 2008 11:49:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1ABF97B67EA; Wed, 24 Sep 2008 11:49:33 +0200 (CEST) Date: Wed, 24 Sep 2008 11:49:33 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080924094933.GB11620@elstar.local> Mail-Followup-To: Balazs Lengyel , Ladislav Lhotka , NETMOD Working Group References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> <48D9EE13.8080307@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48D9EE13.8080307@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 24, 2008 at 09:36:51AM +0200, Balazs Lengyel wrote: > So for me you don't even need a description, just by saying > > type inet:ipv6address; > > you sad it all. Yes, but the definition of inet:ipv6address should still say that it is an IPv6 address. /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 Wed Sep 24 02:58:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019CE3A682A; Wed, 24 Sep 2008 02:58:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D004C3A6A6C for ; Wed, 24 Sep 2008 02:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 xWMK-aq9NDtT for ; Wed, 24 Sep 2008 02:58:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 95D5A3A682A for ; Wed, 24 Sep 2008 02:58:11 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04D99C0029; Wed, 24 Sep 2008 11:58:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pp28PX3s6hPJ; Wed, 24 Sep 2008 11:58:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA2F7C0002; Wed, 24 Sep 2008 11:58:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2D2137B687E; Wed, 24 Sep 2008 11:58:10 +0200 (CEST) Date: Wed, 24 Sep 2008 11:58:10 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080924095810.GA11771@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> <1222242840.6253.43.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1222242840.6253.43.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 24, 2008 at 09:54:00AM +0200, Ladislav Lhotka wrote: > Since YANG modules may potentially use many specific datatypes, > wouldn't it make sense to consider implementing a better datatype > system in YANG? Write up a concrete proposal and convince the working group that (a) there is a problem worth to be solved and (b) that the proposal is an appropriate solution for the problem worth to solve. Until this is done, I suggest we continue with what we have on the table and experience with. /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 Wed Sep 24 03:40: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 1980B28C214; Wed, 24 Sep 2008 03:40:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D97C28C235 for ; Wed, 24 Sep 2008 03:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asvXgoeDQy30 for ; Wed, 24 Sep 2008 03:40:34 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1B07228C23E for ; Wed, 24 Sep 2008 03:40:33 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 669A520D89; Wed, 24 Sep 2008 12:40:32 +0200 (CEST) X-AuditID: c1b4fb3c-af8d1bb0000015b5-d9-48da19203795 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4558320A0A; Wed, 24 Sep 2008 12:40:32 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 12:40:30 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 12:40:30 +0200 Message-ID: <48DA1951.2040500@ericsson.com> Date: Wed, 24 Sep 2008 12:41:21 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , Ladislav Lhotka , NETMOD Working Group References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> <48D9EE13.8080307@ericsson.com> <20080924094933.GB11620@elstar.local> In-Reply-To: <20080924094933.GB11620@elstar.local> X-OriginalArrivalTime: 24 Sep 2008 10:40:30.0337 (UTC) FILETIME=[F7060F10:01C91E31] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org 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 Wed, Sep 24, 2008 at 09:36:51AM +0200, Balazs Lengyel wrote: > >> So for me you don't even need a description, just by saying >> >> type inet:ipv6address; >> >> you sad it all. > > Yes, but the definition of inet:ipv6address should still say that it > is an IPv6 address. > Agreed. Also for datatypes that are not so well defined in external documents, longer descriptions will still be needed. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 04:49: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 40EC43A6B25; Wed, 24 Sep 2008 04:49:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7233A6D77 for ; Wed, 24 Sep 2008 04:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFr1yffzi4us for ; Wed, 24 Sep 2008 04:49:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E60B23A6B25 for ; Wed, 24 Sep 2008 04:49:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8OBnsMT022136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Sep 2008 13:49:54 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8OBnrRk017396; Wed, 24 Sep 2008 13:49:54 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Sep 2008 13:49:54 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Sep 2008 13:49:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Sep 2008 14:49:51 +0300 Message-ID: <84028E2C0BD7D44F8308A6E7FF659CDB634514@FIESEXC015.nsn-intra.net> In-Reply-To: <48D91606.60206@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: Ackdl26o2AYGdw43S9SiKtyfpPRKLgAo54MA References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: , "ext Balazs Lengyel" X-OriginalArrivalTime: 24 Sep 2008 11:49:53.0413 (UTC) FILETIME=[A8690B50:01C91E3B] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080924134954-728D2BB0-9757F4B2/0-0/0-15 X-purgate-size: 1835/0 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Balazs, Balazs Lengyel [balazs.lengyel@ericsson.com] wrote: > Sent: 23 September, 2008 18:15 > To: Linowski, Bernd (EXT-Other - DE/Dusseldorf) > Cc: netmod@ietf.org; j.schoenwaelder@jacobs-university.de > Subject: Re: [netmod] Augmentable Groupings > > > > > The interesting add-on of augmentable groupings is that the new > > elements are available wherever the grouping is used. > > An appropriate usage of the augmentable groupings is given imo > > if the augmented grouping is defined and used with > > "augmentation in mind". > > > "Defining with augmentation in mind" > > For me this means that groupings should be explicitly marked > as augmentable, so users can be > prepared for augmentation. Yes, that very much captures what I had in mind. I also think that making the intent explicit that a grouping may be augmented is useful. > This also has the advantage that > simple (non-marked) groupings are > not augmentable, so you don't have to consider the any > unintended complications. > I agree. And it ensures full backward compatibility with the current use of the augment statement. > grouping interfaceAttributes { > augmentable true; // default would be false > leafs, other content > ... > } > So in order to further refine the augmentable grouping feature, I propose - to add an "augmentable" keyword which takes a boolean value as its only argument and which may appear as sub-statement of grouping. - In case the argument value is "true", the grouping may be augmented - In case the argument value is "false", the grouping cannot be augmented. - The default is "false", so groupings without an augmentable statement cannot be augmented. BR, Bernd > Balazs > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 05:07: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 13A653A6D4A; Wed, 24 Sep 2008 05:07:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F396628C256 for ; Wed, 24 Sep 2008 05:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GLyEuMbeWu6l for ; Wed, 24 Sep 2008 05:07:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 97F103A6D76 for ; Wed, 24 Sep 2008 05:07:36 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A2A9C0008; Wed, 24 Sep 2008 14:07:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LhcV0WXSozz2; Wed, 24 Sep 2008 14:07:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 874EBC000C; Wed, 24 Sep 2008 14:07:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CCE117B7093; Wed, 24 Sep 2008 14:07:31 +0200 (CEST) Date: Wed, 24 Sep 2008 14:07:31 +0200 From: Juergen Schoenwaelder To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" Message-ID: <20080924120731.GB12257@elstar.local> Mail-Followup-To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org, ext Balazs Lengyel References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <84028E2C0BD7D44F8308A6E7FF659CDB634514@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB634514@FIESEXC015.nsn-intra.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 24, 2008 at 02:49:51PM +0300, Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > I agree. And it ensures full backward compatibility with the current > use of the augment statement. There is no official version of YANG out there we have to be backwards compatible to. > So in order to further refine the augmentable grouping feature, I > propose > - to add an "augmentable" keyword which takes a boolean value as > its only argument and which may appear as sub-statement of grouping. > - In case the argument value is "true", the grouping may be augmented > - In case the argument value is "false", the grouping cannot be > augmented. > - The default is "false", so groupings without an augmentable > statement > cannot be augmented. So now back to the discussion what an augmentable grouping means. Only when we precisely understand how an augmented grouping works can I understand whether a bit to turn this on/off is needed and when it should be turned on/off. /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 Wed Sep 24 05:50:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3AD3A6D8E; Wed, 24 Sep 2008 05:50:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFE93A6D8E for ; Wed, 24 Sep 2008 05:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSNMYTDraLBd for ; Wed, 24 Sep 2008 05:50:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EA3893A6D8C for ; Wed, 24 Sep 2008 05:50:04 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 363DD20BA0; Wed, 24 Sep 2008 14:49:58 +0200 (CEST) X-AuditID: c1b4fb3e-a7e83bb000007a96-26-48da376ea956 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3351C20FAD; Wed, 24 Sep 2008 14:49:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 14:49:28 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 14:49:28 +0200 Message-ID: <48DA378C.2070300@ericsson.com> Date: Wed, 24 Sep 2008 14:50:20 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> In-Reply-To: <20080923203042.GC10970@elstar.local> X-OriginalArrivalTime: 24 Sep 2008 12:49:28.0841 (UTC) FILETIME=[FB880F90:01C91E43] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, When I am defining my data models in some specific situations I already know that I intend a part to be augmented/extended. I also don't see why this is such a dangerous feature because: - you face most of the same problems with augmenting a lists or containers - the augmentable statement can totally protect standards - usually if a node implements and advertises "module augmentor" it will anyway consider all the risks. - you always have the fall back possibility augmentable false; and augment the individual uses of the grouping. - if you are not allowed to augment a grouping with mandatory stuff, all an agent has to do is throw away some extra stuff when it receives it Balazs Juergen Schoenwaelder wrote: > On Tue, Sep 23, 2008 at 06:15:02PM +0200, Balazs Lengyel wrote: > >> "Defining with augmentation in mind" >> >> For me this means that groupings should be explicitly marked as >> augmentable, so users can be prepared for augmentation. This also has the >> advantage that simple (non-marked) groupings are not augmentable, so you >> don't have to consider the any unintended complications. >> >> grouping interfaceAttributes { >> augmentable true; // default would be false >> leafs, other content >> ... >> } > > But the underlying question then remains: How does a model writer > determine whether the augmentable bit of a grouping should be on or > off? And if the augmentable bit is on, all the other questions remain > the same - adding a knob does not answer any of those questions... > > /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 Wed Sep 24 06:16:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AD53A6A53; Wed, 24 Sep 2008 06:16:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080723A6D50 for ; Wed, 24 Sep 2008 06:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaFChWkCpy8a for ; Wed, 24 Sep 2008 06:16:55 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2DA503A6A53 for ; Wed, 24 Sep 2008 06:16:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E371A76C4DD; Wed, 24 Sep 2008 15:16:24 +0200 (CEST) Date: Wed, 24 Sep 2008 15:18:33 +0200 (CEST) Message-Id: <20080924.151833.189502425.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48DA378C.2070300@ericsson.com> References: <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@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] 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 Balazs Lengyel wrote: > Hello, > When I am defining my data models in some specific situations I already know > that I intend a part to be augmented/extended. > > I also don't see why this is such a dangerous feature because: > - you face most of the same problems with augmenting a lists or containers There is one main problem with this proposal. It is summarized in one of the first emails on this topic: http://www.ietf.org/mail-archive/web/netmod/current/msg00784.html You do NOT have this problem with normal augment. Adding an 'augementable' flag does not solve this problem. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 06:51:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CAF3A6833; Wed, 24 Sep 2008 06:51:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485253A6DC7 for ; Wed, 24 Sep 2008 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=0.254, 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 5YF8FVPJTH+B for ; Wed, 24 Sep 2008 06:51:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7156F3A680B for ; Wed, 24 Sep 2008 06:51:57 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 701D1D800C5 for ; Wed, 24 Sep 2008 15:51:35 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080924.151833.189502425.mbj@tail-f.com> References: <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> <20080924.151833.189502425.mbj@tail-f.com> Organization: CESNET Date: Wed, 24 Sep 2008 15:51:35 +0200 Message-Id: <1222264295.6253.76.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyNC4gMDkuIDIwMDggdiAxNToxOCArMDIwMDoK PiBCYWxhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPiB3cm90ZToKPiA+ IEhlbGxvLAo+ID4gV2hlbiBJIGFtIGRlZmluaW5nIG15IGRhdGEgbW9kZWxzIGluIHNvbWUgc3Bl Y2lmaWMgc2l0dWF0aW9ucyBJIGFscmVhZHkga25vdwo+ID4gdGhhdCBJIGludGVuZCBhIHBhcnQg dG8gYmUgYXVnbWVudGVkL2V4dGVuZGVkLgo+ID4gCj4gPiBJIGFsc28gZG9uJ3Qgc2VlIHdoeSB0 aGlzIGlzIHN1Y2ggYSBkYW5nZXJvdXMgZmVhdHVyZSBiZWNhdXNlOgo+ID4gLSB5b3UgZmFjZSBt b3N0IG9mIHRoZSBzYW1lIHByb2JsZW1zIHdpdGggYXVnbWVudGluZyBhIGxpc3RzIG9yIGNvbnRh aW5lcnMKPiAKPiBUaGVyZSBpcyBvbmUgbWFpbiBwcm9ibGVtIHdpdGggdGhpcyBwcm9wb3NhbC4g IEl0IGlzIHN1bW1hcml6ZWQgaW4gb25lCj4gb2YgdGhlIGZpcnN0IGVtYWlscyBvbiB0aGlzIHRv cGljOgo+IAo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3Vy cmVudC9tc2cwMDc4NC5odG1sCj4gCj4gWW91IGRvIE5PVCBoYXZlIHRoaXMgcHJvYmxlbSB3aXRo IG5vcm1hbCBhdWdtZW50LgoKSWYgSSBpbXBvcnQgYSBkZWZpbml0aW9uIGZyb20gYSBtb2R1bGUg dGhhdCBoYXMgdGhlIG9yaWdpbmFsIHZlcnNpb24sCndoeSBzaG91bGQgSSBjYXJlIHRoYXQgc29t ZW9uZSBlbHNlIGFsc28gaW1wb3J0cyB0aGF0IGRlZmluaXRpb24gYW5kCm1vZGlmaWVzIGl0IGlu IGhpcyBvd24gbW9kdWxlPyBJIHdpbGwgc3RpbGwgZ2V0IHRoZSBvcmlnaW5hbCB2ZXJzaW9uLgoK TGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Sep 24 07:00:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD1A3A68F0; Wed, 24 Sep 2008 07:00:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED8D3A6A32 for ; Wed, 24 Sep 2008 07:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 nh5dxkhSbxQD for ; Wed, 24 Sep 2008 07:00:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A20FA3A68F0 for ; Wed, 24 Sep 2008 07:00:06 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79FF8C0013; Wed, 24 Sep 2008 15:59:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id keSXjr-NDeNR; Wed, 24 Sep 2008 15:59:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D115FC0029; Wed, 24 Sep 2008 15:59:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2FDAB7B7188; Wed, 24 Sep 2008 15:59:32 +0200 (CEST) Date: Wed, 24 Sep 2008 15:59:32 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080924135932.GA12585@elstar.local> Mail-Followup-To: Balazs Lengyel , "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48DA378C.2070300@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Sep 24, 2008 at 02:50:20PM +0200, Balazs Lengyel wrote: > Hello, > When I am defining my data models in some specific situations I already > know that I intend a part to be augmented/extended. > > I also don't see why this is such a dangerous feature because: > - you face most of the same problems with augmenting a lists or containers > - the augmentable statement can totally protect standards > - usually if a node implements and advertises "module augmentor" it will > anyway consider all the risks. > - you always have the fall back possibility augmentable false; and > augment the individual uses of the grouping. > - if you are not allowed to augment a grouping with mandatory stuff, all > an agent has to do is throw away some extra stuff when it receives it If there are no problems around augmentable groupings, we likely do not need this bit. If there are problems around augmentable groupings, then having a bit to turn on/off augmentability does not help solve the problem. In other words, the introduction of a knob does not help us much in figuring out how augmentable groupings would work. This is the IETF where you can't solve a problem by making it optional. /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 Wed Sep 24 07:08: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 64D213A6D5B; Wed, 24 Sep 2008 07:08:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F783A6D5B for ; Wed, 24 Sep 2008 07:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZVKZtIndpuo for ; Wed, 24 Sep 2008 07:08:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B19493A6DEC for ; Wed, 24 Sep 2008 07:08:36 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A335376C4DE; Wed, 24 Sep 2008 16:08:09 +0200 (CEST) Date: Wed, 24 Sep 2008 16:10:16 +0200 (CEST) Message-Id: <20080924.161016.266158302.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1222264295.6253.76.camel@missotis> References: <48DA378C.2070300@ericsson.com> <20080924.151833.189502425.mbj@tail-f.com> <1222264295.6253.76.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] 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 Ladislav Lhotka wrote: > If I import a definition from a module that has the original version, > why should I care that someone else also imports that definition and > modifies it in his own module? I will still get the original version. Because that's how augment of a grouping would work - if someone augments a grouping, it affects all other users of that grouping (in a device which implements the augmenting module). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 07:18: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 129B63A6A07; Wed, 24 Sep 2008 07:18:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78AE3A67B0 for ; Wed, 24 Sep 2008 07:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 v5V8O9qf1Dml for ; Wed, 24 Sep 2008 07:17:54 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 3CD703A6D5B for ; Wed, 24 Sep 2008 07:17:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,300,1220241600"; d="scan'208";a="136026826" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Sep 2008 10:17:26 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Sep 2008 10:17:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Sep 2008 16:17:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ForCES Forwarding Element Model Thread-Index: AckeUDueQ9vQ2d+LRX2TCuwBNKMZiQ== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] ForCES Forwarding Element Model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 am reviewing http://www.ietf.org/internet-drafts/draft-ietf-forces-model-15.txt which is on the IESG table for approval. It looks like a good candidate for NETMOD if the language was ready. Is any of you folks familiar with this work and thought how NETMOD would apply? Other comments? Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 07:21: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 7F07E3A6B5D; Wed, 24 Sep 2008 07:21:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1873A6B5D for ; Wed, 24 Sep 2008 07:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EJNrwDLyfxk for ; Wed, 24 Sep 2008 07:21:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3B4CA3A6B5C for ; Wed, 24 Sep 2008 07:21:12 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 622D6D800BD; Wed, 24 Sep 2008 16:21:10 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080924.161016.266158302.mbj@tail-f.com> References: <48DA378C.2070300@ericsson.com> <20080924.151833.189502425.mbj@tail-f.com> <1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> Organization: CESNET Date: Wed, 24 Sep 2008 16:21:11 +0200 Message-Id: <1222266071.6253.89.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyNC4gMDkuIDIwMDggdiAxNjoxMCArMDIwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gSWYgSSBpbXBv cnQgYSBkZWZpbml0aW9uIGZyb20gYSBtb2R1bGUgdGhhdCBoYXMgdGhlIG9yaWdpbmFsIHZlcnNp b24sCj4gPiB3aHkgc2hvdWxkIEkgY2FyZSB0aGF0IHNvbWVvbmUgZWxzZSBhbHNvIGltcG9ydHMg dGhhdCBkZWZpbml0aW9uIGFuZAo+ID4gbW9kaWZpZXMgaXQgaW4gaGlzIG93biBtb2R1bGU/IEkg d2lsbCBzdGlsbCBnZXQgdGhlIG9yaWdpbmFsIHZlcnNpb24uCj4gCj4gQmVjYXVzZSB0aGF0J3Mg aG93IGF1Z21lbnQgb2YgYSBncm91cGluZyB3b3VsZCB3b3JrIC0gaWYgc29tZW9uZQo+IGF1Z21l bnRzIGEgZ3JvdXBpbmcsIGl0IGFmZmVjdHMgYWxsIG90aGVyIHVzZXJzIG9mIHRoYXQgZ3JvdXBp bmcgKGluIGEKPiBkZXZpY2Ugd2hpY2ggaW1wbGVtZW50cyB0aGUgYXVnbWVudGluZyBtb2R1bGUp LgoKT2YgY291cnNlISBJZiBJIGltcG9ydCB0aGUgbW9kdWxlIHdpdGggdGhlIG9yaWdpbmFsIGRl ZmluaXRpb24gYW5kIHRoZW4KdGhpcyBkZWZpbml0aW9uIGNoYW5nZXMgaW4gdGhhdCBtb2R1bGUs IHRoZSBzYW1lIHByb2JsZW0gYXBwZWFycy4KCkl0IGlzIG1vcmUgYSBwcm9ibGVtIG9mIGNvbnRy b2xsaW5nIHdoYXQgcmVhbGx5IGdldHMgaW1wb3J0ZWQgKHdoaWNoCnJldmlzaW9uKS4KCldvdWxk IGl0IGhlbHAgaWYgdGhlIGF1Z21lbnRlZCBkZWZpbml0aW9uIGJlY2FtZSBwYXJ0IG9mIHRoZSBh dWdtZW50aW5nCm1vZHVsZSBuYW1lc3BhY2U/CgpNb2R1bGUgQSBkZWZpbmVzIGFtb2Q6Zm9vLgoK TW9kdWxlIEIgaW1wb3J0cyBBIGFuZCBhdWdtZW50cyBhbW9kOmZvbyBpbnRvIGJtb2Q6Zm9vLgoK TW9kdWxlIEMgbWF5IGltcG9ydCBqdXN0IEIsIHRoZW4gaXQgY2FuIG9ubHkgdXNlIGJtb2Q6Zm9v LCBvciBpbXBvcnQKYWxzbyBBIGFuZCB0aGVuIHVzZSB0aGUgb3JpZ2luYWwgdmVyc2lvbiBhbW9k OmZvbyBhcyB3ZWxsLgoKTGFkYQoKCj4gCj4gCj4gL21hcnRpbgotLSAKTGFkaXNsYXYgTGhvdGth LCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Sep 24 07:26: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 4185D3A6DA4; Wed, 24 Sep 2008 07:26:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43A83A6DB9 for ; Wed, 24 Sep 2008 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpoH9Emi3a7V for ; Wed, 24 Sep 2008 07:26:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 832B53A6D72 for ; Wed, 24 Sep 2008 07:26:47 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 11F1976C4DD; Wed, 24 Sep 2008 16:25:56 +0200 (CEST) Date: Wed, 24 Sep 2008 16:28:00 +0200 (CEST) Message-Id: <20080924.162800.210257880.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1222266071.6253.89.camel@missotis> References: <1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> <1222266071.6253.89.camel@missotis> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] 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 Ladislav Lhotka wrote: > Would it help if the augmented definition became part of the augmenting > module namespace? > > Module A defines amod:foo. > > Module B imports A and augments amod:foo into bmod:foo. This can already be done by creating a new grouping: module b { ... import a { prefix a; } grouping foo { uses a:foo; leaf b-stuff { ... } } } > Module C may import just B, then it can only use bmod:foo, or import > also A and then use the original version amod:foo as well. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 07:46:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A23D3A69D9; Wed, 24 Sep 2008 07:46:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021763A6B5C for ; Wed, 24 Sep 2008 07:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEDa+FJPQlko for ; Wed, 24 Sep 2008 07:46:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 01D0B3A69D9 for ; Wed, 24 Sep 2008 07:46:24 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5E4A1D800BD; Wed, 24 Sep 2008 16:45:46 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080924.162800.210257880.mbj@tail-f.com> References: <1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> <1222266071.6253.89.camel@missotis> <20080924.162800.210257880.mbj@tail-f.com> Organization: CESNET Date: Wed, 24 Sep 2008 16:45:46 +0200 Message-Id: <1222267546.6253.104.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyNC4gMDkuIDIwMDggdiAxNjoyOCArMDIwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gV291bGQgaXQg aGVscCBpZiB0aGUgYXVnbWVudGVkIGRlZmluaXRpb24gYmVjYW1lIHBhcnQgb2YgdGhlIGF1Z21l bnRpbmcKPiA+IG1vZHVsZSBuYW1lc3BhY2U/Cj4gPiAKPiA+IE1vZHVsZSBBIGRlZmluZXMgYW1v ZDpmb28uCj4gPiAKPiA+IE1vZHVsZSBCIGltcG9ydHMgQSBhbmQgYXVnbWVudHMgYW1vZDpmb28g aW50byBibW9kOmZvby4KPiAKPiBUaGlzIGNhbiBhbHJlYWR5IGJlIGRvbmUgYnkgY3JlYXRpbmcg YSBuZXcgZ3JvdXBpbmc6Cj4gCj4gICAgbW9kdWxlIGIgewo+ICAgICAgIC4uLgo+ICAgICAgIGlt cG9ydCBhIHsgcHJlZml4IGE7IH0KPiAgCj4gICAgICAgZ3JvdXBpbmcgZm9vIHsKPiAgICAgICAg IHVzZXMgYTpmb287Cj4gICAgICAgICBsZWFmIGItc3R1ZmYgeyAuLi4gfQo+ICAgICAgIH0KPiAg ICB9CgpPaCB5ZXMsIG9yIGV2ZW4gYnkgYXBwbHlpbmcgYXVnbWVudCBoZXJlIHRvIGdldCBpbnNp ZGUgdGhlIGdyb3VwaW5nCmE6Zm9vLiBUbyBCZXJuZDogaXNuJ3QgdGhpcyBzdWZmaWNpZW50PwoK TGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Sep 24 08:32: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 7C31C3A68F4; Wed, 24 Sep 2008 08:32:23 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DF33A68F0 for ; Wed, 24 Sep 2008 08:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXfpZyPJML0c for ; Wed, 24 Sep 2008 08:32:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 781C63A63C9 for ; Wed, 24 Sep 2008 08:32:18 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A417F2043D; Wed, 24 Sep 2008 17:31:49 +0200 (CEST) X-AuditID: c1b4fb3e-a7682bb000007a96-77-48da5d650688 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 929F8201FC; Wed, 24 Sep 2008 17:31:49 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 17:31:49 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 17:31:49 +0200 Message-ID: <48DA5D98.9090700@ericsson.com> Date: Wed, 24 Sep 2008 17:32:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <20080922.103953.69288811.mbj@tail-f.com> <48D79811.9030109@ericsson.com> <1222092265.6243.156.camel@missotis> <48D7B406.1000305@ericsson.com> <1222115322.32313.35.camel@missotis> In-Reply-To: <1222115322.32313.35.camel@missotis> X-OriginalArrivalTime: 24 Sep 2008 15:31:49.0304 (UTC) FILETIME=[A94CC380:01C91E5A] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] delete on list and leaf-list X-BeenThere: netmod@ietf.org 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 CgpMYWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gQmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgUG8gMjIu IDA5LiAyMDA4IHYgMTc6MDQgKzAyMDA6Cj4gCj4+IFNvIHRvIHBvaW50IHRvIGFuICJhZGRyZXNz IiBpdGVtIHlvdSBoYXZlIHRvIHNwZWNpZnkgaXQncyBrZXkgKGlwKS4gV2l0aG91dCB0aGF0IEkg d291bGQgYXNzdW1lIAo+PiAgICB0aGUgZXhwcmVzc2lvbiBpcyBpbmNvcnJlY3QuIFdlIG5ldmVy IHN0b3JlIGFuIGVtcHR5IGFkZHJlc3MsIGluIHRoZSBkYXRhc3RvcmUgaXQgYWx3YXlzIGhhcyAK Pj4gYSBrZXkgKGlwKS4gQUZBSUsgaW4gWHBhdGggPGFkZHJlc3MvPiB3b3VsZCBzZWxlY3QgYWxs IG5vZGVzLCBidXQgZG8gd2Ugd2FudCB0byBhbGxvdyBzdWNoIAo+PiBYUGF0aC1saWtlIGFkZHJl c3Npbmcgb2YgdGhlIG1hbmFnZWQgaXRlbXM/IFdlIG5ldmVyIHNhZCB0aGF0IHRpbGwgbm93LCBz byBJIHdvdWxkIGtlZXAgaXQgCj4+IHNpbXBsZS4gSWYgeW91IHdhbnQgc29tZXRoaW5nIGFkZHJl c3MgaXQgd2l0aCBpdCdzIGtleS4KPiAKPiBUaGUgYXBwcm9hY2ggb2YgUkZDIDUyNjEgbG9va3Mg YmV0dGVyICh0aG91Z2ggSSBoYXZlbid0IHJlYWQgaXQgdmVyeQo+IGNhcmVmdWxseSB5ZXQpLiBJ IGRvbid0IHVuZGVyc3RhbmQgdGhlIGZlYXIgb2YgWFBhdGgsIGl0IHNob3VsZG4ndCBiZSBhCj4g dGVycmlibGUgcHJvYmxlbSBmb3IgYW55IGFnZW50IHRvIGltcGxlbWVudCBpdC4gVGhlc2UgInNp bXBsZSIKPiBhcHByb2FjaGVzIHNlZW0gdG8gbGVhZCB0byBpbmNvbnNpc3RlbmNpZXMuCkJBTEFa UzogVGhlIHBvaW50IGlzIG5vdCB0aGUgZmVhciBvZiBYUGF0aC4gTmV0Y29uZiBhcyBJIHVuZGVy c3RhbmQgaW50ZW50aW9uYWxseSBhdm9pZGVkIApmaWx0ZXJzIGZvciBlZGl0LWNvbmZpZyBib3Ro IHN1YnRyZWUgYW5kIHhwYXRoLiBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIGlzIGludHJvZHVjaW5n IFhQYXRoIApmaWx0ZXJzIGludG8gZWRpdC1jb25maWcsIHNvIGl0IG11c3QgYmUgZXhwbGljaXRs eSBzdGF0ZWQuCj4gCj4+IEF0IGxlYXN0IHRoYXQgaXMgbXkgdmlldywgYnV0IHRoaXMgaXMgc29t ZXRoaW5nIHRoYXQgdGhlIFlBTkcgZHJhZnQgc2hvdWxkIGNlcnRhaW5seSBkZXNjcmliZSEKPiAK PiBZZXMsIHN1Y2ggcnVsZXMgc2hvdWxkIGJlIHNwZWNpZmllZCBpbiB0aGUgWUFORyBkcmFmdCwg YnV0IHNpbmNlIHRoZQo+IGVkaXQtY29uZmlnIG9wZXJhdGlvbnMgYXJlIGludHJvZHVjZWQgaW4g UkZDIDQ3NDEsIG9uZSB3b3VsZCBhc3N1bWUgdGhhdAo+IHRoZXkgYXJlIGluZGVwZW5kZW50IG9m IFlBTkcuIE90aGVyd2lzZSBpdCBjYW4gZWFzaWx5IGhhcHBlbiB0aGF0IHRoZQo+IG9wZXJhdGlv bnMgaGF2ZSBkaWZmZXJlbnQgc2VtYW50aWNzIGluIGRpZmZlcmVudCBETSBsYW5ndWFnZXMuCkJB TEFaUzogVGhlbiBwbGVhc2UgcHJvcG9zZSBhbiB1cGRhdGUgdG8gUkZDIDQ3NDEuIEkgdGhpbmsg ZHVyaW5nIHRoZSBZQU5HIGVmZm9ydCB3ZSBtdXN0IHN0YXRlIApob3cgc3VjaCBhbiBvcGVyYXRp b24gd29ya3MuCj4gCj4gTGFkYQo+IAoKLS0gCkJhbGF6cyBMZW5neWVsICAgICAgICAgICAgICAg ICAgICAgICBFcmljc3NvbiBIdW5nYXJ5IEx0ZC4KVFNQIFN5c3RlbSBNYW5hZ2VyCkVDTjogODMx IDczMjAgICAgICAgICAgICAgICAgICAgICAgICBGYXg6ICszNiAxIDQzNzc3OTIKVGVsOiArMzYt MS00MzctNzMyMCAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBs aXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From netmod-bounces@ietf.org Wed Sep 24 08:36: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 F2D763A68F0; Wed, 24 Sep 2008 08:36:34 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6043A6D77 for ; Wed, 24 Sep 2008 08:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 099u0I3SnULh for ; Wed, 24 Sep 2008 08:36:33 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 589E73A68F0 for ; Wed, 24 Sep 2008 08:36:33 -0700 (PDT) Received: (qmail 92974 invoked from network); 24 Sep 2008 15:35:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.153 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 24 Sep 2008 15:35:45 -0000 X-YMail-OSG: AgM2kGkVM1lPEcgPkUEWIvtyB0e.wBZs_dAvmSA.SvYgkZ3UMm_FHmmq3dqPbihOmDfUXie00FdIqlp0qxzulSmEK9e8fL4vcH4hxefahW4BTSIhLanIg1xFuTi3LiEjVSqd2HiELkGLsaK73rIp1TYh X-Yahoo-Newman-Property: ymail-3 Message-ID: <48DA5E50.9020609@netconfcentral.com> Date: Wed, 24 Sep 2008 08:35:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <48DA378C.2070300@ericsson.com> <20080924.151833.189502425.mbj@tail-f.com> <1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> In-Reply-To: <20080924.161016.266158302.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> If I import a definition from a module that has the original version, >> why should I care that someone else also imports that definition and >> modifies it in his own module? I will still get the original version. > > Because that's how augment of a grouping would work - if someone > augments a grouping, it affects all other users of that grouping (in a > device which implements the augmenting module). > YANG is no different than any other IETF specification in one regard. If it is perceived to be too complicated for the benefit it provides, then it will not be implemented. The tally of SNMP roadkill is substantial, and the WG would be naive to think complexity doesn't really matter. IMO, augmentable groupings provide a feature the IETF cannot even use, and it is way too complicated to implement. Show me the running code first, and maybe I will change my mind. Current augment is tractable because it operates on specific nodes in the entire 'MIB tree'. With augmented groupings you must process the unspecified "entire module set" (in O(N^^2) time) to determine the actual contents of a grouping. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 09: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 38B1028C343; Wed, 24 Sep 2008 09:42:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3B528C350 for ; Wed, 24 Sep 2008 09:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qydxlxQIdQBE for ; Wed, 24 Sep 2008 09:42:03 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id B4AF628C343 for ; Wed, 24 Sep 2008 09:42:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aAnHCABxnQ+cJCWPEZ1hldevH2nRyXXFHphu7do/NB6GXTqoKW842K5vuuwUTZBl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.116] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KiXQk-0004or-NA for netmod@ietf.org; Wed, 24 Sep 2008 12:41:35 -0400 Message-ID: <001d01c91e64$78770a40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <1222238867.6253.10.camel@missotis><20080924071104.GA11402@elstar.local> <48D9EE13.8080307@ericsson.com> Date: Wed, 24 Sep 2008 09:42:01 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4cc694529be4e1238a0be115740bb5c18350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.116 Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Balazs Lengyel" > To: "Ladislav Lhotka" ; "NETMOD Working Group" > Sent: Wednesday, September 24, 2008 12:36 AM > Subject: Re: [netmod] equality of keys ... > Comparing in lexical space would mean that 1.0 and 1.00 are different numbers. > > What problems do you foresee with comparing in value space? > Do we need something about this in the draft? Maybe one general statement valid for all data types? ... This may or may not be a consideration in the netconf architecture, but I think a historical reminder might be in order here. CMIP did comparisons in what is here being called the "value space" rather than the "lexical space." SNMP comparisons are in clearly in the lexical space. This is one of the things SNMP got right, in my opinion. The reason becomes clear if you consider the mechanics of master/subagent implementation. Using the "value space" requires that the master be able to dynamically acquire whatever the ad hoc comparison rules for a particular bit of information might happen to be. This is not just of concern for operation dispatch, but also for access control. The problem isn't as bad as it *could* be because this is really only necessary for distinguishing attributes (scoping), since (CMIP) filtering can be delegated to subagents without any loss of efficiency. Of course, for this to work the wire format needs to have been canonicalized, which only really makes sense if it's a machine-to-machine protocol rather than something that humans are intended to be typing in by hand. Again, I don't know whether these issues are of any relevance to netconf, but they *did* make a big difference in CMIP / SNMP implementation. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 10:25: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 783353A67A4; Wed, 24 Sep 2008 10:25:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628553A6874 for ; Wed, 24 Sep 2008 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 0ahtveKsPT7s for ; Wed, 24 Sep 2008 10:24:58 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 8BCD53A67A4 for ; Wed, 24 Sep 2008 10:24:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HHvaXEQzpq2bybo2DdfaKpH1GWjL2vLrz9N3T2HVEE/1eAjJOAkt+x2wDhmLIpwR; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.116] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KiY6H-0007q2-EC for netmod@ietf.org; Wed, 24 Sep 2008 13:24:29 -0400 Message-ID: <008901c91e6a$78c4cd60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48DA378C.2070300@ericsson.com><20080924.151833.189502425.mbj@tail-f.com><1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> Date: Wed, 24 Sep 2008 10:24:58 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4417b8db7d8babddf02fe80d1caf7fb4c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.116 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Wednesday, September 24, 2008 7:10 AM > Subject: Re: [netmod] Augmentable Groupings ... > Because that's how augment of a grouping would work - if someone > augments a grouping, it affects all other users of that grouping (in a > device which implements the augmenting module). ... Maybe it would be helpful to step back and consider what the reasons for wanting to do "augmentation" are. I've seen three in the SNMP world. Forgive the O-O terminology. (1) to provide a means of implementing something functionally equivalent to subclassing, in which either all or none of the instances of the superclass in a given system will also be instances of the subclass. (2) to provide a means of formally requiring that instances of two classes within a system exist in a 1:1 relationship. (3) To allow standards devlopers to get agreement on a basic subset capability, providing a hook for other standards (or vendors) to add additional capabilities subject to the same constraints as in (1) above. If we separate (2) out as really being a different kind of "beast", this problem reduces to the one of what netmod's basic metamodel is, and how module / definition revision and refinement ares handled. Until this gets hammered out, these same arguments will just keep coming up again and again. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Sep 24 12:48:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFC53A688E; Wed, 24 Sep 2008 12:48:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399B53A6BCB for ; Wed, 24 Sep 2008 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gj-juipsLBM for ; Wed, 24 Sep 2008 12:48:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5C8F03A6B74 for ; Wed, 24 Sep 2008 12:48:14 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1517776C4DD; Wed, 24 Sep 2008 21:48:18 +0200 (CEST) Date: Wed, 24 Sep 2008 21:49:52 +0200 (CEST) Message-Id: <20080924.214952.108024838.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <008901c91e6a$78c4cd60$6801a8c0@oemcomputer> References: <1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> <008901c91e6a$78c4cd60$6801a8c0@oemcomputer> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, "Randy Presuhn" wrote: > Maybe it would be helpful to step back and consider what the reasons > for wanting to do "augmentation" are. I've seen three in the SNMP world. > Forgive the O-O terminology. > > (1) to provide a means of implementing something functionally equivalent > to subclassing, in which either all or none of the instances of the superclass > in a given system will also be instances of the subclass. This is what augmentable groupings try to solve. > (2) to provide a means of formally requiring that instances of two classes > within a system exist in a 1:1 relationship. This can be done with keyrefs in YANG. > (3) To allow standards devlopers to get agreement on a basic subset > capability, providing a hook for other standards (or vendors) to add > additional capabilities This is what the current 'augment' mechanism in YANG tries to solve. > subject to the same constraints as in (1) above. ... but I don't understand this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 25 18:17: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 B2C063A69FF; Thu, 25 Sep 2008 18:17:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268943A69FF for ; Thu, 25 Sep 2008 18:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzbzJhb8mqLT for ; Thu, 25 Sep 2008 18:17:25 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 670B93A6A14 for ; Thu, 25 Sep 2008 18:17:25 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7S00KU13LAPR@usaga01-in.huawei.com> for netmod@ietf.org; Thu, 25 Sep 2008 18:17:35 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7S00JO73L9HT@usaga01-in.huawei.com> for netmod@ietf.org; Thu, 25 Sep 2008 18:17:34 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Fri, 26 Sep 2008 09:17:15 +0800 Date: Fri, 26 Sep 2008 09:17:15 +0800 From: fanhuaxiang 90002624 In-reply-to: <1222244362.6253.60.camel@missotis> To: Ladislav Lhotka Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> <48D9EE13.8080307@ericsson.com> <1222244362.6253.60.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, > That the concepts of equality and ordering in the value space and > multiple representations can be addressed only in descriptions. why say "only in descriptions"? does it mean it is only a implementation thing? > > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > 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 Sep 25 20:40: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 9A4A93A67E6; Thu, 25 Sep 2008 20:40:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8226F3A6A78 for ; Thu, 25 Sep 2008 20:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7ZHYUrZz0aA for ; Thu, 25 Sep 2008 20:40:13 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A73FB3A67E6 for ; Thu, 25 Sep 2008 20:40:13 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7S00K0CA50PR@usaga01-in.huawei.com> for netmod@ietf.org; Thu, 25 Sep 2008 20:39:01 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7S00GHJA4Z3U@usaga01-in.huawei.com> for netmod@ietf.org; Thu, 25 Sep 2008 20:39:00 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Fri, 26 Sep 2008 11:38:41 +0800 Date: Fri, 26 Sep 2008 11:38:41 +0800 From: fanhuaxiang 90002624 In-reply-to: <48DA378C.2070300@ericsson.com> To: Balazs Lengyel Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, can anyone explaint it to me why augmentation of grouping raise so many issues augmentation of containers, lists ... do not involve. e.g. why add a augmentable statement to grouping but not to container, list etc. > Hello, > When I am defining my data models in some specific situations I > already know that I intend a > part to be augmented/extended. > > I also don't see why this is such a dangerous feature because: > - you face most of the same problems with augmenting a lists or > containers- the augmentable statement can totally protect standards > - usually if a node implements and advertises "module augmentor" > it will anyway consider all > the risks. > - you always have the fall back possibility augmentable false; and > augment the individual uses > of the grouping. > - if you are not allowed to augment a grouping with mandatory > stuff, all an agent has to do is > throw away some extra stuff when it receives it > > Balazs > > Juergen Schoenwaelder wrote: > > On Tue, Sep 23, 2008 at 06:15:02PM +0200, Balazs Lengyel wrote: > > > >> "Defining with augmentation in mind" > >> > >> For me this means that groupings should be explicitly marked as > >> augmentable, so users can be prepared for augmentation. This > also has the > >> advantage that simple (non-marked) groupings are not > augmentable, so you > >> don't have to consider the any unintended complications. > >> > >> grouping interfaceAttributes { > >> augmentable true; // default would be false > >> leafs, other content > >> ... > >> } > > > > But the underlying question then remains: How does a model writer > > determine whether the augmentable bit of a grouping should be on or > > off? And if the augmentable bit is on, all the other questions > remain> the same - adding a knob does not answer any of those > questions...> > > /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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Sep 25 22:21:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F273A691A; Thu, 25 Sep 2008 22:21:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195213A69BF for ; Thu, 25 Sep 2008 22:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 mra7UDcvnihY for ; Thu, 25 Sep 2008 22:21:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DFB003A691A for ; Thu, 25 Sep 2008 22:21:01 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 171A6C002A; Fri, 26 Sep 2008 07:20:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FRBocF4j6-g1; Fri, 26 Sep 2008 07:20:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C691AC0026; Fri, 26 Sep 2008 07:20:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 482617B9A42; Fri, 26 Sep 2008 07:20:18 +0200 (CEST) Date: Fri, 26 Sep 2008 07:20:18 +0200 From: Juergen Schoenwaelder To: fanhuaxiang 90002624 Message-ID: <20080926052018.GA27388@elstar.local> Mail-Followup-To: fanhuaxiang 90002624 , Balazs Lengyel , netmod@ietf.org References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Sep 26, 2008 at 11:38:41AM +0800, fanhuaxiang 90002624 wrote: > Hi, > can anyone explaint it to me why augmentation of grouping raise so > many issues augmentation of containers, lists ... do not involve. > e.g. why add a augmentable statement to grouping but not to > container, list etc. Augementations of containers etc is supported and easy since the augmentation happens in the data tree and thus has a well define scope. An augmentation of a grouping is open ended and not well scoped (it is unclear where it applies in data trees) and augmentations of groupings might lead to name clashes. In other words, to make augmentations of grouping work, it is necessary to figure out how to scope them and how to ensure that name clashes are avoided. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 26 00:39: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 E76BF28C12E; Fri, 26 Sep 2008 00:39:17 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC0D28C130 for ; Fri, 26 Sep 2008 00:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN7g5SlIIdPe for ; Fri, 26 Sep 2008 00:39:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6F76428C12E for ; Fri, 26 Sep 2008 00:39:09 -0700 (PDT) Received: from [147.32.223.111] (unknown [147.32.223.111]) by office2.cesnet.cz (Postfix) with ESMTP id 12FCCD800BD; Fri, 26 Sep 2008 09:39:19 +0200 (CEST) From: Ladislav Lhotka To: fanhuaxiang 90002624 In-Reply-To: References: <1222238867.6253.10.camel@missotis> <20080924071104.GA11402@elstar.local> <48D9EE13.8080307@ericsson.com> <1222244362.6253.60.camel@missotis> Organization: CESNET Date: Fri, 26 Sep 2008 09:39:18 +0200 Message-Id: <1222414758.6318.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] equality of keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 ZmFuaHVheGlhbmcgOTAwMDI2MjQgcMOtxaFlIHYgUMOhIDI2LiAwOS4gMjAwOCB2IDA5OjE3ICsw ODAwOgo+IEhpLCAKPiA+IFRoYXQgdGhlIGNvbmNlcHRzIG9mIGVxdWFsaXR5IGFuZCBvcmRlcmlu ZyBpbiB0aGUgdmFsdWUgc3BhY2UgYW5kCj4gPiBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMgY2Fu IGJlIGFkZHJlc3NlZCBvbmx5IGluIGRlc2NyaXB0aW9ucy4KPiB3aHkgc2F5ICJvbmx5IGluIGRl c2NyaXB0aW9ucyI/IGRvZXMgaXQgbWVhbiBpdCBpcyBvbmx5IGEgaW1wbGVtZW50YXRpb24gdGhp bmc/CgpZZXMsIGltcGxlbWVudG9ycyBoYXZlIHRvIHJlYWQgdGhlc2UgdmVyYmFsIGRlc2NyaXB0 aW9ucyBhbmQgd3JpdGUgdGhlCmNvZGUgYWNjb3JkaW5nbHkuIFRoaXMgaW5mb3JtYXRpb24gaXMg bm90IGFjY2Vzc2libGUgdG8gZnV0dXJlIGdlbmVyaWMKWUFORyB2YWxpZGF0b3JzIGFuZCB0aGUg RFNETCBtYXBwaW5nIHdpbGwgdHJhbnNsYXRlIGl0IG9ubHkgdG8KZG9jdW1lbnRhdGlvbiBhbm5v dGF0aW9ucyBhcyB3ZWxsLgoKTGFkYQogCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1Ag S2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri Sep 26 02:01: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 306743A6ADE; Fri, 26 Sep 2008 02:01:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C1A28C19A for ; Fri, 26 Sep 2008 02:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhbItGs48PG1 for ; Fri, 26 Sep 2008 02:01:45 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 59C693A6AE3 for ; Fri, 26 Sep 2008 02:01:45 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7S006YOP37KK@usaga01-in.huawei.com> for netmod@ietf.org; Fri, 26 Sep 2008 02:01:55 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7S006FGP355X@usaga01-in.huawei.com> for netmod@ietf.org; Fri, 26 Sep 2008 02:01:55 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Fri, 26 Sep 2008 17:01:35 +0800 Date: Fri, 26 Sep 2008 17:01:35 +0800 From: fanhuaxiang 90002624 In-reply-to: <20080926052018.GA27388@elstar.local> To: j.schoenwaelder@jacobs-university.de Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> <20080926052018.GA27388@elstar.local> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Thanks, I see. since grouping is different from other statements, why are we expecting the same effect of augment. how about that, whenever a grouping is augmented, a new grouping is also created while keep the augmented grouping unchanged? > On Fri, Sep 26, 2008 at 11:38:41AM +0800, fanhuaxiang 90002624 wrote: > > Hi, > > can anyone explaint it to me why augmentation of grouping raise so > > many issues augmentation of containers, lists ... do not involve. > > e.g. why add a augmentable statement to grouping but not to > > container, list etc. > > Augementations of containers etc is supported and easy since the > augmentation happens in the data tree and thus has a well define > scope. An augmentation of a grouping is open ended and not well scoped > (it is unclear where it applies in data trees) and augmentations of > groupings might lead to name clashes. > > In other words, to make augmentations of grouping work, it is > necessary to figure out how to scope them and how to ensure that name > clashes are avoided. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 26 02:57: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 1DE9D3A6893; Fri, 26 Sep 2008 02:57:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08BE13A68B0 for ; Fri, 26 Sep 2008 02:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 umQNr-tCfCYF for ; Fri, 26 Sep 2008 02:57:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3C51E3A6893 for ; Fri, 26 Sep 2008 02:57:21 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B452C006F; Fri, 26 Sep 2008 11:56:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8GewNwCuiiJT; Fri, 26 Sep 2008 11:56:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2B5FC0063; Fri, 26 Sep 2008 11:56:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5C9B07B9E6D; Fri, 26 Sep 2008 11:56:37 +0200 (CEST) Date: Fri, 26 Sep 2008 11:56:37 +0200 From: Juergen Schoenwaelder To: fanhuaxiang 90002624 Message-ID: <20080926095637.GA28110@elstar.local> Mail-Followup-To: fanhuaxiang 90002624 , Balazs Lengyel , netmod@ietf.org References: <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> <20080926052018.GA27388@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Fri, Sep 26, 2008 at 05:01:35PM +0800, fanhuaxiang 90002624 wrote: > since grouping is different from other statements, why are we > expecting the same effect of augment. how about that, whenever a > grouping is augmented, a new grouping is also created while keep the > augmented grouping unchanged? This feature is already supported by YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 26 12:14:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA153A699A; Fri, 26 Sep 2008 12:14:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246383A68A6 for ; Fri, 26 Sep 2008 12:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDQ9vl-YJWYr for ; Fri, 26 Sep 2008 12:14:42 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 194AA3A68BB for ; Fri, 26 Sep 2008 12:14:42 -0700 (PDT) Received: (qmail 24550 invoked from network); 26 Sep 2008 19:13:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.153 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 26 Sep 2008 19:13:40 -0000 X-YMail-OSG: ADyshjgVM1lnYNIz1pdQDsSqAQ8PAploR5hpivqNToiPBjTDOX9R5AvSMC.BaLfDlJE8ujVC_1uszH6lhmzbZmDMgvM3SVHA3mkmAsTYpOjki6NPwjqd75c8vyPBKh1VpGqSlE.St_aXPuhl5pDQ2WrrHtYO_YiHm0_rvHZqSGan X-Yahoo-Newman-Property: ymail-3 Message-ID: <48DD3462.4090408@netconfcentral.com> Date: Fri, 26 Sep 2008 12:13:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> <20080926052018.GA27388@elstar.local> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org fanhuaxiang 90002624 wrote: > Hi, > Thanks, I see. > since grouping is different from other statements, why are we expecting the same effect of augment. > how about that, whenever a grouping is augmented, a new grouping is also created while keep the augmented grouping unchanged? > IMO, it is important that the language is deterministic, and any module or submodule is 'self-contained', meaning that a human (or compiler) can start with foo.yang and understand its contents to determine if they are valid. I also believe the "all or nothing" augment is totally useless for the IETF framework which allows modules to evolve over time, and change control is distributed. Consider this simple example why augmentable groupings are not self-compiling: module A { import B { prefix B; } augment B:G1 { leaf x { type int32; } } } module B { grouping G1 { leaf a { type string; } leaf b { type string; } } } module C { import B { prefix B; } container foo { leaf x { type string; } uses B:G1; } } Note that: - each individual module would compile just fine - there is no indication within module B or C that leaf 'x' from module A even exists (normal for augment) - when all modules are loaded together into some application, then it known that leaf 'x' already exists. - since groupings do not preserve namespace identity, this is a fatal error - normal augment is always deterministic, since at most there can be 2 modules involved, and when compiling the module with the augment-stmt, its complete validity can be determined since the database target is explicit - normal augment preserves namespaces, so name collision is not an issue anyway Andy >> On Fri, Sep 26, 2008 at 11:38:41AM +0800, fanhuaxiang 90002624 wrote: >>> Hi, >>> can anyone explaint it to me why augmentation of grouping raise so >>> many issues augmentation of containers, lists ... do not involve. >>> e.g. why add a augmentable statement to grouping but not to >>> container, list etc. >> Augementations of containers etc is supported and easy since the >> augmentation happens in the data tree and thus has a well define >> scope. An augmentation of a grouping is open ended and not well scoped >> (it is unclear where it applies in data trees) and augmentations of >> groupings might lead to name clashes. >> >> In other words, to make augmentations of grouping work, it is >> necessary to figure out how to scope them and how to ensure that name >> clashes are avoided. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Sep 26 18:40: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 ED3633A6A4C; Fri, 26 Sep 2008 18:40:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03B53A6831 for ; Fri, 26 Sep 2008 18:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5ImNCXicGxY for ; Fri, 26 Sep 2008 18:40:13 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A42593A68A7 for ; Fri, 26 Sep 2008 18:40:13 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7T00BDOZBDU0@usaga01-in.huawei.com> for netmod@ietf.org; Fri, 26 Sep 2008 18:40:25 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7T00AKRZBBT7@usaga01-in.huawei.com> for netmod@ietf.org; Fri, 26 Sep 2008 18:40:25 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sat, 27 Sep 2008 09:40:09 +0800 Date: Sat, 27 Sep 2008 09:40:09 +0800 From: fanhuaxiang 90002624 In-reply-to: <48DD3462.4090408@netconfcentral.com> To: Andy Bierman Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <46DCD7DCAFF0E94796B7C2894ED9F266045C8F66@esebe103.NOE.Nokia.com> <48A2FB32.9060405@netconfcentral.com> <7A8DC7028ADB134DB675F2EF1FAAEFCE354058@esebe103.NOE.Nokia.com> <84028E2C0BD7D44F8308A6E7FF659CDB5F9493@FIESEXC015.nsn-intra.net> <20080919183240.GA1601@elstar.local> <84028E2C0BD7D44F8308A6E7FF659CDB63401B@FIESEXC015.nsn-intra.net> <48D91606.60206@ericsson.com> <20080923203042.GC10970@elstar.local> <48DA378C.2070300@ericsson.com> <20080926052018.GA27388@elstar.local> <48DD3462.4090408@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, comments inline. > fanhuaxiang 90002624 wrote: > > Hi, > > Thanks, I see. > > since grouping is different from other statements, why are we > expecting the same effect of augment. > > how about that, whenever a grouping is augmented, a new > grouping is also created while keep the augmented grouping > unchanged? > > > > > IMO, it is important that the language is deterministic, > and any module or submodule is 'self-contained', meaning that > a human (or compiler) can start with foo.yang and understand > its contents to determine if they are valid. > > I also believe the "all or nothing" augment is totally > useless for the IETF framework which allows modules to > evolve over time, and change control is distributed. > > Consider this simple example why augmentable groupings > are not self-compiling: > > module A { > > import B { prefix B; } > > augment B:G1 { > leaf x { type int32; } > } > } > > module B { > > grouping G1 { > leaf a { type string; } > leaf b { type string; } > } > } > > module C { > > import B { prefix B; } > > container foo { > leaf x { type string; } > uses B:G1; > } > } > > > Note that: > - each individual module would compile just fine > - there is no indication within module B or C that > leaf 'x' from module A even exists (normal for augment) > - when all modules are loaded together into some > application, then it known that leaf 'x' already exists. > - since groupings do not preserve namespace identity, > this is a fatal error > - normal augment is always deterministic, since at most > there can be 2 modules involved, and when compiling the > module with the augment-stmt, its complete validity > can be determined since the database target is explicit > - normal augment preserves namespaces, so name collision > is not an issue anyway Yeah, C hardly know which grouping to use, original one in B or augmented one in A? so IMHO, we should preserve the origin of B:G1, and define augmented B:G1 to A:G1 or B:G2(if it is augmented in B), so "uses B:G1" statement is diterministic now. but in that case, we should design a grouping-specific augment statement. > > > Andy > > > >> On Fri, Sep 26, 2008 at 11:38:41AM +0800, fanhuaxiang 90002624 > wrote:>>> Hi, > >>> can anyone explaint it to me why augmentation of grouping > raise so > >>> many issues augmentation of containers, lists ... do not involve. > >>> e.g. why add a augmentable statement to grouping but not to > >>> container, list etc. > >> Augementations of containers etc is supported and easy since the > >> augmentation happens in the data tree and thus has a well define > >> scope. An augmentation of a grouping is open ended and not well > scoped>> (it is unclear where it applies in data trees) and > augmentations of > >> groupings might lead to name clashes. > >> > >> In other words, to make augmentations of grouping work, it is > >> necessary to figure out how to scope them and how to ensure > that name > >> clashes are avoided. > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > Germany>> Fax: +49 421 200 3103 university.de/>>> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Sep 27 18:40: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 765463A68BF; Sat, 27 Sep 2008 18:40:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790D33A6916 for ; Sat, 27 Sep 2008 18:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pO5JpzKJDNz for ; Sat, 27 Sep 2008 18:40:17 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id CAD133A68BF for ; Sat, 27 Sep 2008 18:40:17 -0700 (PDT) Received: (qmail 7958 invoked from network); 28 Sep 2008 01:40:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.153 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 28 Sep 2008 01:40:30 -0000 X-YMail-OSG: Dmt6YFsVM1lCpuK0yuYP6yei.tf548XeM94YDo_P8QvfTmIdbxgvNyvecp78HG4i9ULpkZDYaWANdrFmP57lgu9ogueEWF4ejZy.rgovF3ZFj5kgzKwgwFbUAmrqP1EMpVRFSbCj0JvwTxjutTWr74GP5.ebPqfAlx9Mo_gp15MHjZkh X-Yahoo-Newman-Property: ymail-5 Message-ID: <48DEE08D.1010001@netconfcentral.com> Date: Sat, 27 Sep 2008 18:40:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org 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, 7.7, para 2: The values in a leaf-list MUST be unique. Why do the leaf-list values have to be unique? Isn't that a data model decision, just like with list? There can be duplicate list entries if the list is non-config and has no keys defined. IMO, leaf-list should have an 'allow-duplicates true/false' sub-statement. (e.g., consider a DM for an iPod playlist; the default is not to allow duplicate songs, but the user can override it.) 7.7.6, para 1: Why can't a leaf-list use merge with edit-config? It can be ordered-by system (default) and insert new entries last (default) or no-op if the entry already exists. 7.7.6, para 6: create and delete are 1-at-a-time. The same issue was brought up for list. There is no way to delete the entire leaf-list or list. A note suggesting that if a delete operation for all entries at once is desired for a leaf-list or list, then it should be defined within its own NP container. A 'delete' operation on the container will have the same effect as a delete on every explicit leaf-list or list instance, but with a much simpler PDU. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Sep 27 23:32:04 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4399F3A696D; Sat, 27 Sep 2008 23:32:04 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708C93A696D for ; Sat, 27 Sep 2008 23:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 yBx0X89jwToV for ; Sat, 27 Sep 2008 23:32:02 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0C1CB3A692D for ; Sat, 27 Sep 2008 23:32:02 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7W006BQ7HRWC@usaga01-in.huawei.com> for netmod@ietf.org; Sat, 27 Sep 2008 23:32:15 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7W0014J7HPJ0@usaga01-in.huawei.com> for netmod@ietf.org; Sat, 27 Sep 2008 23:32:15 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sun, 28 Sep 2008 14:31:55 +0800 Date: Sun, 28 Sep 2008 14:31:55 +0800 From: fanhuaxiang 90002624 In-reply-to: <48DEE08D.1010001@netconfcentral.com> To: Andy Bierman Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <48DEE08D.1010001@netconfcentral.com> Cc: NETMOD Working Group Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, > Hi, > > 7.7, para 2: > > The values in a leaf-list MUST be unique. > > Why do the leaf-list values have to be unique? > Isn't that a data model decision, just like with list? > There can be duplicate list entries if the list is > non-config and has no keys defined. > > IMO, leaf-list should have an 'allow-duplicates true/false' > sub-statement. > > (e.g., consider a DM for an iPod playlist; the default is not > to allow duplicate songs, but the user can override it.) > I think we should investigate the scenarios where duplicated leaf-list is neccessary. basically, we should not repeat the same infomation unless there is an meaning for duplication. > > 7.7.6, para 1: > > Why can't a leaf-list use merge with edit-config? > It can be ordered-by system (default) and insert > new entries last (default) or no-op if the entry already > exists. > 7.7.6 3th para from end: If the operation is "merge" or "replace" the leaf-list entry is created if it does not exist. so merge is equivalent to create when node does not exsit or noop otherwise. > > 7.7.6, para 6: > > create and delete are 1-at-a-time. > The same issue was brought up for list. > There is no way to delete the entire leaf-list or list. > > A note suggesting that if a delete operation for all > entries at once is desired for a leaf-list or list, then > it should be defined within its own NP container. > A 'delete' operation on the container will have the same > effect as a delete on every explicit leaf-list or list instance, > but with a much simpler PDU. > I agree. Best regards, washam _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Sep 28 06:11:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CD93A68CF; Sun, 28 Sep 2008 06:11:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF83F3A68CF for ; Sun, 28 Sep 2008 06:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osUL0nmp7dsB for ; Sun, 28 Sep 2008 06:11:52 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id EDC613A68E6 for ; Sun, 28 Sep 2008 06:11:52 -0700 (PDT) Received: (qmail 87838 invoked from network); 28 Sep 2008 13:11:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 28 Sep 2008 13:11:29 -0000 X-YMail-OSG: kl4jCRwVM1kAYT0r1Ltj2eB9TGAXkXKJHBc.h2pTkP8yyEovxoWxOGVbs7fYqcCT7Kw6.F4KnAP9PXXb4KEchTJPGcqFP7FjKkj3XrDaX8njwoMNcyZus5q1bxEI4IoK6Z5MqJDsY65GVV6Gf13Y.zoY77h1FY1rMD3_Ui8oAhUPmWNTjpltHRWYht7o8e6IsOM8fQ-- X-Yahoo-Newman-Property: ymail-5 Message-ID: <48DF827F.2000301@netconfcentral.com> Date: Sun, 28 Sep 2008 06:11:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: <48DEE08D.1010001@netconfcentral.com> In-Reply-To: Cc: NETMOD Working Group Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org 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 fanhuaxiang 90002624 wrote: > Hi, >> Hi, >> >> 7.7, para 2: >> >> The values in a leaf-list MUST be unique. >> >> Why do the leaf-list values have to be unique? >> Isn't that a data model decision, just like with list? >> There can be duplicate list entries if the list is >> non-config and has no keys defined. >> >> IMO, leaf-list should have an 'allow-duplicates true/false' >> sub-statement. >> >> (e.g., consider a DM for an iPod playlist; the default is not >> to allow duplicate songs, but the user can override it.) >> > I think we should investigate the scenarios where duplicated leaf-list is neccessary. > basically, we should not repeat the same infomation unless there is an meaning for duplication. It is up to the data model if duplicates have meaning, not the YANG language. Another use case is the representation of any sort of 'data point sequence', such as raw data associated with an IPPM metric, or as config, some array of values to seed a function for an IPPM metric collector. RMON-style history buckets are another common non-config case. >> 7.7.6, para 1: >> >> Why can't a leaf-list use merge with edit-config? >> It can be ordered-by system (default) and insert >> new entries last (default) or no-op if the entry already >> exists. >> > 7.7.6 3th para from end: > If the operation is "merge" or "replace" the leaf-list entry is created if it does not exist. > so merge is equivalent to create when node does not exsit or noop otherwise. >> 7.7.6, para 6: >> >> create and delete are 1-at-a-time. >> The same issue was brought up for list. >> There is no way to delete the entire leaf-list or list. >> >> A note suggesting that if a delete operation for all >> entries at once is desired for a leaf-list or list, then >> it should be defined within its own NP container. >> A 'delete' operation on the container will have the same >> effect as a delete on every explicit leaf-list or list instance, >> but with a much simpler PDU. >> > I agree. > Best regards, > washam > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Sep 28 06:36: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 D58663A6403; Sun, 28 Sep 2008 06:36:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C5F3A6931 for ; Sun, 28 Sep 2008 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rtct5Q+4Oxx2 for ; Sun, 28 Sep 2008 06:36:18 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 0D2443A68D4 for ; Sun, 28 Sep 2008 06:36:18 -0700 (PDT) Received: (qmail 94451 invoked from network); 28 Sep 2008 13:36:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 28 Sep 2008 13:36:32 -0000 X-YMail-OSG: J4wd6p8VM1m2MmtFHHXF4u62ubMlbzg5CjuQCfOY5XMVqh2brYRvvxtb_lJeBXFTKnVVHX8_wdscU0_f3E5pCnRE3j3AQCdA9Zf5yXLNjGKizJk_RMEzy473iPYm5VgtwsAkRwbeG3yqov62VrFgjUnx X-Yahoo-Newman-Property: ymail-3 Message-ID: <48DF885E.1070704@netconfcentral.com> Date: Sun, 28 Sep 2008 06:36:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Randy Presuhn References: <48DA378C.2070300@ericsson.com><20080924.151833.189502425.mbj@tail-f.com><1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> <008901c91e6a$78c4cd60$6801a8c0@oemcomputer> In-Reply-To: <008901c91e6a$78c4cd60$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Martin Bjorklund" >> To: >> Cc: >> Sent: Wednesday, September 24, 2008 7:10 AM >> Subject: Re: [netmod] Augmentable Groupings > ... >> Because that's how augment of a grouping would work - if someone >> augments a grouping, it affects all other users of that grouping (in a >> device which implements the augmenting module). > ... > > Maybe it would be helpful to step back and consider what the reasons > for wanting to do "augmentation" are. I've seen three in the SNMP world. > Forgive the O-O terminology. > > (1) to provide a means of implementing something functionally equivalent > to subclassing, in which either all or none of the instances of the superclass > in a given system will also be instances of the subclass. > Is this how OO works? I think not. If you want to modify all instances of a class, don't you have to modify that class definition, or 1 of its ancestors? Ignoring all the implementation details for augmentable groupings, this does not seem to be a data modeling practice that is currently in use. It seems better suited to the IRTF than the IETF at this time. We have lots of experience with vendors augmenting specific objects in SNMP, and it is quite reasonable to support that same sort of functionality in NETCONF and YANG. We have no experience with augmenting arbitrary abstractions, which in turn can use other groupings as well as augment other groupings. If one really thought about all the new complexity due to the nature of the data-def-stmt, this feature may not seem so great after all. > (2) to provide a means of formally requiring that instances of two classes > within a system exist in a 1:1 relationship. > > (3) To allow standards devlopers to get agreement on a basic subset > capability, providing a hook for other standards (or vendors) to add > additional capabilities subject to the same constraints as in (1) above. > > If we separate (2) out as really being a different kind of "beast", this problem > reduces to the one of what netmod's basic metamodel is, and how module > / definition revision and refinement ares handled. Until this gets hammered > out, these same arguments will just keep coming up again and again. > > Randy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Sep 28 16:44: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 175E03A69F4; Sun, 28 Sep 2008 16:44:43 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A103A6A9C for ; Sun, 28 Sep 2008 16:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0O1ePpY83X8 for ; Sun, 28 Sep 2008 16:44:40 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5BD0C3A6A8C for ; Sun, 28 Sep 2008 16:44:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YsVhjx7q9wVuGIIccYgnsoruCu7u9OrVnc7hSQstxboeknh2W7NtNeBU2rSYN7M9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.239] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Kk5wb-0007kR-72 for netmod@ietf.org; Sun, 28 Sep 2008 19:44:53 -0400 Message-ID: <003801c921c4$4c6ba740$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48DA378C.2070300@ericsson.com><20080924.151833.189502425.mbj@tail-f.com><1222264295.6253.76.camel@missotis> <20080924.161016.266158302.mbj@tail-f.com> <008901c91e6a$78c4cd60$6801a8c0@oemcomputer> <48DF885E.1070704@netconfcentral.com> Date: Sun, 28 Sep 2008 16:45:32 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e49b5147d76bbb5b94d56fa99054ee2aab350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.239 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: > Sent: Sunday, September 28, 2008 6:36 AM > Subject: Re: [netmod] Augmentable Groupings ... > > (1) to provide a means of implementing something functionally equivalent > > to subclassing, in which either all or none of the instances of the superclass > > in a given system will also be instances of the subclass. > > > > Is this how OO works? I think not. > If you want to modify all instances of a class, don't > you have to modify that class definition, or 1 of its ancestors? ... (1) I'm making no claim that this is "how OO works" or that it is how OO should work. It's merely the way SNMP SMI augmentation works, for better or worse. This WG needs to be clear on whether, when it borrows the word, whether it also borrows the baggage that comes with it. (2) Configuration management sanity demands that to "modify a class definition" in any non-trivial way has to be understood as creating a new class definition. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Sep 28 21:36: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 3E8CC3A6887; Sun, 28 Sep 2008 21:36:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751E43A69C0 for ; Sun, 28 Sep 2008 21:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTnhZuyT-SCt for ; Sun, 28 Sep 2008 21:36:12 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 080CE3A6887 for ; Sun, 28 Sep 2008 21:36:05 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Sun, 28 Sep 2008 21:35:15 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Sep 2008 21:34:40 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Sep 2008 21:34:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Sep 2008 21:32:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8T4WTM16550; Sun, 28 Sep 2008 21:32:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8T4SKSh094148; Mon, 29 Sep 2008 04:28:20 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809290428.m8T4SKSh094148@idle.juniper.net> To: Andy Bierman In-reply-to: <48DF827F.2000301@netconfcentral.com> Date: Mon, 29 Sep 2008 00:28:20 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Sep 2008 04:32:29.0699 (UTC) FILETIME=[6200D530:01C921EC] Cc: NETMOD Working Group Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.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 up to the data model if duplicates have meaning, >not the YANG language. YANG doesn't model all data. If YANG operations require each list member to be uniquely identified (for delete and insert operations), then YANG can't handle non-unique list members. This implies that if you want a series of values like: me me not me me not you are forced to add a unique key like: one me one me not one me one me not It's noisier, but allows YANG operations to be unambiguous. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 01:52:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCAB3A6AAE; Mon, 29 Sep 2008 01:52:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E50C3A6AFF for ; Mon, 29 Sep 2008 01:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, 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 nmCQsjLv76ee for ; Mon, 29 Sep 2008 01:52:07 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 627323A6AAE for ; Mon, 29 Sep 2008 01:52:07 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 892AF76C4E7; Mon, 29 Sep 2008 10:52:23 +0200 (CEST) Date: Mon, 29 Sep 2008 10:55:03 +0200 (CEST) Message-Id: <20080929.105503.27702769.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48DEE08D.1010001@netconfcentral.com> References: <48DEE08D.1010001@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] 7.7 leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > 7.7, para 2: > > The values in a leaf-list MUST be unique. > > Why do the leaf-list values have to be unique? > Isn't that a data model decision, just like with list? > There can be duplicate list entries if the list is > non-config and has no keys defined. I agree that it would be consistent to allow duplicates in non-config leaf-lists. > IMO, leaf-list should have an 'allow-duplicates true/false' > sub-statement. ... but do we really need a new keyword for this? Can we just say that duplicates are allowed in non-config leaf-lists, and leave it to the description clause to specify the meaning of them, if applicable? > (e.g., consider a DM for an iPod playlist; the default is not > to allow duplicate songs, but the user can override it.) > > > 7.7.6, para 1: > > Why can't a leaf-list use merge with edit-config? It can, as described later in 7.7.6. > 7.7.6, para 6: > > create and delete are 1-at-a-time. Yes, that's what we currently have. > The same issue was brought up for list. > There is no way to delete the entire leaf-list or list. But shouldn't we fix this? I'd like to see a way to delete all entries in a leaf-list and list. > A note suggesting that if a delete operation for all > entries at once is desired for a leaf-list or list, then > it should be defined within its own NP container. I'd rather see this function (delete all entries) supported directly w/o the data modeller having to worry about it. I'd like to minimize the number of "data model tricks" a user must do in order to use the NETCONF protocol efficently. This is one of the underlying design ideas for YANG - a (resonable) YANG data model will work efficently with NETCONF. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 05:34: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 0FB973A6881; Mon, 29 Sep 2008 05:34:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B803A697E for ; Mon, 29 Sep 2008 05:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzz+EZq2fqEc for ; Mon, 29 Sep 2008 05:34:27 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 69F753A6881 for ; Mon, 29 Sep 2008 05:34:27 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 29 Sep 2008 05:33:12 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 05:33:10 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 05:33:09 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 05:31:33 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8TCVWM24699; Mon, 29 Sep 2008 05:31:32 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8TCROMZ096471; Mon, 29 Sep 2008 12:27:24 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809291227.m8TCROMZ096471@idle.juniper.net> Date: Mon, 29 Sep 2008 08:27:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Sep 2008 12:31:33.0333 (UTC) FILETIME=[4E8B5050:01C9222F] Cc: NETMOD Working Group Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.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 Phil Shafer writes: >It's noisier, but allows YANG operations to be unambiguous. Shoulda gone to bed: one me two me not three me four me not Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 08:03: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 591BD3A67A8; Mon, 29 Sep 2008 08:03:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1133A68C6 for ; Mon, 29 Sep 2008 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59ptTKYUkg1G for ; Mon, 29 Sep 2008 08:03:22 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 9143B3A6817 for ; Mon, 29 Sep 2008 08:03:22 -0700 (PDT) Received: (qmail 76479 invoked from network); 29 Sep 2008 15:03:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 29 Sep 2008 15:03:38 -0000 X-YMail-OSG: 3uNhPPkVM1mevArbnJ8_jFrRepyhmG.wXqM3hLY1ddfUBuwH94ZkHwmN63zG8VfTPGp3zObmX0wKYbO5g.rnQSkNV_Jyc1Cia6O7Nn5Mt9OHzO9T_OS3aynZc0rSW1iAjEkWtm.BiECWdyHrdB9.B5HSVIUwSVdW27u2YSyQrNp1 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E0EE49.9060507@netconfcentral.com> Date: Mon, 29 Sep 2008 08:03:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48DEE08D.1010001@netconfcentral.com> <20080929.105503.27702769.mbj@tail-f.com> In-Reply-To: <20080929.105503.27702769.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> 7.7, para 2: >> >> The values in a leaf-list MUST be unique. >> >> Why do the leaf-list values have to be unique? >> Isn't that a data model decision, just like with list? >> There can be duplicate list entries if the list is >> non-config and has no keys defined. > > I agree that it would be consistent to allow duplicates in non-config > leaf-lists. > >> IMO, leaf-list should have an 'allow-duplicates true/false' >> sub-statement. > > ... but do we really need a new keyword for this? Can we just say > that duplicates are allowed in non-config leaf-lists, and leave it to > the description clause to specify the meaning of them, if applicable? > Yes -- that was my first idea, but it is not as expressive for the DM designer. I agree the read-only use case is far more likely. >> (e.g., consider a DM for an iPod playlist; the default is not >> to allow duplicate songs, but the user can override it.) >> >> >> 7.7.6, para 1: >> >> Why can't a leaf-list use merge with edit-config? > > It can, as described later in 7.7.6. > >> 7.7.6, para 6: >> >> create and delete are 1-at-a-time. > > Yes, that's what we currently have. > >> The same issue was brought up for list. >> There is no way to delete the entire leaf-list or list. > > But shouldn't we fix this? I'd like to see a way to delete all > entries in a leaf-list and list. > The leaf-list operations are consistent with list operations now -- if you think of a leaf-list as a list with just a key any nothing else. An easy fix -- but possibly dangerous -- is to treat a missing key as a wildcard if nc:operation='delete' is present in the leaf-list or list node. This is consistent with the other node types (container, leaf). No instance info given in the delete means delete all instances. I prefer this approach because no changes to the NETCONF protocol are needed at all. It is also nearly pointless to 2nd guess all the ways an application can get an PDU wrong. The fewer special cases the better. When deleting a mandatory node within a case/choice, then do you delete the rest of the case nodes as well, and undo the entire case/choice -- unless the choice is mandatory? Or does a manager have to explicitly delete all the case arm nodes at once to remove an optional choice? This automatic deletion happens when any node from a different case is selected. It should work consistently for all edit operations. >> A note suggesting that if a delete operation for all >> entries at once is desired for a leaf-list or list, then >> it should be defined within its own NP container. > > I'd rather see this function (delete all entries) supported directly > w/o the data modeller having to worry about it. I'd like to minimize > the number of "data model tricks" a user must do in order to use the > NETCONF protocol efficently. This is one of the underlying design > ideas for YANG - a (resonable) YANG data model will work efficently > with NETCONF. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 08:27: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 EA8F33A6908; Mon, 29 Sep 2008 08:27:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210553A6A8D for ; Mon, 29 Sep 2008 08:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G2ymUs-yPXb for ; Mon, 29 Sep 2008 08:27:28 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 231793A6908 for ; Mon, 29 Sep 2008 08:27:28 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7F44C20644; Mon, 29 Sep 2008 17:26:39 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-19-48e0f3afb4eb Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6AAE7209D1; Mon, 29 Sep 2008 17:26:39 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 17:26:38 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 17:26:38 +0200 Message-ID: <48E0F3EC.6030405@ericsson.com> Date: Mon, 29 Sep 2008 17:27:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48DEE08D.1010001@netconfcentral.com> <20080929.105503.27702769.mbj@tail-f.com> <48E0EE49.9060507@netconfcentral.com> In-Reply-To: <48E0EE49.9060507@netconfcentral.com> X-OriginalArrivalTime: 29 Sep 2008 15:26:38.0280 (UTC) FILETIME=[C3FB0480:01C92247] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org 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: > > The leaf-list operations are consistent with list operations > now -- if you think of a leaf-list as a list with just a key > any nothing else. > > An easy fix -- but possibly dangerous -- is to treat a missing key > as a wildcard if nc:operation='delete' is present in > the leaf-list or list node. This is consistent with > the other node types (container, leaf). No instance info > given in the delete means delete all instances. > > I prefer this approach because no changes to the NETCONF protocol > are needed at all. It is also nearly pointless to 2nd guess all > the ways an application can get an PDU wrong. > The fewer special cases the better. > Isn't having a special case for delete only a CLR? Wont it hurt consistency? IMHO we are introducing a new concept: "addressing multiple nodes in one edit config operation". To introduce this just for one such specific case hits me as strange. Or would you like to allow it for replace as well (merge, create)? list foo { key bar; leaf bar {} leaf myLittleBit {} } // omiting key means myLittleBit in all foo entries ? newValue Would I be allowed to write // omiting key means all foo entries ? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 08:37: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 196733A67A8; Mon, 29 Sep 2008 08:37:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734823A693C for ; Mon, 29 Sep 2008 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 LSSgqZriDFFk for ; Mon, 29 Sep 2008 08:37:56 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 75DD33A67A8 for ; Mon, 29 Sep 2008 08:37:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 29 Sep 2008 08:35:16 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 08:35:22 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 08:35:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 08:35:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8TFZKM21937; Mon, 29 Sep 2008 08:35:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8TFVC0F097980; Mon, 29 Sep 2008 15:31:12 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809291531.m8TFVC0F097980@idle.juniper.net> To: Andy Bierman In-reply-to: <48E0EE49.9060507@netconfcentral.com> Date: Mon, 29 Sep 2008 11:31:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Sep 2008 15:35:21.0569 (UTC) FILETIME=[FBE29510:01C92248] Cc: netmod@ietf.org Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.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: >When deleting a mandatory node within a case/choice, then >do you delete the rest of the case nodes as well, and undo >the entire case/choice -- unless the choice is mandatory? No. You are making individual operations on a database. Until commit time, the database need not fulfill the mandatory constraint. >This automatic deletion happens when any node from a different case >is selected. It should work consistently for all edit operations. The auto-delete mechanism removes an obvious source of error that can never be valid at commit time. Compare these two cases to a web form with a mandatory field and a set of radio button. Selecting one radio button clears the other choices, but clearing the mandatory field does nothing. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 09:52: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 E582A3A693C; Mon, 29 Sep 2008 09:52:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D8A3A695B for ; Mon, 29 Sep 2008 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1mqFH7QgJhn for ; Mon, 29 Sep 2008 09:52:43 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 9E38C3A693C for ; Mon, 29 Sep 2008 09:52:43 -0700 (PDT) Received: (qmail 71742 invoked from network); 29 Sep 2008 16:52:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 29 Sep 2008 16:52:21 -0000 X-YMail-OSG: lg72ZG8VM1kM3i29N84q3doSXXZ_zuZKO0R.xHHhgOvYDxMCAVZvOSVCGqARo.DPTJ1Rzw6jBmFaF3WLPgco2qgwbrqEgFTrqtMCfhoBk4HFrGcN0CJfAWQYod5IonB3aq9KMQhePbhkYeC0fz_foik- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E107C3.9090405@netconfcentral.com> Date: Mon, 29 Sep 2008 09:52:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Phil Shafer References: <200809291531.m8TFVC0F097980@idle.juniper.net> In-Reply-To: <200809291531.m8TFVC0F097980@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org 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: >> When deleting a mandatory node within a case/choice, then >> do you delete the rest of the case nodes as well, and undo >> the entire case/choice -- unless the choice is mandatory? > > No. You are making individual operations on a database. > Until commit time, the database need not fulfill the > mandatory constraint. > That may be true for but not or as the target. But individual deletes are OK -- so the manager is responsible for deleting all case nodes. >> This automatic deletion happens when any node from a different case >> is selected. It should work consistently for all edit operations. > > The auto-delete mechanism removes an obvious source of error > that can never be valid at commit time. > IMO, deleting a mandatory node in an optional case is either an error or the manager wants to delete the entire choice, but calling it an error is fine. > Compare these two cases to a web form with a mandatory field and a > set of radio button. Selecting one radio button clears the other > choices, but clearing the mandatory field does nothing. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 10: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 24DEC3A6A08; Mon, 29 Sep 2008 10:04:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB723A6B0F for ; Mon, 29 Sep 2008 10:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yYIkbc8hcDD for ; Mon, 29 Sep 2008 10:04:28 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id D87563A6B5B for ; Mon, 29 Sep 2008 10:04:27 -0700 (PDT) Received: (qmail 37899 invoked from network); 29 Sep 2008 17:04:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 29 Sep 2008 17:04:44 -0000 X-YMail-OSG: hhV9Lw8VM1lmm6fdf6yvW0MHAeXdmRjtBrSzYpmm4OPVUglyW2R2yLeUwnyz7udMFM6SuNaTiZM7rl2Kmr9sVmink7LgjRtjlgeGesDevw2oc2XPaSjJjfvzMeuCelq2Kak- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E10AAA.4060308@netconfcentral.com> Date: Mon, 29 Sep 2008 10:04:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <48DEE08D.1010001@netconfcentral.com> <20080929.105503.27702769.mbj@tail-f.com> <48E0EE49.9060507@netconfcentral.com> <48E0F3EC.6030405@ericsson.com> In-Reply-To: <48E0F3EC.6030405@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org 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: > > > Andy Bierman wrote: > >> >> The leaf-list operations are consistent with list operations >> now -- if you think of a leaf-list as a list with just a key >> any nothing else. >> >> An easy fix -- but possibly dangerous -- is to treat a missing key >> as a wildcard if nc:operation='delete' is present in >> the leaf-list or list node. This is consistent with >> the other node types (container, leaf). No instance info >> given in the delete means delete all instances. >> >> I prefer this approach because no changes to the NETCONF protocol >> are needed at all. It is also nearly pointless to 2nd guess all >> the ways an application can get an PDU wrong. >> The fewer special cases the better. >> > Isn't having a special case for delete only a CLR? Wont it hurt > consistency? IMHO we are introducing a new concept: "addressing multiple > nodes in one edit config operation". To introduce this just for one such > specific case hits me as strange. > > Or would you like to allow it for replace as well (merge, create)? > > list foo { > key bar; > leaf bar {} > leaf myLittleBit {} > } > > // omiting key means myLittleBit in all foo > entries ? > newValue > > > Would I be allowed to write > > // omiting key means all foo entries ? > > > No, because 'myLittleBit' is a leaf with just one instance. You cannot start throwing in assumptions about the parent nodes. If the delete attribute is on the list, then (as always) the agent must decide which element(s) to delete. The NETCONF protocol is silent on this issue of how instances are specified for edit-config operations. YANG should specify exactly which nodes (with or without values) need to be present in an PDU, in order to perform a NETCONF create, replace, merge, or delete. It is fine if all operations are 1-node-at-a-time, but that should be mentioned in the sections on list and leaf-list. IMO, YANG should only add CLRs that are needed for interoperability. But instead, there are plenty of CLRs which presume how the YANG language will be used forever, even though it is brand new. > Balazs > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 11:37: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 482A13A69ED; Mon, 29 Sep 2008 11:37:00 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A533A6A05 for ; Mon, 29 Sep 2008 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 R9DefM8Ih3oG for ; Mon, 29 Sep 2008 11:36:58 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 69CA43A69ED for ; Mon, 29 Sep 2008 11:36:58 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E40C676C4E7; Mon, 29 Sep 2008 20:36:13 +0200 (CEST) Date: Mon, 29 Sep 2008 20:38:11 +0200 (CEST) Message-Id: <20080929.203811.146695419.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E0EE49.9060507@netconfcentral.com> References: <48DEE08D.1010001@netconfcentral.com> <20080929.105503.27702769.mbj@tail-f.com> <48E0EE49.9060507@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] 7.7 leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > >> The same issue was brought up for list. > >> There is no way to delete the entire leaf-list or list. > > But shouldn't we fix this? I'd like to see a way to delete all > > entries in a leaf-list and list. > > > > The leaf-list operations are consistent with list operations > now -- if you think of a leaf-list as a list with just a key > any nothing else. > > An easy fix -- but possibly dangerous -- is to treat a missing key > as a wildcard if nc:operation='delete' is present in > the leaf-list or list node. This is consistent with > the other node types (container, leaf). No instance info > given in the delete means delete all instances. Yes, but as I wrote in the first email in the other thread ("delete on list and leaf-list"), this is problematic b/c you cannot distinguish between "missing a value" and "the empty string value" in a leaf-list: leaf-list foo { type string; } Given the db: first entry third entry what does mean? Delete all entries or the entry whose value is the empty string? > I prefer this approach because no changes to the NETCONF protocol > are needed at all. It is also nearly pointless to 2nd guess all > the ways an application can get an PDU wrong. > The fewer special cases the better. I agree with this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 12:17:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF73D3A67A5; Mon, 29 Sep 2008 12:17:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DE83A6870 for ; Mon, 29 Sep 2008 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 A1WdVADUdFgx for ; Mon, 29 Sep 2008 12:17:18 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 316CF3A67A5 for ; Mon, 29 Sep 2008 12:17:18 -0700 (PDT) Received: (qmail 28617 invoked from network); 29 Sep 2008 19:17:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 29 Sep 2008 19:17:32 -0000 X-YMail-OSG: fYZ2x3oVM1kBBvAIrgWLjC73gx4NFfNsrcaLZ.J9Hc0ohcB_jySSl80wYcccszurLdG5MSFlwaCsLoh_fT.L09zcYnFEzkv_FoIrlMl8z8tE6M4askL0_3UYCFEHzTJs5Gys7acbGIyrKa4hJ8tyr4YBBYx17pdxM963c5ymSK99 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E129CB.4090901@netconfcentral.com> Date: Mon, 29 Sep 2008 12:17:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48DEE08D.1010001@netconfcentral.com> <20080929.105503.27702769.mbj@tail-f.com> <48E0EE49.9060507@netconfcentral.com> <20080929.203811.146695419.mbj@tail-f.com> In-Reply-To: <20080929.203811.146695419.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org 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: >>>> The same issue was brought up for list. >>>> There is no way to delete the entire leaf-list or list. >>> But shouldn't we fix this? I'd like to see a way to delete all >>> entries in a leaf-list and list. >>> >> The leaf-list operations are consistent with list operations >> now -- if you think of a leaf-list as a list with just a key >> any nothing else. >> >> An easy fix -- but possibly dangerous -- is to treat a missing key >> as a wildcard if nc:operation='delete' is present in >> the leaf-list or list node. This is consistent with >> the other node types (container, leaf). No instance info >> given in the delete means delete all instances. > > Yes, but as I wrote in the first email in the other thread ("delete on > list and leaf-list"), this is problematic b/c you cannot distinguish > between "missing a value" and "the empty string value" in a leaf-list: > > leaf-list foo { > type string; > } > > Given the db: > > first entry > > third entry > > what does > > > > mean? Delete all entries or the entry whose value is the empty > string? > > good point. I think we should stick with 1-at-a-time for now. The 'correct' approach would be to add an explicit 'delete-all' operation to NETCONF-bis, whenever that gets done. > > >> I prefer this approach because no changes to the NETCONF protocol >> are needed at all. It is also nearly pointless to 2nd guess all >> the ways an application can get an PDU wrong. >> The fewer special cases the better. > > I agree with this. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 14:37:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618FB3A6B66; Mon, 29 Sep 2008 14:37:31 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B003A6B66 for ; Mon, 29 Sep 2008 14:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbYP7KlWLyHk for ; Mon, 29 Sep 2008 14:37:29 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id EFA533A6B21 for ; Mon, 29 Sep 2008 14:37:28 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA17835 for ; Mon, 29 Sep 2008 17:37:48 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA23242 for ; Mon, 29 Sep 2008 17:37:47 -0400 (EDT) Message-Id: <200809292137.RAA23242@adminfs.snmp.com> To: netmod@ietf.org Date: Mon, 29 Sep 2008 17:37:47 -0400 From: David Reid Subject: [netmod] question about notification 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I'm starting to look at notifications and I have a question about the example in section 4.2.10. The if-index leaf does not appear in the XML encoding. I'm guessing if-index is not supposed to be in the YANG part. Is that correct? -David Reid ---- 4.2.10. Notification Definitions YANG allows the definition of notifications suitable for NETCONF. YANG data definition statements are used to model the content of the notification. YANG Example: notification link-failure { description "A link failure has been detected"; leaf if-index { type int32 { range "1 .. max"; } } leaf if-name { type keyref { path "/interfaces/interface/name"; } } } NETCONF XML Encoding: 2007-09-01T10:00:00Z so-1/2/3.0 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Sep 29 23:37: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 E4B733A6839; Mon, 29 Sep 2008 23:37:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6B43A6839 for ; Mon, 29 Sep 2008 23:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouLxDvCM7cvv for ; Mon, 29 Sep 2008 23:37:49 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 97FD33A67F4 for ; Mon, 29 Sep 2008 23:37:49 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 802CE20F17; Tue, 30 Sep 2008 08:07:25 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-c3-48e1c1e5b76a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9631A20ECC; Tue, 30 Sep 2008 08:06:29 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 08:05:58 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 08:05:57 +0200 Message-ID: <48E1C331.8060301@ericsson.com> Date: Tue, 30 Sep 2008 08:12:01 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48DEE08D.1010001@netconfcentral.com> <20080929.105503.27702769.mbj@tail-f.com> <48E0EE49.9060507@netconfcentral.com> <48E0F3EC.6030405@ericsson.com> <48E10AAA.4060308@netconfcentral.com> In-Reply-To: <48E10AAA.4060308@netconfcentral.com> X-OriginalArrivalTime: 30 Sep 2008 06:05:57.0681 (UTC) FILETIME=[9B08BA10:01C922C2] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] 7.7 leaf-list X-BeenThere: netmod@ietf.org 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: > Balazs Lengyel wrote: >> >> >> Andy Bierman wrote: >> >>> >>> The leaf-list operations are consistent with list operations >>> now -- if you think of a leaf-list as a list with just a key >>> any nothing else. >>> >>> An easy fix -- but possibly dangerous -- is to treat a missing key >>> as a wildcard if nc:operation='delete' is present in >>> the leaf-list or list node. This is consistent with >>> the other node types (container, leaf). No instance info >>> given in the delete means delete all instances. >>> >>> I prefer this approach because no changes to the NETCONF protocol >>> are needed at all. It is also nearly pointless to 2nd guess all >>> the ways an application can get an PDU wrong. >>> The fewer special cases the better. >>> >> Isn't having a special case for delete only a CLR? Wont it hurt >> consistency? IMHO we are introducing a new concept: "addressing >> multiple nodes in one edit config operation". To introduce this just >> for one such specific case hits me as strange. >> >> Or would you like to allow it for replace as well (merge, create)? >> >> list foo { >> key bar; >> leaf bar {} >> leaf myLittleBit {} >> } >> >> // omiting key means myLittleBit in all >> foo entries ? >> newValue >> >> >> Would I be allowed to write >> >> // omiting key means all foo entries ? >> >> >> > > No, because 'myLittleBit' is a leaf with just one instance. > You cannot start throwing in assumptions about the parent nodes. > If the delete attribute is on the list, then (as always) > the agent must decide which element(s) to delete. > > The NETCONF protocol is silent on this issue > of how instances are specified for edit-config operations. > > YANG should specify exactly which nodes (with or without values) > need to be present in an PDU, in order to perform > a NETCONF create, replace, merge, or delete. It is fine if > all operations are 1-node-at-a-time, but that should be mentioned > in the sections on list and leaf-list. > > IMO, YANG should only add CLRs that are needed for interoperability. > But instead, there are plenty of CLRs which presume how the > YANG language will be used forever, even though it is brand new. > Andy > I see your point, but IMHO one could just as well say: when addressing list foo, if I don't specify the key, that means all keys (like in XPath). But you sad in another mail, let's stick to 1-at-a-time for now, so this is a problem for another day. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 05:59:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25D83A693B; Tue, 30 Sep 2008 05:59:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75BA3A6986 for ; Tue, 30 Sep 2008 05:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSR-tfuTDSZw for ; Tue, 30 Sep 2008 05:59:56 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 23EC13A693B for ; Tue, 30 Sep 2008 05:59:56 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8000MD7ESBP1@usaga01-in.huawei.com> for netmod@ietf.org; Tue, 30 Sep 2008 06:00:12 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8000F3MESA9N@usaga01-in.huawei.com> for netmod@ietf.org; Tue, 30 Sep 2008 06:00:11 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106]) by szxmc04-in.huawei.com (mshttpd); Tue, 30 Sep 2008 20:59:54 +0800 Date: Tue, 30 Sep 2008 20:59:54 +0800 From: fanhuaxiang 90002624 In-reply-to: <200809292137.RAA23242@adminfs.snmp.com> To: David Reid Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <200809292137.RAA23242@adminfs.snmp.com> Cc: netmod@ietf.org Subject: Re: [netmod] question about notification 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I have the same confusion. washam > I'm starting to look at notifications and I have a question about > the example in section 4.2.10. The if-index leaf does not appear > in the XML encoding. I'm guessing if-index is not supposed to be > in the YANG part. Is that correct? > > -David Reid > > ---- > > 4.2.10. Notification Definitions > > YANG allows the definition of notifications suitable for NETCONF. > YANG data definition statements are used to model the content of > the notification. > > YANG Example: > > notification link-failure { > description "A link failure has been detected"; > leaf if-index { > type int32 { range "1 .. max"; } > } > leaf if-name { > type keyref { > path "/interfaces/interface/name"; > } > } > } > > NETCONF XML Encoding: > > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > 2007-09-01T10:00:00Z > > so-1/2/3.0 > > > > _______________________________________________ > 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 Sep 30 06:28:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D6C3A6B1D; Tue, 30 Sep 2008 06:28:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B4E3A6B23 for ; Tue, 30 Sep 2008 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyHRpNh4l1b9 for ; Tue, 30 Sep 2008 06:28:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id ABCC83A6B1D for ; Tue, 30 Sep 2008 06:28:44 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8UDT2RM017937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 Sep 2008 15:29:03 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8UDT1hQ002893 for ; Tue, 30 Sep 2008 15:29:02 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 15:29:02 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Sep 2008 15:28:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netmod] Augmentable Groupings Thread-Index: AckjAHTqgF4brOf5TPa4ypAIz7wg9w== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Sep 2008 13:29:02.0033 (UTC) FILETIME=[808AEC10:01C92300] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080930152903-65638BB0-CF1E7248/0-0/0-15 X-purgate-size: 5487/0 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi All, looking at the discussion around the proposal of the augmentable grouping feature, I think that there is no rough consensus to integrate this feature into YANG. I think the main motivation that lead to this proposal was in particular being able to extend commonly used groupings in an effective manner by augmenting them with additional nodes. I see a value in this feature for the seamless distribution of grouping extensions. However, the question "Is it a bug or feature?" is not easy to answer. Martin Bjorklund wrote on September 24, 2008 9:50 PM > "Randy Presuhn" wrote: >> (1) to provide a means of implementing something functionally equivalent >> to subclassing, in which either all or none of the instances of the superclass >> in a given system will also be instances of the subclass. > > This is what augmentable groupings try to solve. As I understand this proposal was not meant to be an OO feature. Augmentable Groupings are functionally not equivalent to subclassing or inheritance. IMO OO features should be prepared based on complex types as an extension of the YANG type system (i.e. typed objects) which is far beyond of what augmentable groupings is proposing. Balazs Lengyel wrote: >> Hello, >> When I am defining my data models in some specific situations I already know >> that I intend a part to be augmented/extended. >> >> I also don't see why this is such a dangerous feature because: >> - you face most of the same problems with augmenting a lists or containers I also was thinking that this is not a dangerous feature but .... Martin Bjorklund wrote on September 24, 2008 3:19 PM: >There is one main problem with this proposal. It is summarized in one >of the first emails on this topic: >http://www.ietf.org/mail-archive/web/netmod/current/msg00784.html > >You do NOT have this problem with normal augment. >Adding an 'augementable' flag does not solve this problem. ... this is the point where I start yielding. The current proposal for augmentable groupings so far does not provide a solution for the issue addressed by Phil. Therefor I would like to suggest not to spend additional discussion bandwith for this topic and resume later if we have some written text and a better understanding of language abstractions for YANG. Cheers, Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Sunday, September 28, 2008 3:37 PM > To: Randy Presuhn > Cc: netmod@ietf.org > Subject: Re: [netmod] Augmentable Groupings > > Randy Presuhn wrote: > > Hi - > > > >> From: "Martin Bjorklund" > >> To: > >> Cc: > >> Sent: Wednesday, September 24, 2008 7:10 AM > >> Subject: Re: [netmod] Augmentable Groupings > > ... > >> Because that's how augment of a grouping would work - if someone > >> augments a grouping, it affects all other users of that > grouping (in a > >> device which implements the augmenting module). > > ... > > > > Maybe it would be helpful to step back and consider what the reasons > > for wanting to do "augmentation" are. I've seen three in > the SNMP world. > > Forgive the O-O terminology. > > > > (1) to provide a means of implementing something > functionally equivalent > > to subclassing, in which either all or none of the > instances of the superclass > > in a given system will also be instances of the subclass. > > > > Is this how OO works? I think not. > If you want to modify all instances of a class, don't > you have to modify that class definition, or 1 of its ancestors? > > Ignoring all the implementation details for augmentable > groupings, this does not seem to be a data modeling practice > that is currently in use. It seems better suited to the > IRTF than the IETF at this time. > > We have lots of experience with vendors augmenting specific > objects in SNMP, and it is quite reasonable to support > that same sort of functionality in NETCONF and YANG. > We have no experience with augmenting arbitrary abstractions, > which in turn can use other groupings as well as augment > other groupings. If one really thought about all the > new complexity due to the nature of the data-def-stmt, > this feature may not seem so great after all. > > > > (2) to provide a means of formally requiring that instances > of two classes > > within a system exist in a 1:1 relationship. > > > > (3) To allow standards devlopers to get agreement on a basic subset > > capability, providing a hook for other standards (or vendors) to add > > additional capabilities subject to the same constraints as > in (1) above. > > > > If we separate (2) out as really being a different kind of > "beast", this problem > > reduces to the one of what netmod's basic metamodel is, and > how module > > / definition revision and refinement ares handled. Until > this gets hammered > > out, these same arguments will just keep coming up again and again. > > > > Randy > > > > > 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 Tue Sep 30 07:09: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 8F94E3A6A4C; Tue, 30 Sep 2008 07:09:55 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA09D3A6B36 for ; Tue, 30 Sep 2008 07:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.146, 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 miO3uGzA2DQa for ; Tue, 30 Sep 2008 07:09:53 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id E10183A6A4C for ; Tue, 30 Sep 2008 07:09:53 -0700 (PDT) Received: (qmail 94725 invoked from network); 30 Sep 2008 14:10:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 30 Sep 2008 14:10:13 -0000 X-YMail-OSG: p6h0RcgVM1nX7TThFfVJRqgs215giMMqgBQGcF7xXAPyIDM4j6gvAObvWDS0dbftdZhP7KWdzye2iB3e0jYZyx.JzL3gWwCGo0LtzdzMjLW7T6JNqNkvA2AWUvgSTsUvtsupWgS82ddeSMV88SV3b10W X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E23343.8070806@netconfcentral.com> Date: Tue, 30 Sep 2008 07:10:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: <200809292137.RAA23242@adminfs.snmp.com> In-Reply-To: Cc: netmod@ietf.org Subject: [netmod] leafref (was Re: question about notification 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 fanhuaxiang 90002624 wrote: > Hi, > I have the same confusion. This is just a bug in the example -- the if-index node should be present. This example was brought up before wrt/ leafref. Notice how if-name is a clean definition, and conveys the correct semantics (if-name is a pointer to the database)? Notice how if-index is cut-and-paste, and if it had a description clause, would say "This is a copy of the if-index from the list entry that caused the link-failure."? A named type (InterfaceIndex) would be a little better, but a leafref might be better still: notification link-failure { description "A link failure has been detected"; leaf if-index { type leafref { path "/interfaces/interface/if-index"; } } leaf if-name { type keyref { path "/interfaces/interface/name"; } } } (IMO, YANG should have leafref instead of keyref.) > washam Andy >> I'm starting to look at notifications and I have a question about >> the example in section 4.2.10. The if-index leaf does not appear >> in the XML encoding. I'm guessing if-index is not supposed to be >> in the YANG part. Is that correct? >> >> -David Reid >> >> ---- >> >> 4.2.10. Notification Definitions >> >> YANG allows the definition of notifications suitable for NETCONF. >> YANG data definition statements are used to model the content of >> the notification. >> >> YANG Example: >> >> notification link-failure { >> description "A link failure has been detected"; >> leaf if-index { >> type int32 { range "1 .. max"; } >> } >> leaf if-name { >> type keyref { >> path "/interfaces/interface/name"; >> } >> } >> } >> >> NETCONF XML Encoding: >> >> > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> >> 2007-09-01T10:00:00Z >> >> so-1/2/3.0 >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 07:19: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 1B69F3A686D; Tue, 30 Sep 2008 07:19:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC373A6B36 for ; Tue, 30 Sep 2008 07:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 pMJuAY0UotiN for ; Tue, 30 Sep 2008 07:19:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 056943A686D for ; Tue, 30 Sep 2008 07:19:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A0451C004F; Tue, 30 Sep 2008 16:19:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XTcC83dAn0Px; Tue, 30 Sep 2008 16:19:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23E44C0047; Tue, 30 Sep 2008 16:19:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5F4257D69B1; Tue, 30 Sep 2008 16:19:42 +0200 (CEST) Date: Tue, 30 Sep 2008 16:19:42 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080930141942.GA25609@elstar.local> Mail-Followup-To: Andy Bierman , fanhuaxiang 90002624 , netmod@ietf.org References: <200809292137.RAA23242@adminfs.snmp.com> <48E23343.8070806@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48E23343.8070806@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] leafref (was Re: question about notification example) 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, Sep 30, 2008 at 07:10:11AM -0700, Andy Bierman wrote: > (IMO, YANG should have leafref instead of keyref.) I think this should be on the open issues list. /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 Sep 30 07:31: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 34A1E3A67AB; Tue, 30 Sep 2008 07:31:23 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAA43A6AE3 for ; Tue, 30 Sep 2008 07:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KEhkqH1UPpu for ; Tue, 30 Sep 2008 07:31:17 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 82BF43A67AB for ; Tue, 30 Sep 2008 07:31:17 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA04903; Tue, 30 Sep 2008 10:31:37 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA17397; Tue, 30 Sep 2008 10:31:36 -0400 (EDT) Message-Id: <200809301431.KAA17397@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Tue, 30 Sep 2008 07:10:11 -0700. <48E23343.8070806@netconfcentral.com> Date: Tue, 30 Sep 2008 10:31:36 -0400 Cc: netmod@ietf.org Subject: Re: [netmod] leafref (was Re: question about notification example) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I like the leafref idea a lot. Are you suggestion we eliminate the keyref type or support both keyref and leafref where keyref is used to reference a list entry and leafref is used to reference a leaf? -David Reid > This is just a bug in the example -- the if-index node should be present. > > This example was brought up before wrt/ leafref. > > Notice how if-name is a clean definition, and conveys > the correct semantics (if-name is a pointer to the database)? > > Notice how if-index is cut-and-paste, and if it had a > description clause, would say "This is a copy of the > if-index from the list entry that caused the link-failure."? > > A named type (InterfaceIndex) would be a little better, > but a leafref might be better still: > > notification link-failure { > description "A link failure has been detected"; > leaf if-index { > type leafref { > path "/interfaces/interface/if-index"; > } > } > leaf if-name { > type keyref { > path "/interfaces/interface/name"; > } > } > } > > (IMO, YANG should have leafref instead of keyref.) > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 08:23:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEF23A67AB; Tue, 30 Sep 2008 08:23:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC723A67AB for ; Tue, 30 Sep 2008 08:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 yVEeKlpMzewn for ; Tue, 30 Sep 2008 08:23:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C88C23A6B37 for ; Tue, 30 Sep 2008 08:23:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8UFOGvx004894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 Sep 2008 17:24:16 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8UFOGWA021270 for ; Tue, 30 Sep 2008 17:24:16 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 17:24:16 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 17:24:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Sep 2008 18:24:13 +0300 Message-ID: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Augmentable Groupings Thread-Index: AckjAHTqgF4brOf5TPa4ypAIz7wg9wAChJzg References: From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: , "Ersue, Mehmet (NSN - DE/Munich)" X-OriginalArrivalTime: 30 Sep 2008 15:24:16.0795 (UTC) FILETIME=[9A0FDEB0:01C92310] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080930172416-57D69BB0-3889C717/0-0/0-15 X-purgate-size: 7062/0 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org = Hi, Mehmet Ers=FC wrote: > Subject: Re: [netmod] Augmentable Groupings > = > = > Hi All, > = > looking at the discussion around the proposal of the = > augmentable grouping feature, I think that there is no = > rough consensus to integrate this feature into YANG. > = This is also my impression. > I think the main motivation that lead to this proposal = > was in particular being able to extend commonly used = > groupings in an effective manner by augmenting them = > with additional nodes. I see a value in this feature for = > the seamless distribution of grouping extensions. > = > However, the question "Is it a bug or feature?" is not = > easy to answer. > = > Martin Bjorklund wrote on September 24, 2008 9:50 PM > > "Randy Presuhn" wrote: > >> (1) to provide a means of implementing something functionally > equivalent > >> to subclassing, in which either all or none of the instances of the > superclass > >> in a given system will also be instances of the subclass. > > > > This is what augmentable groupings try to solve. > = > As I understand this proposal was not meant to be an = > OO feature. Augmentable Groupings are functionally = > not equivalent to subclassing or inheritance. IMO OO = > features should be prepared based on complex types = > as an extension of the YANG type system (i.e. typed = > objects) which is far beyond of what augmentable = > groupings is proposing. > = I agree. The idea was to strengthen the applicability of groupings to represent basic concepts that may be extended in a uniform manner and to do this with already existing YANG language features. > Balazs Lengyel wrote: > >> Hello, > >> When I am defining my data models in some specific situations I > already know > >> that I intend a part to be augmented/extended. > >> = > >> I also don't see why this is such a dangerous feature because: > >> - you face most of the same problems with augmenting a lists or > containers > = > I also was thinking that this is not a dangerous feature = > but .... > = > Martin Bjorklund wrote on September 24, 2008 3:19 PM: > >There is one main problem with this proposal. It is = > summarized in one > >of the first emails on this topic: > >http://www.ietf.org/mail-archive/web/netmod/current/msg00784.html > > > >You do NOT have this problem with normal augment. > >Adding an 'augementable' flag does not solve this problem. > = > ... this is the point where I start yielding. The current = > proposal for augmentable groupings so far does not = > provide a solution for the issue addressed by Phil. Yes. So an alternative is to define basic concepts as well as extensions in own groupings and augment all the places = one by one where an extension makes sense. module B { grouping NetworkInterface { // ... } // ... } module X { grouping HighCapacityInterfaceExtension { list HighCapacityInterface { // ... } = } augment "B:/controller/interfaces" { use HighCapacityInterfaceExtension; } augment "B:/transceiver/interfaces" = use HighCapacityInterfaceExtension; } // .... } As discussed with Balazs in Dublin, using a list = as base element in the grouping could help to identify extensions and avoid name clashes. BR, Bernd > = > Therefor I would like to suggest not to spend additional = > discussion bandwith for this topic and resume later if = > we have some written text and a better understanding = > of language abstractions for YANG. > = > Cheers, = > Mehmet > = > = > > -----Original Message----- > > From: netmod-bounces@ietf.org = > > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Andy Bierman > > Sent: Sunday, September 28, 2008 3:37 PM > > To: Randy Presuhn > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Augmentable Groupings > > = > > Randy Presuhn wrote: > > > Hi - > > > = > > >> From: "Martin Bjorklund" > > >> To: > > >> Cc: > > >> Sent: Wednesday, September 24, 2008 7:10 AM > > >> Subject: Re: [netmod] Augmentable Groupings > > > ... > > >> Because that's how augment of a grouping would work - if someone > > >> augments a grouping, it affects all other users of that = > > grouping (in a > > >> device which implements the augmenting module). > > > ... > > > = > > > Maybe it would be helpful to step back and consider what = > the reasons > > > for wanting to do "augmentation" are. I've seen three in = > > the SNMP world. > > > Forgive the O-O terminology. > > > = > > > (1) to provide a means of implementing something = > > functionally equivalent > > > to subclassing, in which either all or none of the = > > instances of the superclass > > > in a given system will also be instances of the subclass. > > > = > > = > > Is this how OO works? I think not. > > If you want to modify all instances of a class, don't > > you have to modify that class definition, or 1 of its ancestors? > > = > > Ignoring all the implementation details for augmentable > > groupings, this does not seem to be a data modeling practice > > that is currently in use. It seems better suited to the > > IRTF than the IETF at this time. > > = > > We have lots of experience with vendors augmenting specific > > objects in SNMP, and it is quite reasonable to support > > that same sort of functionality in NETCONF and YANG. > > We have no experience with augmenting arbitrary abstractions, > > which in turn can use other groupings as well as augment > > other groupings. If one really thought about all the > > new complexity due to the nature of the data-def-stmt, > > this feature may not seem so great after all. > > = > > = > > > (2) to provide a means of formally requiring that instances = > > of two classes > > > within a system exist in a 1:1 relationship. > > > = > > > (3) To allow standards devlopers to get agreement on a = > basic subset > > > capability, providing a hook for other standards (or = > vendors) to add > > > additional capabilities subject to the same constraints as = > > in (1) above. > > > = > > > If we separate (2) out as really being a different kind of = > > "beast", this problem > > > reduces to the one of what netmod's basic metamodel is, and = > > how module > > > / definition revision and refinement ares handled. Until = > > this gets hammered > > > out, these same arguments will just keep coming up again = > and again. > > > = > > > Randy > > > = > > = > > = > > 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 > = _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 08:24: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 0A87A3A6833; Tue, 30 Sep 2008 08:24:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0A43A6B95 for ; Tue, 30 Sep 2008 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.126, 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 rAQKsufjOOTL for ; Tue, 30 Sep 2008 08:24:22 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id CDEBE3A67AB for ; Tue, 30 Sep 2008 08:24:22 -0700 (PDT) Received: (qmail 71411 invoked from network); 30 Sep 2008 15:24:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 30 Sep 2008 15:24:37 -0000 X-YMail-OSG: so0gVEcVM1k0P7Mh3mUJqMQB84yKrwBigjwOtl_nIuEVpyU56ac3WEfJ44UrkvHPYvgBCy_nagx85zpIDy1WZ55Vkpq5KXnsjckg0W0oWj1Swj3l3b9PyOenep9C8jmMElw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E244B3.9020109@netconfcentral.com> Date: Tue, 30 Sep 2008 08:24:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: David Reid References: <200809301431.KAA17397@adminfs.snmp.com> In-Reply-To: <200809301431.KAA17397@adminfs.snmp.com> Cc: netmod@ietf.org Subject: Re: [netmod] leafref (was Re: question about notification 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 David Reid wrote: > I like the leafref idea a lot. > > Are you suggestion we eliminate the keyref type or support both keyref and > leafref where keyref is used to reference a list entry and leafref is used to > reference a leaf? > I can see the value in leaving the keyref semantics as is, and also having a leafref with new semantics. Sometimes you really mean to constrain the value set to the current key values within another list (ala SQL foreign key). But many times you want a pointer-to-a-leaf instead of cut-and-paste-of-a-leaf. The use-cases are very different. > -David Reid Andy > > >> This is just a bug in the example -- the if-index node should be present. >> >> This example was brought up before wrt/ leafref. >> >> Notice how if-name is a clean definition, and conveys >> the correct semantics (if-name is a pointer to the database)? >> >> Notice how if-index is cut-and-paste, and if it had a >> description clause, would say "This is a copy of the >> if-index from the list entry that caused the link-failure."? >> >> A named type (InterfaceIndex) would be a little better, >> but a leafref might be better still: >> >> notification link-failure { >> description "A link failure has been detected"; >> leaf if-index { >> type leafref { >> path "/interfaces/interface/if-index"; >> } >> } >> leaf if-name { >> type keyref { >> path "/interfaces/interface/name"; >> } >> } >> } >> >> (IMO, YANG should have leafref instead of keyref.) >> >> > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 08:43:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05DEC3A6B54; Tue, 30 Sep 2008 08:43:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696E63A6B37 for ; Tue, 30 Sep 2008 08:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.110, 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 nL3wNVpiZliz for ; Tue, 30 Sep 2008 08:42:59 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 5897328C13A for ; Tue, 30 Sep 2008 08:42:57 -0700 (PDT) Received: (qmail 24803 invoked from network); 30 Sep 2008 15:43:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 30 Sep 2008 15:43:16 -0000 X-YMail-OSG: vEqdJQ4VM1kiTdh1zrhQcBZGOc5qybNjYcRipK98yPl6EqaNWVC0JOT78N.dnbx9DtWrfYXVqyC9h4KguHkm4pzl7j06ASPSJlMs77.YJDyMvesCgvt6ue3fo4lolRi9iLQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E24913.40305@netconfcentral.com> Date: Tue, 30 Sep 2008 08:43:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] NETMOD interim agenda X-BeenThere: netmod@ietf.org 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, According to IETF Rules, the interim agenda is already 6 days late. Is there going to be an agenda posted? Should we start a major issues list now? - import-by-revision (revision identification, etc.) - module/submodule change control rules - leafref and keyref - feature and if-feature I would be thrilled if I left D.C. knowing the NETMOD WG had really put a lot of thought into these 4 topics and really nailed the solution. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 08:46: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 3620D28C18D; Tue, 30 Sep 2008 08:46:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C3D3A6B54 for ; Tue, 30 Sep 2008 08:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 rPXchyP9dlSe for ; Tue, 30 Sep 2008 08:45:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8A9F93A6B92 for ; Tue, 30 Sep 2008 08:45:15 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61794C0053; Tue, 30 Sep 2008 17:45:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4+0woDtCI0t6; Tue, 30 Sep 2008 17:45:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 953FEC004F; Tue, 30 Sep 2008 17:45:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D25F27D6B17; Tue, 30 Sep 2008 17:45:22 +0200 (CEST) Date: Tue, 30 Sep 2008 17:45:22 +0200 From: Juergen Schoenwaelder To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" Message-ID: <20080930154522.GA25764@elstar.local> Mail-Followup-To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Sep 30, 2008 at 06:24:13PM +0300, Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > Yes. So an alternative is to define basic concepts as well > as extensions in own groupings and augment all the places > one by one where an extension makes sense. > > module B { > grouping NetworkInterface { > // ... > } > // ... > } > module X { > grouping HighCapacityInterfaceExtension { > list HighCapacityInterface { > // ... > } > } > augment "B:/controller/interfaces" { > use HighCapacityInterfaceExtension; > } > augment "B:/transceiver/interfaces" > use HighCapacityInterfaceExtension; > } > // .... > } Yes, this makes it decidable for tools where the extension applies and where not. And with the when statement in place, you might even be able to express further constraints when the extension makes sense. > As discussed with Balazs in Dublin, using a list > as base element in the grouping could help > to identify extensions and avoid name clashes. I do not see the name clash problem since the added XML elements exist in the XML namespace associated with module X and not in the XML namespace associated with module B. I am not sure why a list is needed. Balazs, am I missing something? /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 Sep 30 10:28:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201F03A6B1D; Tue, 30 Sep 2008 10:28:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E525C3A6BB9 for ; Tue, 30 Sep 2008 10:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f5ZIOM4oJXM for ; Tue, 30 Sep 2008 10:28:48 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 4A7613A6B1D for ; Tue, 30 Sep 2008 10:28:47 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA25116 for ; Tue, 30 Sep 2008 13:29:07 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA23997 for ; Tue, 30 Sep 2008 13:29:06 -0400 (EDT) Message-Id: <200809301729.NAA23997@adminfs.snmp.com> To: netmod@ietf.org Date: Tue, 30 Sep 2008 13:29:06 -0400 From: David Reid Subject: [netmod] read-create access X-BeenThere: netmod@ietf.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 SMIv2's addition of read-create access was helpful to code generators to know what code to generate to handle a row create attempt. An attempt to create a row in a read-write table generates an error response while an attempt to create a row in a read-create table creates a new row (if all the other constraints are met). I'd like to automatically generate similar code from yang, but the only information I have is config true/false. Is there a way to know if new list entries can be created that I'm not seeing? If not, would it be useful to have a substatement under the list statement which would indicate if new list entries can be created? Or maybe extend the config statement in some way? -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 12:08: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 222C43A67EF; Tue, 30 Sep 2008 12:08:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E5F3A6B2F for ; Tue, 30 Sep 2008 12:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.258, 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 OsN4fw1lIfxZ for ; Tue, 30 Sep 2008 12:08:15 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8E4123A6A00 for ; Tue, 30 Sep 2008 12:08:15 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D1F4676C322; Tue, 30 Sep 2008 21:08:35 +0200 (CEST) Date: Tue, 30 Sep 2008 21:10:38 +0200 (CEST) Message-Id: <20080930.211038.186655946.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E23343.8070806@netconfcentral.com> References: <200809292137.RAA23242@adminfs.snmp.com> <48E23343.8070806@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] leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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: > a leafref might be better still: > > notification link-failure { > description "A link failure has been detected"; > leaf if-index { > type leafref { > path "/interfaces/interface/if-index"; > } > } > leaf if-name { > type keyref { > path "/interfaces/interface/name"; > } > } > } > > (IMO, YANG should have leafref instead of keyref.) Shouldn't the leafref path be "/interfaces/interface[name=../if-name]/if-index"; Or would a leafref be allowed to have wildcards? If so, what does such a wildcard mean? I can clearly see the use case in notifications (although using these expressions might be a bit cumbersome - a long time ago we talked about an alternatove syntax, I'll see if I can find it). But do you see any use case for leafref for something else? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 13:04: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 E28F728C19C; Tue, 30 Sep 2008 13:04:37 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C82A28C10C for ; Tue, 30 Sep 2008 13:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.098, 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 PUKonTF0mfE2 for ; Tue, 30 Sep 2008 13:04:36 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 0EE1928C193 for ; Tue, 30 Sep 2008 13:04:35 -0700 (PDT) Received: (qmail 7620 invoked from network); 30 Sep 2008 20:04:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 30 Sep 2008 20:04:51 -0000 X-YMail-OSG: iwQL0gkVM1lwJFiAgnqBx0XL8bfkU5N8Uh_GEdBrvyk1K7JaoYSPrk3CzBltjsy9NaG35OU8Tn6UAh9Lodnt4aKdvIg9ACnZ6ncK18cL5uu0p46mgRQgCeGIohZejFpAxJw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E28662.2030802@netconfcentral.com> Date: Tue, 30 Sep 2008 13:04:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, ..... > module B { > grouping NetworkInterface { > // ... > } > // ... > } > module X { > grouping HighCapacityInterfaceExtension { > list HighCapacityInterface { > // ... > } > } > augment "B:/controller/interfaces" { > use HighCapacityInterfaceExtension; > } > augment "B:/transceiver/interfaces" > use HighCapacityInterfaceExtension; > } > // .... > } > .... The curly brace placement is important here. Maybe I am missing too many details, but this looks like normal augments -- what we have now. The augment statements are outside the HighCap.. grouping. Module X in this example has 3 top-level body-stmts. I do not see how the NetworkInterface grouping relates to the HighCapacityInterfaceExtension grouping. There is no 'uses' for 'NetworkInterface'. It would help to see a complete example and the fully expanded results of all augments and uses. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Sep 30 13:19: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 726193A6B23; Tue, 30 Sep 2008 13:19:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2D13A6B23 for ; Tue, 30 Sep 2008 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 dMYB1bAGgogV for ; Tue, 30 Sep 2008 13:19:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 854273A6B2B for ; Tue, 30 Sep 2008 13:19:04 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96267C0057; Tue, 30 Sep 2008 22:17:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ts3-fx9hW7P9; Tue, 30 Sep 2008 22:17:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA6D4C0058; Tue, 30 Sep 2008 22:17:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3625C7D7032; Tue, 30 Sep 2008 22:17:08 +0200 (CEST) Date: Tue, 30 Sep 2008 22:17:08 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080930201708.GA26238@elstar.local> Mail-Followup-To: Andy Bierman , "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> <48E28662.2030802@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48E28662.2030802@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Sep 30, 2008 at 01:04:50PM -0700, Andy Bierman wrote: > Maybe I am missing too many details, but this > looks like normal augments -- what we have now. Yes - I thought that this was his conclusion; we live with augmentations as they are defined today (and they require to be explicit about what is being augmented). /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 Sep 30 23:36:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2A23A687F; Tue, 30 Sep 2008 23:36:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E07E3A687F for ; Tue, 30 Sep 2008 23:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_20=-0.74, 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 DZLb2aAQswSn for ; Tue, 30 Sep 2008 23:36:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4381D3A6864 for ; Tue, 30 Sep 2008 23:36:45 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 10F82D800CC for ; Wed, 1 Oct 2008 08:37:08 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080930201708.GA26238@elstar.local> References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> <48E28662.2030802@netconfcentral.com> <20080930201708.GA26238@elstar.local> Organization: CESNET Date: Wed, 01 Oct 2008 08:37:07 +0200 Message-Id: <1222843027.8357.17.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMOadCAzMC4gMDkuIDIwMDggdiAyMjoxNyAr MDIwMDoKPiBPbiBUdWUsIFNlcCAzMCwgMjAwOCBhdCAwMTowNDo1MFBNIC0wNzAwLCBBbmR5IEJp ZXJtYW4gd3JvdGU6Cj4gCj4gPiBNYXliZSBJIGFtIG1pc3NpbmcgdG9vIG1hbnkgZGV0YWlscywg YnV0IHRoaXMKPiA+IGxvb2tzIGxpa2Ugbm9ybWFsIGF1Z21lbnRzIC0tIHdoYXQgd2UgaGF2ZSBu b3cuCj4gCj4gWWVzIC0gSSB0aG91Z2h0IHRoYXQgdGhpcyB3YXMgaGlzIGNvbmNsdXNpb247IHdl IGxpdmUgd2l0aAo+IGF1Z21lbnRhdGlvbnMgYXMgdGhleSBhcmUgZGVmaW5lZCB0b2RheSAoYW5k IHRoZXkgcmVxdWlyZSB0bwo+IGJlIGV4cGxpY2l0IGFib3V0IHdoYXQgaXMgYmVpbmcgYXVnbWVu dGVkKS4KCkkgd29uZGVyIC0gYXJlIHRoZXJlIGFueSB1c2UgY2FzZXMgd2hlcmUgdGhpcyBpcyBu b3Qgc3VmZmljaWVudD8KCkxhZGEKCj4gCj4gL2pzCj4gCi0tIApMYWRpc2xhdiBMaG90a2EsIENF U05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Tue Sep 30 23:49: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 0ACD83A69FF; Tue, 30 Sep 2008 23:49:51 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CAA3A6BBC for ; Tue, 30 Sep 2008 23:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqLlkKY1SjC2 for ; Tue, 30 Sep 2008 23:49:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AAA473A699C for ; Tue, 30 Sep 2008 23:49:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EC0F421396; Wed, 1 Oct 2008 08:50:08 +0200 (CEST) X-AuditID: c1b4fb3e-a7682bb000007a96-d8-48e31da060e2 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D9E242136B; Wed, 1 Oct 2008 08:50:08 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 08:50:01 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 08:50:01 +0200 Message-ID: <48E31DC0.7070209@ericsson.com> Date: Wed, 01 Oct 2008 08:50:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200809292137.RAA23242@adminfs.snmp.com> <48E23343.8070806@netconfcentral.com> <20080930.211038.186655946.mbj@tail-f.com> In-Reply-To: <20080930.211038.186655946.mbj@tail-f.com> X-OriginalArrivalTime: 01 Oct 2008 06:50:01.0630 (UTC) FILETIME=[ED5D13E0:01C92391] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] leafref X-BeenThere: netmod@ietf.org 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, Previously we had a basic question about leafrefs: Is a leafref A) a pointer to a leaf (something like the instance identifier) with a value describing the path to the leaf in the data tree or B) is it a link (like a linux soft-link) so it will actually carry the value stored in the referenced leaf? I could see the use for both. Balazs Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> a leafref might be better still: >> >> notification link-failure { >> description "A link failure has been detected"; >> leaf if-index { >> type leafref { >> path "/interfaces/interface/if-index"; >> } >> } >> leaf if-name { >> type keyref { >> path "/interfaces/interface/name"; >> } >> } >> } >> >> (IMO, YANG should have leafref instead of keyref.) > > Shouldn't the leafref path be > > "/interfaces/interface[name=../if-name]/if-index"; > > Or would a leafref be allowed to have wildcards? If so, what does > such a wildcard mean? > > I can clearly see the use case in notifications (although using these > expressions might be a bit cumbersome - a long time ago we talked > about an alternatove syntax, I'll see if I can find it). But do you > see any use case for leafref for something else? > > > > /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 Wed Oct 1 01:21: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 92E5E3A69CB; Wed, 1 Oct 2008 01:21:34 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70DB3A6C07 for ; Wed, 1 Oct 2008 01:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8GI9k+iGR4k for ; Wed, 1 Oct 2008 01:21:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BFEAB3A6A1E for ; Wed, 1 Oct 2008 01:21:31 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7FD1620224; Wed, 1 Oct 2008 10:21:51 +0200 (CEST) X-AuditID: c1b4fb3e-a9686bb000007a96-0f-48e3331f71c7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6443D2133A; Wed, 1 Oct 2008 10:21:51 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 10:21:49 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 10:21:49 +0200 Message-ID: <48E33344.6020009@ericsson.com> Date: Wed, 01 Oct 2008 10:22:28 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> <20080930154522.GA25764@elstar.local> In-Reply-To: <20080930154522.GA25764@elstar.local> X-OriginalArrivalTime: 01 Oct 2008 08:21:49.0147 (UTC) FILETIME=[C0197AB0:01C9239E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Sep 30, 2008 at 06:24:13PM +0300, Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > >> Yes. So an alternative is to define basic concepts as well >> as extensions in own groupings and augment all the places >> one by one where an extension makes sense. >> >> module B { >> grouping NetworkInterface { >> // ... >> } >> // ... >> } >> module X { >> grouping HighCapacityInterfaceExtension { >> list HighCapacityInterface { >> // ... >> } >> } >> augment "B:/controller/interfaces" { >> use HighCapacityInterfaceExtension; >> } >> augment "B:/transceiver/interfaces" >> use HighCapacityInterfaceExtension; >> } >> // .... >> } > > Yes, this makes it decidable for tools where the extension applies and > where not. And with the when statement in place, you might even be > able to express further constraints when the extension makes sense. > >> As discussed with Balazs in Dublin, using a list >> as base element in the grouping could help >> to identify extensions and avoid name clashes. > > I do not see the name clash problem since the added XML elements exist > in the XML namespace associated with module X and not in the XML > namespace associated with module B. I am not sure why a list is > needed. Balazs, am I missing something? > > /js > I don't exactly remember the discussion. I don't see any naming clashes either. This solution allows you to check in the on-the-wire XML which basic grouping/list and which extension list/grouping is present, as the list itself carries the name of the grouping (only by a self-imposed naming convention). Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 1 01:39: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 EC6E73A692D; Wed, 1 Oct 2008 01:39:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD623A6BDA for ; Wed, 1 Oct 2008 01:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TGpx3VdYioFk for ; Wed, 1 Oct 2008 01:39:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 591DD3A692D for ; Wed, 1 Oct 2008 01:39:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D1D1C0060; Wed, 1 Oct 2008 10:39:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1ZoZDptRwvub; Wed, 1 Oct 2008 10:39:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC309C005F; Wed, 1 Oct 2008 10:39:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3AF667D775B; Wed, 1 Oct 2008 10:39:23 +0200 (CEST) Date: Wed, 1 Oct 2008 10:39:23 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20081001083923.GA26926@elstar.local> Mail-Followup-To: Balazs Lengyel , "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> <20080930154522.GA25764@elstar.local> <48E33344.6020009@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48E33344.6020009@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Oct 01, 2008 at 10:22:28AM +0200, Balazs Lengyel wrote: > This solution allows you to check in the on-the-wire XML which basic > grouping/list and which extension list/grouping is present, as the list > itself carries the name of the grouping (only by a self-imposed naming > convention). Why is this needed? There is a namespace, no? Since I know the modules implemented on a device and their namespaces, I have everything I need to identify the exact definition of something. /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