From netmod-bounces@ietf.org Mon Jun 2 01:58: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 39E133A6C97; Mon, 2 Jun 2008 01:58: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 918B53A6C97 for ; Mon, 2 Jun 2008 01:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8VkkRLOQMYN for ; Mon, 2 Jun 2008 01:58:10 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id C39E53A6C90 for ; Mon, 2 Jun 2008 01:58:10 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 29C071B80C8; Mon, 2 Jun 2008 10:58:10 +0200 (CEST) Date: Mon, 02 Jun 2008 10:59:11 +0200 (CEST) Message-Id: <20080602.105911.94253672.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48417B41.4030409@netconfcentral.com> References: <48417B41.4030409@netconfcentral.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > What does 'ordered-by user;' mean for read-only data or > RPC input or notification content? I think this is similar to the discussion about what 'mandatory' means in these contexts, and we must make sure we address this. ordered-by user means that the order carries information, and I think it makes sense also for read-only data. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 2 07:37: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 7567A3A6B02; Mon, 2 Jun 2008 07:37: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 E0EC93A6B02 for ; Mon, 2 Jun 2008 07:37:25 -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 wPMZHijcOSZI for ; Mon, 2 Jun 2008 07:37:25 -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 E714D3A6BC7 for ; Mon, 2 Jun 2008 07:37:14 -0700 (PDT) Received: (qmail 50742 invoked from network); 2 Jun 2008 14:37:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.242.167 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 2 Jun 2008 14:37:10 -0000 X-YMail-OSG: WbBnH9EVM1l7Oug0aoRsz9iDY2xSZVO3r8e1jtI5sZ24KqzQVtmEYtoGUfrJLCYot17E9xnHZIl72anWcfs4Rrg4YrMyB5JAwH6yZqA36sQSx2WGd.ecxwU8QP31rJbDAgof.saWCa8S6tVQMHV4sA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48440594.7040904@netconfcentral.com> Date: Mon, 02 Jun 2008 07:37:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <48417B41.4030409@netconfcentral.com> <20080602.105911.94253672.mbj@tail-f.com> In-Reply-To: <20080602.105911.94253672.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> What does 'ordered-by user;' mean for read-only data or >> RPC input or notification content? > > I think this is similar to the discussion about what 'mandatory' means > in these contexts, and we must make sure we address this. ordered-by > user means that the order carries information, and I think it makes > sense also for read-only data. > I don't see how the manager can ever specify the order for read-only data. My code is going to reject any operation (other than 'none' implied by default-operation) on read-only data. Are you suggesting the 'key' and 'insert' attributes would be used in a operation somehow? IMO, data presentation order is a manager station problem. The agent should not be burdened with sortable read-only tables. User ordering exists because it makes sense for some configuration data, like the DNS example in the draft. > > > /martin > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 2 10:05: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 E6DEB3A6D0C; Mon, 2 Jun 2008 10:05:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601CC3A6D0A for ; Mon, 2 Jun 2008 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KekMvE3SRQ4j for ; Mon, 2 Jun 2008 10:05:49 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 8715928C27B for ; Mon, 2 Jun 2008 10:00:15 -0700 (PDT) Received: (qmail 23098 invoked from network); 2 Jun 2008 17:00:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.242.167 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 2 Jun 2008 17:00:15 -0000 X-YMail-OSG: vEYHKegVM1kVbvANf.Lh9E7i_PZkbxioqEMG9zN21UtJcX32oLcOiD2awLUMf7MOcm6jdchWPZdUBFH5T7xDMA06SlJn1MwgYCyVepf9dQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4844271E.7070309@netconfcentral.com> Date: Mon, 02 Jun 2008 10:00:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <48417B41.4030409@netconfcentral.com> <20080602.105911.94253672.mbj@tail-f.com> In-Reply-To: <20080602.105911.94253672.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: >.... > I think this is similar to the discussion about what 'mandatory' means > in these contexts, and we must make sure we address this. IMO, the real issue here is reuse of groupings, because that is where this sort of 'no-op' statement really shows up. Should 'uses' be a special case, where the 'no-op' statements are ignored as the grouping contents replace the uses node within a notification or RPC i/o? (Current implementations do this) The other real issue here is 'leafref' and 'noderef'. Should notifications (and RPC i/o) use some sort of pointer mechanism instead of including data that is intended for the configuration database? This could mean a lot of cut-and-paste, which would be bad. The upside is that it is better to be precise about the data definitions. Something more constrained than 'anyxml' which means "this node is a read-only copy of that container or list over there". >... > /martin > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 3 00:33:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283693A6784; Tue, 3 Jun 2008 00:33:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8CE3A6AC0 for ; Tue, 3 Jun 2008 00:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWhzGvr-EDFW for ; Tue, 3 Jun 2008 00:33:31 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id AB1123A6784 for ; Tue, 3 Jun 2008 00:33:31 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 6AAD01B80CE; Tue, 3 Jun 2008 09:33:32 +0200 (CEST) Date: Tue, 03 Jun 2008 09:34:34 +0200 (CEST) Message-Id: <20080603.093434.172638393.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48440594.7040904@netconfcentral.com> References: <48417B41.4030409@netconfcentral.com> <20080602.105911.94253672.mbj@tail-f.com> <48440594.7040904@netconfcentral.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > >> What does 'ordered-by user;' mean for read-only data or > >> RPC input or notification content? > > > > I think this is similar to the discussion about what 'mandatory' means > > in these contexts, and we must make sure we address this. ordered-by > > user means that the order carries information, and I think it makes > > sense also for read-only data. > > > > I don't see how the manager can ever specify the order for > read-only data. My code is going to reject any > operation (other than 'none' implied by default-operation) > on read-only data. Are you suggesting the 'key' and 'insert' > attributes would be used in a operation somehow? No, I'm suggesting that the concept of an order with semantic meaning might be useful also for read-only data. However, 'ordered-by user' is a bad description for this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 3 00:48: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 62E0C28C0D8; Tue, 3 Jun 2008 00:48: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 CF2A328C0E2 for ; Tue, 3 Jun 2008 00:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBcAPDLrCe1k for ; Tue, 3 Jun 2008 00:48:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id BA0F33A6BD0 for ; Tue, 3 Jun 2008 00:48:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 959B71B80C5; Tue, 3 Jun 2008 09:48:06 +0200 (CEST) Date: Tue, 03 Jun 2008 09:49:09 +0200 (CEST) Message-Id: <20080603.094909.49496441.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4844271E.7070309@netconfcentral.com> References: <48417B41.4030409@netconfcentral.com> <20080602.105911.94253672.mbj@tail-f.com> <4844271E.7070309@netconfcentral.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] yang-00, ordered-by statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > >.... > > I think this is similar to the discussion about what 'mandatory' means > > in these contexts, and we must make sure we address this. > > > IMO, the real issue here is reuse of groupings, because that > is where this sort of 'no-op' statement really shows up. > > Should 'uses' be a special case, where the 'no-op' statements > are ignored as the grouping contents replace the uses node > within a notification or RPC i/o? (Current implementations do this) I think 'uses' will have to do this, otherwise we will see N versions of each grouping, each version differing in the combination of 'config', 'ordered-by', 'mandatory' statements: grouping address { leaf ip { mandatory true; } leaf port; } grouping address-no-mandatory { leaf ip; leaf port; } This is clearly not optimal. But the question is if these statements are ignored only in 'uses', but errors if they are specified inline? container foo { config false; leaf bar { mandatory true; // error or not? } I think that the spec can say that these statements are ignored, and let the tools give warnings to the user if they want to. > The other real issue here is 'leafref' and 'noderef'. > Should notifications (and RPC i/o) use some sort of pointer > mechanism instead of including data that is intended for > the configuration database? This could mean a lot of > cut-and-paste, which would be bad. The upside is that > it is better to be precise about the data definitions. > Something more constrained than 'anyxml' which means > "this node is a read-only copy of that container or list > over there". If you just want a ref, you can always use an instance-identifier. But if you want to include the data in the notification, you currently have to do some copy-and-paste in the data model. Is this something we should try to find a solution for? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 4 02:24: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 D190D3A6C5F; Wed, 4 Jun 2008 02:24: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 225163A6C5F for ; Wed, 4 Jun 2008 02:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_72=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 HLwH3qdM+JPV for ; Wed, 4 Jun 2008 02:24:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6FBF03A68BD for ; Wed, 4 Jun 2008 02:24:19 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id F0D8AD800CA for ; Wed, 4 Jun 2008 11:24:21 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 04 Jun 2008 11:24:21 +0200 Message-Id: <1212571461.6193.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Subject: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, draft-ietf-netmod-yang-00 says: "References to definitions in the local module MAY use the prefix notation." The use of local prefix can be seen e.g., in inet-types.yang: typedef ip-address { type union { type inet:ipv4-address; type inet:ipv6-address; } ... } typedef ipv4-address { ... } Equivalently, "type ipv[46]-address;" could be used, without the local prefix. I think this dichotomy is confusing and inconsistent since 1. The typedef'ed name cannot have the prefix. 2. When referencing names from external modules, one can only get to top-level definitions whereas with the local prefix names in all scopes can be referenced. My suggestion is to remove the possibility of using the local prefix entirely (does it help anything?), or at least allow it only for referencing top-level definitions in the local module. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 4 07:30: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 0054528C1D1; Wed, 4 Jun 2008 07:30: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 6053528C1D1 for ; Wed, 4 Jun 2008 07:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=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 4NEw+bdjcoyg for ; Wed, 4 Jun 2008 07:30:55 -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 1247128C1DE for ; Wed, 4 Jun 2008 07:30:20 -0700 (PDT) Received: (qmail 75564 invoked from network); 4 Jun 2008 14:30:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.242.167 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 4 Jun 2008 14:30:18 -0000 X-YMail-OSG: W9ffX_0VM1kfQ0Uu31foG7qFXIBD4DqKF4uUzhmQ1BFPOPLwgvhIsqxCjeIUNnRyLci.wD36v7u9h.Zmvsk0_HLCOzLgya6t0KPszv0xfSS.1KZ2rC7XSfav8bjjr.mmKTE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4846A6F8.5000809@netconfcentral.com> Date: Wed, 04 Jun 2008 07:30:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <1212571461.6193.18.camel@missotis> In-Reply-To: <1212571461.6193.18.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > > draft-ietf-netmod-yang-00 says: > "References to definitions in the local module MAY use the prefix > notation." > > The use of local prefix can be seen e.g., in inet-types.yang: > > typedef ip-address { > type union { > type inet:ipv4-address; > type inet:ipv6-address; > } > ... > } > > typedef ipv4-address { > ... > } > > Equivalently, "type ipv[46]-address;" could be used, without the local > prefix. > > I think this dichotomy is confusing and inconsistent since > > 1. The typedef'ed name cannot have the prefix. > The prefix is not used in any definitions in this manner. Why is this a problem? > 2. When referencing names from external modules, one can only get to > top-level definitions whereas with the local prefix names in all scopes > can be referenced. > This has nothing to do with prefixes. Only the top level identifiers are exported. The nodes /A/foo and /B/foo are not the same, and 'foo' is not required to be unique (outside its sibling set). You cannot export 'foo' on its own, prefix or not. Within a module, only the local typedefs and groupings within the direct ancestor nodes are visible. This is extended to the ancestors of the grouping, if the current node is a 'uses-stmt'. It is not 'all scopes'. You cannot override a typedef or grouping name in this 'definition path', but the same name can be used for multiple definitions in different paths. (Just like C and just as simple to implement :-) > My suggestion is to remove the possibility of using the local prefix > entirely (does it help anything?), or at least allow it only for > referencing top-level definitions in the local module. Phil had a suggestion previously to always use the local prefix. Now you are suggesting to never use the local prefix. I don't really care that much. It is half a line of code to make sure the prefix given is not the local prefix (except inside submodules ;-). The current solution is fine with me. BTW, I prefer the 'SMIv2 way' of listing all imported identifiers in the imports section, and never use prefixes ever. There are different techniques to achieve the same 'future-proofing' that the prefix provides, and it is subjective which technique one might prefer. > > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 4 11:54: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 0EE533A68A9; Wed, 4 Jun 2008 11:54: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 1E1193A68A9 for ; Wed, 4 Jun 2008 11:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_72=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 rhimILJjTHzd for ; Wed, 4 Jun 2008 11:54:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 327D63A6CDA for ; Wed, 4 Jun 2008 11:54:36 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0C862D800CA; Wed, 4 Jun 2008 20:54:40 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4846A6F8.5000809@netconfcentral.com> References: <1212571461.6193.18.camel@missotis> <4846A6F8.5000809@netconfcentral.com> Organization: CESNET Date: Wed, 04 Jun 2008 20:54:39 +0200 Message-Id: <1212605679.10140.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IFN0IDA0LiAwNi4gMjAwOCB2IDA3OjMwIC0wNzAwOgo+ID4g Cj4gPiAxLiBUaGUgdHlwZWRlZidlZCBuYW1lIGNhbm5vdCBoYXZlIHRoZSBwcmVmaXguCj4gPiAK PiAKPiAKPiBUaGUgcHJlZml4IGlzIG5vdCB1c2VkIGluIGFueSBkZWZpbml0aW9ucyBpbiB0aGlz IG1hbm5lci4KPiBXaHkgaXMgdGhpcyBhIHByb2JsZW0/CgpTaW5jZSB0aGUgZGVmaW5pdGlvbiBh bmQgaXRzIHJlZmVyZW5jZSB1c2UgZGlmZmVyZW50IG5hbWVzLgoKPiAKPiA+IDIuIFdoZW4gcmVm ZXJlbmNpbmcgbmFtZXMgZnJvbSBleHRlcm5hbCBtb2R1bGVzLCBvbmUgY2FuIG9ubHkgZ2V0IHRv Cj4gPiB0b3AtbGV2ZWwgZGVmaW5pdGlvbnMgd2hlcmVhcyB3aXRoIHRoZSBsb2NhbCBwcmVmaXgg bmFtZXMgaW4gYWxsIHNjb3Blcwo+ID4gY2FuIGJlIHJlZmVyZW5jZWQuCj4gPiAKPiAKPiBUaGlz IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggcHJlZml4ZXMuCj4gT25seSB0aGUgdG9wIGxldmVsIGlk ZW50aWZpZXJzIGFyZSBleHBvcnRlZC4KPiBUaGUgbm9kZXMgL0EvZm9vIGFuZCAvQi9mb28gYXJl IG5vdCB0aGUgc2FtZSwgYW5kICdmb28nCj4gaXMgbm90IHJlcXVpcmVkIHRvIGJlIHVuaXF1ZSAo b3V0c2lkZSBpdHMgc2libGluZyBzZXQpLgo+IFlvdSBjYW5ub3QgZXhwb3J0ICdmb28nIG9uIGl0 cyBvd24sIHByZWZpeCBvciBub3QuCgpJIGtub3csIGJ1dCBpdCBtYWtlcyB0aGUgc2VtYW50aWNz IG9mIHByZWZpeC1xdWFsaWZpZWQgcmVmZXJlbmNlcyB0bwpleHRlcm5hbCBzeW1ib2xzIGRpZmZl cmVudCBmcm9tIHJlZmVyZW5jZXMgdG8gbG9jYWwgb25lcy4gSW1hZ2luZSBhCm1vZHVsZSB0aGF0 IGltcG9ydHMgaXRzZWxmIHdpdGggYSBkaWZmZXJlbnQgcHJlZml4IChidHcuIGlzIHRoaXMKYWxs b3dlZD8pLgoKPiA+IE15IHN1Z2dlc3Rpb24gaXMgdG8gcmVtb3ZlIHRoZSBwb3NzaWJpbGl0eSBv ZiB1c2luZyB0aGUgbG9jYWwgcHJlZml4Cj4gPiBlbnRpcmVseSAoZG9lcyBpdCBoZWxwIGFueXRo aW5nPyksIG9yIGF0IGxlYXN0IGFsbG93IGl0IG9ubHkgZm9yCj4gPiByZWZlcmVuY2luZyB0b3At bGV2ZWwgZGVmaW5pdGlvbnMgaW4gdGhlIGxvY2FsIG1vZHVsZS4KPiAKPiBQaGlsIGhhZCBhIHN1 Z2dlc3Rpb24gcHJldmlvdXNseSB0byBhbHdheXMgdXNlIHRoZSBsb2NhbCBwcmVmaXguCgpBciBs ZWFzdCB0aGlzIHdvdWxkIGJlIGNvbnNpc3RlbnQsIGJ1dCBJIGZhaWwgdG8gc2VlIHRoZSBpbmZv cm1hdGlvbgp2YWx1ZSB0aGF0IHRoZSBwcmVmaXggY2FycmllcyBzaW5jZSBldmVyeSBzdWNoIHJl ZmVyZW5jZSBzdGFydHMgd2l0aCBhCmtleXdvcmQgKHVzZXMgb2YgdHlwZSkgdGhhdCBzaWduYWxz IHZlcnkgY2xlYXJseSB3aGF0IHRoZSBuZXh0IHRva2VuIGlzLgpFeHRlbnNpb25zIGFyZSBkaWZm ZXJlbnQgaW4gdGhpcyByZXNwZWN0LCBzbyB3aXRoIHRoZW0gaXQgbWFrZXMgc2Vuc2UgdG8KYWx3 YXlzIHJlcXVpcmUgcHJlZml4ZXMuCgpJIGFtIG5vdCBzYXlpbmcgaXQncyBhIGJpZyBwcm9ibGVt LCBidXQgcmF0aGVyIGFuIHVubmVjZXNzYXJ5CmNvbXBsaWNhdGlvbi4KCkxhZGEKCi0tIApMYWRp c2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRt b2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Jun 5 00:50: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 CDD8C3A6BD6; Thu, 5 Jun 2008 00:50: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 97E8E28C168 for ; Thu, 5 Jun 2008 00:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=0.300, 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 aPgHOOTl0tV9 for ; Thu, 5 Jun 2008 00:50:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5C5C83A6D2F for ; Thu, 5 Jun 2008 00:48:20 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id AC5F9D800CB for ; Thu, 5 Jun 2008 09:48:24 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Thu, 05 Jun 2008 09:48:24 +0200 Message-Id: <1212652104.6075.53.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Subject: [netmod] keeping track of proposed changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, my question may follow from the fact that I have little experience with IETF working group workflows, but anyway: quite a few proposals for changes in YANG etc. have been raised and discussed in the mailing list but I am not sure - does anyone keep track of them and how will they be resolved? Perhaps we should enter them into a request tracker? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 5 00:50: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 DD3993A6BF8; Thu, 5 Jun 2008 00:50:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A10A3A6BF8 for ; Thu, 5 Jun 2008 00:50: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 88lpot97-SFN for ; Thu, 5 Jun 2008 00:50:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2AC043A6D34 for ; Thu, 5 Jun 2008 00:48:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A60AC0066; Thu, 5 Jun 2008 09:48:37 +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 YrDc3U3xeeW6; Thu, 5 Jun 2008 09:48:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 682F9C006B; Thu, 5 Jun 2008 09:48:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6279B5AEFCD; Thu, 5 Jun 2008 09:48:27 +0200 (CEST) Date: Thu, 5 Jun 2008 09:48:27 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080605074827.GE22539@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1212571461.6193.18.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1212571461.6193.18.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names 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, Jun 04, 2008 at 11:24:21AM +0200, Ladislav Lhotka wrote: > My suggestion is to remove the possibility of using the local prefix > entirely (does it help anything?), or at least allow it only for > referencing top-level definitions in the local module. I do not get the point. I assume it takes extra code to disallow the use of the local prefix and I don't really understand which problem is getting fixed by not allowing local prefixes. /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 Jun 5 01:10: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 851A03A68E0; Thu, 5 Jun 2008 01:10: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 485323A68E0 for ; Thu, 5 Jun 2008 01:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=0.200, 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 L07r+M4VQgHE for ; Thu, 5 Jun 2008 01:10:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0382A3A6BE4 for ; Thu, 5 Jun 2008 01:10:49 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 97674D800CE for ; Thu, 5 Jun 2008 10:10:54 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20080605074827.GE22539@elstar.local> References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> Organization: CESNET Date: Thu, 05 Jun 2008 10:10:54 +0200 Message-Id: <1212653454.6075.67.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Subject: Re: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMSMdCAwNS4gMDYuIDIwMDggdiAwOTo0OCAr MDIwMDoKPiBPbiBXZWQsIEp1biAwNCwgMjAwOCBhdCAxMToyNDoyMUFNICswMjAwLCBMYWRpc2xh diBMaG90a2Egd3JvdGU6Cj4gIAo+ID4gTXkgc3VnZ2VzdGlvbiBpcyB0byByZW1vdmUgdGhlIHBv c3NpYmlsaXR5IG9mIHVzaW5nIHRoZSBsb2NhbCBwcmVmaXgKPiA+IGVudGlyZWx5IChkb2VzIGl0 IGhlbHAgYW55dGhpbmc/KSwgb3IgYXQgbGVhc3QgYWxsb3cgaXQgb25seSBmb3IKPiA+IHJlZmVy ZW5jaW5nIHRvcC1sZXZlbCBkZWZpbml0aW9ucyBpbiB0aGUgbG9jYWwgbW9kdWxlLgo+IAo+IEkg ZG8gbm90IGdldCB0aGUgcG9pbnQuIEkgYXNzdW1lIGl0IHRha2VzIGV4dHJhIGNvZGUgdG8gZGlz YWxsb3cgdGhlCj4gdXNlIG9mIHRoZSBsb2NhbCBwcmVmaXggYW5kIEkgZG9uJ3QgcmVhbGx5IHVu ZGVyc3RhbmQgd2hpY2ggcHJvYmxlbSBpcwoKSXQncyB0aGUgb3RoZXIgd2F5IGFyb3VuZCAtIGlm IHRoZSBwcmVmaXhlcyB3ZXJlIG9ubHkgcmVzZXJ2ZWQgZm9yCnJlZmVycmluZyB0byBleHRlcm5h bCBkZWZpbml0aW9ucywgdGhlIGNvZGUgY2FuIGltbWVkaWF0ZWx5IGxvb2sgdXAgdGhlCm1vZHVs ZSBjb3JyZXNwb25kaW5nIHRvIHRoZSBwcmVmaXggYW5kIHRoZSBkZWZpbml0aW9uIGluIGl0LiBB cyBpdCBpcwpub3csIHRoZSBjb2RlIGhhcyB0byBjaGVjayB3aGV0aGVyIHRoZSBwcmVmaXggaXMg bG9jYWwgYW5kIGp1c3QgaWdub3JlCml0IGlmIGl0IGlzIHRoZSBjYXNlLiBOb3QgYSBiaWcgZGVh bCBvZiBjb3Vyc2UuCgo+IGdldHRpbmcgZml4ZWQgYnkgbm90IGFsbG93aW5nIGxvY2FsIHByZWZp eGVzLgoKSSB3aWxsIGFuc3dlciBieSBhbm90aGVyIHF1ZXN0aW9uOiBXaGF0IHByb2JsZW0gaXMg Z2V0dGluZyBmaXhlZCBieQphbGxvd2luZyBsb2NhbCBwcmVmaXhlcz8KCkxhZGEKCj4gCj4gL2pz Cj4gCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxp bmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Jun 5 01:25: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 96E2C3A6B78; Thu, 5 Jun 2008 01:25: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 7614A3A6C6C for ; Thu, 5 Jun 2008 01:25:26 -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.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpeiy+c8LoSa for ; Thu, 5 Jun 2008 01:25:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E38C83A6D3C for ; Thu, 5 Jun 2008 01:22:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FF0EC006A; Thu, 5 Jun 2008 10:22:45 +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 qpiCG7dvsPDV; Thu, 5 Jun 2008 10:22:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0ECDC006E; Thu, 5 Jun 2008 10:22:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C23D75AF1E3; Thu, 5 Jun 2008 10:22:38 +0200 (CEST) Date: Thu, 5 Jun 2008 10:22:38 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080605082238.GA22938@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1212653454.6075.67.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names 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, Jun 05, 2008 at 10:10:54AM +0200, Ladislav Lhotka wrote: > It's the other way around - if the prefixes were only reserved for > referring to external definitions, the code can immediately look up > the module corresponding to the prefix and the definition in it. As > it is now, the code has to check whether the prefix is local and > just ignore it if it is the case. Not a big deal of course. OK, depends on how you implement things. If I get a prefix, I lookup the module and it does not matter whether the prefix points to the local module or some external module. > I will answer by another question: What problem is getting fixed by > allowing local prefixes? Wrong question. The correct question to ask is: What problem is getting fixed by disallowing local prefixes? ;-) My point is that it is unambiguous what foo:bar means in the module with prefix foo and hence I so far I see no reason to declare this illegal. /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 Jun 5 02:31: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 37FF33A6BD2; Thu, 5 Jun 2008 02:31: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 5A87F3A689D for ; Thu, 5 Jun 2008 02:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g87QxtYh30z8 for ; Thu, 5 Jun 2008 02:31:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 626FE3A6BD2 for ; Thu, 5 Jun 2008 02:31:07 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B71FAD800CE; Thu, 5 Jun 2008 11:31:09 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080605082238.GA22938@elstar.local> References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@elstar.local> Organization: CESNET Date: Thu, 05 Jun 2008 11:31:09 +0200 Message-Id: <1212658269.6075.133.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMSMdCAwNS4gMDYuIDIwMDggdiAxMDoyMiAr MDIwMDoKPiBNeSBwb2ludCBpcyB0aGF0IGl0IGlzIHVuYW1iaWd1b3VzIHdoYXQgZm9vOmJhciBt ZWFucyBpbiB0aGUgbW9kdWxlCj4gd2l0aCBwcmVmaXggZm9vIGFuZCBoZW5jZSBJIHNvIGZhciBJ IHNlZSBubyByZWFzb24gdG8gZGVjbGFyZSB0aGlzCj4gaWxsZWdhbC4KCkkgYW0gYXBwcm9hY2hp bmcgaXQgZnJvbSB0aGUgcG9zaXRpb24gdGhhdCBZQU5HIGlzIG5vdCB5ZXQgc29tZXRoaW5nCmVz dGFibGlzaGVkIGFuZCBzbyBpdCBpcyBJTU8gdXNlZnVsIHRvIGFsc28gYXNrIHdoaWNoIGZlYXR1 cmVzIGNhbiBiZQpyZW1vdmVkLiBTaW5jZSBJIGRvbid0IHNlZSBhbnkgYWRkZWQgdmFsdWUgaW4g dXNpbmcgdGhlIGxvY2FsIHByZWZpeCwKaXQncyBhIGdvb2QgY2FuZGlkYXRlIGZvciByZW1vdmFs LiBUaGlzIGlzIGp1c3QgT2NjYW0ncyByYXpvci4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2Es IENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Jun 5 02:35: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 CEAFA3A6BD2; Thu, 5 Jun 2008 02:35: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 480CB3A6B6A for ; Thu, 5 Jun 2008 02:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PNI-oZUtra9 for ; Thu, 5 Jun 2008 02:35:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0ACD628C254 for ; Thu, 5 Jun 2008 02:34:01 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0482C0079; Thu, 5 Jun 2008 11:34:06 +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 9zm-7DF1Lykp; Thu, 5 Jun 2008 11:33:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDEF5C0077; Thu, 5 Jun 2008 11:33:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C0EB35AF419; Thu, 5 Jun 2008 11:33:54 +0200 (CEST) Date: Thu, 5 Jun 2008 11:33:54 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080605093354.GA23139@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@elstar.local> <1212658269.6075.133.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1212658269.6075.133.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names 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, Jun 05, 2008 at 11:31:09AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v ??t 05. 06. 2008 v 10:22 +0200: > > My point is that it is unambiguous what foo:bar means in the module > > with prefix foo and hence I so far I see no reason to declare this > > illegal. > > I am approaching it from the position that YANG is not yet something > established and so it is IMO useful to also ask which features can be > removed. Since I don't see any added value in using the local prefix, > it's a good candidate for removal. This is just Occam's razor. For me, you are _adding_ a CLR without a sound justification for it. If I can write foo:bar everywhere, why should I not be allowed to use it in the module defining foo? /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 Jun 5 02:48: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 7E5733A63C9; Thu, 5 Jun 2008 02:48: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 EC8963A693D for ; Thu, 5 Jun 2008 02:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl+3JLFVY7ee for ; Thu, 5 Jun 2008 02:48:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0EB1A3A63C9 for ; Thu, 5 Jun 2008 02:48:53 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A32FED800CC; Thu, 5 Jun 2008 11:48:58 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080605093354.GA23139@elstar.local> References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@elstar.local> <1212658269.6075.133.camel@missotis> <20080605093354.GA23139@elstar.local> Organization: CESNET Date: Thu, 05 Jun 2008 11:48:58 +0200 Message-Id: <1212659338.6075.146.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMSMdCAwNS4gMDYuIDIwMDggdiAxMTozMyAr MDIwMDoKPiBPbiBUaHUsIEp1biAwNSwgMjAwOCBhdCAxMTozMTowOUFNICswMjAwLCBMYWRpc2xh diBMaG90a2Egd3JvdGU6Cj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgcD8/Pz9lIHYgPz90IDA1 LiAwNi4gMjAwOCB2IDEwOjIyICswMjAwOgo+ID4gPiBNeSBwb2ludCBpcyB0aGF0IGl0IGlzIHVu YW1iaWd1b3VzIHdoYXQgZm9vOmJhciBtZWFucyBpbiB0aGUgbW9kdWxlCj4gPiA+IHdpdGggcHJl Zml4IGZvbyBhbmQgaGVuY2UgSSBzbyBmYXIgSSBzZWUgbm8gcmVhc29uIHRvIGRlY2xhcmUgdGhp cwo+ID4gPiBpbGxlZ2FsLgo+ID4gCj4gPiBJIGFtIGFwcHJvYWNoaW5nIGl0IGZyb20gdGhlIHBv c2l0aW9uIHRoYXQgWUFORyBpcyBub3QgeWV0IHNvbWV0aGluZwo+ID4gZXN0YWJsaXNoZWQgYW5k IHNvIGl0IGlzIElNTyB1c2VmdWwgdG8gYWxzbyBhc2sgd2hpY2ggZmVhdHVyZXMgY2FuIGJlCj4g PiByZW1vdmVkLiBTaW5jZSBJIGRvbid0IHNlZSBhbnkgYWRkZWQgdmFsdWUgaW4gdXNpbmcgdGhl IGxvY2FsIHByZWZpeCwKPiA+IGl0J3MgYSBnb29kIGNhbmRpZGF0ZSBmb3IgcmVtb3ZhbC4gVGhp cyBpcyBqdXN0IE9jY2FtJ3MgcmF6b3IuCj4gCj4gRm9yIG1lLCB5b3UgYXJlIF9hZGRpbmdfIGEg Q0xSIHdpdGhvdXQgYSBzb3VuZCBqdXN0aWZpY2F0aW9uIGZvciBpdC4KClNvcnJ5LCBJIGFscmVh ZHkgd2FudGVkIHRvIGFzayBmZXcgdGltZXMgd2hhdCBDTFIgbWVhbnMuIFdpa2lwZWRpYSBrbm93 cwppdCBvbmx5IGFzICJDb21tb24gTGFuZ3VhZ2UgUnVudGltZSIuIDotKQoKQnV0IGlmIHdlIHN0 YXJ0ZWQgZnJvbSBhIGNsZWFuIHNsYXRlLCBib3RoIG9wdGlvbnMgLSB3aXRoIGFuZCB3aXRob3V0 CmxvY2FsIHByZWZpeGVzIC0gYmVpbmcgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQsIHRoZSBzaW1w bGVyIG9uZSBzaG91bGQKYmUgcHJlZmVycmVkLgoKPiAKPiBJZiBJIGNhbiB3cml0ZSBmb286YmFy IGV2ZXJ5d2hlcmUsIHdoeSBzaG91bGQgSSBub3QgYmUgYWxsb3dlZCB0byB1c2UKPiBpdCBpbiB0 aGUgbW9kdWxlIGRlZmluaW5nIGZvbz8KCkkgY2FuIGFsc28gcHJlcGVuZCB0aGUgZnVsbCBuYW1l c3BhY2UgdG8gZWFjaCBsb2NhbCBpZGVudGlmaWVyIGFuZCBpdAp3b3VsZCBhbHNvIGJlIHVuYW1i aWd1b3VzLiBTaG91bGQgSSBiZSBhbGxvd2VkIHRvIGRvIHNvPwoKTGFkYQoKLS0gCkxhZGlzbGF2 IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBp ZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jun 5 02:54: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 1507F3A6BD2; Thu, 5 Jun 2008 02:54: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 143873A6BD2 for ; Thu, 5 Jun 2008 02:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xInbqGZ1WiDG for ; Thu, 5 Jun 2008 02:54: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 866683A6C03 for ; Thu, 5 Jun 2008 02:54:23 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0BA5C0073; Thu, 5 Jun 2008 11:54:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4LwWcrY3ckCq; Thu, 5 Jun 2008 11:54: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 63468C0072; Thu, 5 Jun 2008 11:54:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5EAED5AF493; Thu, 5 Jun 2008 11:54:21 +0200 (CEST) Date: Thu, 5 Jun 2008 11:54:21 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080605095421.GB23139@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@elstar.local> <1212658269.6075.133.camel@missotis> <20080605093354.GA23139@elstar.local> <1212659338.6075.146.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1212659338.6075.146.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names 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, Jun 05, 2008 at 11:48:58AM +0200, Ladislav Lhotka wrote: > Sorry, I already wanted to ask few times what CLR means. Wikipedia knows > it only as "Common Language Runtime". :-) Crappy Little Rule > But if we started from a clean slate, both options - with and without > local prefixes - being functionally equivalent, the simpler one should > be preferred. We will not converge... > > If I can write foo:bar everywhere, why should I not be allowed to use > > it in the module defining foo? > > I can also prepend the full namespace to each local identifier and it > would also be unambiguous. Should I be allowed to do so? This is a different subject. Right now, namespaces as prefixes are not legal anywhere in YANG. But yes, if they were legal, I would expect that they are legal everywhere, including the module that defines the namespace. ;-) /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 Jun 5 04:14:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E06028C168; Thu, 5 Jun 2008 04:14: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 5EA5428C168 for ; Thu, 5 Jun 2008 04:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=0.200, 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 TkwB7lOqJdIP for ; Thu, 5 Jun 2008 04:14:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8695C28C19E for ; Thu, 5 Jun 2008 04:14:51 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9E8B2D800C4; Thu, 5 Jun 2008 13:14:56 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080605095421.GB23139@elstar.local> References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@elstar.local> <1212658269.6075.133.camel@missotis> <20080605093354.GA23139@elstar.local> <1212659338.6075.146.camel@missotis> <20080605095421.GB23139@elstar.local> Organization: CESNET Date: Thu, 05 Jun 2008 13:14:56 +0200 Message-Id: <1212664496.6075.166.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMSMdCAwNS4gMDYuIDIwMDggdiAxMTo1NCAr MDIwMDoKPiAKPiBUaGlzIGlzIGEgZGlmZmVyZW50IHN1YmplY3QuIFJpZ2h0IG5vdywgbmFtZXNw YWNlcyBhcyBwcmVmaXhlcyBhcmUgbm90Cj4gbGVnYWwgYW55d2hlcmUgaW4gWUFORy4gQnV0IHll cywgaWYgdGhleSB3ZXJlIGxlZ2FsLCBJIHdvdWxkIGV4cGVjdAo+IHRoYXQgdGhleSBhcmUgbGVn YWwgZXZlcnl3aGVyZSwgaW5jbHVkaW5nIHRoZSBtb2R1bGUgdGhhdCBkZWZpbmVzIHRoZQo+IG5h bWVzcGFjZS4gOy0pCgpQeXRob24gaGFzIGEgc2ltaWxhciBtZWNoYW5pc20gZm9yIHJlZmVyaW5n IHRvIGZvcmVpZ24gc3ltYm9scyBidXQgeW91CmNhbm5vdCBwcmVwZW5kIHRoZSBwYXRoIG9mIHRo ZSBjdXJyZW50IG1vZHVsZSB0byBsb2NhbCBpZGVudGlmaWVycyAtIGFuZApubyBvbmUgaGFzIHBy b2JhYmx5IGV2ZXIgY29uc2lkZXJlZCBpdCBhcyBzb21ldGhpbmcgdXNlZnVsLgoKTW9yZW92ZXIs IHdpdGhvdXQgbWVudGlvbmluZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgdGhlIGxvY2FsIHBy ZWZpeCwKdGhlIHByZWZpeCBzdGF0ZW1lbnQgZGlyZWN0bHkgdW5kZXIgbW9kdWxlIGNhbiBiZSBt YWRlIG9wdGlvbmFsLApiZWNvbWluZyBlZmZlY3RpdmVseSBqdXN0IGEgcGFydCBvZiBtb2R1bGUg bWV0YWRhdGEuCgpMYWRhCgo+IAo+IC9qcwo+IAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQK UEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Jun 5 04:50: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 9ACB93A6C8E; Thu, 5 Jun 2008 04:50: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 1EA3B3A6CB7 for ; Thu, 5 Jun 2008 04:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 Qw4SCCh2A6vA for ; Thu, 5 Jun 2008 04:50:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D789B3A6C8E for ; Thu, 5 Jun 2008 04:50:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8842AC0071; Thu, 5 Jun 2008 13:50:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rtc06DpTQ08l; Thu, 5 Jun 2008 13:50:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21DB3C006D; Thu, 5 Jun 2008 13:50:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 152AE5AF72B; Thu, 5 Jun 2008 13:50:16 +0200 (CEST) Date: Thu, 5 Jun 2008 13:50:16 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080605115016.GA23351@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1212571461.6193.18.camel@missotis> <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@elstar.local> <1212658269.6075.133.camel@missotis> <20080605093354.GA23139@elstar.local> <1212659338.6075.146.camel@missotis> <20080605095421.GB23139@elstar.local> <1212664496.6075.166.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1212664496.6075.166.camel@missotis> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: NETMOD Working Group Subject: Re: [netmod] use of prefix with local names 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, Jun 05, 2008 at 01:14:56PM +0200, Ladislav Lhotka wrote: > Moreover, without mentioning the possibility of using the local prefix, > the prefix statement directly under module can be made optional, > becoming effectively just a part of module metadata. Lets just agree to disagree on the first issue. On the second topic, the design team felt that it is useful to document a "common" prefix to be used by others when important a module. In other words, the prefix statement exists for a very different reason. /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 Jun 5 04: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 D80C53A6A16; Thu, 5 Jun 2008 04:50: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 03FF93A6CC6 for ; Thu, 5 Jun 2008 04:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmbQhLXBZ9eS for ; Thu, 5 Jun 2008 04:50:36 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 3D77B3A6A16 for ; Thu, 5 Jun 2008 04:50:36 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id A80BD1B80C8; Thu, 5 Jun 2008 13:50:41 +0200 (CEST) Date: Thu, 05 Jun 2008 13:50:42 +0200 (CEST) Message-Id: <20080605.135042.105718023.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080605082238.GA22938@elstar.local> References: <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@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] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > My point is that it is unambiguous what foo:bar means in the module > with prefix foo Or rather, we should make sure it is unambiguous. The current text does not spell this out explicitly, but says: When a YANG implementation resolves a reference to an unprefixed ^^^^^^^^^^ type or grouping, it searches up the levels of hierarchy in the schema tree, starting at the current level, for the definition of the type or grouping. I agree with Juergen that it should be possible to use the local prefix. Compare with XML: Both in YANG and XML you can choose to always use the local prefix, or always use no prefix for local/default, or a combination. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 5 06:53: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 94CBB28C21F; Thu, 5 Jun 2008 06:53: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 7B70B28C213 for ; Thu, 5 Jun 2008 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4WkJfpBA43P for ; Thu, 5 Jun 2008 06:53:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 964E028C21F for ; Thu, 5 Jun 2008 06:53:51 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 59C65D800D0; Thu, 5 Jun 2008 15:53:57 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080605.135042.105718023.mbj@tail-f.com> References: <20080605074827.GE22539@elstar.local> <1212653454.6075.67.camel@missotis> <20080605082238.GA22938@elstar.local> <20080605.135042.105718023.mbj@tail-f.com> Organization: CESNET Date: Thu, 05 Jun 2008 15:53:57 +0200 Message-Id: <1212674038.6075.239.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: netmod@ietf.org Subject: Re: [netmod] use of prefix with local names X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMDUuIDA2LiAyMDA4IHYgMTM6NTAgKzAyMDA6 Cj4gCj4gICA8Zm9vIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20iCj4gICAgICAgIGV4OnhtbG5z PSJodHRwOi8vZXhhbXBsZS5jb20iPgo+ICAgICA8YmFyLz4KPiAgICAgPGV4OmJhci8+Cj4gICA8 L2Zvbz4KPiAKQnV0IGhlcmUgdGhlIG1hcHBpbmdzIHByZWZpeC0+VVJJIGFyZSBleHBsaWNpdGx5 IGRlY2xhcmVkLCBhbmQgZXhhY3RseQp0aGUgc2FtZSBtZWNoYW5pc20gaXMgdXNlZCBmb3Igb3Ro ZXIgbmFtZXNwYWNlcy4gSW4gWUFORywgaXQgd291bGQKY29ycmVzcG9uZCB0byB0aGUgZm9sbG93 aW5nOgoKbW9kdWxlIG15bW9kdWxlIHsKICAuLi4KICBwcmVmaXggZm9vOwogIGltcG9ydCBteW1v ZHVsZSB7IHByZWZpeCBiYXI7IH0KICAuLi4KfQoKSGVyZSwgdGhlICp0b3AtbGV2ZWwqIHN5bWJv bHMgb2YgbXltb2R1bGUgc2hvdWxkIGluZGVlZCBiZSBhdmFpbGFibGUgYXMKYmFyOnN5bWJvbC4K CkFzIEp1ZXJnZW4gcG9pbnRlZCBvdXQsIHRoZSAicHJlZml4IGZvbyIgc3RhdGVtZW50IHNlcnZl cyBhIGRpZmZlcmVudApwdXJwb3NlLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVU ClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jun 5 11:07: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 EE3B728C0E5; Thu, 5 Jun 2008 11:07: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 498883A6CD4 for ; Thu, 5 Jun 2008 11:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 oWvgoHeMsxb4 for ; Thu, 5 Jun 2008 11:07:44 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id D19BE3A6861 for ; Thu, 5 Jun 2008 11:07:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=akCe6eWP9VDKqKYmMEFtrs8y70NwqscM/F9II0eDye8X44xPqL36T+aFxvX2UzIL; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.84.214] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K4JsJ-0005AQ-4N for netmod@ietf.org; Thu, 05 Jun 2008 14:07:47 -0400 Message-ID: <002c01c8c737$24a23cc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <1212652104.6075.53.camel@missotis> Date: Thu, 5 Jun 2008 11:08:22 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b38e768e4e63a6b16b572e2de4c76fd013350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.214 Subject: Re: [netmod] keeping track of proposed changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Ladislav Lhotka" > To: "NETMOD Working Group" > Sent: Thursday, June 05, 2008 12:48 AM > Subject: [netmod] keeping track of proposed changes ... > my question may follow from the fact that I have little experience with > IETF working group workflows, but anyway: quite a few proposals for > changes in YANG etc. have been raised and discussed in the mailing list > but I am not sure - does anyone keep track of them and how will they be > resolved? Perhaps we should enter them into a request tracker? ... There appears to already be an issue tracker for netmod - see http://www3.tools.ietf.org/wg/netmod/trac/report/1 Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 6 07:05: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 AE3AF3A6AFC; Fri, 6 Jun 2008 07:05: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 1E0CE3A6D2F for ; Fri, 6 Jun 2008 07:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 nc3wO1hKQK3X for ; Fri, 6 Jun 2008 07:05:20 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 3263C28C1E4 for ; Fri, 6 Jun 2008 07:05:17 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id ae0G1Z00R0cZkys5100A00; Fri, 06 Jun 2008 14:05:25 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id ae5K1Z00F4HwxpC3W00000; Fri, 06 Jun 2008 14:05:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=y5_oIsQvr_EA:10 a=AvmIKPG6opsA:10 a=48vgC7mUAAAA:8 a=ipqJhtc8XeVgn_K2KHsA:9 a=i0j6bLsvG5NywcCiSIYA:7 a=JEe3e-Biho2m8lfypmTaf4ZyNPIA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'NETMOD Working Group'" References: <1212652104.6075.53.camel@missotis> <002c01c8c737$24a23cc0$6801a8c0@oemcomputer> Date: Fri, 6 Jun 2008 10:05:16 -0400 Message-ID: <033f01c8c7de$599a2300$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002c01c8c737$24a23cc0$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjHNx1ft2tVKJweRPi5PmjDOMLYvwAnGqtw Subject: Re: [netmod] keeping track of proposed changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, There is an issues tracker available for netmod. See http://www3.tools.ietf.org/wg/netmod/trac/report/1 I have not decided how it should be used, and have not discussed this with DavidP yet. Generally, it is the editor of a document that keeps track of requested and proposed changes to the document, preferably with an change log and an open issues list as appendices in the document. Editors generally are empowered to determine consensus regarding proposed changes to their document. The chairs have the responsibility to ensure that editors are being fair and open, and when we submit documents to the AD/IESG, we sometimes need to be able to point to the discussions and where consensus was reached, to "prove" we had a fair and open process, and to deal with potential appeals. An issues tracker is also useful for "closing" discussions that could go on endlessly. So the issue tracker would also be useful for the chairs to be able to document consensus, focus conversations, and declare a topic closed. I created a ticket for one thread to experiment with the tracker. We can do this for subsequent threads if desired. I started this issue before we had an controversy, simply documenting "this was discussed here", and the chairs can go into the thread-tracker and document where consensus was reached in a thread. I am not sure this is a good approach however, because the issues are not necessarily clearly defined when a thread starts, and a thread might bloom into mulitple issues, and never reach any consensus. If we try to track too much, we may create information overload. For previous WGs I co-chaired, I tried using the issue stracker for all the requested changes, including aggregations of editorial corrections. I found this to be a problem. There is significant overhead in tracking every change and having to maintain a database of the requests. We already have a formal venue for requestng changes - the mailing list. To track an issue that is raised on the list in the tracker means copying the request from email into the tracker, and copying "significant" subsequent discussion of the issue into the tracler as well. Then there are two parallel discussions that become hard to keep in sync without a lot of work. So, I think the issue tracker should be used for "issues", not all proposed changes. The way I would like to track proposed changes is to have the editors keep their own proposed change logs, which may include many small editorial changes. This allows the editors to organize their work in a manner thay find comfortable. I keep mine in folders for each document, and flag the ones I have yet to address in the document, and clear the flag after I make the chnage. This is easy for me as an editor. The documents should have a change log summarizing the changes that have been made. We should track issues where documenting consensus is important. The editors can determine fairly easily which proposed changes require them to think about "what is the consensus on this?" and those that do not. As issues arise that require the editor to judge consensus, the editor should have them documented in the issues tracker. If issues arise where the editor is not sure he understands the edits, he can have that documented in the tracker. If an issue is not yet resolved when a new draft is published, the "open issues" should be mentioned in an appendix. The chairs (and possibly editors) can also document significant threads to discuss technical alternatives and choose a resolution. The chairs will watch for these, but WG members can also request that an issue be documented. The chairs can decide something does not deserve a ticket. The editors should be prepared to create and post a list of open and resolved issues when requested by the chairs, and should be prepared to discuss the current status of issues when we have an IETF session. The issues tracker certainly should be helpful to the editors for this purpose. Does this sound reasonable? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Thursday, June 05, 2008 2:08 PM > To: NETMOD Working Group > Subject: Re: [netmod] keeping track of proposed changes > > Hi - > > > From: "Ladislav Lhotka" > > To: "NETMOD Working Group" > > Sent: Thursday, June 05, 2008 12:48 AM > > Subject: [netmod] keeping track of proposed changes > ... > > my question may follow from the fact that I have little > experience with > > IETF working group workflows, but anyway: quite a few proposals for > > changes in YANG etc. have been raised and discussed in the > mailing list > > but I am not sure - does anyone keep track of them and how > will they be > > resolved? Perhaps we should enter them into a request tracker? > ... > > There appears to already be an issue tracker for netmod - > see http://www3.tools.ietf.org/wg/netmod/trac/report/1 > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 10 05:26: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 71D293A67DF; Tue, 10 Jun 2008 05:26: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 93A4F3A6832 for ; Tue, 10 Jun 2008 05:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=0.188, 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 JpLOcDvLOh1S for ; Tue, 10 Jun 2008 05:26:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E61123A67DF for ; Tue, 10 Jun 2008 05:26:02 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 2421ED800C5; Tue, 10 Jun 2008 14:26:24 +0200 (CEST) From: Ladislav Lhotka To: David Harrington In-Reply-To: <033f01c8c7de$599a2300$0600a8c0@china.huawei.com> References: <1212652104.6075.53.camel@missotis> <002c01c8c737$24a23cc0$6801a8c0@oemcomputer> <033f01c8c7de$599a2300$0600a8c0@china.huawei.com> Organization: CESNET Date: Tue, 10 Jun 2008 14:26:24 +0200 Message-Id: <1213100784.6867.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 'NETMOD Working Group' Subject: Re: [netmod] keeping track of proposed changes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGkgRGF2ZSwKCmFub3RoZXIgYmVuZWZpdCBvZiBhbiBpc3N1ZSB0cmFja2VyIGlzIHRoYXQgZXZl cnlvbmUgd2hvIHdhbnRzIHRvIHN0YXJ0CmEgdGhyZWFkIGNhbiBicm93c2UgdGhlIHByZXZpb3Vz IHRpY2tldHMgdG8gc2VlIHdoZXRoZXIgdGhlIHNhbWUgb3IKcmVsYXRlZCBpc3N1ZSBoYXMgYWxy ZWFkeSBiZWVuIGFkZHJlc3NlZC4KCkluIGFueSBjYXNlLCBJIHN1Z2dlc3QgdG8gdXNlIHRoZSB0 cmFja2VyIGFsc28gZm9yIGlzc3VlcyB0aGF0IGFyZQpjb25zaWRlcmVkIGJ1Z3MgLSBhbHRob3Vn aCB0aGUgbm90aW9uIG9mIGEgYnVnIGlzIHN1YmplY3RpdmUsIHRvby4gQnV0CmF0IGxlYXN0IG1p c3Rha2VzIGFuZCBvbW1pc2lvbnMgc3BvdHRlZCBpbiB0aGUgZHJhZnRzIHNob3VsZCBnbyB0aGVy ZS4KCldpdGggcmVzcGVjdCB0byB0aGUgcHJvYmxlbSBvZiB1c2luZyBhIHRyYWNrZXIgdmVyc3Vz IG1haWxpbmcgbGlzdCwKSSBhc2tlZCBteSBjb2xsZWFndWVzIGZyb20gdGhlIENTSVJUIHRlYW0g d2hvIGhhdmUgdG8gZGVhbCB3aXRoIHRoZSBzYW1lCnByb2JsZW0gYWJvdXQgdGhlaXIgc29sdXRp b24gLSB0aGV5IGhhdmUgYW4gaXNzdWUgdHJhY2tlciBpbnRlZ3JhdGVkCndpdGggYSBtYWlsaW5n IGxpc3Qgc28gdGhhdCBldmVyeSBpbmNvbWluZyBlbWFpbCBpcyBhdXRvbWF0aWNhbGx5CmVudGVy ZWQgaW50byB0aGUgdHJhY2tlci4KCj5Gcm9tIHlvdXIgcHJldmlvdXMgdGVzdCB0aWNrZXQgSSB1 bmRlcnN0YW5kIHRoYXQgdGhlIHRyYWNrZXIgc2VuZHMgYW4KZW1haWwgdG8gdGhlIGxpc3Qgd2hl biBhIG5ldyB0aWNrZXQgaXMgY3JlYXRlZC4gSSBhbSBub3QgYWJsZSB0byBmaW5kIGluCnRoIGV0 cmFja2VyIHRob3VnaCB3aGV0aGVyIGl0IGlzIHBvc3NpYmxlIHRvIHJlZ2lzdGVyIGZvciBvYnRh aW5pbmcKbm90aWZpY2F0aW9ucyB3cnQgYSBjb25jcmV0ZSBpc3N1ZS4gVGhlc2UgdHdvIHRoaW5n cyBzaG91bGQgYmUgZW5vdWdoCmZvciB0aGUgZm9sa3MgaW50ZXJlc3RlZCBpbiBhIGdpdmVuIHRp Y2tldCB0byBnZXQgaW5mb3JtZWQgYW5kIGludm9sdmVkLgoKTGFkYQoKRGF2aWQgSGFycmluZ3Rv biBww63FoWUgdiBQw6EgMDYuIDA2LiAyMDA4IHYgMTA6MDUgLTA0MDA6Cj4gSGksCj4gCj4gVGhl cmUgaXMgYW4gaXNzdWVzIHRyYWNrZXIgYXZhaWxhYmxlIGZvciBuZXRtb2QuCj4gU2VlIGh0dHA6 Ly93d3czLnRvb2xzLmlldGYub3JnL3dnL25ldG1vZC90cmFjL3JlcG9ydC8xCj4gCj4gSSBoYXZl IG5vdCBkZWNpZGVkIGhvdyBpdCBzaG91bGQgYmUgdXNlZCwgYW5kIGhhdmUgbm90IGRpc2N1c3Nl ZCB0aGlzCj4gd2l0aCBEYXZpZFAgeWV0Lgo+IAo+IEdlbmVyYWxseSwgaXQgaXMgdGhlIGVkaXRv ciBvZiBhIGRvY3VtZW50IHRoYXQga2VlcHMgdHJhY2sgb2YKPiByZXF1ZXN0ZWQgYW5kIHByb3Bv c2VkIGNoYW5nZXMgdG8gdGhlIGRvY3VtZW50LCBwcmVmZXJhYmx5IHdpdGggYW4KPiBjaGFuZ2Ug bG9nIGFuZCBhbiBvcGVuIGlzc3VlcyBsaXN0IGFzIGFwcGVuZGljZXMgaW4gdGhlIGRvY3VtZW50 Lgo+IEVkaXRvcnMgZ2VuZXJhbGx5IGFyZSBlbXBvd2VyZWQgdG8gZGV0ZXJtaW5lIGNvbnNlbnN1 cyByZWdhcmRpbmcKPiBwcm9wb3NlZCBjaGFuZ2VzIHRvIHRoZWlyIGRvY3VtZW50LiBUaGUgY2hh aXJzIGhhdmUgdGhlIHJlc3BvbnNpYmlsaXR5Cj4gdG8gZW5zdXJlIHRoYXQgZWRpdG9ycyBhcmUg YmVpbmcgZmFpciBhbmQgb3BlbiwgYW5kIHdoZW4gd2Ugc3VibWl0Cj4gZG9jdW1lbnRzIHRvIHRo ZSBBRC9JRVNHLCB3ZSBzb21ldGltZXMgbmVlZCB0byBiZSBhYmxlIHRvIHBvaW50IHRvIHRoZQo+ IGRpc2N1c3Npb25zIGFuZCB3aGVyZSBjb25zZW5zdXMgd2FzIHJlYWNoZWQsIHRvICJwcm92ZSIg d2UgaGFkIGEgZmFpcgo+IGFuZCBvcGVuIHByb2Nlc3MsIGFuZCB0byBkZWFsIHdpdGggcG90ZW50 aWFsIGFwcGVhbHMuIEFuIGlzc3Vlcwo+IHRyYWNrZXIgaXMgYWxzbyB1c2VmdWwgZm9yICJjbG9z aW5nIiBkaXNjdXNzaW9ucyB0aGF0IGNvdWxkIGdvIG9uCj4gZW5kbGVzc2x5Lgo+IAo+IFNvIHRo ZSBpc3N1ZSB0cmFja2VyIHdvdWxkIGFsc28gYmUgdXNlZnVsIGZvciB0aGUgY2hhaXJzIHRvIGJl IGFibGUgdG8KPiBkb2N1bWVudCBjb25zZW5zdXMsIGZvY3VzIGNvbnZlcnNhdGlvbnMsIGFuZCBk ZWNsYXJlIGEgdG9waWMgY2xvc2VkLgo+IAo+IEkgY3JlYXRlZCBhIHRpY2tldCBmb3Igb25lIHRo cmVhZCB0byBleHBlcmltZW50IHdpdGggdGhlIHRyYWNrZXIuIFdlCj4gY2FuIGRvIHRoaXMgZm9y IHN1YnNlcXVlbnQgdGhyZWFkcyBpZiBkZXNpcmVkLiBJIHN0YXJ0ZWQgdGhpcyBpc3N1ZQo+IGJl Zm9yZSB3ZSBoYWQgYW4gY29udHJvdmVyc3ksIHNpbXBseSBkb2N1bWVudGluZyAidGhpcyB3YXMg ZGlzY3Vzc2VkCj4gaGVyZSIsIGFuZCB0aGUgY2hhaXJzIGNhbiBnbyBpbnRvIHRoZSB0aHJlYWQt dHJhY2tlciBhbmQgZG9jdW1lbnQKPiB3aGVyZSBjb25zZW5zdXMgd2FzIHJlYWNoZWQgaW4gYSB0 aHJlYWQuIEkgYW0gbm90IHN1cmUgdGhpcyBpcyBhIGdvb2QKPiBhcHByb2FjaCBob3dldmVyLCBi ZWNhdXNlIHRoZSBpc3N1ZXMgYXJlIG5vdCBuZWNlc3NhcmlseSBjbGVhcmx5Cj4gZGVmaW5lZCB3 aGVuIGEgdGhyZWFkIHN0YXJ0cywgYW5kIGEgdGhyZWFkIG1pZ2h0IGJsb29tIGludG8gbXVsaXRw bGUKPiBpc3N1ZXMsIGFuZCBuZXZlciByZWFjaCBhbnkgY29uc2Vuc3VzLiBJZiB3ZSB0cnkgdG8g dHJhY2sgdG9vIG11Y2gsIHdlCj4gbWF5IGNyZWF0ZSBpbmZvcm1hdGlvbiBvdmVybG9hZC4gCj4g Cj4gRm9yIHByZXZpb3VzIFdHcyBJIGNvLWNoYWlyZWQsIEkgdHJpZWQgdXNpbmcgdGhlIGlzc3Vl IHN0cmFja2VyIGZvcgo+IGFsbCB0aGUgcmVxdWVzdGVkIGNoYW5nZXMsIGluY2x1ZGluZyBhZ2dy ZWdhdGlvbnMgb2YgZWRpdG9yaWFsCj4gY29ycmVjdGlvbnMuIEkgZm91bmQgdGhpcyB0byBiZSBh IHByb2JsZW0uIFRoZXJlIGlzIHNpZ25pZmljYW50Cj4gb3ZlcmhlYWQgaW4gdHJhY2tpbmcgZXZl cnkgY2hhbmdlIGFuZCBoYXZpbmcgdG8gbWFpbnRhaW4gYSBkYXRhYmFzZSBvZgo+IHRoZSByZXF1 ZXN0cy4gV2UgYWxyZWFkeSBoYXZlIGEgZm9ybWFsIHZlbnVlIGZvciByZXF1ZXN0bmcgY2hhbmdl cyAtCj4gdGhlIG1haWxpbmcgbGlzdC4gVG8gdHJhY2sgYW4gaXNzdWUgdGhhdCBpcyByYWlzZWQg b24gdGhlIGxpc3QgaW4gdGhlCj4gdHJhY2tlciBtZWFucyBjb3B5aW5nIHRoZSByZXF1ZXN0IGZy b20gZW1haWwgaW50byB0aGUgdHJhY2tlciwgYW5kCj4gY29weWluZyAic2lnbmlmaWNhbnQiIHN1 YnNlcXVlbnQgZGlzY3Vzc2lvbiBvZiB0aGUgaXNzdWUgaW50byB0aGUKPiB0cmFjbGVyIGFzIHdl bGwuIFRoZW4gdGhlcmUgYXJlIHR3byBwYXJhbGxlbCBkaXNjdXNzaW9ucyB0aGF0IGJlY29tZQo+ IGhhcmQgdG8ga2VlcCBpbiBzeW5jIHdpdGhvdXQgYSBsb3Qgb2Ygd29yay4gU28sIEkgdGhpbmsg dGhlIGlzc3VlCj4gdHJhY2tlciBzaG91bGQgYmUgdXNlZCBmb3IgImlzc3VlcyIsIG5vdCBhbGwg cHJvcG9zZWQgY2hhbmdlcy4KPiAKPiBUaGUgd2F5IEkgd291bGQgbGlrZSB0byB0cmFjayBwcm9w b3NlZCBjaGFuZ2VzIGlzIHRvIGhhdmUgdGhlIGVkaXRvcnMKPiBrZWVwIHRoZWlyIG93biBwcm9w b3NlZCBjaGFuZ2UgbG9ncywgd2hpY2ggbWF5IGluY2x1ZGUgbWFueSBzbWFsbAo+IGVkaXRvcmlh bCBjaGFuZ2VzLiBUaGlzIGFsbG93cyB0aGUgZWRpdG9ycyB0byBvcmdhbml6ZSB0aGVpciB3b3Jr IGluIGEKPiBtYW5uZXIgdGhheSBmaW5kIGNvbWZvcnRhYmxlLiBJIGtlZXAgbWluZSBpbiBmb2xk ZXJzIGZvciBlYWNoCj4gZG9jdW1lbnQsIGFuZCBmbGFnIHRoZSBvbmVzIEkgaGF2ZSB5ZXQgdG8g YWRkcmVzcyBpbiB0aGUgZG9jdW1lbnQsIGFuZAo+IGNsZWFyIHRoZSBmbGFnIGFmdGVyIEkgbWFr ZSB0aGUgY2huYWdlLiBUaGlzIGlzIGVhc3kgZm9yIG1lIGFzIGFuCj4gZWRpdG9yLiBUaGUgZG9j dW1lbnRzIHNob3VsZCBoYXZlIGEgY2hhbmdlIGxvZyBzdW1tYXJpemluZyB0aGUgY2hhbmdlcwo+ IHRoYXQgaGF2ZSBiZWVuIG1hZGUuIAo+IAo+IFdlIHNob3VsZCB0cmFjayBpc3N1ZXMgd2hlcmUg ZG9jdW1lbnRpbmcgY29uc2Vuc3VzIGlzIGltcG9ydGFudC4gVGhlCj4gZWRpdG9ycyBjYW4gZGV0 ZXJtaW5lIGZhaXJseSBlYXNpbHkgd2hpY2ggcHJvcG9zZWQgY2hhbmdlcyByZXF1aXJlCj4gdGhl bSB0byB0aGluayBhYm91dCAid2hhdCBpcyB0aGUgY29uc2Vuc3VzIG9uIHRoaXM/IiBhbmQgdGhv c2UgdGhhdCBkbwo+IG5vdC4gQXMgaXNzdWVzIGFyaXNlIHRoYXQgcmVxdWlyZSB0aGUgZWRpdG9y IHRvIGp1ZGdlIGNvbnNlbnN1cywgdGhlCj4gZWRpdG9yIHNob3VsZCBoYXZlIHRoZW0gZG9jdW1l bnRlZCBpbiB0aGUgaXNzdWVzIHRyYWNrZXIuIElmIGlzc3Vlcwo+IGFyaXNlIHdoZXJlIHRoZSBl ZGl0b3IgaXMgbm90IHN1cmUgaGUgdW5kZXJzdGFuZHMgdGhlIGVkaXRzLCBoZSBjYW4KPiBoYXZl IHRoYXQgZG9jdW1lbnRlZCBpbiB0aGUgdHJhY2tlci4gIElmIGFuIGlzc3VlIGlzIG5vdCB5ZXQg cmVzb2x2ZWQKPiB3aGVuIGEgbmV3IGRyYWZ0IGlzIHB1Ymxpc2hlZCwgdGhlICJvcGVuIGlzc3Vl cyIgc2hvdWxkIGJlIG1lbnRpb25lZAo+IGluIGFuIGFwcGVuZGl4Lgo+IAo+IFRoZSBjaGFpcnMg KGFuZCBwb3NzaWJseSBlZGl0b3JzKSBjYW4gYWxzbyBkb2N1bWVudCBzaWduaWZpY2FudAo+IHRo cmVhZHMgdG8gZGlzY3VzcyB0ZWNobmljYWwgYWx0ZXJuYXRpdmVzIGFuZCBjaG9vc2UgYSByZXNv bHV0aW9uLiBUaGUKPiBjaGFpcnMgd2lsbCB3YXRjaCBmb3IgdGhlc2UsIGJ1dCBXRyBtZW1iZXJz IGNhbiBhbHNvIHJlcXVlc3QgdGhhdCBhbgo+IGlzc3VlIGJlIGRvY3VtZW50ZWQuIFRoZSBjaGFp cnMgY2FuIGRlY2lkZSBzb21ldGhpbmcgZG9lcyBub3QgZGVzZXJ2ZQo+IGEgdGlja2V0LiAKPiAK PiBUaGUgZWRpdG9ycyBzaG91bGQgYmUgcHJlcGFyZWQgdG8gY3JlYXRlIGFuZCBwb3N0IGEgbGlz dCBvZiBvcGVuIGFuZAo+IHJlc29sdmVkIGlzc3VlcyB3aGVuIHJlcXVlc3RlZCBieSB0aGUgY2hh aXJzLCBhbmQgc2hvdWxkIGJlIHByZXBhcmVkCj4gdG8gZGlzY3VzcyB0aGUgY3VycmVudCBzdGF0 dXMgb2YgaXNzdWVzIHdoZW4gd2UgaGF2ZSBhbiBJRVRGIHNlc3Npb24uCj4gVGhlIGlzc3VlcyB0 cmFja2VyIGNlcnRhaW5seSBzaG91bGQgYmUgaGVscGZ1bCB0byB0aGUgZWRpdG9ycyBmb3IgdGhp cwo+IHB1cnBvc2UuCj4gCj4gRG9lcyB0aGlzIHNvdW5kIHJlYXNvbmFibGU/Cj4gCj4gRGF2aWQg SGFycmluZ3Rvbgo+IGRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldAo+IGlldGZkYmhAY29tY2FzdC5u ZXQKPiBkaGFycmluZ3RvbkBodWF3ZWkuY29tCj4gCj4gCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQo+ID4gRnJvbTogbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgCj4gPiBbbWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFuZHkgUHJlc3Vobgo+ID4gU2Vu dDogVGh1cnNkYXksIEp1bmUgMDUsIDIwMDggMjowOCBQTQo+ID4gVG86IE5FVE1PRCBXb3JraW5n IEdyb3VwCj4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0ga2VlcGluZyB0cmFjayBvZiBwcm9wb3Nl ZCBjaGFuZ2VzCj4gPiAKPiA+IEhpIC0KPiA+IAo+ID4gPiBGcm9tOiAiTGFkaXNsYXYgTGhvdGth IiA8bGhvdGthQGNlc25ldC5jej4KPiA+ID4gVG86ICJORVRNT0QgV29ya2luZyBHcm91cCIgPG5l dG1vZEBpZXRmLm9yZz4KPiA+ID4gU2VudDogVGh1cnNkYXksIEp1bmUgMDUsIDIwMDggMTI6NDgg QU0KPiA+ID4gU3ViamVjdDogW25ldG1vZF0ga2VlcGluZyB0cmFjayBvZiBwcm9wb3NlZCBjaGFu Z2VzCj4gPiAuLi4KPiA+ID4gbXkgcXVlc3Rpb24gbWF5IGZvbGxvdyBmcm9tIHRoZSBmYWN0IHRo YXQgSSBoYXZlIGxpdHRsZSAKPiA+IGV4cGVyaWVuY2Ugd2l0aAo+ID4gPiBJRVRGIHdvcmtpbmcg Z3JvdXAgd29ya2Zsb3dzLCBidXQgYW55d2F5OiBxdWl0ZSBhIGZldyBwcm9wb3NhbHMKPiBmb3IK PiA+ID4gY2hhbmdlcyBpbiBZQU5HIGV0Yy4gaGF2ZSBiZWVuIHJhaXNlZCBhbmQgZGlzY3Vzc2Vk IGluIHRoZSAKPiA+IG1haWxpbmcgbGlzdAo+ID4gPiBidXQgSSBhbSBub3Qgc3VyZSAtIGRvZXMg YW55b25lIGtlZXAgdHJhY2sgb2YgdGhlbSBhbmQgaG93IAo+ID4gd2lsbCB0aGV5IGJlCj4gPiA+ IHJlc29sdmVkPyBQZXJoYXBzIHdlIHNob3VsZCBlbnRlciB0aGVtIGludG8gYSByZXF1ZXN0IHRy YWNrZXI/Cj4gPiAuLi4KPiA+IAo+ID4gVGhlcmUgYXBwZWFycyB0byBhbHJlYWR5IGJlIGFuIGlz c3VlIHRyYWNrZXIgZm9yIG5ldG1vZCAtCj4gPiBzZWUgaHR0cDovL3d3dzMudG9vbHMuaWV0Zi5v cmcvd2cvbmV0bW9kL3RyYWMvcmVwb3J0LzEKPiA+IAo+ID4gUmFuZHkKPiA+IAo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IG5ldG1vZCBtYWls aW5nIGxpc3QKPiA+IG5ldG1vZEBpZXRmLm9yZwo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QKPiA+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRm Lm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCi0tIApM YWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApu ZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QK From netmod-bounces@ietf.org Wed Jun 11 02:21:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B12E3A6886; Wed, 11 Jun 2008 02:21:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619533A6886 for ; Wed, 11 Jun 2008 02:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=0.167, 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 5F0d9y3WyHAQ for ; Wed, 11 Jun 2008 02:21:51 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 836EA3A68EE for ; Wed, 11 Jun 2008 02:21:48 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 41E68D800C1 for ; Wed, 11 Jun 2008 11:22:12 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 11 Jun 2008 11:22:11 +0200 Message-Id: <1213176131.7113.17.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [netmod] anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, if I use "anyxml data;", can the XML chunk inside ... contain any elements or attributes with the namespace of the module, i.e., the same namespace as the element? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 11 05:16:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8461B3A67ED; Wed, 11 Jun 2008 05:16: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 9AA823A67ED for ; Wed, 11 Jun 2008 05:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj5A2SZgQizR for ; Wed, 11 Jun 2008 05:16:48 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id CF0953A6838 for ; Wed, 11 Jun 2008 05:16:47 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 487071B80C5; Wed, 11 Jun 2008 14:17:11 +0200 (CEST) Date: Wed, 11 Jun 2008 14:17:10 +0200 (CEST) Message-Id: <20080611.141710.47458090.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1213176131.7113.17.camel@missotis> References: <1213176131.7113.17.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] anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > > if I use "anyxml data;", can the XML chunk inside ... > contain any elements or attributes with the namespace of the module, > i.e., the same namespace as the element? Sure. There are no restrictions on the XML inside an 'anyxml' node. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 11 07:50:33 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131163A68D2; Wed, 11 Jun 2008 07:50:33 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2513A68D2 for ; Wed, 11 Jun 2008 07:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 YvsVKm15ZsEr for ; Wed, 11 Jun 2008 07:50:30 -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 836823A69E0 for ; Wed, 11 Jun 2008 07:50:30 -0700 (PDT) Received: (qmail 7394 invoked from network); 11 Jun 2008 14:50:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 11 Jun 2008 14:50:53 -0000 X-YMail-OSG: pWjfqhIVM1n04Y3QY_cspggtnrauWbTEDJ8VS38sRqoh5XDgmvBdTFeVoaTbKEOEjedJjzL_3Q5v59jFFfqcOlzHqfVDMg9W74ni9HLFPBjOodsl53zhrXztFWHR X-Yahoo-Newman-Property: ymail-3 Message-ID: <484FE64B.5070609@netconfcentral.com> Date: Wed, 11 Jun 2008 07:50:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <1213176131.7113.17.camel@missotis> <20080611.141710.47458090.mbj@tail-f.com> In-Reply-To: <20080611.141710.47458090.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > Ladislav Lhotka wrote: >> Hi, >> >> if I use "anyxml data;", can the XML chunk inside ... >> contain any elements or attributes with the namespace of the module, >> i.e., the same namespace as the element? > > Sure. There are no restrictions on the XML inside an 'anyxml' node. > This particular feature is available throughout the YANG constructs. Even though 'anyxml' cannot be augmented, it can contain any namespace. Any other non-leaf node can be augmented from another module (and therefore another XML namespace). YANG has implicit augment-ability. In XSD, the 'substitutionGroup hack' (ala yangdump) is needed to manually identify all the 'augment points' within the subtree. > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 11 16:30: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 C788B3A684E; Wed, 11 Jun 2008 16:30: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 0BE723A69B3 for ; Wed, 11 Jun 2008 16:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 kKHkKN5hmTf3 for ; Wed, 11 Jun 2008 16:30:42 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id A7E7D3A69A2 for ; Wed, 11 Jun 2008 16:30:41 -0700 (PDT) Received: (qmail 64802 invoked from network); 11 Jun 2008 23:31:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 11 Jun 2008 23:31:02 -0000 X-YMail-OSG: sEQ8MjIVM1lDa0cZ0HN919lX8EI4.Rq8vOE.4MWR55HrBGwe0t6.XusoSvn7SIBUuQZdfm6cdVWnZl4yZIzzCAK2lb6djFAf2xET4u2zAQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48506034.4000104@netconfcentral.com> Date: Wed, 11 Jun 2008 16:31:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I would like to resolve the usage of default-stmt and mandatory-stmt, within the YANG language, and the protocol operation behavior. (This debate was never really resolved) I can accept that default and mandatory MUST NOT be used together in any fashion (e.g., derived default from the data type). This means 'mandatory true;' can only be used if: 1) there is no data model defined default value 2) the agent will not supply any value for this leaf (or leaf-list) 3) a or for this data will not contain any instances until one is provided by a manager I think this is the behavior Phil wanted. Mandatory means the manager must set it or it will not exist. The config stays 'invalid' until the node is supplied. No default value will be used by the agent under any condition. I think the controversy is with agent-supplied defaults that are not documented in the data model -- should the agent be required to return a value for of the leaf in this case? (I say yes.) Although data-model dependent, it may be valuable for an operator to know that there is no 'foo' knob present, vs. knowing that the knob is present and the agent supplied its own value, vs. knowing the knob is present and some manager supplied the value. XML attributes (ala operation, key, insert) could be defined to add to replies for this purpose. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 11 23:07: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 0B2A43A6836; Wed, 11 Jun 2008 23:07: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 235963A684F for ; Wed, 11 Jun 2008 23:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbeAwkdGgcvG for ; Wed, 11 Jun 2008 23:07:35 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 0AB8A3A6836 for ; Wed, 11 Jun 2008 23:07:35 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 65C161B80CE; Thu, 12 Jun 2008 08:08:01 +0200 (CEST) Date: Thu, 12 Jun 2008 08:08:08 +0200 (CEST) Message-Id: <20080612.080808.258902106.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48506034.4000104@netconfcentral.com> References: <48506034.4000104@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] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > I would like to resolve the usage of default-stmt and mandatory-stmt, > within the YANG language, and the protocol operation behavior. > (This debate was never really resolved) > > I can accept that default and mandatory MUST NOT be used together > in any fashion (e.g., derived default from the data type). > This means 'mandatory true;' can only be used if: > 1) there is no data model defined default value > 2) the agent will not supply any value for this leaf (or leaf-list) > 3) a or for this data will not contain any instances > until one is provided by a manager > > I think this is the behavior Phil wanted. > Mandatory means the manager must set it or it will not exist. > The config stays 'invalid' until the node is supplied. > No default value will be used by the agent under any condition. > > I think the controversy is with agent-supplied defaults that > are not documented in the data model Right. We have three options here. 1. pretend that agent-supplied defaults don't exist 2. realize that they do exit, but don't have any formal support for specifying them, and thus no formal support for a client to learn them. 3. make it possible for an agent developer to specify them, and thus for a client to learn them and adapt to them. The answer to the rest of your issues will follow from the outcome of this one. > -- should the agent be required > to return a value for of the leaf in this case? (I say yes.) If we choose 2 above, yes; if we choose 3, no (then it would work like data-model specific default, which can be controlled with :with-defaults). > Although data-model dependent, it may be valuable for an operator > to know that there is no 'foo' knob present, vs. knowing that the > knob is present and the agent supplied its own value, vs. knowing > the knob is present and some manager supplied the value. > > XML attributes (ala operation, key, insert) could be defined > to add to replies for this purpose. One use-case to think about. Suppose a manager sends a in order to store a backup. Later he sends this backup back in an . If the get-config reply included defaults w/o any annotations, the edit-config will explicitly set all those defaults, and they are no longer defaults. This is something I think we must avoid. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 01:35: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 218953A68CC; Thu, 12 Jun 2008 01:35: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 A70513A6996 for ; Thu, 12 Jun 2008 01:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Xdo4yjb6T6gF for ; Thu, 12 Jun 2008 01:35:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 610313A68CC for ; Thu, 12 Jun 2008 01:35:03 -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 43A89D800C1 for ; Thu, 12 Jun 2008 10:35:28 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080612.080808.258902106.mbj@tail-f.com> References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> Organization: CESNET Date: Thu, 12 Jun 2008 10:35:28 +0200 Message-Id: <1213259728.6339.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGksCgp0aGVyZSBhcmUgYWN0dWFsbHkgdHdvIGZvcm1zIG9mIGNvbmZpZ3VyYXRpb24gZGF0YSB0 aGF0IFlBTkcgbW9kZWxzCmRpcmVjdGx5IGFkZHJlc3M6CgpBLiBGdWxsIGNvbmZpZ3VyYXRpb24g d2l0aCBhbGwgcGFyYW1ldGVycyB0aGF0IHRoZSBhZ2VudCB1c2VzIGluIGFueQp3YXkuCgpCLiBS ZWR1Y2VkIGNvbmZpZ3VyYXRpb24gd2hlcmUgc29tZSBwYXJhbWV0ZXJzIG1heSBiZSBtaXNzaW5n IGJlY2F1c2UKdGhleSBoYXZlIGRlZmF1bHQgdmFsdWVzIGluIHRoZSBmdWxsIGNvbmZpZ3VyYXRp b24uCgpJbiBBLCAib3B0aW9uYWwiIG1lYW5zIHRoYXQgZWl0aGVyIHRoZSBwYXJhbWV0ZXIgaXMg bm90IGVzc2VudGlhbCAoZS5nLiwKZGVzY3JpcHRpb24pIE9SIHRoYXQgaXQgaXMgaW4gYSBzdWJz eXN0ZW0gdGhhdCBtYXkgbm90IGJlIG9wZXJhdGlvbmFsCih0aGF0IG1lYW5zIGluc2lkZSBhICJw cmVzZW5jZSIgY29udGFpbmVyIHRoYXQgaXMgbWlzc2luZykuCgpJbiBCLCAib3B0aW9uYWwiIG1h eSBtZWFuIHRoZSBzYW1lIHRoaW5ncyBhcyBhYm92ZSwgYnV0IGFsc28gdGhhdCB0aGUKcGFyYW1l dGVyIGluIHF1ZXN0aW9uIGhhcyBhIGRlZmF1bHQgdmFsdWUuCgpJIHRoaW5rIGl0IHdvdWxkIGJl IHVzZWZ1bCB0byBjbGVhcmx5IGRpc3Rpbmd1aXNoIHRoZXNlIHRocmVlIG1lYW5pbmdzCm9mIG1h bmRhdG9yeS9vcHRpb25hbCBpbiBZQU5HLiBUaGUgcmVkdWNlZCBmb3JtIEIgaXMgd2hhdCB0cmFk aXRpb25hbApDTElzIHByZXNlbnQgdG8gdGhlIHVzZXIsIHNvIEkgdW5kZXJzdGFuZCB3aHkgUGhp bCBhc3N1bWVzIGl0IG11c3QgZXhpc3QKaW4gdGhlIGRldmljZSwgYnV0IGluIG91ciBpbXBsZW1l bnRhbnRpb24gaXQgYWN0dWFsbHkgZG9lc24ndCAtIHRoZQpyZWR1Y3Rpb24gaXMgb25seSBwZXJm b3JtZWQgYXQgdGhlIG1hbmFnZXIgc2lkZS4KCkxhZGEKCk1hcnRpbiBCam9ya2x1bmQgcMOtxaFl IHYgxIx0IDEyLiAwNi4gMjAwOCB2IDA4OjA4ICswMjAwOgo+IEhpLAo+IAo+IEFuZHkgQmllcm1h biA8YW5keUBuZXRjb25mY2VudHJhbC5jb20+IHdyb3RlOgo+ID4gSGksCj4gPiAKPiA+IEkgd291 bGQgbGlrZSB0byByZXNvbHZlIHRoZSB1c2FnZSBvZiBkZWZhdWx0LXN0bXQgYW5kIG1hbmRhdG9y eS1zdG10LAo+ID4gd2l0aGluIHRoZSBZQU5HIGxhbmd1YWdlLCBhbmQgdGhlIHByb3RvY29sIG9w ZXJhdGlvbiBiZWhhdmlvci4KPiA+IChUaGlzIGRlYmF0ZSB3YXMgbmV2ZXIgcmVhbGx5IHJlc29s dmVkKQo+ID4gCj4gPiBJIGNhbiBhY2NlcHQgdGhhdCBkZWZhdWx0IGFuZCBtYW5kYXRvcnkgTVVT VCBOT1QgYmUgdXNlZCB0b2dldGhlcgo+ID4gaW4gYW55IGZhc2hpb24gKGUuZy4sIGRlcml2ZWQg ZGVmYXVsdCBmcm9tIHRoZSBkYXRhIHR5cGUpLgo+ID4gVGhpcyBtZWFucyAnbWFuZGF0b3J5IHRy dWU7JyBjYW4gb25seSBiZSB1c2VkIGlmOgo+ID4gICAxKSB0aGVyZSBpcyBubyBkYXRhIG1vZGVs IGRlZmluZWQgZGVmYXVsdCB2YWx1ZQo+ID4gICAyKSB0aGUgYWdlbnQgd2lsbCBub3Qgc3VwcGx5 IGFueSB2YWx1ZSBmb3IgdGhpcyBsZWFmIChvciBsZWFmLWxpc3QpCj4gPiAgIDMpIGEgPGdldD4g b3IgPGdldC1jb25maWc+IGZvciB0aGlzIGRhdGEgd2lsbCBub3QgY29udGFpbiBhbnkgaW5zdGFu Y2VzCj4gPiAgICAgIHVudGlsIG9uZSBpcyBwcm92aWRlZCBieSBhIG1hbmFnZXIKPiA+IAo+ID4g SSB0aGluayB0aGlzIGlzIHRoZSBiZWhhdmlvciBQaGlsIHdhbnRlZC4KPiA+IE1hbmRhdG9yeSBt ZWFucyB0aGUgbWFuYWdlciBtdXN0IHNldCBpdCBvciBpdCB3aWxsIG5vdCBleGlzdC4KPiA+IFRo ZSBjb25maWcgc3RheXMgJ2ludmFsaWQnIHVudGlsIHRoZSBub2RlIGlzIHN1cHBsaWVkLgo+ID4g Tm8gZGVmYXVsdCB2YWx1ZSB3aWxsIGJlIHVzZWQgYnkgdGhlIGFnZW50IHVuZGVyIGFueSBjb25k aXRpb24uCj4gPiAKPiA+IEkgdGhpbmsgdGhlIGNvbnRyb3ZlcnN5IGlzIHdpdGggYWdlbnQtc3Vw cGxpZWQgZGVmYXVsdHMgdGhhdAo+ID4gYXJlIG5vdCBkb2N1bWVudGVkIGluIHRoZSBkYXRhIG1v ZGVsCj4gCj4gUmlnaHQuICBXZSBoYXZlIHRocmVlIG9wdGlvbnMgaGVyZS4gIAo+IAo+ICAgMS4g cHJldGVuZCB0aGF0IGFnZW50LXN1cHBsaWVkIGRlZmF1bHRzIGRvbid0IGV4aXN0Cj4gCj4gICAy LiByZWFsaXplIHRoYXQgdGhleSBkbyBleGl0LCBidXQgZG9uJ3QgaGF2ZSBhbnkgZm9ybWFsIHN1 cHBvcnQgZm9yCj4gICAgICBzcGVjaWZ5aW5nIHRoZW0sIGFuZCB0aHVzIG5vIGZvcm1hbCBzdXBw b3J0IGZvciBhIGNsaWVudCB0bwo+ICAgICAgbGVhcm4gdGhlbS4KPiAKPiAgIDMuIG1ha2UgaXQg cG9zc2libGUgZm9yIGFuIGFnZW50IGRldmVsb3BlciB0byBzcGVjaWZ5IHRoZW0sIGFuZCB0aHVz Cj4gICAgICBmb3IgYSBjbGllbnQgdG8gbGVhcm4gdGhlbSBhbmQgYWRhcHQgdG8gdGhlbS4KPiAK PiAKPiBUaGUgYW5zd2VyIHRvIHRoZSByZXN0IG9mIHlvdXIgaXNzdWVzIHdpbGwgZm9sbG93IGZy b20gdGhlIG91dGNvbWUgb2YKPiB0aGlzIG9uZS4KPiAKPiA+IC0tIHNob3VsZCB0aGUgYWdlbnQg YmUgcmVxdWlyZWQKPiA+IHRvIHJldHVybiBhIHZhbHVlIGZvciA8Z2V0Kj4gb2YgdGhlIGxlYWYg aW4gdGhpcyBjYXNlPyAoSSBzYXkgeWVzLikKPiAKPiBJZiB3ZSBjaG9vc2UgMiBhYm92ZSwgeWVz OyBpZiB3ZSBjaG9vc2UgMywgbm8gKHRoZW4gaXQgd291bGQgd29yayBsaWtlCj4gZGF0YS1tb2Rl bCBzcGVjaWZpYyBkZWZhdWx0LCB3aGljaCBjYW4gYmUgY29udHJvbGxlZCB3aXRoCj4gOndpdGgt ZGVmYXVsdHMpLgo+IAo+ID4gQWx0aG91Z2ggZGF0YS1tb2RlbCBkZXBlbmRlbnQsIGl0IG1heSBi ZSB2YWx1YWJsZSBmb3IgYW4gb3BlcmF0b3IKPiA+IHRvIGtub3cgdGhhdCB0aGVyZSBpcyBubyAn Zm9vJyBrbm9iIHByZXNlbnQsIHZzLiBrbm93aW5nIHRoYXQgdGhlCj4gPiBrbm9iIGlzIHByZXNl bnQgYW5kIHRoZSBhZ2VudCBzdXBwbGllZCBpdHMgb3duIHZhbHVlLCB2cy4ga25vd2luZwo+ID4g dGhlIGtub2IgaXMgcHJlc2VudCBhbmQgc29tZSBtYW5hZ2VyIHN1cHBsaWVkIHRoZSB2YWx1ZS4K PiA+IAo+ID4gWE1MIGF0dHJpYnV0ZXMgKGFsYSBvcGVyYXRpb24sIGtleSwgaW5zZXJ0KSBjb3Vs ZCBiZSBkZWZpbmVkCj4gPiB0byBhZGQgdG8gPGdldCo+IHJlcGxpZXMgZm9yIHRoaXMgcHVycG9z ZS4KPiAKPiBPbmUgdXNlLWNhc2UgdG8gdGhpbmsgYWJvdXQuICBTdXBwb3NlIGEgbWFuYWdlciBz ZW5kcyBhIDxnZXQtY29uZmlnLz4KPiBpbiBvcmRlciB0byBzdG9yZSBhIGJhY2t1cC4gIExhdGVy IGhlIHNlbmRzIHRoaXMgYmFja3VwIGJhY2sgaW4gYW4KPiA8ZWRpdC1jb25maWcvPi4gIElmIHRo ZSBnZXQtY29uZmlnIHJlcGx5IGluY2x1ZGVkIGRlZmF1bHRzIHcvbyBhbnkKPiBhbm5vdGF0aW9u cywgdGhlIGVkaXQtY29uZmlnIHdpbGwgZXhwbGljaXRseSBzZXQgYWxsIHRob3NlIGRlZmF1bHRz LAo+IGFuZCB0aGV5IGFyZSBubyBsb25nZXIgZGVmYXVsdHMuICBUaGlzIGlzIHNvbWV0aGluZyBJ IHRoaW5rIHdlIG11c3QKPiBhdm9pZC4KPiAKPiAKPiAvbWFydGluCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4g bmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jun 12 02:05: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 798033A69EC; Thu, 12 Jun 2008 02:05: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 557853A693D for ; Thu, 12 Jun 2008 02:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W78dwANY7v5v for ; Thu, 12 Jun 2008 02:05:09 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 623763A6782 for ; Thu, 12 Jun 2008 02:05:09 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 6DE4F1B80C8; Thu, 12 Jun 2008 11:05:36 +0200 (CEST) Date: Thu, 12 Jun 2008 11:05:43 +0200 (CEST) Message-Id: <20080612.110543.144949271.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1213259728.6339.43.camel@missotis> References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <1213259728.6339.43.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] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Ladislav Lhotka wrote: > Hi, > > there are actually two forms of configuration data that YANG models > directly address: > > A. Full configuration with all parameters that the agent uses in any > way. > > B. Reduced configuration where some parameters may be missing because > they have default values in the full configuration. > > In A, "optional" means that either the parameter is not essential (e.g., > description) For example: leaf description { mandatory false; type string; } > OR that it is in a subsystem that may not be operational > (that means inside a "presence" container that is missing). For example: container ssh { presence "Enables ssh"; leaf ip { mandatory true; type inet:ip-address; } } Are my examples what you had in mind? You say that 'ip' is optional, b/c it is defined within a presence-container. In my view, it is still mandatory - but mandatory always has a scope; the node MUST exist if its parent exist. > In B, "optional" may mean the same things as above, but also that the > parameter in question has a default value. > > I think it would be useful to clearly distinguish these three meanings > of mandatory/optional in YANG. First, note that we don't use the word "optional" to describe these. I don't agree that there are different meanings of 'mandatory'. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 02:23: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 6853D3A6822; Thu, 12 Jun 2008 02:23: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 0F7F33A697D for ; Thu, 12 Jun 2008 02:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=0.136, 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 nT32jOduEEf2 for ; Thu, 12 Jun 2008 02:23:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 35DF33A6822 for ; Thu, 12 Jun 2008 02:23:38 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 55D04D800C8; Thu, 12 Jun 2008 11:24:05 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080612.110543.144949271.mbj@tail-f.com> References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <1213259728.6339.43.camel@missotis> <20080612.110543.144949271.mbj@tail-f.com> Organization: CESNET Date: Thu, 12 Jun 2008 11:24:05 +0200 Message-Id: <1213262645.6339.77.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMTIuIDA2LiAyMDA4IHYgMTE6MDUgKzAyMDA6 Cj4gICAKPiAgIGNvbnRhaW5lciBzc2ggewo+ICAgICBwcmVzZW5jZSAiRW5hYmxlcyBzc2giOwo+ ICAgICAKPiAgICAgbGVhZiBpcCB7IAo+ICAgICAgIG1hbmRhdG9yeSB0cnVlOwo+ICAgICAgIHR5 cGUgaW5ldDppcC1hZGRyZXNzOwo+ICAgICB9Cj4gICB9CgpUaGlzIGlzIGEgZ29vZCBleGFtcGxl OiBJUCBhZHJlc3MgaXMgbWFuZGF0b3J5LCBzaW5jZSBzc2ggc2VydmVyIGNhbm5vdAp3b3JrIHdp dGhvdXQgaXQuIEJ1dCBhIGNvbW1vbiBwcmFjdGljZSBhcHBsaWVkIGJ5IG1hbnkgZGV2aWNlcyBp cyB0byBzZXQKaXQgYnkgZGVmYXVsdCB0byBhbiBSRkMgMTkxOCBhZGRyZXNzLgoKU28gaW4gZmFj dCB0aGlzIGlzIHRoZSBjYXNlIHdoZXJlIGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgYm90aCBtYW5k YXRvcnkKYW5kIGRlZmF1bHQsIGlmIHdlIGludGVycHJldCBtYW5kYXRvcnkgYXMgImVzc2VudGlh bCBpbiB0aGUgZnVsbApjb25maWd1cmF0aW9uIi4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2Es IENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Jun 12 05:41: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 495C83A6904; Thu, 12 Jun 2008 05:41: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 1D5DC3A67E2 for ; Thu, 12 Jun 2008 05:41:35 -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 7CydAI21s8Zy for ; Thu, 12 Jun 2008 05:41:34 -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 9D7BD3A6AC8 for ; Thu, 12 Jun 2008 05:41:26 -0700 (PDT) Received: (qmail 62163 invoked from network); 12 Jun 2008 12:41:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 12 Jun 2008 12:41:53 -0000 X-YMail-OSG: Wj90QZEVM1mAJYO27yTmmX2y0EZcBpU97QXOExXy4G38J6aCRHBznaa_a4drvgKARiIyQSVXzXM76vML7IRfe0qrU3iBMhBzz.f2g5Pak9QFo72odhocGuVgXrDc8NHd_.Q- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4851198E.5020802@andybierman.com> Date: Thu, 12 Jun 2008 05:41:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> In-Reply-To: <20080612.080808.258902106.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, >..... >> I think the controversy is with agent-supplied defaults that >> are not documented in the data model > > Right. We have three options here. > > 1. pretend that agent-supplied defaults don't exist > > 2. realize that they do exit, but don't have any formal support for > specifying them, and thus no formal support for a client to > learn them. > > 3. make it possible for an agent developer to specify them, and thus > for a client to learn them and adapt to them. > This is not really possible. If the leaf or typedef has a default, then the agent MUST use it. If it doesn't, the agent is free to choose any default. I do not want to change the meaning of default to be the same as SMI. This is not really a YANG issue, but rather a protocol issue that should be solved with the 'with-defaults' flag. The only argument against returning agent-supplied defaults is that there might be lots of them. IMO this is flawed logic. 1) It should be up to the operator, not the vendor, to decide when to return these agent-supplied defaults 2) It should be up to the operator, not the vendor, to decide if CPU and bandwidth would be 'wasted' or simply 'used' by retrieving these agent supplied defaults 3) It is well understood that silent changes to config defaults across versions and/or platforms is a source of network outages, which should be addressed by a robust standards-based configuration solution > >.... > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 06:24: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 368463A6767; Thu, 12 Jun 2008 06:24: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 4B32C3A6915 for ; Thu, 12 Jun 2008 06:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4Elahf-Gy6X for ; Thu, 12 Jun 2008 06:24:19 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 158183A6818 for ; Thu, 12 Jun 2008 06:24:19 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 809F01B80C8; Thu, 12 Jun 2008 15:24:46 +0200 (CEST) Date: Thu, 12 Jun 2008 15:24:54 +0200 (CEST) Message-Id: <20080612.152454.216453357.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4851198E.5020802@andybierman.com> References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@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] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > >..... > >> I think the controversy is with agent-supplied defaults that > >> are not documented in the data model > > Right. We have three options here. 1. pretend that agent-supplied defaults don't exist > > 2. realize that they do exit, but don't have any formal support for > > specifying them, and thus no formal support for a client to > > learn them. > > 3. make it possible for an agent developer to specify them, and thus > > for a client to learn them and adapt to them. > > > > This is not really possible. Do you mean that 3 is not possible? I think it might be (think positive!) But is it something we want to do? > If the leaf or typedef has a default, then the agent MUST use it. Agreed. > If it doesn't, the agent is free to choose any default. Even when mandatory is true? Even when mandatory if false? These are the rules that we will have to spell out, if we go for 2) or 3) above. > I do not want to change the meaning of default to be > the same as SMI. Neither do I. > This is not really a YANG issue, but rather a protocol issue > that should be solved with the 'with-defaults' flag. > > The only argument against returning agent-supplied defaults > is that there might be lots of them. IMO this is flawed logic. Agreed. > 1) It should be up to the operator, not the vendor, to decide > when to return these agent-supplied defaults > > 2) It should be up to the operator, not the vendor, to decide > if CPU and bandwidth would be 'wasted' or simply 'used' > by retrieving these agent supplied defaults > > 3) It is well understood that silent changes to config defaults across > versions and/or platforms is a source of network outages, which > should be addressed by a robust standards-based configuration solution Agreed. So we agree that :with-defaults is the solution for controlling when defaults are sent. The issue here is how/if agent-supplied defaults are specified and learned by the client. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 06:50: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 EBC423A6ADF; Thu, 12 Jun 2008 06:50: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 236DF3A6AE8 for ; Thu, 12 Jun 2008 06:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 JeMMEwtkgntQ for ; Thu, 12 Jun 2008 06:50:36 -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 BA9C23A6AE3 for ; Thu, 12 Jun 2008 06:50:35 -0700 (PDT) Received: (qmail 62557 invoked from network); 12 Jun 2008 13:51:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 12 Jun 2008 13:51:02 -0000 X-YMail-OSG: bxUSLk8VM1mAdqwCOJNempjBVIOpuO1UYr4gPCBpN0x_gQxW70jxkNIQHIrIKMRvd9DvHupvD5xgXLEh35ci1MwbkOnUAoZ.oYa3XW2qOQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485129C3.3050009@netconfcentral.com> Date: Thu, 12 Jun 2008 06:50:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com> <20080612.152454.216453357.mbj@tail-f.com> In-Reply-To: <20080612.152454.216453357.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> ..... >>>> I think the controversy is with agent-supplied defaults that >>>> are not documented in the data model >>> Right. We have three options here. 1. pretend that agent-supplied defaults don't exist >>> 2. realize that they do exit, but don't have any formal support for >>> specifying them, and thus no formal support for a client to >>> learn them. >>> 3. make it possible for an agent developer to specify them, and thus >>> for a client to learn them and adapt to them. >>> >> This is not really possible. > > Do you mean that 3 is not possible? I think it might be (think > positive!) But is it something we want to do? > Why not just use to retrieve the values at runtime? It is a flawed hack to force operators to rely on external documentation that may not even be correct on all platforms. It is easier and more robust to simply ask the agent what values are in effect at the moment. >> If the leaf or typedef has a default, then the agent MUST use it. > > Agreed. > >> If it doesn't, the agent is free to choose any default. > > Even when mandatory is true? Even when mandatory if false? > no -- if mandatory is true then the agent must not use any default, documented or not. The agent must wait for the manager to provide a value, or it is an error. If mandatory is false, and there is no default, documented or otherwise, then the node is not needed for operation, and the config will be accepted without the node. > These are the rules that we will have to spell out, if we go for 2) or > 3) above. > >> I do not want to change the meaning of default to be >> the same as SMI. > > Neither do I. > >> This is not really a YANG issue, but rather a protocol issue >> that should be solved with the 'with-defaults' flag. >> >> The only argument against returning agent-supplied defaults >> is that there might be lots of them. IMO this is flawed logic. > > Agreed. > >> 1) It should be up to the operator, not the vendor, to decide >> when to return these agent-supplied defaults >> >> 2) It should be up to the operator, not the vendor, to decide >> if CPU and bandwidth would be 'wasted' or simply 'used' >> by retrieving these agent supplied defaults >> >> 3) It is well understood that silent changes to config defaults across >> versions and/or platforms is a source of network outages, which >> should be addressed by a robust standards-based configuration solution > > Agreed. > > So we agree that :with-defaults is the solution for controlling when > defaults are sent. The issue here is how/if agent-supplied defaults > are specified and learned by the client. > I don't want to complicate the default-stmt with sort-of-default, or sometimes-default statements. Also, this issue could be viewed as just one detail within the larger AGENT-CAPABILITIES problem. I prefer to deal with the entire problem (but sometime in the future, after YANG 1.0 is done.) > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 08:25: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 5F5063A67AB; Thu, 12 Jun 2008 08:25: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 4590D3A6968 for ; Thu, 12 Jun 2008 08:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsEGtwwhDJcC for ; Thu, 12 Jun 2008 08:25:12 -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 C7C443A67AB for ; Thu, 12 Jun 2008 08:25:11 -0700 (PDT) Received: (qmail 80814 invoked from network); 12 Jun 2008 15:25:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 12 Jun 2008 15:25:32 -0000 X-YMail-OSG: U40UGHgVM1ljf03_PtE2EEKErlg7u7qcnnZiy3a0U1cBL49b7fh2YuPUipeuerL.NAv4GymQ7nzDxsAKV3OhPK3NNvyzwbr6bgVuq42qLQvxIjoBzT7hi1BvulC7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48513FE9.1030901@netconfcentral.com> Date: Thu, 12 Jun 2008 08:25:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com> <20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> In-Reply-To: <485129C3.3050009@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, >>... >>> If the leaf or typedef has a default, then the agent MUST use it. >> Agreed. >> >>> If it doesn't, the agent is free to choose any default. >> Even when mandatory is true? Even when mandatory if false? >> > I think these rules make sense for default and mandatory: - if mandatory==true: * default-stmt MUST NOT appear in the same YANG construct * if the data type has a default defined, then the agent will ignore it * the agent will not supply a default value under any conditions * an rpc-error will be generated for to or of to , if this node is missing - else: * if default-stmt is present in the leaf*, the agent will use it * else if the data type has a default defined, then the agent will use it * else the agent is free to supply any default value that is valid for the data type - if the agent supplies a value: - a node exists in the configuration with the value - the meta-variable 'set-by' is given the value 'agent' - else if the manager supplies a value: - a node exists in the configuration with the value - the meta-variable 'set-by' is given the value 'manager' - else: - a node does not exist in the configuration and the data model defines what happens if the node is missing The 'set-by' meta-variable is maintained by the agent for each node. If the 'with-defaults' flag (in retrieval requests) is set to 'true', then nodes where set-by==agent are included in the response. Otherwise these agent-supplied nodes are not returned in any data retrieval operation, including . A node is returned in operations (if with-defaults==false) if the manager provides a value, even if the manager happens to provide the default value for the leaf. A standard read-only data model object called 'with-defaults-default' is needed, to indicate which mode the agent will use if no 'with-defaults' flag is present in a retrieval request. IMO, RFC 4741 does not recognize 'with-defaults==false', but real-world routers do not work this way, so the default (for the default ;-) should be false. leaf with-defaults-default { description "Indicates whether agent-supplied nodes will be returned in retrieval operations, if the 'with-defaults' attribute is not present."; type boolean; config false; default false; } Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 09:53: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 8363B3A67AB; Thu, 12 Jun 2008 09:53: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 4D85A3A67AB for ; Thu, 12 Jun 2008 09:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.390, 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 c3nTryy4OsAz for ; Thu, 12 Jun 2008 09:53: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 7A8763A6830 for ; Thu, 12 Jun 2008 09:53:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1F9CC0060; Thu, 12 Jun 2008 18:53:31 +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 4nuoLIj9AYYs; Thu, 12 Jun 2008 18:53:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16293C005A; Thu, 12 Jun 2008 18:53:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D95D45B6B76; Thu, 12 Jun 2008 18:53:24 +0200 (CEST) Date: Thu, 12 Jun 2008 18:53:24 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080612165324.GA3763@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com> <20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <48513FE9.1030901@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48513FE9.1030901@netconfcentral.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory 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, Jun 12, 2008 at 08:25:29AM -0700, Andy Bierman wrote: > I think these rules make sense for default and mandatory: [...] So if there is a value with the meta-variable "set-by" with a value 'agent', how does this impact edit-config operations with say the operation create? Will it fail or succeed? It looks to me that we are facing a problem in the protocol which ought to be solved 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 Jun 12 10:21: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 393BA3A681E; Thu, 12 Jun 2008 10:21: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 1399E3A68AD for ; Thu, 12 Jun 2008 10:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74Cd87L3XUEj for ; Thu, 12 Jun 2008 10:21:57 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 257703A681E for ; Thu, 12 Jun 2008 10:21:56 -0700 (PDT) Received: (qmail 24843 invoked from network); 12 Jun 2008 17:22:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 12 Jun 2008 17:22:24 -0000 X-YMail-OSG: izuLN.kVM1kzvk2NjqLYmarUeeOyIAyPMUWS4zqCwIxdKpRPyGaGYV5wwmCQN6KXCNpwkAo4rlAlcnVgUK9TtxWRQS95ssLbwfkXH__Axy.NCHXADbGtOBrplhRCurVS0Dw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48515B4D.2070608@netconfcentral.com> Date: Thu, 12 Jun 2008 10:22:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com> <20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <48513FE9.1030901@netconfcentral.com> <20080612165324.GA3763@elstar.local> In-Reply-To: <20080612165324.GA3763@elstar.local> Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Jun 12, 2008 at 08:25:29AM -0700, Andy Bierman wrote: > >> I think these rules make sense for default and mandatory: > > [...] > > So if there is a value with the meta-variable "set-by" with a value > 'agent', how does this impact edit-config operations with say the > operation create? Will it fail or succeed? It should fail. That is why it is important that the entire configuration be visible, if requested. > > It looks to me that we are facing a problem in the protocol which > ought to be solved there. YANG is supposed to provide an XML mapping for NETCONF operations. This seems to fall under that charter item, but you are probably right. I don't want one operation for YANG data models and another for non-YANG. We already have that with the operation, which is bad enough. This does not have to be standardized at all, if there is no consensus on the problem or the solution. However, there are many aspects of CLI-based configuration management that are not very inter-operable, and therefore are not appropriate for IETF standards. NETCONF + proprietary XML is not that much better than SSH + proprietary CLI, and it appears the operators know that. > > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 11:13: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 16A7E3A69DD; Thu, 12 Jun 2008 11:13: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 CD5D43A67AB for ; Thu, 12 Jun 2008 11:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=0.125, 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 CdzhYploLZhS for ; Thu, 12 Jun 2008 11:13:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0AFDB3A6784 for ; Thu, 12 Jun 2008 11:13: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 B32F0D800C4 for ; Thu, 12 Jun 2008 20:14:22 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <48513FE9.1030901@netconfcentral.com> References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com> <20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <48513FE9.1030901@netconfcentral.com> Organization: CESNET Date: Thu, 12 Jun 2008 20:14:23 +0200 Message-Id: <1213294463.6339.148.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAxMi4gMDYuIDIwMDggdiAwODoyNSAtMDcwMDoKPiBU aGUgJ3NldC1ieScgbWV0YS12YXJpYWJsZSBpcyBtYWludGFpbmVkIGJ5IHRoZSBhZ2VudCBmb3Ig ZWFjaCBub2RlLgo+IElmIHRoZSAnd2l0aC1kZWZhdWx0cycgZmxhZyAoaW4gcmV0cmlldmFsIHJl cXVlc3RzKSBpcyBzZXQgdG8gJ3RydWUnLAo+IHRoZW4gbm9kZXMgd2hlcmUgc2V0LWJ5PT1hZ2Vu dCBhcmUgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbnNlLgo+IE90aGVyd2lzZSB0aGVzZSBhZ2VudC1z dXBwbGllZCBub2RlcyBhcmUgbm90IHJldHVybmVkIGluIGFueQo+IGRhdGEgcmV0cmlldmFsIG9w ZXJhdGlvbiwgaW5jbHVkaW5nIDxjb3B5LWNvbmZpZz4uCj4gCgpCdXQgdGhlcmUgc3RpbGwgbXVz dCBiZSBhbiBvcHRpb24gZm9yIHRoZSBtYW5hZ2VyIHRvIGFzayB0aGUgYWdlbnQgZm9yCkFMTCB2 YWx1ZXMgaW4gaXRzIGNvbmZpZ3VyYXRpb24gZGF0YWJhc2UgaW5jbHVkaW5nIGRhdGEgbW9kZWwg ZGVmYXVsdHMuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDog RTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Jun 12 11:36:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D513A679C; Thu, 12 Jun 2008 11:36:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555B53A6B08 for ; Thu, 12 Jun 2008 11:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 GA5gKKqy8fF5 for ; Thu, 12 Jun 2008 11:36:13 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 69F273A679C for ; Thu, 12 Jun 2008 11:36:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ESPlA9RZI2HmlOUlBnEHTNO1kI4xAIFm+fmEapax0COBMG9D5Ql5a3iQeN4AuzQc; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.83.45] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K6rf6-0003c3-4g for netmod@ietf.org; Thu, 12 Jun 2008 14:36:40 -0400 Message-ID: <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com><20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> Date: Thu, 12 Jun 2008 11:37:28 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b33f66f7d91f2af032a41240f02f19ecc9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.83.45 Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Martin Bjorklund" > Cc: > Sent: Thursday, June 12, 2008 6:50 AM > Subject: Re: [netmod] default and mandatory ... > I don't want to complicate the default-stmt with sort-of-default, > or sometimes-default statements. When the requirements design team hashed through this, our general conclusion was that defaults were useful only if they specified an interface contract. Anything else (including the SMI-style sense) didn't help provide a real configuration management solution. > Also, this issue could be viewed > as just one detail within the larger AGENT-CAPABILITIES problem. > I prefer to deal with the entire problem (but sometime in the future, > after YANG 1.0 is done.) A slightly different way of looking at this, which entirely eliminates the need for AGENT-CAPABILITIES, is to derive a version or platform- specific model from the "standard" model. This way, vendor-specific extensions and limitations, model-specific quirks, and all the stuff that comes with multiple releases can be handled in the same way. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 12:02: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 010023A6AAB; Thu, 12 Jun 2008 12:02: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 5ECE13A6A86 for ; Thu, 12 Jun 2008 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0--cXkOSdK+H for ; Thu, 12 Jun 2008 12:02:02 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id EFEFA3A6ABF for ; Thu, 12 Jun 2008 12:01:55 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 9501D1B80C8; Thu, 12 Jun 2008 21:02:24 +0200 (CEST) Date: Thu, 12 Jun 2008 21:02:33 +0200 (CEST) Message-Id: <20080612.210233.110686457.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <485129C3.3050009@netconfcentral.com> References: <4851198E.5020802@andybierman.com> <20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@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] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > >>> Right. We have three options here. 1. pretend that agent-supplied defaults don't exist > >>> 2. realize that they do exit, but don't have any formal support for > >>> specifying them, and thus no formal support for a client to > >>> learn them. > >>> 3. make it possible for an agent developer to specify them, and thus > >>> for a client to learn them and adapt to them. I think that you're saying that we should do 2, i.e. make sure the document handles the case that agent-supplied defaults exist. I would prefer to explore 3, to see if that would work. > >> This is not really possible. > > Do you mean that 3 is not possible? I think it might be (think > > positive!) But is it something we want to do? > > > > Why not just use to retrieve the values at runtime? > It is a flawed hack to force operators to rely on external > documentation that may not even be correct on all platforms. I haven't talked about using flawed external documentation. There might be other solutions to this problem. > >> If the leaf or typedef has a default, then the agent MUST use it. > > Agreed. > > > >> If it doesn't, the agent is free to choose any default. > > Even when mandatory is true? Even when mandatory if false? > > > > > no -- if mandatory is true then the agent must not use > any default, documented or not. The agent must wait > for the manager to provide a value, or it is an error. Ladislav brought up a use-case where mandatory and agent-supplied default would make sense. Again, this depends on if we want to do 2 or 3. If we do 2, then I agree with you, b/c otherwise there would be no way (but trial-and-error) for a manager to know if it has to provide values for all mandatory leafs. OTOH, if we do 3, then the manager would know if a particular agent uses a default value or not. > I don't want to complicate the default-stmt with sort-of-default, > or sometimes-default statements. Neither do I. > Also, this issue could be viewed > as just one detail within the larger AGENT-CAPABILITIES problem. > I prefer to deal with the entire problem (but sometime in the future, > after YANG 1.0 is done.) Yes maybe you are right. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 12:02: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 A86DD3A689B; Thu, 12 Jun 2008 12:02: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 A30863A6AF9 for ; Thu, 12 Jun 2008 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 pXJlO+lpbpP6 for ; Thu, 12 Jun 2008 12:02:05 -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 59FD53A6B23 for ; Thu, 12 Jun 2008 12:01:35 -0700 (PDT) Received: (qmail 99918 invoked from network); 12 Jun 2008 19:02:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 12 Jun 2008 19:02:03 -0000 X-YMail-OSG: NTLZVpoVM1nPv0X325m5hMdK3NXwHOtxDX8.FukvzSr2IXJCBDmzqLSHtRnXNqvff9.FshMhOpYr_xV_3KeLtezM6H.c9aIZaBj5VPv6CCosXwlHKehnk8Yia56LckPT44c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485172A8.6010706@netconfcentral.com> Date: Thu, 12 Jun 2008 12:02:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com><20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> In-Reply-To: <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Martin Bjorklund" >> Cc: >> Sent: Thursday, June 12, 2008 6:50 AM >> Subject: Re: [netmod] default and mandatory > ... >> I don't want to complicate the default-stmt with sort-of-default, >> or sometimes-default statements. > > When the requirements design team hashed through this, our general > conclusion was that defaults were useful only if they specified an > interface contract. Anything else (including the SMI-style sense) didn't > help provide a real configuration management solution. > Fine, but that's not really the issue at hand. The problem is that the CLI style of CM is to document all the agent-supplied defaults off-line in an ad-hoc manner. In YANG terms, these are the values the agent fills in when there is no default-stmt to apply and mandatory==false. In NETCONF terms, a manager has no way of knowing (through the protocol) which knobs of this type are not in use, and which are in use with an internal default, or what that internal default value is on a particular agent. These knobs could account for most of the CLI. Given that vendors are even less likely to agree on standard YANG defaults, when they can barely agree on SMIv2 DEFVAL suggested defaults, a NETCONF manager is going to need to deal with this problem. IMO, this is an area where the 'native' interface is not good enough for standards, and something better is needed. >> Also, this issue could be viewed >> as just one detail within the larger AGENT-CAPABILITIES problem. >> I prefer to deal with the entire problem (but sometime in the future, >> after YANG 1.0 is done.) > > A slightly different way of looking at this, which entirely eliminates the > need for AGENT-CAPABILITIES, is to derive a version or platform- > specific model from the "standard" model. This way, vendor-specific > extensions and limitations, model-specific quirks, and all the stuff that > comes with multiple releases can be handled in the same way. It seems like more work than just retrieving the values from the agent, and it still requires a lot of offline documentation, but it is machine-readable documentation at least. > > Randy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 12:08: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 026B23A6784; Thu, 12 Jun 2008 12:08: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 7BEB83A686E for ; Thu, 12 Jun 2008 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwnSIlpDCRDj for ; Thu, 12 Jun 2008 12:08:20 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 8DD3D3A69AB for ; Thu, 12 Jun 2008 12:08:20 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 837BD1B80C8; Thu, 12 Jun 2008 21:08:49 +0200 (CEST) Date: Thu, 12 Jun 2008 21:08:58 +0200 (CEST) Message-Id: <20080612.210858.218814317.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> References: <20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <008301c8ccbb$5eab62a0$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] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, "Randy Presuhn" wrote: > Hi - > > > From: "Andy Bierman" > > Also, this issue could be viewed > > as just one detail within the larger AGENT-CAPABILITIES problem. > > I prefer to deal with the entire problem (but sometime in the future, > > after YANG 1.0 is done.) > > A slightly different way of looking at this, which entirely eliminates the > need for AGENT-CAPABILITIES, is to derive a version or platform- > specific model from the "standard" model. This way, vendor-specific > extensions and limitations, model-specific quirks, and all the stuff that > comes with multiple releases can be handled in the same way. Yes, I have been thinking about using the standard module + an overlay module which specifices implementation-specific defaults. This overlay module would be available through the schema discovery mechanism. Something like this: // std module module foo { ... container a { leaf b { type int32; } } } // implementation-specific overlay agent-module foo { container a { leaf b { default 42; } } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 12:14:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3483A679C; Thu, 12 Jun 2008 12:14:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837E53A679C for ; Thu, 12 Jun 2008 12:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 waTP5jwgLDqe for ; Thu, 12 Jun 2008 12:14:18 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 990183A67CC for ; Thu, 12 Jun 2008 12:14:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kbLxPIRrYAHIFsuUfaZ96cXx8ng2gawK7mOR7VBqwYGx+p88T2LhYi0kiqeuVw9V; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.83.45] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K6sFx-0002Fp-I3 for netmod@ietf.org; Thu, 12 Jun 2008 15:14:45 -0400 Message-ID: <00ab01c8ccc0$b26045a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com><20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> <485172A8.6010706@netconfcentral.com> Date: Thu, 12 Jun 2008 12:15:36 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b33e43cd9c81225d20e5d83a4a5971a6eb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.83.45 Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 12, 2008 12:02 PM > Subject: Re: [netmod] default and mandatory ... > Fine, but that's not really the issue at hand. > The problem is that the CLI style of CM is to document > all the agent-supplied defaults off-line in an ad-hoc manner. > In YANG terms, these are the values the agent fills in when > there is no default-stmt to apply and mandatory==false. > > In NETCONF terms, a manager has no way of knowing > (through the protocol) which knobs of this type > are not in use, and which are in use with an internal default, > or what that internal default value is on a particular agent. ... Such things, while perhaps well-intentioned and convenient, are *toxic* to real configuration management. If the interface specifications are incomplete or inaccurate, we shoudn't be surprised if configuration errors cause significant operational problems. If we follow a course that guarantees that interface specifications are incomplete or inaccurate, if we can't provide a way to determine *exactly* what a device's configuration is, and, more importantly, how to return that device to that *exact* configuration at some later point in time, this exercise will have been a waste of time. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 12:33: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 C24F93A683E; Thu, 12 Jun 2008 12:33: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 709333A686D for ; Thu, 12 Jun 2008 12:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 C06L8p0sR-4T for ; Thu, 12 Jun 2008 12:33:36 -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 A73A73A683E for ; Thu, 12 Jun 2008 12:33:36 -0700 (PDT) Received: (qmail 6888 invoked from network); 12 Jun 2008 19:34:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 12 Jun 2008 19:34:01 -0000 X-YMail-OSG: 7Ky_MlcVM1kOBYhV39Dj17ARDeCYAlxj78WJAL5kGgCJ4HLVJpScXGOxh0IzRbvhUGveA1sOHE1.HOo5.tNq4SvQaxTEMKPFY2cOcTm2l9cV10ol7JjlXBLR9niqIiAiJDU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48517A26.3030600@netconfcentral.com> Date: Thu, 12 Jun 2008 12:33:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <4851198E.5020802@andybierman.com><20080612.152454.216453357.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> <485172A8.6010706@netconfcentral.com> <00ab01c8ccc0$b26045a0$6801a8c0@oemcomputer> In-Reply-To: <00ab01c8ccc0$b26045a0$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: >> Sent: Thursday, June 12, 2008 12:02 PM >> Subject: Re: [netmod] default and mandatory > ... >> Fine, but that's not really the issue at hand. >> The problem is that the CLI style of CM is to document >> all the agent-supplied defaults off-line in an ad-hoc manner. >> In YANG terms, these are the values the agent fills in when >> there is no default-stmt to apply and mandatory==false. >> >> In NETCONF terms, a manager has no way of knowing >> (through the protocol) which knobs of this type >> are not in use, and which are in use with an internal default, >> or what that internal default value is on a particular agent. > ... > > Such things, while perhaps well-intentioned and convenient, > are *toxic* to real configuration management. > > If the interface specifications are incomplete or inaccurate, > we shoudn't be surprised if configuration errors cause > significant operational problems. If we follow a course that > guarantees that interface specifications are incomplete or > inaccurate, if we can't provide a way to determine *exactly* > what a device's configuration is, and, more importantly, how > to return that device to that *exact* configuration at some > later point in time, this exercise will have been a waste of time. > +1 IMO, it is not a coincidence that all of the NMS projects of this nature ever attempted (at my former employer), failed because they could not deal with the massive data silo maintenance. Data-model driven tool automation is the only viable answer, but it requires some changes from the 'CLI' way of doing CM. > Randy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 12 13:29: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 CE8DC3A6975; Thu, 12 Jun 2008 13:29: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 2D5773A6A8B for ; Thu, 12 Jun 2008 13:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.354, 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 FENX2C2K-kE2 for ; Thu, 12 Jun 2008 13:29:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D1B833A69BD for ; Thu, 12 Jun 2008 13:29:37 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CBC5C006E; Thu, 12 Jun 2008 22:30:07 +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 MHleiv84zr-E; Thu, 12 Jun 2008 22:30:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07609C0060; Thu, 12 Jun 2008 22:30:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D6EC75CDE9E; Thu, 12 Jun 2008 22:29:59 +0200 (CEST) Date: Thu, 12 Jun 2008 22:29:59 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080612202959.GA3598@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> <485172A8.6010706@netconfcentral.com> <00ab01c8ccc0$b26045a0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00ab01c8ccc0$b26045a0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory 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, Jun 12, 2008 at 12:15:36PM -0700, Randy Presuhn wrote: > If the interface specifications are incomplete or inaccurate, > we shoudn't be surprised if configuration errors cause > significant operational problems. If we follow a course that > guarantees that interface specifications are incomplete or > inaccurate, if we can't provide a way to determine *exactly* > what a device's configuration is, and, more importantly, how > to return that device to that *exact* configuration at some > later point in time, this exercise will have been a waste of time. Setting the *exact* configuration at some later point in time on the *same* device (same hardware plus same firmware) is a realistic goal. However, once you allow changes in hardware or firmware, the problem becomes really really hard and if we set the bar that high, we are going to fail. If you look at a plain Unix server, you likely have hundreds of knobs and several interesting possible interactions between them. The only way I personally survive is by trusting package and software maintainers to set "sensible" defaults and most of the time this works extremely well. So I am with Phil in the sense that most of the time, I do not really want to see all the many defaults that exist. If I have to dig deep to solve a specific problem, I am happy with finding the relevant default _values_ and being able to change them. And no, I do not use (=trust) documentation to tell me what the default is; I like to see the setting on the device itself. Perhaps we overestimate the value of the "default" statement in YANG and we underestimate the value of a NETCONF feature (get-settings ;-) to let me retrieve all knobs and their current settings when really needed. /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 Jun 12 13:48: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 49B3C3A6975; Thu, 12 Jun 2008 13:48: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 3B2A23A6899 for ; Thu, 12 Jun 2008 13:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 dfD6LZfl2Occ for ; Thu, 12 Jun 2008 13:48:14 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 325F33A6892 for ; Thu, 12 Jun 2008 13:48:14 -0700 (PDT) Received: (qmail 93916 invoked from network); 12 Jun 2008 20:48:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.128.201 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 12 Jun 2008 20:48:42 -0000 X-YMail-OSG: NhGyqosVM1mi1sACsLeOBI67K7v4MJxH8WVK1_8d2U2WXciFz3WBGL0XosNpUHDsgX.jn5Rh5vUHBDPYf5NWAF9EZj5uM8KTBQfkvPgl.3TE6.epmhhyfqvgaIzv3Sm42AA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48518BA7.1060507@netconfcentral.com> Date: Thu, 12 Jun 2008 13:48:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn , netmod@ietf.org References: <48506034.4000104@netconfcentral.com> <20080612.080808.258902106.mbj@tail-f.com> <485129C3.3050009@netconfcentral.com> <008301c8ccbb$5eab62a0$6801a8c0@oemcomputer> <485172A8.6010706@netconfcentral.com> <00ab01c8ccc0$b26045a0$6801a8c0@oemcomputer> <20080612202959.GA3598@elstar.local> In-Reply-To: <20080612202959.GA3598@elstar.local> Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Jun 12, 2008 at 12:15:36PM -0700, Randy Presuhn wrote: > >> If the interface specifications are incomplete or inaccurate, >> we shoudn't be surprised if configuration errors cause >> significant operational problems. If we follow a course that >> guarantees that interface specifications are incomplete or >> inaccurate, if we can't provide a way to determine *exactly* >> what a device's configuration is, and, more importantly, how >> to return that device to that *exact* configuration at some >> later point in time, this exercise will have been a waste of time. > > Setting the *exact* configuration at some later point in time on the > *same* device (same hardware plus same firmware) is a realistic goal. > However, once you allow changes in hardware or firmware, the problem > becomes really really hard and if we set the bar that high, we are > going to fail. > > If you look at a plain Unix server, you likely have hundreds of knobs > and several interesting possible interactions between them. The only > way I personally survive is by trusting package and software > maintainers to set "sensible" defaults and most of the time this works > extremely well. So I am with Phil in the sense that most of the time, > I do not really want to see all the many defaults that exist. If I > have to dig deep to solve a specific problem, I am happy with finding > the relevant default _values_ and being able to change them. And no, I > do not use (=trust) documentation to tell me what the default is; I > like to see the setting on the device itself. > We all share this position. Most (but not all) of the time, leave the agent-set defaults out. > Perhaps we overestimate the value of the "default" statement in YANG > and we underestimate the value of a NETCONF feature (get-settings ;-) > to let me retrieve all knobs and their current settings when really > needed. This would be OK. Instead of changing the existing and copy operations, create a new verb. It doesn't solve the behavior of being different on different agents, but it provides a clean way to get every knob. The operations need to be self-consistent on a given platform (at least). Phil and I came up with a good definition for property for NETCONF, that goes all the way back to the XMLCONF design team: - The 'payload' output from a or MUST be accepted by the agent without modification as input to an operation, when it has an empty configuration. > > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 04:57: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 96EF93A6963; Fri, 13 Jun 2008 04:57: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 3005C3A6810 for ; Fri, 13 Jun 2008 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG1cjVwK75+Q for ; Fri, 13 Jun 2008 04:52:18 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id DC6BA3A682A for ; Fri, 13 Jun 2008 04:52:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:37220 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1K77pl-0006Rs-5s; Fri, 13 Jun 2008 13:52:45 +0200 MIME-Version: 1.0 From: "netmod" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: balazs.lengyel@ericsson.com X-Trac-Project: netmod Date: Fri, 13 Jun 2008 11:52:45 -0000 X-URL: http://tools.ietf.org/netmod/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netmod/trac/ticket/2 Message-ID: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: balazs.lengyel@ericsson.com, netmod@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 13 Jun 2008 04:57:15 -0700 Cc: netmod@ietf.org Subject: [netmod] #2: Rpcs and Notification inside lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: netmod@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ticket #2: Rpcs and Notification inside lists Add the possibility to define notifications and custom-rpc inside a list. The XML encoding of the notification/rpc should include an instance- identifier pointing to the list(entry). This would make the object oriented usage of YANG much easier. -----------------------------------------+---------------------------------- Reporter: balazs.lengyel@ericsson.com | Owner: Type: enhancement | Status: new Priority: critical | Milestone: Component: YANG | Version: Severity: - | Keywords: -----------------------------------------+---------------------------------- -- Ticket URL: netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 05:04: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 6D1433A67A2; Fri, 13 Jun 2008 05:04: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 978763A63CB for ; Fri, 13 Jun 2008 05:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, 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 DlmfUiNLK4aP for ; Fri, 13 Jun 2008 05:04:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 177963A63D3 for ; Fri, 13 Jun 2008 05:04:48 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FF77C0014; Fri, 13 Jun 2008 14:05:19 +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 6BlRyXwmY8UD; Fri, 13 Jun 2008 14:05:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86C42C0010; Fri, 13 Jun 2008 14:05:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 696475CE801; Fri, 13 Jun 2008 14:05:12 +0200 (CEST) Date: Fri, 13 Jun 2008 14:05:12 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20080613120512.GA4378@elstar.local> Mail-Followup-To: netmod@ietf.org, balazs.lengyel@ericsson.com References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [netmod] #2: Rpcs and Notification inside lists 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, Jun 13, 2008 at 11:52:45AM -0000, netmod wrote: > Add the possibility to define notifications and custom-rpc inside a list. > The XML encoding of the notification/rpc should include an instance- > identifier pointing to the list(entry). > > This would make the object oriented usage of YANG much easier. Please explain why this is "much easier". Are you not just replacing an explict argument with an implicit one? Or do you also want to do magic name mangling of the rpc name itself? And if we were to do this, then why only for list elements? /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 Jun 13 05:50: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 17F893A68DE; Fri, 13 Jun 2008 05:50: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 E4C503A691C for ; Fri, 13 Jun 2008 05:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5HLnvEaoOvw for ; Fri, 13 Jun 2008 05:50:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 42B8F3A682A for ; Fri, 13 Jun 2008 05:50:06 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BCF612130D for ; Fri, 13 Jun 2008 14:50:36 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-9b-48526d1ce67b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A54A220F86 for ; Fri, 13 Jun 2008 14:50:36 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 14:50:45 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 14:50:45 +0200 Message-ID: <48526D1B.8080403@ericsson.com> Date: Fri, 13 Jun 2008 14:50:35 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> In-Reply-To: <20080613120512.GA4378@elstar.local> X-OriginalArrivalTime: 13 Jun 2008 12:50:45.0667 (UTC) FILETIME=[18C68730:01C8CD54] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I think if we allow the agent to supply a default value even when there is no default value in the YANG model that might confuse people. The whole aim of YANG is to specify the model formally. We have the default statement in YANG that can be used to specify the defaults. Why do we want to allow (or maybe even recommend) devices not to specify their default values? Are there simply to many defaults? In some cases it might be important whether a leaf exist or the agent creates it with an agent-supplied default value. Generally maintaining Andy's 'set-by' meta-variable is something I would like to avoid. Having multiple types of defaults (YANG documented and only agent supplied but not documented) is something I would also like to avoid if possible. ====================================================================================== I think if a leaf does not have a default statement that is part of the contract/model meaning that the leaf is NOT created/supplied with a value unless the operator really sets it. If the agents want to supply a default, I think it should include this fact in it's model! Any reason not to do that? If needed an an overlay module which specifices implementation-specific defaults might be a usable idea if we manage to keep it simple. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 06:17: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 42CB83A6977; Fri, 13 Jun 2008 06:17: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 A90D63A682F for ; Fri, 13 Jun 2008 06:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-0.814, 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 Q7+GTtqI1kX9 for ; Fri, 13 Jun 2008 06:17:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C758E3A6977 for ; Fri, 13 Jun 2008 06:17: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 99443D800C5 for ; Fri, 13 Jun 2008 15:17:48 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <48526D1B.8080403@ericsson.com> References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <48526D1B.8080403@ericsson.com> Organization: CESNET Date: Fri, 13 Jun 2008 15:17:48 +0200 Message-Id: <1213363068.6309.44.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgUMOhIDEzLiAwNi4gMjAwOCB2IDE0OjUwICswMjAwOgoK PiBJZiB0aGUgYWdlbnRzIHdhbnQgdG8gc3VwcGx5IGEgZGVmYXVsdCwgSSB0aGluayBpdCBzaG91 bGQgaW5jbHVkZSB0aGlzIGZhY3QgaW4gaXQncyBtb2RlbCEgQW55IAo+IHJlYXNvbiBub3QgdG8g ZG8gdGhhdD8KClRoaXMgd291bGQgcmVzdWx0IGludG8gd2F5IHRvbyBtYW55IGRhdGEgbW9kZWxz IGRpZmZlcmluZyBqdXN0IGJ5CmRlZmF1bHQgdmFsdWVzLiBUaGF0J3Mgd2h5IEkgc3RpbGwgdGhp bmsgaXQgaXMgYmV0dGVyIHRvIGtlZXAgdGhlIGRhdGEKbW9kZWwgYW5kIHBhcmFtZXRlciBkZWZh dWx0cyBhcyB0d28gaW5kZXBlbmRlbnQgdGhpbmdzLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3Rr YSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri Jun 13 06:32: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 E40353A682A; Fri, 13 Jun 2008 06:32: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 46C763A682A for ; Fri, 13 Jun 2008 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKZxvA6m7Aqr for ; Fri, 13 Jun 2008 06:32:57 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 509CA3A681E for ; Fri, 13 Jun 2008 06:32:57 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id dNea1Z0030QuhwU570Hg00; Fri, 13 Jun 2008 13:33:28 +0000 Received: from Harrington73653 ([222.210.104.239]) by OMTA02.westchester.pa.mail.comcast.net with comcast id dRZB1Z00559vUzA3NRZJdY; Fri, 13 Jun 2008 13:33:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=x7dXYSUcbJ1vaPDLwlwA:9 a=ATYNTzhvi2teMiM5Zl0A:7 a=w8LsCDEbVFm3tWL6VXvz-cKHvacA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Fri, 13 Jun 2008 21:33:19 +0800 Message-ID: <011e01c8cd5a$12fa8da0$9106a8c0@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: AcjNWgq3uVTXVYwxSOWh6qSkyIiEdw== Subject: [netmod] IETF72 sessions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Netmod has two sessions for IETF72. The first session is Thursday morning 9am. We expext this session will have some introduction and status presentations suitable for casual observers, plus some detailed technical work. The second session is Friday morning, and we expect this to be focused on technical details - not for the casual observer. Proposals for agenda items welcome. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 07:35: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 3246E3A681E; Fri, 13 Jun 2008 07:35: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 022B73A6924 for ; Fri, 13 Jun 2008 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCr2shesGXY3 for ; Fri, 13 Jun 2008 07:35:44 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 766DD3A681E for ; Fri, 13 Jun 2008 07:35:44 -0700 (PDT) Received: (qmail 92950 invoked from network); 13 Jun 2008 14:36:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.156.218 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 13 Jun 2008 14:36:14 -0000 X-YMail-OSG: yldbMtsVM1lJMenpJcBjAmwQKOuyzRrWa.g8kPc7V8p3J6IQRk2BLhoHmy3.jVBd9psE1XRGdHGH6a3SmKot.YKXPM9icqPaRkBC_GtQ.A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485285DB.9030402@netconfcentral.com> Date: Fri, 13 Jun 2008 07:36:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: netmod@ietf.org, balazs.lengyel@ericsson.com References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> In-Reply-To: <20080613120512.GA4378@elstar.local> Subject: Re: [netmod] #2: Rpcs and Notification inside lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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, Jun 13, 2008 at 11:52:45AM -0000, netmod wrote: > >> Add the possibility to define notifications and custom-rpc inside a list. >> The XML encoding of the notification/rpc should include an instance- >> identifier pointing to the list(entry). >> >> This would make the object oriented usage of YANG much easier. > > Please explain why this is "much easier". Are you not just replacing > an explict argument with an implicit one? Or do you also want to do > magic name mangling of the rpc name itself? And if we were to do this, > then why only for list elements? > I agree with Juergen. The NETCONF protocol is not object-oriented. The and messages are top-level elements, and the name of the RPC method is the element name. Allowing these constructs to appear at arbitrary points in the data subtree can create naming conflicts. The notification can always include a data node of type 'instance-identifier' to identify the list entry that caused the notification. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 08:06: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 BFF7E3A67A4; Fri, 13 Jun 2008 08:06: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 249A03A695D for ; Fri, 13 Jun 2008 08:06:38 -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 YGjr8BKXt5Yb for ; Fri, 13 Jun 2008 08:06:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9FF653A67A4 for ; Fri, 13 Jun 2008 08:06:36 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 84AA721142; Fri, 13 Jun 2008 17:07:07 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-69-48528d1b8d19 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6DBDB20F8D; Fri, 13 Jun 2008 17:07:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:07:16 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:07:16 +0200 Message-ID: <48528D1A.8000309@ericsson.com> Date: Fri, 13 Jun 2008 17:07:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <485285DB.9030402@netconfcentral.com> In-Reply-To: <485285DB.9030402@netconfcentral.com> X-OriginalArrivalTime: 13 Jun 2008 15:07:16.0184 (UTC) FILETIME=[2AB43D80:01C8CD67] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] #2: Rpcs and Notification inside lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Andy, What specific naming conflicts do you have in mind? On the general concept; I agree that YANG is not object oriented, but many people will use object oriented programing languages to implement it. Also you can find object orientation in KALUA, the XSD proposal and in Ericssons original modeling language, so it seems quite some people would be happy to use YANG in an object oriented manner. regards Balazs Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Fri, Jun 13, 2008 at 11:52:45AM -0000, netmod wrote: >> >>> Add the possibility to define notifications and custom-rpc inside a >>> list. >>> The XML encoding of the notification/rpc should include an instance- >>> identifier pointing to the list(entry). >>> >>> This would make the object oriented usage of YANG much easier. >> >> Please explain why this is "much easier". Are you not just replacing >> an explict argument with an implicit one? Or do you also want to do >> magic name mangling of the rpc name itself? And if we were to do this, >> then why only for list elements? >> > > I agree with Juergen. > The NETCONF protocol is not object-oriented. > The and messages are top-level elements, and the > name of the RPC method is the element name. Allowing these constructs > to appear at arbitrary points in the data subtree can create naming > conflicts. > > The notification can always include a data node of type > 'instance-identifier' > to identify the list entry that caused the notification. > >> /js >> > > Andy > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 08:09: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 20AE13A67A4; Fri, 13 Jun 2008 08:09: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 BF6633A6924 for ; Fri, 13 Jun 2008 08:09:36 -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 8hg8-cljBCNG for ; Fri, 13 Jun 2008 08:09:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7EFDF3A67A4 for ; Fri, 13 Jun 2008 08:09:35 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3D21520111; Fri, 13 Jun 2008 17:10:06 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-52-48528dce3a6c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 21C4420FF0; Fri, 13 Jun 2008 17:10:06 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:10:15 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:10:14 +0200 Message-ID: <48528DCD.3080903@ericsson.com> Date: Fri, 13 Jun 2008 17:10:05 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org, balazs.lengyel@ericsson.com, "Ersue, Mehmet (NSN - DE/Muenich)" References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> In-Reply-To: <20080613120512.GA4378@elstar.local> X-OriginalArrivalTime: 13 Jun 2008 15:10:14.0680 (UTC) FILETIME=[95189180:01C8CD67] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] #2: Rpcs and Notification inside lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, In object orientation it is usual to define methods/procedures as part of an object, a model defined RPC can be used as an equivalent(near equivalent) of a procedure in the OO world. This has the advantages: - the definition of the object and the procedure is kept in the same place. - It tells the reader that this procedure is related to this object - there is no need to define (or forget to define :-) an explicit references to the object - This allows an easy mapping from object oriented analysis (e.g. UML). You don't have to lift all the procedures to the top level - This allows an easy mapping to object oriented programming languages As described in the YANG draft Chapter 5.3 objects can be represented as lists in YANG. As for notifications: most notifications anyway have a source parameter pointing to a specific point (object) in the model. It would be easier if we could just define the notification inside an Object/list. - no need to explicitly define that the object is the source of the notification - the model shows which objects can be the source of which notifications. This is a bit of information our customers are frequently asking for. By the way both in the XSD proposal (http://www.ietf.org/proceedings/08mar/slides/canmod-3/canmod-3.htm) and in the Ericsson internal modeling language it is possible to embed actions in a managed object/managed resource. Balazs Juergen Schoenwaelder wrote: > On Fri, Jun 13, 2008 at 11:52:45AM -0000, netmod wrote: > >> Add the possibility to define notifications and custom-rpc inside a list. >> The XML encoding of the notification/rpc should include an instance- >> identifier pointing to the list(entry). >> >> This would make the object oriented usage of YANG much easier. > > Please explain why this is "much easier". Are you not just replacing > an explict argument with an implicit one? Or do you also want to do > magic name mangling of the rpc name itself? And if we were to do this, > then why only for list elements? > > /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 Fri Jun 13 08:16: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 BBF903A689E; Fri, 13 Jun 2008 08:16: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 49B983A689E for ; Fri, 13 Jun 2008 08:16:03 -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 X4oxRc+0Z1yP for ; Fri, 13 Jun 2008 08:16:02 -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 2A6A23A6825 for ; Fri, 13 Jun 2008 08:16:02 -0700 (PDT) Received: (qmail 57145 invoked from network); 13 Jun 2008 15:16:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.156.218 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 13 Jun 2008 15:16:28 -0000 X-YMail-OSG: DwiNhD0VM1ltF.Sjo5J4OSVaiik0gULY1Oq9JaxJGEojGupHSOpxTSoZIcs1jWaCmiVTNwYdC1j6Ta5RcqgxTUmY0BJl3JoSqSLGn5uCPQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48528F49.4010404@netconfcentral.com> Date: Fri, 13 Jun 2008 08:16:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <48526D1B.8080403@ericsson.com> In-Reply-To: <48526D1B.8080403@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > I think if we allow the agent to supply a default value even when there is no default value in > the YANG model that might confuse people. > I think we need to deal with the way real routers and other NE devices actually work. > The whole aim of YANG is to specify the model formally. We have the default statement in YANG > that can be used to specify the defaults. Why do we want to allow (or maybe even recommend) > devices not to specify their default values? Are there simply to many defaults? > The aim of NETCONF and YANG is to facilitate network configuration APIs that actually work, in a cost-effective manner. NE vendors cannot even agree on mandatory defaults within their own company, let alone across the entire industry. Agent-supplied defaults are a reality, and a robust CM solution should deal with them directly. Silent default changes across platforms and versions are also a reality. Sometimes silent default changes do the right thing, as Juergen said, and they are not a problem at all. But sometimes an operator wants to upgrade just a subset of routers to pick up some new features or bugfixes, and some totally unrelated feature breaks because different boxes in the same network are using different defaults. Operators hate to upgrade router code because of these types of surprises. Bottom line: The 'CLI way' of hiding agent-supplied knobs from the operator is broken, and a real CM solution will not be possible unless all the agent-supplied knobs can be retrieved from the agent somehow. > In some cases it might be important whether a leaf exist or the agent creates it with an > agent-supplied default value. > > Generally maintaining Andy's 'set-by' meta-variable is something I would like to avoid. Having > multiple types of defaults (YANG documented and only agent supplied but not documented) is > something I would also like to avoid if possible. > Simply declaring agent-supplied knobs illegal or out of scope does not help. > ====================================================================================== > > I think if a leaf does not have a default statement that is part of the contract/model meaning > that the leaf is NOT created/supplied with a value unless the operator really sets it. > > If the agents want to supply a default, I think it should include this fact in it's model! Any > reason not to do that? What if the 4 different sw-dev groups in the same company cannot agree on the default for their platform (happened all the time where I used to work)? The reality is that agents need to supply platform-specific defaults, and sometimes the default value needs to change over time. NETCONF needs a new verb to retrieve these settings. This is not really a YANG problem at all. If the designers can agree on a default value, they will use a default-stmt. End of problem from the YANG POV. > > If needed an an overlay module which specifices implementation-specific defaults might be a > usable idea if we manage to keep it simple. > > Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 08:19: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 744313A6829; Fri, 13 Jun 2008 08:19: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 9A1663A6829 for ; Fri, 13 Jun 2008 08:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 lhG+5y6acLvH for ; Fri, 13 Jun 2008 08:19:55 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 12A533A6825 for ; Fri, 13 Jun 2008 08:19:55 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CBC43205E0; Fri, 13 Jun 2008 17:20:25 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-f6-48529039a228 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A2AD820FDF; Fri, 13 Jun 2008 17:20:25 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:20:34 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:20:34 +0200 Message-ID: <48529038.2040807@ericsson.com> Date: Fri, 13 Jun 2008 17:20:24 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <48526D1B.8080403@ericsson.com> <48528F49.4010404@netconfcentral.com> In-Reply-To: <48528F49.4010404@netconfcentral.com> X-OriginalArrivalTime: 13 Jun 2008 15:20:34.0075 (UTC) FILETIME=[0648BEB0:01C8CD69] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello Andy, I agree with most of your mail, but I do not understand, why cant the designers specify in some YANG like format what their specific node is doing with the defaults? What do you think of Martin's overlay proposal? regards Balazs Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> I think if we allow the agent to supply a default value even when >> there is no default value in the YANG model that might confuse people. >> > > I think we need to deal with the way real routers and other NE devices > actually work. > >> The whole aim of YANG is to specify the model formally. We have the >> default statement in YANG that can be used to specify the defaults. >> Why do we want to allow (or maybe even recommend) devices not to >> specify their default values? Are there simply to many defaults? >> > > The aim of NETCONF and YANG is to facilitate network configuration APIs > that actually work, in a cost-effective manner. > > NE vendors cannot even agree on mandatory defaults within their own > company, let alone across the entire industry. Agent-supplied defaults > are a reality, and a robust CM solution should deal with them directly. > > Silent default changes across platforms and versions are also a reality. > Sometimes silent default changes do the right thing, as Juergen said, > and they are not a problem at all. > > But sometimes an operator wants to upgrade just a subset of routers > to pick up some new features or bugfixes, > and some totally unrelated feature breaks because different boxes > in the same network are using different defaults. Operators hate > to upgrade router code because of these types of surprises. > > Bottom line: The 'CLI way' of hiding agent-supplied knobs from the operator > is broken, and a real CM solution will not be possible unless all > the agent-supplied knobs can be retrieved from the agent somehow. > > > >> In some cases it might be important whether a leaf exist or the agent >> creates it with an agent-supplied default value. >> >> Generally maintaining Andy's 'set-by' meta-variable is something I >> would like to avoid. Having multiple types of defaults (YANG >> documented and only agent supplied but not documented) is something I >> would also like to avoid if possible. >> > > Simply declaring agent-supplied knobs illegal or out of scope > does not help. > > > >> ====================================================================================== >> >> >> I think if a leaf does not have a default statement that is part of >> the contract/model meaning that the leaf is NOT created/supplied with >> a value unless the operator really sets it. >> >> If the agents want to supply a default, I think it should include this >> fact in it's model! Any reason not to do that? > > What if the 4 different sw-dev groups in the same company > cannot agree on the default for their platform (happened > all the time where I used to work)? > > The reality is that agents need to supply platform-specific > defaults, and sometimes the default value needs to change > over time. NETCONF needs a new verb to retrieve these settings. > > This is not really a YANG problem at all. If the designers > can agree on a default value, they will use a default-stmt. > End of problem from the YANG POV. > > >> >> If needed an an overlay module which specifices >> implementation-specific defaults might be a usable idea if we manage >> to keep it simple. >> >> Balazs > > > Andy > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 08:20: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 7AA5B3A6829; Fri, 13 Jun 2008 08:20: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 798723A6982 for ; Fri, 13 Jun 2008 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.279, 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 4R9EWZ4B-t6h for ; Fri, 13 Jun 2008 08:20: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 2139E3A6829 for ; Fri, 13 Jun 2008 08:20:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7F0FC0018; Fri, 13 Jun 2008 17:20: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 l6hrXR-GKpdL; Fri, 13 Jun 2008 17:20:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7407C001C; Fri, 13 Jun 2008 17:20:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D4EF15CF4CC; Fri, 13 Jun 2008 17:20:42 +0200 (CEST) Date: Fri, 13 Jun 2008 17:20:42 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080613152042.GB5298@elstar.local> Mail-Followup-To: Balazs Lengyel , netmod@ietf.org, "Ersue, Mehmet (NSN - DE/Muenich)" References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <48528DCD.3080903@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48528DCD.3080903@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] #2: Rpcs and Notification inside lists 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, Jun 13, 2008 at 05:10:05PM +0200, Balazs Lengyel wrote: > In object orientation it is usual to define methods/procedures as > part of an object, a model defined RPC can be used as an > equivalent(near equivalent) of a procedure in the OO world. This has > the advantages: Balazs, it will help me if you can outline a possible solution to see how this maps to NETCONF (which is not OO and just has flat rpc/notification namespaces). Consider this example: container foo { notification failure { ... } rpc restart { ... } } list bar { notification failure { ... } rpc restart { ... } } What is the resulting XML shipped in NETCONF? /js (who still believes rpc should be operation for RFC 4741 consistency ;-) -- 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 Jun 13 08:30: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 1BE353A69D0; Fri, 13 Jun 2008 08:30: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 0CFDE3A69D0 for ; Fri, 13 Jun 2008 08:30:16 -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_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 IoHNvcNjzReb for ; Fri, 13 Jun 2008 08:30:15 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id C939D3A69D4 for ; Fri, 13 Jun 2008 08:30:12 -0700 (PDT) Received: (qmail 31304 invoked from network); 13 Jun 2008 15:30:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.156.218 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 13 Jun 2008 15:30:38 -0000 X-YMail-OSG: jT9q3lsVM1krEDCMcwuKzSI40lAnAMMqDNhkdynUljonIeZh5tQIzv.9UAuYIwGmCUdLpy_2MB0zrDttl_bb.K4A9lCM1f.F28ii2TO27Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4852929B.5020803@netconfcentral.com> Date: Fri, 13 Jun 2008 08:30:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <485285DB.9030402@netconfcentral.com> <48528D1A.8000309@ericsson.com> In-Reply-To: <48528D1A.8000309@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] #2: Rpcs and Notification inside lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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 Andy, > What specific naming conflicts do you have in mind? > What if I have in the same module: rpc foo { ... } rpc X.foo { ... } list X { rpc foo { ... }; list Y { rpc foo { ... }; } } How do I encode all these RPC method names in an element? They are all in the same namespace, and they are all named 'foo'? Do you come up with some name-mangling hack, like X.foo, X.Y.foo, etc.? Whatever scheme you use, a naming conflict could occur, since all valid XML element names are also valid YANG identifiers (a mistake IMO). The same problem exists for . IMO, it really complicates the language to mix rpc and notification constructs in with the config database definition. You may want NETCONF to be OO, but it isn't. The verbs are notifications are procedural, outside the NV-config datastore. I prefer to have a clean definition of the NV-config contents, and keep the protocol verbs separate. Our conceptual NV-datastore should be rock-solid and need very few design changes over the next 20 years. Our set of verbs isn't even stable over a 2 year span, let alone 20 years. Andy > On the general concept; > > I agree that YANG is not object oriented, but many people will use > object oriented programing languages to implement it. Also you can find > object orientation in KALUA, the XSD proposal and in Ericssons original > modeling language, so it seems quite some people would be happy to use > YANG in an object oriented manner. > > regards Balazs > > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Jun 13, 2008 at 11:52:45AM -0000, netmod wrote: >>> >>>> Add the possibility to define notifications and custom-rpc inside a >>>> list. >>>> The XML encoding of the notification/rpc should include an instance- >>>> identifier pointing to the list(entry). >>>> >>>> This would make the object oriented usage of YANG much easier. >>> >>> Please explain why this is "much easier". Are you not just replacing >>> an explict argument with an implicit one? Or do you also want to do >>> magic name mangling of the rpc name itself? And if we were to do this, >>> then why only for list elements? >>> >> >> I agree with Juergen. >> The NETCONF protocol is not object-oriented. >> The and messages are top-level elements, and the >> name of the RPC method is the element name. Allowing these constructs >> to appear at arbitrary points in the data subtree can create naming >> conflicts. >> >> The notification can always include a data node of type >> 'instance-identifier' >> to identify the list entry that caused the notification. >> >>> /js >>> >> >> Andy >> > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 08:38: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 7CA2A3A67A4; Fri, 13 Jun 2008 08:38: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 E0D3A3A6804 for ; Fri, 13 Jun 2008 08:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESA-2ThhencU for ; Fri, 13 Jun 2008 08:38:20 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 0F1DE3A67A4 for ; Fri, 13 Jun 2008 08:38:20 -0700 (PDT) Received: (qmail 12588 invoked from network); 13 Jun 2008 15:38:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.156.218 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 13 Jun 2008 15:38:45 -0000 X-YMail-OSG: 23iseyMVM1kRw.Zu7e5O1_A6u6O5wMIFIbRGBq7AI5irgY8NKjRwiq7IKp9QP.P3kIO_4gMLNjaBTdNCp4B6Sa05Jtjz7C0AWRNgpRZnXQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48529482.3030704@netconfcentral.com> Date: Fri, 13 Jun 2008 08:38:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <48526D1B.8080403@ericsson.com> <48528F49.4010404@netconfcentral.com> <48529038.2040807@ericsson.com> In-Reply-To: <48529038.2040807@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello Andy, > I agree with most of your mail, but I do not understand, why cant the > designers specify in some YANG like format what their specific node is > doing with the defaults? What do you think of Martin's overlay proposal? This is still an offline documentation solution, which has proven with SNMP to be of little to no practical use whatsoever. > regards Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 08:47: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 48CBF3A68CE; Fri, 13 Jun 2008 08:47: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 E2AC03A6982 for ; Fri, 13 Jun 2008 08:47:06 -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 HEqNlJgf+PAI for ; Fri, 13 Jun 2008 08:47:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C442F3A68CE for ; Fri, 13 Jun 2008 08:47:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C6DA421032; Fri, 13 Jun 2008 17:47:36 +0200 (CEST) X-AuditID: c1b4fb3c-ab896bb00000193b-9f-485296986105 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A805E205B2; Fri, 13 Jun 2008 17:47:36 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:47:45 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:47:45 +0200 Message-ID: <48529697.9080904@ericsson.com> Date: Fri, 13 Jun 2008 17:47:35 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <068.a8df84a445ff62ae83619bab669abb2a@tools.ietf.org> <20080613120512.GA4378@elstar.local> <48526D1B.8080403@ericsson.com> <48528F49.4010404@netconfcentral.com> <48529038.2040807@ericsson.com> <48529482.3030704@netconfcentral.com> In-Reply-To: <48529482.3030704@netconfcentral.com> X-OriginalArrivalTime: 13 Jun 2008 15:47:45.0840 (UTC) FILETIME=[D2E45300:01C8CD6C] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy, I am not saying you should not be able to fetch the stuff on-line. I am rather arguing that it should ALSO be available off-line as well, as part of YANG. The whole of YANG is off-line :-) Balazs Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello Andy, >> I agree with most of your mail, but I do not understand, why cant the >> designers specify in some YANG like format what their specific node is >> doing with the defaults? What do you think of Martin's overlay proposal? > > This is still an offline documentation solution, which has proven > with SNMP to be of little to no practical use whatsoever. > > >> regards Balazs > > Andy > > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 13:21: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 0385E3A682E; Fri, 13 Jun 2008 13:21: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 64E813A6885 for ; Fri, 13 Jun 2008 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1WtW0EtKbQ5 for ; Fri, 13 Jun 2008 13:21:10 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 3A0823A682E for ; Fri, 13 Jun 2008 13:21:10 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 0B9A01B80CC; Fri, 13 Jun 2008 22:21:42 +0200 (CEST) Date: Fri, 13 Jun 2008 22:21:55 +0200 (CEST) Message-Id: <20080613.222155.87559959.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48529482.3030704@netconfcentral.com> References: <48528F49.4010404@netconfcentral.com> <48529038.2040807@ericsson.com> <48529482.3030704@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] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Balazs Lengyel wrote: > > Hello Andy, > > I agree with most of your mail, but I do not understand, why cant the > > designers specify in some YANG like format what their specific node is > > doing with the defaults? What do you think of Martin's overlay proposal? > > This is still an offline documentation solution, which has proven > with SNMP to be of little to no practical use whatsoever. We can do better than that, since we can make the default-overlay spec available using the schema discovery procedure. There are also other reasons that AGENT-CAPABILITIES are not being used (they are complex and difficult to get right, they reveal sensitive information (for vendors) etc). I think there are two issues here. The first is that is has to be clear from the YANG document exactly where the agent is allowed to use implementation-specific defaults. I think we all agree that this has to be solved, even though it seems we disagree on the solution (e.g. should implementation-specific defaults be allowed for mandatory leafs or not). The second issue is that given that the agent can use implementation-specific defaults, should we have a standard way of making these defaults documented and available for the client? I think that we should. If soemone doesn't trust the default-spec, feel free to ignore it. Just like you will do if you don't trust the YANG-spec that the agent claims conformance to. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 13 14:33: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 420763A689E; Fri, 13 Jun 2008 14:33: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 90B2E3A690F for ; Fri, 13 Jun 2008 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.244, 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 GOOOAEvey0Sl for ; Fri, 13 Jun 2008 14:33:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 708943A689E for ; Fri, 13 Jun 2008 14:33:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7FEAC0024; Fri, 13 Jun 2008 23:34:22 +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 NnPKFLG6iGZt; Fri, 13 Jun 2008 23:34:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 088A3C0016; Fri, 13 Jun 2008 23:34:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E12995D133A; Fri, 13 Jun 2008 23:34:15 +0200 (CEST) Date: Fri, 13 Jun 2008 23:34:15 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080613213415.GB555@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <48528F49.4010404@netconfcentral.com> <48529038.2040807@ericsson.com> <48529482.3030704@netconfcentral.com> <20080613.222155.87559959.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080613.222155.87559959.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory 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, Jun 13, 2008 at 10:21:55PM +0200, Martin Bjorklund wrote: > The second issue is that given that the agent can use > implementation-specific defaults, should we have a standard way of > making these defaults documented and available for the client? > > I think that we should. If soemone doesn't trust the default-spec, > feel free to ignore it. Just like you will do if you don't trust the > YANG-spec that the agent claims conformance to. I am not against documentation; I love documentation. But I feel uncomfortable with the idea of having to "trust" documentation. If I really need to know the default values (and this usually happens when I am trying to solve a tricky problem and is not the standard situation), then I prefer to ask the instrumentation since this is the most authoritative source of information. /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 Jun 13 16:36: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 A14653A698A; Fri, 13 Jun 2008 16:36: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 ACF5E3A69C6 for ; Fri, 13 Jun 2008 16:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 58KtJjHRCQ71 for ; Fri, 13 Jun 2008 16:36:55 -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 12BDE3A698A for ; Fri, 13 Jun 2008 16:36:55 -0700 (PDT) Received: (qmail 55632 invoked from network); 13 Jun 2008 23:37:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.156.218 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 13 Jun 2008 23:37:22 -0000 X-YMail-OSG: l4u.484VM1ked93aeb1yGg69uUgDeEPtpAebJW.vGX1oS7jPbzEc3Dz9diBLYxC38N.Gzk_N3k1gFlD.5XikVY3oFoOu_SF4x3_TAlVUqQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485304B1.4060108@netconfcentral.com> Date: Fri, 13 Jun 2008 16:37:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <48528F49.4010404@netconfcentral.com> <48529038.2040807@ericsson.com> <48529482.3030704@netconfcentral.com> <20080613.222155.87559959.mbj@tail-f.com> <20080613213415.GB555@elstar.local> In-Reply-To: <20080613213415.GB555@elstar.local> Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Jun 13, 2008 at 10:21:55PM +0200, Martin Bjorklund wrote: > >> The second issue is that given that the agent can use >> implementation-specific defaults, should we have a standard way of >> making these defaults documented and available for the client? >> >> I think that we should. If soemone doesn't trust the default-spec, >> feel free to ignore it. Just like you will do if you don't trust the >> YANG-spec that the agent claims conformance to. > > I am not against documentation; I love documentation. But I feel > uncomfortable with the idea of having to "trust" documentation. If I > really need to know the default values (and this usually happens when > I am trying to solve a tricky problem and is not the standard > situation), then I prefer to ask the instrumentation since this is the > most authoritative source of information. > Diving into the technical issues (why not?), there are really 2 features being discussed here. The first is , which would be a new verb that did what is supposed to do, which is to get all the values, including usually hidden default settings. This is the best way to find out what happened, after the fact. This is the easy part. The second feature is the ability to predict the behavior and new state of the device, given its current state and some arbitrary set of config changes that an operator wants to make. This is a much harder problem, but quite relevant to NETCONF. What if you had a NETCONF API to turn on your laptop wireless card during an IETF plenary? Do you want to find out after the fact that the default setting was 'ad-hoc mode'? Sometimes you really want to know what a config change operation will do beforehand. The fatal flaw with the AGENT-CAPABILITIES approach is that there is no way for a manager to know the entire set of platform/version variants. The 'variance identity matrix' and the location of all the data is totally arbitrary. Any real solution must not require humans in the loop at all to identify, locate or apply the agent variance information. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jun 14 05:55: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 C3B4C3A6A71; Sat, 14 Jun 2008 05:55: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 469F43A6A71 for ; Sat, 14 Jun 2008 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnYSW6exzxop for ; Sat, 14 Jun 2008 05:55:12 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 2A6FF3A692A for ; Sat, 14 Jun 2008 05:55:12 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id B76001B80DC; Sat, 14 Jun 2008 14:55:44 +0200 (CEST) Date: Sat, 14 Jun 2008 14:56:01 +0200 (CEST) Message-Id: <20080614.145601.227617898.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <485304B1.4060108@netconfcentral.com> References: <20080613.222155.87559959.mbj@tail-f.com> <20080613213415.GB555@elstar.local> <485304B1.4060108@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] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Jun 13, 2008 at 10:21:55PM +0200, Martin Bjorklund wrote: > > > >> The second issue is that given that the agent can use > >> implementation-specific defaults, should we have a standard way of > >> making these defaults documented and available for the client? > >> > >> I think that we should. If soemone doesn't trust the default-spec, > >> feel free to ignore it. Just like you will do if you don't trust the > >> YANG-spec that the agent claims conformance to. > > I am not against documentation; I love documentation. But I feel > > uncomfortable with the idea of having to "trust" documentation. If I > > really need to know the default values (and this usually happens when > > I am trying to solve a tricky problem and is not the standard > > situation), then I prefer to ask the instrumentation since this is the > > most authoritative source of information. > > > > Diving into the technical issues (why not?), there are really 2 features > being discussed here. The first is , which would be a > new verb that did what is supposed to do, I prefer standardizing the current with-defaults parameter. The with-defaults parameter works with get, get-config and copy-config. It is also clear from the name what it does. Having get, get-config and get-settings might be more confusing. > The second feature is the ability to predict the behavior and > new state of the device, given its current state and some > arbitrary set of config changes that an operator wants to make. > This is a much harder problem, but quite relevant to NETCONF. > > What if you had a NETCONF API to turn on your laptop wireless card > during an IETF plenary? Do you want to find out after the fact > that the default setting was 'ad-hoc mode'? Sometimes you really > want to know what a config change operation will do beforehand. It seems you are arguing *for* having a formal way of defining and learning implementation-specific defaults. If we don't do this, but accept the fact that implementations will have their own defaults, we will end up with the situation you just described. > The fatal flaw with the AGENT-CAPABILITIES approach is that > there is no way for a manager to know the entire set of platform/version > variants. The 'variance identity matrix' and the location of > all the data is totally arbitrary. Any real solution must > not require humans in the loop at all to identify, locate > or apply the agent variance information. So the idea with an implementation-specific default-overlay spec is that the client can get it off the box and apply it to the standard yang module, in order to get the agent-specific data. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jun 14 08:51: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 E0F463A6A5A; Sat, 14 Jun 2008 08:51: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 CCC6A3A67F5 for ; Sat, 14 Jun 2008 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 Qc8aixK-QaKW for ; Sat, 14 Jun 2008 08:51: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 DC5113A6A35 for ; Sat, 14 Jun 2008 08:51:19 -0700 (PDT) Received: (qmail 48984 invoked from network); 14 Jun 2008 15:51:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.156.218 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 14 Jun 2008 15:51:53 -0000 X-YMail-OSG: FiWhtLAVM1kaK0LJOzMF9Ip66ctlweyQ5YYg8ACatRooTw7_v0DhLP7qYX2RYCPQqPfmfuJadUxNaFC5JVj73rw0rwK_VIDnv_0maiF59RDWskjZuRdSOXo2u4v1VXOIWhE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4853E917.5060804@netconfcentral.com> Date: Sat, 14 Jun 2008 08:51:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080613.222155.87559959.mbj@tail-f.com> <20080613213415.GB555@elstar.local> <485304B1.4060108@netconfcentral.com> <20080614.145601.227617898.mbj@tail-f.com> In-Reply-To: <20080614.145601.227617898.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Jun 13, 2008 at 10:21:55PM +0200, Martin Bjorklund wrote: >>> >>>> The second issue is that given that the agent can use >>>> implementation-specific defaults, should we have a standard way of >>>> making these defaults documented and available for the client? >>>> >>>> I think that we should. If soemone doesn't trust the default-spec, >>>> feel free to ignore it. Just like you will do if you don't trust the >>>> YANG-spec that the agent claims conformance to. >>> I am not against documentation; I love documentation. But I feel >>> uncomfortable with the idea of having to "trust" documentation. If I >>> really need to know the default values (and this usually happens when >>> I am trying to solve a tricky problem and is not the standard >>> situation), then I prefer to ask the instrumentation since this is the >>> most authoritative source of information. >>> >> Diving into the technical issues (why not?), there are really 2 features >> being discussed here. The first is , which would be a >> new verb that did what is supposed to do, > > I prefer standardizing the current with-defaults parameter. The > with-defaults parameter works with get, get-config and copy-config. > It is also clear from the name what it does. Having get, get-config > and get-settings might be more confusing. > >> The second feature is the ability to predict the behavior and >> new state of the device, given its current state and some >> arbitrary set of config changes that an operator wants to make. >> This is a much harder problem, but quite relevant to NETCONF. >> >> What if you had a NETCONF API to turn on your laptop wireless card >> during an IETF plenary? Do you want to find out after the fact >> that the default setting was 'ad-hoc mode'? Sometimes you really >> want to know what a config change operation will do beforehand. > > It seems you are arguing *for* having a formal way of defining and > learning implementation-specific defaults. If we don't do this, but > accept the fact that implementations will have their own defaults, we > will end up with the situation you just described. > I think that agent-supplied defaults is just one issue within the larger data model conformance problem, and agent variance from some conformance level for all aspects of the protocol should be considered. I am concerned that there are not enough people contributing in the WG to add this complex problem to the YANG 1.0 plate. >> The fatal flaw with the AGENT-CAPABILITIES approach is that >> there is no way for a manager to know the entire set of platform/version >> variants. The 'variance identity matrix' and the location of >> all the data is totally arbitrary. Any real solution must >> not require humans in the loop at all to identify, locate >> or apply the agent variance information. > > So the idea with an implementation-specific default-overlay spec is > that the client can get it off the box and apply it to the standard > yang module, in order to get the agent-specific data. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jun 14 09:18: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 E9E033A6780; Sat, 14 Jun 2008 09:18: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 D38943A6856 for ; Sat, 14 Jun 2008 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 LRrzhkV2+1Oy for ; Sat, 14 Jun 2008 09:18:33 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 091223A6780 for ; Sat, 14 Jun 2008 09:18:32 -0700 (PDT) Received: (qmail 66711 invoked from network); 14 Jun 2008 16:19:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.156.218 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 14 Jun 2008 16:19:02 -0000 X-YMail-OSG: vLiJioAVM1lzBLCEW7X_2TtRbJsAMrD9lqdf7Wc06iNUESu8eiYddralF3Tx41wP20tsQVco2CiH98Gqd9_vym3zPiKBEzdoEWj0eV9ILR4ByORukRtW.JY1W0ywf.AkiT4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4853EF74.6050508@netconfcentral.com> Date: Sat, 14 Jun 2008 09:19:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080613.222155.87559959.mbj@tail-f.com> <20080613213415.GB555@elstar.local> <485304B1.4060108@netconfcentral.com> <20080614.145601.227617898.mbj@tail-f.com> In-Reply-To: <20080614.145601.227617898.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org >... > I prefer standardizing the current with-defaults parameter. The > with-defaults parameter works with get, get-config and copy-config. > It is also clear from the name what it does. Having get, get-config > and get-settings might be more confusing. > I tend to agree with you, but either way has pros and cons. It could be done with a capability either way, as well, so managers will know if the with-defaults attribute will be accepted (or if the verb will be accepted). >> The second feature is the ability to predict the behavior and >> new state of the device, given its current state and some >> arbitrary set of config changes that an operator wants to make. >> This is a much harder problem, but quite relevant to NETCONF. >> > So the idea with an implementation-specific default-overlay spec is > that the client can get it off the box and apply it to the standard > yang module, in order to get the agent-specific data. > It seems like a good idea to me. Have the agent return URLs or the actual YANG files that precisely describe the data models currently supported on that agent. Actually, the term agent-supplied defaults is much better marketing than agent conformance variance. When I proposed this same sort of thing to the SMING WG (10 years ago?) the vendors hated it. They said "there is no way we want to let our customers know all the little ways our products do not conform to the standard data models." This feature cannot be perceived as a way to advertise product defects. ;-) > > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 16 01:25:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B6C3A67FC; Mon, 16 Jun 2008 01:25:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2555B3A6A6F for ; Mon, 16 Jun 2008 01:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQIBhsB1ZhaF for ; Mon, 16 Jun 2008 01:25:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 46BB33A67FC for ; Mon, 16 Jun 2008 01:25:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C9506548024; Mon, 16 Jun 2008 10:26:23 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-ac-485623af599c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7F931520001; Mon, 16 Jun 2008 10:26:23 +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, 16 Jun 2008 10:25:22 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:25:22 +0200 Message-ID: <48562363.8090203@ericsson.com> Date: Mon, 16 Jun 2008 10:25:07 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20080613.222155.87559959.mbj@tail-f.com> <20080613213415.GB555@elstar.local> <485304B1.4060108@netconfcentral.com> <20080614.145601.227617898.mbj@tail-f.com> In-Reply-To: <20080614.145601.227617898.mbj@tail-f.com> X-OriginalArrivalTime: 16 Jun 2008 08:25:22.0068 (UTC) FILETIME=[84CF6540:01C8CF8A] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] default and mandatory X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org +1 Balazs Martin Bjorklund wrote: > I prefer standardizing the current with-defaults parameter. The > with-defaults parameter works with get, get-config and copy-config. > It is also clear from the name what it does. Having get, get-config > and get-settings might be more confusing. > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 16 02: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 C59443A683B; Mon, 16 Jun 2008 02: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 975173A683B for ; Mon, 16 Jun 2008 02:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW+erOkC29R1 for ; Mon, 16 Jun 2008 02:30:40 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id BE26C3A6A57 for ; Mon, 16 Jun 2008 02:30:40 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id B076B1B80C9; Mon, 16 Jun 2008 11:31:20 +0200 (CEST) Date: Mon, 16 Jun 2008 11:31:22 +0200 (CEST) Message-Id: <20080616.113122.210899146.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de 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] comments on draft-schoenw-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: , 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 a comment on the ip prefix types. The text says: The IPv4 address represented in dotted quad notation should have all bits that do not belong to the prefix set to zero. Should a server treat e.g. 10.0.0.1/8 and 10.0.0.2/8 as equal values? (For example if a list entry exists with key 10.0.0.1/8, should a request to create 10.0.0.2/8 fail?) Should a server accept 10.0.0.1/8 as an input value, but send back 10.0.0.0/8? Is a server allowed to accept 10.0.0.1/8 as an input value, but send back 10.0.0.0/8? Would it be better to s/should/MUST/ in the description above? A comment on the ipv4 address, which contains an optional zone index. Do we need to specify the expected behavior when a server does not support zone index for a particular object? RFC4001 contains some discussion about the zone index; can we refer to that rfc in this document? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 16 06:45: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 342AC3A6B05; Mon, 16 Jun 2008 06:45: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 62A753A67A2 for ; Mon, 16 Jun 2008 06:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.268, 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 8Voq9Vkb8gM4 for ; Mon, 16 Jun 2008 06:45:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47A933A6B01 for ; Mon, 16 Jun 2008 06:45:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A242C0043; Mon, 16 Jun 2008 15:46:21 +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 q0c8ChdFdIZA; Mon, 16 Jun 2008 15:46:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0E7FC0038; Mon, 16 Jun 2008 15:46:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D2DD85D2AF1; Mon, 16 Jun 2008 15:46:14 +0200 (CEST) Date: Mon, 16 Jun 2008 15:46:14 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080616134614.GA3608@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20080616.113122.210899146.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080616.113122.210899146.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-schoenw-netmod-yang-types-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Jun 16, 2008 at 11:31:22AM +0200, Martin Bjorklund wrote: > I have a comment on the ip prefix types. > > The text says: > > The IPv4 address represented in dotted quad notation should have > all bits that do not belong to the prefix set to zero. > > Should a server treat e.g. 10.0.0.1/8 and 10.0.0.2/8 as equal values? > (For example if a list entry exists with key 10.0.0.1/8, should a > request to create 10.0.0.2/8 fail?) > > Should a server accept 10.0.0.1/8 as an input value, but send back > 10.0.0.0/8? > > Is a server allowed to accept 10.0.0.1/8 as an input value, but send > back 10.0.0.0/8? > > Would it be better to s/should/MUST/ in the description above? Yes, MUST might be a better choice to avoid this sort of problems. > A comment on the ipv4 address, which contains an optional zone index. > Do we need to specify the expected behavior when a server does not > support zone index for a particular object? This might depend on the particular circumstances of the usage of this object. Do you have a concrete proposal? > RFC4001 contains some discussion about the zone index; can we refer > to that rfc in this document? I like to avoid a dependency on RFC 4001. Which discussion do you mean? Would it be sufficient to add the following text to the description clauses of ipv4-address and ipv6-address? The zone index is used to disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index number or the name of an interface. If the zone index is not present, the default zone of the device will be used. /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 Jun 20 02:14: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 4C0C73A69E5; Fri, 20 Jun 2008 02:14: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 D73753A69E5 for ; Fri, 20 Jun 2008 02:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgyEmuOQcgB8 for ; Fri, 20 Jun 2008 02:14:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1850F3A69E6 for ; Fri, 20 Jun 2008 02:14:24 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CA3D21443 for ; Fri, 20 Jun 2008 11:14:06 +0200 (CEST) X-AuditID: c1b4fb3e-aa991bb000004ec0-94-485b74de6fe9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 66C4A2132F for ; Fri, 20 Jun 2008 11:14:06 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 11:14:25 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 11:14:25 +0200 Message-ID: <485B74DC.3050703@ericsson.com> Date: Fri, 20 Jun 2008 11:14:04 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org X-OriginalArrivalTime: 20 Jun 2008 09:14:25.0124 (UTC) FILETIME=[08A91A40:01C8D2B6] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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, Why is it not allowed to augment a grouping? We just came up against a very clear use case where that would be needed. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 20 07:18: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 4EC953A694B; Fri, 20 Jun 2008 07:18: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 CAB803A698E for ; Fri, 20 Jun 2008 07:18:54 -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 yDQWUUle6h8s for ; Fri, 20 Jun 2008 07:18:54 -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 23E453A694B for ; Fri, 20 Jun 2008 07:18:54 -0700 (PDT) Received: (qmail 26638 invoked from network); 20 Jun 2008 14:18:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.91 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 20 Jun 2008 14:18:53 -0000 X-YMail-OSG: e8hHZFYVM1ktXPnIF.DVlZ2NISjB3yrFW4miZwpKmuiruh3ZcQoGJb66h23azMcW25C0jXxlVPgLQc3Evf90WHApNdAfW.AiYqntQiNPXPnnUi_EGYZ7CTHqsj7mtctS8QM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485BBC4B.9020701@netconfcentral.com> Date: Fri, 20 Jun 2008 07:18:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <485B74DC.3050703@ericsson.com> In-Reply-To: <485B74DC.3050703@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > Why is it not allowed to augment a grouping? We just came up against a > very clear use case where that would be needed. > I reason not to do it is due to the ripple effect within all the uses-stmts. One nice feature with MIBs is that I can extract a MIB module from an RFC 2 or 10 or 15 years old and I can compile it to get the same results as when the RFC was published. If you extend a grouping and it is used already in a published RFC, then when I compile it 10 years later, and the grouping has changed since the RFC was published, I end up with a different conceptual module than the one in the RFC. That is bad for interoperability. The solution -- a separate version ID for every import or construct in the YANG file -- is way worse than the problem. The current solution in YANG requires a new name: grouping foo2 { uses foo; leaf newleaf { ... } } IMO, stability and interoperability are more important features to preserve. > Balazs Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 00:16: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 223023A686A; Mon, 23 Jun 2008 00:16: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 C98B53A6816 for ; Mon, 23 Jun 2008 00:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qb-8rahcGi2 for ; Mon, 23 Jun 2008 00:16:16 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id C4A363A68C7 for ; Mon, 23 Jun 2008 00:16: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 ESMTP id 30F451B80C5; Mon, 23 Jun 2008 09:16:11 +0200 (CEST) Date: Mon, 23 Jun 2008 09:16:18 +0200 (CEST) Message-Id: <20080623.091618.69953144.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <485BBC4B.9020701@netconfcentral.com> References: <485B74DC.3050703@ericsson.com> <485BBC4B.9020701@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > Balazs Lengyel wrote: > > Hello, > > Why is it not allowed to augment a grouping? We just came up against a very clear use case where that would be needed. > > > > I reason not to do it is due to the ripple effect > within all the uses-stmts. > > One nice feature with MIBs is that I can extract a MIB module > from an RFC 2 or 10 or 15 years old and I can compile it > to get the same results as when the RFC was published. > > If you extend a grouping and it is used already in a published > RFC, then when I compile it 10 years later, and the grouping > has changed since the RFC was published, I end up with > a different conceptual module than the one in the RFC. You get exactly the same result with the current YANG mechanisms. If the original RFC is augmented 10 years later and you recompile it with the new augmenting module, you get a different result than w/o the augmenting module. This is a feature. For a given set of modules that uses a grouping, you can get exactly the same effect as you would get if you were allowed to augment a grouping, by hunting down all the uses of the grouping, and augment them directly. For example: Given: module a { grouping foo { leaf bar; } container x { uses foo; } container y { uses foo; } } Instead of: augment /a:foo { // illegal leaf baz; } You would do: augment /a:x { leaf baz; } augment /a:y { leaf baz; } > The solution -- a separate version ID for every import or > construct in the YANG file -- is way worse than the problem. > > The current solution in YANG requires a new name: > > grouping foo2 { > uses foo; > > leaf newleaf { ... } > } I think this is a different issue - this is the upgrade rules for a grouping. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 00:23: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 5EDBC3A686A; Mon, 23 Jun 2008 00:23: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 A8D153A68C7 for ; Mon, 23 Jun 2008 00:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 vjsHzMEX7mL9 for ; Mon, 23 Jun 2008 00:23: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 10EF63A686A for ; Mon, 23 Jun 2008 00:23:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 582E8C000A; Mon, 23 Jun 2008 09:23:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MsNYPFmKWbXx; Mon, 23 Jun 2008 09:23: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 79838C0003; Mon, 23 Jun 2008 09:23:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29DDB5D756F; Mon, 23 Jun 2008 09:23:20 +0200 (CEST) Date: Mon, 23 Jun 2008 09:23:20 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080623072320.GA11366@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <485B74DC.3050703@ericsson.com> <485BBC4B.9020701@netconfcentral.com> <20080623.091618.69953144.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080623.091618.69953144.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping 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, Jun 23, 2008 at 09:16:18AM +0200, Martin Bjorklund wrote: > For a given set of modules that uses a grouping, you can get exactly > the same effect as you would get if you were allowed to augment a > grouping, by hunting down all the uses of the grouping, and augment > them directly. For example: > > Given: > > module a { > grouping foo { > leaf bar; > } > > container x { > uses foo; > } > > container y { > uses foo; > } > > } > > Instead of: > > augment /a:foo { // illegal > leaf baz; > } > > You would do: > > augment /a:x { > leaf baz; > } > > augment /a:y { > leaf baz; > } The question is what "uses foo" means, that is when augments take effect. In your example, I would expect that "uses foo" in module a always means the same thing unless the augment /a:foo is in the very same module. If the augment /a:foo is in a different module b, then I would say that this can't affect module a. And if you agree with that (not sure), then the question is how you actually refer to this augment /a:foo if you want to use the augmented version of foo. So probably grouping b:goo { uses foo; leaf baz; } is good enough? /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 Jun 23 01: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 55F223A692D; Mon, 23 Jun 2008 01: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 A87CA3A6933 for ; Mon, 23 Jun 2008 01:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdCSW7Y4RIYf for ; Mon, 23 Jun 2008 01:07:44 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D0A043A692D for ; Mon, 23 Jun 2008 01:07:43 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 1467D1B80C5; Mon, 23 Jun 2008 10:07:43 +0200 (CEST) Date: Mon, 23 Jun 2008 10:07:50 +0200 (CEST) Message-Id: <20080623.100750.120709978.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080623072320.GA11366@elstar.local> References: <485BBC4B.9020701@netconfcentral.com> <20080623.091618.69953144.mbj@tail-f.com> <20080623072320.GA11366@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Jun 23, 2008 at 09:16:18AM +0200, Martin Bjorklund wrote: > > > For a given set of modules that uses a grouping, you can get exactly > > the same effect as you would get if you were allowed to augment a > > grouping, by hunting down all the uses of the grouping, and augment > > them directly. For example: > > > > Given: > > > > module a { > > grouping foo { > > leaf bar; > > } > > > > container x { > > uses foo; > > } > > > > container y { > > uses foo; > > } > > > > } > > > > Instead of: > > > > augment /a:foo { // illegal > > leaf baz; > > } > > > > You would do: > > > > augment /a:x { > > leaf baz; > > } > > > > augment /a:y { > > leaf baz; > > } > > The question is what "uses foo" means, that is when augments take > effect. In your example, I would expect that "uses foo" in module a > always means the same thing unless the augment /a:foo is in the very > same module. If the augment /a:foo is in a different module b, then I > would say that this can't affect module a. And if you agree with that > (not sure) No. augment (as it is used currently) is typically external to the module. So for example: container x { leaf y; } always means the same thing in my local module, but 'x' can later be augmented from some other module. Same thing when augmenting a grouping: container x { uses foo; } > , then the question is how you actually refer to this > augment /a:foo if you want to use the augmented version of foo. So > probably You never refer to the augmented grouping. The whole point with augment is that you should not have to update the original definition. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 01:23: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 3F8BF3A6960; Mon, 23 Jun 2008 01:23: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 C21263A6960 for ; Mon, 23 Jun 2008 01:23:28 -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.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi6cmGoQrj1g for ; Mon, 23 Jun 2008 01:23:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 812483A6933 for ; Mon, 23 Jun 2008 01:23:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DB78C0044; Mon, 23 Jun 2008 10:23:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LogND4z+c5jF; Mon, 23 Jun 2008 10:23: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 5E9D9C0038; Mon, 23 Jun 2008 10:23:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 21E155D7E97; Mon, 23 Jun 2008 10:23:20 +0200 (CEST) Date: Mon, 23 Jun 2008 10:23:20 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080623082320.GA11698@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <485BBC4B.9020701@netconfcentral.com> <20080623.091618.69953144.mbj@tail-f.com> <20080623072320.GA11366@elstar.local> <20080623.100750.120709978.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080623.100750.120709978.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping 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, Jun 23, 2008 at 10:07:50AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jun 23, 2008 at 09:16:18AM +0200, Martin Bjorklund wrote: > > > > > For a given set of modules that uses a grouping, you can get exactly > > > the same effect as you would get if you were allowed to augment a > > > grouping, by hunting down all the uses of the grouping, and augment > > > them directly. For example: > > > > > > Given: > > > > > > module a { > > > grouping foo { > > > leaf bar; > > > } > > > > > > container x { > > > uses foo; > > > } > > > > > > container y { > > > uses foo; > > > } > > > > > > } > > > > > > Instead of: > > > > > > augment /a:foo { // illegal > > > leaf baz; > > > } > > > > > > You would do: > > > > > > augment /a:x { > > > leaf baz; > > > } > > > > > > augment /a:y { > > > leaf baz; > > > } > > > > The question is what "uses foo" means, that is when augments take > > effect. In your example, I would expect that "uses foo" in module a > > always means the same thing unless the augment /a:foo is in the very > > same module. If the augment /a:foo is in a different module b, then I > > would say that this can't affect module a. And if you agree with that > > (not sure) > > No. augment (as it is used currently) is typically external to the > module. So for example: > > container x { > leaf y; > } > > always means the same thing in my local module, but 'x' can later be > augmented from some other module. Same thing when augmenting a > grouping: > > container x { > uses foo; > } > > > , then the question is how you actually refer to this > > augment /a:foo if you want to use the augmented version of foo. So > > probably > > You never refer to the augmented grouping. The whole point with > augment is that you should not have to update the original > definition. I understand all that but since groupings are reusable constructs, they are pretty different from containers. An augment of a container actually does not change the definition of the container; it just adds something to be hosted by the augmented container. If I choose so, I can ignore the augmentation. /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 Jun 23 01:29: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 A9DA33A6816; Mon, 23 Jun 2008 01:29: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 05EEF3A6917 for ; Mon, 23 Jun 2008 01:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7b6XkETiHao for ; Mon, 23 Jun 2008 01:29:41 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 315D53A6943 for ; Mon, 23 Jun 2008 01:29: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 ESMTP id 37D651B80C5; Mon, 23 Jun 2008 10:29:40 +0200 (CEST) Date: Mon, 23 Jun 2008 10:29:47 +0200 (CEST) Message-Id: <20080623.102947.71614638.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080616134614.GA3608@elstar.local> References: <20080616.113122.210899146.mbj@tail-f.com> <20080616134614.GA3608@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] comments on draft-schoenw-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Jun 16, 2008 at 11:31:22AM +0200, Martin Bjorklund wrote: > > A comment on the ipv4 address, which contains an optional zone index. > > Do we need to specify the expected behavior when a server does not > > support zone index for a particular object? > > This might depend on the particular circumstances of the usage of this > object. Do you have a concrete proposal? Maybe say that if the object does not support zones, the error-tag 'invalid-value' should be used. (or maybe 'bad-element'; it's not clear to me when 'bad-element'/'bad-attribute' vs. 'invalid-value' should be used). Can you elaborate on the particular circumstances that could affect the error message? > > RFC4001 contains some discussion about the zone index; can we refer > > to that rfc in this document? > > I like to avoid a dependency on RFC 4001. Which discussion do you > mean? Would it be sufficient to add the following text to the > description clauses of ipv4-address and ipv6-address? > > The zone index is used to disambiguate identical address values. > For link-local addresses, the zone index will typically be the > interface index number or the name of an interface. If the zone > index is not present, the default zone of the device will be used. Adding this text would help. What about the special zone index '0' (which in 4001 refers to the default zone)? For the ipv6 type, should we add a reference to rfc4007? In rfc4001, you had: The size of the zone index has been chosen so that it is consistent with (i) the numerical zone index, defined in [RFC4007], and (ii) the sin6_scope_id field of the sockaddr_in6 structure, defined in RFC 2553 [RFC2553]. Why do you also allow interface name now? Can the server decides if interface name or index is accepted? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 01:35: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 9C38A3A6816; Mon, 23 Jun 2008 01:35: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 47BC33A6927 for ; Mon, 23 Jun 2008 01:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWjAunloIoCz for ; Mon, 23 Jun 2008 01:35:55 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 7A88D3A6816 for ; Mon, 23 Jun 2008 01:35: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 ESMTP id 0F83A1B80C5; Mon, 23 Jun 2008 10:35:55 +0200 (CEST) Date: Mon, 23 Jun 2008 10:36:02 +0200 (CEST) Message-Id: <20080623.103602.167174096.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080623082320.GA11698@elstar.local> References: <20080623072320.GA11366@elstar.local> <20080623.100750.120709978.mbj@tail-f.com> <20080623082320.GA11698@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: [...] > I understand all that but since groupings are reusable constructs, > they are pretty different from containers. An augment of a container > actually does not change the definition of the container; it just adds > something to be hosted by the augmented container. If I choose so, I > can ignore the augmentation. The same thing would apply to augment of a grouping. If grouping 'foo' defined in module 'a' is augmented by module 'b', and a server implements 'a', but not 'b', then 'foo' (on that server) will not add the augmented objects from 'b'. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 06:35: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 8F8433A6996; Mon, 23 Jun 2008 06:35: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 925153A699C for ; Mon, 23 Jun 2008 06:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 z7Z6MURGeDiT for ; Mon, 23 Jun 2008 06:35:39 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id C85A53A6996 for ; Mon, 23 Jun 2008 06:35:39 -0700 (PDT) Received: (qmail 92957 invoked from network); 23 Jun 2008 13:35:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 13:35:34 -0000 X-YMail-OSG: XZCRB1gVM1mT.Miw2eGsWMdrryhxSuFc.Sjuue2eIbi_7R8DXi_blJYtmkDFkCkCleGceqrK0Cj9YiXrn9n9R1Ve8ntS81gAxueCzr0SV.o4b_FM298WL3UR9cosTtMMayc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485FA6A4.4030200@netconfcentral.com> Date: Mon, 23 Jun 2008 06:35:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080623072320.GA11366@elstar.local> <20080623.100750.120709978.mbj@tail-f.com> <20080623082320.GA11698@elstar.local> <20080623.103602.167174096.mbj@tail-f.com> In-Reply-To: <20080623.103602.167174096.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > [...] > >> I understand all that but since groupings are reusable constructs, >> they are pretty different from containers. An augment of a container >> actually does not change the definition of the container; it just adds >> something to be hosted by the augmented container. If I choose so, I >> can ignore the augmentation. > > The same thing would apply to augment of a grouping. If grouping > 'foo' defined in module 'a' is augmented by module 'b', and a server > implements 'a', but not 'b', then 'foo' (on that server) will not add > the augmented objects from 'b'. > We almost had it figured out in Philly. (Now we are back to square one though :-( The real problem with groupings is understanding the contents, and therefore the conformance requirements. Consider 4 modules: m1: contains grouping G = { leaf1, leaf2 } m2: uses G m3: augments grouping G: G' = G + { leaf3 } m4: uses G' There are a couple big problems. 1) locking the 'uses-stmt' - When m1 is published it contains 2 leafs. - When m2 is published, m1:G contains 2 leafs and the semantics of m2 depends on this fact. - Later m1 is republished and 'list1' is added to the grouping Q: How does a developer compiling m2 (at any time after m2 is published) import the correct version of m1, such that G has 2 child nodes, not 3? - If m2 is ever republished, is it required to use the new m1:G then, or can it still use the old version of m1:G? * Unless this problem is solved, I do not see how a grouping can ever be modified (let alone augmented), after it is published in an RFC. 2) collecting the augments - When m3 augments G with 'leaf3', this is being added to the XML namespace for m1. There is no naming collision protection like normal augments. There is no way to tell in NETCONF PDUs where 'leaf3' is defined. - m2 and m4 will import m1 to access G, but how does m4 know to import m3? - What if there are multiple uses of G in m4, and not all of them should be updated (i.e., m4 wants to use G and G') - What if the constructs in m2 or m4 which use G are in turn used in other constructs or modules? (e.g., uses within a grouping) How does the implementer distinguish G from G' then? * Augmenting a grouping is quite complicated. IMO we should stick to augmenting accessible objects only for now. Andy > > /martin > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 06:49: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 4557E3A67A6; Mon, 23 Jun 2008 06:49: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 AEF763A67A6 for ; Mon, 23 Jun 2008 06:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPQ6fxZFJcEm for ; Mon, 23 Jun 2008 06:49:29 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id C56AA3A67DA for ; Mon, 23 Jun 2008 06:49:29 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 5A51B1B80C5; Mon, 23 Jun 2008 15:49:29 +0200 (CEST) Date: Mon, 23 Jun 2008 15:49:36 +0200 (CEST) Message-Id: <20080623.154936.199811755.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <485FA6A4.4030200@netconfcentral.com> References: <20080623082320.GA11698@elstar.local> <20080623.103602.167174096.mbj@tail-f.com> <485FA6A4.4030200@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 real problem with groupings is understanding the > contents, and therefore the conformance requirements. > > Consider 4 modules: > > m1: contains grouping G = { leaf1, leaf2 } > m2: uses G > m3: augments grouping G: G' = G + { leaf3 } > m4: uses G' No, m4 uses G. And m3 just augments G, it does not create a G'. > There are a couple big problems. > 1) locking the 'uses-stmt' > > - When m1 is published it contains 2 leafs. > - When m2 is published, m1:G contains 2 leafs and the semantics > of m2 depends on this fact. > - Later m1 is republished and 'list1' is added to the grouping > > Q: How does a developer compiling m2 (at any time after m2 > is published) import the correct version > of m1, such that G has 2 child nodes, not 3? Just like with normal 'augment', the developer knows if the augmenting module 'm3' is supported, and thus if just the two leaves from m1 should be implemented, or if the augmented leafs should be implemented as well. > - If m2 is ever republished, is it required to use the new > m1:G then, or can it still use the old version of m1:G? > > * Unless this problem is solved, I do not see how a grouping > can ever be modified (let alone augmented), after it is > published in an RFC. I think you're mixing two different concepts here; versioning vs. augmentations. I agree with you on the versioning issue though. > 2) collecting the augments > - When m3 augments G with 'leaf3', this is being added to the > XML namespace for m1. No, just like w/ normal augment, 'leaf3' would be defined in m3's namespace. > There is no naming collision protection > like normal augments. There is no way to tell in NETCONF PDUs where > 'leaf3' is defined. See above. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 07:38: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 EC6343A697E; Mon, 23 Jun 2008 07: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 87AA13A69E3 for ; Mon, 23 Jun 2008 07:38:02 -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 8h3Rc+LcWrQH for ; Mon, 23 Jun 2008 07:38:01 -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 A58C83A697E for ; Mon, 23 Jun 2008 07:38:01 -0700 (PDT) Received: (qmail 41249 invoked from network); 23 Jun 2008 14:38:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 14:38:00 -0000 X-YMail-OSG: SD5_giIVM1kdGV3vkYepAhPt9VewqXbxy39bERMIQudP0I5YEOkglBm9Owi4Ov.Tb4MJCU2vnb_5BmRq2hQK4Zei9Ec0SHg5l4mowntwph_phGrWr2tCvYw6OaPgS3xgtLM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485FB546.1060100@netconfcentral.com> Date: Mon, 23 Jun 2008 07:37:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080623082320.GA11698@elstar.local> <20080623.103602.167174096.mbj@tail-f.com> <485FA6A4.4030200@netconfcentral.com> <20080623.154936.199811755.mbj@tail-f.com> In-Reply-To: <20080623.154936.199811755.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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 real problem with groupings is understanding the >> contents, and therefore the conformance requirements. >> >> Consider 4 modules: >> >> m1: contains grouping G = { leaf1, leaf2 } >> m2: uses G >> m3: augments grouping G: G' = G + { leaf3 } >> m4: uses G' > > No, m4 uses G. And m3 just augments G, it does not create a G'. > So you are saying that G' can only be local to m3 because the augment of G can only be in m3 and only used in m3? In that case, I would much rather punt this whole idea and force the DM writer to use the constructs already available which can produce the same results. Combining lots of grouping augments could be a DM reader's nightmare. I prefer to see it spelled out inline with separate uses-stmts, instead of hidden in augment-stmts, scattered throughout the module. >> There are a couple big problems. >> 1) locking the 'uses-stmt' >> >> - When m1 is published it contains 2 leafs. >> - When m2 is published, m1:G contains 2 leafs and the semantics >> of m2 depends on this fact. >> - Later m1 is republished and 'list1' is added to the grouping >> >> Q: How does a developer compiling m2 (at any time after m2 >> is published) import the correct version >> of m1, such that G has 2 child nodes, not 3? > > Just like with normal 'augment', the developer knows if the augmenting > module 'm3' is supported, and thus if just the two leaves from m1 should be > implemented, or if the augmented leafs should be implemented as well. > >> - If m2 is ever republished, is it required to use the new >> m1:G then, or can it still use the old version of m1:G? >> >> * Unless this problem is solved, I do not see how a grouping >> can ever be modified (let alone augmented), after it is >> published in an RFC. > > I think you're mixing two different concepts here; versioning > vs. augmentations. I agree with you on the versioning issue though. > Yes I am mixing 2 similar problems. Groupings are much different than anything the IETF has ever used before in a network management data modeling language. When m2 is published, the exact definitions from m1 it uses needs to be specified and locked -- regardless of what happens to m1 in the future. This property of MIBs is not just a feature, it is a show-stopper MUST HAVE for standards. A standard cannot have any 'place-holders' replaced at compile-time, like a #define in C. SMIv2 does not allow TEXTUAL-CONVENTIONs to ever be changed in non-backward-compatible ways. The OBJECT-TYPE and NOTIFICATION-TYPE macros are completely enumerated for a given conformance level, for a given version of the module. Just because YANG might have more complex objects to enumerate, does not mean this problem should be ignored. It is not as if there is some shortage of unique names for groupings. If you need a grouping G' that extends G in a module, then just create a new grouping G2, and start using that instead of G for new data structures. >> 2) collecting the augments >> - When m3 augments G with 'leaf3', this is being added to the >> XML namespace for m1. > > No, just like w/ normal augment, 'leaf3' would be defined in m3's namespace. This really changes how groupings work. All the grouping objects are created in the namespace of the uses-stmt. IMO, groupings are already problematic enough without adding the complexity of altering the uses-stmt expansion of groupings from external modules. You can already do this augmenting locally in a controlled and tractable manner. I thought it was verboten to define multiple ways of doing the same thing in a data modeling language. (I like that rule -- it means we should be tossing stuff out of YANG inside of piling on more stuff ;-) > >> There is no naming collision protection >> like normal augments. There is no way to tell in NETCONF PDUs where >> 'leaf3' is defined. > > See above. > > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 08:28: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 9E4193A6979; Mon, 23 Jun 2008 08:28: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 E2B253A698A for ; Mon, 23 Jun 2008 08:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2yjssBWNVEA for ; Mon, 23 Jun 2008 08:28:23 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 34B0A3A67DA for ; Mon, 23 Jun 2008 08:28:21 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 08:28:16 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 08:27:49 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 08:27:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 08:27:48 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5NFRlx79180; Mon, 23 Jun 2008 08:27:47 -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 m5NFPHZJ061502; Mon, 23 Jun 2008 15:25:17 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806231525.m5NFPHZJ061502@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080623.154936.199811755.mbj@tail-f.com> Date: Mon, 23 Jun 2008 11:25:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 15:27:48.0282 (UTC) FILETIME=[B138F9A0:01C8D545] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >I think you're mixing two different concepts here; versioning >vs. augmentations. I agree with you on the versioning issue though. The problem is that without versioning, augmentation of groupings is considered dangerous, since ordinary uses can suffer drive-by augmentation. But not having augmentation of groupings reduces the utility of both augmentation and grouping, and forces the use of hack like grouping names with version number in them. Which IMHO drives us back to the need for versioned imports. If I can control which revision of a module I'm importing, then my dependency is explicit and changes to the module don't affect me. This gives the stability and certainty that is needed for modules to be both fixed and evolving, as they are in the real world. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 08:48: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 4E8B33A67CF; Mon, 23 Jun 2008 08:48: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 4C1013A69BB for ; Mon, 23 Jun 2008 08:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, 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 rv2U9W2YjmI7 for ; Mon, 23 Jun 2008 08:48:24 -0700 (PDT) Received: from psmtp.com (exprod7ob113.obsmtp.com [64.18.2.178]) by core3.amsl.com (Postfix) with ESMTP id 1BB9A3A67CF for ; Mon, 23 Jun 2008 08:48:23 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 08:47:44 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, 23 Jun 2008 08:47:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 08:47:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 08:42: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 m5NFg0x83578 for ; Mon, 23 Jun 2008 08:42:00 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5NFdTPk061607 for ; Mon, 23 Jun 2008 15:39:30 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806231539.m5NFdTPk061607@idle.juniper.net> To: netmod@ietf.org Date: Mon, 23 Jun 2008 11:39:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 15:42:00.0713 (UTC) FILETIME=[AD4F9F90:01C8D547] Subject: [netmod] augment a leaf? X-BeenThere: netmod@ietf.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 MODsters, So should I be able to augment a leaf? Currently, I don't think this is possible, but there are a number of circumstances where it would be useful, such as: - allow access to i18n/translation strings - allow gui apps to augment with custom display info - allow vendors to attach info needed for CLI display Something like: augment ietf-bgp:group/ietf-bgp:peer/ietf-bgp:as { junos:populate-with protocols/bgp/group/peer/as-number; junos:i18n I18N_BGP_AS; junos:gui-hint display-as-dotted-number; } (where ietf-bgp is the prefix for the IETF's bgp standard that defined a leaf called "as", that I want to augment with vendor-specific information.) Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 09:14: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 D010F3A69D4; Mon, 23 Jun 2008 09:14: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 DCE363A6A12 for ; Mon, 23 Jun 2008 09:14:52 -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 miP0JrZ3XWbr for ; Mon, 23 Jun 2008 09:14: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 210843A69D4 for ; Mon, 23 Jun 2008 09:14:52 -0700 (PDT) Received: (qmail 44233 invoked from network); 23 Jun 2008 16:14:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 16:14:50 -0000 X-YMail-OSG: 2TKPqLcVM1kSarUaH1_F2WqOISF2zhUgSytqrRtTcQZAOcgXbFJpvy8sYT1AJLFAZ5ygRHQBBlKs3w9c.kTmlhDBqeCftfD0cLVig8q8E1Xb42XxNBeiIKWeBUCJWusbH54- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485FCBF8.7030302@netconfcentral.com> Date: Mon, 23 Jun 2008 09:14:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806231525.m5NFPHZJ061502@idle.juniper.net> In-Reply-To: <200806231525.m5NFPHZJ061502@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: > Martin Bjorklund writes: >> I think you're mixing two different concepts here; versioning >> vs. augmentations. I agree with you on the versioning issue though. > > The problem is that without versioning, augmentation of groupings > is considered dangerous, since ordinary uses can suffer drive-by > augmentation. But not having augmentation of groupings reduces the > utility of both augmentation and grouping, and forces the use of > hack like grouping names with version number in them. > > Which IMHO drives us back to the need for versioned imports. If I > can control which revision of a module I'm importing, then my > dependency is explicit and changes to the module don't affect me. > This gives the stability and certainty that is needed for modules > to be both fixed and evolving, as they are in the real world. > Putting the versioning info in the name is not a hack. It handles all of the real-world problems with mixing old and new implementations just fine. I think multiple concurrent versions of the same module within the same system or the same agent raises complexity concerns. I do not think the IETF has enough experience with the 'grouping/uses' method of NM definition reuse to justify this level of complexity. IMO, the best approach wrt/ IETF standards is to somehow spell out (in machine-readable form) exactly what is contained in a particular module version. This info cannot be lost as the module changes over time. SMIv2 uses a separate conformance section for this purpose, which should be adapted for YANG. In my example, if m2 had a conformance section that spelled out the leafs, like: module m2 { namespace "..."; prefix m2; import m1 { prefix m1; } revision 2008-06-23 { description "Using new version of grouping G from m1"; } revision 2008-06-01 { description "Initial version"; } container foo { uses G; } conformance 2008-06-23 { object /foo/leaf1; object /foo/leaf2 { min-access read-only; } object /foo/list1/key; object /foo/list1/leaf-a; object /foo/list1/leaf-b; } conformance 2008-06-01 { object /foo/leaf1; object /foo/leaf2 { min-access read-only; } } } This way there is only 1 file for each module maintained, and it is still very clear what is contained in each version. I know this can get verbose if there are lots of leafs to enumerate, but so far nobody has standardized more than 3 NETCONF knobs at a time, so I'm not very concerned about the burden on readers or writers. For standards users, it is really important to know what to expect when a device claims to support version X of the foo module. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 09:20: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 2330F3A6A36; Mon, 23 Jun 2008 09:20: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 678603A6A36 for ; Mon, 23 Jun 2008 09:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QkklqZFTgqd for ; Mon, 23 Jun 2008 09:20:31 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D14323A6A2F for ; Mon, 23 Jun 2008 09:20:30 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 811981B80C5; Mon, 23 Jun 2008 18:20:30 +0200 (CEST) Date: Mon, 23 Jun 2008 18:20:48 +0200 (CEST) Message-Id: <20080623.182048.148577796.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <485FB546.1060100@netconfcentral.com> References: <485FA6A4.4030200@netconfcentral.com> <20080623.154936.199811755.mbj@tail-f.com> <485FB546.1060100@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> The real problem with groupings is understanding the > >> contents, and therefore the conformance requirements. > >> > >> Consider 4 modules: > >> > >> m1: contains grouping G = { leaf1, leaf2 } > >> m2: uses G > >> m3: augments grouping G: G' = G + { leaf3 } > >> m4: uses G' > > No, m4 uses G. And m3 just augments G, it does not create a G'. > > > > So you are saying that G' can only be local to m3 > because the augment of G can only be in m3 and only used in m3? I'm not sure I follow this. There is no named grouping G'. For example: module m1 { grouping G { leaf leaf1; leaf leaf2; } } module m2 { container x { uses m1:G; } container y { container z { uses m1:G; } } } module m3 { augment /m1:G { leaf leaf3; } } If a server implements m2 and m3, you might get: 10 20 30 This is exactly the same effect as if m3 was defined like this: module m3 { augment /m2:x { leaf 3; } augment /m2:y/m2:z { leaf 3; } } So I don't get what you mean when you talk about G' and how groupings can evolve over time. > In that case, I would much rather punt this whole idea > and force the DM writer to use the constructs already > available which can produce the same results. augmentation of a grouping solves one problem that is not possible to solve today. The 'm3' module can augment m1:G, without having to know about m2 or any other module that uses G. > Combining lots of grouping augments could be a DM reader's > nightmare. Browsing through a list of copy-and-pasted explicit augement of the data hierarchy might be even worse... > >> There are a couple big problems. > >> 1) locking the 'uses-stmt' > >> > >> - When m1 is published it contains 2 leafs. > >> - When m2 is published, m1:G contains 2 leafs and the semantics > >> of m2 depends on this fact. > >> - Later m1 is republished and 'list1' is added to the grouping > >> > >> Q: How does a developer compiling m2 (at any time after m2 > >> is published) import the correct version > >> of m1, such that G has 2 child nodes, not 3? > > Just like with normal 'augment', the developer knows if the augmenting > > module 'm3' is supported, and thus if just the two leaves from m1 should be > > implemented, or if the augmented leafs should be implemented as well. > > > >> - If m2 is ever republished, is it required to use the new > >> m1:G then, or can it still use the old version of m1:G? > >> > >> * Unless this problem is solved, I do not see how a grouping > >> can ever be modified (let alone augmented), after it is > >> published in an RFC. > > I think you're mixing two different concepts here; versioning > > vs. augmentations. I agree with you on the versioning issue though. > > > > Yes I am mixing 2 similar problems. > Groupings are much different than anything the IETF has ever used > before in a network management data modeling language. > > When m2 is published, the exact definitions from m1 it uses needs to be > specified and locked -- regardless of what happens to m1 > in the future. Agreed. The data tree is well-defined, modulo augment of the data hierarchy - this is what we currently have, and it would not change if we introduce augment of grouping. > This property of MIBs is not just a feature, it is > a show-stopper MUST HAVE for standards. A standard cannot have > any 'place-holders' replaced at compile-time, like a #define in C. > SMIv2 does not allow TEXTUAL-CONVENTIONs to ever be changed in > non-backward-compatible ways. The OBJECT-TYPE and NOTIFICATION-TYPE > macros are completely enumerated for a given conformance level, > for a given version of the module. The intention is to do the same for our corresponding statement, which is 'typedef'. > It is not as if there is some shortage of unique names for groupings. > If you need a grouping G' that extends G in a module, then just > create a new grouping G2, and start using that instead of G > for new data structures. Agreed. But this is a separate isssue; this is about versioning. You and I agree on the versioning rules. > >> 2) collecting the augments > >> - When m3 augments G with 'leaf3', this is being added to the > >> XML namespace for m1. > > No, just like w/ normal augment, 'leaf3' would be defined in m3's namespace. > > This really changes how groupings work. No. This is how augment works. The grouping/uses stays the same. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 09:26: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 32BA53A69F4; Mon, 23 Jun 2008 09:26: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 C9C383A6A16 for ; Mon, 23 Jun 2008 09:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdGkfEZMmiGc for ; Mon, 23 Jun 2008 09:26:16 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id A648F3A68B5 for ; Mon, 23 Jun 2008 09:26:16 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 8E2301B80C5; Mon, 23 Jun 2008 18:26:16 +0200 (CEST) Date: Mon, 23 Jun 2008 18:26:34 +0200 (CEST) Message-Id: <20080623.182634.184565185.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200806231525.m5NFPHZJ061502@idle.juniper.net> References: <20080623.154936.199811755.mbj@tail-f.com> <200806231525.m5NFPHZJ061502@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > >I think you're mixing two different concepts here; versioning > >vs. augmentations. I agree with you on the versioning issue though. > > The problem is that without versioning, augmentation of groupings > is considered dangerous, since ordinary uses can suffer drive-by > augmentation. But not having augmentation of groupings reduces the > utility of both augmentation and grouping, and forces the use of > hack like grouping names with version number in them. Again I think the two issues are mixed - adding a version number to the grouping name solves the versioning problem, but not the augementation problem. > Which IMHO drives us back to the need for versioned imports. If I > can control which revision of a module I'm importing, then my > dependency is explicit and changes to the module don't affect me. > This gives the stability and certainty that is needed for modules > to be both fixed and evolving, as they are in the real world. Some other module would still be able to augment your data tree. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 09: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 EC7363A69D3; Mon, 23 Jun 2008 09: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 151DE3A69F4 for ; Mon, 23 Jun 2008 09:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 gl0n9qnNdPZw for ; Mon, 23 Jun 2008 09:35:59 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 845AC3A69D3 for ; Mon, 23 Jun 2008 09:35:57 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 09:32:59 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, 23 Jun 2008 09:35:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 09:35:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 09:35: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 m5NGZdx98609; Mon, 23 Jun 2008 09:35: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 m5NGX9FA062597; Mon, 23 Jun 2008 16:33:09 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806231633.m5NGX9FA062597@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080623.182634.184565185.mbj@tail-f.com> Date: Mon, 23 Jun 2008 12:33:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 16:35:40.0349 (UTC) FILETIME=[2C5D16D0:01C8D54F] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Some other module would still be able to augment your data tree. Yes, but I want that. What I don't want is for the next version of a module that I import to add leafs to my data that aren't implemented. If I import a module (A) in my module (B), and I code to today's version of A, when the next version of A appears, no one knows that my software doesn't implement leafs described in the modern A. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 09: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 7A0EE3A6910; Mon, 23 Jun 2008 09: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 753933A69D3 for ; Mon, 23 Jun 2008 09:38:44 -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 kBbbBkTaopNw for ; Mon, 23 Jun 2008 09:38:40 -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 C1DDB3A6910 for ; Mon, 23 Jun 2008 09:38:40 -0700 (PDT) Received: (qmail 56041 invoked from network); 23 Jun 2008 16:38:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 16:38:39 -0000 X-YMail-OSG: 3qqXB0sVM1mUsjURENePyqi9n1AD1UWORovoAkeEISt5tdl3cCDh5F12IDJrMkrh6rOb3.irhmfuKLRIlewcV6VZ5NH4EnSTW1vUSzoQcg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485FD18D.40607@netconfcentral.com> Date: Mon, 23 Jun 2008 09:38:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080623.154936.199811755.mbj@tail-f.com> <200806231525.m5NFPHZJ061502@idle.juniper.net> <20080623.182634.184565185.mbj@tail-f.com> In-Reply-To: <20080623.182634.184565185.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> I think you're mixing two different concepts here; versioning >>> vs. augmentations. I agree with you on the versioning issue though. >> The problem is that without versioning, augmentation of groupings >> is considered dangerous, since ordinary uses can suffer drive-by >> augmentation. But not having augmentation of groupings reduces the >> utility of both augmentation and grouping, and forces the use of >> hack like grouping names with version number in them. > > Again I think the two issues are mixed - adding a version number to > the grouping name solves the versioning problem, but not the > augementation problem. > I don't agree that there is a problem with augment. I don't agree that the IETF has enough experience with YANG to reach consensus and sufficiently specify this in an an inter-operable manner. >> Which IMHO drives us back to the need for versioned imports. If I >> can control which revision of a module I'm importing, then my >> dependency is explicit and changes to the module don't affect me. >> This gives the stability and certainty that is needed for modules >> to be both fixed and evolving, as they are in the real world. > > Some other module would still be able to augment your data tree. Fine. They can specify the exact data nodes to augment with the existing augment-stmt. It is unambiguous and allows each uses-stmt to be augmented or not, instead of all-or-none. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 10:09: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 2976F3A69FD; Mon, 23 Jun 2008 10:09: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 1D0193A699F for ; Mon, 23 Jun 2008 10:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 u6UHSeUUgKhK for ; Mon, 23 Jun 2008 10:09:04 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id CC08D3A6A2B for ; Mon, 23 Jun 2008 10:09:02 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 10:08:57 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, 23 Jun 2008 10:08:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 10:08:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 10:08: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 m5NH8Zx08120; Mon, 23 Jun 2008 10:08:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5NH64IF062882; Mon, 23 Jun 2008 17:06:05 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806231706.m5NH64IF062882@idle.juniper.net> To: Andy Bierman In-reply-to: <485FCBF8.7030302@netconfcentral.com> Date: Mon, 23 Jun 2008 13:06:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 17:08:36.0233 (UTC) FILETIME=[C6150F90:01C8D553] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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: >Putting the versioning info in the name is not a hack. The issues with this approach become exposed when you work thru some more complex cases than are allowed in the space of an email. But let's try..... I have a BGP module. This module defines over three thousand statements: [edit protocols bgp] phil@dent# help apropos . | match set | count Count: 3587 lines This is the number of leaf nodes under the BGP section of the JUNOS configuration hierarchy. Certainly many of these are repeated, since we allow knobs to exist at multiple, more specific levels of the configuration hiearchy, but this is meant to give you an idea of the complexity and size of the problem. As we move to YANG, these repeated nodes will become groupings. Groupings will use other groupings as required to get the exact combination of knobs required. For example, the bgp-afi-options grouping defines two nodes, prefix-limit and rib-group. This grouping is used in seven places, six of which are other groupings. I traced the references for the first grouping and found it used in eight places. If I pick the first grouping that uses this new grouping, I find it used in three places which aren't groups. So it's not a matter of adding version numbers to one grouping, but to every grouping that uses that grouping. This leads to YANG that looks like: container protocols { container bgp { grouping bgp-afi-options-v1 { container prefix-limit { ... } leaf rib-group { ... } } grouping bgp-afi-options-v2 { container prefix-limit { ... } leaf rib-group { ... } } grouping bgp-afi-options-v3 { container prefix-limit { ... } leaf rib-group { ... } } grouping bgp-afi-default-v1 { use bgp-afi-options-v1; ... } grouping bgp-afi-default-v2 { use bgp-afi-options-v2; ... } grouping bgp-afi-default-v3 { use bgp-afi-options-v3; ... } grouping bgp-family-v1 { ... container family { container inet { container unicast { use bgp-afi-default-v1; ... } container multicast { use bgp-afi-default-v1; ... } ... } } } grouping bgp-family-v2 { ... container family { container inet { container unicast { use bgp-afi-default-v2; ... } container multicast { use bgp-afi-default-v2; ... } ... } } } grouping bgp-family-v3 { ... container family { container inet { container unicast { use bgp-afi-default-v3; ... } container multicast { use bgp-afi-default-v3; ... } ... } } } grouping bgp-peer-options-1 { use bgp-family-v1; ... } grouping bgp-peer-options-2 { use bgp-family-v2; ... } grouping bgp-peer-options-3 { use bgp-family-v3; ... } use bgp-peer-options-3; list group { ... use bgp-peer-options-3; list peer { ... use bgp-peer-options-3; } } } } This is needed because I changed one thing in one leaf in one grouping. Imagine this after a few years of a hundred bgp hackers. Compare it to "import bgp { revision 2008-01-01; }". History belongs in historical documents. It doesn't need to be intermixed with the modern YANG. It would be like the plot of every zombie movie ever made. The volume of dead YANG zombie groupings limping around would overwhelm our shotgun-wielding heroes. The percent of crap you carry inside a module in order to avoid breaking other people will outweigh and obscure the real YANG you want the precious reader to understand. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 10:46: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 0E0F53A69D5; Mon, 23 Jun 2008 10:46: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 0D6513A69D5 for ; Mon, 23 Jun 2008 10:46:50 -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 V1K4fYv7fB-e for ; Mon, 23 Jun 2008 10:46:48 -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 2E0D63A6838 for ; Mon, 23 Jun 2008 10:46:48 -0700 (PDT) Received: (qmail 50950 invoked from network); 23 Jun 2008 17:46:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 17:46:46 -0000 X-YMail-OSG: 4xAJudEVM1nIxZAWKTq_6n1tNOwHA8aNmIMr47Hwlbnn9yqVqkMWIRydzsaamnLQI3yXDLzzXQh5p_l1VsgrGUdtQDFLN_gRdin_W0XuaY4hycNcQjE.pR778S04Q21js5E- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485FE184.3060300@netconfcentral.com> Date: Mon, 23 Jun 2008 10:46:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806231706.m5NH64IF062882@idle.juniper.net> In-Reply-To: <200806231706.m5NH64IF062882@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: >> Putting the versioning info in the name is not a hack. > > The issues with this approach become exposed when you work thru > some more complex cases than are allowed in the space of an email. > But let's try..... > > I have a BGP module. This module defines over three thousand > statements: > > [edit protocols bgp] > phil@dent# help apropos . | match set | count > Count: 3587 lines > > This is the number of leaf nodes under the BGP section of the JUNOS > configuration hierarchy. Certainly many of these are repeated, > since we allow knobs to exist at multiple, more specific levels of > the configuration hiearchy, but this is meant to give you an idea > of the complexity and size of the problem. > > As we move to YANG, these repeated nodes will become groupings. > Groupings will use other groupings as required to get the exact > combination of knobs required. > > For example, the bgp-afi-options grouping defines two nodes, > prefix-limit and rib-group. This grouping is used in seven places, > six of which are other groupings. I traced the references for the > first grouping and found it used in eight places. If I pick the > first grouping that uses this new grouping, I find it used in three > places which aren't groups. > > So it's not a matter of adding version numbers to one grouping, but > to every grouping that uses that grouping. This leads to YANG that > looks like: > > container protocols { > container bgp { > grouping bgp-afi-options-v1 { > container prefix-limit { > ... > } > leaf rib-group { > ... > } > } > grouping bgp-afi-options-v2 { > container prefix-limit { > ... > } > leaf rib-group { > ... > } > } > grouping bgp-afi-options-v3 { > container prefix-limit { > ... > } > leaf rib-group { > ... > } > } > grouping bgp-afi-default-v1 { > use bgp-afi-options-v1; > ... > } > grouping bgp-afi-default-v2 { > use bgp-afi-options-v2; > ... > } > grouping bgp-afi-default-v3 { > use bgp-afi-options-v3; > ... > } > grouping bgp-family-v1 { > ... > container family { > container inet { > container unicast { > use bgp-afi-default-v1; > ... > } > container multicast { > use bgp-afi-default-v1; > ... > } > ... > } > } > } > grouping bgp-family-v2 { > ... > container family { > container inet { > container unicast { > use bgp-afi-default-v2; > ... > } > container multicast { > use bgp-afi-default-v2; > ... > } > ... > } > } > } > grouping bgp-family-v3 { > ... > container family { > container inet { > container unicast { > use bgp-afi-default-v3; > ... > } > container multicast { > use bgp-afi-default-v3; > ... > } > ... > } > } > } > grouping bgp-peer-options-1 { > use bgp-family-v1; > ... > } > grouping bgp-peer-options-2 { > use bgp-family-v2; > ... > } > grouping bgp-peer-options-3 { > use bgp-family-v3; > ... > } > > use bgp-peer-options-3; > list group { > ... > use bgp-peer-options-3; > list peer { > ... > use bgp-peer-options-3; > } > } > } > } > This looks clear, unambiguous, and tractable to me. > This is needed because I changed one thing in one leaf in one > grouping. Imagine this after a few years of a hundred bgp hackers. > Compare it to "import bgp { revision 2008-01-01; }". > So every manager and agent needs to maintain N concurrent versions of each module, and diff them by hand to figure out what changed. Not much better. > History belongs in historical documents. It doesn't need to be > intermixed with the modern YANG. It would be like the plot of every > zombie movie ever made. The volume of dead YANG zombie groupings > limping around would overwhelm our shotgun-wielding heroes. The > percent of crap you carry inside a module in order to avoid breaking > other people will outweigh and obscure the real YANG you want the > precious reader to understand. It is not history -- it is standards conformance. Juergen proposed a modification with conformance-group definitions like SMIv2 GROUP, which could greatly reduce the redundancy. Speaking of history, when SMING WG collapsed in failure, it was because most of WG, let alone IETF, was not really on-board with all the changes to SMIv2 that were proposed. Finally somebody said "My engineers will never bother to learn this", and the whole thing collapsed, as vendor after vendor agreed they would rather do nothing than 'learn all this new stuff'. I do not see much participation in this WG at all so far, and the possibility of a SMING-repeat seems non-trivial. IMO, start simple, and make sure there even is a YANG 1.0 published. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 10:48: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 BD9743A6A7B; Mon, 23 Jun 2008 10:48: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 1E1D53A6A7A for ; Mon, 23 Jun 2008 10:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnmK28393BQv for ; Mon, 23 Jun 2008 10:48:18 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 355843A6A7C for ; Mon, 23 Jun 2008 10:48:18 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id BE6A81B80C5; Mon, 23 Jun 2008 19:48:17 +0200 (CEST) Date: Mon, 23 Jun 2008 19:48:35 +0200 (CEST) Message-Id: <20080623.194835.178508621.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200806231633.m5NGX9FA062597@idle.juniper.net> References: <20080623.182634.184565185.mbj@tail-f.com> <200806231633.m5NGX9FA062597@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > >Some other module would still be able to augment your data tree. > > Yes, but I want that. What I don't want is for the next version > of a module that I import to add leafs to my data that aren't > implemented. If I import a module (A) in my module (B), and I code > to today's version of A, when the next version of A appears, no one > knows that my software doesn't implement leafs described in the > modern A. Agreed. augement of grouping will not give you that, just like normal augment doesn't give you that. You have full control of this - only if you implement the augmenting module, your data tree will be augmented. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 12:00: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 8D4773A69D5; Mon, 23 Jun 2008 12:00: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 825693A69D5 for ; Mon, 23 Jun 2008 12:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.721 X-Spam-Level: X-Spam-Status: No, score=-5.721 tagged_above=-999 required=5 tests=[AWL=-0.414, 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 6Ez4UhpmFIaP for ; Mon, 23 Jun 2008 12:00:21 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id A411E3A6991 for ; Mon, 23 Jun 2008 12:00:14 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 12:00:11 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 11:59:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 11:59:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 11:59:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5NIxux43949; Mon, 23 Jun 2008 11:59:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5NIvQCW063961; Mon, 23 Jun 2008 18:57:26 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806231857.m5NIvQCW063961@idle.juniper.net> T>o: Andy Bierman In-reply-to: <485FE184.3060300@netconfcentral.com> Date: Mon, 23 Jun 2008 14:57:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 18:59:57.0460 (UTC) FILETIME=[54676540:01C8D563] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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 looks clear, unambiguous, and tractable to me. unambiguous? tractable? maybe, but even this change of one leaf makes the problem pretty obvious. You'd put too much of the volume of the module into maintenance and not into clearly describing the current state of the art. >So every manager and agent needs to maintain N concurrent >versions of each module, and diff them by hand to figure out >what changed. Not much better. I disagree. N independently readable, standalone versions are easier to parse than one soup pot full of everything. Diff will show you stuff like: + grouping bgp-afi-options-v2 { + container prefix-limit { + ... + } + leaf rib-group { + ... + } + } ... + grouping bgp-afi-default-v2 { + use bgp-afi-options-v2; + ... + } ... + grouping bgp-family-v2 { + ... + container family { + container inet { + container unicast { + use bgp-afi-default-v2; + ... + } + container multicast { + use bgp-afi-default-v2; + ... + } + ... + } + } + } ... + grouping bgp-peer-options-2 { + use bgp-family-v2; + ... + } - use bgp-peer-options-1; + use bgp-peer-options-2; list group { ... - use bgp-peer-options-1; + use bgp-peer-options-2; list peer { ... - use bgp-peer-options-1; + use bgp-peer-options-2; } } This won't show you want's changed. But if you diffed versions, you'd get something like: + leaf new-thing { + ... + } In addition, a YANG-enabled diff application can know the relationship between the bgp-family grouping over multiple revisions. If you turn this into bgp-family-v1/2/3 you lose that continuity. No one knows if bgp-family-v2 is new or a new revision. You end up with the YANG equivalent of spaghetti code. YANG tries to make rich data that applications can use. Being able to use previous module revisions is a more simple, clear and consistent mechanism for module evolution. >I do not see much participation in this WG at all so far, >and the possibility of a SMING-repeat seems non-trivial. This is an entirely different discussion. If you don't think YANG will be adopted, let's talk about the chief reasons why you think it won't be. Versioned imports will surely not be on that list. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 12:51: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 0FA353A694C; Mon, 23 Jun 2008 12:51: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 497853A69F4 for ; Mon, 23 Jun 2008 12:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD6WpFaZ6QKR for ; Mon, 23 Jun 2008 12:51:08 -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 7885F3A69ED for ; Mon, 23 Jun 2008 12:51:08 -0700 (PDT) Received: (qmail 91039 invoked from network); 23 Jun 2008 19:51:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 19:51:06 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <485FFEA8.1030503@netconfcentral.com> Date: Mon, 23 Jun 2008 12:51:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806231857.m5NIvQCW063961@idle.juniper.net> In-Reply-To: <200806231857.m5NIvQCW063961@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> This looks clear, unambiguous, and tractable to me. > > unambiguous? tractable? maybe, but even this change of > one leaf makes the problem pretty obvious. You'd put too > much of the volume of the module into maintenance and not > into clearly describing the current state of the art. > >> So every manager and agent needs to maintain N concurrent >> versions of each module, and diff them by hand to figure out >> what changed. Not much better. > > I disagree. N independently readable, standalone versions > are easier to parse than one soup pot full of everything. > Diff will show you stuff like: > > + grouping bgp-afi-options-v2 { > + container prefix-limit { > + ... > + } > + leaf rib-group { > + ... > + } > + } > ... > + grouping bgp-afi-default-v2 { > + use bgp-afi-options-v2; > + ... > + } > ... > + grouping bgp-family-v2 { > + ... > + container family { > + container inet { > + container unicast { > + use bgp-afi-default-v2; > + ... > + } > + container multicast { > + use bgp-afi-default-v2; > + ... > + } > + ... > + } > + } > + } > ... > + grouping bgp-peer-options-2 { > + use bgp-family-v2; > + ... > + } > > - use bgp-peer-options-1; > + use bgp-peer-options-2; > list group { > ... > - use bgp-peer-options-1; > + use bgp-peer-options-2; > list peer { > ... > - use bgp-peer-options-1; > + use bgp-peer-options-2; > } > } > > > This won't show you want's changed. But if you diffed versions, > you'd get something like: > > + leaf new-thing { > + ... > + } > > In addition, a YANG-enabled diff application can know the relationship > between the bgp-family grouping over multiple revisions. If you > turn this into bgp-family-v1/2/3 you lose that continuity. No one > knows if bgp-family-v2 is new or a new revision. You end up with > the YANG equivalent of spaghetti code. > > YANG tries to make rich data that applications can use. Being > able to use previous module revisions is a more simple, clear > and consistent mechanism for module evolution. > What about version mixing? Is this allowed: module m2 (version 2008-06-01) { grouping G {} } module m2 (version 2008-06-23) { grouping G { // + new stuff } } module m3 { import m2 { prefix m2; } grouping GG { container gg { uses G; } } } module m4 { import m2 { prefix m2; revision 2008-06-01; } import m3 { prefix m3; } list X { uses G; uses GG; } } YANG mid-term 1: Specify the contents of list 'X'. Show your work :-) >> I do not see much participation in this WG at all so far, >> and the possibility of a SMING-repeat seems non-trivial. > > This is an entirely different discussion. If you don't think YANG > will be adopted, let's talk about the chief reasons why you think > it won't be. Versioned imports will surely not be on that list. > It might be on that list, if the example I showed above is allowed. If it is a compiler error, go away and come back when m4 is not mixing versions of m2:G, then I can live with it. I prefer to get started with the YANG already defined, and only do MUST-HAVE changes, if any. Anything in the 'nice-to-have' category can wait until YANG 1.1, etc. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 13:17:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EC93A6A18; Mon, 23 Jun 2008 13:17:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24333A6A3D for ; Mon, 23 Jun 2008 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 1sIpM-x+Hw7q for ; Mon, 23 Jun 2008 13:17:22 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id CD72F3A697F for ; Mon, 23 Jun 2008 13:17:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 13:16:51 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:17:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:17:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 13:17:20 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5NKHJx67964; Mon, 23 Jun 2008 13:17: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 m5NKEmKJ064987; Mon, 23 Jun 2008 20:14:49 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806232014.m5NKEmKJ064987@idle.juniper.net> To: Andy Bierman In-reply-to: <485FFEA8.1030503@netconfcentral.com> Date: Mon, 23 Jun 2008 16:14:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 20:17:20.0080 (UTC) FILETIME=[239EFD00:01C8D56E] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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: >YANG mid-term 1: Specify the contents of list 'X'. Show your work :-) The result is that GG is using the modern G, so X will have an old G and a new G in GG. If we flesh your example out a bit: module m2 { revision 2008-06-01 { ... } grouping G { leaf g-2008-06-01 { type empty; } } } module m2 { revision 2008-06-23 { ... } revision 2008-06-01 { ... } grouping G { leaf g-2008-06-01 { type empty; } leaf g-2008-06-23 { type empty; } } } module m3 { import m2 { revision 2008-06-23; prefix m2; } grouping GG { container gg { uses G; } } } module m4 { import m2 { prefix m2; revision 2008-06-01; } import m3 { prefix m3; } list X { uses G; uses GG; } } So the hierarchy would be: >It might be on that list, if the example I showed above is allowed. >If it is a compiler error, go away and come back when m4 is not >mixing versions of m2:G, then I can live with it. Your example is really the type of mixing should not be allowed, since m4 is trying to use an m2 that's older than m3. This would mean that m4 was written using out-of-date modules. A reasonable rule would be that if you write or rev a module, you MUST move to fully modern imports. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 13:41: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 9A9293A6948; Mon, 23 Jun 2008 13:41: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 14C373A69DB for ; Mon, 23 Jun 2008 13:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q342Png-zJol for ; Mon, 23 Jun 2008 13:41:53 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 36CE93A6948 for ; Mon, 23 Jun 2008 13:41:53 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id DC1B01B80D3; Mon, 23 Jun 2008 22:41:52 +0200 (CEST) Date: Mon, 23 Jun 2008 22:42:11 +0200 (CEST) Message-Id: <20080623.224211.229320042.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200806232014.m5NKEmKJ064987@idle.juniper.net> References: <485FFEA8.1030503@netconfcentral.com> <200806232014.m5NKEmKJ064987@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > module m4 { > import m2 { > prefix m2; > revision 2008-06-01; > } > > import m3 { prefix m3; } Is this just a typo, or do you suggest that the 'revision' on the import is optional? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 13:50: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 2B7153A6A12; Mon, 23 Jun 2008 13:50: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 C3C093A6A12 for ; Mon, 23 Jun 2008 13:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 MGBzvlcVrkR9 for ; Mon, 23 Jun 2008 13:50:10 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 526403A68DB for ; Mon, 23 Jun 2008 13:50:08 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 13:49:28 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:48:40 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:48:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 13:48:39 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5NKmdx78060; Mon, 23 Jun 2008 13:48: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 m5NKk8SX065213; Mon, 23 Jun 2008 20:46:08 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806232046.m5NKk8SX065213@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080623.224211.229320042.mbj@tail-f.com> Date: Mon, 23 Jun 2008 16:46:08 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 20:48:39.0932 (UTC) FILETIME=[8419A3C0:01C8D572] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >Is this just a typo, or do you suggest that the 'revision' on the >import is optional? typo. I copied Andy's text and fixed one import but not the other. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 14: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 0D0FD3A69F9; Mon, 23 Jun 2008 14: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 C820A3A6A90 for ; Mon, 23 Jun 2008 14:04:31 -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 PlG3-96lXIDq for ; Mon, 23 Jun 2008 14:04:31 -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 208FE3A6A8E for ; Mon, 23 Jun 2008 14:02:50 -0700 (PDT) Received: (qmail 9689 invoked from network); 23 Jun 2008 21:02:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 21:02:49 -0000 X-YMail-OSG: JczNb4YVM1mExLnxQEfW0mEnXg43vqwHphE.jmzNmkj6qJNS0nTh5NjTvJwEdMuHF9EGG9UqxFGUx7ZbcY9c9hfQOO1fXCxC8FP31ZGjTN8tyOyYIv0Ll4nv0Z_amfcQCMk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48600F77.9070304@netconfcentral.com> Date: Mon, 23 Jun 2008 14:02:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <485FFEA8.1030503@netconfcentral.com> <200806232014.m5NKEmKJ064987@idle.juniper.net> <20080623.224211.229320042.mbj@tail-f.com> In-Reply-To: <20080623.224211.229320042.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: > Phil Shafer wrote: >> module m4 { >> import m2 { >> prefix m2; >> revision 2008-06-01; >> } >> >> import m3 { prefix m3; } > > Is this just a typo, or do you suggest that the 'revision' on the > import is optional? > I was wondering that myself. If every import has to have a revision clause, and every module must have a unique revision statement for each published version, then it is less of a problem. The DM writer would be forced to update the 'import m2' in m4 to the latest revision of m2 because 'import m3' collides with it. It adds some overhead -- every time module 'foo' is changed, every import in the module will need to be checked and updated to the latest version. In an N-writers development environment, this could become difficult to maintain. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 14:42:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7FF3A687D; Mon, 23 Jun 2008 14:42:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215E33A68E0 for ; Mon, 23 Jun 2008 14:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 TTaU4YRCNph3 for ; Mon, 23 Jun 2008 14:42:44 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 65DD73A6805 for ; Mon, 23 Jun 2008 14:42:42 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 23 Jun 2008 14:42:41 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 14:41:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 14:41:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 14:41:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5NLfQx95777; Mon, 23 Jun 2008 14:41:27 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5NLcu0A065784; Mon, 23 Jun 2008 21:38:56 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806232138.m5NLcu0A065784@idle.juniper.net> To: Andy Bierman In-reply-to: <48600F77.9070304@netconfcentral.com> Date: Mon, 23 Jun 2008 17:38:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jun 2008 21:41:27.0707 (UTC) FILETIME=[E43DBEB0:01C8D579] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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: >If every import has to have a revision clause, and >every module must have a unique revision statement >for each published version, then it is less of a problem. >The DM writer would be forced to update the 'import m2' in m4 >to the latest revision of m2 because 'import m3' collides with it. Exactly. A human would need to check and update the module. And until they did, everything would continue to work as it did before the new revision was published. >It adds some overhead -- every time module 'foo' is changed, >every import in the module will need to be checked and >updated to the latest version. In an N-writers development >environment, this could become difficult to maintain. But it also means the switch to a new revision is gated by someone making the change. There's an explicit dependency and an explicit action is required to change it. This also gives us more latitude WRT module updating rules, since we know the DM writers won't be broken by new revisions. It works as a safeguard. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jun 23 14:53: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 5D80F3A6929; Mon, 23 Jun 2008 14:53: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 482393A688B for ; Mon, 23 Jun 2008 14:53: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 1uAPlPoHjBSN for ; Mon, 23 Jun 2008 14:53:27 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 954B23A6929 for ; Mon, 23 Jun 2008 14:53:27 -0700 (PDT) Received: (qmail 35241 invoked from network); 23 Jun 2008 21:53:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 23 Jun 2008 21:53:26 -0000 X-YMail-OSG: vSlg9_MVM1nlSRr2Zfy5VJBUONlbivy7D9PaggovWrihSPan5B9WIUjtvEsHviOWpDNjO_powe_XyITgB9W2odXvgBzFDYWGsQRgOrzG43WaJOWojhE55lLWB0XNNmuYlGA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48601B54.4020105@netconfcentral.com> Date: Mon, 23 Jun 2008 14:53:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806232138.m5NLcu0A065784@idle.juniper.net> In-Reply-To: <200806232138.m5NLcu0A065784@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: >> If every import has to have a revision clause, and >> every module must have a unique revision statement >> for each published version, then it is less of a problem. >> The DM writer would be forced to update the 'import m2' in m4 >> to the latest revision of m2 because 'import m3' collides with it. > > Exactly. A human would need to check and update the module. > And until they did, everything would continue to work as > it did before the new revision was published. > >> It adds some overhead -- every time module 'foo' is changed, >> every import in the module will need to be checked and >> updated to the latest version. In an N-writers development >> environment, this could become difficult to maintain. > > But it also means the switch to a new revision is gated by someone > making the change. There's an explicit dependency and an explicit > action is required to change it. I know -- that's why it works. > > This also gives us more latitude WRT module updating rules, since > we know the DM writers won't be broken by new revisions. It works > as a safeguard. yes -- solves the changed-grouping problem, but the cost is maintaining every version of every module, instead of just 1 version of every module. If you encounter a typo or make a simple bugfix that does not change the semantics (a clarification) can the bug be fixed in all affected versions of the module without updating the revision at all? It seems you could only make these bug-fixes in a new latest version. > > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 03:31: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 6E9CD3A6962; Tue, 24 Jun 2008 03:31: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 5A9473A6962 for ; Tue, 24 Jun 2008 03:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSnJnDxkkqtH for ; Tue, 24 Jun 2008 03:31:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EBA9D3A693C for ; Tue, 24 Jun 2008 03:31:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41809C001F; Tue, 24 Jun 2008 12:31:18 +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 hEhbkApKZ82K; Tue, 24 Jun 2008 12:31:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 912CFC0041; Tue, 24 Jun 2008 12:31:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3D54B5DCCB9; Tue, 24 Jun 2008 12:31:10 +0200 (CEST) Date: Tue, 24 Jun 2008 12:31:10 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080624103110.GA26158@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20080616.113122.210899146.mbj@tail-f.com> <20080616134614.GA3608@elstar.local> <20080623.102947.71614638.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080623.102947.71614638.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-schoenw-netmod-yang-types-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Mon, Jun 23, 2008 at 10:29:47AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jun 16, 2008 at 11:31:22AM +0200, Martin Bjorklund wrote: > > > A comment on the ipv4 address, which contains an optional zone index. > > > Do we need to specify the expected behavior when a server does not > > > support zone index for a particular object? > > > > This might depend on the particular circumstances of the usage of this > > object. Do you have a concrete proposal? > > Maybe say that if the object does not support zones, the error-tag > 'invalid-value' should be used. (or maybe 'bad-element'; it's not > clear to me when 'bad-element'/'bad-attribute' vs. 'invalid-value' > should be used). > > Can you elaborate on the particular circumstances that could affect > the error message? I also have trouble to understand which RFC4741 error tag is for which purpose. Perhaps Andy can shed some light on this... > > > RFC4001 contains some discussion about the zone index; can we refer > > > to that rfc in this document? > > > > I like to avoid a dependency on RFC 4001. Which discussion do you > > mean? Would it be sufficient to add the following text to the > > description clauses of ipv4-address and ipv6-address? > > > > The zone index is used to disambiguate identical address values. > > For link-local addresses, the zone index will typically be the > > interface index number or the name of an interface. If the zone > > index is not present, the default zone of the device will be used. > > Adding this text would help. What about the special zone index '0' > (which in 4001 refers to the default zone)? Do we need it? If you want the default zone, you can simply omit the zone part. But I would also not object against having %0 mean the same thing for those who like index numbers. But see below... > For the ipv6 type, should we add a reference to rfc4007? Done. > In rfc4001, you had: > > The size of the zone index has been chosen so that it is consistent > with (i) the numerical zone index, defined in [RFC4007], and (ii) the > sin6_scope_id field of the sockaddr_in6 structure, defined in RFC > 2553 [RFC2553]. > > Why do you also allow interface name now? Can the server decides if > interface name or index is accepted? This is something for the WG to discuss. I allowed interface names since this is what I believe is commonly shown on CLIs. It seems that most people I get in touch with refer to interfaces by the equivalent of ifName instead of ifIndex. Sure, allowing both formats in the zone index raises a bunch of questions that should be answered: - does a number take precedence to be an index number (if there is an interface with a matching number) - what are boxes supposed to generate (index numbers or names) - are implementations supposed to remember whether a value was configured as name or number. All these questions could be avoided by just having one format, which however requires to find agreement how NETCONF data models identify interfaces, by name or by index number. Opinions more than welcome. /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 Jun 24 04:33:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E413A68D3; Tue, 24 Jun 2008 04:33:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85B43A699F for ; Tue, 24 Jun 2008 04:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb29waBuor5o for ; Tue, 24 Jun 2008 04:33:28 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D72D63A6889 for ; Tue, 24 Jun 2008 04:33:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 95B901B80C5; Tue, 24 Jun 2008 13:33:27 +0200 (CEST) Date: Tue, 24 Jun 2008 13:33:36 +0200 (CEST) Message-Id: <20080624.133336.163340411.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48600F77.9070304@netconfcentral.com> References: <200806232014.m5NKEmKJ064987@idle.juniper.net> <20080623.224211.229320042.mbj@tail-f.com> <48600F77.9070304@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > > Phil Shafer wrote: > >> module m4 { > >> import m2 { > >> prefix m2; > >> revision 2008-06-01; > >> } > >> > >> import m3 { prefix m3; } > > Is this just a typo, or do you suggest that the 'revision' on the > > import is optional? > > > > I was wondering that myself. > If every import has to have a revision clause, and > every module must have a unique revision statement > for each published version, then it is less of a problem. > The DM writer would be forced to update the 'import m2' in m4 > to the latest revision of m2 because 'import m3' collides with it. But that won't work. Suppose we have the following standard modules, published in rfcs: module ietf-m1 { revision 2008-06-23 { ... } revision 2008-06-01 { ... } } module ietf-m2 { import ietf-m1 { revision 2008-06-01; } } module ietf-m3 { import ietf-m1 { revision 2008-06-23; } } Now, my m4 module needs to import ietf-m2 and ietf-m3, which means that I will have dependencies to two versions of ietf-m1. I don't think we can require that all published modules are re-published as soon as one common module is updated - as an example, imagine that a clarification is needed in the inet-types module. So if we do this, we will have to accept that a server will have to support multiple versions of the same module. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 07:28: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 D860E3A69BD; Tue, 24 Jun 2008 07:28: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 27EEC3A69B2 for ; Tue, 24 Jun 2008 07:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 aRwsx8iKxXU8 for ; Tue, 24 Jun 2008 07:28:15 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 41E683A698B for ; Tue, 24 Jun 2008 07:28:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Tue, 24 Jun 2008 07:27:51 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 07:27:49 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 07:27:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 07:26:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5OEQ5x67474; Tue, 24 Jun 2008 07:26:05 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5OENY81070902; Tue, 24 Jun 2008 14:23:34 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806241423.m5OENY81070902@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080624.133336.163340411.mbj@tail-f.com> Date: Tue, 24 Jun 2008 10:23:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jun 2008 14:26:06.0379 (UTC) FILETIME=[3D2127B0:01C8D606] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >So if we do this, we will have to accept that a server will have to >support multiple versions of the same module. Absolutely. Not the easiest medicine, but IMHO it's what we need. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 08:21: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 28B783A6997; Tue, 24 Jun 2008 08:21: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 779F33A69FC for ; Tue, 24 Jun 2008 08:21:36 -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 Pl+ck303B9vQ for ; Tue, 24 Jun 2008 08:21:35 -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 24CF73A6997 for ; Tue, 24 Jun 2008 08:21:35 -0700 (PDT) Received: (qmail 77336 invoked from network); 24 Jun 2008 15:21:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2008 15:21:33 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <486110FB.5020002@netconfcentral.com> Date: Tue, 24 Jun 2008 08:21:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806241423.m5OENY81070902@idle.juniper.net> In-Reply-To: <200806241423.m5OENY81070902@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: > Martin Bjorklund writes: >> So if we do this, we will have to accept that a server will have to >> support multiple versions of the same module. > > Absolutely. Not the easiest medicine, but IMHO it's what > we need. Is this how CLI works? It sure isn't how SNMP works. Are there any agents that support every API version ever released, or do they support only the latest release at the time? I've only worked on the latter, and don't know of any examples of the former. I think this complexity is not worth the unproven utility that the groupings/uses approach to definition reuse claims to provide. Can anyone actually think of any sets of objects that should be defined in a grouping in a stand-alone module, because they are so reusable for all other modules? IMO, it is far more likely that the groupings and uses will be in the same module, in which case the problem goes away. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 09:25: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 A6C343A6A69; Tue, 24 Jun 2008 09:25: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 0C28D3A6A62 for ; Tue, 24 Jun 2008 09:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KucDO9qicZst for ; Tue, 24 Jun 2008 09:25:30 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 2AC953A6A56 for ; Tue, 24 Jun 2008 09:25:30 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 96FA91B80C5; Tue, 24 Jun 2008 18:25:30 +0200 (CEST) Date: Tue, 24 Jun 2008 18:25:51 +0200 (CEST) Message-Id: <20080624.182551.64680542.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <486110FB.5020002@netconfcentral.com> References: <200806241423.m5OENY81070902@idle.juniper.net> <486110FB.5020002@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, it is far more likely that the groupings and uses > will be in the same module, in which case the problem > goes away. The problem goes away for non-exported groupings, i.e. groupings scoped by some other statement than 'module' or 'submodule'. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 10:22: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 512CA3A68CA; Tue, 24 Jun 2008 10:22: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 153DF3A68E5 for ; Tue, 24 Jun 2008 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 pkN8aty5+f2W for ; Tue, 24 Jun 2008 10:22:48 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 39A623A68CA for ; Tue, 24 Jun 2008 10:22:46 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Tue, 24 Jun 2008 10:20:22 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 10:22:33 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 10:22:33 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 10:22:32 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5OHMVx23204; Tue, 24 Jun 2008 10:22:31 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5OHJxqI072419; Tue, 24 Jun 2008 17:20:00 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806241720.m5OHJxqI072419@idle.juniper.net> To: Andy Bierman In-reply-to: <486110FB.5020002@netconfcentral.com> Date: Tue, 24 Jun 2008 13:19:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jun 2008 17:22:32.0030 (UTC) FILETIME=[E2AB4FE0:01C8D61E] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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: >Can anyone actually think of any sets of objects that >should be defined in a grouping in a stand-alone module, >because they are so reusable for all other modules? >IMO, it is far more likely that the groupings and uses >will be in the same module, in which case the problem >goes away. Are you trying to define away the issue or just looking for a use case? Use name is any group of related nodes, say the address, port, and routing instance of a tcp socket. But this isn't an isolated issue, since you also have enumerations which will grow over time. When I add a new enumeration to a type that another module uses, how will I know if a device that announces that module uses the old or new version of that type? What will they do when I give them the new enum value? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 11:24: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 589BB3A68E0; Tue, 24 Jun 2008 11:24: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 8E24C3A68D0 for ; Tue, 24 Jun 2008 11:24:04 -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 ltPyuHL-REON for ; Tue, 24 Jun 2008 11:24: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 88E303A6829 for ; Tue, 24 Jun 2008 11:24:03 -0700 (PDT) Received: (qmail 66486 invoked from network); 24 Jun 2008 18:24:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2008 18:24:03 -0000 X-YMail-OSG: rA5ipIIVM1kFNYvBiPM2tiSgMqtAZXJaBcBZ2Hr..m6c.dzzjk6z7mHPTHLxVF4uOB0k2ilHhPjmPoOOfv4S40rHl.LW3M1m_G6KnJBqSX04GDpi9WVscSKW5v8b3JH_1zo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48613BC0.4040507@netconfcentral.com> Date: Tue, 24 Jun 2008 11:24:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806241720.m5OHJxqI072419@idle.juniper.net> In-Reply-To: <200806241720.m5OHJxqI072419@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: >> Can anyone actually think of any sets of objects that >> should be defined in a grouping in a stand-alone module, >> because they are so reusable for all other modules? >> IMO, it is far more likely that the groupings and uses >> will be in the same module, in which case the problem >> goes away. > > Are you trying to define away the issue or just looking for a use > case? Use name is any group of related nodes, say the address, > port, and routing instance of a tcp socket. > Looking for a use-case, and as usual, you have a good one. In SNMP-land, even though there are no structures, there is some experience with reusable data types, like InetAddress. There was a painful migration from IpAddress to InetAddress, but at least it was possible because IpAddress was not re-defined. Instead a new name was used. Due to the huge lag-time that Juergen mentioned for getting data models in RFCs updated (e.g., 2 years to never), import-by-version is not a realistic choice for standards. IMO, if 'deep indexing' is too complicated for YANG, than supporting multiple module versions within the same agent is 10X as complicated. The interactions for data-type chaining alone would be a nightmare to code. Then add in grouping/uses and augments, and N variants of each callback function, and coding complexity plus memory requirements goes through the roof. > But this isn't an isolated issue, since you also have enumerations > which will grow over time. When I add a new enumeration to a type > that another module uses, how will I know if a device that announces > that module uses the old or new version of that type? What will > they do when I give them the new enum value? The schema discovery mechanism will include the module version that contains the type -- this will be the one only version of that type on the agent. A manager will always need to be aware of every version of every module it uses. That has always been the case, to deal with N different agents. My concern is making the agent deal with N versions, which would be unprecedented. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 12:07: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 DF21A3A67CE; Tue, 24 Jun 2008 12:07: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 E6CF83A67CE for ; Tue, 24 Jun 2008 12:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 6NBq4lODI51E for ; Tue, 24 Jun 2008 12:07:54 -0700 (PDT) Received: from psmtp.com (exprod7ob113.obsmtp.com [64.18.2.178]) by core3.amsl.com (Postfix) with ESMTP id 527C63A67AD for ; Tue, 24 Jun 2008 12:07:49 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Tue, 24 Jun 2008 12:07:46 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 12:06:52 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 12:06:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 12:06: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 m5OJ6ox61302; Tue, 24 Jun 2008 12:06: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 m5OJ4Jkh073322; Tue, 24 Jun 2008 19:04:19 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806241904.m5OJ4Jkh073322@idle.juniper.net> To: Andy Bierman In-reply-to: <48613BC0.4040507@netconfcentral.com> Date: Tue, 24 Jun 2008 15:04:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jun 2008 19:06:51.0576 (UTC) FILETIME=[75A63B80:01C8D62D] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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: >Due to the huge lag-time that Juergen mentioned >for getting data models in RFCs updated (e.g., 2 years to never), >import-by-version is not a realistic choice for standards. I see the exact opposite. Since data models are slow to update, there needs to be a mechanism to say "Hey, I'm still using the old one". Versioned imports give that. >IMO, if 'deep indexing' is too complicated for YANG, >than supporting multiple module versions within the >same agent is 10X as complicated. This is a question of where the complexity lies. Deep indexing puts a cost on the device. Versioned imports puts a cost on the application, and the cost is mostly covered by the fact that you need to grok multiple modules. Imagine that we put the revision name as part of the module name (not that I'm suggesting that as a real fix). The code of "import A { revision 2; }" isn't any worse than "import A-revision-2;". Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 12:40: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 285E73A6844; Tue, 24 Jun 2008 12:40: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 B13B03A6844 for ; Tue, 24 Jun 2008 12:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaRPiBrS+7or for ; Tue, 24 Jun 2008 12:40:53 -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 EDD0F3A681F for ; Tue, 24 Jun 2008 12:40:53 -0700 (PDT) Received: (qmail 8541 invoked from network); 24 Jun 2008 19:40:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2008 19:40:49 -0000 X-YMail-OSG: MhdzJgYVM1lu9mkT9LrbaOmFfmXswdU9OwKNeBdtkvOoZzqnrq5JXvmr39Q9vLwqY9H5_BE1Bn.BKeQcxiCkUok3c12JfWOdiqmcjEWnqBg6HfnVFHRyM0MRtIlKO4Wdxik- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48614DBF.8070500@netconfcentral.com> Date: Tue, 24 Jun 2008 12:40:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806241904.m5OJ4Jkh073322@idle.juniper.net> In-Reply-To: <200806241904.m5OJ4Jkh073322@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: >> Due to the huge lag-time that Juergen mentioned >> for getting data models in RFCs updated (e.g., 2 years to never), >> import-by-version is not a realistic choice for standards. > > I see the exact opposite. Since data models are slow to > update, there needs to be a mechanism to say "Hey, I'm > still using the old one". Versioned imports give that. > Conformance statements give you that without requiring an agent to support N versions of each module. >> IMO, if 'deep indexing' is too complicated for YANG, >> than supporting multiple module versions within the >> same agent is 10X as complicated. > > This is a question of where the complexity lies. Deep > indexing puts a cost on the device. Versioned imports > puts a cost on the application, and the cost is mostly > covered by the fact that you need to grok multiple > modules. Imagine that we put the revision name as > part of the module name (not that I'm suggesting that > as a real fix). The code of "import A { revision 2; }" > isn't any worse than "import A-revision-2;". > I am most concerned with the standards utility of YANG and NETCONF. Juergen brought up a critical point: Vendors do not have change control over standard modules. If they happen to use 2 incompatible standard modules (via imports ripple), then they are stuck. They have to cut-and-paste one of the (fixed) standard DMs to their own namespace, to continue using the standard. That DM would not be 'standards-based' anymore, so that option isn't very attractive. I do not think vendors will implement multiple versions of the same YANG module in the same agent. Making this a requirement would be a show-stopper. Ignoring it and letting applications and agents break any time a version conflict is detected is not going to work either. This problem may need to be solved with a separate document that explains how YANG MUST/SHOULD/MAY be used within IETF documents. The YANG language does not need versioned imports. Let vendors figure this out on their own with extensions. In IETF data models there are some changes that must never be allowed, in order to make the standard usable. There are some practices (like description clauses) that are also required for interoperability. The way YANG is defined now, a standard YANG module does not need any revision statements, contact info, any description clauses, and any field value (like the namespace) can change at any time. I suspect the IESG might have something to say about that during their review. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 12:41: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 716B33A69A1; Tue, 24 Jun 2008 12:41: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 E694B3A681F for ; Tue, 24 Jun 2008 12:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.371, 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 9RDGq6rX7B4H for ; Tue, 24 Jun 2008 12:41:13 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 293423A6929 for ; Tue, 24 Jun 2008 12:41:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=icA5VM5IPtc2Y1/MvUjEm8yzet0dSoA0DqE3DjMJcfWfkWpJcpfyaDdbV0+NDUb/; h=Received:Message-ID:From:To: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.108] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KBEO6-0000GZ-0H for netmod@ietf.org; Tue, 24 Jun 2008 15:41:10 -0400 Message-ID: <006f01c8d632$69c6bc40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Tue, 24 Jun 2008 12:42:16 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b36f287862e6b0b5c5260fe2a3398396f4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.108 Subject: [netmod] Provisioning in anticipation of upgrade X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - Here's a use case I don't recall having been discussed here. ISP plans to issue firmware / software upgrade to a node. To minimize downtime, it wants the configuration data for the new software version to be available in EEPROM (or whatever) as soon as the new software is installed. Doing this would mean loading a configuration into the device, where that configuration would be described by a data model different from what the device supported at the moment. Perhaps it's best to simply discount it as pathological, but maybe it can help us think about what (if anything) it means to send a configuration to a device that is based on a different model from what the device actually "is". Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 12:49: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 7611F3A69A1; Tue, 24 Jun 2008 12:49: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 C39B43A69A1 for ; Tue, 24 Jun 2008 12:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 aOWL0xmnvj2p for ; Tue, 24 Jun 2008 12:49:18 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id CDC4F3A681F for ; Tue, 24 Jun 2008 12:49:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YvG1xf/pHaqq1quzzzeLnvzl3+lbtQt7Hum90nmxQkiodgXMtKIT9//tdYcNJYnH; 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.108] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KBEVx-0002jq-Ic for netmod@ietf.org; Tue, 24 Jun 2008 15:49:17 -0400 Message-ID: <007e01c8d633$8fa39e00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200806241904.m5OJ4Jkh073322@idle.juniper.net> <48614DBF.8070500@netconfcentral.com> Date: Tue, 24 Jun 2008 12:50:30 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3fd005254fd09903d0ab027bb8c97a7d2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.108 Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Tuesday, June 24, 2008 12:40 PM > Subject: Re: [netmod] Augment a grouping ... > Conformance statements give you that without requiring > an agent to support N versions of each module. Versioned imports do *not* require an agent to support "N versions of each module". They're simply "truth in advertising" about what an agent *does* support, and what needs to be done to properly implement a particular definition. However, I think this discussion does reveal the importance (from and implementation perspective) of being able to determine whether two definitions (whether different versions of "the same thing" or not) are equivalent in some interesting dimension. That's a critical part of the factoring process that allows code re-use, as well as setting the bounds of interoperability. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 12:58: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 F2FB33A6906; Tue, 24 Jun 2008 12: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 52AD53A68E4 for ; Tue, 24 Jun 2008 12:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 ei9s9WB-2f+e for ; Tue, 24 Jun 2008 12:58:19 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id CEB983A6844 for ; Tue, 24 Jun 2008 12:58:17 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Tue, 24 Jun 2008 12:57:46 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 12:58:12 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 12:58:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 12:58: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 m5OJwBx77166; Tue, 24 Jun 2008 12:58: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 m5OJtduZ073804; Tue, 24 Jun 2008 19:55:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806241955.m5OJtduZ073804@idle.juniper.net> To: Andy Bierman In-reply-to: <48614DBF.8070500@netconfcentral.com> Date: Tue, 24 Jun 2008 15:55:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jun 2008 19:58:11.0877 (UTC) FILETIME=[A1A6DD50:01C8D634] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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: >Conformance statements give you that without requiring >an agent to support N versions of each module. So you see conformance statements that list the value of every enumeration of every type, so that when a new one is added, apps can inspect these lists and see that my device's conformance statement doesn't list the new one? >I do not think vendors will implement multiple versions >of the same YANG module in the same agent. Making this >a requirement would be a show-stopper. If that's what the spec says, and what the WG decides, I think it'll be implemented. Any technology that is oriented toward networks and network management that doesn't have the flexibility to allow specs to evolve is dead. What we're trying to make with YANG (and NETCONF) is a plumbing mechanism that one can build one's products around, so that this isn't code at some far corner of the source code, but a reasonable way to support the entire product. YANG-based infrastructure gives us this. If YANG modules are dead, we might as well be written them in Latin. And yes, I'm sure the IESG has a "no Latin" policy. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 13:01: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 71EF13A68E4; Tue, 24 Jun 2008 13:01: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 235A63A68E4 for ; Tue, 24 Jun 2008 13:01:31 -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 jkBEy0H348gS for ; Tue, 24 Jun 2008 13:01:30 -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 713D63A682A for ; Tue, 24 Jun 2008 13:01:30 -0700 (PDT) Received: (qmail 51685 invoked from network); 24 Jun 2008 20:01:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2008 20:01:22 -0000 X-YMail-OSG: P_1HhfYVM1lWHF4xbx_S.djUw7tRHSl6NNt68sOFYVk1UdoZ0.smqbmDhadTsmx85kH17FYrJFxF8DU18bAW6V1QP6pf5ijkGsc8QMc5e.WKMed3Cqo2TtdTvB8TdKeLEEc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48615290.8030605@netconfcentral.com> Date: Tue, 24 Jun 2008 13:01:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <200806241904.m5OJ4Jkh073322@idle.juniper.net> <48614DBF.8070500@netconfcentral.com> <007e01c8d633$8fa39e00$6801a8c0@oemcomputer> In-Reply-To: <007e01c8d633$8fa39e00$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Phil Shafer" >> Cc: >> Sent: Tuesday, June 24, 2008 12:40 PM >> Subject: Re: [netmod] Augment a grouping > ... >> Conformance statements give you that without requiring >> an agent to support N versions of each module. > > Versioned imports do *not* require an agent to support "N versions > of each module". They're simply "truth in advertising" about what > an agent *does* support, and what needs to be done to properly > implement a particular definition. > You are right. It would not be as clean as complete identifiable versions. It would be the intersection of the changed imported and augmented symbols as they ripple from the top module through all imports, nested imports, submodules, and nested submodules. Not every construct changes in every release of course, so it is only an arbitrary subset that one needs to deal with, which doesn't help the code design at all. In SNMP, only the typedef is reusable, and allowed to change only in backward-compatible ways. So 1 instance of the fooObject may allow 1..10 and a newer instance of the fooObject may allow 1..5 instead. That seems much more tractable than arbitrary object changes (add, remove, modify) for any given subtree in the configuration, within the same agent. Of course, the RPC methods and notifications can have multiple versions as well. > However, I think this discussion does reveal the importance (from > and implementation perspective) of being able to determine whether > two definitions (whether different versions of "the same thing" or not) > are equivalent in some interesting dimension. That's a critical part > of the factoring process that allows code re-use, as well as setting > the bounds of interoperability. > > Randy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 13:05: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 E56F23A68E4; Tue, 24 Jun 2008 13:05: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 05A8C3A68E4 for ; Tue, 24 Jun 2008 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-yWI2aFMGNs for ; Tue, 24 Jun 2008 13:05:01 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 2D4763A6868 for ; Tue, 24 Jun 2008 13:05:01 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id BB3EF1B80C5; Tue, 24 Jun 2008 22:05:01 +0200 (CEST) Date: Tue, 24 Jun 2008 22:05:23 +0200 (CEST) Message-Id: <20080624.220523.163153757.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48614DBF.8070500@netconfcentral.com> References: <200806241904.m5OJ4Jkh073322@idle.juniper.net> <48614DBF.8070500@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > If they happen to use 2 incompatible standard modules > (via imports ripple), then they are stuck. They have > to cut-and-paste one of the (fixed) standard DMs to their own > namespace, to continue using the standard. That DM > would not be 'standards-based' anymore, so that option > isn't very attractive. > > I do not think vendors will implement multiple versions > of the same YANG module in the same agent. Although I'm still not convinced that versioned imports is a good idea, I don't think that this particular issue is a problem. The agent will have to advertise one version for which it implements the data definition statements, rpcs and notifications. But if some other modules reuse typedefs and groupings, the agent just implements those types (as it does with other types). BTW, we I think we should state that a server advertises a module in the hello message only if it implements data definition statements, rpc, or notifications from that module. No need to advertise e.g. yang-types. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 13:08: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 A05453A69A1; Tue, 24 Jun 2008 13:08: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 A1E063A69E9 for ; Tue, 24 Jun 2008 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 GO2ULdQ+0MbS for ; Tue, 24 Jun 2008 13:08:20 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 747513A6868 for ; Tue, 24 Jun 2008 13:08:19 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 24 Jun 2008 13:07:48 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 13:07:49 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 13:07:49 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 13:03:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5OK36x79461; Tue, 24 Jun 2008 13:03:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5OK0YoJ073863; Tue, 24 Jun 2008 20:00:34 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806242000.m5OK0YoJ073863@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <006f01c8d632$69c6bc40$6801a8c0@oemcomputer> Date: Tue, 24 Jun 2008 16:00:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jun 2008 20:03:06.0723 (UTC) FILETIME=[5164CB30:01C8D635] Cc: netmod@ietf.org Subject: Re: [netmod] Provisioning in anticipation of upgrade X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Randy Presuhn" writes: >Doing this would >mean loading a configuration into the device, where that >configuration would be described by a data model different >from what the device supported at the moment. This is turn would mean the device couldn't grok anything about the incoming config and would just write it off in the startup config with zero checks. When the device boots, the new sw sees the new config. Given that the device can't enforce any rules on this new config, it sounds like a distinct but odd case. In practice, leaving unknown config for a device to see on its next boot is a fairly dangerous thing. There's little or no error recovery. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 13: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 EF8C528C0EA; Tue, 24 Jun 2008 13: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 D68CB28C0E0 for ; Tue, 24 Jun 2008 13:17:06 -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 OnSKMbdLJM9C for ; Tue, 24 Jun 2008 13:17:06 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 2BBF128C0DD for ; Tue, 24 Jun 2008 13:17:06 -0700 (PDT) Received: (qmail 17181 invoked from network); 24 Jun 2008 20:17:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2008 20:17:06 -0000 X-YMail-OSG: o2rETn8VM1lwRFEoIepJSO3CcZ7k7VFNFkX8wk9U0VdflTrAcb2.aUlvA5m_._rwiBfnD7qGCgCtRYbaJKdU.vTAYKD4LwuMdD61poRZDgtYJcu49F5VBlmQslaAmCBrPAk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48615640.8010207@netconfcentral.com> Date: Tue, 24 Jun 2008 13:17:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <200806241904.m5OJ4Jkh073322@idle.juniper.net> <48614DBF.8070500@netconfcentral.com> <20080624.220523.163153757.mbj@tail-f.com> In-Reply-To: <20080624.220523.163153757.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org 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: >> If they happen to use 2 incompatible standard modules >> (via imports ripple), then they are stuck. They have >> to cut-and-paste one of the (fixed) standard DMs to their own >> namespace, to continue using the standard. That DM >> would not be 'standards-based' anymore, so that option >> isn't very attractive. >> >> I do not think vendors will implement multiple versions >> of the same YANG module in the same agent. > > Although I'm still not convinced that versioned imports is a good > idea, I don't think that this particular issue is a problem. > > The agent will have to advertise one version for which it implements > the data definition statements, rpcs and notifications. But if some > other modules reuse typedefs and groupings, the agent just implements > those types (as it does with other types). > > BTW, we I think we should state that a server advertises a module in > the hello message only if it implements data definition statements, > rpc, or notifications from that module. No need to advertise > e.g. yang-types. I disagree. If the yang-types module changes over time, and m1 imports yang-types.v1 and m2 imports yang-types.v2, and m3 imports m1 and m2. Juergen pointed out that if the 'delta' module is owned by another organization, your module (e.g., m3) is broken until that organization removes the delta (e.g., update m1 to use yang-types.v2). > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 13:34: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 B70843A68CA; Tue, 24 Jun 2008 13:34: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 1E56E3A68CA for ; Tue, 24 Jun 2008 13:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPPU8piNZuoe for ; Tue, 24 Jun 2008 13:34:23 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 542653A67FD for ; Tue, 24 Jun 2008 13:34:23 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 535901B80D4; Tue, 24 Jun 2008 22:34:24 +0200 (CEST) Date: Tue, 24 Jun 2008 22:34:46 +0200 (CEST) Message-Id: <20080624.223446.223301844.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48615640.8010207@netconfcentral.com> References: <48614DBF.8070500@netconfcentral.com> <20080624.220523.163153757.mbj@tail-f.com> <48615640.8010207@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > > Although I'm still not convinced that versioned imports is a good > > idea, I don't think that this particular issue is a problem. > > The agent will have to advertise one version for which it implements > > the data definition statements, rpcs and notifications. But if some > > other modules reuse typedefs and groupings, the agent just implements > > those types (as it does with other types). [...] > I disagree. > If the yang-types module changes over time, and m1 imports yang-types.v1 > and m2 imports yang-types.v2, and m3 imports m1 and m2. Juergen pointed > out that if the 'delta' module is owned by another organization, your > module (e.g., m3) is broken until that organization removes the delta > (e.g., update m1 to use yang-types.v2). My point was that it is not broken. A server that implements m3 would advertise the version it implements (as per above). The types used in m1 and m2 are well-defined and part of the normal type-chain that the server has to implement. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 16:23:42 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3439B3A6A65; Tue, 24 Jun 2008 16:23:42 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF603A6A64 for ; Tue, 24 Jun 2008 16:23:41 -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 uy1S1Z5d8HR7 for ; Tue, 24 Jun 2008 16:23:40 -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 E173D3A6A57 for ; Tue, 24 Jun 2008 16:23:40 -0700 (PDT) Received: (qmail 17110 invoked from network); 24 Jun 2008 23:23:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2008 23:23:41 -0000 X-YMail-OSG: R9grjKAVM1mGq549KtQgnPqAnFo1nN7QZH0ZW7NFJ1yPDKK4Ovz9eALVw1nALlc6jsJNrqG9KCDZGjMtQkOdcDChQGKxBWqxSEJjv2R3dsXZjNlPhGQaqo5aAxnv0fh.uKw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <486181FB.8070800@netconfcentral.com> Date: Tue, 24 Jun 2008 16:23:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <48614DBF.8070500@netconfcentral.com> <20080624.220523.163153757.mbj@tail-f.com> <48615640.8010207@netconfcentral.com> <20080624.223446.223301844.mbj@tail-f.com> In-Reply-To: <20080624.223446.223301844.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Although I'm still not convinced that versioned imports is a good >>> idea, I don't think that this particular issue is a problem. >>> The agent will have to advertise one version for which it implements >>> the data definition statements, rpcs and notifications. But if some >>> other modules reuse typedefs and groupings, the agent just implements >>> those types (as it does with other types). > > [...] > >> I disagree. >> If the yang-types module changes over time, and m1 imports yang-types.v1 >> and m2 imports yang-types.v2, and m3 imports m1 and m2. Juergen pointed >> out that if the 'delta' module is owned by another organization, your >> module (e.g., m3) is broken until that organization removes the delta >> (e.g., update m1 to use yang-types.v2). > > My point was that it is not broken. A server that implements m3 > would advertise the version it implements (as per above). The types > used in m1 and m2 are well-defined and part of the normal type-chain > that the server has to implement. > This is kind of an implementation detail, but it seems to me that if m3 imports yang-types directly, and also imports m1, that objects expanded from groupings in m1 will be using yang-types.v1, and objects expanded from groupings directly in m3 will use yang-types.v2. This aspect of groupings is not obvious, and (IMO) complicated to implement. > > /martin > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 20:52: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 2F82A3A6823; Tue, 24 Jun 2008 20:52: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 E5A3F3A6A77 for ; Tue, 24 Jun 2008 20:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 jifw1AHmGnPc for ; Tue, 24 Jun 2008 20:52:52 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 3CDB53A6814 for ; Tue, 24 Jun 2008 20:52:41 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 24 Jun 2008 20:52:41 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 20:51:23 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 20:51:22 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 20:51:22 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5P3pLx24207; Tue, 24 Jun 2008 20:51: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 m5P3mlut076404; Wed, 25 Jun 2008 03:48:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806250348.m5P3mlut076404@idle.juniper.net> To: Andy Bierman In-reply-to: <486181FB.8070800@netconfcentral.com> Date: Tue, 24 Jun 2008 23:48:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jun 2008 03:51:22.0397 (UTC) FILETIME=[BBB86CD0:01C8D676] Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.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 is kind of an implementation detail, but it seems to >me that if m3 imports yang-types directly, and also imports >m1, that objects expanded from groupings in m1 will be using >yang-types.v1, and objects expanded from groupings directly >in m3 will use yang-types.v2. This aspect of groupings >is not obvious, and (IMO) complicated to implement. Can you explain why this is more complicated? It seems like this is really just a matter of understanding that a module is uniquely described by the name plus the revision, rather than just the name. This seems pretty trivial. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 22:34: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 4C0C63A681B; Tue, 24 Jun 2008 22:34: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 884E33A681B for ; Tue, 24 Jun 2008 22:34:20 -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 2ejcOcGR8ONp for ; Tue, 24 Jun 2008 22:34:19 -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 A52613A67DD for ; Tue, 24 Jun 2008 22:34:19 -0700 (PDT) Received: (qmail 6939 invoked from network); 25 Jun 2008 05:34:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 25 Jun 2008 05:34:19 -0000 X-YMail-OSG: bzI3aq4VM1mbKY056i4mn9xJcSx5tuda3U.8dlkHb9qBE9O6FaMFAS3OocT3RoGoQOjza_pEtzpahK.XB69iBEHgMpF9pnK48G.4LISe8A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4861D8DA.4070105@netconfcentral.com> Date: Tue, 24 Jun 2008 22:34:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806250348.m5P3mlut076404@idle.juniper.net> In-Reply-To: <200806250348.m5P3mlut076404@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> This is kind of an implementation detail, but it seems to >> me that if m3 imports yang-types directly, and also imports >> m1, that objects expanded from groupings in m1 will be using >> yang-types.v1, and objects expanded from groupings directly >> in m3 will use yang-types.v2. This aspect of groupings >> is not obvious, and (IMO) complicated to implement. > > Can you explain why this is more complicated? It seems like this > is really just a matter of understanding that a module is uniquely > described by the name plus the revision, rather than just the name. > This seems pretty trivial. > I don't think it will help anymore to debate implementation details. The IETF has a lot of experience with SMIv2. I prefer the way SMIv2 handles versioning and conformance. There is one file for each module and you can derive all the versions from that file, and all the versions will be backward-compatible with each other. I guess time will tell if YANG is too complicated, and there are any deployments or not. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jun 24 23:42: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 607F33A67DD; Tue, 24 Jun 2008 23:42: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 AF78E3A67DD for ; Tue, 24 Jun 2008 23:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4xd1c6Q+stB for ; Tue, 24 Jun 2008 23:42:10 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id E3AAE3A67AB for ; Tue, 24 Jun 2008 23:42:09 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 647AB1B80C8; Wed, 25 Jun 2008 08:42:10 +0200 (CEST) Date: Wed, 25 Jun 2008 08:42:20 +0200 (CEST) Message-Id: <20080625.084220.210492649.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <486181FB.8070800@netconfcentral.com> References: <48615640.8010207@netconfcentral.com> <20080624.223446.223301844.mbj@tail-f.com> <486181FB.8070800@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] Augment a grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > This is kind of an implementation detail, but it seems to > me that if m3 imports yang-types directly, and also imports > m1, that objects expanded from groupings in m1 will be using > yang-types.v1, and objects expanded from groupings directly > in m3 will use yang-types.v2. This aspect of groupings > is not obvious, and (IMO) complicated to implement. I think this would be a natural extension to what's already there in the draft: References from inside the grouping are relative to the scope in which the grouping is defined, not where it is used. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 00:26:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383F43A67AB; Wed, 25 Jun 2008 00:26:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503E63A67AB for ; Wed, 25 Jun 2008 00:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIECEUMoNB12 for ; Wed, 25 Jun 2008 00:26:20 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 830163A677E for ; Wed, 25 Jun 2008 00:26:20 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 32BC61B80C8; Wed, 25 Jun 2008 09:26:21 +0200 (CEST) Date: Wed, 25 Jun 2008 09:26:31 +0200 (CEST) Message-Id: <20080625.092631.08203988.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200806231539.m5NFdTPk061607@idle.juniper.net> References: <200806231539.m5NFdTPk061607@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] augment a leaf? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > MODsters, > > So should I be able to augment a leaf? Currently, I don't think > this is possible, but there are a number of circumstances where > it would be useful, such as: > > - allow access to i18n/translation strings > - allow gui apps to augment with custom display info > - allow vendors to attach info needed for CLI display This seems to something different than the current meaning of 'augment'. I think you want to attach vendor-specific information to a standard module. IMO this is an implementation (or vendor specific) issue. This is something that I need to support as well, and we already support it for our proprietary DML. We do this through "annotation files", where we attach implementation specific stuff to the schema tree, like in your example. My plan for YANG is to use the "overlay" technique that I mentioned in the thread about implementation specific defaults. > Something like: > > augment ietf-bgp:group/ietf-bgp:peer/ietf-bgp:as { > junos:populate-with protocols/bgp/group/peer/as-number; > junos:i18n I18N_BGP_AS; > junos:gui-hint display-as-dotted-number; > } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 08:08: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 1B2B43A6A48; Wed, 25 Jun 2008 08:08: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 CA04F3A6A38 for ; Wed, 25 Jun 2008 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLKUW0OuixzD for ; Wed, 25 Jun 2008 08:08:22 -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 442A53A6A5B for ; Wed, 25 Jun 2008 08:08:22 -0700 (PDT) Received: (qmail 11486 invoked from network); 25 Jun 2008 15:08:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 25 Jun 2008 15:08:18 -0000 X-YMail-OSG: f_Fv19IVM1lDY0hsp4EH8WNqWJ3iUR3MuTrMBexnslv3gqdFG76roB2OUa6r81hq4Cjsi4Jc1VkI6MM8FQUyroJnZGCKXUgc5j1Izzj6KQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48625F60.5010908@netconfcentral.com> Date: Wed, 25 Jun 2008 08:08:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <200806231539.m5NFdTPk061607@idle.juniper.net> <20080625.092631.08203988.mbj@tail-f.com> In-Reply-To: <20080625.092631.08203988.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] augment a leaf? X-BeenThere: netmod@ietf.org 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: > Phil Shafer wrote: >> MODsters, >> >> So should I be able to augment a leaf? Currently, I don't think >> this is possible, but there are a number of circumstances where >> it would be useful, such as: >> >> - allow access to i18n/translation strings >> - allow gui apps to augment with custom display info >> - allow vendors to attach info needed for CLI display > > This seems to something different than the current meaning of > 'augment'. I think you want to attach vendor-specific information to > a standard module. IMO this is an implementation (or vendor specific) > issue. > This feature is exactly what 'extension' provides, not 'augment'. But this must be inline with the YANG module, not remote and certainly not a 1-of-N choice of extensions. > This is something that I need to support as well, and we already > support it for our proprietary DML. We do this through "annotation > files", where we attach implementation specific stuff to the schema > tree, like in your example. My plan for YANG is to use the "overlay" > technique that I mentioned in the thread about implementation specific > defaults. I like your 'extension overlay' idea. This has great potential for platform-specific mappings, callback registries, error registries, etc. IMO, it is worth considering this as part of the standard. We can never hope to configure or monitor everything with standards. The goal of a standard is to "do common things in common ways". NM costs more than it should because there aren't enough mechanisms to auto-magically 'plug the holes' in an API for all the non-standard bits. It seems to me no new syntax is needed, but rather an algorithm to apply an overlay to a module, which seems rather trivial. (The hard work is implementing the various extensions contained in the overlay. There may need to be protocol extensions, like a verb to allow an operator to apply an i18n overlay of their choice to the internal NETCONF error message registry. > >> Something like: >> >> augment ietf-bgp:group/ietf-bgp:peer/ietf-bgp:as { >> junos:populate-with protocols/bgp/group/peer/as-number; >> junos:i18n I18N_BGP_AS; >> junos:gui-hint display-as-dotted-number; >> } > > > /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 08:19:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0463A6978; Wed, 25 Jun 2008 08:19:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1FE3A6978 for ; Wed, 25 Jun 2008 08:19:44 -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.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNg1TvBezzCt for ; Wed, 25 Jun 2008 08:19:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 82A583A6911 for ; Wed, 25 Jun 2008 08:19:43 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10024C0057; Wed, 25 Jun 2008 17:19:41 +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-262TBzeFau; Wed, 25 Jun 2008 17:19:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40500C0052; Wed, 25 Jun 2008 17:19:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B4C015DEE5A; Wed, 25 Jun 2008 17:19:33 +0200 (CEST) Date: Wed, 25 Jun 2008 17:19:33 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080625151933.GB29347@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <200806231539.m5NFdTPk061607@idle.juniper.net> <20080625.092631.08203988.mbj@tail-f.com> <48625F60.5010908@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48625F60.5010908@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] augment a leaf? 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, Jun 25, 2008 at 08:08:16AM -0700, Andy Bierman wrote: > This feature is exactly what 'extension' provides, not 'augment'. > But this must be inline with the YANG module, not remote and > certainly not a 1-of-N choice of extensions. An 'extension' defines a new language construct; an augment defines something that logically belongs somewhere else, e.g. into a standard module you should not touch. Both things are needed and they do quite different things. > I like your 'extension overlay' idea. This has great potential for > platform-specific mappings, callback registries, error registries, > etc. IMO, it is worth considering this as part of the standard. I first need to understand in more detail how this idea is going to work before I can like it so much to believe it should be part of a standard. Perhaps Martin can start a separate thread with a more concrete proposal how "extension overlays" are supposed to work. /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 Jun 25 09:16: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 7A9223A6899; Wed, 25 Jun 2008 09:16: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 91B6D3A6899 for ; Wed, 25 Jun 2008 09:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 SPOfeGjt6vHP for ; Wed, 25 Jun 2008 09:16:16 -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 A62323A67AB for ; Wed, 25 Jun 2008 09:16:16 -0700 (PDT) Received: (qmail 50649 invoked from network); 25 Jun 2008 16:16:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 25 Jun 2008 16:16:16 -0000 X-YMail-OSG: 5I.wnR4VM1l5rlQIlrSSLn7D7pL9Apqbacj3lajStzA_ejkWbZpwWQ0q9RKtukhSiuvM7uukho5e8XJab943f04oOcUVou0vRA9QX9mgdQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48626F4E.2000204@netconfcentral.com> Date: Wed, 25 Jun 2008 09:16:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <200806231539.m5NFdTPk061607@idle.juniper.net> <20080625.092631.08203988.mbj@tail-f.com> <48625F60.5010908@netconfcentral.com> <20080625151933.GB29347@elstar.local> In-Reply-To: <20080625151933.GB29347@elstar.local> Subject: Re: [netmod] augment a leaf? X-BeenThere: netmod@ietf.org 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, Jun 25, 2008 at 08:08:16AM -0700, Andy Bierman wrote: > >> This feature is exactly what 'extension' provides, not 'augment'. >> But this must be inline with the YANG module, not remote and >> certainly not a 1-of-N choice of extensions. > > An 'extension' defines a new language construct; an augment defines > something that logically belongs somewhere else, e.g. into a standard > module you should not touch. Both things are needed and they do quite > different things. > I meant the specific list like i18n translation strings. These are not part of YANG. You would need to define an extension for this. As for the overlay, I suppose any construct could be in the overlay, so it is like augment-stmt in that respect. >> I like your 'extension overlay' idea. This has great potential for >> platform-specific mappings, callback registries, error registries, >> etc. IMO, it is worth considering this as part of the standard. > > I first need to understand in more detail how this idea is going to > work before I can like it so much to believe it should be part of a > standard. Perhaps Martin can start a separate thread with a more > concrete proposal how "extension overlays" are supposed to work. > I said 'consider' not 'include', which just means discuss it on the mailing list. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 11:48: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 2D1973A6ACA; Wed, 25 Jun 2008 11:48: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 A02233A6ACA for ; Wed, 25 Jun 2008 11:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 GtOW2AZbyXke for ; Wed, 25 Jun 2008 11:48:33 -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 DE6B83A6A32 for ; Wed, 25 Jun 2008 11:48:33 -0700 (PDT) Received: (qmail 59020 invoked from network); 25 Jun 2008 18:48:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 25 Jun 2008 18:48:31 -0000 X-YMail-OSG: J_w_kaAVM1msb_.CqoMoX.dx7JfeD.xKplw4ybQ0ELCbEgmWYgKZK1r18qw4AFM7n8b8qMbKAmVhbnj2un7w58nYkauzvTlxtaK9i4N_sCZvkFISUVqmdoGbHLOdlb68jf4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <486292FD.8050900@netconfcentral.com> Date: Wed, 25 Jun 2008 11:48:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund , netmod@ietf.org References: <20080616.113122.210899146.mbj@tail-f.com> <20080616134614.GA3608@elstar.local> <20080623.102947.71614638.mbj@tail-f.com> <20080624103110.GA26158@elstar.local> In-Reply-To: <20080624103110.GA26158@elstar.local> Subject: Re: [netmod] comments on draft-schoenw-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Jun 23, 2008 at 10:29:47AM +0200, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Mon, Jun 16, 2008 at 11:31:22AM +0200, Martin Bjorklund wrote: >>>> A comment on the ipv4 address, which contains an optional zone index. >>>> Do we need to specify the expected behavior when a server does not >>>> support zone index for a particular object? >>> This might depend on the particular circumstances of the usage of this >>> object. Do you have a concrete proposal? >> Maybe say that if the object does not support zones, the error-tag >> 'invalid-value' should be used. (or maybe 'bad-element'; it's not >> clear to me when 'bad-element'/'bad-attribute' vs. 'invalid-value' >> should be used). >> >> Can you elaborate on the particular circumstances that could affect >> the error message? > > I also have trouble to understand which RFC4741 error tag is for which > purpose. Perhaps Andy can shed some light on this... > application operation-not-supported error Zone index encoding not supported. invalid-value is not correct when the value is valid for the leaf syntax, as defined in the data model. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 12:24: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 A1A913A6A6A; Wed, 25 Jun 2008 12:24: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 2EBA23A6A6A for ; Wed, 25 Jun 2008 12:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NxMSQGZWWXi for ; Wed, 25 Jun 2008 12:24:47 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 392703A6A32 for ; Wed, 25 Jun 2008 12:24:47 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 59C2C1B80D5; Wed, 25 Jun 2008 21:24:47 +0200 (CEST) Date: Wed, 25 Jun 2008 21:25:12 +0200 (CEST) Message-Id: <20080625.212512.154553784.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <486292FD.8050900@netconfcentral.com> References: <20080623.102947.71614638.mbj@tail-f.com> <20080624103110.GA26158@elstar.local> <486292FD.8050900@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] comments on draft-schoenw-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: , 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: > > application > operation-not-supported > error > Zone index encoding not supported. > I would never have guessed 'operation-not-supported'! The term "operation" is used for two things in rfc4741; as the "rpc operation" (e.g. get-config), and also as the edit-config inline operations (e.g. 'merge'). So I would think that this error is returned e.g. if someone tries to do an edit-config towards running, and :writeble-running is not advertised. > invalid-value is not correct when the value is valid > for the leaf syntax, as defined in the data model. invalid-value is defined as The request specifies an unacceptable value for one or more parameters. It's not obvious to me that "unacceptable value" only covers syntax checks. If we ever do a revised 4741, I think more text should be added re. the error codes. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 12:53: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 5EC673A6898; Wed, 25 Jun 2008 12:53: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 6817A3A69AC for ; Wed, 25 Jun 2008 12:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.367, 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 sTBJC8aJ1IpD for ; Wed, 25 Jun 2008 12:53: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 1A7823A6898 for ; Wed, 25 Jun 2008 12:53:16 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 277DDC0059; Wed, 25 Jun 2008 21:53:18 +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 yjun6Jz4JIYP; Wed, 25 Jun 2008 21:53:12 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C8C8C0042; Wed, 25 Jun 2008 21:53:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DC0AB5DF399; Wed, 25 Jun 2008 21:53:10 +0200 (CEST) Date: Wed, 25 Jun 2008 21:53:10 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080625195310.GB29719@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <20080623.102947.71614638.mbj@tail-f.com> <20080624103110.GA26158@elstar.local> <486292FD.8050900@netconfcentral.com> <20080625.212512.154553784.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080625.212512.154553784.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-schoenw-netmod-yang-types-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Jun 25, 2008 at 09:25:12PM +0200, Martin Bjorklund wrote: > Andy Bierman wrote: > > > > application > > operation-not-supported > > error > > Zone index encoding not supported. > > > > I would never have guessed 'operation-not-supported'! So do I. > The term "operation" is used for two things in rfc4741; as the "rpc > operation" (e.g. get-config), and also as the edit-config inline > operations (e.g. 'merge'). Yes, that is bad. Terminology is not really consistent in RFC 4741. > > invalid-value is not correct when the value is valid > > for the leaf syntax, as defined in the data model. > > invalid-value is defined as > > The request specifies an unacceptable value for one > or more parameters. > > It's not obvious to me that "unacceptable value" only covers syntax > checks. Same here. > If we ever do a revised 4741, I think more text should be added > re. the error codes. Yes. And we have to find consistent terminology at the same time and make sure the document is consistent in the use of terms. /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 Jun 25 13:29:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A376D28C15E; Wed, 25 Jun 2008 13:29:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2434728C15D for ; Wed, 25 Jun 2008 13:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 F+0bRyrMn9iw for ; Wed, 25 Jun 2008 13:28:59 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 72F0728C15A for ; Wed, 25 Jun 2008 13:28:59 -0700 (PDT) Received: (qmail 56032 invoked from network); 25 Jun 2008 20:29:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 25 Jun 2008 20:29:00 -0000 X-YMail-OSG: 467uRQ8VM1lClulYq7FQvyLGCHlGpZ1wU_qi3BPCGJas0lbfDJhcSoe3LGP0xIgqKAZU_pPqh6xHjGJlKPjQXoST2aUPrQ6a1JR1y_D0HuDaYqi4DKHtybZzz.jxa5uGlR8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4862AA89.3010007@netconfcentral.com> Date: Wed, 25 Jun 2008 13:28:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund , andy@netconfcentral.com, netmod@ietf.org References: <20080623.102947.71614638.mbj@tail-f.com> <20080624103110.GA26158@elstar.local> <486292FD.8050900@netconfcentral.com> <20080625.212512.154553784.mbj@tail-f.com> <20080625195310.GB29719@elstar.local> In-Reply-To: <20080625195310.GB29719@elstar.local> Subject: Re: [netmod] comments on draft-schoenw-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: , 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, Jun 25, 2008 at 09:25:12PM +0200, Martin Bjorklund wrote: > >> Andy Bierman wrote: >>> >>> application >>> operation-not-supported >>> error >>> Zone index encoding not supported. >>> >> I would never have guessed 'operation-not-supported'! > > So do I. > That was the intent of allowing 'application layer operation' not supported. I guess bad-element could apply. I agree the terminology is bad. Andy >> The term "operation" is used for two things in rfc4741; as the "rpc >> operation" (e.g. get-config), and also as the edit-config inline >> operations (e.g. 'merge'). > > Yes, that is bad. Terminology is not really consistent in RFC 4741. > >>> invalid-value is not correct when the value is valid >>> for the leaf syntax, as defined in the data model. >> invalid-value is defined as >> >> The request specifies an unacceptable value for one >> or more parameters. >> >> It's not obvious to me that "unacceptable value" only covers syntax >> checks. > > Same here. > >> If we ever do a revised 4741, I think more text should be added >> re. the error codes. > > Yes. And we have to find consistent terminology at the same time and > make sure the document is consistent in the use of terms. > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 13:42: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 574083A6AC8; Wed, 25 Jun 2008 13:42: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 834683A6AC8 for ; Wed, 25 Jun 2008 13:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzNsE-EYabKf for ; Wed, 25 Jun 2008 13:42:24 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 9E4CB3A6919 for ; Wed, 25 Jun 2008 13:42:24 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id BB5CA1B80C8 for ; Wed, 25 Jun 2008 22:42:24 +0200 (CEST) Date: Wed, 25 Jun 2008 22:42:50 +0200 (CEST) Message-Id: <20080625.224250.89223041.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] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Starting a new thread for the overlay discussion. I want to solve the same problem as Phil, i.e. being able to attach vendor-specific implementation directives to standard modules, w/o actually having to modify the standard module text. My original idea was to use annotation files for this, where these files would be applied as overlays to the original module. For example: Given this standard module: module ietf-interface { namespace "urn:ietf:params:xml:ns:interface"; prefix if; ... container interfaces { list interface { key name; leaf name { type string; } leaf mtu { type uint32; } ... } } } I could write an annotation file (my-interface.ann) like this: annotation ietf-interface { // add an import of the vendor-specific extensions import tailf-extensions { prefix tailf; } container interface { list interface { // add an important implementation detail tailf:callpoint my-cp; } } } Then I would give this information to my YANG compiler: # pyang --emit-code ietf-interface.yang --annotation my-interface.ann Annotations file can cascade, so I can have one annotation file with CLI-hints, one with code generation hints and so on. Or put everything in one file. This was supposed to be completely proprietary. But I think the same idea can be useful to specify implementation-specific defaults. Something like this: annotation ietf-interface { container interface { list interface { leaf mtu { // add a product-specific default default 1500; } } } } This would require some changes to the current YANG semantics (can I add a default value to a mandatory leaf?) and for it to be useful, a manager MUST be able to get this information, e.g. by using the schema discovery mechanism. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 15:27: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 BA29A3A68ED; Wed, 25 Jun 2008 15:27: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 B30FE3A68ED for ; Wed, 25 Jun 2008 15:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, 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 r5XlVmHlLNCZ for ; Wed, 25 Jun 2008 15:27:37 -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 B338D3A680C for ; Wed, 25 Jun 2008 15:27:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ASVmEAKkBG3oSyridb1V3yg26s9M/k8x+6d2uK7zpKwMSJE295qYbGW39fBwnEQ0; 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.35.186] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KBdSj-0008Tl-SI for netmod@ietf.org; Wed, 25 Jun 2008 18:27:38 -0400 Message-ID: <001101c8d712$dea07520$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080625.224250.89223041.mbj@tail-f.com> Date: Wed, 25 Jun 2008 15:29: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b335ab9968ee81285e1a5e82f614ea5432350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.186 Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > Sent: Wednesday, June 25, 2008 1:42 PM > Subject: [netmod] overlays ... > This would require some changes to the current YANG semantics (can I > add a default value to a mandatory leaf?) and for it to be useful, a > manager MUST be able to get this information, e.g. by using the schema > discovery mechanism. ... I like the general concept a lot. It was one of the things I found most interesting about the the work Alex Clemm and TJ Tjong had done leading up to the canmod BOF. At a previous company, we got a lot of experience using different annotation strategies with our GDMO and SNMP SMI MIB compilers. A few conclusions I've reached: (1) For software (release) configuration management sanity, it is essential to be able to keep annotations separate from the annotated material. (2) If the annotation in any way changes the "interface contract" represented, it is essential to be able to treat this as a distinct contract (= class definition or whatever) even if it is allomorphic to the original definition. (this means, for example, being able to retrieve the modified interface definition) (3) Having "chains" of refinement, while perhaps theoretically elegant, can be a maintenance pain. It's ultimately easier to derive different versions of a definition from the same base definition, than working back through a chain of versions to reach that base. This is particularly true if an organization does development work on multiple releases concurrently. (4) It's important to separate annotations that elaborate on the "interface contract" from the ones that elaborate on the implementation. (5) It's important to think through annotations for IMPORTed bits very carefully. In our particular case, we encountered situations where instrumentation from different vendors meant that "the same" bit of management information in different contexts on a single system required different annotations. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 23:39:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947DA3A6832; Wed, 25 Jun 2008 23:39:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9CC3A6832 for ; Wed, 25 Jun 2008 23:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 rPPL3nE4-GXj for ; Wed, 25 Jun 2008 23:39:45 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id F38153A6826 for ; Wed, 25 Jun 2008 23:39:42 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 25 Jun 2008 23:39:21 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 23:37:53 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 23:37:52 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 23:36: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 m5Q6a0x23527; Wed, 25 Jun 2008 23:36:00 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5Q6XRBE085859; Thu, 26 Jun 2008 06:33:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806260633.m5Q6XRBE085859@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080625.224250.89223041.mbj@tail-f.com> Date: Thu, 26 Jun 2008 02:33:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Jun 2008 06:36:00.0916 (UTC) FILETIME=[E6308D40:01C8D756] Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: > annotation ietf-interface { > > // add an import of the vendor-specific extensions > import tailf-extensions { > prefix tailf; > } > > container interface { > > list interface { > // add an important implementation detail > tailf:callpoint my-cp; > } > } > } This gives two distinct "container" statements, one in real YANG and one in annotations. What would you think of using an augmentation-like approach: annotation ietf-interface { import tailf-extensions { ... } annotate "interface/interface" { // add an important implementation detail tailf:callpoint my-cp; } } Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jun 25 23:45: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 7E3A128B797; Wed, 25 Jun 2008 23:45: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 708963A6840 for ; Wed, 25 Jun 2008 23:45:11 -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 oAaOJ+uNj8UB for ; Wed, 25 Jun 2008 23:45:07 -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 6D5C83A6825 for ; Wed, 25 Jun 2008 23:45:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VzNIWJ5n/6skVnB13WIrg7bgrViQR0mtaHIeHMDH6VDccp7h7LaJxoJuusECq787; 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.188.177] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KBlEB-0005UY-EX for netmod@ietf.org; Thu, 26 Jun 2008 02:45:07 -0400 Message-ID: <000401c8d758$5e76d880$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200806260633.m5Q6XRBE085859@idle.juniper.net> Date: Wed, 25 Jun 2008 23:46:31 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3415f6cd8465bc2c9ae5c3e96a913af57350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.177 Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Martin Bjorklund" > Cc: > Sent: Wednesday, June 25, 2008 11:33 PM > Subject: Re: [netmod] overlays ... > This gives two distinct "container" statements, one in > real YANG and one in annotations. What would you think > of using an augmentation-like approach: ... Yet another way of looking at the problem is to consider the annotation as a transform applied to one model to produce another. The kinds of transform that are possible set the limits of what can be considered in some sense to be "compatible" models. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 00:21: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 685D13A68B1; Thu, 26 Jun 2008 00:21: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 04FFE3A687A for ; Thu, 26 Jun 2008 00:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4peLJIpk4p0 for ; Thu, 26 Jun 2008 00:21:19 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id B3D483A6832 for ; Thu, 26 Jun 2008 00:21:18 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 637391B80CD; Thu, 26 Jun 2008 09:21:20 +0200 (CEST) Date: Thu, 26 Jun 2008 09:21:31 +0200 (CEST) Message-Id: <20080626.092131.225956908.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200806260633.m5Q6XRBE085859@idle.juniper.net> References: <20080625.224250.89223041.mbj@tail-f.com> <200806260633.m5Q6XRBE085859@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] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: > > annotation ietf-interface { > > > > // add an import of the vendor-specific extensions > > import tailf-extensions { > > prefix tailf; > > } > > > > container interface { > > > > list interface { > > // add an important implementation detail > > tailf:callpoint my-cp; > > } > > } > > } > > This gives two distinct "container" statements, one in > real YANG and one in annotations. Yes, just like it's currently being done in 'uses' refinements. (but then we might want to change that). > What would you think > of using an augmentation-like approach: > > annotation ietf-interface { > > import tailf-extensions { ... } > > annotate "interface/interface" { > // add an important implementation detail > tailf:callpoint my-cp; > } > } This is the strategy we currently use in our proprietary DML. The disadvantage is that it becomes clumsy and error-prone if you have many annotations: annotate "interface/interface" { tailf:callpoint my-cp; } annotate "interface/interface/mtu" { tailf:display-hint "..."; } annotate "interface/interface/unit" { tailf:callpoint my-cp2; } annotate "interface/interface/unit/vlan-id" { tailf:display-hit "..."; } ... Maybe a hybrid scheme would work: annotate "interface/interface" { tailf:callpoint my-cp; annotate mtu { tailf:display-hint "..."; } annotate unit { annotate vlan-id { ... } } } Hmmm I like this for the same reasons that I like an explicit 'refine' statement in 'uses'. With the "overlay" method (for annotations and refinements), both the syntax and semantics for a particular statement is different depending on context. For example: uses my-grouping { container foo { default 17; } } The 'container' statement in 'uses' does not mean the same thing as it does outside 'uses' - outside it creates a new container, inside it modifies an existing one. And syntax-wise, the substatements that are allowed in 'container' is different inside and outside the 'uses'. With such an 'annotate' statement, everything can be put into a normal module: module my-interface-annotations { import ietf-interface { ... } import tailf-extensions { ... } annotate /if:interfaces/if:interface { ... } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 00:41: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 1544328C108; Thu, 26 Jun 2008 00:41: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 CBD6F28C108 for ; Thu, 26 Jun 2008 00:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmiAC3aWTjBQ for ; Thu, 26 Jun 2008 00:41:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6A58428C104 for ; Thu, 26 Jun 2008 00:41:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CEF1FC0054; Thu, 26 Jun 2008 09:41: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 bMC-4De61hsc; Thu, 26 Jun 2008 09:41:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D6F1C0039; Thu, 26 Jun 2008 09:41:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A41C55DFAF7; Thu, 26 Jun 2008 09:41:45 +0200 (CEST) Date: Thu, 26 Jun 2008 09:41:45 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080626074145.GF272@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20080625.224250.89223041.mbj@tail-f.com> <200806260633.m5Q6XRBE085859@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200806260633.m5Q6XRBE085859@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] overlays 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, Jun 26, 2008 at 02:33:27AM -0400, Phil Shafer wrote: > Martin Bjorklund writes: > > annotation ietf-interface { > > > > // add an import of the vendor-specific extensions > > import tailf-extensions { > > prefix tailf; > > } > > > > container interface { > > > > list interface { > > // add an important implementation detail > > tailf:callpoint my-cp; > > } > > } > > } > > This gives two distinct "container" statements, one in > real YANG and one in annotations. What would you think > of using an augmentation-like approach: > > annotation ietf-interface { > > import tailf-extensions { ... } > > annotate "interface/interface" { > // add an important implementation detail > tailf:callpoint my-cp; > } > } We had this at some point in SMIng but it got dropped in the published version. Note that you can use the normal module framework with this approach - no need for "annotation" to start the module. While more verbose for large modules, I find the "annotate" statement approach nicer because it allows me to cut&paste an annotation without loosing the context what precisely is being annotated. /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 Jun 26 04:53: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 245E33A67ED; Thu, 26 Jun 2008 04:53: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 D864F3A67ED for ; Thu, 26 Jun 2008 04:53:50 -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 ixjtl29heZxH for ; Thu, 26 Jun 2008 04:53:47 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B72A23A67AE for ; Thu, 26 Jun 2008 04:53:46 -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 1FF48D800CB for ; Thu, 26 Jun 2008 13:53:49 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080625.224250.89223041.mbj@tail-f.com> References: <20080625.224250.89223041.mbj@tail-f.com> Organization: CESNET Date: Thu, 26 Jun 2008 13:53:49 +0200 Message-Id: <1214481229.6293.72.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SGkgTWFydGluLAoKdGhlIHNpbXBsZXN0IHBvc3NpYmxlIGFwcHJvYWNoIC0gYW5kIG9uZSB0aGF0 IHdvcmtzIHByZXR0eSB3ZWxsIGZvciBtZQppbiB0aGUgUkVMQVggTkcgY29udGV4dCAtIGlzIHRv IHNwZWNpZnkgdGhhdCBzdGF0ZW1lbnRzIHdpdGggZm9yZWlnbgpuYW1lc3BhY2VzIE1BWSBiZSBp Z25vcmVkIGFuZCB0aGVpciBlZmZlY3QgaXMgdW5zcGVjaWZpZWQgb24gdGhlIGdlbmVyYWwKWUFO RyBsZXZlbC4KCklmIHRoaXMgY291bGQgYmUgYWNjZXB0ZWQsIEkgd291bGQgYWxzbyB2b3RlIGZv ciByZW1vdmluZyB0aGUgZXh0ZW5zaW9uCnN0YXRlbWVudCBmcm9tIFlBTkcgLSBpdCBpcyBhY3R1 YWxseSBxdWl0ZSB3ZWFrLCBlc3NlbnRpYWxseSB0ZWxsaW5nIHRoZQpwYXJzZXIgdGhhdCBzdWNo IGEgc3ltYm9sIGV4aXN0cyBhbmQgaG93IHRvIHRyYW5zZm9ybSBpdCB0byBZSU4uIEl0CmRvZXNu J3QgcHJvdmlkZSBhbnkgc3ludGFjdGljIGNvbnN0cmFpbnRzIGFzIHRvIHdoZXJlIHRoZSBuZXcg c3RhdGVtZW50Cm1heSBhcHBlYXLvu78sIHdoYXQgYXJlIGl0cyBzdWJzdGF0ZW1lbnRzIGV0Yy4g RXh0ZW5zaW9ucyBjb3VsZCBiZSBoYW5kbGVkCmluIHRoZSBzYW1lIHdheSBhcyBhbm5vdGF0aW9u cywgYW5kIGlnbm9yZWQgYnkgZGVmYXVsdC4KCkkgYmVsaWV2ZSBpdCBpcyBtdWNoIGVhc2llciAo YW5kLCBhdCB0aGUgZW5kIG9mIHRoZSBkYXksIG5lY2Vzc2FyeQphbnl3YXkpIHRvIG1vZGlmeSB0 aGUgZ2VuZXJpYyBwYXJzZXIgdG8gdW5kZXJzdGFuZCB0aGUgYW5ub3RhdGlvbnMgYW5kCnByb3By aWV0YXJ5IGV4dGVuc2lvbnMsIHJhdGhlciB0aGF0IHRyeSB0byBpbnZlbnQgc21hcnQgZXh0ZW5z aW9uCm1lY2hhbmlzbXMgZm9yIHRoZSBnZW5lcmljIHBhcnNlci4KCkxhZGEKCk1hcnRpbiBCam9y a2x1bmQgcMOtxaFlIHYgU3QgMjUuIDA2LiAyMDA4IHYgMjI6NDIgKzAyMDA6Cj4gSGksCj4gCj4g U3RhcnRpbmcgYSBuZXcgdGhyZWFkIGZvciB0aGUgb3ZlcmxheSBkaXNjdXNzaW9uLgo+IAo+IEkg d2FudCB0byBzb2x2ZSB0aGUgc2FtZSBwcm9ibGVtIGFzIFBoaWwsIGkuZS4gYmVpbmcgYWJsZSB0 byBhdHRhY2gKPiB2ZW5kb3Itc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gZGlyZWN0aXZlcyB0byBz dGFuZGFyZCBtb2R1bGVzLCB3L28KPiBhY3R1YWxseSBoYXZpbmcgdG8gbW9kaWZ5IHRoZSBzdGFu ZGFyZCBtb2R1bGUgdGV4dC4KPiAKPiBNeSBvcmlnaW5hbCBpZGVhIHdhcyB0byB1c2UgYW5ub3Rh dGlvbiBmaWxlcyBmb3IgdGhpcywgd2hlcmUgdGhlc2UKPiBmaWxlcyB3b3VsZCBiZSBhcHBsaWVk IGFzIG92ZXJsYXlzIHRvIHRoZSBvcmlnaW5hbCBtb2R1bGUuICBGb3IKPiBleGFtcGxlOgo+IAo+ IEdpdmVuIHRoaXMgc3RhbmRhcmQgbW9kdWxlOgo+IAo+ICAgbW9kdWxlIGlldGYtaW50ZXJmYWNl IHsKPiAgICAgbmFtZXNwYWNlICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmludGVyZmFjZSI7Cj4g ICAgIHByZWZpeCBpZjsKPiAKPiAgICAgLi4uCj4gCj4gICAgIGNvbnRhaW5lciBpbnRlcmZhY2Vz IHsKPiAKPiAgICAgICBsaXN0IGludGVyZmFjZSB7Cj4gICAgICAgICBrZXkgbmFtZTsKPiAKPiAg ICAgICAgIGxlYWYgbmFtZSB7Cj4gICAgICAgICAgIHR5cGUgc3RyaW5nOwo+ICAgICAgICAgfQo+ ICAKPiAgICAgICAgIGxlYWYgbXR1IHsKPiAgICAgICAgICAgdHlwZSB1aW50MzI7Cj4gICAgICAg ICB9Cj4gCj4gICAgICAgICAuLi4KPiAgICAgICAgfQo+ICAgICAgfQo+ICAgfQo+IAo+IAo+IEkg Y291bGQgd3JpdGUgYW4gYW5ub3RhdGlvbiBmaWxlIChteS1pbnRlcmZhY2UuYW5uKSBsaWtlIHRo aXM6Cj4gCj4gICBhbm5vdGF0aW9uIGlldGYtaW50ZXJmYWNlIHsKPiAgCj4gICAgIC8vIGFkZCBh biBpbXBvcnQgb2YgdGhlIHZlbmRvci1zcGVjaWZpYyBleHRlbnNpb25zCj4gICAgIGltcG9ydCB0 YWlsZi1leHRlbnNpb25zIHsKPiAgICAgICBwcmVmaXggdGFpbGY7Cj4gICAgIH0KPiAKPiAgICAg Y29udGFpbmVyIGludGVyZmFjZSB7Cj4gIAo+ICAgICAgIGxpc3QgaW50ZXJmYWNlIHsKPiAgICAg ICAgIC8vIGFkZCBhbiBpbXBvcnRhbnQgaW1wbGVtZW50YXRpb24gZGV0YWlsCj4gICAgICAgICB0 YWlsZjpjYWxscG9pbnQgbXktY3A7Cj4gICAgICAgfQo+ICAgICB9Cj4gICB9Cj4gICAgICAgICAg Cj4gVGhlbiBJIHdvdWxkIGdpdmUgdGhpcyBpbmZvcm1hdGlvbiB0byBteSBZQU5HIGNvbXBpbGVy Ogo+IAo+ICAgIyBweWFuZyAtLWVtaXQtY29kZSBpZXRmLWludGVyZmFjZS55YW5nIC0tYW5ub3Rh dGlvbiBteS1pbnRlcmZhY2UuYW5uCj4gCj4gQW5ub3RhdGlvbnMgZmlsZSBjYW4gY2FzY2FkZSwg c28gSSBjYW4gaGF2ZSBvbmUgYW5ub3RhdGlvbiBmaWxlIHdpdGgKPiBDTEktaGludHMsIG9uZSB3 aXRoIGNvZGUgZ2VuZXJhdGlvbiBoaW50cyBhbmQgc28gb24uICBPciBwdXQKPiBldmVyeXRoaW5n IGluIG9uZSBmaWxlLgo+IAo+IFRoaXMgd2FzIHN1cHBvc2VkIHRvIGJlIGNvbXBsZXRlbHkgcHJv cHJpZXRhcnkuCj4gCj4gCj4gQnV0IEkgdGhpbmsgdGhlIHNhbWUgaWRlYSBjYW4gYmUgdXNlZnVs IHRvIHNwZWNpZnkKPiBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBkZWZhdWx0cy4gIFNvbWV0aGlu ZyBsaWtlIHRoaXM6Cj4gCj4gICBhbm5vdGF0aW9uIGlldGYtaW50ZXJmYWNlIHsKPiAKPiAgICAg Y29udGFpbmVyIGludGVyZmFjZSB7Cj4gICAgICAKPiAgICAgICBsaXN0IGludGVyZmFjZSB7Cj4g Cj4gICAgICAgICBsZWFmIG10dSB7Cj4gICAgICAgICAgIC8vIGFkZCBhIHByb2R1Y3Qtc3BlY2lm aWMgZGVmYXVsdAo+ICAgICAgICAgICBkZWZhdWx0IDE1MDA7Cj4gICAgICAgICB9Cj4gICAgICAg fQo+ICAgICB9Cj4gICB9Cj4gCj4gVGhpcyB3b3VsZCByZXF1aXJlIHNvbWUgY2hhbmdlcyB0byB0 aGUgY3VycmVudCBZQU5HIHNlbWFudGljcyAoY2FuIEkKPiBhZGQgYSBkZWZhdWx0IHZhbHVlIHRv IGEgbWFuZGF0b3J5IGxlYWY/KSBhbmQgZm9yIGl0IHRvIGJlIHVzZWZ1bCwgYQo+IG1hbmFnZXIg TVVTVCBiZSBhYmxlIHRvIGdldCB0aGlzIGluZm9ybWF0aW9uLCBlLmcuIGJ5IHVzaW5nIHRoZSBz Y2hlbWEKPiBkaXNjb3ZlcnkgbWVjaGFuaXNtLgo+IAo+IAo+IC9tYXJ0aW4KPiAKPiAgCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFp bGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6 IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jun 26 05:11: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 DA45C3A6999; Thu, 26 Jun 2008 05:11: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 447C03A6999 for ; Thu, 26 Jun 2008 05:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 CY0cGaGqT9uc for ; Thu, 26 Jun 2008 05:11:05 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id F3B283A6974 for ; Thu, 26 Jun 2008 05:11:04 -0700 (PDT) Received: (qmail 51777 invoked from network); 26 Jun 2008 12:11:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 26 Jun 2008 12:11:03 -0000 X-YMail-OSG: kMgIS.oVM1m7iBvlNcAF8rSGjXuPX2gJGA7uUtjsWI9p1.RJveO6Ex.PPV1L1kefQFrDPKpTIwE1dSr.Rb2OlvlrhLxg8.TZxyeiZ1aPRVdozukAWH4OBItSXnKifugxxVk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48638755.8060007@netconfcentral.com> Date: Thu, 26 Jun 2008 05:11:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806260633.m5Q6XRBE085859@idle.juniper.net> In-Reply-To: <200806260633.m5Q6XRBE085859@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org 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: > Martin Bjorklund writes: >> annotation ietf-interface { >> >> // add an import of the vendor-specific extensions >> import tailf-extensions { >> prefix tailf; >> } >> >> container interface { >> >> list interface { >> // add an important implementation detail >> tailf:callpoint my-cp; >> } >> } >> } > > This gives two distinct "container" statements, one in > real YANG and one in annotations. What would you think > of using an augmentation-like approach: > > annotation ietf-interface { > > import tailf-extensions { ... } > > annotate "interface/interface" { > // add an important implementation detail > tailf:callpoint my-cp; > } > } > What about nested groupings and typedefs? There is no way to identify the name of a nested typedef or grouping with Xpath because they are not in the same naming scope. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 05:46: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 B06C628C11D; Thu, 26 Jun 2008 05:46: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 5038C3A6A96 for ; Thu, 26 Jun 2008 05:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enxTq9YRbZNU for ; Thu, 26 Jun 2008 05:46:20 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 6BBC43A6AD5 for ; Thu, 26 Jun 2008 05:46: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 ESMTP id C2B431B80FD; Thu, 26 Jun 2008 14:46:02 +0200 (CEST) Date: Thu, 26 Jun 2008 14:46:14 +0200 (CEST) Message-Id: <20080626.144614.249642590.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48638755.8060007@netconfcentral.com> References: <200806260633.m5Q6XRBE085859@idle.juniper.net> <48638755.8060007@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] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > What about nested groupings and typedefs? > > There is no way to identify the name of a nested > typedef or grouping with Xpath because they are not in the same > naming scope. You are right. Maybe they should be in the same naming scope. Are there any compelling reasons for having separate naming scopes? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 07:11:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB9E3A6ACE; Thu, 26 Jun 2008 07:11:35 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3901A28C12B for ; Thu, 26 Jun 2008 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 gOw2E9Ns6wfU for ; Thu, 26 Jun 2008 07:11:33 -0700 (PDT) Received: from psmtp.com (exprod7ob113.obsmtp.com [64.18.2.178]) by core3.amsl.com (Postfix) with ESMTP id 8878B3A6ACE for ; Thu, 26 Jun 2008 07:11:31 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Thu, 26 Jun 2008 07:10:02 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 07:11:32 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 07:11:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 07:11:31 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5QEBUx78840; Thu, 26 Jun 2008 07:11:30 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5QE8vVA088074; Thu, 26 Jun 2008 14:08:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806261408.m5QE8vVA088074@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1214481229.6293.72.camel@missotis> Date: Thu, 26 Jun 2008 10:08:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Jun 2008 14:11:31.0134 (UTC) FILETIME=[8844DDE0:01C8D796] Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.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 this could be accepted, I would also vote for removing the extension >statement from YANG - it is actually quite weak, essentially telling the >parser that such a symbol exists and how to transform it to YIN. It allows the parser to know when a statement is an extension and when it's a typo. If I have an extension "junos:foo" and misspell the prefix, a compiler that understands "junos" won't see that "junss:foo" is a mistake, but will ignore it. We want to be able to catch errors at compile time. >I believe it is much easier (and, at the end of the day, necessary >anyway) to modify the generic parser to understand the annotations and >proprietary extensions, rather that try to invent smart extension >mechanisms for the generic parser. For proprietary YANG modules (and eventually for well-known extensions), putting them inline with the YANG they are part of is a big win. Asking the reader to look in two places is something we try to avoid (but is unavoidable when extending standards). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 08:02:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76E83A6904; Thu, 26 Jun 2008 08:02: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 0C8B33A6904 for ; Thu, 26 Jun 2008 08:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 T5qEwEolW316 for ; Thu, 26 Jun 2008 08:01:57 -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 B8FB83A689C for ; Thu, 26 Jun 2008 08:01:57 -0700 (PDT) Received: (qmail 27845 invoked from network); 26 Jun 2008 15:02:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 26 Jun 2008 15:01:59 -0000 X-YMail-OSG: P.NldeAVM1m6eHqo5atFOTUnlfHCUubTphLp_K8QDhr_B3yrQMANAMblvLROyRqGUsGSA0wDPrt596mqJJpVj7_3tBvGK1ES45MHOqePKkqrfuQ0_FNmNomm3mdXb1j5U4k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4863AF66.4000702@netconfcentral.com> Date: Thu, 26 Jun 2008 08:01:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <200806260633.m5Q6XRBE085859@idle.juniper.net> <48638755.8060007@netconfcentral.com> <20080626.144614.249642590.mbj@tail-f.com> In-Reply-To: <20080626.144614.249642590.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org 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: >> What about nested groupings and typedefs? >> >> There is no way to identify the name of a nested >> typedef or grouping with Xpath because they are not in the same >> naming scope. > > You are right. Maybe they should be in the same naming scope. Are > there any compelling reasons for having separate naming scopes? > I keep bringing this up: typedef foo ... grouping foo ... leaf foo ... extension foo ... It doesn't really matter what nest level the typedef or grouping is at -- /foo always refers to the accessible object (leaf foo). Phil claims that it would be too restrictive on the vendor. I keep claiming that it will useful to be able to have a unique identifier, even for non-data like typedefs and groupings. It is OK with me to reproduce the hierarchy rather than use Xpath, and not change all the naming scope rules now. > > /martin > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 08:19: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 C37073A6977; Thu, 26 Jun 2008 08:19: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 EA3E83A69BA for ; Thu, 26 Jun 2008 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 yk1ucBF6VtAk for ; Thu, 26 Jun 2008 08:19:26 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 6BDEF3A6943 for ; Thu, 26 Jun 2008 08:19:26 -0700 (PDT) Received: (qmail 63554 invoked from network); 26 Jun 2008 15:19:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 26 Jun 2008 15:19:27 -0000 X-YMail-OSG: i8kuSNIVM1mKBA5DD1iQ7If.lpxfY.4tGBbc3NRifIbWGiXFvtabH5NZH98fasXaYzVxaORnKRaYAh3YWBN5hEh7b8eZwdAhW_93ZjMD7A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4863B37E.6040206@netconfcentral.com> Date: Thu, 26 Jun 2008 08:19:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <200806260633.m5Q6XRBE085859@idle.juniper.net> <48638755.8060007@netconfcentral.com> <20080626.144614.249642590.mbj@tail-f.com> <4863AF66.4000702@netconfcentral.com> In-Reply-To: <4863AF66.4000702@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: >> Hi, >> >> Andy Bierman wrote: >>> What about nested groupings and typedefs? >>> >>> There is no way to identify the name of a nested >>> typedef or grouping with Xpath because they are not in the same >>> naming scope. >> >> You are right. Maybe they should be in the same naming scope. Are >> there any compelling reasons for having separate naming scopes? >> > > I keep bringing this up: > > typedef foo ... > > grouping foo ... > > leaf foo ... > > extension foo ... > > It doesn't really matter what nest level the typedef or grouping > is at -- /foo always refers to the accessible object (leaf foo). > Phil claims that it would be too restrictive on the vendor. > I keep claiming that it will useful to be able to have a > unique identifier, even for non-data like typedefs and groupings. > > It is OK with me to reproduce the hierarchy rather than > use Xpath, and not change all the naming scope rules now. > I think it has to be done with an overlay tree. There is absolutely no way to use Xpath to reference the sub-tree under a 'uses' or 'augment' node. (I brought up the issue of names for uses already.) >> >> /martin >> >> > > Andy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 10:24: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 148813A6A4F; Thu, 26 Jun 2008 10:24: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 D13373A6A4F for ; Thu, 26 Jun 2008 10:24:02 -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 A2v7KP0TVf6N for ; Thu, 26 Jun 2008 10:23:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BD4463A68E3 for ; Thu, 26 Jun 2008 10:23:58 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1F369D800CC; Thu, 26 Jun 2008 19:24:01 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200806261408.m5QE8vVA088074@idle.juniper.net> References: <200806261408.m5QE8vVA088074@idle.juniper.net> Organization: CESNET Date: Thu, 26 Jun 2008 19:24:01 +0200 Message-Id: <1214501042.6293.86.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDI2LiAwNi4gMjAwOCB2IDEwOjA4IC0wNDAwOgo+IExh ZGlzbGF2IExob3RrYSB3cml0ZXM6Cj4gPklmIHRoaXMgY291bGQgYmUgYWNjZXB0ZWQsIEkgd291 bGQgYWxzbyB2b3RlIGZvciByZW1vdmluZyB0aGUgZXh0ZW5zaW9uCj4gPnN0YXRlbWVudCBmcm9t IFlBTkcgLSBpdCBpcyBhY3R1YWxseSBxdWl0ZSB3ZWFrLCBlc3NlbnRpYWxseSB0ZWxsaW5nIHRo ZQo+ID5wYXJzZXIgdGhhdCBzdWNoIGEgc3ltYm9sIGV4aXN0cyBhbmQgaG93IHRvIHRyYW5zZm9y bSBpdCB0byBZSU4uCj4gCj4gSXQgYWxsb3dzIHRoZSBwYXJzZXIgdG8ga25vdyB3aGVuIGEgc3Rh dGVtZW50IGlzIGFuIGV4dGVuc2lvbgo+IGFuZCB3aGVuIGl0J3MgYSB0eXBvLiAgSWYgSSBoYXZl IGFuIGV4dGVuc2lvbiAianVub3M6Zm9vIiBhbmQKPiBtaXNzcGVsbCB0aGUgcHJlZml4LCBhIGNv bXBpbGVyIHRoYXQgdW5kZXJzdGFuZHMgImp1bm9zIiB3b24ndAo+IHNlZSB0aGF0ICJqdW5zczpm b28iIGlzIGEgbWlzdGFrZSwgYnV0IHdpbGwgaWdub3JlIGl0LiAgV2Ugd2FudAo+IHRvIGJlIGFi bGUgdG8gY2F0Y2ggZXJyb3JzIGF0IGNvbXBpbGUgdGltZS4KCldlbGwsIGEgZ2VuZXJpYyBwYXJz ZXIgd291bGQganVzdCBpZ25vcmUgaXQgLSB3aXRoIHRoZSB0eXBvIG9yIHdpdGhvdXQuCkFuZCBh bnkgYXBwbGljYXRpb24gdGhhdCBpcyBhYmxlIHRvIGludGVycHJldCB0aGUgZXh0ZW5zaW9uIHNo b3VsZCBjaGVjawpub3Qgb25seSBmb3IgdHlwb3MgYnV0IGFsc28gZm9yIHByb3BlciBwbGFjZW1l bnQgb2YgdGhlIHN0YXRlbWVudCwgaXRzCnN1YnN0YXRlbWVudHMgZXRjLgoKPiAKPiA+SSBiZWxp ZXZlIGl0IGlzIG11Y2ggZWFzaWVyIChhbmQsIGF0IHRoZSBlbmQgb2YgdGhlIGRheSwgbmVjZXNz YXJ5Cj4gPmFueXdheSkgdG8gbW9kaWZ5IHRoZSBnZW5lcmljIHBhcnNlciB0byB1bmRlcnN0YW5k IHRoZSBhbm5vdGF0aW9ucyBhbmQKPiA+cHJvcHJpZXRhcnkgZXh0ZW5zaW9ucywgcmF0aGVyIHRo YXQgdHJ5IHRvIGludmVudCBzbWFydCBleHRlbnNpb24KPiA+bWVjaGFuaXNtcyBmb3IgdGhlIGdl bmVyaWMgcGFyc2VyLgo+IAo+IEZvciBwcm9wcmlldGFyeSBZQU5HIG1vZHVsZXMgKGFuZCBldmVu dHVhbGx5IGZvciB3ZWxsLWtub3duCj4gZXh0ZW5zaW9ucyksIHB1dHRpbmcgdGhlbSBpbmxpbmUg d2l0aCB0aGUgWUFORyB0aGV5IGFyZSBwYXJ0IG9mIGlzCj4gYSBiaWcgd2luLiAgQXNraW5nIHRo ZSByZWFkZXIgdG8gbG9vayBpbiB0d28gcGxhY2VzIGlzIHNvbWV0aGluZwo+IHdlIHRyeSB0byBh dm9pZCAoYnV0IGlzIHVuYXZvaWRhYmxlIHdoZW4gZXh0ZW5kaW5nIHN0YW5kYXJkcykuCgpJIGFt IG5vdCBzdXJlIHRoYXQgd2UgdGFsayBhYm91dCB0aGUgc2FtZSB0aGluZy4gSSBhbSBhZHZvY2F0 aW5nIGV4YWN0bHkKd2hhdCB5b3UgYXJlIHNheWluZyAtIGNvbWJpbmUgdGhlIGFubm90YXRpb25z L2V4dGVuc2lvbnMgaW4tbGluZSB3aXRoCnRoZSBtb2R1bGUgdGV4dC4gTXkgcG9pbnQganVzdCBp cyB0aGF0IHNheWluZyAiaWdub3JlIGFsbCBzdGF0ZW1lbnRzIGluCm90aGVyIG5hbWVzcGFjZXMi IHByb3ZpZGVzIGEgcmVhc29uYWJsZSBwYXRoIGZvciBleHRlbnNpb25zIGJ1dCBkb2VzIG5vdApp bnRyb2R1Y2UgYW55IG5ldyBzdGF0ZW1lbnRzLiBCZWZvcmUgY29taW5nIHVwIHdpdGggWUFORyBs YW5ndWFnZQpjb25zdHJ1Y3RzLCBJJ2QgbGlrZSB0byBzZWUgdGhlIGNhc2VzIHdoZXJlIHRoaXMg c2ltcGxlIGFwcHJvYWNoIGZhaWxzLgoKQ2hlZXJzLCBMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGth LCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Jun 26 10: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 1E5213A690C; Thu, 26 Jun 2008 10:46: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 9CB2F3A690C for ; Thu, 26 Jun 2008 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 538tS1uyztQk for ; Thu, 26 Jun 2008 10:45:58 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id EC0CA3A68E3 for ; Thu, 26 Jun 2008 10:45:57 -0700 (PDT) Received: (qmail 99181 invoked from network); 26 Jun 2008 17:45:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 26 Jun 2008 17:45:55 -0000 X-YMail-OSG: 1EUwJWAVM1krvj47ehEM70A3PpTapld3rzKUi6npBllvLlzxSR2Bm_xc8o93dx5ohLYL_0_2xsbXHNll8nlYnsg9Sw4dFgxo.Van_BxMpaOyMiVnc8sJ9nBFjnSA X-Yahoo-Newman-Property: ymail-3 Message-ID: <4863D5D1.1060607@netconfcentral.com> Date: Thu, 26 Jun 2008 10:45:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200806261408.m5QE8vVA088074@idle.juniper.net> <1214501042.6293.86.camel@missotis> In-Reply-To: <1214501042.6293.86.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IMSMdCAyNi4gMDYu IDIwMDggdiAxMDowOCAtMDQwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyaXRlczoKPj4+IElmIHRo aXMgY291bGQgYmUgYWNjZXB0ZWQsIEkgd291bGQgYWxzbyB2b3RlIGZvciByZW1vdmluZyB0aGUg ZXh0ZW5zaW9uCj4+PiBzdGF0ZW1lbnQgZnJvbSBZQU5HIC0gaXQgaXMgYWN0dWFsbHkgcXVpdGUg d2VhaywgZXNzZW50aWFsbHkgdGVsbGluZyB0aGUKPj4+IHBhcnNlciB0aGF0IHN1Y2ggYSBzeW1i b2wgZXhpc3RzIGFuZCBob3cgdG8gdHJhbnNmb3JtIGl0IHRvIFlJTi4KPj4gSXQgYWxsb3dzIHRo ZSBwYXJzZXIgdG8ga25vdyB3aGVuIGEgc3RhdGVtZW50IGlzIGFuIGV4dGVuc2lvbgo+PiBhbmQg d2hlbiBpdCdzIGEgdHlwby4gIElmIEkgaGF2ZSBhbiBleHRlbnNpb24gImp1bm9zOmZvbyIgYW5k Cj4+IG1pc3NwZWxsIHRoZSBwcmVmaXgsIGEgY29tcGlsZXIgdGhhdCB1bmRlcnN0YW5kcyAianVu b3MiIHdvbid0Cj4+IHNlZSB0aGF0ICJqdW5zczpmb28iIGlzIGEgbWlzdGFrZSwgYnV0IHdpbGwg aWdub3JlIGl0LiAgV2Ugd2FudAo+PiB0byBiZSBhYmxlIHRvIGNhdGNoIGVycm9ycyBhdCBjb21w aWxlIHRpbWUuCj4gCj4gV2VsbCwgYSBnZW5lcmljIHBhcnNlciB3b3VsZCBqdXN0IGlnbm9yZSBp dCAtIHdpdGggdGhlIHR5cG8gb3Igd2l0aG91dC4KPiBBbmQgYW55IGFwcGxpY2F0aW9uIHRoYXQg aXMgYWJsZSB0byBpbnRlcnByZXQgdGhlIGV4dGVuc2lvbiBzaG91bGQgY2hlY2sKPiBub3Qgb25s eSBmb3IgdHlwb3MgYnV0IGFsc28gZm9yIHByb3BlciBwbGFjZW1lbnQgb2YgdGhlIHN0YXRlbWVu dCwgaXRzCj4gc3Vic3RhdGVtZW50cyBldGMuCj4gCgpXaGF0IGV4YWN0bHkgaXMgYSAnZ2VuZXJp YycgcGFyc2VyIGZvciBhIGxhbmd1YWdlIHRoYXQgaXMgYnJhbmQgbmV3PwpJIGhvcGUgd2UgZG9u J3QgZm9sbG93IHRoZSBwYXRoIG9mIHRoZSAnZ2VuZXJpYyBNSUIgd2Fsa2VyJyBpbiBTTk1QLAp3 aGVyZSBiYWQgZGVjaXNpb25zIGFyZSBtYWRlIHRvIG1haW50YWluIGR1bWIgdG9vbHMuCgpUaGUg ZXh0ZW5zaW9uLXN0bXQgYWxsb3dzIGEgcGFyc2VyIHRvIGdlbmVyYXRlIFlJTiBjb3JyZWN0bHks CmJ1dCBtb3N0bHksIGl0IG1ha2VzIHZlbmRvciBob29rcyB2aXNpYmxlIGluIHRoZSBtb2R1bGVz CmFuZCB0aGUgbGFuZ3VhZ2UuICBUaGlzIGFsbG93cyBleHRlbnNpb25zIHRvIGJlIHRyYWNrZWQK bGlrZSBvdGhlciBkZWZpbml0aW9ucywgd2l0aCB2ZXJzaW9uaW5nIGFuZCBzY2hlbWEgYWR2ZXJ0 aXNlbWVudC4KCgo+Pj4gSSBiZWxpZXZlIGl0IGlzIG11Y2ggZWFzaWVyIChhbmQsIGF0IHRoZSBl bmQgb2YgdGhlIGRheSwgbmVjZXNzYXJ5Cj4+PiBhbnl3YXkpIHRvIG1vZGlmeSB0aGUgZ2VuZXJp YyBwYXJzZXIgdG8gdW5kZXJzdGFuZCB0aGUgYW5ub3RhdGlvbnMgYW5kCj4+PiBwcm9wcmlldGFy eSBleHRlbnNpb25zLCByYXRoZXIgdGhhdCB0cnkgdG8gaW52ZW50IHNtYXJ0IGV4dGVuc2lvbgo+ Pj4gbWVjaGFuaXNtcyBmb3IgdGhlIGdlbmVyaWMgcGFyc2VyLgo+PiBGb3IgcHJvcHJpZXRhcnkg WUFORyBtb2R1bGVzIChhbmQgZXZlbnR1YWxseSBmb3Igd2VsbC1rbm93bgo+PiBleHRlbnNpb25z KSwgcHV0dGluZyB0aGVtIGlubGluZSB3aXRoIHRoZSBZQU5HIHRoZXkgYXJlIHBhcnQgb2YgaXMK Pj4gYSBiaWcgd2luLiAgQXNraW5nIHRoZSByZWFkZXIgdG8gbG9vayBpbiB0d28gcGxhY2VzIGlz IHNvbWV0aGluZwo+PiB3ZSB0cnkgdG8gYXZvaWQgKGJ1dCBpcyB1bmF2b2lkYWJsZSB3aGVuIGV4 dGVuZGluZyBzdGFuZGFyZHMpLgo+IAo+IEkgYW0gbm90IHN1cmUgdGhhdCB3ZSB0YWxrIGFib3V0 IHRoZSBzYW1lIHRoaW5nLiBJIGFtIGFkdm9jYXRpbmcgZXhhY3RseQo+IHdoYXQgeW91IGFyZSBz YXlpbmcgLSBjb21iaW5lIHRoZSBhbm5vdGF0aW9ucy9leHRlbnNpb25zIGluLWxpbmUgd2l0aAo+ IHRoZSBtb2R1bGUgdGV4dC4gTXkgcG9pbnQganVzdCBpcyB0aGF0IHNheWluZyAiaWdub3JlIGFs bCBzdGF0ZW1lbnRzIGluCj4gb3RoZXIgbmFtZXNwYWNlcyIgcHJvdmlkZXMgYSByZWFzb25hYmxl IHBhdGggZm9yIGV4dGVuc2lvbnMgYnV0IGRvZXMgbm90Cj4gaW50cm9kdWNlIGFueSBuZXcgc3Rh dGVtZW50cy4gQmVmb3JlIGNvbWluZyB1cCB3aXRoIFlBTkcgbGFuZ3VhZ2UKPiBjb25zdHJ1Y3Rz LCBJJ2QgbGlrZSB0byBzZWUgdGhlIGNhc2VzIHdoZXJlIHRoaXMgc2ltcGxlIGFwcHJvYWNoIGZh aWxzLgo+IAoKSSBhZ3JlZSB3aXRoIFJhbmR5LgpJdCBzZWVtcyBiZXR0ZXIgdG8ga2VlcCB0aGUg bWV0YS1jcnVmdCBvdXQgb2YgdGhlIGRhdGEgbW9kZWwuClRoaXMgZG9lcyBub3QgYmVsb25nIGlu c2lkZSBzdGFuZGFyZCBkYXRhIG1vZGVscy4KV2hhdCBpZiB0d28gZGlmZmVyZW50IHByb2R1Y3Rz IG9yIHZlcnNpb25zIGhhdmUgZGlmZmVyZW50IGNydWZ0CmZvciBhIGdpdmVuIERNIGRlZmluaXRp b24/ICBJIGd1ZXNzIHdlIHdvdWxkIG5lZWQgdG8gYWRkIENQUC1zdHlsZQojaWYsICNlbHNlLCAj ZWxpZiBjb25zdHJ1Y3RzIHRvIGRlYWwgd2l0aCB0aGF0LiAgTm8gdGhhbmtzLgpJIHByZWZlciB0 aGUgc2ltcGxlc3QgcG9zc2libGUgRE1MIHRoYXQgd2UgY2FuIHVzZSB0byBzdXBwb3J0CnN0YW5k YXJkcy1iYXNlZCBjb250ZW50LgoKSSBoYXZlIHNvbWUgY29uY2VybnMgdGhhdCBzaW5jZSB3ZSBo YXZlIG5vIGFyY2hpdGVjdHVyZSB3aGF0c29ldmVyCmZvciBzdGFuZGFyZHMtYmFzZWQgbXVsdGkt cHJvdG9jb2wgbmV0d29yayBtYW5hZ2VtZW50LCB0aGF0IHdlCmhhdmUgbm8gY29tbW9uIHZpc2lv biBvZiB0aGUgZ29hbHMgZm9yIFlBTkcuICBDbGVhcmx5IHRoZXJlIGlzCnNvbWUgYWR2YW50YWdl IGluIGhhdmluZyBhIGNvbW1vbiBsYW5ndWFnZSBmb3IgYWxsIHByb3ByaWV0YXJ5Ck5FVENPTkYg ZGF0YSBtb2RlbHMsIGJ1dCB3ZSBzb3J0LW9mIGFscmVhZHkgaGFkIHRoYXQgd2l0aCBYU0QuCgpJ TU8sIFlBTkcgYW5kIE5FVENPTkYgYXJlIG1vc3RseSB3b3J0aGxlc3MgdW5sZXNzIGFjdHVhbApz dGFuZGFyZCBjb250ZW50IGlzIGRlZmluZWQgYW5kIHB1Ymxpc2hlZCBpbiBSRkNzLiAgVGhlcmVm b3JlLApZQU5HJ3MgdXNlZnVsbmVzcyBmb3Igc3RhbmRhcmQgZGF0YSBtb2RlbHMgYW5kIG11bHRp LXZlbmRvcgppbnRlcm9wZXJhYmlsaXR5IHNob3VsZCBiZSB0aGUgaGlnaGVzdCBwcmlvcml0aWVz LgoKCj4gQ2hlZXJzLCBMYWRhCj4gCgpBbmR5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jun 26 12:04: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 5A0393A6A4B; Thu, 26 Jun 2008 12:04: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 8173E3A69BE for ; Thu, 26 Jun 2008 12:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViXr8WDacDlW for ; Thu, 26 Jun 2008 12:04:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7CB333A6A2B for ; Thu, 26 Jun 2008 12:04:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 624F1C0027; Thu, 26 Jun 2008 21:04:35 +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 hz3dkPP3BVF1; Thu, 26 Jun 2008 21:04:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF71CC002A; Thu, 26 Jun 2008 21:04:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D6065E0B14; Thu, 26 Jun 2008 21:04:28 +0200 (CEST) Date: Thu, 26 Jun 2008 21:04:28 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080626190428.GA2340@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , netmod@ietf.org References: <200806261408.m5QE8vVA088074@idle.juniper.net> <1214501042.6293.86.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1214501042.6293.86.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] overlays 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, Jun 26, 2008 at 07:24:01PM +0200, Ladislav Lhotka wrote: > Well, a generic parser would just ignore it - with the typo or without. > And any application that is able to interpret the extension should check > not only for typos but also for proper placement of the statement, its > substatements etc. An application that is able to interpret an extension foo will also have to skip over things it does not understand, including any typos of loo^hfoo. /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 Jun 26 12:21: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 8B91E3A6A11; Thu, 26 Jun 2008 12:21: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 6C82A3A6A11 for ; Thu, 26 Jun 2008 12:21:30 -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 0q5R6nXmeYAq for ; Thu, 26 Jun 2008 12:21:29 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 9C56B3A68EA for ; Thu, 26 Jun 2008 12:21:27 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 26 Jun 2008 12:21:27 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, 26 Jun 2008 12:21:22 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 12:21:22 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 12:21:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5QJLKx77923; Thu, 26 Jun 2008 12:21:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5QJIlTG090013; Thu, 26 Jun 2008 19:18:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806261918.m5QJIlTG090013@idle.juniper.net> To: Andy Bierman In-reply-to: <4863AF66.4000702@netconfcentral.com> Date: Thu, 26 Jun 2008 15:18:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Jun 2008 19:21:21.0332 (UTC) FILETIME=[D0E3F740:01C8D7C1] Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.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: >Phil claims that it would be too restrictive on the vendor. I don't think I claimed that. My claim is that a rule that we don't need is a CLR. There's nothing in the langauge that needs these namespaces to be common. If we need the namespaces to be common to allow some new feature like annotations, it stops being a CLR. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 12:28: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 8A1173A6A4B; Thu, 26 Jun 2008 12:28: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 47EBD3A67CF for ; Thu, 26 Jun 2008 12:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs5ql2z0btid for ; Thu, 26 Jun 2008 12:28:11 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 7BC513A6A4B for ; Thu, 26 Jun 2008 12:28:11 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 47C901B80CA; Thu, 26 Jun 2008 21:28:14 +0200 (CEST) Date: Thu, 26 Jun 2008 21:28:43 +0200 (CEST) Message-Id: <20080626.212843.105033069.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4863B37E.6040206@netconfcentral.com> References: <20080626.144614.249642590.mbj@tail-f.com> <4863AF66.4000702@netconfcentral.com> <4863B37E.6040206@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] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > There is absolutely no way to use Xpath to reference the sub-tree > under a 'uses' or 'augment' node. Right. But do we really need to annotate the 'uses' and 'augment' statements themselves? Hmm... pretty weak argument, and it smells like a CLR ("you can annotate all statements but two, b/c we didn't think it was necessary"). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 12:54: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 906973A6A2B; Thu, 26 Jun 2008 12:54: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 3956B3A6A2B for ; Thu, 26 Jun 2008 12:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 Smbt+7eKJ4bf for ; Thu, 26 Jun 2008 12:54:31 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id B36183A69DC for ; Thu, 26 Jun 2008 12:54:31 -0700 (PDT) Received: (qmail 3454 invoked from network); 26 Jun 2008 19:54:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 26 Jun 2008 19:54:29 -0000 X-YMail-OSG: 5XYT.MgVM1n21NuDPl0y9Z3LA.Ip4l2P46_XGsKBfx3WwTOUKfPeOdhTpbkaR_p4W3RbVmndEvdhhfaU_RyAM6XHcrB9bar1UzfPqo_LoA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4863F3F3.8090002@netconfcentral.com> Date: Thu, 26 Jun 2008 12:54:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080626.144614.249642590.mbj@tail-f.com> <4863AF66.4000702@netconfcentral.com> <4863B37E.6040206@netconfcentral.com> <20080626.212843.105033069.mbj@tail-f.com> In-Reply-To: <20080626.212843.105033069.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org 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: >> There is absolutely no way to use Xpath to reference the sub-tree >> under a 'uses' or 'augment' node. > > Right. But do we really need to annotate the 'uses' and 'augment' > statements themselves? Hmm... pretty weak argument, and it smells > like a CLR ("you can annotate all statements but two, b/c we didn't > think it was necessary"). > Are you trying to convince yourself? One use-case mentioned is attaching a bunch of i18n translation strings (or constants) to a description clause, and those can show up everywhere. Nobody wants to read a data model draft full of that sort of 'tool stuff' inline, and a 1:1 overlay seems the most simple to manage. IMO, a tree overlay makes the most sense because it is complete, already defined, and doesn't throw out the existing design in order to work. > > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 13:06:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7DB3A6823; Thu, 26 Jun 2008 13:06:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0109B3A67EF for ; Thu, 26 Jun 2008 13:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOZs+0p1yqAk for ; Thu, 26 Jun 2008 13:06:31 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 218463A6823 for ; Thu, 26 Jun 2008 13:06:31 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 0B6EA1B80CA; Thu, 26 Jun 2008 22:06:34 +0200 (CEST) Date: Thu, 26 Jun 2008 22:07:03 +0200 (CEST) Message-Id: <20080626.220703.78525800.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4863F3F3.8090002@netconfcentral.com> References: <4863B37E.6040206@netconfcentral.com> <20080626.212843.105033069.mbj@tail-f.com> <4863F3F3.8090002@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] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> There is absolutely no way to use Xpath to reference the sub-tree > >> under a 'uses' or 'augment' node. > > Right. But do we really need to annotate the 'uses' and 'augment' > > statements themselves? Hmm... pretty weak argument, and it smells > > like a CLR ("you can annotate all statements but two, b/c we didn't > > think it was necessary"). > > > > Are you trying to convince yourself? Yes. I haven't succeeded yet though. > One use-case mentioned is attaching a bunch > of i18n translation strings (or constants) > to a description clause, and those can show up everywhere. > Nobody wants to read a data model draft full > of that sort of 'tool stuff' inline With both proposals the DM writer can choose to do everything inline, or in an extra annotation file. > and a 1:1 overlay > seems the most simple to manage. The drawback is that with the overlay we'll have to say that some statements can be used to add to the module (like the import in my first example), but some others are only valid if the corresponding statement exist in the original module (e.g. 'container'; you cannot add new the data definition statements in an overlay). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jun 26 13:54: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 A242D3A67D0; Thu, 26 Jun 2008 13:54: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 454473A67D0 for ; Thu, 26 Jun 2008 13:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 62u9-P+avYw2 for ; Thu, 26 Jun 2008 13:54:16 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 208493A67CF for ; Thu, 26 Jun 2008 13:54:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 26 Jun 2008 13:52:46 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 13:54:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 13:54:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 13:54:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5QKs1x21694; Thu, 26 Jun 2008 13:54:01 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5QKpRPb090953; Thu, 26 Jun 2008 20:51:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806262051.m5QKpRPb090953@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080626.220703.78525800.mbj@tail-f.com> Date: Thu, 26 Jun 2008 16:51:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Jun 2008 20:54:01.0965 (UTC) FILETIME=[C34939D0:01C8D7CE] Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund writes: >The drawback is that with the overlay we'll have to say that some >statements can be used to add to the module (like the import in my >first example), but some others are only valid if the corresponding >statement exist in the original module (e.g. 'container'; you cannot >add new the data definition statements in an overlay). My hangup is this is really overloading the YANG statements, making them mean one thing in annotations in one one thing in normal modules. While sort of conditional logic and overloading is confusing to readers. You can't say "a list statement needs to specify a key", since a list statement in an annotation doesn't need to do this. This was a mistake I made in the JUNOS DDL. Several statements have meanings that are dependent on which parent statement they appear under. This has been a continuing source of irritation for developers and I regret it. A statement should have one meaning and that meaning should be clear, consistent, and unchanging. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 27 01:25: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 F22243A67B6; Fri, 27 Jun 2008 01:25: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 599023A67AF for ; Fri, 27 Jun 2008 01:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_BACKHAIR_43=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJKsqDqRdgQQ for ; Fri, 27 Jun 2008 01:25:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 229C83A67D1 for ; Fri, 27 Jun 2008 01:25: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 C4603D800CC; Fri, 27 Jun 2008 10:25:52 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4863D5D1.1060607@netconfcentral.com> References: <200806261408.m5QE8vVA088074@idle.juniper.net> <1214501042.6293.86.camel@missotis> <4863D5D1.1060607@netconfcentral.com> Organization: CESNET Date: Fri, 27 Jun 2008 10:25:52 +0200 Message-Id: <1214555152.6623.15.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAyNi4gMDYuIDIwMDggdiAxMDo0NSAtMDcwMDoKPiBM YWRpc2xhdiBMaG90a2Egd3JvdGU6Cj4gPiBQaGlsIFNoYWZlciBww63FoWUgdiDEjHQgMjYuIDA2 LiAyMDA4IHYgMTA6MDggLTA0MDA6Cj4gPj4gTGFkaXNsYXYgTGhvdGthIHdyaXRlczoKPiA+Pj4g SWYgdGhpcyBjb3VsZCBiZSBhY2NlcHRlZCwgSSB3b3VsZCBhbHNvIHZvdGUgZm9yIHJlbW92aW5n IHRoZSBleHRlbnNpb24KPiA+Pj4gc3RhdGVtZW50IGZyb20gWUFORyAtIGl0IGlzIGFjdHVhbGx5 IHF1aXRlIHdlYWssIGVzc2VudGlhbGx5IHRlbGxpbmcgdGhlCj4gPj4+IHBhcnNlciB0aGF0IHN1 Y2ggYSBzeW1ib2wgZXhpc3RzIGFuZCBob3cgdG8gdHJhbnNmb3JtIGl0IHRvIFlJTi4KPiA+PiBJ dCBhbGxvd3MgdGhlIHBhcnNlciB0byBrbm93IHdoZW4gYSBzdGF0ZW1lbnQgaXMgYW4gZXh0ZW5z aW9uCj4gPj4gYW5kIHdoZW4gaXQncyBhIHR5cG8uICBJZiBJIGhhdmUgYW4gZXh0ZW5zaW9uICJq dW5vczpmb28iIGFuZAo+ID4+IG1pc3NwZWxsIHRoZSBwcmVmaXgsIGEgY29tcGlsZXIgdGhhdCB1 bmRlcnN0YW5kcyAianVub3MiIHdvbid0Cj4gPj4gc2VlIHRoYXQgImp1bnNzOmZvbyIgaXMgYSBt aXN0YWtlLCBidXQgd2lsbCBpZ25vcmUgaXQuICBXZSB3YW50Cj4gPj4gdG8gYmUgYWJsZSB0byBj YXRjaCBlcnJvcnMgYXQgY29tcGlsZSB0aW1lLgo+ID4gCj4gPiBXZWxsLCBhIGdlbmVyaWMgcGFy c2VyIHdvdWxkIGp1c3QgaWdub3JlIGl0IC0gd2l0aCB0aGUgdHlwbyBvciB3aXRob3V0Lgo+ID4g QW5kIGFueSBhcHBsaWNhdGlvbiB0aGF0IGlzIGFibGUgdG8gaW50ZXJwcmV0IHRoZSBleHRlbnNp b24gc2hvdWxkIGNoZWNrCj4gPiBub3Qgb25seSBmb3IgdHlwb3MgYnV0IGFsc28gZm9yIHByb3Bl ciBwbGFjZW1lbnQgb2YgdGhlIHN0YXRlbWVudCwgaXRzCj4gPiBzdWJzdGF0ZW1lbnRzIGV0Yy4K PiA+IAo+IAo+IFdoYXQgZXhhY3RseSBpcyBhICdnZW5lcmljJyBwYXJzZXIgZm9yIGEgbGFuZ3Vh Z2UgdGhhdCBpcyBicmFuZCBuZXc/Cj4gSSBob3BlIHdlIGRvbid0IGZvbGxvdyB0aGUgcGF0aCBv ZiB0aGUgJ2dlbmVyaWMgTUlCIHdhbGtlcicgaW4gU05NUCwKPiB3aGVyZSBiYWQgZGVjaXNpb25z IGFyZSBtYWRlIHRvIG1haW50YWluIGR1bWIgdG9vbHMuCgpBIGdlbmVyaWMgcGFyc2VyIGlzIG9u ZSB3aG9zZSBiZWhhdmlvdXIgd2lsbCBiZSBkZWZpbmVkIGluIHRoZSBZQU5HCnN0YW5kYXJkLiBJ dCBpcyBhbiBleGFjdCBhbmFsb2d5IG9mIFJFTEFYIE5HLgoKPiAKPiBUaGUgZXh0ZW5zaW9uLXN0 bXQgYWxsb3dzIGEgcGFyc2VyIHRvIGdlbmVyYXRlIFlJTiBjb3JyZWN0bHksCgpBcyB3ZSBoYXZl IGFscmVhZHkgZGlzY3Vzc2VkIHdpdGggTWFydGluIG9mZiB0aGUgbGlzdCwgdGhlc2UgWUFORzwt PllJTgp0cmFuc2xhdGlvbiBydWxlcyBjYW4gYmUgZWFzaWx5IHNwZWNpZmllZCBpbiBhIHRleHQg ZmlsZSwgc28gaXQgaXMgbm8KcHJvYmxlbSB0byBleHRlbmQgc3VjaCBhIGZpbGUuIEFuZCB0aGVy ZSBjb3VsZCBiZSBhIGRlZmF1bHQgdHJhbnNsYXRpb24KcnVsZSB0aGF0IGNvbnZlcnRzIHRoZSBz dGF0ZW1lbnQgaW4gYW4gZWxlbWVudCB3aXRoIHRoZSBzYW1lIG5hbWUgYW5kCmF0dHJpYnV0ZSAi YXJnIiBvciBzb21ldGhpbmcgbGlrZSB0aGF0LgoKPiBidXQgbW9zdGx5LCBpdCBtYWtlcyB2ZW5k b3IgaG9va3MgdmlzaWJsZSBpbiB0aGUgbW9kdWxlcwo+IGFuZCB0aGUgbGFuZ3VhZ2UuICBUaGlz IGFsbG93cyBleHRlbnNpb25zIHRvIGJlIHRyYWNrZWQKPiBsaWtlIG90aGVyIGRlZmluaXRpb25z LCB3aXRoIHZlcnNpb25pbmcgYW5kIHNjaGVtYSBhZHZlcnRpc2VtZW50LgoKQXBwbGljYXRpb25z IGNhbiB0cmFjayB0aGUgZXh0ZW5zaW9ucyBpZiB0aGV5IHdhbnQgdG8sIHRoZXkganVzdCBjYW5u b3QKY2hlY2sgdGhhdCB0aGUgbmFtZSBpcyBjb3JyZWN0LiBPciwgdGhleSBjYW4gZXh0ZW5kIFlB TkcgZ3JhbW1hciBhbmQKZGVhbCBoYW5kbGUgdGhlIGV4dGVuc2lvbiBhcyBhbnkgb3RoZXIgWUFO RyBzdGF0ZW1lbnQgLSB0aGUgZXh0ZW5zaW9uCnN0YXRlbWVudCBmYWxscyBzaG9ydCBpbiB0aGlz IHJlc3BlY3QuCgo+IAo+IAo+ID4+PiBJIGJlbGlldmUgaXQgaXMgbXVjaCBlYXNpZXIgKGFuZCwg YXQgdGhlIGVuZCBvZiB0aGUgZGF5LCBuZWNlc3NhcnkKPiA+Pj4gYW55d2F5KSB0byBtb2RpZnkg dGhlIGdlbmVyaWMgcGFyc2VyIHRvIHVuZGVyc3RhbmQgdGhlIGFubm90YXRpb25zIGFuZAo+ID4+ PiBwcm9wcmlldGFyeSBleHRlbnNpb25zLCByYXRoZXIgdGhhdCB0cnkgdG8gaW52ZW50IHNtYXJ0 IGV4dGVuc2lvbgo+ID4+PiBtZWNoYW5pc21zIGZvciB0aGUgZ2VuZXJpYyBwYXJzZXIuCj4gPj4g Rm9yIHByb3ByaWV0YXJ5IFlBTkcgbW9kdWxlcyAoYW5kIGV2ZW50dWFsbHkgZm9yIHdlbGwta25v d24KPiA+PiBleHRlbnNpb25zKSwgcHV0dGluZyB0aGVtIGlubGluZSB3aXRoIHRoZSBZQU5HIHRo ZXkgYXJlIHBhcnQgb2YgaXMKPiA+PiBhIGJpZyB3aW4uICBBc2tpbmcgdGhlIHJlYWRlciB0byBs b29rIGluIHR3byBwbGFjZXMgaXMgc29tZXRoaW5nCj4gPj4gd2UgdHJ5IHRvIGF2b2lkIChidXQg aXMgdW5hdm9pZGFibGUgd2hlbiBleHRlbmRpbmcgc3RhbmRhcmRzKS4KPiA+IAo+ID4gSSBhbSBu b3Qgc3VyZSB0aGF0IHdlIHRhbGsgYWJvdXQgdGhlIHNhbWUgdGhpbmcuIEkgYW0gYWR2b2NhdGlu ZyBleGFjdGx5Cj4gPiB3aGF0IHlvdSBhcmUgc2F5aW5nIC0gY29tYmluZSB0aGUgYW5ub3RhdGlv bnMvZXh0ZW5zaW9ucyBpbi1saW5lIHdpdGgKPiA+IHRoZSBtb2R1bGUgdGV4dC4gTXkgcG9pbnQg anVzdCBpcyB0aGF0IHNheWluZyAiaWdub3JlIGFsbCBzdGF0ZW1lbnRzIGluCj4gPiBvdGhlciBu YW1lc3BhY2VzIiBwcm92aWRlcyBhIHJlYXNvbmFibGUgcGF0aCBmb3IgZXh0ZW5zaW9ucyBidXQg ZG9lcyBub3QKPiA+IGludHJvZHVjZSBhbnkgbmV3IHN0YXRlbWVudHMuIEJlZm9yZSBjb21pbmcg dXAgd2l0aCBZQU5HIGxhbmd1YWdlCj4gPiBjb25zdHJ1Y3RzLCBJJ2QgbGlrZSB0byBzZWUgdGhl IGNhc2VzIHdoZXJlIHRoaXMgc2ltcGxlIGFwcHJvYWNoIGZhaWxzLgo+ID4gCj4gCj4gSSBhZ3Jl ZSB3aXRoIFJhbmR5Lgo+IEl0IHNlZW1zIGJldHRlciB0byBrZWVwIHRoZSBtZXRhLWNydWZ0IG91 dCBvZiB0aGUgZGF0YSBtb2RlbC4KPiBUaGlzIGRvZXMgbm90IGJlbG9uZyBpbnNpZGUgc3RhbmRh cmQgZGF0YSBtb2RlbHMuCj4gV2hhdCBpZiB0d28gZGlmZmVyZW50IHByb2R1Y3RzIG9yIHZlcnNp b25zIGhhdmUgZGlmZmVyZW50IGNydWZ0Cj4gZm9yIGEgZ2l2ZW4gRE0gZGVmaW5pdGlvbj8gIEkg Z3Vlc3Mgd2Ugd291bGQgbmVlZCB0byBhZGQgQ1BQLXN0eWxlCj4gI2lmLCAjZWxzZSwgI2VsaWYg Y29uc3RydWN0cyB0byBkZWFsIHdpdGggdGhhdC4gIE5vIHRoYW5rcy4KPiBJIHByZWZlciB0aGUg c2ltcGxlc3QgcG9zc2libGUgRE1MIHRoYXQgd2UgY2FuIHVzZSB0byBzdXBwb3J0Cj4gc3RhbmRh cmRzLWJhc2VkIGNvbnRlbnQuCgpBbiBhcHBsaWNhdGlvbiB0aGF0IHdhbnRzIHRvIGtlZXAgdGhp cyBjcnVmdCBvdXQgb2YgdGhlIERNIGNhbiBkbyBzbywKYnV0IEkgYW0gbm90IHN1cmUgdGhhdCB0 aGUgbWVjaGFuaXNtIGZvciBkb2luZyB0aGlzIGhhcyB0byBiZSBzcGVjaWZpZWQKdG9nZXRoZXIg d2l0aCB0aGUgY29yZSBZQU5HLgogCj4gCj4gSSBoYXZlIHNvbWUgY29uY2VybnMgdGhhdCBzaW5j ZSB3ZSBoYXZlIG5vIGFyY2hpdGVjdHVyZSB3aGF0c29ldmVyCj4gZm9yIHN0YW5kYXJkcy1iYXNl ZCBtdWx0aS1wcm90b2NvbCBuZXR3b3JrIG1hbmFnZW1lbnQsIHRoYXQgd2UKPiBoYXZlIG5vIGNv bW1vbiB2aXNpb24gb2YgdGhlIGdvYWxzIGZvciBZQU5HLiAgQ2xlYXJseSB0aGVyZSBpcwo+IHNv bWUgYWR2YW50YWdlIGluIGhhdmluZyBhIGNvbW1vbiBsYW5ndWFnZSBmb3IgYWxsIHByb3ByaWV0 YXJ5Cj4gTkVUQ09ORiBkYXRhIG1vZGVscywgYnV0IHdlIHNvcnQtb2YgYWxyZWFkeSBoYWQgdGhh dCB3aXRoIFhTRC4KPiAKPiBJTU8sIFlBTkcgYW5kIE5FVENPTkYgYXJlIG1vc3RseSB3b3J0aGxl c3MgdW5sZXNzIGFjdHVhbAo+IHN0YW5kYXJkIGNvbnRlbnQgaXMgZGVmaW5lZCBhbmQgcHVibGlz aGVkIGluIFJGQ3MuICBUaGVyZWZvcmUsCj4gWUFORydzIHVzZWZ1bG5lc3MgZm9yIHN0YW5kYXJk IGRhdGEgbW9kZWxzIGFuZCBtdWx0aS12ZW5kb3IKPiBpbnRlcm9wZXJhYmlsaXR5IHNob3VsZCBi ZSB0aGUgaGlnaGVzdCBwcmlvcml0aWVzLgoKSSBhZ3JlZSB3aXRoIHRoaXMsIGFuZCBpdCBpcyBJ TU8gYmV0dGVyIHRvIHN0YXJ0IHdpdGggdGhlIHNpbXBsZXN0CnBvc3NpYmxlIGxhbmd1YWdlIGFu ZCBhZGQgZmVhdHVyZXMgb25seSBhZnRlciB0aGVyZSBpcyBlbm91Z2ggZXZpZGVuY2UKdGhhdCB0 aGV5IGFyZSByZWFsbHkgbmVlZGVkLCBhbmQgcGVyaGFwcyBob3cgdG8gZG8gaXQgcmlnaHQuCgpM YWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWls aW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri Jun 27 01:31: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 37E383A67B6; Fri, 27 Jun 2008 01:31: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 9718D3A67B6 for ; Fri, 27 Jun 2008 01:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 rN7nTGX0msrf for ; Fri, 27 Jun 2008 01:31:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CD4103A6784 for ; Fri, 27 Jun 2008 01:31:35 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5FCBED800D0 for ; Fri, 27 Jun 2008 10:31:39 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20080626190428.GA2340@elstar.local> References: <200806261408.m5QE8vVA088074@idle.juniper.net> <1214501042.6293.86.camel@missotis> <20080626190428.GA2340@elstar.local> Organization: CESNET Date: Fri, 27 Jun 2008 10:31:38 +0200 Message-Id: <1214555498.6623.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IMSMdCAyNi4gMDYuIDIwMDggdiAyMTowNCAr MDIwMDoKPiBPbiBUaHUsIEp1biAyNiwgMjAwOCBhdCAwNzoyNDowMVBNICswMjAwLCBMYWRpc2xh diBMaG90a2Egd3JvdGU6Cj4gIAo+ID4gV2VsbCwgYSBnZW5lcmljIHBhcnNlciB3b3VsZCBqdXN0 IGlnbm9yZSBpdCAtIHdpdGggdGhlIHR5cG8gb3Igd2l0aG91dC4KPiA+IEFuZCBhbnkgYXBwbGlj YXRpb24gdGhhdCBpcyBhYmxlIHRvIGludGVycHJldCB0aGUgZXh0ZW5zaW9uIHNob3VsZCBjaGVj awo+ID4gbm90IG9ubHkgZm9yIHR5cG9zIGJ1dCBhbHNvIGZvciBwcm9wZXIgcGxhY2VtZW50IG9m IHRoZSBzdGF0ZW1lbnQsIGl0cwo+ID4gc3Vic3RhdGVtZW50cyBldGMuCj4gCj4gQW4gYXBwbGlj YXRpb24gdGhhdCBpcyBhYmxlIHRvIGludGVycHJldCBhbiBleHRlbnNpb24gZm9vIHdpbGwgYWxz bwo+IGhhdmUgdG8gc2tpcCBvdmVyIHRoaW5ncyBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kLCBpbmNs dWRpbmcgYW55IHR5cG9zCj4gb2YgbG9vXmhmb28uCgpObywgaXQgd2lsbCBrbm93IHRoYXQgaXQg aXMgYWJsZSB0byBjb21wbGV0ZWx5IGludGVycHJldCB2b2NhYnVsYXJ5IGluCm5hbWVzcGFjZSBY LCBhbmQgYWxsIHVzZWQgbmFtZXNwYWNlIHdpbGwgaGF2ZSB0byBiZSBkZWZpbmVkIGluIHRoZQpt b2R1bGUsIHNvIGl0IHdpbGwgcmVjb2duaXplIGFsbCB0eXBvcyBhbmQgc3ludGF4IGVycm9ycyB3 aXRoaW4gdGhhdApuYW1lc3BhY2UuCgpJbiBmYWN0LCB0aGUgdHlwbyBpbiBQaGlsJ3MgZXhhbXBs ZSB3YXMgaW4gYSBuYW1lc3BhY2UgcHJlZml4LCBzbyB0aGlzCnNob3VsZCBiZSBjYXVnaHQgZXZl biBieSBhIGdlbmVyaWMgcGFyc2VyLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVU ClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri Jun 27 07:10: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 785A43A6957; Fri, 27 Jun 2008 07:10: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 37DFA3A6A00 for ; Fri, 27 Jun 2008 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.011 X-Spam-Level: X-Spam-Status: No, score=-6.011 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9sJz4DH3g6g for ; Fri, 27 Jun 2008 07:10:55 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id EA0463A6957 for ; Fri, 27 Jun 2008 07:10:50 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Fri, 27 Jun 2008 07:10:38 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, 27 Jun 2008 07:10:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 07:10:22 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 07:07: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 m5RE7mx95924; Fri, 27 Jun 2008 07:07:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5RE5D1w096333; Fri, 27 Jun 2008 14:05:14 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806271405.m5RE5D1w096333@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1214555152.6623.15.camel@missotis> Date: Fri, 27 Jun 2008 10:05:13 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Jun 2008 14:07:54.0671 (UTC) FILETIME=[31A8FBF0:01C8D85F] Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.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: >As we have already discussed with Martin off the list, these YANG<->YIN >translation rules can be easily specified in a text file, so it is no >problem to extend such a file. I'm having trouble seeing any of this as an improvement on what's currently in the spec. How is an external text file a win? What's the issue with the current extension mechanism? What problem are you trying to solve by removing it? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 27 07:42: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 939693A6B13; Fri, 27 Jun 2008 07:42: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 ABBD33A6B13 for ; Fri, 27 Jun 2008 07:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, J_BACKHAIR_43=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyHQ8o4nAwbQ for ; Fri, 27 Jun 2008 07:42:33 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id CD97E3A6AB0 for ; Fri, 27 Jun 2008 07:42:32 -0700 (PDT) Received: (qmail 34356 invoked from network); 27 Jun 2008 14:42:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 27 Jun 2008 14:42:32 -0000 X-YMail-OSG: Whkez50VM1mXUjA0H0lZVX046__hgNe43ms0XiEvuR758YpTKip9w2bsT5SX2hyhNLtwH4nstXzDoIHhT4.X3Lu6hIXeyPD1PDah1QQNmQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4864FC55.2080903@netconfcentral.com> Date: Fri, 27 Jun 2008 07:42:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200806271405.m5RE5D1w096333@idle.juniper.net> In-Reply-To: <200806271405.m5RE5D1w096333@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> As we have already discussed with Martin off the list, these YANG<->YIN >> translation rules can be easily specified in a text file, so it is no >> problem to extend such a file. > > I'm having trouble seeing any of this as an improvement on what's > currently in the spec. How is an external text file a win? What's > the issue with the current extension mechanism? What problem are > you trying to solve by removing it? > I agree with Phil on this one. At first, I was really opposed to the extension-stmt, mostly because I didn't want to encourage non-standard mechanisms. But now I think they are kind of useful, and easy to parse. For example, the smidump program adds extensions that are specialized for NETCONF applications that want access to SMIv2 defined data. This is not something that should be built into the YANG language, and the extension-stmt handles it very well. It is possible to design tools which allow the user to attach functionality to the extensions. At a minimum, tools can gather the extensions used within each construct and make them available within the manager or agent as meta-data. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 27 08:06: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 6A68E3A6903; Fri, 27 Jun 2008 08:06: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 E7EE73A68E8 for ; Fri, 27 Jun 2008 08:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_BACKHAIR_43=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hPWQTSby3k0 for ; Fri, 27 Jun 2008 08:06:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 15DC53A6903 for ; Fri, 27 Jun 2008 08:06:15 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 263E9D800D7; Fri, 27 Jun 2008 17:06:19 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200806271405.m5RE5D1w096333@idle.juniper.net> References: <200806271405.m5RE5D1w096333@idle.juniper.net> Organization: CESNET Date: Fri, 27 Jun 2008 17:06:19 +0200 Message-Id: <1214579179.7246.33.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgUMOhIDI3LiAwNi4gMjAwOCB2IDEwOjA1IC0wNDAwOgo+IExh ZGlzbGF2IExob3RrYSB3cml0ZXM6Cj4gPkFzIHdlIGhhdmUgYWxyZWFkeSBkaXNjdXNzZWQgd2l0 aCBNYXJ0aW4gb2ZmIHRoZSBsaXN0LCB0aGVzZSBZQU5HPC0+WUlOCj4gPnRyYW5zbGF0aW9uIHJ1 bGVzIGNhbiBiZSBlYXNpbHkgc3BlY2lmaWVkIGluIGEgdGV4dCBmaWxlLCBzbyBpdCBpcyBubwo+ ID5wcm9ibGVtIHRvIGV4dGVuZCBzdWNoIGEgZmlsZS4KPiAKPiBJJ20gaGF2aW5nIHRyb3VibGUg c2VlaW5nIGFueSBvZiB0aGlzIGFzIGFuIGltcHJvdmVtZW50IG9uIHdoYXQncwo+IGN1cnJlbnRs eSBpbiB0aGUgc3BlYy4gIEhvdyBpcyBhbiBleHRlcm5hbCB0ZXh0IGZpbGUgYSB3aW4/ICBXaGF0 J3MKClRoZSBzcGVjIGNvdWxkIHJlbWFpbiB1bnRvdWNoZWQgd3J0IFlBTkc8LT5ZSU4gdHJhbnNs YXRpb24uIFRoZSB0ZXh0CmZpbGUgd291bGQgYmUgdXNlZCBieSBweWFuZyBhbmQgb3RoZXIgdG9v bHMuCgo+IHRoZSBpc3N1ZSB3aXRoIHRoZSBjdXJyZW50IGV4dGVuc2lvbiBtZWNoYW5pc20/ICBX aGF0IHByb2JsZW0gYXJlCj4geW91IHRyeWluZyB0byBzb2x2ZSBieSByZW1vdmluZyBpdD8KClNp bXBsaWZ5IFlBTkcuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJ RDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri Jun 27 08:23: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 6C96228C146; Fri, 27 Jun 2008 08:23: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 BEDE028C140 for ; Fri, 27 Jun 2008 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=0.260, 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 9FQ3piSFFZCi for ; Fri, 27 Jun 2008 08:23:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id ED0E728C134 for ; Fri, 27 Jun 2008 08:23:27 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7E0E7D800D1; Fri, 27 Jun 2008 17:23:32 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4864FC55.2080903@netconfcentral.com> References: <200806271405.m5RE5D1w096333@idle.juniper.net> <4864FC55.2080903@netconfcentral.com> Organization: CESNET Date: Fri, 27 Jun 2008 17:23:33 +0200 Message-Id: <1214580213.7246.47.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IFDDoSAyNy4gMDYuIDIwMDggdiAwNzo0MiAtMDcwMDoKCj4g SSBhZ3JlZSB3aXRoIFBoaWwgb24gdGhpcyBvbmUuCj4gQXQgZmlyc3QsIEkgd2FzIHJlYWxseSBv cHBvc2VkIHRvIHRoZSBleHRlbnNpb24tc3RtdCwKPiBtb3N0bHkgYmVjYXVzZSBJIGRpZG4ndCB3 YW50IHRvIGVuY291cmFnZSBub24tc3RhbmRhcmQgbWVjaGFuaXNtcy4KClRoZSBleHRlbnNpb24g c3RhdGVtZW50IGlzIGxhbWUuIFRoaXMgaXMgYmVjYXVzZSBZQU5HIHN5bnRheCBpcyBkZWZpbmVk CmJ5IHRoZSBBQk5GIGdyYW1tYXIgYW5kIHRoaXMgaXMgd2hlcmUgdGhlIGV4dGVuc2lvbiBzaG91 bGQgYmUgZm9ybWFsbHkKc3BlY2lmaWVkLiBUaGUgZXh0ZW5zaW9uIHN0YXRlbWVudCBkb2VzIGl0 IGF0IGEgd3JvbmcgbGV2ZWwuIEl0IGlzIGFzIGlmCmEgc3RhdGVtZW50IGluIGEgcHJvZ3JhbW1p bmcgbGFuZ3VhZ2UgY291bGQgY2hhbmdlIHRoZSBncmFtbWFyIG9mIHRoZQpsYW5ndWFnZS4gVGhp cyBjb3VsZCBsZWFkIHRvIGluY29uc2lzdGVuY2llcy4gRm9yIGV4YW1wbGU6IGNhbiBJIHVzZSB0 aGUKbmV3bHkgZGVmaW5lZCBzdGF0ZW1lbnQgYXMgYSBzdWJzdGF0ZW1lbnQgb2YgdGhlIGV4dGVu c2lvbiBzdGF0ZW1lbnQKdGhhdCBkZWZpbmVzIGl0LCBvciBiZWZvcmUgdGhlIGV4dGVuc2lvbiBz dGF0ZW1lbnQ/Cgo+IAo+IEJ1dCBub3cgSSB0aGluayB0aGV5IGFyZSBraW5kIG9mIHVzZWZ1bCwg YW5kIGVhc3kgdG8gcGFyc2UuCj4gRm9yIGV4YW1wbGUsIHRoZSBzbWlkdW1wIHByb2dyYW0gYWRk cyBleHRlbnNpb25zIHRoYXQgYXJlIHNwZWNpYWxpemVkIGZvcgo+IE5FVENPTkYgYXBwbGljYXRp b25zIHRoYXQgd2FudCBhY2Nlc3MgdG8gU01JdjIgZGVmaW5lZCBkYXRhLgo+IFRoaXMgaXMgbm90 IHNvbWV0aGluZyB0aGF0IHNob3VsZCBiZSBidWlsdCBpbnRvIHRoZSBZQU5HIGxhbmd1YWdlLAo+ IGFuZCB0aGUgZXh0ZW5zaW9uLXN0bXQgaGFuZGxlcyBpdCB2ZXJ5IHdlbGwuCgpXaGF0IGhhcHBl bnMgaWYgc21pZHVtcCBqdXN0IGFkZHMgdGhlIGV4dGVuc2lvbnMgd2l0aG91dCBkZWNsYXJpbmcg dGhlbQp2aWEgZXh0ZW5zaW9uLXN0bXQ/CiAKPiAKPiBJdCBpcyBwb3NzaWJsZSB0byBkZXNpZ24g dG9vbHMgd2hpY2ggYWxsb3cgdGhlIHVzZXIgdG8KPiBhdHRhY2ggZnVuY3Rpb25hbGl0eSB0byB0 aGUgZXh0ZW5zaW9ucy4gIEF0IGEgbWluaW11bSwKPiB0b29scyBjYW4gZ2F0aGVyIHRoZSBleHRl bnNpb25zIHVzZWQgd2l0aGluIGVhY2ggY29uc3RydWN0Cj4gYW5kIG1ha2UgdGhlbSBhdmFpbGFi bGUgd2l0aGluIHRoZSBtYW5hZ2VyIG9yIGFnZW50IGFzIG1ldGEtZGF0YS4KClJpZ2h0LCBhbmQg ZXZlcnkgc3VjaCBwcm9ncmFtIGhhcyB0byBjaGVjayB0aGF0IHRoZSB1c2Ugb2YgdGhlCmV4dGVu c2lvbnMgaXMgc3ludGFjdGljYWxseSBjb3JyZWN0LCB3aGljaCB0aGUgZXh0ZW5zaW9uIHN0YXRl bWVudApkb2Vzbid0LgoKTGFkYSAKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5 IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri Jun 27 08:45: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 545D228C1B2; Fri, 27 Jun 2008 08:45: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 521E228C1AA for ; Fri, 27 Jun 2008 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 KO+P1rLMFp7S for ; Fri, 27 Jun 2008 08:45:36 -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 39EF028C1A4 for ; Fri, 27 Jun 2008 08:45:28 -0700 (PDT) Received: (qmail 97678 invoked from network); 27 Jun 2008 15:45:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.228.164 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 27 Jun 2008 15:45:28 -0000 X-YMail-OSG: h1n9jNQVM1kWt8xeKOUez1hE9q8qyAfHWg3lQVlvgYiPHcPqWH6oWncHNriZUjkX15FHE10aQTxZhgX4Ynu6LonVEJ_6pEA1tjCtvEL8MYtrzjAB2_HS._oesgH18HQW_TIcQaDe4YBDoDc6EM.7Gw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48650B17.6070500@netconfcentral.com> Date: Fri, 27 Jun 2008 08:45:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200806271405.m5RE5D1w096333@idle.juniper.net> <4864FC55.2080903@netconfcentral.com> <1214580213.7246.47.camel@missotis> In-Reply-To: <1214580213.7246.47.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQw6EgMjcuIDA2 LiAyMDA4IHYgMDc6NDIgLTA3MDA6Cj4gCj4+IEkgYWdyZWUgd2l0aCBQaGlsIG9uIHRoaXMgb25l Lgo+PiBBdCBmaXJzdCwgSSB3YXMgcmVhbGx5IG9wcG9zZWQgdG8gdGhlIGV4dGVuc2lvbi1zdG10 LAo+PiBtb3N0bHkgYmVjYXVzZSBJIGRpZG4ndCB3YW50IHRvIGVuY291cmFnZSBub24tc3RhbmRh cmQgbWVjaGFuaXNtcy4KPiAKPiBUaGUgZXh0ZW5zaW9uIHN0YXRlbWVudCBpcyBsYW1lLiBUaGlz IGlzIGJlY2F1c2UgWUFORyBzeW50YXggaXMgZGVmaW5lZAo+IGJ5IHRoZSBBQk5GIGdyYW1tYXIg YW5kIHRoaXMgaXMgd2hlcmUgdGhlIGV4dGVuc2lvbiBzaG91bGQgYmUgZm9ybWFsbHkKPiBzcGVj aWZpZWQuIFRoZSBleHRlbnNpb24gc3RhdGVtZW50IGRvZXMgaXQgYXQgYSB3cm9uZyBsZXZlbC4g SXQgaXMgYXMgaWYKPiBhIHN0YXRlbWVudCBpbiBhIHByb2dyYW1taW5nIGxhbmd1YWdlIGNvdWxk IGNoYW5nZSB0aGUgZ3JhbW1hciBvZiB0aGUKPiBsYW5ndWFnZS4gVGhpcyBjb3VsZCBsZWFkIHRv IGluY29uc2lzdGVuY2llcy4gRm9yIGV4YW1wbGU6IGNhbiBJIHVzZSB0aGUKPiBuZXdseSBkZWZp bmVkIHN0YXRlbWVudCBhcyBhIHN1YnN0YXRlbWVudCBvZiB0aGUgZXh0ZW5zaW9uIHN0YXRlbWVu dAo+IHRoYXQgZGVmaW5lcyBpdCwgb3IgYmVmb3JlIHRoZSBleHRlbnNpb24gc3RhdGVtZW50Pwo+ IAoKSU1PIHRoZSBleHRlbnNpb24tc3RtdCBpcyBhIGdvb2QgY29tcHJvbWlzZSBiZXR3ZWVuIHN0 YW5kYXJkcyBuZWVkcwphbmQgdmVuZG9yIG5lZWRzLiAgSXQgYWxsb3dzIGhvb2tzIHRvIGJlIGFk ZGVkLCBuZXcgZXhwZXJpbWVudGFsCmNvbnN0cnVjdHMgdG8gYmUgdGVzdGVkLCBidXQgaXQgZG9l cyBub3QgYWxsb3cgZXZlcnlvbmUgdG8KY3JlYXRlIHRoZWlyIG93biB2ZXJzaW9uIG9mIFlBTkcu ICBUaGF0IGtpbmQgb2YgZmxleGliaWxpdHkKZG9lcyBub3QgaGVscCBpbnRlcm9wZXJhYmlsaXR5 LgoKCj4+IEJ1dCBub3cgSSB0aGluayB0aGV5IGFyZSBraW5kIG9mIHVzZWZ1bCwgYW5kIGVhc3kg dG8gcGFyc2UuCj4+IEZvciBleGFtcGxlLCB0aGUgc21pZHVtcCBwcm9ncmFtIGFkZHMgZXh0ZW5z aW9ucyB0aGF0IGFyZSBzcGVjaWFsaXplZCBmb3IKPj4gTkVUQ09ORiBhcHBsaWNhdGlvbnMgdGhh dCB3YW50IGFjY2VzcyB0byBTTUl2MiBkZWZpbmVkIGRhdGEuCj4+IFRoaXMgaXMgbm90IHNvbWV0 aGluZyB0aGF0IHNob3VsZCBiZSBidWlsdCBpbnRvIHRoZSBZQU5HIGxhbmd1YWdlLAo+PiBhbmQg dGhlIGV4dGVuc2lvbi1zdG10IGhhbmRsZXMgaXQgdmVyeSB3ZWxsLgo+IAo+IFdoYXQgaGFwcGVu cyBpZiBzbWlkdW1wIGp1c3QgYWRkcyB0aGUgZXh0ZW5zaW9ucyB3aXRob3V0IGRlY2xhcmluZyB0 aGVtCj4gdmlhIGV4dGVuc2lvbi1zdG10Pwo+CgpUaGF0J3Mgd2hhdCBoYXBwZW5lZCBhdCBmaXJz dCwgYW5kIHlhbmdkdW1wIGdlbmVyYXRlZCBlcnJvcnMKZm9yIGV2ZXJ5IGxlYWYgOi0oICAgVGhl biBKdWVyZ2VuIGFkZGVkIHlhbmctc21pLnlhbmcKd2l0aCB0aGUgZXh0ZW5zaW9ucy4gIFlhbmdk dW1wIGNoZWNrcyB0aGUgZm9sbG93aW5nOgogICAtIGV4dGVuc2lvbiBpcyBkZWZpbmVkIGluIHRo ZSBzcGVjaWZpZWQgbW9kdWxlCiAgIC0gYXJndW1lbnQgc2hvdWxkIG1hdGNoIHRoZSAybmQgZmll bGQgKHByZXNlbnQgb3Igbm90KQoKSXQgaXMgdHJ1ZSB0aGF0IHRoZSBjb21waWxlciBjYW5ub3Qg dmFsaWRhdGUgdGhhdCB0aGUgcHJvcGVyCnN1Yi1maWVsZHMgKGlmIGFueSkgYXJlIHByZXNlbnQg aW4gYW4gZXh0ZW5zaW9uIHVzYWdlLApiYXNlZCBvbiB0aGUgZXh0ZW5zaW9uLXN0bXQuICBUaGF0 J3MgT0ssIGJlY2F1c2UgdGhlCmxvdy1sZXZlbCBwYXJzaW5nIGlzIHRoZSBzYW1lIGFzIHdoYXQg c3RhbmRhcmQgWUFORyB1c2VzLAphbmQgaWYgbXkgdG9vbCBkb2Vzbid0IHVuZGVyc3RhbmQgdGhl IGV4dGVuc2lvbiwgaXQgY2FuIHN0aWxsCnNhdmUgaXQgYXMgJ2FwcGluZm8nLgoKCgo+PiBJdCBp cyBwb3NzaWJsZSB0byBkZXNpZ24gdG9vbHMgd2hpY2ggYWxsb3cgdGhlIHVzZXIgdG8KPj4gYXR0 YWNoIGZ1bmN0aW9uYWxpdHkgdG8gdGhlIGV4dGVuc2lvbnMuICBBdCBhIG1pbmltdW0sCj4+IHRv b2xzIGNhbiBnYXRoZXIgdGhlIGV4dGVuc2lvbnMgdXNlZCB3aXRoaW4gZWFjaCBjb25zdHJ1Y3QK Pj4gYW5kIG1ha2UgdGhlbSBhdmFpbGFibGUgd2l0aGluIHRoZSBtYW5hZ2VyIG9yIGFnZW50IGFz IG1ldGEtZGF0YS4KPiAKPiBSaWdodCwgYW5kIGV2ZXJ5IHN1Y2ggcHJvZ3JhbSBoYXMgdG8gY2hl Y2sgdGhhdCB0aGUgdXNlIG9mIHRoZQo+IGV4dGVuc2lvbnMgaXMgc3ludGFjdGljYWxseSBjb3Jy ZWN0LCB3aGljaCB0aGUgZXh0ZW5zaW9uIHN0YXRlbWVudAo+IGRvZXNuJ3QuCj4gCgpJZiBteSB0 b29sIGRvZXMgdW5kZXJzdGFuZCB0aGUgZXh0ZW5zaW9uLCB0aGVuIGl0IGNhbiBkbwphbGwgdGhl IHZhbGlkYXRpb24gbmVlZGVkIHdpdGhpbiB0aGUgY29kZS4gIElmIGl0IGRvZXNuJ3QKdW5kZXJz dGFuZCB0aGUgZXh0ZW5zaW9uLCB0aGVuIHRoZXJlIGlzbid0IG11Y2ggdmFsdWUKaW4gdmFsaWRh dGluZyB0aGUgbmVzdGVkIHN1Yi1jbGF1c2VzLiAgU3RhbmRhcmQgWUFORyBpcwpkaWZmZXJlbnQu ICBJIGNhbid0IGp1c3QgaWdub3JlIGEgcmFuZ2Utc3RtdCB3aXRob3V0CmJyZWFraW5nIHNvbWV0 aGluZyBhbmQgYmVpbmcgbm9uLWNvbXBsaWFudC4gIEV4dGVuc2lvbnMKYXJlIG9wdGlvbmFsLiAg T25seSBhbiBhZ2VudCBpbXBsZW1lbnRpbmcvYWR2ZXJ0aXNpbmcKdGhlIG1vZHVsZSBjb250YWlu aW5nIHRoZSBleHRlbnNpb24tc3RtdCBpcyBleHBlY3RlZCB0byBzdXBwb3J0IGl0LgoKCj4gTGFk YSAKPiAKCkFuZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri Jun 27 10:07: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 2AE603A67E6; Fri, 27 Jun 2008 10:07: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 C49213A67E6 for ; Fri, 27 Jun 2008 10:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.267, 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 n9ESiB1LXURa for ; Fri, 27 Jun 2008 10:07:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EA04A3A6768 for ; Fri, 27 Jun 2008 10:07:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0431C0037; Fri, 27 Jun 2008 19:07:36 +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 T1lmwVR1kbbR; Fri, 27 Jun 2008 19:07:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1728EC0034; Fri, 27 Jun 2008 19:07:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66C545E20D2; Fri, 27 Jun 2008 19:07:29 +0200 (CEST) Date: Fri, 27 Jun 2008 19:07:29 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080627170729.GA4121@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , netmod@ietf.org References: <200806271405.m5RE5D1w096333@idle.juniper.net> <4864FC55.2080903@netconfcentral.com> <1214580213.7246.47.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1214580213.7246.47.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] overlays 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, Jun 27, 2008 at 05:23:33PM +0200, Ladislav Lhotka wrote: > The extension statement is lame. This is because YANG syntax is defined > by the ABNF grammar and this is where the extension should be formally > specified. The extension statement does it at a wrong level. It is as if > a statement in a programming language could change the grammar of the > language. This could lead to inconsistencies. For example: can I use the > newly defined statement as a substatement of the extension statement > that defines it, or before the extension statement? The extension statement does not "define" an extension, it just "declares" the existence of an extension. In SMIng, we did embed ABNF in the extension statement but if was clear that nobody would like to write an ABNF runtime interpreter - so the ABNF was more meant as documentation. In addition, I note that while ABNF is great for capturing some properties, it does not catch everything you expect from to be catched by a compiler which implements all the semantics of a statement. In other words, I assume we agree that the _definition_ of a YANG extension is out of scope for YANG itself. So the question left is whether the _declaration_ of an extensions is useful to have or not. I personally find it nice if generic tools (that do not necessarily implement all possible extensions) can identify all undeclared extensions used in a module; some of them might be simply typos. /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 Jun 27 10:15: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 6E43C3A697F; Fri, 27 Jun 2008 10:15: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 B37EF3A697F for ; Fri, 27 Jun 2008 10:15: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 529V69rpMcSw for ; Fri, 27 Jun 2008 10:15:10 -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 E97C63A68E8 for ; Fri, 27 Jun 2008 10:15:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KaZ3c4EmoQ4xRjDkLSxgpT3hFrkuAhfh/nTycFzsHKey0V59gUUefA2YoOfHxNT5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.89.179] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KCHER-0002FV-Tj for netmod@ietf.org; Fri, 27 Jun 2008 12:55:32 -0400 Message-ID: <004301c8d876$d0718420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200806271405.m5RE5D1w096333@idle.juniper.net> Date: Fri, 27 Jun 2008 09:56: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3dbe147e0bc7098774c3643bb7cb84164350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.179 Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Ladislav Lhotka" > Cc: > Sent: Friday, June 27, 2008 7:05 AM > Subject: Re: [netmod] overlays ... > How is an external text file a win? ... If the annotations go beyond the externally visible "adjustments" to the management interface, the ability to put stuff in an external text file is a huge win from a source-code configuration management perspective. Been there, done that with MIB compilers. I think there are two categories of stuff here. Applying the "adjustments" to the management interface defined by the file should effectively result in a new interface definition, which would be darn convenient to have available as a single file, possibly an output of the processing. Applying the "elaborations" (annotations having to do with the guts of the implementation, such as data structure or callback bindings) would obviously be very specific to a particular implementation environment, and out of our scope here. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 27 11:55: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 97DB33A68DD; Fri, 27 Jun 2008 11:55: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 2D8F83A68DD for ; Fri, 27 Jun 2008 11:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 JQok0ZjXinuQ for ; Fri, 27 Jun 2008 11:55:04 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 2CE463A68B4 for ; Fri, 27 Jun 2008 11:55:01 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Fri, 27 Jun 2008 11:54:03 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 11:54:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 11:54:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 11:54:02 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5RIs1x82664; Fri, 27 Jun 2008 11:54:01 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5RIpQaI098016; Fri, 27 Jun 2008 18:51:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806271851.m5RIpQaI098016@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1214580213.7246.47.camel@missotis> Date: Fri, 27 Jun 2008 14:51:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Jun 2008 18:54:02.0421 (UTC) FILETIME=[2A6FBE50:01C8D887] Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.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 extension statement is lame. This is because YANG syntax is defined >by the ABNF grammar and this is where the extension should be formally >specified. The extension statement does it at a wrong level. It is as if >a statement in a programming language could change the grammar of the >language. This could lead to inconsistencies. The ABNF defines the grammar, which allows for extensions. The extension statement declares the extension. Using undeclared extensions is an error. This is similar to defining structs in C. The C language defines how they are used, but you need to declare them before using them. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jun 27 13:05: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 46C5A3A6B40; Fri, 27 Jun 2008 13:05: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 EED403A6B59 for ; Fri, 27 Jun 2008 13:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwPrVlvCb6DQ for ; Fri, 27 Jun 2008 13:05:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2AF4E3A6821 for ; Fri, 27 Jun 2008 13:05:35 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DD607D800CE; Fri, 27 Jun 2008 22:05:39 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080627170729.GA4121@elstar.local> References: <200806271405.m5RE5D1w096333@idle.juniper.net> <4864FC55.2080903@netconfcentral.com> <1214580213.7246.47.camel@missotis> <20080627170729.GA4121@elstar.local> Organization: CESNET Date: Fri, 27 Jun 2008 22:05:40 +0200 Message-Id: <1214597140.7246.61.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFDDoSAyNy4gMDYuIDIwMDggdiAxOTowNyAr MDIwMDoKPiBJbiBvdGhlciB3b3JkcywgSSBhc3N1bWUgd2UgYWdyZWUgdGhhdCB0aGUgX2RlZmlu aXRpb25fIG9mIGEgWUFORwo+IGV4dGVuc2lvbiBpcyBvdXQgb2Ygc2NvcGUgZm9yIFlBTkcgaXRz ZWxmLiBTbyB0aGUgcXVlc3Rpb24gbGVmdCBpcwo+IHdoZXRoZXIgdGhlIF9kZWNsYXJhdGlvbl8g b2YgYW4gZXh0ZW5zaW9ucyBpcyB1c2VmdWwgdG8gaGF2ZSBvciBub3QuCgpQZXJoYXBzIGEgZGVj bGFyYXRpb24gb2YgYSBuYW1lc3BhY2UgYW5kIHByZWZpeCB1c2VkIGZvciB0aGUgZXh0ZW5zaW9u cwpjb3VsZCBiZSBzdWZmaWNpZW50LiBBbmQgb2YgY291cnNlLCB0aGUgZXh0ZW5zaW9uIHN0YXRl bWVudHMgbXVzdCBmb2xsb3cKdGhlIGdlbmVyYWwgc3RydWN0dXJlIG9mIFlBTkcgc3RhdGVtZW50 cy4KCj4gCj4gSSBwZXJzb25hbGx5IGZpbmQgaXQgbmljZSBpZiBnZW5lcmljIHRvb2xzICh0aGF0 IGRvIG5vdCBuZWNlc3NhcmlseQo+IGltcGxlbWVudCBhbGwgcG9zc2libGUgZXh0ZW5zaW9ucykg Y2FuIGlkZW50aWZ5IGFsbCB1bmRlY2xhcmVkCj4gZXh0ZW5zaW9ucyB1c2VkIGluIGEgbW9kdWxl OyBzb21lIG9mIHRoZW0gbWlnaHQgYmUgc2ltcGx5IHR5cG9zLgoKSWYgSSBjYW4ndCBkbyBhbnl0 aGluZyB3aXRoIHRoZSBzdGF0ZW1lbnQsIHRoZW4gaXQgaXMgcHJldHR5IG11Y2gKaXJyZWxldmFu dCB3aGV0aGVyIGl0IGNvbnRhaW5zIHR5cG9zIG9yIG5vdC4KCkxhZGEKCi0tIApMYWRpc2xhdiBM aG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri Jun 27 13:13: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 A37CB3A6821; Fri, 27 Jun 2008 13:13: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 415AB3A6821 for ; Fri, 27 Jun 2008 13:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.253, 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 j26oKn8L5TCC for ; Fri, 27 Jun 2008 13:13:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 410A43A67AD for ; Fri, 27 Jun 2008 13:13:43 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6765C0008; Fri, 27 Jun 2008 22:13:47 +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 NOH7xBVR36QM; Fri, 27 Jun 2008 22:13: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 7CD92C0037; Fri, 27 Jun 2008 22:13:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BD8445E2C5D; Fri, 27 Jun 2008 22:13:38 +0200 (CEST) Date: Fri, 27 Jun 2008 22:13:38 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080627201338.GA8175@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , netmod@ietf.org References: <200806271405.m5RE5D1w096333@idle.juniper.net> <4864FC55.2080903@netconfcentral.com> <1214580213.7246.47.camel@missotis> <20080627170729.GA4121@elstar.local> <1214597140.7246.61.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1214597140.7246.61.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] overlays 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, Jun 27, 2008 at 10:05:40PM +0200, Ladislav Lhotka wrote: > > I personally find it nice if generic tools (that do not necessarily > > implement all possible extensions) can identify all undeclared > > extensions used in a module; some of them might be simply typos. > > If I can't do anything with the statement, then it is pretty much > irrelevant whether it contains typos or not. We don't have to agree here. You seem to assume that every module writer uses the same tools as a model implementor, which is not generally true, at least not in the SMI space. /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 Jun 27 13: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 8E0503A6B1C; Fri, 27 Jun 2008 13: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 1E5C73A6B1C for ; Fri, 27 Jun 2008 13:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=0.186, 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 JCAOujbLoysz for ; Fri, 27 Jun 2008 13:20:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5A1C43A67AD for ; Fri, 27 Jun 2008 13:20:29 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5FC3ED800CE; Fri, 27 Jun 2008 22:20:34 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200806271851.m5RIpQaI098016@idle.juniper.net> References: <200806271851.m5RIpQaI098016@idle.juniper.net> Organization: CESNET Date: Fri, 27 Jun 2008 22:20:35 +0200 Message-Id: <1214598035.7246.74.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgUMOhIDI3LiAwNi4gMjAwOCB2IDE0OjUxIC0wNDAwOgoKPiBU aGlzIGlzIHNpbWlsYXIgdG8gZGVmaW5pbmcgc3RydWN0cyBpbiBDLiAgVGhlIEMgbGFuZ3VhZ2Ug ZGVmaW5lcwo+IGhvdyB0aGV5IGFyZSB1c2VkLCBidXQgeW91IG5lZWQgdG8gZGVjbGFyZSB0aGVt IGJlZm9yZSB1c2luZyB0aGVtLgo+IAoKQWN0dWFsbHkgQyBzdHJ1Y3R1cmVzIGFsd2F5cyBoYXZl IHRvIGJlIGRlZmluZWQsIHRvby4gQyBzdHJ1Y3R1cmVzIGFyZQpjb21wYXJhYmxlIHRvIFlBTkcg Z3JvdXBpbmdzLiBPbiB0aGUgb3RoZXIgaGFuZCwgYW4gZXh0ZW5zaW9uIHN0YXRlbWVudApkZWNs YXJlcyBhIG5ldyBzdGF0ZW1lbnQgYW5kIHRoZXJlIGlzIG5vIGFuYWxvZ3kgZm9yIGl0IGluIEMg b3IgYW55Cm90aGVyIGxhbmd1YWdlIEkgYW0gYXdhcmUgb2YuCgpMYWRhCgotLSAKTGFkaXNsYXYg TGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Fri Jun 27 14:38: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 4D50728C201; Fri, 27 Jun 2008 14:38: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 C114328C201 for ; Fri, 27 Jun 2008 14:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 p1vuajXYFiHM for ; Fri, 27 Jun 2008 14:38:51 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id C56B628C1FF for ; Fri, 27 Jun 2008 14:38:49 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 27 Jun 2008 14:37:53 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, 27 Jun 2008 14:37:58 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 14:37:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 14:33:02 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m5RLX1x32732; Fri, 27 Jun 2008 14:33:02 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m5RLUR0V099503; Fri, 27 Jun 2008 21:30:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806272130.m5RLUR0V099503@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1214598035.7246.74.camel@missotis> Date: Fri, 27 Jun 2008 17:30:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Jun 2008 21:33:02.0714 (UTC) FILETIME=[60E4EDA0:01C8D89D] Cc: netmod@ietf.org Subject: Re: [netmod] overlays X-BeenThere: netmod@ietf.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: >Actually C structures always have to be defined, too. C structures are >comparable to YANG groupings. On the other hand, an extension statement >declares a new statement and there is no analogy for it in C or any >other language I am aware of. XML ;^) But seriously, the ability to define values for language tokens is universal in languages. In YANG, we just allow the definition of the token that appears as a peer to the built-in YANG statements. Allowing random stuff that isn't defined anywhere would make for a bad language. (XML? ;^) (Sorry, couldn't resist) Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jun 28 18:52: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 89F1E3A67AB; Sat, 28 Jun 2008 18:52: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 5BD123A67AB for ; Sat, 28 Jun 2008 18:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrPFs5xsQI5t for ; Sat, 28 Jun 2008 18:52:41 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 56C643A67A1 for ; Sat, 28 Jun 2008 18:52:38 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA04.westchester.pa.mail.comcast.net with comcast id jQVV1Z00F0xGWP8540vv00; Sun, 29 Jun 2008 01:52:46 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA12.westchester.pa.mail.comcast.net with comcast id jdsY1Z0021m6Z1J3YdsdPh; Sun, 29 Jun 2008 01:52:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=Ng6Huk5TjN0toCiumlsA:9 a=ssii6g0CnExUldFUE95SJD1kCwsA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Sun, 29 Jun 2008 09:52:31 +0800 Message-ID: <033b01c8d98a$d1a67340$51f780de@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: AcjZisrl+YgG3iFqTCqiYjv1TU73AA== Subject: [netmod] IETF72 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, IETF72 is approaching. We need documents published and presentations prepared. Publication deadlines are July 7 for -00- drafts and July 14 for -01- drafts. The netmod charter calls for: Jun 2008 All _individual_ drafts available that will be used as input into the WG documents (draft-bjorklund-yang, architecture draft, YIN draft, YANG standard library draft, DSDL mapping rules draft) = Who is willing to step forward to get these published before the IETF72 deadline? 1) YANG: Martin Bj=F6rklund; will there be a -01-? 2) draft-schoenw-netmod-yang-types: J=FCrgen; will there be a -01-? 3) YIN draft: will this be split out? I assume no before ietf72 (and possibly never) 4) architecture draft: ??? Let me point out that are still waiting for a written discussion of the meta-data stuff. 5) DSDL mapping rules draft: ??? The charter is ambiguous on the deadline, but mentions reaching consensus in Dublin, so we should have an individual draft before the -00- deadline. We also need presentations discussing the directions and open issues. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jun 28 22: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 BA10C3A6A20; Sat, 28 Jun 2008 22: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 A6E453A6A20 for ; Sat, 28 Jun 2008 22:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.240, 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 odURyBcI6WZ7 for ; Sat, 28 Jun 2008 22:35:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2E623A67B2 for ; Sat, 28 Jun 2008 22:35:12 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08E2DC0017; Sun, 29 Jun 2008 07:35:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u7MH5Ydk+J-c; Sun, 29 Jun 2008 07:35:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A603EC0010; Sun, 29 Jun 2008 07:35:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C41EE5E34FA; Sun, 29 Jun 2008 07:35:13 +0200 (CEST) Date: Sun, 29 Jun 2008 07:35:13 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080629053513.GA9280@elstar.local> Mail-Followup-To: David Harrington , netmod@ietf.org References: <033b01c8d98a$d1a67340$51f780de@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <033b01c8d98a$d1a67340$51f780de@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] IETF72 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sun, Jun 29, 2008 at 09:52:31AM +0800, David Harrington wrote: > 2) draft-schoenw-netmod-yang-types: J?rgen; will there be a -01-? Very likely. There have been several changes since the -00 version. /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 Jun 29 00:34: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 6BA0C3A67DB; Sun, 29 Jun 2008 00:34: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 2C7D73A67DB for ; Sun, 29 Jun 2008 00:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=0.162, 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 R5WKMotFCo7W for ; Sun, 29 Jun 2008 00:34:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6AF143A67B2 for ; Sun, 29 Jun 2008 00:34:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B1DE0D800CE for ; Sun, 29 Jun 2008 09:34:32 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <033b01c8d98a$d1a67340$51f780de@china.huawei.com> References: <033b01c8d98a$d1a67340$51f780de@china.huawei.com> Organization: CESNET Date: Sun, 29 Jun 2008 09:34:32 +0200 Message-Id: <1214724872.11160.2.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] IETF72 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 RGF2aWQgSGFycmluZ3RvbiBww63FoWUgdiBOZSAyOS4gMDYuIDIwMDggdiAwOTo1MiArMDgwMDoK PiA1KSBEU0RMIG1hcHBpbmcgcnVsZXMgZHJhZnQ6ID8/Pwo+IAlUaGUgY2hhcnRlciBpcyBhbWJp Z3VvdXMgb24gdGhlIGRlYWRsaW5lLCBidXQgbWVudGlvbnMKPiByZWFjaGluZyBjb25zZW5zdXMg aW4gRHVibGluLCBzbwo+IAl3ZSBzaG91bGQgaGF2ZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IGJlZm9y ZSB0aGUgLTAwLSBkZWFkbGluZS4KPiAKSSBhbSB3b3JraW5nIG9uIHRoZSBtYXBwaW5nIGRyYWZ0 IGFuZCBvbiB0aGUgcGx1Z2luIGZvciBweWFuZyBpbgpwYXJhbGxlbCwgSSB3aWxsIGRvIG15IGJl c3QgdG8gZmluaXNoIGJvdGggdGlsbCA3IEp1bHkuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGth LCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jun 30 14:07: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 507A73A6A73; Mon, 30 Jun 2008 14:07: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 970CF3A6A95 for ; Mon, 30 Jun 2008 14:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZOPmZCYLVcX for ; Mon, 30 Jun 2008 14:07:54 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id D4DA83A6838 for ; Mon, 30 Jun 2008 14:07:53 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id C6F961B80C5; Mon, 30 Jun 2008 23:08:03 +0200 (CEST) Date: Mon, 30 Jun 2008 23:08:04 +0200 (CEST) Message-Id: <20080630.230804.22971651.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <033b01c8d98a$d1a67340$51f780de@china.huawei.com> References: <033b01c8d98a$d1a67340$51f780de@china.huawei.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] IETF72 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, "David Harrington" wrote: > 1) YANG: Martin Bj=F6rklund; will there be a -01-? No. > 3) YIN draft: will this be split out? I assume no before ietf72 (and > possibly never) No; not before IETF72, and I vote never. > We also need presentations discussing the directions and open issues. My plan is to compile a list of open issues and questions for the YANG language, which I would like to present. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod