From netmod-bounces@ietf.org Wed Jul 2 00:15: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 5340F3A6B36; Wed, 2 Jul 2008 00:15: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 4FEDF3A6A89 for ; Wed, 2 Jul 2008 00:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.121, 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 AR3chiSmtVib for ; Wed, 2 Jul 2008 00:15:55 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 894733A68F4 for ; Wed, 2 Jul 2008 00:15: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 7055A1B80CC for ; Wed, 2 Jul 2008 09:16:03 +0200 (CEST) Date: Wed, 02 Jul 2008 09:16:23 +0200 (CEST) Message-Id: <20080702.091623.190514914.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] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, As we have discussed earlier, we don't currently have a fine grained agent conformance mechanism, and it seems consensus is to not do this now (with the possible exception of when-capability). This means that a server that claims conformance to a module must implement it fully (modulo when-capability). But this makes a 'deprected' object problematic. If an object is deprecated, it means: "deprecated" indicates an obsolete definition, but it permits new/continued implementation in order to foster interoperability with older/existing implementations. So a client knows that a server fully implements a module, but if there are any deprecated objects, it doesn't know if those objects are implemented or not. Can we remove 'deprected' and use 'current' and 'obsolete' only? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 2 00:42: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 DDBC23A6B59; Wed, 2 Jul 2008 00:42: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 CA82A3A6B59 for ; Wed, 2 Jul 2008 00:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.218, 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 uoGd4rgliUYE for ; Wed, 2 Jul 2008 00:42: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 89BFC3A6B36 for ; Wed, 2 Jul 2008 00:42:03 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DA28C0054; Wed, 2 Jul 2008 09:42:13 +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 MrWTqUiNJbvD; Wed, 2 Jul 2008 09:42:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57B10C005A; Wed, 2 Jul 2008 09:42:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2FDAD5E99B8; Wed, 2 Jul 2008 09:42:04 +0200 (CEST) Date: Wed, 2 Jul 2008 09:42:04 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080702074204.GC850@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20080702.091623.190514914.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080702.091623.190514914.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Jul 02, 2008 at 09:16:23AM +0200, Martin Bjorklund wrote: > As we have discussed earlier, we don't currently have a fine grained > agent conformance mechanism, and it seems consensus is to not do this now > (with the possible exception of when-capability). > > This means that a server that claims conformance to a module must > implement it fully (modulo when-capability). > > But this makes a 'deprected' object problematic. If an object is > deprecated, it means: > > "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster > interoperability with older/existing implementations. > > So a client knows that a server fully implements a module, but if > there are any deprecated objects, it doesn't know if those objects are > implemented or not. > > Can we remove 'deprected' and use 'current' and 'obsolete' only? The assumption that every implementation will implement modules fully is an illusion if you ask me. I think the distinction between obsolete and deprecated has been useful in the SMI space and so I would not easily give it up. /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 Jul 2 01:41: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 2E8653A6C12; Wed, 2 Jul 2008 01:41: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 141743A6C12 for ; Wed, 2 Jul 2008 01:41:37 -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 ylrsnLfC1dZ6 for ; Wed, 2 Jul 2008 01:41:36 -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 394D33A6BFD for ; Wed, 2 Jul 2008 01:41:35 -0700 (PDT) Received: (qmail 46932 invoked from network); 2 Jul 2008 08:41:45 -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; 2 Jul 2008 08:41:43 -0000 X-YMail-OSG: UDvPuxoVM1kmDIK7YO2qtU2x0R1OFzyvf242yEtxmQi3HjHiDe6PP8SUPTKfuco7s8qA1g3oNInebuqRL.fmxKJ7pbMiUEh8ZUHWPfEnCGvz9fWY9HsDyPfS1sAMjipCvyo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <486B3F45.1010802@netconfcentral.com> Date: Wed, 02 Jul 2008 01:41:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund , netmod@ietf.org References: <20080702.091623.190514914.mbj@tail-f.com> <20080702074204.GC850@elstar.local> In-Reply-To: <20080702074204.GC850@elstar.local> Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Wed, Jul 02, 2008 at 09:16:23AM +0200, Martin Bjorklund wrote: > >> As we have discussed earlier, we don't currently have a fine grained >> agent conformance mechanism, and it seems consensus is to not do this now >> (with the possible exception of when-capability). >> >> This means that a server that claims conformance to a module must >> implement it fully (modulo when-capability). >> >> But this makes a 'deprected' object problematic. If an object is >> deprecated, it means: >> >> "deprecated" indicates an obsolete definition, but it permits >> new/continued implementation in order to foster >> interoperability with older/existing implementations. >> >> So a client knows that a server fully implements a module, but if >> there are any deprecated objects, it doesn't know if those objects are >> implemented or not. >> >> Can we remove 'deprected' and use 'current' and 'obsolete' only? > > The assumption that every implementation will implement modules fully > is an illusion if you ask me. I think the distinction between obsolete > and deprecated has been useful in the SMI space and so I would not > easily give it up. > deprecated serves a very useful purpose -- it means the feature is supported now, but it will go away in the future. It is needed to phase out old API mechanisms, instead of eliminating them abruptly from version N to N+1. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 2 02:41: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 F01CB3A688C; Wed, 2 Jul 2008 02:41: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 C8F4F3A688C for ; Wed, 2 Jul 2008 02:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 wjlF6dnEPNis for ; Wed, 2 Jul 2008 02:41:49 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id C2F423A6780 for ; Wed, 2 Jul 2008 02:41:49 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id kxhJ1Z0070FhH24A200A00; Wed, 02 Jul 2008 09:41:59 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id kxhj1Z0031m6Z1J8UxhmCM; Wed, 02 Jul 2008 09:41:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=AHajoeWBSowFqDtEia8A:9 a=JLKjcTSqzf-s7eGDoSoA:7 a=hfQZkma36qcScojqqZDvaa3n_eEA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=GImYjLvvVJkA:10 From: "David Harrington" To: , "'Martin Bjorklund'" References: <20080702.091623.190514914.mbj@tail-f.com> <20080702074204.GC850@elstar.local> Date: Wed, 2 Jul 2008 17:41:42 +0800 Message-ID: <003e01c8dc27$de189f50$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjcFy3A5Ir4xjIpSzGZyeQFuWtmQgAEJggg In-Reply-To: <20080702074204.GC850@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org +1 dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, July 02, 2008 3:42 PM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] deprecated and conformance > > On Wed, Jul 02, 2008 at 09:16:23AM +0200, Martin Bjorklund wrote: > > > As we have discussed earlier, we don't currently have a fine grained > > agent conformance mechanism, and it seems consensus is to > not do this now > > (with the possible exception of when-capability). > > > > This means that a server that claims conformance to a module must > > implement it fully (modulo when-capability). > > > > But this makes a 'deprected' object problematic. If an object is > > deprecated, it means: > > > > "deprecated" indicates an obsolete definition, but it permits > > new/continued implementation in order to foster > > interoperability with older/existing implementations. > > > > So a client knows that a server fully implements a module, but if > > there are any deprecated objects, it doesn't know if those > objects are > > implemented or not. > > > > Can we remove 'deprected' and use 'current' and 'obsolete' only? > > The assumption that every implementation will implement modules fully > is an illusion if you ask me. I think the distinction between obsolete > and deprecated has been useful in the SMI space and so I would not > easily give it up. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 2 03:36: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 8D00A3A6962; Wed, 2 Jul 2008 03:36: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 49EFF3A68B3 for ; Wed, 2 Jul 2008 03:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.110, 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 YVatEYwTZqJs for ; Wed, 2 Jul 2008 03:36:31 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 7D0763A6840 for ; Wed, 2 Jul 2008 03:36: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 8E63D1B80CC; Wed, 2 Jul 2008 12:36:40 +0200 (CEST) Date: Wed, 02 Jul 2008 12:37:01 +0200 (CEST) Message-Id: <20080702.123701.210154767.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080702074204.GC850@elstar.local> References: <20080702.091623.190514914.mbj@tail-f.com> <20080702074204.GC850@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > The assumption that every implementation will implement modules fully > is an illusion if you ask me. I think the distinction between obsolete > and deprecated has been useful in the SMI space and so I would not > easily give it up. I agree with both statements. But I also think there is a real problem with the current spec. W/o any explicit conformance rules in the YANG spec, can a server claim conformance to a module if it implements one single object from the module? Do we really believe that we'll get interoperable configuration management from this? How is a client supposed to adapt to a server that - without any rules - implements some subset of a module? I think the best solution would be to have some kind of agent-capabilities, which a conformant server that implements a subset of a module would have to use. At a minimum, I think we need to write down in the spec what a conformant server can and must do while still claiming conformance to a module. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 2 04:00: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 E0C8B3A6A1C; Wed, 2 Jul 2008 04:00: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 E04CB3A69B6 for ; Wed, 2 Jul 2008 04:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 A+LOrqb3VsQX for ; Wed, 2 Jul 2008 04:00:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E34E43A693E for ; Wed, 2 Jul 2008 04:00:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A34CC0014; Wed, 2 Jul 2008 13:00:53 +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 gZFLnXgcVepz; Wed, 2 Jul 2008 13:00:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3476EC0057; Wed, 2 Jul 2008 13:00:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0EF965E9E21; Wed, 2 Jul 2008 13:00:47 +0200 (CEST) Date: Wed, 2 Jul 2008 13:00:46 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080702110046.GA1329@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20080702.091623.190514914.mbj@tail-f.com> <20080702074204.GC850@elstar.local> <20080702.123701.210154767.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080702.123701.210154767.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Jul 02, 2008 at 12:37:01PM +0200, Martin Bjorklund wrote: > But I also think there is a real problem with the current spec. W/o > any explicit conformance rules in the YANG spec, can a server claim > conformance to a module if it implements one single object from the > module? Do we really believe that we'll get interoperable > configuration management from this? How is a client supposed to adapt > to a server that - without any rules - implements some subset of a > module? > > I think the best solution would be to have some kind of > agent-capabilities, which a conformant server that implements a subset > of a module would have to use. > > At a minimum, I think we need to write down in the spec what a > conformant server can and must do while still claiming conformance to > a module. I believe we should get YANG 1.0 out and worry about this later. YANG module authors can still use English language to write down what needs to be implemented to be compliant and what is optional. We do this for protocols all the time. /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 Jul 2 05:23: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 C04C43A690D; Wed, 2 Jul 2008 05:23: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 B85933A690D for ; Wed, 2 Jul 2008 05:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 7lsN4Xn45tLJ for ; Wed, 2 Jul 2008 05:23:27 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B198B3A6867 for ; Wed, 2 Jul 2008 05:23:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,737,1204520400"; d="scan'208";a="133851959" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 02 Jul 2008 08:23:35 -0400 X-IronPort-AV: E=Sophos;i="4.27,737,1204520400"; d="scan'208";a="220998425" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Jul 2008 08:23:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jul 2008 14:23:32 +0200 Message-ID: In-Reply-To: <20080702110046.GA1329@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] deprecated and conformance Thread-Index: AcjcMujevqROBLTOQqeK52C1+RCPRQACxs+w References: <20080702.091623.190514914.mbj@tail-f.com><20080702074204.GC850@elstar.local><20080702.123701.210154767.mbj@tail-f.com> <20080702110046.GA1329@elstar.local> From: "Romascanu, Dan (Dan)" To: , "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Yes, and also - aren't we missing module compliance with agent capabilities. In SMI it is not the agent capabilities macro that dictates compliance, and one cannot claim compliance with a certain compliance profile without implementing all objects described in the respective compliance module. If we go on the agent-capabilities line, this would rather refer to the sum of different modules that the server complies to. Dan (speaking as contributor) > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, July 02, 2008 2:01 PM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] deprecated and conformance > > On Wed, Jul 02, 2008 at 12:37:01PM +0200, Martin Bjorklund wrote: > > > But I also think there is a real problem with the current > spec. W/o > > any explicit conformance rules in the YANG spec, can a server claim > > conformance to a module if it implements one single object from the > > module? Do we really believe that we'll get interoperable > > configuration management from this? How is a client > supposed to adapt > > to a server that - without any rules - implements some subset of a > > module? > > > > I think the best solution would be to have some kind of > > agent-capabilities, which a conformant server that > implements a subset > > of a module would have to use. > > > > At a minimum, I think we need to write down in the spec what a > > conformant server can and must do while still claiming > conformance to > > a module. > > I believe we should get YANG 1.0 out and worry about this > later. YANG module authors can still use English language to > write down what needs to be implemented to be compliant and > what is optional. We do this for protocols all the time. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 2 05:25: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 DDE943A6867; Wed, 2 Jul 2008 05:25: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 06AC03A6867 for ; Wed, 2 Jul 2008 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4OQBp+VGMyX for ; Wed, 2 Jul 2008 05:25:02 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 275113A6833 for ; Wed, 2 Jul 2008 05:25:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,737,1204520400"; d="scan'208";a="133852174" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 02 Jul 2008 08:25:11 -0400 X-IronPort-AV: E=Sophos;i="4.27,737,1204520400"; d="scan'208";a="227801264" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Jul 2008 08:25:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jul 2008 14:25:09 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] deprecated and conformance Thread-Index: AcjcMujevqROBLTOQqeK52C1+RCPRQACxs+wAAAmaKA= References: <20080702.091623.190514914.mbj@tail-f.com><20080702074204.GC850@elstar.local><20080702.123701.210154767.mbj@tail-f.com><20080702110046.GA1329@elstar.local> From: "Romascanu, Dan (Dan)" To: , "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] deprecated and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org s/missing/mixing/ > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Wednesday, July 02, 2008 3:24 PM > To: j.schoenwaelder@jacobs-university.de; Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] deprecated and conformance > > Yes, and also - aren't we missing module compliance with > agent capabilities. In SMI it is not the agent capabilities > macro that dictates compliance, and one cannot claim > compliance with a certain compliance profile without > implementing all objects described in the respective > compliance module. If we go on the agent-capabilities line, > this would rather refer to the sum of different modules that > the server complies to. > > Dan > (speaking as contributor) > > > -----Original Message----- > > From: netmod-bounces@ietf.org > > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Wednesday, July 02, 2008 2:01 PM > > To: Martin Bjorklund > > Cc: netmod@ietf.org > > Subject: Re: [netmod] deprecated and conformance > > > > On Wed, Jul 02, 2008 at 12:37:01PM +0200, Martin Bjorklund wrote: > > > > > But I also think there is a real problem with the current > > spec. W/o > > > any explicit conformance rules in the YANG spec, can a > server claim > > > conformance to a module if it implements one single > object from the > > > module? Do we really believe that we'll get interoperable > > > configuration management from this? How is a client > > supposed to adapt > > > to a server that - without any rules - implements some > subset of a > > > module? > > > > > > I think the best solution would be to have some kind of > > > agent-capabilities, which a conformant server that > > implements a subset > > > of a module would have to use. > > > > > > At a minimum, I think we need to write down in the spec what a > > > conformant server can and must do while still claiming > > conformance to > > > a module. > > > > I believe we should get YANG 1.0 out and worry about this > later. YANG > > module authors can still use English language to write down > what needs > > to be implemented to be compliant and what is optional. We > do this for > > protocols all the time. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 4 09:24: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 857853A6AB0; Fri, 4 Jul 2008 09:24: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 734883A68FA for ; Fri, 4 Jul 2008 09:24:50 -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 4lA2d8ES+vE5 for ; Fri, 4 Jul 2008 09:24:49 -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 BF4D53A6830 for ; Fri, 4 Jul 2008 09:24:49 -0700 (PDT) Received: (qmail 62359 invoked from network); 4 Jul 2008 16:24:57 -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; 4 Jul 2008 16:24:55 -0000 X-YMail-OSG: Ha3SqDoVM1nkDO2Tbd_S54Bsh11gHT.FLXAqhubrWjDjEKxcslg9azKKbgNkkZgdORUGCIE_94Odxr6H6uUYX_ZWZ4xFaFAfsmVxNWmP2Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <486E4ED6.90308@netconfcentral.com> Date: Fri, 04 Jul 2008 09:24:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] change control rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Where do change control rules and guidelines belong in YANG? I know this is a slippery slope into CLR quicksand, but IMO, most of the difficult unresolved issues involve the interaction between modules as they change over time. After ~15 years of reviewing MIBs for Cisco and the IETF, I am obviously biased towards paying attention to how SMIv2 handles this problem. The whole point of MIB Police or MIB Doctors is to maintain the robustness, stability, and coherence of the API embodied in the complete set of data model modules. (You think MIBs are bad? You should see some of the crap MIB writers want to publish!) I know many people would prefer to start over and pretend XML encoding and YANG complexity invalidates our SMI experience. Maybe that's true, but then all the more reason to pay careful attention to this problem, and not punt it into the future. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 5 09:26: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 7F5633A6B96; Sat, 5 Jul 2008 09:26: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 49F123A6B96 for ; Sat, 5 Jul 2008 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05+vqo5TFNQX for ; Sat, 5 Jul 2008 09:26:40 -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 8A2463A6B5A for ; Sat, 5 Jul 2008 09:26:37 -0700 (PDT) Received: (qmail 63942 invoked from network); 5 Jul 2008 16:26:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.212 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 5 Jul 2008 16:26:36 -0000 X-YMail-OSG: JQ3difkVM1nMi1b5n4KWxaTlx6mkNt31xW9MDtkFa3Z4vn_ZRBjJppMBT12Kwf5VUrQEqN2O.ucpx0O0pjlyfuslhJdJDYTYwXNqZoDZpQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <486FA0BA.9040601@netconfcentral.com> Date: Sat, 05 Jul 2008 09:26:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] range/length and pattern statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I noticed that the range statement in 8.1.3 clearly says how to deal with multiple ranges in the typedef chain. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. An example in the draft might be good: typedef my-base-str-type { type my-base-str-type { length "1..255"; } } typedef my-str-type { description "Valid range refinement"; type my-base-str-type { length "11 | 42"; } } typedef my-str-type { description "Invalid range refinement"; type my-base-str-type { length "1..999"; } } Another example in 8.2.3 showing the relative 'min' or 'max' would be good: type my-base-str-type { length "42 .. max"; // 42 .. 255 } The pattern statement in 8.3.4 does not mention typedef chain processing at all, which needs to be fixed. Unlike range/length, the pattern expressions are not validated against each other. Instead, ALL the patterns in the typedef chain are logically ANDed together, when validating a value against its data type. Disjoint expressions (e.g., "[1-9]" and "[a-z]") always produce a negative result during evaluation. This may be a data model bug, but is not a YANG error. An example like the one above would be good in 8.3.5. (TBD) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 5 10:04: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 960713A6B95; Sat, 5 Jul 2008 10:04: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 6785D3A6A52 for ; Sat, 5 Jul 2008 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.168 X-Spam-Level: X-Spam-Status: No, score=0.168 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jduf9YsjwSdh for ; Sat, 5 Jul 2008 10:04:11 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 98B1B3A6B95 for ; Sat, 5 Jul 2008 10:04:11 -0700 (PDT) Received: (qmail 14772 invoked from network); 5 Jul 2008 17:04:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.212 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 5 Jul 2008 17:04:10 -0000 X-YMail-OSG: VOF6_zcVM1nJlsRHdHwSM8j_jJQfexg0BjgVqoQdDMHw0s7AVUZ.qrQRnes1IIBm8szbcZPmbng7G1djGkCNH8ssR23HF37Z72Oxm5ddog-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <486FA988.2050300@netconfcentral.com> Date: Sat, 05 Jul 2008 10:04:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group References: <486FA0BA.9040601@netconfcentral.com> In-Reply-To: <486FA0BA.9040601@netconfcentral.com> Subject: Re: [netmod] range/length and pattern statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > I noticed that the range statement in 8.1.3 clearly says > how to deal with multiple ranges in the typedef chain. > > If a value restriction is applied to an already > restricted type, the new restriction MUST be equal or more limiting, > that is raising the lower bounds, reducing the upper bounds, removing > explicit values or ranges, or splitting ranges into multiple ranges > with intermediate gaps. > > An example in the draft might be good: > An example without cut-and-paste bugs would be better :-) > typedef my-base-str-type { > type my-base-str-type { ^^^^^^^^^^^^^^^^ string > length "1..255"; > } > } > > typedef my-str-type { > description "Valid range refinement"; > type my-base-str-type { > length "11 | 42"; > } > } > > typedef my-str-type { > description "Invalid range refinement"; > type my-base-str-type { > length "1..999"; > } > } > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Jul 6 07:50: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 D2FA43A6978; Sun, 6 Jul 2008 07:50: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 E021C3A6978 for ; Sun, 6 Jul 2008 07:50:18 -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 6q1sOxLkgkTe for ; Sun, 6 Jul 2008 07:50:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2D7FE3A67CF for ; Sun, 6 Jul 2008 07:50:18 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1ABEED803B1 for ; Sun, 6 Jul 2008 16:50:21 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Sun, 06 Jul 2008 16:50:21 +0200 Message-Id: <1215355821.27454.8.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [netmod] draft-lhotka-yang-dsdl-map-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, this is the draft describing YANG->DSDL mapping rules. It corresponds to the current implementation of the DSDL plugin for pyang - together with Martin, we will work towards making it available within the next few days. Lada A new version of I-D, draft-lhotka-yang-dsdl-map-00.txt has been successfuly submitted by Ladislav Lhotka and posted to the IETF repository. Filename: draft-lhotka-yang-dsdl-map Revision: 00 Title: Mapping of YANG to DSDL Creation_date: 2008-07-06 WG ID: Independent Submission Number_of_pages: 41 Abstract: This draft describes the algorithm and rules for mapping data models expressed in the YANG language to Document Schema Definition Languages (DSDL) with additional annotations. -- 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 Sun Jul 6 10:06: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 2A7B33A68BA; Sun, 6 Jul 2008 10:06: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 68DDF3A68BA for ; Sun, 6 Jul 2008 10:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=1.217, 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 UyuU6DDRgwTz for ; Sun, 6 Jul 2008 10:06:02 -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 B32703A689E for ; Sun, 6 Jul 2008 10:06:02 -0700 (PDT) Received: (qmail 91583 invoked from network); 6 Jul 2008 17:06:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.212 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 6 Jul 2008 17:06:04 -0000 X-YMail-OSG: SkXE_.cVM1lsK8cIP5Vh54frEWmYraNDh8fVBcRHeoWuIgpTE5lwtNyN7ZNFcTJRtVNwFtmOKVqNF.xDGBfB0sfm2Fjb5FMgbjckh5.sOw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4870FB7A.4090807@netconfcentral.com> Date: Sun, 06 Jul 2008 10:06:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] ABNF for YANG comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I don't see any ABNF describing YANG comments, e.g.: /* * this is a comment */ // so is this There is one sentence in Appendix D: This grammar assumes that the scanner replaces YANG comments with a single space character. Does the ABNF need a formal definition of all the comment variants? ============================= The 'smidump -f yang' output puts a comment before the 'module' keyword. Both pyang and yangdump accept comments anywhere in the file, but I don't think the ABNF reflects that: [yang-00, pg 128, para 4] OLD: module-stmt = module-keyword sep identifier-str optsep NEW: module-stmt = optsep module-keyword sep identifier-str optsep ^^^^^^ (The current ABNF properly accounts for any trailing whitespace.) Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Jul 6 13:27: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 3BD633A6903; Sun, 6 Jul 2008 13:27: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 0A9E13A6903 for ; Sun, 6 Jul 2008 13:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lROm6kJ6msX0 for ; Sun, 6 Jul 2008 13:27:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E81AD3A682E for ; Sun, 6 Jul 2008 13:27:43 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id C3CA976C224; Sun, 6 Jul 2008 22:27:50 +0200 (CEST) Date: Sun, 06 Jul 2008 22:27:45 +0200 (CEST) Message-Id: <20080706.222745.190320188.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <486FA0BA.9040601@netconfcentral.com> References: <486FA0BA.9040601@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] range/length and pattern statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 noticed that the range statement in 8.1.3 clearly says > how to deal with multiple ranges in the typedef chain. > > If a value restriction is applied to an already > restricted type, the new restriction MUST be equal or more limiting, > that is raising the lower bounds, reducing the upper bounds, removing > explicit values or ranges, or splitting ranges into multiple ranges > with intermediate gaps. > > An example in the draft might be good: > > typedef my-base-str-type { > type my-base-str-type { > length "1..255"; > } > } > > typedef my-str-type { > description "Valid range refinement"; > type my-base-str-type { > length "11 | 42"; > } > } > > typedef my-str-type { > description "Invalid range refinement"; > type my-base-str-type { > length "1..999"; > } > } I added this, to 8.3.3 since it shows length refinements, and I also added: typedef my-base-int32-type { type int32 { range "1..4 | 10..20"; } } type my-base-int32-type { // legal range restriction range "11..max"; // 11..20 } type int32 { // illegal range restriction range "11..100"; } to 8.1.4. > The pattern statement in 8.3.4 does not mention typedef chain > processing at all, which needs to be fixed. The text says in 8.3.4: It [pattern] is used to restrict the built-in type "string", or types derived from "string", to values that completely matches the pattern. Isn't it clear that the word "restrict" means that the value space is not extended? > Unlike range/length, > the pattern expressions are not validated against each other. > Instead, ALL the patterns in the typedef chain are logically ANDed > together, when validating a value against its data type. > Disjoint expressions (e.g., "[1-9]" and "[a-z]") always > produce a negative result during evaluation. > This may be a data model bug, but is not a YANG error. > > An example like the one above would be good in 8.3.5. (TBD) Whatabout this (useless) example: typedef my-str { type string { pattern "a|c|e"; } } typedef my-str2 { type my-str { pattern "a-d"; } } The value space of the type "my-str2" consists of the strings "a" and "c". A useful example could be: typedef loopback-ipv4-address { type inet:ipv4-address { pattern "127.*"; } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Jul 6 21:10: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 F275B3A685D; Sun, 6 Jul 2008 21:10: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 F1DEC3A6896 for ; Sun, 6 Jul 2008 21:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=0.811, 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 LvceYXVtf4zt for ; Sun, 6 Jul 2008 21:10:26 -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 4ED0A3A681B for ; Sun, 6 Jul 2008 21:10:26 -0700 (PDT) Received: (qmail 35728 invoked from network); 7 Jul 2008 04:10:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.212 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 7 Jul 2008 04:10:30 -0000 X-YMail-OSG: vZ3oJpcVM1leeCpY5K903nuziGs.liNZS9AgVWerznhsYbvSpPH0osRBgj693enVKdJtxiZKjZDNDD0s8D4INDFtbwpJdqkfrLP6RFNvFA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48719734.2070104@netconfcentral.com> Date: Sun, 06 Jul 2008 21:10:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <486FA0BA.9040601@netconfcentral.com> <20080706.222745.190320188.mbj@tail-f.com> In-Reply-To: <20080706.222745.190320188.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] range/length and pattern statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I noticed that the range statement in 8.1.3 clearly says >> how to deal with multiple ranges in the typedef chain. >> >> If a value restriction is applied to an already >> restricted type, the new restriction MUST be equal or more limiting, >> that is raising the lower bounds, reducing the upper bounds, removing >> explicit values or ranges, or splitting ranges into multiple ranges >> with intermediate gaps. >> >> An example in the draft might be good: >> >> typedef my-base-str-type { >> type my-base-str-type { >> length "1..255"; >> } >> } >> >> typedef my-str-type { >> description "Valid range refinement"; >> type my-base-str-type { >> length "11 | 42"; >> } >> } >> >> typedef my-str-type { >> description "Invalid range refinement"; >> type my-base-str-type { >> length "1..999"; >> } >> } > > I added this, to 8.3.3 since it shows length refinements, and I also > added: > > typedef my-base-int32-type { > type int32 { > range "1..4 | 10..20"; > } > } > > type my-base-int32-type { > // legal range restriction > range "11..max"; // 11..20 > } > > type int32 { > // illegal range restriction > range "11..100"; > } > > to 8.1.4. Note that without change control rules, and I were allowed to remove the range-stmt from 'my-base-int32-type', then the relative value of 'max' would change silently (and not be detected by 'diff'). (Couldn't help throwing that one in :-) > > >> The pattern statement in 8.3.4 does not mention typedef chain >> processing at all, which needs to be fixed. > > The text says in 8.3.4: > > It [pattern] is used to restrict the built-in type "string", or > types derived from "string", to values that completely matches the > pattern. > > Isn't it clear that the word "restrict" means that the value space is > not extended? It would be more clear if the text said that all patterns in the typedef chain must match in order for a string to be considered valid content for a data type. (Is the term 'typedef chain' defined?) Is is really important that DM writers know how YANG data types work, so some extra examples here is better than too few examples. > > >> Unlike range/length, >> the pattern expressions are not validated against each other. >> Instead, ALL the patterns in the typedef chain are logically ANDed >> together, when validating a value against its data type. >> Disjoint expressions (e.g., "[1-9]" and "[a-z]") always >> produce a negative result during evaluation. >> This may be a data model bug, but is not a YANG error. >> >> An example like the one above would be good in 8.3.5. (TBD) > > Whatabout this (useless) example: > > typedef my-str { > type string { > pattern "a|c|e"; > } > } > > typedef my-str2 { > type my-str { > pattern "a-d"; > } > } > > The value space of the type "my-str2" consists of the strings "a" > and "c". > > fine. > A useful example could be: > > typedef loopback-ipv4-address { > type inet:ipv4-address { > pattern "127.*"; > } > } > very fine. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 7 02:57:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B20428C12E; Mon, 7 Jul 2008 02:57:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D144728C12E for ; Mon, 7 Jul 2008 02:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YbUuaf+jAgF for ; Mon, 7 Jul 2008 02:57:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 187B928C12D for ; Mon, 7 Jul 2008 02:57:12 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7B9CFD803B8 for ; Mon, 7 Jul 2008 11:57:17 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20080706.222745.190320188.mbj@tail-f.com> References: <486FA0BA.9040601@netconfcentral.com> <20080706.222745.190320188.mbj@tail-f.com> Organization: CESNET Date: Mon, 07 Jul 2008 11:57:17 +0200 Message-Id: <1215424637.23783.31.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] range/length and pattern statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBOZSAwNi4gMDcuIDIwMDggdiAyMjoyNyArMDIwMDoK Cj4gPiBUaGUgcGF0dGVybiBzdGF0ZW1lbnQgaW4gOC4zLjQgZG9lcyBub3QgbWVudGlvbiB0eXBl ZGVmIGNoYWluCj4gPiBwcm9jZXNzaW5nIGF0IGFsbCwgd2hpY2ggbmVlZHMgdG8gYmUgZml4ZWQu Cj4gCj4gVGhlIHRleHQgc2F5cyBpbiA4LjMuNDoKPiAKPiAgICBJdCBbcGF0dGVybl0gaXMgdXNl ZCB0byByZXN0cmljdCB0aGUgYnVpbHQtaW4gdHlwZSAic3RyaW5nIiwgb3IKPiAgICB0eXBlcyBk ZXJpdmVkIGZyb20gInN0cmluZyIsIHRvIHZhbHVlcyB0aGF0IGNvbXBsZXRlbHkgbWF0Y2hlcyB0 aGUKPiAgICBwYXR0ZXJuLgo+IAo+IElzbid0IGl0IGNsZWFyIHRoYXQgdGhlIHdvcmQgInJlc3Ry aWN0IiBtZWFucyB0aGF0IHRoZSB2YWx1ZSBzcGFjZSBpcwo+IG5vdCBleHRlbmRlZD8KPiAKCkl0 IHNob3VsZCBzYXkgZXhwbGljaXRseSB0aGF0IHRoZSByZWdleHBzIGFyZSBBTkRlZC4gQWN0dWFs bHksIGlzIGl0CnBvc3NpYmxlIHRvIHNwZWNpZnkgbXVsdGlwbGUgcGF0dGVybiBzdGF0ZW1lbnRz IHdpdGhpbiB0aGUgc2FtZSB0eXBlZGVmPwpYU0QgZGF0YXR5cGUgbGlicmFyeSBzdXBwb3J0cyB0 aGlzIC0gdGhleSBhcmUgQU5EZWQsIHRvby4KCkxhZGEKCgotLSAKTGFkaXNsYXYgTGhvdGthLCBD RVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jul 7 03:22: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 6FE2D28C16D; Mon, 7 Jul 2008 03:22: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 376B428C170 for ; Mon, 7 Jul 2008 03:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=-0.557, 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 89tqNbXcFZu8 for ; Mon, 7 Jul 2008 03:22:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6A01928C16D for ; Mon, 7 Jul 2008 03:22:57 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1D0A4D801DF for ; Mon, 7 Jul 2008 12:23:03 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Mon, 07 Jul 2008 12:23:03 +0200 Message-Id: <1215426183.23783.39.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [netmod] order of subelements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, XML encoding rules for container (section 7.5.6) specify: "The container's child nodes are encoded as subelements to the container element, in the same order as they are defined within the container statement." The DHCP tutorial seems to violate this: The data model says container dhcp { description "configuration and operational parameters for a DHCP server."; leaf max-lease-time { type uint32; units seconds; default 7200; } leaf default-lease-time { type uint32; units seconds; must '$this <= ../max-lease-time' { error-message "The default-lease-time must be less than max-lease-time"; } default 600; } .... } but the XML snippet has 600 7200 Perhaps the restriction on order can be removed? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 7 03:32:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4870728C194; Mon, 7 Jul 2008 03:32:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE0B28C191 for ; Mon, 7 Jul 2008 03:32:19 -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 TXfueQPtf9HS for ; Mon, 7 Jul 2008 03:32: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 9EEF328C14B for ; Mon, 7 Jul 2008 03:32:00 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09B56C0051; Mon, 7 Jul 2008 12:32: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 gmx0w5IK2WcD; Mon, 7 Jul 2008 12:32:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FF52C0056; Mon, 7 Jul 2008 12:32:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B9975F0F1C; Mon, 7 Jul 2008 12:31:59 +0200 (CEST) Date: Mon, 7 Jul 2008 12:31:59 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080707103159.GA4710@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <486FA0BA.9040601@netconfcentral.com> <20080706.222745.190320188.mbj@tail-f.com> <1215424637.23783.31.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1215424637.23783.31.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] range/length and pattern statements 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, Jul 07, 2008 at 11:57:17AM +0200, Ladislav Lhotka wrote: > It should say explicitly that the regexps are ANDed. Actually, is it > possible to specify multiple pattern statements within the same typedef? > XSD datatype library supports this - they are ANDed, too. We discussed this but then I think we did not really see the need for this feature. The more complicated pattern we have so far are typically OR combinations rather than AND combinations. /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 Jul 7 05:10:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996093A6A6A; Mon, 7 Jul 2008 05:10:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D753A6918 for ; Mon, 7 Jul 2008 05:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=0.558, 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 DJigqb5Lujh5 for ; Mon, 7 Jul 2008 05:10:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 64AA23A6A7A for ; Mon, 7 Jul 2008 05:10:12 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5E1A5D80404; Mon, 7 Jul 2008 14:10:18 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080707103159.GA4710@elstar.local> References: <486FA0BA.9040601@netconfcentral.com> <20080706.222745.190320188.mbj@tail-f.com> <1215424637.23783.31.camel@missotis> <20080707103159.GA4710@elstar.local> Organization: CESNET Date: Mon, 07 Jul 2008 14:10:18 +0200 Message-Id: <1215432618.23783.59.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] range/length and pattern statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFBvIDA3LiAwNy4gMjAwOCB2IDEyOjMxICsw MjAwOgo+IE9uIE1vbiwgSnVsIDA3LCAyMDA4IGF0IDExOjU3OjE3QU0gKzAyMDAsIExhZGlzbGF2 IExob3RrYSB3cm90ZToKPiAgCj4gPiBJdCBzaG91bGQgc2F5IGV4cGxpY2l0bHkgdGhhdCB0aGUg cmVnZXhwcyBhcmUgQU5EZWQuIEFjdHVhbGx5LCBpcyBpdAo+ID4gcG9zc2libGUgdG8gc3BlY2lm eSBtdWx0aXBsZSBwYXR0ZXJuIHN0YXRlbWVudHMgd2l0aGluIHRoZSBzYW1lIHR5cGVkZWY/Cj4g PiBYU0QgZGF0YXR5cGUgbGlicmFyeSBzdXBwb3J0cyB0aGlzIC0gdGhleSBhcmUgQU5EZWQsIHRv by4KPiAKPiBXZSBkaXNjdXNzZWQgdGhpcyBidXQgdGhlbiBJIHRoaW5rIHdlIGRpZCBub3QgcmVh bGx5IHNlZSB0aGUgbmVlZCBmb3IKPiB0aGlzIGZlYXR1cmUuIFRoZSBtb3JlIGNvbXBsaWNhdGVk IHBhdHRlcm4gd2UgaGF2ZSBzbyBmYXIgYXJlCj4gdHlwaWNhbGx5IE9SIGNvbWJpbmF0aW9ucyBy YXRoZXIgdGhhbiBBTkQgY29tYmluYXRpb25zLgoKRm9yIGV4YW1wbGUsIHRoZSBwYXR0ZXJuIGZv ciBpcHY2LWFkZHJlc3MgaW4KZHJhZnQtc2Nob2Vudy1uZXRtb2QteWFuZy10eXBlcy0wMCBpcyBu b3QgY29ycmVjdC4gVGhlIGFsdGVybmF0aXZlIGZvcgpzaG9ydGVuZWQgYWRkcmVzcyBpcyAob21p dHRpbmcgdGhlIHNjb3BlIHBhcnQpCgogICAgJygoWzAtOWEtZkEtRl17MSw0fTopKihbMC05YS1m QS1GXXsxLDR9KSkqKDo6KScKKyAgICcoKFswLTlhLWZBLUZdezEsNH06KSooWzAtOWEtZkEtRl17 MSw0fSkpKicKCmJ1dCB0aGlzIGFsbG93cyBhbnkgbnVtYmVyIG9mIDE2LWJpdCBibG9ja3MgdG8g dGhlIGxlZnQgYW5kIHRvIHRoZSByaWdodApvZiB0aGUgZG91YmxlIGNvbG9uLCB3aGljaCBpcyB3 cm9uZy4KCkJvdGggdGhlIGZ1bGwgYW5kIHNob3J0ZW5lZCBmb3JtIG9mIGFuIElQdjYgYWRkcmVz cyBjYW4gYmUgcmVzdHJpY3RlZAp0b2dldGhlciBieQoKICAgICcoWzAtOWEtZkEtRl17MCw0fTop ezAsN31bMC05YS1mQS1GXXswLDR9JwoKICAgIEFORAoKICAgICcoKFswLTlhLWZBLUZdKzopezd9 WzAtOWEtZkEtRl0rKXwoKFswLTlhLWZBLUZdKzopKlswLTlhLWZBLUZdKyk/OjonCisgICAnKChb MC05YS1mQS1GXSs6KSpbMC05YS1mQS1GXSspPycKCkEgc2luZ2xlLWV4cHJlc3Npb24gYWx0ZXJu YXRpdmUgY2FuIGJlIGRlcml2ZWQgZnJvbSB0aGUgQUJORiBpbiBSRkMgMzk4NgooaXQncyB1c2Vk IGluIHB5YW5nKSwgYnV0IGl0IHdvdWxkIGJlIHByb2hpYml0aXZlbHkgbG9uZyBhbmQKY29tcGxp Y2F0ZWQuCgpMYWRhCgo+IAo+IC9qcwo+IAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQ IEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jul 7 06:12: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 5058D3A67EF; Mon, 7 Jul 2008 06:12: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 E5D243A6915 for ; Mon, 7 Jul 2008 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_20=-0.74, GB_I_LETTER=-2, 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 73ZkD7ocH3NE for ; Mon, 7 Jul 2008 06:12:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2D1A03A67EF for ; Mon, 7 Jul 2008 06:12: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 23577D802D2 for ; Mon, 7 Jul 2008 15:12:35 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Mon, 07 Jul 2008 15:12:35 +0200 Message-Id: <1215436355.23783.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [netmod] regexp for domain name X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, the regexp for domain-name in draft-schoenw-netmod-yang-types-00 is '([\p{L}\p{N}]+\.)*[\p{L}\p{N}]' The obvious problem is that it should allow hyphens. Also, the class \p{L} stands for Unicode letters whereas RFC 1034 only allows the 52 ASCII letters. Or has it been extended to Unicode letters? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 7 13:51: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 DCF0B3A6B78; Mon, 7 Jul 2008 13:51: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 E2DAA3A6B66 for ; Mon, 7 Jul 2008 13:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11+gWT67ojQy for ; Mon, 7 Jul 2008 13:51:15 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 687F23A6B79 for ; Mon, 7 Jul 2008 13:51:02 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 0DC1D76C4CA; Mon, 7 Jul 2008 22:51:01 +0200 (CEST) Date: Mon, 07 Jul 2008 22:50:39 +0200 (CEST) Message-Id: <20080707.225039.151034185.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4870FB7A.4090807@netconfcentral.com> References: <4870FB7A.4090807@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] ABNF for YANG comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org [2nd attempt] Andy Bierman wrote: > Hi, > > I don't see any ABNF describing YANG comments, e.g.: > > /* > * this is a comment > */ > > // so is this > > There is one sentence in Appendix D: > > This grammar assumes that the scanner replaces YANG comments with a > single space character. > > Does the ABNF need a formal definition of all the comment variants? I don't think it's possible to define this *within* the same grammar as we use to define the statements. For example, this is valid: module "f" + /* c1 */ 'o' + // c2 'o' { ... } > ============================= > > The 'smidump -f yang' output puts a comment before the 'module' keyword. > Both pyang and yangdump accept comments anywhere in the file, > but I don't think the ABNF reflects that: > > [yang-00, pg 128, para 4] > > OLD: > module-stmt = module-keyword sep identifier-str optsep > > NEW: > module-stmt = optsep module-keyword sep identifier-str optsep > ^^^^^^ Thanks; fixed. (same fix applied for submodule-stmt). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 8 08:58:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243BF28C0EC; Tue, 8 Jul 2008 08:58:09 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F0628C0EC for ; Tue, 8 Jul 2008 08:58:07 -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 v9xbIGSKH8li for ; Tue, 8 Jul 2008 08:58:06 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 161693A6810 for ; Tue, 8 Jul 2008 08:58:06 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA02.westchester.pa.mail.comcast.net with comcast id nQ3U1Z01Q1GhbT8520EG00; Tue, 08 Jul 2008 15:58:15 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id nTy61Z0064HwxpC3TTy6Cs; Tue, 08 Jul 2008 15:58:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=aq2Tg0OviCYA:10 a=_3KjqZ5oE-AA:10 a=48vgC7mUAAAA:8 a=10FJ3vgptZZeGpb_D1YA:9 a=5W_cFCXzbpl5AcbJ-5-BLZWKe8AA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Ladislav Lhotka'" , "'NETMOD Working Group'" References: <1215355821.27454.8.camel@missotis> Date: Tue, 8 Jul 2008 23:58:09 +0800 Message-ID: <04c001c8e113$6b7ad760$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1215355821.27454.8.camel@missotis> Thread-Index: Acjfd6FH8ztkkCxXS/KiUtZYGe8ozwBm2law Subject: Re: [netmod] draft-lhotka-yang-dsdl-map-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Are you proposing this as a draft to meet the WG deliverables for DSDL mapping? Do you want agenda time to discuss how this draft addresses the charter deliverables for DSDL? Or do you just want to publish this as an informational document of interest to the WG, with no intention of making this a candidate for the DSDL deliverable? If so, would you like agenda time to discuss this informational document? dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Sunday, July 06, 2008 10:50 PM > To: NETMOD Working Group > Subject: [netmod] draft-lhotka-yang-dsdl-map-00 > > Hi, > > this is the draft describing YANG->DSDL mapping rules. It > corresponds to > the current implementation of the DSDL plugin for pyang - > together with > Martin, we will work towards making it available within the next few > days. > > Lada > > A new version of I-D, draft-lhotka-yang-dsdl-map-00.txt has > been successfuly > submitted by Ladislav Lhotka and posted to the IETF repository. > > Filename: draft-lhotka-yang-dsdl-map > Revision: 00 > Title: Mapping of YANG to DSDL > Creation_date: 2008-07-06 > WG ID: Independent Submission > Number_of_pages: 41 > > Abstract: > This draft describes the algorithm and rules for mapping data models > expressed in the YANG language to Document Schema Definition > Languages (DSDL) with additional annotations. > > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 8 09:53:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F74F3A68D2; Tue, 8 Jul 2008 09:53: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 F1C3C3A68D2 for ; Tue, 8 Jul 2008 09:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdCO6th5tmwP for ; Tue, 8 Jul 2008 09:53:25 -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 170BB3A6810 for ; Tue, 8 Jul 2008 09:53:25 -0700 (PDT) Received: (qmail 78725 invoked from network); 8 Jul 2008 16:53:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.174.43 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 8 Jul 2008 16:53:32 -0000 X-YMail-OSG: ONEziE8VM1nPsO.v6XT8ln3bMisZvBR8UpSM5n_E6cEkX6CKYC3_rqTX_0bAPUKrxuRanSsqZdt53doQyYbszFa7AMWssonfpZaj5WYHvQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48739B88.1060205@netconfcentral.com> Date: Tue, 08 Jul 2008 09:53:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] keyref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I have some concerns about the keyref builtin data type. 8.8. The keyref Built-in Type ------------------------------ The keyref type is used to reference a particular list entry in the data tree. Its value is constrained to be the same as the key of an existing list entry. Randy already brought up the issue of hot-swap/provisioning configuration. It is insufficient to constrain the value of a keyref to the set of existing instances. This must be the set of all possible instances instead. It is also too restrictive to limit a keyref to a leaf used as a key. A new list can be created with key leafs which happen to already be defined as non-key leafs in other data structure (does not have to be in a list). Perhaps a separate 'leafref' would be better for this purpose. IMO, this is also needed to define notification content properly. If the leaf with the keyref type represents configuration, the list entry it refers to MUST also represent configuration. Such a leaf puts a constraint on a valid configuration. In a valid configuration, all keyref nodes MUST reference existing list entries. I do not agree with this paragraph. smidump is already violating this rule by using keyref within notifications to provide a pointer to the list entry associated with the notification. What is the purpose of this restriction? 8.8.2. The path Statement -------------------------- Why does keyref need to be made super-complicated by allowing predicates in the path-stmt? (The ABNF for this is not correct BTW). The example on pg 99 shows a path-stmt with a predicate: container default-address { leaf ifname { type keyref { path "../../interface/name"; } } leaf address { type keyref { path "../../interface[name = $this/../ifname]/address/ip"; } } } IMO, this is really esoteric and hard to read. How important is it to limit the keyref value range to a subset of all instances? Limiting instance values will break provisioning applications anyway, so this extra feature does not seem very important. The examples of keyref in use (ipfix-psamp, smidump 'borrowed key' and notification key) make sense to me, and do not need this instance subsetting feature. 8.10 The union Built-in Type ---------------------------- A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "keyref". What is the purpose of excluding keyref from the list of valid type-stmts within a union? I am not saying this is wrong, but some explanation would be helpful. Other Issues (not in draft) ------------------------------------ What happens if a keyref points to another keyref object, which happens to be a key defined as a keyref? Is this allowed? So compilers must check for 'loops' in the path-stmt to make sure the keyref chain eventually ends at a leaf with a real data type? What happens if node 'X' is deprecated or obsoleted in a new version of module foo? Does that automagically invalidate all the modules that reference foo:X in keyref path-stmts? What if the data type for leaf 'Y' changes over time? Which version of 'Y' is referenced in keyrefs in other modules? How are modules which use keyrefs that contain path-stmts which reference nodes in other modules kept in synch (or not) with each other? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 8 10:59: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 919643A6AB5; Tue, 8 Jul 2008 10:59: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 575443A6AB5 for ; Tue, 8 Jul 2008 10:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-QbQ7y7k+rJ for ; Tue, 8 Jul 2008 10:59:06 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 38A023A69B3 for ; Tue, 8 Jul 2008 10:59:06 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m68HxD400045 for ; Tue, 8 Jul 2008 17:59:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8E124.18EBC7DF" Date: Tue, 8 Jul 2008 13:57:31 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4155A3175@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-mahy-canmod-dsdl-02.txt Thread-Index: AcjhIoDB8cQXr2pvT0y/hR/1FoudVwAAJUQA From: "Sharon Chisholm" To: Subject: [netmod] FW: I-D Action:draft-mahy-canmod-dsdl-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E124.18EBC7DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Here is the update to the DSDL for NETCONF Definition, including the rough mapping to Yang. Lada has done some great work on mapping the concept of containers, which we will merge into the next version. Changes this version - some tweaks to make it easier to map to Yang (infoType, etc) - A section describing what gets mapped from Yang, including a few things we don't think get mapped. The document maintains its complete definition of DSDL for NETCONF that was in earlier versions, since it seems this is the only way to ensure interoperable implementations and high-quality mappings from Yang. During the analysis, we identified a number of areas where we think Yang should consider changes. These are captured in the document, but I will start individual email threads on the mailing list on each one to better enable discussion. Just a note that as yang is still a moving target, we don't go into excruciating detail on the mapping quite yet as the fear is that this will have to constantly be updated as yang evolves. Sharon=20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, July 08, 2008 1:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mahy-canmod-dsdl-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representing Netconf Data Models using Document Schema Definition Languages (DSDL) Author(s) : R. Mahy, et al. Filename : draft-mahy-canmod-dsdl-02.txt Pages : 72 Date : 2008-07-08 This document describes a concrete approach for representing Netconf and other IETF data models using the RelaxNG schema language and the Schematron validation language, which are both part of ISO's Document Schema Definition Languages (DSDL) standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-canmod-dsdl-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8E124.18EBC7DF Content-Type: application/octet-stream; name="draft-mahy-canmod-dsdl-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-mahy-canmod-dsdl-02.URL Content-Disposition: attachment; filename="draft-mahy-canmod-dsdl-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tYWh5LWNhbm1vZC1kc2RsLTAyLnR4dA0K ------_=_NextPart_001_01C8E124.18EBC7DF Content-Type: text/plain; name="ATT2829229.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2829229.txt Content-Disposition: attachment; filename="ATT2829229.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C8E124.18EBC7DF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------_=_NextPart_001_01C8E124.18EBC7DF-- From netmod-bounces@ietf.org Tue Jul 8 11:39:31 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1B53A6AB6; Tue, 8 Jul 2008 11:39: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 3CF2A3A6AB2 for ; Tue, 8 Jul 2008 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbhLQKohpkcz for ; Tue, 8 Jul 2008 11:39:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 01BC83A6A9F for ; Tue, 8 Jul 2008 11:39:28 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m68IdZg18661 for ; Tue, 8 Jul 2008 18:39:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 14:39:16 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4155EC81B@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dublin Core for Contact Information Thread-Index: AcjhKezoYgZh5GwmSLG9iduHzrQXDA== From: "Sharon Chisholm" To: Subject: [netmod] Dublin Core for Contact Information X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi The DSDL definition for NETCONF makes use of Dublin Core for contact information. I believe this should also be used in the yang language specification. http://dublincore.org/documents/dces/ Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 8 12:13: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 09FE428C265; Tue, 8 Jul 2008 12:13: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 E303F28C26F for ; Tue, 8 Jul 2008 12:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv4DL15xmPUp for ; Tue, 8 Jul 2008 12:13:02 -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 E0F1928C265 for ; Tue, 8 Jul 2008 12:13:01 -0700 (PDT) Received: (qmail 83244 invoked from network); 8 Jul 2008 19:13:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.174.43 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 8 Jul 2008 19:13:09 -0000 X-YMail-OSG: smJ.wHUVM1lEvrE9R.PrrwFiwrol9rD0ASie3z7zSMzAJppXlhrNaFGDCCNYmRPKq8_VQuDP_yH_u6wuEx1_42kRlDYyuYMpWat9FvhU.g._6mJGuL_bipZkGKd.xy0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4873BC42.5050708@netconfcentral.com> Date: Tue, 08 Jul 2008 12:13:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4155EC81B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4155EC81B@zcarhxm2.corp.nortel.com> Cc: netmod@ietf.org Subject: Re: [netmod] Dublin Core for Contact Information X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Sharon Chisholm wrote: > Hi > > The DSDL definition for NETCONF makes use of Dublin Core for contact > information. I believe this should also be used in the yang language > specification. > > http://dublincore.org/documents/dces/ > IMO, this is overkill. There are 15+ different fields. The YANG description, reference, organization, and contact fields borrowed from SMIv2 are sufficient. 15 flavors will lead to complex CLRs for each one. E.g.: Who is the creator of the module vs. just a contributor? YANG already supports extensions. A YANG module full of dublin-core extensions could be used in any module which wants to add this meta-data. > Sharon Chisholm Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 8 12:49: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 558C83A6904; Tue, 8 Jul 2008 12:49: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 2BA3D3A6904 for ; Tue, 8 Jul 2008 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVDJEfQ0iD5s for ; Tue, 8 Jul 2008 12:49:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F35803A67EC for ; Tue, 8 Jul 2008 12:49:03 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3F97C007F; Tue, 8 Jul 2008 21:49:12 +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 OmtRco7z8LbB; Tue, 8 Jul 2008 21:49:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB12FC006F; Tue, 8 Jul 2008 21:49:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B5C115FB7E7; Tue, 8 Jul 2008 21:49:05 +0200 (CEST) Date: Tue, 8 Jul 2008 21:49:05 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080708194905.GB24336@elstar.local> Mail-Followup-To: Sharon Chisholm , netmod@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4155EC81B@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4155EC81B@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Dublin Core for Contact Information X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Jul 08, 2008 at 02:39:16PM -0400, Sharon Chisholm wrote: > The DSDL definition for NETCONF makes use of Dublin Core for contact > information. I believe this should also be used in the yang language > specification. > > http://dublincore.org/documents/dces/ Is that any different from RFC 5013? Anyway, reading RFC 5013 tells me that quite a number of additional clarifications are needed to adopt RFC 5013. Who defines the vocabulary used for "subject" or "type"? Who defines the "formal identification system" used by the "relation" element? What is the usage / purpose of the "coverage" element? Perhaps someone interested in using Dublin Core can work out these details or identify the subset of RFC 5013 that makes sense in the YANG context and explain to us how that subset differs from what we have in place. I am open for alignment but I think someone has to come up with a more detailed proposal than "use Dublin Core" (and RFC 5013 is rather fuzzy as it only talks about vocabularies etc. that someone needs to establish for a given purpose). /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 Jul 8 14:30:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE32B28C2E2; Tue, 8 Jul 2008 14:30:10 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AF928C2A7 for ; Tue, 8 Jul 2008 14:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW9C90aeY0Tq for ; Tue, 8 Jul 2008 14:30:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7980E28C2E0 for ; Tue, 8 Jul 2008 14:30:08 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 19D6F76C4CC; Tue, 8 Jul 2008 23:30:28 +0200 (CEST) Date: Tue, 08 Jul 2008 23:30:16 +0200 (CEST) Message-Id: <20080708.233016.104600796.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48739B88.1060205@netconfcentral.com> References: <48739B88.1060205@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] keyref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 have some concerns about the keyref builtin data type. > > 8.8. The keyref Built-in Type > ------------------------------ > > The keyref type is used to reference a particular list entry in the > data tree. Its value is constrained to be the same as the key of an > existing list entry. > > > Randy already brought up the issue of hot-swap/provisioning > configuration. It is insufficient to constrain the value of > a keyref to the set of existing instances. This must be the set of > all possible instances instead. If this is what you want, just use the same type as the corresponding key. For example, instead of: leaf if-name { type keyref { path "/interfaces/interface/name"; } } do: leaf if-name { type string; } The whole point of using a keyref is to be able to have a reference to an existing instance of some sort. > It is also too restrictive to limit a keyref to a leaf used as a key. > A new list can be created with key leafs which happen to already be > defined as non-key leafs in other data structure (does not have to > be in a list). Perhaps a separate 'leafref' would be better for this > purpose. IMO, this is also needed to define notification content > properly. Please make a proposal for what you want to do. I don't understand which problem 'leafref' solves. > If the leaf with the keyref type represents configuration, the list > entry it refers to MUST also represent configuration. Such a leaf > puts a constraint on a valid configuration. In a valid > configuration, all keyref nodes MUST reference existing list entries. > > I do not agree with this paragraph. > smidump is already violating this rule by using keyref within > notifications to provide a pointer to the list entry associated > with the notification. What is the purpose of this restriction? Since a configuration is invalid if a keyref points to a non-existing instance, the keyref cannot point to something that may change dynamically. A configuration cannot be valid at one point in time, but invalid the next just b/c some operational state changed. > 8.8.2. The path Statement > -------------------------- > > Why does keyref need to be made super-complicated by allowing > predicates in the path-stmt? It allows just one form of a predicate; equality. The reason is that we need some way to refer to multiple keys. > (The ABNF for this is not correct BTW). Please let me know what the errors are. > The example on pg 99 shows a path-stmt with a predicate: > > container default-address { > leaf ifname { > type keyref { > path "../../interface/name"; > } > } > leaf address { > type keyref { > path "../../interface[name = $this/../ifname]/address/ip"; > } > } > } > > > IMO, this is really esoteric and hard to read. I agree with the hard to read part. See below. > How important is it to limit the keyref value range > to a subset of all instances? Limiting instance > values will break provisioning applications anyway, > so this extra feature does not seem very important. The example shows how I can refer to an instance which have keys on more than one level. So given this: list interface { key "name"; ... list address { key "ip"; ... } } the example shows how a specific ip address on a specific interface can be referenced. > The examples of keyref in use (ipfix-psamp, smidump 'borrowed key' > and notification key) make sense to me, and do not need this > instance subsetting feature. Right. In most cases, a simple keyref will do the job. But the current solution covers multiple hierarchies and multiple keys. > 8.10 The union Built-in Type > ---------------------------- > > A member type can be of any built-in or derived type, except it MUST > NOT be one of the built-in types "empty" or "keyref". > > What is the purpose of excluding keyref from the list of > valid type-stmts within a union? I am not saying this is wrong, > but some explanation would be helpful. The problem is the interpretation of the following: leaf foo { type union { type keyref "/interface/ifIndex"; type string; } } Suppose ifIndexes 1, 2, and 3 exists, and I set foo to 1. This is fine. Now suppse I remove ifIndex 1. This is still fine, but foo magically changed its underlying type from a uint32 into a string. > Other Issues (not in draft) > ------------------------------------ > > What happens if a keyref points to another keyref object, > which happens to be a key defined as a keyref? Is this > allowed? Sure. > So compilers must check for 'loops' in the > path-stmt to make sure the keyref chain eventually ends > at a leaf with a real data type? Yes, a loop would be an error. > What happens if node 'X' is deprecated or obsoleted in a new > version of module foo? Does that automagically invalidate > all the modules that reference foo:X in keyref path-stmts? No, the text says: If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module. (not specific to keyref) > What if the data type for leaf 'Y' changes over time? > Which version of 'Y' is referenced in keyrefs in other modules? With the current import scheme (i.e. no import by revision), you will not be allowed to change the data type unrestricted. > How are modules which use keyrefs that contain path-stmts > which reference nodes in other modules kept in synch (or not) > with each other? I don't understand the question. Just like augment paths maybe? This being said, I would very much like to see a better solution for the keyref problem. What we have now is the best we have found so far. The problem is that we want simple references to object instances. If we just need any reference, we could use an instance-identifier, but the syntax far from simple. Compare with how ifIndex is referenced in mibs; sometimes it's like atmSvcVpCrossConnectLowIfIndex from the ATM2-MIB, and sometimes it's references through an OBJECT IDENTIFIER. The keyref constructs formalizes the simple case of reference. Compare: leaf if-name { type keyref { path "/interfaces/interface/name"; } } to: leaf if-name-2 { type instance-identifier; } And the encodings: eth0 to: /if:interfaces/if:interface[if:name="eth0"] /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 8 22:59:35 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA3A3A67DB; Tue, 8 Jul 2008 22:59: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 B97153A67DB for ; Tue, 8 Jul 2008 22:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=0.321, 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 ElvSDxv5mt+y for ; Tue, 8 Jul 2008 22:59:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9D8983A684F for ; Tue, 8 Jul 2008 22:59:33 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E8D5FD80465 for ; Wed, 9 Jul 2008 07:59:40 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <04c001c8e113$6b7ad760$0600a8c0@china.huawei.com> References: <1215355821.27454.8.camel@missotis> <04c001c8e113$6b7ad760$0600a8c0@china.huawei.com> Organization: CESNET Date: Wed, 09 Jul 2008 07:59:40 +0200 Message-Id: <1215583180.6597.8.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] draft-lhotka-yang-dsdl-map-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SGkgRGF2ZSwKCm15IGludGVudGlvbiB3YXMgLSBhbmQgd2UgZGlzY3Vzc2VkIGl0IGluIHRoZSBs aXN0IG9uIDIzIE1heSAtIHRvCmNvbGxlY3QgbXkgZXhwZXJpZW5jZSBmcm9tIGltcGxlbWVudGlu ZyB0aGUgbWFwcGluZy4gUGFydHMgb2YgaXQgc2hvdWxkCklNTyBlbmQgdXAgaW4gdGhlIGNoYXJ0 ZXIgZGVsaXZlcmFibGUsIGNvbWJpbmVkIHdpdGggb3RoZXIgd29yayBhbmQKc2hhcGVkIGJ5IGZ1 cnRoZXIgZGlzY3Vzc2lvbi4KCkkgd291bGQgYXBwcmVjaWF0ZSB0byBnZXQgYSBzbG90IGluIHRo ZSBhZ2VuZGEgdG8gcHJlc2VudCB0aGlzIHdvcmssCmVzcGVjaWFsbHkgdGhlIG9wZW4gaXNzdWVz LgoKTGFkYQoKRGF2aWQgSGFycmluZ3RvbiBww63FoWUgdiDDmnQgMDguIDA3LiAyMDA4IHYgMjM6 NTggKzA4MDA6Cj4gSGksCj4gCj4gQXJlIHlvdSBwcm9wb3NpbmcgdGhpcyBhcyBhIGRyYWZ0IHRv IG1lZXQgdGhlIFdHIGRlbGl2ZXJhYmxlcyBmb3IgRFNETAo+IG1hcHBpbmc/Cj4gRG8geW91IHdh bnQgYWdlbmRhIHRpbWUgdG8gZGlzY3VzcyBob3cgdGhpcyBkcmFmdCBhZGRyZXNzZXMgdGhlCj4g Y2hhcnRlciBkZWxpdmVyYWJsZXMgZm9yIERTREw/IAo+IAo+IE9yIGRvIHlvdSBqdXN0IHdhbnQg dG8gcHVibGlzaCB0aGlzIGFzIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgb2YKPiBpbnRlcmVz dCB0byB0aGUgV0csIHdpdGggbm8gaW50ZW50aW9uIG9mIG1ha2luZyB0aGlzIGEgY2FuZGlkYXRl IGZvcgo+IHRoZSBEU0RMIGRlbGl2ZXJhYmxlPwo+IElmIHNvLCB3b3VsZCB5b3UgbGlrZSBhZ2Vu ZGEgdGltZSB0byBkaXNjdXNzIHRoaXMgaW5mb3JtYXRpb25hbAo+IGRvY3VtZW50Pwo+IAo+IGRi aAo+IAo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+IEZyb206IG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnIAo+ID4gW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIExhZGlzbGF2IExob3RrYQo+ID4gU2VudDogU3VuZGF5LCBKdWx5IDA2LCAyMDA4IDEw OjUwIFBNCj4gPiBUbzogTkVUTU9EIFdvcmtpbmcgR3JvdXAKPiA+IFN1YmplY3Q6IFtuZXRtb2Rd IGRyYWZ0LWxob3RrYS15YW5nLWRzZGwtbWFwLTAwCj4gPiAKPiA+IEhpLAo+ID4gCj4gPiB0aGlz IGlzIHRoZSBkcmFmdCBkZXNjcmliaW5nIFlBTkctPkRTREwgbWFwcGluZyBydWxlcy4gSXQgCj4g PiBjb3JyZXNwb25kcyB0bwo+ID4gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgdGhlIERT REwgcGx1Z2luIGZvciBweWFuZyAtIAo+ID4gdG9nZXRoZXIgd2l0aAo+ID4gTWFydGluLCB3ZSB3 aWxsIHdvcmsgdG93YXJkcyBtYWtpbmcgaXQgYXZhaWxhYmxlIHdpdGhpbiB0aGUgbmV4dCBmZXcK PiA+IGRheXMuCj4gPiAKPiA+IExhZGEKPiA+IAo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWxob3RrYS15YW5nLWRzZGwtbWFwLTAwLnR4dCBoYXMgCj4gPiBiZWVuIHN1Y2Nlc3NmdWx5 Cj4gPiBzdWJtaXR0ZWQgYnkgTGFkaXNsYXYgTGhvdGthIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4KPiA+IAo+ID4gRmlsZW5hbWU6CSBkcmFmdC1saG90a2EteWFuZy1kc2RsLW1h cAo+ID4gUmV2aXNpb246CSAwMAo+ID4gVGl0bGU6CQkgTWFwcGluZyBvZiBZQU5HIHRvIERTREwK PiA+IENyZWF0aW9uX2RhdGU6CSAyMDA4LTA3LTA2Cj4gPiBXRyBJRDoJCSBJbmRlcGVuZGVudCBT dWJtaXNzaW9uCj4gPiBOdW1iZXJfb2ZfcGFnZXM6IDQxCj4gPiAKPiA+IEFic3RyYWN0Ogo+ID4g VGhpcyBkcmFmdCBkZXNjcmliZXMgdGhlIGFsZ29yaXRobSBhbmQgcnVsZXMgZm9yIG1hcHBpbmcg ZGF0YSBtb2RlbHMKPiA+IGV4cHJlc3NlZCBpbiB0aGUgWUFORyBsYW5ndWFnZSB0byBEb2N1bWVu dCBTY2hlbWEgRGVmaW5pdGlvbgo+ID4gTGFuZ3VhZ2VzIChEU0RMKSB3aXRoIGFkZGl0aW9uYWwg YW5ub3RhdGlvbnMuCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAo+ID4gICAgICAgICAgICAgICAgICAgICAKPiA+IC0tIAo+ ID4gTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKPiA+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDCj4gPiAK PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBu ZXRtb2QgbWFpbGluZyBsaXN0Cj4gPiBuZXRtb2RAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCj4gPiAKPiAKLS0gCkxhZGlzbGF2IExob3Rr YSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Jul 9 05:23: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 4537C3A6950; Wed, 9 Jul 2008 05:23: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 A91903A67FB for ; Wed, 9 Jul 2008 05:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9Nv6yQG9lyx for ; Wed, 9 Jul 2008 05:23:03 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 833E03A6950 for ; Wed, 9 Jul 2008 05:23:03 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m69CNBB19893; Wed, 9 Jul 2008 12:23:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 08:21:52 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4155ECEB1@zcarhxm2.corp.nortel.com> In-Reply-To: <20080708194905.GB24336@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Dublin Core for Contact Information Thread-Index: AcjhM7asKzYwIMbmSZ2ChYhHV7ieYwAim7Mw References: <713043CE8B8E1348AF3C546DBE02C1B4155EC81B@zcarhxm2.corp.nortel.com> <20080708194905.GB24336@elstar.local> From: "Sharon Chisholm" To: Cc: netmod@ietf.org Subject: Re: [netmod] Dublin Core for Contact Information X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Note that there is already an XML mapping for Dublin Core http://dublincore.org/documents/dc-xml-guidelines/ I'll have a look through RFC 5013 because I'm having difficulty imagining what the ambiguities might be. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Tuesday, July 08, 2008 3:49 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netmod@ietf.org Subject: Re: [netmod] Dublin Core for Contact Information On Tue, Jul 08, 2008 at 02:39:16PM -0400, Sharon Chisholm wrote: > The DSDL definition for NETCONF makes use of Dublin Core for contact > information. I believe this should also be used in the yang language > specification. > > http://dublincore.org/documents/dces/ Is that any different from RFC 5013? Anyway, reading RFC 5013 tells me that quite a number of additional clarifications are needed to adopt RFC 5013. Who defines the vocabulary used for "subject" or "type"? Who defines the "formal identification system" used by the "relation" element? What is the usage / purpose of the "coverage" element? Perhaps someone interested in using Dublin Core can work out these details or identify the subset of RFC 5013 that makes sense in the YANG context and explain to us how that subset differs from what we have in place. I am open for alignment but I think someone has to come up with a more detailed proposal than "use Dublin Core" (and RFC 5013 is rather fuzzy as it only talks about vocabularies etc. that someone needs to establish for a given purpose). /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 Jul 9 06:17:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABEA3A6A9E; Wed, 9 Jul 2008 06:17:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345D428C0FC for ; Wed, 9 Jul 2008 06:17:56 -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 WcyoLoGsZTdd for ; Wed, 9 Jul 2008 06:17:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 302CF3A6A6A for ; Wed, 9 Jul 2008 06:17:55 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4675C008B; Wed, 9 Jul 2008 15:18:06 +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 FAHyjfpH-phl; Wed, 9 Jul 2008 15:17:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD4B0C0080; Wed, 9 Jul 2008 15:17:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CBC935FC6F5; Wed, 9 Jul 2008 15:17:58 +0200 (CEST) Date: Wed, 9 Jul 2008 15:17:58 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080709131758.GA25775@elstar.local> Mail-Followup-To: Sharon Chisholm , netmod@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4155EC81B@zcarhxm2.corp.nortel.com> <20080708194905.GB24336@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4155ECEB1@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4155ECEB1@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Dublin Core for Contact Information 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, Jul 09, 2008 at 08:21:52AM -0400, Sharon Chisholm wrote: > Hi > > Note that there is already an XML mapping for Dublin Core > http://dublincore.org/documents/dc-xml-guidelines/ > > I'll have a look through RFC 5013 because I'm having difficulty > imagining what the ambiguities might be. It always helps to read the specifications. ;-) /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 Jul 9 14:08: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 64B233A6B89; Wed, 9 Jul 2008 14:08: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 1B5223A6B6C for ; Wed, 9 Jul 2008 14:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMu84nIOWBpR for ; Wed, 9 Jul 2008 14:08:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 201263A6B89 for ; Wed, 9 Jul 2008 14:08:10 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 62EBF76C388; Wed, 9 Jul 2008 23:08:35 +0200 (CEST) Date: Wed, 09 Jul 2008 23:08:21 +0200 (CEST) Message-Id: <20080709.230821.135918476.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1215355821.27454.8.camel@missotis> References: <1215355821.27454.8.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] draft-lhotka-yang-dsdl-map-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Ladislav Lhotka wrote: > this is the draft describing YANG->DSDL mapping rules. It corresponds to > the current implementation of the DSDL plugin for pyang - together with > Martin, we will work towards making it available within the next few > days. There is a new release of the pyang tool available, which can be used to generate a DSDL schema from YANG/YIN modules. Available through http://www.yang-central.org (or directly from http://code.google.com/p/pyang). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 10 13:15:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EF93A6A27; Thu, 10 Jul 2008 13:15: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 21E2B3A6A27 for ; Thu, 10 Jul 2008 13:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuWbNA1pf-Oc for ; Thu, 10 Jul 2008 13:15:14 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id E58283A69EB for ; Thu, 10 Jul 2008 13:15:13 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6AKFQd06531 for ; Thu, 10 Jul 2008 20:15:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 16:15:17 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Units Thread-Index: AcjiyavBpl74zWrjTjOKSQH6NXgBgw== From: "Sharon Chisholm" To: Subject: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi I think we should standardize on a small set of units, while not precluding people from inventing their own (I've always been fond on nano-parsecs). This will avoid the sec, second, seconds, scnds, s problem. Here is the text from NETCONF DSDL " NOTE: It is recommended that the symbol be an identifier for a unit of measure as specified in the Unified Code of Units of Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM). This provides a set of symbols and a grammar for constructing identifiers for units of measure that are unique, and may be easily entered with a keyboard supporting the limited character set known as 7-bit ASCII. ISO 2955 formerly provided a specification with this scope, but was withdrawn in 2001. UCUM largely follows ISO 2955 with modifications to remove ambiguities and other problems. URL for GML specs is: http://www.opengeospatial.org/standards/gml" Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 10 15: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 C97943A6A12; Thu, 10 Jul 2008 15: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 E74DE3A6A12 for ; Thu, 10 Jul 2008 15:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=0.608, 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 h28wARoYDFfg for ; Thu, 10 Jul 2008 15:30:41 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 0E1443A69D5 for ; Thu, 10 Jul 2008 15:30:41 -0700 (PDT) Received: (qmail 59824 invoked from network); 10 Jul 2008 22:30:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.56 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 10 Jul 2008 22:30:55 -0000 X-YMail-OSG: Jergq6sVM1mb6LWPwCGZh1v1.YawU6pDfW641kjaIDCF28W45NfHFmVHAbCZFDeOJ.JYacq0.MQDaJGUAbvlYNPNM8T0YBCDo3Aseg5opmRAjA.LAIOIpJGLilcmGiU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48768D9C.5040404@netconfcentral.com> Date: Thu, 10 Jul 2008 15:30:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I think we should standardize on a small set of units, while not > precluding people from inventing their own (I've always been fond on > nano-parsecs). This will avoid the sec, second, seconds, scnds, s > problem. > > Here is the text from NETCONF DSDL > > " NOTE: It is recommended that the symbol be an identifier for a > unit of measure as specified in the Unified Code of Units of > Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM). This > provides a set of symbols and a grammar for constructing > identifiers for units of measure that are unique, and may be > easily entered with a keyboard supporting the limited character > set known as 7-bit ASCII. ISO 2955 formerly provided a > specification with this scope, but was withdrawn in 2001. UCUM > largely follows ISO 2955 with modifications to remove ambiguities > and other problems. > URL for GML specs is: http://www.opengeospatial.org/standards/gml" > I agree with you (!) My only concern is that a SMIv2 UNITS clause converted to a YANG units-stmt maintains the same semantics for the same string value. (I don't know if this UCUM spec accounts for SMIv2.) Since this is an XML-wide issue, not a NETCONF issue, the actual solution will probably require a separate RFC. > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 10 16:51: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 D1F4E3A6A22; Thu, 10 Jul 2008 16:51: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 6CB443A6A22 for ; Thu, 10 Jul 2008 16:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3NIh2KEK1b4 for ; Thu, 10 Jul 2008 16:51:13 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 20D2B3A69DD for ; Thu, 10 Jul 2008 16:51:13 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jul 2008 16:51:23 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, 10 Jul 2008 16:50:57 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 16:50:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 16:43:16 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6ANhGx30907; Thu, 10 Jul 2008 16:43:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6ANeSk8030068; Thu, 10 Jul 2008 23:40:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807102340.m6ANeSk8030068@idle.juniper.net> To: Andy Bierman In-reply-to: <48768D9C.5040404@netconfcentral.com> Date: Thu, 10 Jul 2008 19:40:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Jul 2008 23:43:16.0883 (UTC) FILETIME=[B9DF3E30:01C8E2E6] Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.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 >Sharon Chisholm wrote: >> " NOTE: It is recommended that the symbol be an identifier for a >> unit of measure as specified in the Unified Code of Units of >> Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM). This >> provides a set of symbols and a grammar for constructing >> identifiers for units of measure that are unique, and may be >> easily entered with a keyboard supporting the limited character >> set known as 7-bit ASCII. ISO 2955 formerly provided a >> specification with this scope, but was withdrawn in 2001. UCUM >> largely follows ISO 2955 with modifications to remove ambiguities >> and other problems. Just skimmed the spec (http://aurora.regenstrief.org/~ucum/ucum.html) and am not sure what to make of it. found none of this to be true. It's not 7-bit ascii (Angstrom). It allows for subscripts and other weirdnesses. The intro says: The Unified Code for Units of Measure is inspired by and heavily based on ISO 2955-1983, ANSI X3.50-1986, and HL7's extensions called ISO+. The respective ISO and ANSI standards are both entitled Representation of [...] units in systems with limited character sets where ISO 2955 refers to SI and other units provided by ISO 1000-1981, while ANSI X3.50 extends ISO 2955 to include U.S. customary units. Because these standards carry the restriction of limited character sets in their names they seem to be of less value today, when graphical user interfaces and laser printers are in wide-spread use. For this reason, the european standard ENV 12435 in its clause 7.3 declares ISO 2955 obsolete. So it's specifically _not_ restricting itself to text. It's also defining a grammar as well as a set of units, so it supports constructs like "mg/(8.h.kg)" (milligram per kilogram and 8-hour shift) and "m[iU]/mL" (milli-international unit per milliliter). It does handle the multiple definitions of units like "yard", with names like "yd_br", "yd_i", and "yd_us", but I don't know that "units d;" is gonna win the d. We'll have to sit for a few h with a Queen Anne's wine barrel of beer and put some cal_[15] into thinking about this. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 10 17:17: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 18E533A6AB7; Thu, 10 Jul 2008 17:17: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 706DE3A6AB7 for ; Thu, 10 Jul 2008 17:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.654, 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 bDVnpiMBeRmN for ; Thu, 10 Jul 2008 17:17:10 -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 42E083A6AB3 for ; Thu, 10 Jul 2008 17:17:10 -0700 (PDT) Received: (qmail 29247 invoked from network); 11 Jul 2008 00:17:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.56 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 11 Jul 2008 00:17:24 -0000 X-YMail-OSG: Y7qIC0IVM1m7cV.weWbQxStgmpWVW9xr8E1miETCh4Z8x4yTnD_D4wjTNd3_80VkbXFOkSzs16n8vMA2.hWCjOPVq5md9wiuF1akgs3Abd1O.647g6lJl7rvBEInT_k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4876A690.6060709@netconfcentral.com> Date: Thu, 10 Jul 2008 17:17:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807102340.m6ANeSk8030068@idle.juniper.net> In-Reply-To: <200807102340.m6ANeSk8030068@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org 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: >> Sharon Chisholm wrote: >>> " NOTE: It is recommended that the symbol be an identifier for a >>> unit of measure as specified in the Unified Code of Units of >>> Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM). This >>> provides a set of symbols and a grammar for constructing >>> identifiers for units of measure that are unique, and may be >>> easily entered with a keyboard supporting the limited character >>> set known as 7-bit ASCII. ISO 2955 formerly provided a >>> specification with this scope, but was withdrawn in 2001. UCUM >>> largely follows ISO 2955 with modifications to remove ambiguities >>> and other problems. > > Just skimmed the spec (http://aurora.regenstrief.org/~ucum/ucum.html) > and am not sure what to make of it. > found none of this to be true. > > It's not 7-bit ascii (Angstrom). It allows for subscripts and other > weirdnesses. The intro says: > > The Unified Code for Units of Measure is inspired by and heavily > based on ISO 2955-1983, ANSI X3.50-1986, and HL7's extensions > called ISO+. The respective ISO and ANSI standards are both > entitled Representation of [...] units in systems with limited > character sets where ISO 2955 refers to SI and other units > provided by ISO 1000-1981, while ANSI X3.50 extends ISO 2955 > to include U.S. customary units. Because these standards carry > the restriction of limited character sets in their names they > seem to be of less value today, when graphical user interfaces > and laser printers are in wide-spread use. For this reason, the > european standard ENV 12435 in its clause 7.3 declares ISO 2955 > obsolete. > > So it's specifically _not_ restricting itself to text. > > It's also defining a grammar as well as a set of units, so it > supports constructs like "mg/(8.h.kg)" (milligram per kilogram and > 8-hour shift) and "m[iU]/mL" (milli-international unit per milliliter). > > It does handle the multiple definitions of units like "yard", > with names like "yd_br", "yd_i", and "yd_us", but I don't > know that "units d;" is gonna win the d. We'll have to sit > for a few h with a Queen Anne's wine barrel of beer and put > some cal_[15] into thinking about this. > I should have said I agree with the goal of selecting some set of standard units, and use external definitions for the semantics of those units. The IPPM WG has already done work in the area of complex units. The more I search online, the more standards I find to choose from here. This is a huge can of worms. IMO, all the YANG spec should say is: * There SHOULD NOT be any leading or trailing whitespace in the units-stmt * Fully spelled out words SHOULD be used, and abbreviations SHOULD NOT be used * A single space character (0x20) SHOULD be used to separate multiple words in a units-stmt * Accepted standard units of measure names SHOULD be used whenever possible. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 10 18:50: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 F270C3A69F7; Thu, 10 Jul 2008 18:50: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 4542B3A69F7 for ; Thu, 10 Jul 2008 18:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLtPw254PrUR for ; Thu, 10 Jul 2008 18:50:51 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 549CB3A69BF for ; Thu, 10 Jul 2008 18:50:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jul 2008 18:50:55 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 18:50:58 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 18:50:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 18:48:37 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6B1max60364; Thu, 10 Jul 2008 18:48:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6B1jmTI031030; Fri, 11 Jul 2008 01:45:49 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807110145.m6B1jmTI031030@idle.juniper.net> To: Andy Bierman In-reply-to: <4876A690.6060709@netconfcentral.com> Date: Thu, 10 Jul 2008 21:45:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Jul 2008 01:48:37.0128 (UTC) FILETIME=[3C499080:01C8E2F8] Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >IMO, all the YANG spec should say is: > * There SHOULD NOT be any leading or trailing whitespace > in the units-stmt > * Fully spelled out words SHOULD be used, and abbreviations > SHOULD NOT be used > * A single space character (0x20) SHOULD be used to separate > multiple words in a units-stmt > * Accepted standard units of measure names SHOULD be used whenever > possible. I'm not sure that single space isn't a CLR, but otherwise this is a good list. I'd add: * Units should be in plural form, where appropriate This gets us feet, seconds, meters, meters per second, parsecs per gallon, angels per square nanometer, and chicken per pot. I see this as documentation, not a basis for automatic conversion. Using standard words in standard formats is more about consistency and readability. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 00: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 812433A69D8; Fri, 11 Jul 2008 00: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 988773A69D8 for ; Fri, 11 Jul 2008 00:20:28 -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 GI2iU7F9ytXD for ; Fri, 11 Jul 2008 00:20: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 C684F3A6992 for ; Fri, 11 Jul 2008 00:20:27 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49BFEC001B; Fri, 11 Jul 2008 09:20:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q64HeSX9olmQ; Fri, 11 Jul 2008 09:20: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 13BAEC000A; Fri, 11 Jul 2008 09:20:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E83F60051C; Fri, 11 Jul 2008 09:20:38 +0200 (CEST) Date: Fri, 11 Jul 2008 09:20:38 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080711072038.GA29275@elstar.local> Mail-Followup-To: Andy Bierman , Sharon Chisholm , netmod@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> <48768D9C.5040404@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48768D9C.5040404@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Units 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, Jul 10, 2008 at 03:30:52PM -0700, Andy Bierman wrote: >> I think we should standardize on a small set of units, while not >> precluding people from inventing their own (I've always been fond on >> nano-parsecs). This will avoid the sec, second, seconds, scnds, s >> problem. I just did run a simple awk script to extract the UNITS clauses from ALL IETF MIB modules and what I found looked pretty consistent. So obviously MIB reviews have so far dealt with the problem. For me, such rules make sense if there is a way to automatically check them. Otherwise, you end up relying on human MIB reviews anyway. Anyway, I would support clearly anybody who wants to go ahead a write a decent RFCs about units that defines the general rules for representing units and establishes an IANA registry (ideally in a machine readable format) where units can be registered. Once this is in place, we can rely on it and use it in other standards. /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 Jul 11 01:31: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 789613A69DE; Fri, 11 Jul 2008 01:31: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 14E023A684A for ; Fri, 11 Jul 2008 01:31:28 -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 l2GbZ6gEoFbr for ; Fri, 11 Jul 2008 01:31:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E0EBC3A6852 for ; Fri, 11 Jul 2008 01:30:42 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0C5EA2147F; Fri, 11 Jul 2008 10:30:59 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-66-48771a420173 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E8A5F21440; Fri, 11 Jul 2008 10:30:58 +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, 11 Jul 2008 10:30:58 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 10:30:58 +0200 Message-ID: <48771A41.6090004@ericsson.com> Date: Fri, 11 Jul 2008 10:30:57 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 11 Jul 2008 08:30:58.0371 (UTC) FILETIME=[7196E930:01C8E330] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I would be very reluctant to include by reference 100 pages of an external standard (any standards) unless it is absolutely needed. One strong point of YANG is it's concise nature. If you have to read extra 100 pages for units, brrr ... Balazs Sharon Chisholm wrote: > Hi > > I think we should standardize on a small set of units, while not > precluding people from inventing their own (I've always been fond on > nano-parsecs). This will avoid the sec, second, seconds, scnds, s > problem. > > Here is the text from NETCONF DSDL > > " NOTE: It is recommended that the symbol be an identifier for a > unit of measure as specified in the Unified Code of Units of > Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM). This > provides a set of symbols and a grammar for constructing > identifiers for units of measure that are unique, and may be > easily entered with a keyboard supporting the limited character > set known as 7-bit ASCII. ISO 2955 formerly provided a > specification with this scope, but was withdrawn in 2001. UCUM > largely follows ISO 2955 with modifications to remove ambiguities > and other problems. > URL for GML specs is: http://www.opengeospatial.org/standards/gml" > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 07:13: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 EF8303A6B3B; Fri, 11 Jul 2008 07:13: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 B018F3A6B35 for ; Fri, 11 Jul 2008 07:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeLFacy2pZmF for ; Fri, 11 Jul 2008 07:13:40 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 691F13A6B3B for ; Fri, 11 Jul 2008 07:13:40 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6BEDqh11997; Fri, 11 Jul 2008 14:13:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 10:13:32 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4156983B9@zcarhxm2.corp.nortel.com> In-Reply-To: <48771A41.6090004@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Units Thread-Index: AcjjMHajoct6W5OMT+CmjizizTdaUAALwKCA References: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> <48771A41.6090004@ericsson.com> From: "Sharon Chisholm" To: "Balazs Lengyel" Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi That argument doesn't really make any sense to me. But let me first say that my point is we need to standardize on units. How we do it once we agree this is a good goal is the continuation of the discussion. I personally have not made any decisions on whether I like or dislike the approach on units that I quoted, but it does seem like a nice review of some very relevant existing work. The idea that we reinvent things so that we can get it all defined in a single 800 page specification is just nuts to me. There are good reasons to reinvent, but this just isn't one from my perspective. Sharon -----Original Message----- From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] Sent: Friday, July 11, 2008 4:31 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: netmod@ietf.org Subject: Re: [netmod] Units Hello, I would be very reluctant to include by reference 100 pages of an external standard (any standards) unless it is absolutely needed. One strong point of YANG is it's concise nature. If you have to read extra 100 pages for units, brrr ... Balazs Sharon Chisholm wrote: > Hi > > I think we should standardize on a small set of units, while not > precluding people from inventing their own (I've always been fond on > nano-parsecs). This will avoid the sec, second, seconds, scnds, s > problem. > > Here is the text from NETCONF DSDL > > " NOTE: It is recommended that the symbol be an identifier for a > unit of measure as specified in the Unified Code of Units of > Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM). This > provides a set of symbols and a grammar for constructing > identifiers for units of measure that are unique, and may be > easily entered with a keyboard supporting the limited character > set known as 7-bit ASCII. ISO 2955 formerly provided a > specification with this scope, but was withdrawn in 2001. UCUM > largely follows ISO 2955 with modifications to remove ambiguities > and other problems. > URL for GML specs is: http://www.opengeospatial.org/standards/gml" > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 07:22: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 4E3423A6AD6; Fri, 11 Jul 2008 07:22: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 B21C03A6AD6 for ; Fri, 11 Jul 2008 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feoTjp+6njkZ for ; Fri, 11 Jul 2008 07:22:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 73CA33A68C8 for ; Fri, 11 Jul 2008 07:22:56 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8EF7C20959; Fri, 11 Jul 2008 16:23:12 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-d2-48776cd07a5e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6936F2005D; Fri, 11 Jul 2008 16:23:12 +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, 11 Jul 2008 16:23:07 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 16:23:07 +0200 Message-ID: <48776CCA.4010105@ericsson.com> Date: Fri, 11 Jul 2008 16:23:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B415697CFC@zcarhxm2.corp.nortel.com> <48771A41.6090004@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B4156983B9@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4156983B9@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 11 Jul 2008 14:23:07.0294 (UTC) FILETIME=[A368B3E0:01C8E361] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I don't want to reinvent the wheel, but I would also like to avoid being forced to read hundreds of extra pages, so something like UCUM should be a SHOULD or a MIGHT in the RFC but hopefully not a MUST. Reinventing the wheel is nuts, but if we end up with an 800 page specification (or more) YANG is doomed. How long is SMI? Balazs Sharon Chisholm wrote: > Hi > > That argument doesn't really make any sense to me. But let me first say > that my point is we need to standardize on units. How we do it once we > agree this is a good goal is the continuation of the discussion. I > personally have not made any decisions on whether I like or dislike the > approach on units that I quoted, but it does seem like a nice review of > some very relevant existing work. > > The idea that we reinvent things so that we can get it all defined in a > single 800 page specification is just nuts to me. There are good reasons > to reinvent, but this just isn't one from my perspective. > > Sharon > > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Friday, July 11, 2008 4:31 AM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netmod@ietf.org > Subject: Re: [netmod] Units > > Hello, > I would be very reluctant to include by reference 100 pages of an > external standard (any > standards) unless it is absolutely needed. One strong point of YANG is > it's concise nature. If you have to read extra 100 pages for units, brrr > ... > Balazs > > Sharon Chisholm wrote: >> Hi >> >> I think we should standardize on a small set of units, while not >> precluding people from inventing their own (I've always been fond on >> nano-parsecs). This will avoid the sec, second, seconds, scnds, s >> problem. >> >> Here is the text from NETCONF DSDL >> >> " NOTE: It is recommended that the symbol be an identifier for a >> unit of measure as specified in the Unified Code of Units of >> Measure (UCUM) [13] (http://aurora.regenstrief.org/UCUM). This >> provides a set of symbols and a grammar for constructing >> identifiers for units of measure that are unique, and may be >> easily entered with a keyboard supporting the limited character >> set known as 7-bit ASCII. ISO 2955 formerly provided a >> specification with this scope, but was withdrawn in 2001. UCUM >> largely follows ISO 2955 with modifications to remove > ambiguities >> and other problems. >> URL for GML specs is: > http://www.opengeospatial.org/standards/gml" >> Sharon Chisholm >> Nortel >> Ottawa, Ontario >> Canada >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 07:56: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 DE0093A6A37; Fri, 11 Jul 2008 07:56: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 809B528C18D for ; Fri, 11 Jul 2008 07:56:09 -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 t8salZYFsH8Z for ; Fri, 11 Jul 2008 07:56:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6AF463A6A37 for ; Fri, 11 Jul 2008 07:56:08 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E9CD5200B0; Fri, 11 Jul 2008 16:56:24 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-12-487774983faa Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D0122210A5; Fri, 11 Jul 2008 16:56:24 +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, 11 Jul 2008 16:56:24 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 16:56:24 +0200 Message-ID: <48777497.6060807@ericsson.com> Date: Fri, 11 Jul 2008 16:56:23 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48739B88.1060205@netconfcentral.com> <20080708.233016.104600796.mbj@tail-f.com> In-Reply-To: <20080708.233016.104600796.mbj@tail-f.com> X-OriginalArrivalTime: 11 Jul 2008 14:56:24.0495 (UTC) FILETIME=[49D563F0:01C8E366] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] keyref X-BeenThere: netmod@ietf.org 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, Please see below! Martin Bjorklund wrote: > Since a configuration is invalid if a keyref points to a non-existing > instance, the keyref cannot point to something that may change > dynamically. A configuration cannot be valid at one point in time, > but invalid the next just b/c some operational state changed. [BALAZS]: What if someone pulls out an interface card? Can that make a configuration invalid? A must statement can also reference a state variable, so a state change CAN invalidate a configuration. > > This being said, I would very much like to see a better solution for > the keyref problem. What we have now is the best we have found so > far. The problem is that we want simple references to object > instances. If we just need any reference, we could use an > instance-identifier, but the syntax far from simple. Compare with how > ifIndex is referenced in mibs; sometimes it's like > atmSvcVpCrossConnectLowIfIndex from the ATM2-MIB, and sometimes it's > references through an OBJECT IDENTIFIER. The keyref constructs > formalizes the simple case of reference. > > Compare: > > leaf if-name { > type keyref { > path "/interfaces/interface/name"; > } > } > > to: > > leaf if-name-2 { > type instance-identifier; > } > > And the encodings: > > eth0 > > to: > > > /if:interfaces/if:interface[if:name="eth0"] > > [BALAZS]: I think we need both the simple form and the free form (Instance Identifier). Instance identifiers can also point to leafs, to non-existing stuff, to different data-types ... Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 09:01:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C5328C21A; Fri, 11 Jul 2008 09:01: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 280A128C216 for ; Fri, 11 Jul 2008 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.378, 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 1z1Ee6r9+6gO for ; Fri, 11 Jul 2008 09:01:01 -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 A9FB628C23A for ; Fri, 11 Jul 2008 09:00:54 -0700 (PDT) Received: (qmail 29422 invoked from network); 11 Jul 2008 16:01:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.56 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 11 Jul 2008 16:01:11 -0000 X-YMail-OSG: YSewMxgVM1k2BRk429cc4BQd0w50FU.kSoH6Ihlqg8sBj_ihfII.8CVXnRzEn.jyy8R6i6sK0QfRUz944vX.fXAxtuSPYfZeLcuuBPkX9g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <487783C5.90304@netconfcentral.com> Date: Fri, 11 Jul 2008 09:01:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <48739B88.1060205@netconfcentral.com> <20080708.233016.104600796.mbj@tail-f.com> <48777497.6060807@ericsson.com> In-Reply-To: <48777497.6060807@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] keyref X-BeenThere: netmod@ietf.org 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, > Please see below! > > Martin Bjorklund wrote: >> Since a configuration is invalid if a keyref points to a non-existing >> instance, the keyref cannot point to something that may change >> dynamically. A configuration cannot be valid at one point in time, >> but invalid the next just b/c some operational state changed. > [BALAZS]: What if someone pulls out an interface card? Can that make a > configuration invalid? > A must statement can also reference a state variable, so a state change > CAN invalidate a configuration. > I agree. NE configuration must deal with hot-plug/hot-swap. NETCONF has 'continue-on-error' to deal will loading partially valid configurations. However, I would not want the agent generating errors because some config exists for an empty slot. >> >> This being said, I would very much like to see a better solution for >> the keyref problem. What we have now is the best we have found so >> far. The problem is that we want simple references to object >> instances. If we just need any reference, we could use an >> instance-identifier, but the syntax far from simple. Compare with how >> ifIndex is referenced in mibs; sometimes it's like >> atmSvcVpCrossConnectLowIfIndex from the ATM2-MIB, and sometimes it's >> references through an OBJECT IDENTIFIER. The keyref constructs >> formalizes the simple case of reference. >> >> Compare: >> >> leaf if-name { >> type keyref { >> path "/interfaces/interface/name"; >> } >> } >> >> to: >> >> leaf if-name-2 { >> type instance-identifier; >> } >> >> And the encodings: >> >> eth0 >> >> to: >> >> >> /if:interfaces/if:interface[if:name="eth0"] >> >> > [BALAZS]: I think we need both the simple form and the free form > (Instance Identifier). Instance identifiers can also point to leafs, to > non-existing stuff, to different data-types ... > The main use case for leafref is the use of secondary 'index-by-handle' like RMON2 does with the protocolDirLocalIndex. This is a plain leaf in the config table where it is defined. For performance and simplicity, this uint32 is used in many other tables for indexing, instead of the corresponding encoded OCTET STRING identifier for a given protocol encapsulation. This is not currently supported in YANG. The real topic of this thread should be 'Inter-Table Relationships'. IMO, embedding table relationships into the built-in data types is not well defined in YANG, and as a result, the 'keyref' and 'instance-identifier' types are over-loaded and confusing. > Balazs > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 10:22:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AB03A69E4; Fri, 11 Jul 2008 10:22:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFDF3A69E4 for ; Fri, 11 Jul 2008 10:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HOs56Dj1AXh for ; Fri, 11 Jul 2008 10:22:46 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id B51773A68FA for ; Fri, 11 Jul 2008 10:22:45 -0700 (PDT) X-Trace: 56552488/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.49 X-SBRS: None X-RemoteIP: 213.116.52.49 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAF0zd0jVdDQx/2dsb2JhbACDXjKHQKN8Aw X-IronPort-AV: E=Sophos;i="4.30,346,1212361200"; d="scan'208";a="56552488" X-IP-Direction: IN Received: from 1cust49.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.49]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Jul 2008 18:22:55 +0100 Message-ID: <001501c8e371$96aba4e0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Phil Shafer" References: <200807110145.m6B1jmTI031030@idle.juniper.net> Date: Fri, 11 Jul 2008 15:10:35 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Phil Shafer" To: "Andy Bierman" Cc: Sent: Friday, July 11, 2008 3:45 AM Subject: Re: [netmod] Units > Andy Bierman writes: > >IMO, all the YANG spec should say is: > > * There SHOULD NOT be any leading or trailing whitespace > > in the units-stmt > > * Fully spelled out words SHOULD be used, and abbreviations > > SHOULD NOT be used > > * A single space character (0x20) SHOULD be used to separate > > multiple words in a units-stmt > > * Accepted standard units of measure names SHOULD be used whenever > > possible. > > I'm not sure that single space isn't a CLR, but otherwise this > is a good list. I'd add: > > * Units should be in plural form, where appropriate > I would do the exact opposite, namely all units should be in single form, always. I believe it improves recognition, ease of searching for in documents, and, once upon a time, I was taught that it was the recognised correct form (probably an undergraduate engineering course). I am with Andy that, in principle, this is a good idea, and I do like the single space (thinking of the mess that other I-Ds have got into with what is white space). Tom Petch > This gets us feet, seconds, meters, meters per second, parsecs per > gallon, angels per square nanometer, and chicken per pot. > > I see this as documentation, not a basis for automatic conversion. > Using standard words in standard formats is more about consistency > and readability. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 10:29: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 155473A6B80; Fri, 11 Jul 2008 10:29: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 28C5B28C1B5 for ; Fri, 11 Jul 2008 10:29: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_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 GSikhhOem7eA for ; Fri, 11 Jul 2008 10:29: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 058993A6B7E for ; Fri, 11 Jul 2008 10:29:25 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 855D8C0025; Fri, 11 Jul 2008 19:29:42 +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 YkHG9Id4gda0; Fri, 11 Jul 2008 19:29:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2B1EC0006; Fri, 11 Jul 2008 19:29:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C2B2601335; Fri, 11 Jul 2008 19:29:34 +0200 (CEST) Date: Fri, 11 Jul 2008 19:29:33 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20080711172933.GA1061@elstar.local> Mail-Followup-To: "tom.petch" , Andy Bierman , Phil Shafer , netmod@ietf.org References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <001501c8e371$96aba4e0$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Units 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, Jul 11, 2008 at 03:10:35PM +0200, tom.petch wrote: > I am with Andy that, in principle, this is a good idea, and I do > like the single space (thinking of the mess that other I-Ds have got > into with what is white space). I once again like to encourage everybody to extract all the SMIv2 UNITS clauses from all IETF MIB modules and after taking a look at the result I like to see a clear problem statement what is broken and how it is going to be fixed (and include in that how you plan to enforce any new rules). Given all the important open issues I see, I am wondering why we should spend time improving the UNITS clauses. I am not saying there is no value - I am just at odds with the priorities. /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 Jul 11 11:10: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 2DEE128C27A; Fri, 11 Jul 2008 11:10: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 63A6628C27E for ; Fri, 11 Jul 2008 11:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=1.191, BAYES_00=-2.599, GB_I_LETTER=-2, 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 piMpBiPEPpXG for ; Fri, 11 Jul 2008 11:10:09 -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 6C0C628C279 for ; Fri, 11 Jul 2008 11:10:08 -0700 (PDT) Received: (qmail 71331 invoked from network); 11 Jul 2008 18:10:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.56 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 11 Jul 2008 18:10:22 -0000 X-YMail-OSG: OAXo2fwVM1lvU4fXIiED7t_Uf2KRLN2gBop2F9zZNbkArNwS4khrZdAHDG7ObQFTW97ApS0Cor5eAEOpquGO7NWVtdHo6ChYSgF989Kb0uvAvG.OgyXw7xDXmpxf1Qw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4877A20C.7010607@netconfcentral.com> Date: Fri, 11 Jul 2008 11:10:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "tom.petch" , Andy Bierman , Phil Shafer , netmod@ietf.org References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> <20080711172933.GA1061@elstar.local> In-Reply-To: <20080711172933.GA1061@elstar.local> Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org 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 Fri, Jul 11, 2008 at 03:10:35PM +0200, tom.petch wrote: > >> I am with Andy that, in principle, this is a good idea, and I do >> like the single space (thinking of the mess that other I-Ds have got >> into with what is white space). > > I once again like to encourage everybody to extract all the SMIv2 > UNITS clauses from all IETF MIB modules and after taking a look at the > result I like to see a clear problem statement what is broken and how > it is going to be fixed (and include in that how you plan to enforce > any new rules). > I just did a grep on a subset (~40 MIBs) and noticed a few things: - capitalization is not consistent with YANG, which aggressively utilizes lower-case letters - there were multiple variants, even in this small subset, most notably Milliseconds, milliseconds, and milli-seconds. - there were no complex units of measure, not even 'packets per second'. Maybe SMIv2 UNITS is too restrictive, and YANG should support these complex units? It should not forbid them, at least. - vendor MIBs are not reviewed by MIB Doctors, and many more inconsistencies exist in vendor MIBs. YANG needs to support standard and vendor data models. > Given all the important open issues I see, I am wondering why we > should spend time improving the UNITS clauses. I am not saying there > is no value - I am just at odds with the priorities. NASA thinks they found the wreckage of the Mars Polar Lander: http://www.skyandtelescope.com/news/3310281.html I am not proposing that YANG attempt to have some official list of units. I think a list of CLRs could help tools and humans maintain a less ambiguous set of units than no rules at all. Clearly, comparing the strings "meters" to "feet" would have helped in this example. BTW, I prefer the plural form, as Phil suggests, and even lower-case letters and numbers only. This is more recognizable, e.g. 'foot per second'. > > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 12:09:36 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF0F3A6A02; Fri, 11 Jul 2008 12:09:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37A528C1D3 for ; Fri, 11 Jul 2008 12:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, GB_I_LETTER=-2, 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 V69VaQ+EG2QB for ; Fri, 11 Jul 2008 12:09:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E74E63A69E2 for ; Fri, 11 Jul 2008 12:09:33 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01D18C0020; Fri, 11 Jul 2008 21:09:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wPc7RuzYOa2p; Fri, 11 Jul 2008 21:09: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 AC185C0006; Fri, 11 Jul 2008 21:09:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E2E6F601493; Fri, 11 Jul 2008 21:09:40 +0200 (CEST) Date: Fri, 11 Jul 2008 21:09:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080711190940.GA1367@elstar.local> Mail-Followup-To: Andy Bierman , "tom.petch" , Phil Shafer , netmod@ietf.org References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> <20080711172933.GA1061@elstar.local> <4877A20C.7010607@netconfcentral.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <4877A20C.7010607@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Units 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: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 11, 2008 at 11:10:20AM -0700, Andy Bierman wrote: > I just did a grep on a subset (~40 MIBs) and noticed a few things: > > - capitalization is not consistent with YANG, which aggressively > utilizes lower-case letters > - there were multiple variants, even in this small subset, > most notably Milliseconds, milliseconds, and milli-seconds. > - there were no complex units of measure, not even 'packets per second'. > Maybe SMIv2 UNITS is too restrictive, and YANG should > support these complex units? It should not forbid them, at least. SMIv2 UNITS too restrictive? Here is what RFC 2578 says: This UNITS clause, which need not be present, contains a textual definition of the units associated with that object. I do not think this can every be considered too restrictive. ;-) > - vendor MIBs are not reviewed by MIB Doctors, and many more > inconsistencies exist in vendor MIBs. YANG needs to support > standard and vendor data models. So you want tools to check the content of units statements and to generate warnings (failures??) if there is something unknown showing up. I assume if we collect some say 20-30 common strings that have been used in the SMIv2 space so far (and we list them say in the appendix of YANG), we likely cover 90% of what will show up in the networking space. I am attaching my top N list of UNITS strings extracted from IETF SMIv2 MIB modules. Also note that there are some strings that are perfectly valid if you ask me and pretty much outside of any scientific units. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="top-units-sorted.txt" 486 seconds 192 0.1 dbm 125 packets 120 milliseconds 111 Packets 92 octets 78 Octets 70 bytes 52 frames 49 bps 33 mini-slots 33 microseconds 30 Seconds 24 0.1 dB 23 replies 22 requests 22 Frames 21 kilobits per second 19 transactions 18 minutes 18 hundredths of a second 18 bits/second 17 table entries 17 dB 17 bits per second 16 centi-seconds 14 tenth dB 13 percent 13 Events 12 timeouts 12 codewords 12 Bytes 11 kbps 11 bits 10 tenths of seconds 10 sessions 10 failed logins 10 commands 10 attempts 10 Megabytes 10 0.25dBm 8 percents 8 message units (MUs) 8 instances 7 intervals 7 buffers 7 RMS Volts 7 PDUs 7 Locate messages 6 milli-seconds 6 messages 6 detected CRC Anomalies 6 XID exchanges 6 Watts 6 Kbps 6 K-octets 6 % 5 symbols 5 percentage 5 kHz 5 connections 5 bytes per second 5 blocks 5 TQ (16nsec) 5 SSP messages 5 Milliseconds 5 Kilobits per second 5 0.1 Hertz 4 write requests 4 read requests 4 probes 4 path information units (PIUs) 4 notifications 4 hertz 4 directory entries 4 centiseconds 4 Segments 4 RTP packets 4 KBytes 4 Errors 4 Bundle Links 4 Bits 4 1/100ths of a second 3 reports 3 node entries 3 events 3 days 3 LUs 3 I-frames 3 100ms 3 0.5dBm/Hz 3 0.1 dBm 3 0.1 RMS Amp 2 tests 2 tenths of seconds squared 2 tenths of a second 2 tenth dBm 2 successful logins 2 rows 2 retransmissions 2 resets 2 path switches 2 path switch attempts 2 occurrences 2 normal logouts 2 milliSeconds 2 meters 2 matches 2 m 2 log2 2 line retrains 2 failed write requests 2 failed read requests 2 entries 2 elements 2 degrees in celsius 2 degrees Centigrade 2 connection attempts 2 channel history entries 2 baud 2 abnormal logouts 2 XID frames 2 TenthdB 2 R2Ts 2 Printer Resources 2 Polls 2 Minutes 2 Kilobits per Second 2 Kbytes 2 Hz 2 HundredOfSeconds 2 Collisions 2 Bits per second 2 Bits per Second 2 2^32 symbols 2 2^32 byte blocks 2 0.25dB 2 0.25 dB 2 0.1 dBm/Hz 2 -dBc 1 transport endpoints 1 topology subnetworks 1 time-to-live value 1 ticks 1 thousand bps 1 tenth of a percent 1 spreadIntervals 1 short request timeouts 1 samples 1 revolutions per minute 1 responses 1 repeaters 1 redirected logins 1 rate requests 1 ports 1 period 1 nanoseconds 1 nanometers 1 micro seconds 1 maps 1 liveness timeouts 1 iSCSI nodes 1 hops 1 gaps 1 files 1 failures 1 failed login attempts 1 errors 1 errored frame seconds 1 echo responses 1 disconnections 1 definite responses 1 dBmV 1 dBm/Hz 1 count 1 codesperMinislots 1 byte 1 active alarms 1 Volt-Amps 1 UDP Port 1 Times 1 Timer Expiration Events 1 ThenthdBmV 1 TenthdBmV 1 TG entries 1 TDUs 1 TDU wars 1 Symbol-times 1 Spare Printer Resources 1 Seconds until clearing manually set Overload Bit 1 SIDs 1 SDUs 1 RTP connection setups 1 Number of unknown IS-IS frames seen at this level 1 Number of frames with errors that we have received 1 Number of frames with authentication type mismatches 1 Number of frames with authentication key failures 1 Number of frames with ID length mismatches 1 Number of frames with ID field length mismatch 1 Number of corrupted in-memory frames 1 Number of IS-IS PSNP frames seen in this direction at 1 Number of IS-IS LSP frames seen in this direction at 1 Number of IS-IS Hellos frames seen in this direction 1 Number of IS-IS CSNP frames seen in this direction at 1 Number of ES-IS frames seen in this direction at 1 Number of ES Hello frames seen in this direction at 1 Loopback Suspected Events 1 Error Events 1 CPEs 1 Bundle Name Mismatch Events 1 Bits/Sec 1 ANR packets 1 ANR labels 1 1/1000ths of a second 1 0.5 dBm 1 0.1dBm 1 0.1 Volt DC 1 0.1 Amp DC 1 -0.25 dBm/Hz 1 - 0.25 dBm/Hz --GvXjxJ+pjyke8COw Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --GvXjxJ+pjyke8COw-- From netmod-bounces@ietf.org Fri Jul 11 12:23: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 CEF8328C2DE; Fri, 11 Jul 2008 12:23: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 C639128C2DE for ; Fri, 11 Jul 2008 12:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUkQ4Vty3nE7 for ; Fri, 11 Jul 2008 12:23:33 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 5CBB528C2DB for ; Fri, 11 Jul 2008 12:23:30 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 11 Jul 2008 12:23:42 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 12:23:40 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 12:23:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 12:23:40 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6BJNdx37739; Fri, 11 Jul 2008 12:23:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6BJKpaU037347; Fri, 11 Jul 2008 19:20:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807111920.m6BJKpaU037347@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080711190940.GA1367@elstar.local> Date: Fri, 11 Jul 2008 15:20:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Jul 2008 19:23:40.0095 (UTC) FILETIME=[9FCBC4F0:01C8E38B] Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder writes: >I am attaching my top N list of UNITS strings extracted from IETF >SMIv2 MIB modules. Also note that there are some strings that are >perfectly valid if you ask me and pretty much outside of any >scientific units. Here's the same data for JUNOS. Shockingly boring. Thanks, Phil 242 seconds 86 milliseconds 43 bytes 42 minutes 22 bits per second 21 percent 14 bps 12 microseconds 7 kilobits 7 degrees C 6 packets 5 ms 5 kilobits per second 5 kbps 5 cells 3 kilobytes 3 dB 2 seconds to a power of 2 2 pps 2 per second 2 hours 2 hops 2 feet 2 error(s) per second 1 time in microsecond 1 second 1 priority 1 megabytes 1 megabits per second 1 error(s) per 100 symbol 1 error(s) per 100 frames 1 bits 1 baud 1 YYYYMMDD 1 HHMMSS _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 11 12: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 7A99028C2DB; Fri, 11 Jul 2008 12: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 D1C0628C2DB for ; Fri, 11 Jul 2008 12:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=1.342, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBEDLl1+gFhb for ; Fri, 11 Jul 2008 12:26:21 -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 E736228C2D0 for ; Fri, 11 Jul 2008 12:26:20 -0700 (PDT) Received: (qmail 14782 invoked from network); 11 Jul 2008 19:26:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.71.56 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 11 Jul 2008 19:26:33 -0000 X-YMail-OSG: yUevRXYVM1mKR7kQDKOjleecI521wFRV8brdqpH2K6NmoPBl9qH.AaFETzJNduefKrHuxUzGJw.uiTpiMVO1lz9QID38QXao4au5FDladQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4877B3E7.90007@netconfcentral.com> Date: Fri, 11 Jul 2008 12:26:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andy Bierman , "tom.petch" , Phil Shafer , netmod@ietf.org References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> <20080711172933.GA1061@elstar.local> <4877A20C.7010607@netconfcentral.com> <20080711190940.GA1367@elstar.local> In-Reply-To: <20080711190940.GA1367@elstar.local> Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org 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 Fri, Jul 11, 2008 at 11:10:20AM -0700, Andy Bierman wrote: > >> I just did a grep on a subset (~40 MIBs) and noticed a few things: >> >> - capitalization is not consistent with YANG, which aggressively >> utilizes lower-case letters >> - there were multiple variants, even in this small subset, >> most notably Milliseconds, milliseconds, and milli-seconds. >> - there were no complex units of measure, not even 'packets per second'. >> Maybe SMIv2 UNITS is too restrictive, and YANG should >> support these complex units? It should not forbid them, at least. > > SMIv2 UNITS too restrictive? Here is what RFC 2578 says: > > This UNITS clause, which need not be present, contains a textual > definition of the units associated with that object. > > I do not think this can every be considered too restrictive. ;-) > >> - vendor MIBs are not reviewed by MIB Doctors, and many more >> inconsistencies exist in vendor MIBs. YANG needs to support >> standard and vendor data models. > > So you want tools to check the content of units statements and to > generate warnings (failures??) if there is something unknown showing > up. I assume if we collect some say 20-30 common strings that have > been used in the SMIv2 space so far (and we list them say in the > appendix of YANG), we likely cover 90% of what will show up in the > networking space. > > I am attaching my top N list of UNITS strings extracted from IETF > SMIv2 MIB modules. Also note that there are some strings that are > perfectly valid if you ask me and pretty much outside of any > scientific units. > The issue seems to be whether the units-stmt is just a specialized description-stmt (like reference-stmt is), or whether it can be useful to applications as well. Humans are much better at string matching milli-seconds and Milliseconds than machines. > /js > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 14 02:10: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 3FA1728C228; Mon, 14 Jul 2008 02:10: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 50E4F28C232 for ; Mon, 14 Jul 2008 02:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, GB_I_LETTER=-2, 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 sAoJZO0M13OW for ; Mon, 14 Jul 2008 02:10: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 0F5A128C228 for ; Mon, 14 Jul 2008 02:10:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3570C000D; Mon, 14 Jul 2008 11:11: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 l+b+1pwSNTEJ; Mon, 14 Jul 2008 11:11:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CC27C0033; Mon, 14 Jul 2008 11:11:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA24A60A136; Mon, 14 Jul 2008 11:11:01 +0200 (CEST) Date: Mon, 14 Jul 2008 11:11:01 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080714091101.GA7836@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1215436355.23783.70.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1215436355.23783.70.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] regexp for domain name 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, Jul 07, 2008 at 03:12:35PM +0200, Ladislav Lhotka wrote: > Hi, > > the regexp for domain-name in draft-schoenw-netmod-yang-types-00 is > > '([\p{L}\p{N}]+\.)*[\p{L}\p{N}]' > > The obvious problem is that it should allow hyphens. > > Also, the class \p{L} stands for Unicode letters whereas RFC 1034 only > allows the 52 ASCII letters. Or has it been extended to Unicode letters? I will change this patter to read as follows: '([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+' /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 Jul 14 02:19: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 4507228C242; Mon, 14 Jul 2008 02:19: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 8796628C242 for ; Mon, 14 Jul 2008 02:19:06 -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.189, 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 NWNjAB06UyNV for ; Mon, 14 Jul 2008 02:19:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8716F28C203 for ; Mon, 14 Jul 2008 02:19:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8531C003C; Mon, 14 Jul 2008 11:19:30 +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 LqYi8kNyMpAi; Mon, 14 Jul 2008 11:19:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62FA2C000D; Mon, 14 Jul 2008 11:19:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E83F960A1E8; Mon, 14 Jul 2008 11:19:24 +0200 (CEST) Date: Mon, 14 Jul 2008 11:19:24 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080714091924.GB7836@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <486FA0BA.9040601@netconfcentral.com> <20080706.222745.190320188.mbj@tail-f.com> <1215424637.23783.31.camel@missotis> <20080707103159.GA4710@elstar.local> <1215432618.23783.59.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1215432618.23783.59.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] range/length and pattern statements 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, Jul 07, 2008 at 02:10:18PM +0200, Ladislav Lhotka wrote: > For example, the pattern for ipv6-address in > draft-schoenw-netmod-yang-types-00 is not correct. The alternative for > shortened address is (omitting the scope part) > > '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' > + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' > > but this allows any number of 16-bit blocks to the left and to the right > of the double colon, which is wrong. > > Both the full and shortened form of an IPv6 address can be restricted > together by > > '([0-9a-fA-F]{0,4}:){0,7}[0-9a-fA-F]{0,4}' > > AND > > '(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::' > + '(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?' > > A single-expression alternative can be derived from the ABNF in RFC 3986 > (it's used in pyang), but it would be prohibitively long and > complicated. I see your point. I leave this particular type definition unchanged since we first need to figure out whether we want to add multiple ANDed pattern to YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 14 04:32: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 9BE3B3A6B1B; Mon, 14 Jul 2008 04:32: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 9618A28C2B2 for ; Mon, 14 Jul 2008 04:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs9Ma4uCe1HG for ; Mon, 14 Jul 2008 04:32:16 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3AE7B3A6B1B for ; Mon, 14 Jul 2008 04:30:59 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0531BD800BD for ; Mon, 14 Jul 2008 13:31:24 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4877A20C.7010607@netconfcentral.com> References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> <20080711172933.GA1061@elstar.local> <4877A20C.7010607@netconfcentral.com> Organization: CESNET Date: Mon, 14 Jul 2008 13:31:23 +0200 Message-Id: <1216035083.6359.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IFDDoSAxMS4gMDcuIDIwMDggdiAxMToxMCAtMDcwMDoKCj4g TkFTQSB0aGlua3MgdGhleSBmb3VuZCB0aGUgd3JlY2thZ2Ugb2YgdGhlIE1hcnMgUG9sYXIgTGFu ZGVyOgo+IGh0dHA6Ly93d3cuc2t5YW5kdGVsZXNjb3BlLmNvbS9uZXdzLzMzMTAyODEuaHRtbAo+ IApUbyB0aGlzIGVuZCwgaXQgd291bGQgYmUgZXZlbiBzYWZlciB0byBpbmNsdWRlIHRoZSB1bml0 cyBpbiB0aGUgaW5zdGFuY2UKZG9jdW1lbnRzIChORVRDT05GIFBEVXMpLiBXb3VsZCBpdCBiZSB0 b28gbXVjaCB0byBhc3NpZ24gYW4gWE1MCnJlcHJlc2VudGF0aW9uIHRvIHVuaXRzLXN0bXQ/IFRo ZSBsZWFzdCBpbnRydXNpdmUgc2VlbXMgdG8gYmUgYW4Kb3B0aW9uYWwgWE1MIGF0dHJpYnV0ZSB3 aG9zZSB2YWx1ZSwgaWYgcHJlc2VudCwgbXVzdCBiZSBleGFjdGx5IHdoYXQgaXMKcHJlc2NyaWJl ZCBieSB0aGUgdW5pdHMtc3RtdC4gRm9yIGV4YW1wbGUKCmxlYWYgbWF4LWxlYXNlLXRpbWUgewog ICB0eXBlIHVpbnQzMjsKICAgdW5pdHMgc2Vjb25kczsKICAgZGVmYXVsdCA3MjAwOwogICAgICB9 Cgp3b3VsZCBhbGxvdyBlaXRoZXIKCjxtYXgtbGVhc2UtdGltZT4xMjAwPC9tYXgtbGVhc2UtdGlt ZT4KCmFzIGJlZm9yZSwgb3IKCu+7vzxtYXgtbGVhc2UtdGltZSB1bml0cz0ic2Vjb25kcyI+MTIw MDwvbWF4LWxlYXNlLXRpbWU+CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQ IEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jul 14 06:45: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 E33083A69D8; Mon, 14 Jul 2008 06:45: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 C26C43A69BC for ; Mon, 14 Jul 2008 06:45:15 -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=1.401, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Y-2UyWmzAjQf for ; Mon, 14 Jul 2008 06:45:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8B74D3A686B for ; Mon, 14 Jul 2008 06:45:11 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 1EF7ED800BD; Mon, 14 Jul 2008 15:45:36 +0200 (CEST) From: Ladislav Lhotka To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20080714091101.GA7836@elstar.local> References: <1215436355.23783.70.camel@missotis> <20080714091101.GA7836@elstar.local> Organization: CESNET Date: Mon, 14 Jul 2008 15:45:35 +0200 Message-Id: <1216043135.6359.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: NETMOD Working Group Subject: Re: [netmod] regexp for domain name X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SnVlcmdlbiBTY2hvZW53YWVsZGVyIHDDrcWhZSB2IFBvIDE0LiAwNy4gMjAwOCB2IDExOjExICsw MjAwOgo+IE9uIE1vbiwgSnVsIDA3LCAyMDA4IGF0IDAzOjEyOjM1UE0gKzAyMDAsIExhZGlzbGF2 IExob3RrYSB3cm90ZToKPiA+IEhpLAo+ID4gCj4gPiB0aGUgcmVnZXhwIGZvciBkb21haW4tbmFt ZSBpbiBkcmFmdC1zY2hvZW53LW5ldG1vZC15YW5nLXR5cGVzLTAwIGlzIAo+ID4gCj4gPiAnKFtc cHtMfVxwe059XStcLikqW1xwe0x9XHB7Tn1dJwo+ID4gCj4gPiBUaGUgb2J2aW91cyBwcm9ibGVt IGlzIHRoYXQgaXQgc2hvdWxkIGFsbG93IGh5cGhlbnMuCj4gPiAKPiA+IEFsc28sIHRoZSBjbGFz cyBccHtMfSBzdGFuZHMgZm9yIFVuaWNvZGUgbGV0dGVycyB3aGVyZWFzIFJGQyAxMDM0IG9ubHkK PiA+IGFsbG93cyB0aGUgNTIgQVNDSUkgbGV0dGVycy4gT3IgaGFzIGl0IGJlZW4gZXh0ZW5kZWQg dG8gVW5pY29kZSBsZXR0ZXJzPwo+IAo+IEkgd2lsbCBjaGFuZ2UgdGhpcyBwYXR0ZXIgdG8gcmVh ZCBhcyBmb2xsb3dzOgo+IAo+IAknKFthLXpBLVowLTlcLV0rXC4pKlthLXpBLVowLTlcLV0rJwoK QWNjb3JkaW5nIHRvIFJGQyAxMDM0IGl0IHNob3VsZCBiZQoKKFthLXpBLVpdW2EtekEtWjAtOVwt XSpbYS16QS1aMC05XVwuKSpbYS16QS1aXVthLXpBLVowLTlcLV0qW2EtekEtWjAtOV0KCkxhZGEK Ci0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcg bGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QK From netmod-bounces@ietf.org Mon Jul 14 07:00: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 3351E28C29F; Mon, 14 Jul 2008 07:00: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 6D04828C29F for ; Mon, 14 Jul 2008 07:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=-0.131, 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 m3htoZTUQWdh for ; Mon, 14 Jul 2008 07:00: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 2ED3828C1EF for ; Mon, 14 Jul 2008 07:00:27 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8DA3C0039; Mon, 14 Jul 2008 16:00: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 oH0k0ju5unvc; Mon, 14 Jul 2008 16:00: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 5CBB3C0049; Mon, 14 Jul 2008 16:00:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DAF3460AB8A; Mon, 14 Jul 2008 16:00:46 +0200 (CEST) Date: Mon, 14 Jul 2008 16:00:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20080714140046.GB9497@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1215436355.23783.70.camel@missotis> <20080714091101.GA7836@elstar.local> <1216043135.6359.24.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1216043135.6359.24.camel@missotis> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] regexp for domain name 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, Jul 14, 2008 at 03:45:35PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v Po 14. 07. 2008 v 11:11 +0200: > > > > I will change this patter to read as follows: > > > > '([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+' > > According to RFC 1034 it should be > > ([a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9] Yes, even better. I have fixed this in the .xml sources but it won't be in the next ID which is already sitting in the ID publication queue. /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 Jul 14 07:28: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 3DDDC3A6896; Mon, 14 Jul 2008 07:28: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 2F9B23A68C3 for ; Mon, 14 Jul 2008 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=0.226, 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 cQ6XvYXnfQDc for ; Mon, 14 Jul 2008 07:28:16 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5D6403A6896 for ; Mon, 14 Jul 2008 07:28:16 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 9D780D800BD for ; Mon, 14 Jul 2008 16:28:41 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Mon, 14 Jul 2008 16:28:41 +0200 Message-Id: <1216045721.6359.36.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [netmod] session agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I apparently made a mistake by booking my (and unfortunately also my wife's) return flight from Dublin on Friday morning. Now I learnt that there are two scheduled NETMOD sessions, one on Thursday and another on Friday. Is the agenda for both sessions already fixed? Thanks, Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 14 08:01: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 2FFA13A6AED; Mon, 14 Jul 2008 08:01: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 DF0BF3A6AD8 for ; Mon, 14 Jul 2008 08:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMpeeVPsNCP3 for ; Mon, 14 Jul 2008 08:01:54 -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 30A7A28C2EE for ; Mon, 14 Jul 2008 08:01:02 -0700 (PDT) Received: (qmail 88341 invoked from network); 14 Jul 2008 15:01:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.173.187 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 14 Jul 2008 15:01:26 -0000 X-YMail-OSG: 4rqY7lYVM1nHDiJAeHPiZLzGJgXBCQsHY9lB7cdUGYUBZDQxismyhaGWTd87QoL3xoRltddbtxl0L6FCHKYp07sY10b7ZEs2Zz85ntxFC6G.uzkMNBwTlEmiB4ruIZxy3gqviNv5mnsJ7Bnr2nag0U4wqPz9kY5nOCf9WpaFqVG9qsg- X-Yahoo-Newman-Property: ymail-5 Message-ID: <487B6A45.8000900@netconfcentral.com> Date: Mon, 14 Jul 2008 08:01:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> <20080711172933.GA1061@elstar.local> <4877A20C.7010607@netconfcentral.com> <1216035083.6359.10.camel@missotis> In-Reply-To: <1216035083.6359.10.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org 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+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQw6EgMTEuIDA3 LiAyMDA4IHYgMTE6MTAgLTA3MDA6Cj4gCj4+IE5BU0EgdGhpbmtzIHRoZXkgZm91bmQgdGhlIHdy ZWNrYWdlIG9mIHRoZSBNYXJzIFBvbGFyIExhbmRlcjoKPj4gaHR0cDovL3d3dy5za3lhbmR0ZWxl c2NvcGUuY29tL25ld3MvMzMxMDI4MS5odG1sCj4+Cj4gVG8gdGhpcyBlbmQsIGl0IHdvdWxkIGJl IGV2ZW4gc2FmZXIgdG8gaW5jbHVkZSB0aGUgdW5pdHMgaW4gdGhlIGluc3RhbmNlCj4gZG9jdW1l bnRzIChORVRDT05GIFBEVXMpLiBXb3VsZCBpdCBiZSB0b28gbXVjaCB0byBhc3NpZ24gYW4gWE1M Cj4gcmVwcmVzZW50YXRpb24gdG8gdW5pdHMtc3RtdD8gVGhlIGxlYXN0IGludHJ1c2l2ZSBzZWVt cyB0byBiZSBhbgo+IG9wdGlvbmFsIFhNTCBhdHRyaWJ1dGUgd2hvc2UgdmFsdWUsIGlmIHByZXNl bnQsIG11c3QgYmUgZXhhY3RseSB3aGF0IGlzCj4gcHJlc2NyaWJlZCBieSB0aGUgdW5pdHMtc3Rt dC4gRm9yIGV4YW1wbGUKPiAKPiBsZWFmIG1heC1sZWFzZS10aW1lIHsKPiAgICB0eXBlIHVpbnQz MjsKPiAgICB1bml0cyBzZWNvbmRzOwo+ICAgIGRlZmF1bHQgNzIwMDsKPiAgICAgICB9Cj4gCj4g d291bGQgYWxsb3cgZWl0aGVyCj4gCj4gPG1heC1sZWFzZS10aW1lPjEyMDA8L21heC1sZWFzZS10 aW1lPgo+IAo+IGFzIGJlZm9yZSwgb3IKPiAKPiDvu788bWF4LWxlYXNlLXRpbWUgdW5pdHM9InNl Y29uZHMiPjEyMDA8L21heC1sZWFzZS10aW1lPgo+IAoKCkkgZG9uJ3QgcmVhbGx5IGFncmVlLgpU aGUgbWFuYWdlciBjYW5ub3QgZG8gYW55dGhpbmcgbWVhbmluZ2Z1bCB3aXRob3V0IHRoZSBzY2hl bWEuClRoZSBhZ2VudCBjZXJ0YWlubHkgbmVlZHMgdG8ga25vdyBpdHMgb3duIGRhdGEgbW9kZWxz LgpTbyBuZWl0aGVyIE5FVENPTkYgZW50aXR5IHNob3VsZCBuZWVkIHRoaXMgZXh0cmEgaGludC4K VGhleSBrbm93IGFib3V0IG1heC1sZWFzZS10aW1lIDEwMCUgb3IgMCUuCgo+IExhZGEKPiAKCkFu ZHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1v ZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jul 14 08:21: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 832E93A6842; Mon, 14 Jul 2008 08:21: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 972053A689A for ; Mon, 14 Jul 2008 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=0.201, 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 gk7fHTkHNrpp for ; Mon, 14 Jul 2008 08:21:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CA1F43A6842 for ; Mon, 14 Jul 2008 08:21:33 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 002DAD800BD; Mon, 14 Jul 2008 17:21:58 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <487B6A45.8000900@netconfcentral.com> References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> <20080711172933.GA1061@elstar.local> <4877A20C.7010607@netconfcentral.com> <1216035083.6359.10.camel@missotis> <487B6A45.8000900@netconfcentral.com> Organization: CESNET Date: Mon, 14 Jul 2008 17:21:59 +0200 Message-Id: <1216048919.6359.44.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IFBvIDE0LiAwNy4gMjAwOCB2IDA4OjAxIC0wNzAwOgoKPiBJ IGRvbid0IHJlYWxseSBhZ3JlZS4KPiBUaGUgbWFuYWdlciBjYW5ub3QgZG8gYW55dGhpbmcgbWVh bmluZ2Z1bCB3aXRob3V0IHRoZSBzY2hlbWEuCj4gVGhlIGFnZW50IGNlcnRhaW5seSBuZWVkcyB0 byBrbm93IGl0cyBvd24gZGF0YSBtb2RlbHMuCj4gU28gbmVpdGhlciBORVRDT05GIGVudGl0eSBz aG91bGQgbmVlZCB0aGlzIGV4dHJhIGhpbnQuCj4gVGhleSBrbm93IGFib3V0IG1heC1sZWFzZS10 aW1lIDEwMCUgb3IgMCUuCj4gCgpXZWxsLCB0aGUgZ3V5cyB3aXRoIHRoZSBNYXJzIFBvbGFyIExh bmRlciB3ZXJlIHByb2JhYmx5IGFsc28gc3VwcG9zZWQgdG8Ka25vdy4gQXMgbG9uZyBhcyB0aGUg ZGF0YSBtb2RlbCBpcyB0cmFuc2Zvcm1lZCB0byBjb2RlIGJ5IGh1bWFuCnByb2dyYW1tZXJzLCBz dWNoIGVycm9ycyBoYXBwZW4gYW5kIGluZGljYXRpbmcgdGhlIHVuaXRzIGV4cGxpY2l0bHkgd2l0 aAp0aGUgdmFsdWUgY291bGQgYmUgYW4gZXh0cmEgbWVhc3VyZSBhZ2FpbnN0IHRoZW0uCgpMYWRh CgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5n IGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jul 14 08:31: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 BF16028C1BB; Mon, 14 Jul 2008 08:31: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 1755828C1BB for ; Mon, 14 Jul 2008 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T91z0Y5qllZ3 for ; Mon, 14 Jul 2008 08:31:37 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2A0723A6A3B for ; Mon, 14 Jul 2008 08:31:32 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 547DC616001; Mon, 14 Jul 2008 17:32:21 +0200 (CEST) Date: Mon, 14 Jul 2008 17:21:13 +0200 (CEST) Message-Id: <20080714.172113.237954332.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1216043135.6359.24.camel@missotis> References: <1215436355.23783.70.camel@missotis> <20080714091101.GA7836@elstar.local> <1216043135.6359.24.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] regexp for domain name X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyIHDDrcWhZSB2IFBvIDE0LiAwNy4gMjAwOCB2IDExOjExICswMjAwOg0KPiA+IEkg d2lsbCBjaGFuZ2UgdGhpcyBwYXR0ZXIgdG8gcmVhZCBhcyBmb2xsb3dzOg0KPiA+IA0KPiA+IAkn KFthLXpBLVowLTlcLV0rXC4pKlthLXpBLVowLTlcLV0rJw0KPiANCj4gQWNjb3JkaW5nIHRvIFJG QyAxMDM0IGl0IHNob3VsZCBiZQ0KPiANCj4gKFthLXpBLVpdW2EtekEtWjAtOVwtXSpbYS16QS1a MC05XVwuKSpbYS16QS1aXVthLXpBLVowLTlcLV0qW2EtekEtWjAtOV0NCg0KUG9vciAzY29tLmNv bSAoanVzdCBvbmUgZXhhbXBsZSkuICBXaGF0IGFyZSB0aGUgcnVsZXMgdGhhdCBhcmUgcmVhbGx5 DQp1c2VkPw0KDQoNCi9tYXJ0aW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jul 14 08:33: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 E5CA53A6A0F; Mon, 14 Jul 2008 08:33: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 3B6E53A68F3 for ; Mon, 14 Jul 2008 08:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymDpe-YI11tJ for ; Mon, 14 Jul 2008 08:33:21 -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 854703A6847 for ; Mon, 14 Jul 2008 08:33:21 -0700 (PDT) Received: (qmail 65731 invoked from network); 14 Jul 2008 15:33:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.173.187 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 14 Jul 2008 15:33:46 -0000 X-YMail-OSG: sqqVWq0VM1mhS8c57GClWgEVsIYyUsIq50I5ObHW_TPS6APpgZdufAdv_yhtUuFqGghVXs6hlfUQHSLrOZR63e6yqmCcgtryiOwUwiwgsnKPNMgkgzjSgl9Cos0PNSnCa0yPY8YKhQiGr_jpEKXpwrrKvTX.otnRuw-- X-Yahoo-Newman-Property: ymail-5 Message-ID: <487B71D9.4090309@netconfcentral.com> Date: Mon, 14 Jul 2008 08:33:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200807110145.m6B1jmTI031030@idle.juniper.net> <001501c8e371$96aba4e0$0601a8c0@allison> <20080711172933.GA1061@elstar.local> <4877A20C.7010607@netconfcentral.com> <1216035083.6359.10.camel@missotis> <487B6A45.8000900@netconfcentral.com> <1216048919.6359.44.camel@missotis> In-Reply-To: <1216048919.6359.44.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] Units X-BeenThere: netmod@ietf.org 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+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAxNC4gMDcu IDIwMDggdiAwODowMSAtMDcwMDoKPiAKPj4gSSBkb24ndCByZWFsbHkgYWdyZWUuCj4+IFRoZSBt YW5hZ2VyIGNhbm5vdCBkbyBhbnl0aGluZyBtZWFuaW5nZnVsIHdpdGhvdXQgdGhlIHNjaGVtYS4K Pj4gVGhlIGFnZW50IGNlcnRhaW5seSBuZWVkcyB0byBrbm93IGl0cyBvd24gZGF0YSBtb2RlbHMu Cj4+IFNvIG5laXRoZXIgTkVUQ09ORiBlbnRpdHkgc2hvdWxkIG5lZWQgdGhpcyBleHRyYSBoaW50 Lgo+PiBUaGV5IGtub3cgYWJvdXQgbWF4LWxlYXNlLXRpbWUgMTAwJSBvciAwJS4KPj4KPiAKPiBX ZWxsLCB0aGUgZ3V5cyB3aXRoIHRoZSBNYXJzIFBvbGFyIExhbmRlciB3ZXJlIHByb2JhYmx5IGFs c28gc3VwcG9zZWQgdG8KPiBrbm93LiBBcyBsb25nIGFzIHRoZSBkYXRhIG1vZGVsIGlzIHRyYW5z Zm9ybWVkIHRvIGNvZGUgYnkgaHVtYW4KPiBwcm9ncmFtbWVycywgc3VjaCBlcnJvcnMgaGFwcGVu IGFuZCBpbmRpY2F0aW5nIHRoZSB1bml0cyBleHBsaWNpdGx5IHdpdGgKPiB0aGUgdmFsdWUgY291 bGQgYmUgYW4gZXh0cmEgbWVhc3VyZSBhZ2FpbnN0IHRoZW0uCj4gCgpJTU8sIHRoZSB1bml0cyBj bGF1c2Ugc2hvdWxkIG5ldmVyIGNoYW5nZS4KWW91IGNhbiBvbmx5IGFkZCBvbmUgbGF0ZXIgdG8g Y2xhcmlmeSB0aGUgdW5pdHMgYWxyZWFkeQpkZXNjcmliZWQgaW4gdGhlIGRlc2NyaXB0aW9uIGNs YXVzZS4KClRoaXMgaXMgYSBzbGlwcGVyeSBzbG9wZS4gIFRoZXJlIGFyZSBsb3RzIG9mIGNsYXVz ZXMKZnJvbSB0aGUgWUFORyBtb2R1bGUgdGhhdCBhIG1hbmFnZXIgY291bGQgc2VuZCB0bwptYWtl IGRvdWJsZS1zdXJlIHRoZSBhZ2VudCBhbmQgbWFuYWdlciBhcmUgcmVhbGx5IGluIHN5bmMuCgpQ cm9wZXIgY2hhbmdlIGNvbnRyb2wgcnVsZXMsIHdlbGwtZGVmaW5lZCBkYXRhIG1vZGVscyAody8g cHJvcGVyIHVuaXRzKQphbmQgbW9kdWxlIHZlcnNpb24gZGlzY292ZXJ5IHNob3VsZCBiZSBlbm91 Z2ggdG8gZW5zdXJlIHRoYXQgdGhlCm1hbmFnZXIgYW5kIGFnZW50IGFyZSBpbiBzeW5jIC0tIGZv ciBldmVyeSBhc3BlY3Qgb2YgYSBtb2R1bGUuCgo+IExhZGEKPiAKCkFuZHkKCgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlz dApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QK From netmod-bounces@ietf.org Mon Jul 14 08:40: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 9DBE53A6A37; Mon, 14 Jul 2008 08:40: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 CC3E93A6A37 for ; Mon, 14 Jul 2008 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=1.181, BAYES_00=-2.599, GB_I_LETTER=-2, 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 jjJA8NBk7J1h for ; Mon, 14 Jul 2008 08:40:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F2C0F3A6A0F for ; Mon, 14 Jul 2008 08:40:31 -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 A150BD800C7; Mon, 14 Jul 2008 17:40:57 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080714.172113.237954332.mbj@tail-f.com> References: <1215436355.23783.70.camel@missotis> <20080714091101.GA7836@elstar.local> <1216043135.6359.24.camel@missotis> <20080714.172113.237954332.mbj@tail-f.com> Organization: CESNET Date: Mon, 14 Jul 2008 17:40:57 +0200 Message-Id: <1216050057.6359.48.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: netmod@ietf.org Subject: Re: [netmod] regexp for domain name X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAxNC4gMDcuIDIwMDggdiAxNzoyMSArMDIwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gSnVlcmdlbiBT Y2hvZW53YWVsZGVyIHDDrcWhZSB2IFBvIDE0LiAwNy4gMjAwOCB2IDExOjExICswMjAwOgo+ID4g PiBJIHdpbGwgY2hhbmdlIHRoaXMgcGF0dGVyIHRvIHJlYWQgYXMgZm9sbG93czoKPiA+ID4gCj4g PiA+IAknKFthLXpBLVowLTlcLV0rXC4pKlthLXpBLVowLTlcLV0rJwo+ID4gCj4gPiBBY2NvcmRp bmcgdG8gUkZDIDEwMzQgaXQgc2hvdWxkIGJlCj4gPiAKPiA+IChbYS16QS1aXVthLXpBLVowLTlc LV0qW2EtekEtWjAtOV1cLikqW2EtekEtWl1bYS16QS1aMC05XC1dKlthLXpBLVowLTldCj4gCj4g UG9vciAzY29tLmNvbSAoanVzdCBvbmUgZXhhbXBsZSkuICBXaGF0IGFyZSB0aGUgcnVsZXMgdGhh dCBhcmUgcmVhbGx5Cj4gdXNlZD8KCllvdSBhcmUgcmlnaHQsIFJGQyAxMTIzIHJlbGF4ZWQgdGhp cyAoU2VjIDIuMSkgYW5kIGFsbG93ZWQgZmlyc3QKY2hhcmFjdGVyIHRvIGJlIGVpdGhlciBsZXR0 ZXIgb3IgZGlnaXQuIFNvIGhvcGVmdWxseSB0aGUgZmluYWwgdmVyc2lvbgppcwogICAgJyhbYS16 QS1aMC05XVthLXpBLVowLTlcLV0qW2EtekEtWjAtOV1cLikqJworICAgJ1thLXpBLVowLTldW2Et ekEtWjAtOVwtXSpbYS16QS1aMC05XScKCkxhZGEKCj4gCj4gCj4gL21hcnRpbgotLSAKTGFkaXNs YXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9k QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Jul 16 08:03:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927663A692A; Wed, 16 Jul 2008 08:03: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 B71C13A692A for ; Wed, 16 Jul 2008 08:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 I7YodnD3bgyu for ; Wed, 16 Jul 2008 08:03:12 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id D79343A6938 for ; Wed, 16 Jul 2008 08:03:12 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id qd0V1Z0080S2fkCA1f3icA; Wed, 16 Jul 2008 15:03:42 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id qf3g1Z00E4HwxpC8Vf3h5T; Wed, 16 Jul 2008 15:03:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=pkSQW-a3ZWXZ7PtxC-gA:9 a=vlSvGrfSaTl5K7-tiRAA:9 a=l2zZJz3eQPVllixxDi0A:7 a=T6YlCc6VWHXWIG2DM0aU3C6Ep7EA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Ladislav Lhotka'" , "'NETMOD Working Group'" References: <1216045721.6359.36.camel@missotis> Date: Wed, 16 Jul 2008 11:03:40 -0400 Message-ID: <006e01c8e755$22b7dad0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1216045721.6359.36.camel@missotis> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjlveyIGwfuA79ORqOCNxpXg5AhqQBkTdnQ Subject: Re: [netmod] session agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, We are in the procoess of finalizing the agenda. The chairs discussed what we need to accomplish, and then asked for two sessions. 1) The first is for overview discussions that are important for introducing the new WG, its charter, and its deliverables to "casual observers" and people drawn to the new WG. I expect this will largely be a powerpoint session. Most casual observers are there to report to their company whether any progress is being made, what the general architecture of the technology is, what documents will be worked on, and whether their company should get involved in or follow this new WG. We will focus this meeting on providing the level of information needed for that audience, and deciding whether we have suitable starting documents for each deliverable. 2) The second session is deliberately Friday morning, after the casual observer types have left for the week or gone sightseeing. It will be focused solely on detailed technical issues that have been raised on the mailing list, such as compliance and augments and keyrefs, oh my!. Casual observers who have not read the documents thoroughly will be no help, will not be able to contribute in a meaningful way to the detailed technical discussions, and could be a serious distraction. Casual observers are welcome to attend the session, but I expect they will be bored to tears by this level of discussion. Since this is our first official WG meeting, the chairs felt it appropriate to address the needs of both audiences, but to do so separately. To that end, we asked for seating for 80 for the Thursday session, and seating for 30 with tables for the Friday session. I would not like to mix the two sessions, since the audiences/participants have different levels of understanding of the proposals and different goals. I do consider it unfortunate you did not plan to attend IETF sessions the whole week. I recommend you plan on Friday morning sessions being working sessions for netmod in the future. 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 Ladislav Lhotka > Sent: Monday, July 14, 2008 10:29 AM > To: NETMOD Working Group > Subject: [netmod] session agenda > > Hi, > > I apparently made a mistake by booking my (and unfortunately also my > wife's) return flight from Dublin on Friday morning. Now I learnt that > there are two scheduled NETMOD sessions, one on Thursday and > another on > Friday. Is the agenda for both sessions already fixed? > > Thanks, Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 16 08:59: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 D6FCA28C145; Wed, 16 Jul 2008 08:59: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 91FF03A69FF for ; Wed, 16 Jul 2008 08:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 csxIkXwBD5xL for ; Wed, 16 Jul 2008 08:59:52 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 476AE28C145 for ; Wed, 16 Jul 2008 08:59:52 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id qewy1Z0030b6N64A2g0NsB; Wed, 16 Jul 2008 16:00:22 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id qg0L1Z0024HwxpC8Pg0LNa; Wed, 16 Jul 2008 16:00:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=fdx3kDwbfF72CruzmMUA:9 a=MFYVmpPBal-87izul3UA:9 a=s4oOOvnVQKzM3lJ-x-A1IzoAWNAA:4 a=f7GxY0FH8QIA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'NETMOD Working Group'" Date: Wed, 16 Jul 2008 12:00:19 -0400 Message-ID: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjnXQvZ8DTE+wxzTEu93+aJttTeow== Subject: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Below is the proposed agenda for the two sessions. Sorry this is so late. For the past month, DaveP has been on vacation, and I have been travelling on business. Can each author-team confirm that they will be able to present an overview powerpoint of their proposal during the Thursday session? Phil, can you do an overview of the netmod architecture including the purpose of each deliverable and how the deliverables fit together, for the Thursday session? For Friday: Martin has proposed driving dicussion of the YANG open issues and questions. Juergen, do you need time to discuss library issues? Can the DSDL team be prepared to drive discussion of the DSDL open issues? Comments welcome. -- NETMOD WG IETF 72, Dublin, Ireland WG Chairs: David Partain (david.partain@ericsson.com) David Harrington (ietfdbh@comcast.net) THURSDAY, July 31, 2008 0900-1130 Overview of NETMOD Deliverables Scribes, Agenda bashing, WG status review - David Partain (15 minutes) Presentations providing an overview of the deliverables, plus discussion of drafts proposed as WG items. 1. NETMOD Architecture - How do the Deliverables fit together? (20 min) Phil Shafer No internet-draft available 2. YANG - A data modeling language for NETCONF (40 min) M. Bjorklund http://tools.ietf.org/html/draft-ietf-netmod-yang-00 This presentation will include YIN and XML deliverables 3. Common YANG Data Types (15 min) Juergen Schoenwaelder http://tools.ietf.org/html/draft-schoenw-netmod-yang-types-01 4. Mapping of YANG to DSDL (20 min) Ladislav Lhotka, Sharon Chisholm, Rohan Mahy http://tools.ietf.org/html/draft-mahy-canmod-dsdl-02 Ladislav Lhotka http://tools.ietf.org/html/draft-lhotka-yang-dsdl-map-00 Open mic (20 minutes) Hot topics to discuss? Consensus for Adoption of Drafts as WG Items (10 minutes) How many have read? How many believe the doc is mature enough to be a WG draft? Hums for and against (as contribution toward WG consensus) David Harrington YANG YIN (separate or combined with YANG?) XML Mapping (separate or combined with YANG?) YANG Datatypes DSDL Mapping Wrapup David Partain (10 min) FRIDAY, Aug 1, 2008 0900-1130 Open Issues in NETMOD Scribes, Agenda bashing, WG status review - chairs (15 minutes) Open issues and questions for YANG/YIN/XML/LIB - Martin (60 min) Augment a grouping augment a leaf overlays module conformance vs. agent-variance list keys refinements and augments Conditional content ordered-by statement use of prefix with local names anyxml Rpcs and Notification inside lists default and mandatory Provisioning in anticipation of upgrade ip prefix types deprecated and conformance change control rules order of subelements range/length and pattern statements regexp for domain name ABNF for YANG comments Keyrefs deprecated & obsolete Open issues and questions for DSDL (30 min) Open discussion (30 min) Wrapup - David Partain (15 min) -- Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 16 09:11: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 E95013A690F; Wed, 16 Jul 2008 09:11: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 1EE423A690F for ; Wed, 16 Jul 2008 09:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=0.074, 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 pDzaTArxnrJc for ; Wed, 16 Jul 2008 09:11:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E1F3D3A6909 for ; Wed, 16 Jul 2008 09:11:30 -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 20240D800C4 for ; Wed, 16 Jul 2008 18:12:00 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> References: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> Organization: CESNET Date: Wed, 16 Jul 2008 18:12:00 +0200 Message-Id: <1216224720.20409.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 RGF2aWQgSGFycmluZ3RvbiBww63FoWUgdiBTdCAxNi4gMDcuIDIwMDggdiAxMjowMCAtMDQwMDoK Cj4gRm9yIEZyaWRheToKCi4uCgo+IENhbiB0aGUgRFNETCB0ZWFtIGJlIHByZXBhcmVkIHRvIGRy aXZlIGRpc2N1c3Npb24gb2YgdGhlIERTREwgb3Blbgo+IGlzc3Vlcz8KCkkgYW0gdHJ5aW5nIHRv IGNoYW5nZSBteSBib29raW5nIGZvciB0aGUgcmV0dXJuIGZsaWdodCBhbmQgaG90ZWwsIGlmIEkK c3VjY2VlZCwgSSdsbCBiZSBwcmVwYXJlZC4KCkxhZGEKCj4gCj4gQ29tbWVudHMgd2VsY29tZS4K PiAKPiAtLQo+IE5FVE1PRCBXRyAKPiBJRVRGIDcyLCBEdWJsaW4sIElyZWxhbmQgCj4gICBXRyBD aGFpcnM6IAo+ICAgRGF2aWQgUGFydGFpbiAoZGF2aWQucGFydGFpbkBlcmljc3Nvbi5jb20pCj4g ICBEYXZpZCBIYXJyaW5ndG9uIChpZXRmZGJoQGNvbWNhc3QubmV0KSAKPiAKPiBUSFVSU0RBWSwg SnVseSAzMSwgMjAwOCAwOTAwLTExMzAgCj4gT3ZlcnZpZXcgb2YgTkVUTU9EIERlbGl2ZXJhYmxl cwo+IAo+ICAgU2NyaWJlcywgCj4gICBBZ2VuZGEgYmFzaGluZywgCj4gICBXRyBzdGF0dXMgcmV2 aWV3IC0gRGF2aWQgUGFydGFpbiAoMTUgbWludXRlcykgCj4gCj4gICBQcmVzZW50YXRpb25zIHBy b3ZpZGluZyBhbiBvdmVydmlldyBvZiB0aGUgZGVsaXZlcmFibGVzLCAKPiAgIHBsdXMgZGlzY3Vz c2lvbiBvZiBkcmFmdHMgcHJvcG9zZWQgYXMgV0cgaXRlbXMuCj4gCj4gICAgICAgIDEuIE5FVE1P RCBBcmNoaXRlY3R1cmUgLSBIb3cgZG8gdGhlIERlbGl2ZXJhYmxlcyBmaXQgdG9nZXRoZXI/Cj4g KDIwIG1pbikKPiAgICAgICAgICAgIFBoaWwgU2hhZmVyCj4gICAgICAgICAgICBObyBpbnRlcm5l dC1kcmFmdCBhdmFpbGFibGUKPiAKPiAgICAgICAgMi4gWUFORyAtIEEgZGF0YSBtb2RlbGluZyBs YW5ndWFnZSBmb3IgTkVUQ09ORiAoNDAgbWluKQo+ICAgICAgICAgICAgTS4gQmpvcmtsdW5kCj4g ICAgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC15 YW5nLTAwCj4gICAgICAgICAgICBUaGlzIHByZXNlbnRhdGlvbiB3aWxsIGluY2x1ZGUgWUlOIGFu ZCBYTUwgZGVsaXZlcmFibGVzIAo+IAo+ICAgICAgICAzLiBDb21tb24gWUFORyBEYXRhIFR5cGVz ICgxNSBtaW4pCj4gICAgICAgICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAKPiAg Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nob2Vudy1uZXRtb2QteWFuZy10 eXBlcy0wMSAKPiAKPiAgICAgICAgNC4gTWFwcGluZyBvZiBZQU5HIHRvIERTREwgKDIwIG1pbikK PiAgICAgICAgICAgICBMYWRpc2xhdiBMaG90a2EsIFNoYXJvbiBDaGlzaG9sbSwgUm9oYW4gTWFo eSAKPiAgICAgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYWh5LWNh bm1vZC1kc2RsLTAyIAo+ICAgICAgICAgICAgIExhZGlzbGF2IExob3RrYSAKPiAgICAgICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saG90a2EteWFuZy1kc2RsLW1hcC0w MCAKPiAKPiAgIE9wZW4gbWljICgyMCBtaW51dGVzKSAKPiAgICAgICBIb3QgdG9waWNzIHRvIGRp c2N1c3M/IAo+IAo+ICAgQ29uc2Vuc3VzIGZvciBBZG9wdGlvbiBvZiBEcmFmdHMgYXMgV0cgSXRl bXMgKDEwIG1pbnV0ZXMpCj4gCUhvdyBtYW55IGhhdmUgcmVhZD8gCj4gCUhvdyBtYW55IGJlbGll dmUgdGhlIGRvYyBpcyBtYXR1cmUgZW5vdWdoIHRvIGJlIGEgV0cgZHJhZnQ/Cj4gCUh1bXMgZm9y IGFuZCBhZ2FpbnN0IChhcyBjb250cmlidXRpb24gdG93YXJkIFdHIGNvbnNlbnN1cykKPiAJRGF2 aWQgSGFycmluZ3Rvbgo+IAkJWUFORwo+IAkJWUlOIChzZXBhcmF0ZSBvciBjb21iaW5lZCB3aXRo IFlBTkc/KQo+IAkJWE1MIE1hcHBpbmcgKHNlcGFyYXRlIG9yIGNvbWJpbmVkIHdpdGggWUFORz8p Cj4gCQlZQU5HIERhdGF0eXBlcwo+IAkJRFNETCBNYXBwaW5nCj4gCj4gICBXcmFwdXAgRGF2aWQg UGFydGFpbiAoMTAgbWluKQo+IAo+IEZSSURBWSwgQXVnIDEsIDIwMDggMDkwMC0xMTMwIAo+IE9w ZW4gSXNzdWVzIGluIE5FVE1PRAo+IAo+ICAgU2NyaWJlcywgCj4gICBBZ2VuZGEgYmFzaGluZywg Cj4gICBXRyBzdGF0dXMgcmV2aWV3IC0gY2hhaXJzICgxNSBtaW51dGVzKSAKPiAKPiAgIE9wZW4g aXNzdWVzIGFuZCBxdWVzdGlvbnMgZm9yIFlBTkcvWUlOL1hNTC9MSUIgLSBNYXJ0aW4gKDYwIG1p bikKPiAKPiAJQXVnbWVudCBhIGdyb3VwaW5nCj4gCWF1Z21lbnQgYSBsZWFmCj4gCW92ZXJsYXlz Cj4gCW1vZHVsZSBjb25mb3JtYW5jZSB2cy4gYWdlbnQtdmFyaWFuY2UKPiAJbGlzdCBrZXlzCj4g CXJlZmluZW1lbnRzIGFuZCBhdWdtZW50cwo+IAkJQ29uZGl0aW9uYWwgY29udGVudAo+IAlvcmRl cmVkLWJ5IHN0YXRlbWVudAo+IAl1c2Ugb2YgcHJlZml4IHdpdGggbG9jYWwgbmFtZXMKPiAJYW55 eG1sCj4gCVJwY3MgYW5kIE5vdGlmaWNhdGlvbiBpbnNpZGUgbGlzdHMKPiAJZGVmYXVsdCBhbmQg bWFuZGF0b3J5Cj4gCVByb3Zpc2lvbmluZyBpbiBhbnRpY2lwYXRpb24gb2YgdXBncmFkZQo+IAlp cCBwcmVmaXggdHlwZXMKPiAJZGVwcmVjYXRlZCBhbmQgY29uZm9ybWFuY2UKPiAJY2hhbmdlIGNv bnRyb2wgcnVsZXMKPiAJb3JkZXIgb2Ygc3ViZWxlbWVudHMKPiAJcmFuZ2UvbGVuZ3RoIGFuZCBw YXR0ZXJuIHN0YXRlbWVudHMKPiAJcmVnZXhwIGZvciBkb21haW4gbmFtZQo+IAlBQk5GIGZvciBZ QU5HIGNvbW1lbnRzCj4gCUtleXJlZnMKPiAJZGVwcmVjYXRlZCAmIG9ic29sZXRlCj4gCj4gICBP cGVuIGlzc3VlcyBhbmQgcXVlc3Rpb25zIGZvciBEU0RMICgzMCBtaW4pCj4gCj4gICBPcGVuIGRp c2N1c3Npb24gKDMwIG1pbikKPiAKPiAgIFdyYXB1cCAtIERhdmlkIFBhcnRhaW4gKDE1IG1pbikK PiAKPiAtLQo+IFRoYW5rcywKPiBEYXZpZCBIYXJyaW5ndG9uCj4gZGJoYXJyaW5ndG9uQGNvbWNh c3QubmV0Cj4gaWV0ZmRiaEBjb21jYXN0Lm5ldAo+IGRoYXJyaW5ndG9uQGh1YXdlaS5jb20KPiAK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1v ZCBtYWlsaW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtl eSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Wed Jul 16 13:24:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152303A6891; Wed, 16 Jul 2008 13:24:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4893A6891 for ; Wed, 16 Jul 2008 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 gRe6Sq-XJ3E4 for ; Wed, 16 Jul 2008 13:24:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 85EB13A6862 for ; Wed, 16 Jul 2008 13:24:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03DC5C001C; Wed, 16 Jul 2008 22:25: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 IE35QMADKfCO; Wed, 16 Jul 2008 22:25:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43EA4C0079; Wed, 16 Jul 2008 22:25:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BA4A8634F99; Wed, 16 Jul 2008 22:25:06 +0200 (CEST) Date: Wed, 16 Jul 2008 22:25:06 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080716202506.GA1545@elstar.local> Mail-Followup-To: David Harrington , 'NETMOD Working Group' References: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 'NETMOD Working Group' Subject: Re: [netmod] netmod session agendas 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, Jul 16, 2008 at 12:00:19PM -0400, David Harrington wrote: > Can each author-team confirm that they will be able to present an > overview powerpoint of their proposal during the Thursday session? I will take care of the data types document. > Juergen, do you need time to discuss library issues? At this point in time, I believe it is more critical to get core YANG language issues resolved. So lets put data types last and I fine with skipping this altogether in order to get more YANG language issues resolved. /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 Jul 16 13:47:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010B83A68B4; Wed, 16 Jul 2008 13:47:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF5F3A68B4 for ; Wed, 16 Jul 2008 13:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 J18-1Qp5UoiY for ; Wed, 16 Jul 2008 13:47:18 -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 E34163A67F2 for ; Wed, 16 Jul 2008 13:47:17 -0700 (PDT) Received: (qmail 37896 invoked from network); 16 Jul 2008 20:47:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.173.187 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 16 Jul 2008 20:47:46 -0000 X-YMail-OSG: JghVK8UVM1n0sV24hNcX5BZ2ADyB3mlWJIr0G1p0M3cd8Glf5jAVVoMRB8LhntnUv6YbFRpt7l.WnW9.MkPTjMyxRIFeCuhcxa0GF1A0IA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <487E5E70.1020505@netconfcentral.com> Date: Wed, 16 Jul 2008 13:47:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'NETMOD Working Group' References: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> <20080716202506.GA1545@elstar.local> In-Reply-To: <20080716202506.GA1545@elstar.local> Content-Type: multipart/mixed; boundary="------------010400020204060808080701" Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --------------010400020204060808080701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Wed, Jul 16, 2008 at 12:00:19PM -0400, David Harrington wrote: > >> Can each author-team confirm that they will be able to present an >> overview powerpoint of their proposal during the Thursday session? > > I will take care of the data types document. > >> Juergen, do you need time to discuss library issues? > > At this point in time, I believe it is more critical to get core YANG > language issues resolved. So lets put data types last and I fine with > skipping this altogether in order to get more YANG language issues > resolved. > I extracted the new modules and there are a few typos/errors: module: yang-types, pg. 5: OLD: revision 2009-05-22 { NEW: revision 2008-05-22 { ---------------------- module: inet-types, pg. 17: OLD: express 'URI absent' where required." reference "RFC 3986 STD 66 and RFC 3305" NEW: express 'URI absent' where required."; reference "RFC 3986 STD 66 and RFC 3305"; > /js > Andy --------------010400020204060808080701 Content-Type: text/plain; name="yang-types.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="yang-types.log" Warning: Revision date in the future (2009-05-22) yang-types-00.yang:20.5: warning(421): revision date in the future Warning: no valid revision statements, setting version to '2008-07-16' for module 'yang-types' *** yang-types-00.yang: 0 Errors, 2 Warnings --------------010400020204060808080701 Content-Type: text/plain; name="inet-types.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="inet-types.log" inet-types.yang:321.11: error(245): wrong token type Expected: semi-colon or left brace inet-types.yang:322.7: error(245): wrong token type Expected: semi-colon or left brace *** inet-types.yang: 2 Errors, 0 Warnings --------------010400020204060808080701 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --------------010400020204060808080701-- From netmod-bounces@ietf.org Wed Jul 16 14:38: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 709213A69FB; Wed, 16 Jul 2008 14:38: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 5D03B3A69CE for ; Wed, 16 Jul 2008 14:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 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 XB857eOUolbG for ; Wed, 16 Jul 2008 14:38:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9073E3A690E for ; Wed, 16 Jul 2008 14:38:53 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EE1CC0022; Wed, 16 Jul 2008 23:39:23 +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 iwSSZirqhdRv; Wed, 16 Jul 2008 23:39:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FD8AC0020; Wed, 16 Jul 2008 23:39:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BD268635165; Wed, 16 Jul 2008 23:39:17 +0200 (CEST) Date: Wed, 16 Jul 2008 23:39:17 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080716213917.GA1878@elstar.local> Mail-Followup-To: Andy Bierman , 'NETMOD Working Group' References: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> <20080716202506.GA1545@elstar.local> <487E5E70.1020505@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <487E5E70.1020505@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 'NETMOD Working Group' Subject: Re: [netmod] netmod session agendas 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, Jul 16, 2008 at 01:47:44PM -0700, Andy Bierman wrote: > I extracted the new modules and there are a few typos/errors: > > module: yang-types, pg. 5: > > OLD: > > revision 2009-05-22 { > > NEW: > > revision 2008-05-22 { > > ---------------------- > > module: inet-types, pg. 17: > > OLD: > > express 'URI absent' where required." > reference "RFC 3986 STD 66 and RFC 3305" > > NEW: > > express 'URI absent' where required."; > reference "RFC 3986 STD 66 and RFC 3305"; Thanks, both fixed in my sources. /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 Jul 16 14:56: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 DEA4E3A692D; Wed, 16 Jul 2008 14:56: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 821D23A68B4 for ; Wed, 16 Jul 2008 14:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, 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 C9k-Ji32COwy for ; Wed, 16 Jul 2008 14:56:42 -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 8B3D53A68AB for ; Wed, 16 Jul 2008 14:56:42 -0700 (PDT) Received: (qmail 91330 invoked from network); 16 Jul 2008 21:57:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.173.187 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 16 Jul 2008 21:57:10 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <487E6EB4.5050904@netconfcentral.com> Date: Wed, 16 Jul 2008 14:57:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Harrington , 'NETMOD Working Group' References: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> <20080716202506.GA1545@elstar.local> In-Reply-To: <20080716202506.GA1545@elstar.local> Content-Type: multipart/mixed; boundary="------------030402070409000203000806" Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --------------030402070409000203000806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Wed, Jul 16, 2008 at 12:00:19PM -0400, David Harrington wrote: > >> Can each author-team confirm that they will be able to present an >> overview powerpoint of their proposal during the Thursday session? > > I will take care of the data types document. > >> Juergen, do you need time to discuss library issues? > > At this point in time, I believe it is more critical to get core YANG > language issues resolved. So lets put data types last and I fine with > skipping this altogether in order to get more YANG language issues > resolved. Agreed. I reviewed the draft, and it looks fine to me. I attached the diff files in case anyone wants to verify that clarifications and bugfixes are the only changes from yang-00. > > /js > Andy --------------030402070409000203000806 Content-Type: text/plain; name="svndiff.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="svndiff.log" Index: yang-types.yang =================================================================== --- yang-types.yang (revision 54) +++ yang-types.yang (working copy) @@ -9,14 +9,15 @@ "YANG Language Design Team"; contact - "Martin Bjorklund (Editor) "; + "Juergen Schoenwaelder (Editor) + "; description "This module contains standard derived YANG types."; - reference "draft-ietf-netmod-yang-00.txt"; + reference "draft-schoenw-netmod-yang-types-01.txt"; - revision 2007-10-02 { + revision 2009-05-22 { description "Initial revision."; } @@ -147,7 +148,7 @@ typedef uri { type string; description - "A uri type represents Uniform Resource Identifier (URI) + "A uri type represents Uniform Resource Identifier (URI) as defined by STD 66. Objects using this type MUST be in US-ASCII encoding, and @@ -176,12 +177,13 @@ typedef object-identifier { type string { - pattern '[0-2](\.\d+)+'; + pattern '([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*)))' + + '(\.(0|([1-9]\d*)))*'; } description "The object-identifier type represents administratively assigned names in a registration-hierarchical-name tree. - + Values of this type are denoted as a sequence of numerical non-negative sub-identifier values. Each sub-identifier value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers @@ -229,13 +231,14 @@ date-time = full-date "T" full-time'; reference "RFC 3339"; } - + typedef timeticks { type uint32; description "The timeticks type represents a non-negative integer which represents the time, modulo 2^32 (4294967296 decimal), in hundredths of a second between two epochs. + When objects are defined which use this type, the description of the object identifies both of the reference epochs."; @@ -271,7 +274,7 @@ type string; description "Represents media- or physical-level addresses."; - reference + reference "RFC 2579 (STD 58)"; } } Index: inet-types.yang =================================================================== --- inet-types.yang (revision 54) +++ inet-types.yang (working copy) @@ -1,278 +1,325 @@ -module inet-types { + module inet-types { - // XXX namespace to be allocated by IANA + // XXX namespace to be allocated by IANA - namespace "urn:ietf:params:xml:ns:yang:inet-types"; - prefix "inet"; + namespace "urn:ietf:params:xml:ns:yang:inet-types"; + prefix "inet"; - organization - "YANG Language Design Team"; + organization + "YANG Language Design Team"; - contact - "Martin Bjorklund (Editor) "; + contact + "Juergen Schoenwaelder (Editor) + "; - description - "This module contains standard derived YANG types - for Internet addresses and related things."; + description + "This module contains standard derived YANG types + for Internet addresses and related things."; - reference "draft-ietf-netmod-yang-00.txt"; + reference "draft-schoenw-netmod-yang-types-01.txt"; - revision 2007-10-02 { - description "Initial revision."; - } + revision 2008-06-07 { + description "Initial revision."; + } - /* - * collection of protocol field related types - */ + /* + * collection of protocol field related types + */ - typedef ip-version { - type enumeration { - enum unknown { - value 0; - description - "An unknown or unspecified version of the - Internet protocol."; - } - enum ipv4 { - value 1; - description - "The IPv4 protocol as defined in RFC 791."; - } - enum ipv6 { - value 2; - description - "The IPv6 protocol as defined in RFC 2460."; - } - } - description - "This value represents the version of the IP protocol."; - reference - "RFC 791 (STD 5), RFC 2460"; - } + typedef ip-version { + type enumeration { + enum unknown { + value 0; + description + "An unknown or unspecified version of the + Internet protocol."; + } + enum ipv4 { + value 1; + description + "The IPv4 protocol as defined in RFC 791."; + } + enum ipv6 { + value 2; + description + "The IPv6 protocol as defined in RFC 2460."; + } + } + description + "This value represents the version of the IP protocol."; + reference + "RFC 791 (STD 5), RFC 2460"; + } - typedef dscp { - type uint8 { - range "0..63"; - } - description - "The dscp type represents a Differentiated Services - Code-Point that may be used for marking a traffic - stream."; - reference - "RFC 3289, RFC 2474, RFC 2780"; - } + typedef dscp { + type uint8 { + range "0..63"; + } + description + "The dscp type represents a Differentiated Services + Code-Point that may be used for marking a traffic + stream."; + reference + "RFC 3289, RFC 2474, RFC 2780"; + } - typedef flow-label { - type uint32 { - range "0..1048575"; - } - description - "The flow-label type represents flow identifier or - Flow Label in an IPv6 packet header that may be - used to discriminate traffic flows."; - reference - "RFC 2460"; - } + typedef flow-label { + type uint32 { + range "0..1048575"; + } + description + "The flow-label type represents flow identifier or + Flow Label in an IPv6 packet header that may be + used to discriminate traffic flows."; + reference + "RFC 2460"; + } - typedef port-number { - type uint16 { - range "1..65535"; - } - description - "The port-number type represents a 16-bit port - number of an Internet transport layer protocol - such as UDP, TCP, DCCP or SCTP. Port numbers are - assigned by IANA. A current list of all - assignments is available from - . + typedef port-number { + type uint16 { + range "1..65535"; + } + description + "The port-number type represents a 16-bit port + number of an Internet transport layer protocol + such as UDP, TCP, DCCP or SCTP. Port numbers are + assigned by IANA. A current list of all + assignments is available from + . - Note that the value zero is not a valid port - number. A union type might be used in situations - where the value zero is meaningful."; - reference - "RFC 4001"; - } - - /* - * collection of autonomous system related types - */ + Note that the value zero is not a valid port + number. A union type might be used in situations + where the value zero is meaningful."; + reference + "RFC 4001"; + } - typedef asn { - type uint32; - description - "The asn type represents autonomous system numbers which - identify an Autonomous System (AS). An AS is a set of - routers under a single technical administration, using an - interior gateway protocol and common metrics to route - packets within the AS, and using an exterior gateway - protocol to route packets to other ASs'. IANA maintains - the AS number space and has delegated large parts to the - regional registries. + /* + * collection of autonomous system related types + */ - Autonomous system numbers are currently limited to 16 bits - (0..65535). There is however work in progress to enlarge - the autonomous system number space to 32 bits. This - textual convention therefore uses an uint32 base type - without a range restriction in order to support a larger - autonomous system number space."; - reference - "RFC 1771, RFC 1930, RFC 4001"; - } + typedef as-number { + type uint32; + description + "The as-number type represents autonomous system numbers + which identify an Autonomous System (AS). An AS is a set + of routers under a single technical administration, using + an interior gateway protocol and common metrics to route + packets within the AS, and using an exterior gateway + protocol to route packets to other ASs'. IANA maintains + the AS number space and has delegated large parts to the + regional registries. - /* - * collection of IP address and hostname related types - */ + Autonomous system numbers are currently limited to 16 bits + (0..65535). There is however work in progress to enlarge + the autonomous system number space to 32 bits. This + textual convention therefore uses an uint32 base type + without a range restriction in order to support a larger + autonomous system number space."; + reference + "RFC 1771, RFC 1930, RFC 4001"; + } - typedef ip-address { - type union { - type inet:ipv4-address; - type inet:ipv6-address; - } - description - "The ip-address type represents an IP address and - is IP version neutral. The format of the textual - representations implies the IP version."; - } + /* + * collection of IP address and hostname related types + */ - typedef ipv4-address { - type string { - pattern - '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' - + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' - + '(%[\p{N}\p{L}]+)?'; - } - description - "The ipv4-address type represents an IPv4 address in - dotted-quad notation. The IPv4 address may include - a zone index, separated by a % sign."; - } + typedef ip-address { + type union { + type inet:ipv4-address; + type inet:ipv6-address; + } + description + "The ip-address type represents an IP address and + is IP version neutral. The format of the textual + representations implies the IP version."; + } - typedef ipv6-address { - type string { - pattern - /* full */ - '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' - + '(%[\p{N}\p{L}]+)?)' - /* mixed */ - + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' - + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' - + '(%[\p{N}\p{L}]+)?)' - /* shortened */ - + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' - + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' - + '(%[\p{N}\p{L}]+)?)' - /* shortened mixed */ - + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' - + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' - + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' - + '(%[\p{N}\p{L}]+)?)'; - } - description - "The ipv6-address type represents an IPv6 address in - full, mixed, shortened and shortened mixed notation. - The IPv6 address may include a zone index, separated - by a % sign."; - } + typedef ipv4-address { + type string { + pattern + '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' + + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' + + '(%[\p{N}\p{L}]+)?'; + } - typedef ip-prefix { - type union { - type inet:ipv4-prefix; - type inet:ipv6-prefix; - } - description - "The ip-prefix type represents an IP prefix and - is IP version neutral. The format of the textual - representations implies the IP version."; - } + description + "The ipv4-address type represents an IPv4 address in + dotted-quad notation. The IPv4 address may include + a zone index, separated by a % sign. - typedef ipv4-prefix { - type string { - pattern - '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' - + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' - + '/\p{N}+'; - } - description - "The ipv4-prefix type represents an IPv4 address prefix. - The prefix length is given by the number following the - slash character and must be less than or equal 32. - Values larger than 32 should be treated as 32. + 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."; + } - A prefix length value of n corresponds to an IP address - mask which has n contiguous 1-bits from the most - significant bit (MSB) and all other bits set to 0. + typedef ipv6-address { + type string { + pattern + /* full */ + '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' + + '(%[\p{N}\p{L}]+)?)' + /* mixed */ + + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' + + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + + '(%[\p{N}\p{L}]+)?)' + /* shortened */ + + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' + + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' + + '(%[\p{N}\p{L}]+)?)' + /* shortened mixed */ + + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' + + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' + + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + + '(%[\p{N}\p{L}]+)?)'; + } + description + "The ipv6-address type represents an IPv6 address in + full, mixed, shortened and shortened mixed notation. + The IPv6 address may include a zone index, separated + by a % sign. - The IPv4 address represented in dotted quad notation - should have all bits that do not belong to the prefix - set to zero."; - } + 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."; + reference + "RFC 4007: IPv6 Scoped Address Architecture"; + } - typedef ipv6-prefix { - type string { - pattern - /* full */ - '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' - + '/\p{N}+)' - /* mixed */ - + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' - + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' - + '/\p{N}+)' - /* shortened */ - + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' - + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' - + '/\p{N}+)' - /* shortened mixed */ - + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' - + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' - + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' - + '/\p{N}+)'; - } - description - "The ipv6-prefix type represents an IPv6 address prefix. - The prefix length is given by the number following the - slash character and must be less than or equal 128. - Values larger than 128 should be treated as 128. + typedef ip-prefix { + type union { + type inet:ipv4-prefix; + type inet:ipv6-prefix; + } + description + "The ip-prefix type represents an IP prefix and + is IP version neutral. The format of the textual + representations implies the IP version."; + } - A prefix length value of n corresponds to an IP address - mask which has n contiguous 1-bits from the most - significant bit (MSB) and all other bits set to 0. + typedef ipv4-prefix { + type string { + pattern + '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' + + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' + + '/\p{N}+'; + } + description + "The ipv4-prefix type represents an IPv4 address prefix. + The prefix length is given by the number following the + slash character and must be less than or equal 32. - The IPv6 address represented in dotted quad notation - should have all bits that do not belong to the prefix - set to zero."; - } + A prefix length value of n corresponds to an IP address + mask which has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. - typedef domain-name { - type string { - pattern '([\p{L}\p{N}]+\.)*[\p{L}\p{N}]'; - } - description - "The domain-name type represents a DNS domain - name. The name SHOULD be fully qualified - whenever possible. + The IPv4 address represented in dotted quad notation + should have all bits that do not belong to the prefix + set to zero."; + } - The description clause of objects using the - domain-name type MUST describe how (and when) - these names are resolved to IP addresses. + typedef ipv6-prefix { + type string { + pattern + /* full */ + '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' + + '/\p{N}+)' + /* mixed */ + + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' + + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + + '/\p{N}+)' + /* shortened */ + + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' + + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' + + '/\p{N}+)' + /* shortened mixed */ + + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' + + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' + + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + + '/\p{N}+)'; + } + description + "The ipv6-prefix type represents an IPv6 address prefix. + The prefix length is given by the number following the + slash character and must be less than or equal 128. - Note that the resolution of a domain-name value - may require to query multiple DNS records (e.g., - A for IPv4 and AAAA for IPv6). The order of the - resolution process and which DNS record takes - precedence depends on the configuration of the - resolver."; - reference - "RFC 1034"; - } + A prefix length value of n corresponds to an IP address + mask which has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. - typedef host { - type union { - type inet:ip-address; - type inet:domain-name; - } - description - "The host type represents either an IP address - or a DNS domain name."; - } + The IPv6 address should have all bits that do not belong + to the prefix set to zero."; + } -} + /* + * Domain name and URI types. + */ + + typedef domain-name { + type string { + pattern '([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+'; + } + description + "The domain-name type represents a DNS domain + name. The name SHOULD be fully qualified + whenever possible. + + The description clause of objects using the + domain-name type MUST describe how (and when) + these names are resolved to IP addresses. + + Note that the resolution of a domain-name value + may require to query multiple DNS records (e.g., + A for IPv4 and AAAA for IPv6). The order of the + resolution process and which DNS record takes + precedence depends on the configuration of the + resolver."; + reference + "RFC 1034"; + } + + typedef host { + type union { + type inet:ip-address; + type inet:domain-name; + } + description + "The host type represents either an IP address + or a DNS domain name."; + } + + typedef uri { + type string; // TBD: add the regex from RFC 3986 here? + description + "The uri type represents a Uniform Resource Identifier + (URI) as defined by STD 66. + + Objects using the uri type must be in US-ASCII encoding, + and MUST be normalized as described by RFC 3986 Sections + 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary + percent-encoding is removed, and all case-insensitive + characters are set to lowercase except for hexadecimal + digits, which are normalized to uppercase as described in + Section 6.2.2.1. + + The purpose of this normalization is to help provide + unique URIs. Note that this normalization is not + sufficient to provide uniqueness. Two URIs that are + textually distinct after this normalization may still be + equivalent. + + Objects using the uri type may restrict the schemes that + they permit. For example, 'data:' and 'urn:' schemes + might not be appropriate. + + A zero-length URI is not a valid URI. This can be used to + express 'URI absent' where required."; + reference "RFC 3986 STD 66 and RFC 3305"; + } + + } + --------------030402070409000203000806 Content-Type: text/plain; name="yt-diff-normal.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="yt-diff-normal.log" // Generated by yangdiff 0.1.0 // old: yang-types (2007-10-02) yang-types.yang // new: yang-types (2008-07-16) yang-types.yang M contact M reference D revision '2007-10-02' A revision '2009-05-22' M typedef object-identifier M type M pattern --------------030402070409000203000806 Content-Type: text/plain; name="it-diff-normal.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="it-diff-normal.log" // Generated by yangdiff 0.1.0 // old: inet-types (2007-10-02) inet-types.yang // new: inet-types (2008-06-07) inet-types.yang M contact M reference D revision '2007-10-02' A revision '2008-06-07' D typedef asn M typedef ipv4-address M description M typedef ipv6-address M description A reference 'RFC 4007: IPv6 Scope...' M typedef ipv4-prefix M description M typedef ipv6-prefix M description M typedef domain-name M type M pattern A typedef as-number A typedef uri --------------030402070409000203000806 Content-Type: text/plain; name="yt-diff-revision.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="yt-diff-revision.log" // Generated by yangdiff 0.1.0 // old: yang-types (2007-10-02) yang-types.yang // new: yang-types (2008-07-16) yang-types.yang revision 2008-07-16 { description " - Changed contact - Changed reference - Removed revision '2007-10-02' - Added revision '2009-05-22' - Changed typedef object-identifier - Changed type - Changed pattern "; } --------------030402070409000203000806 Content-Type: text/plain; name="it-diff-revision.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="it-diff-revision.log" // Generated by yangdiff 0.1.0 // old: inet-types (2007-10-02) inet-types.yang // new: inet-types (2008-06-07) inet-types.yang revision 2008-07-16 { description " - Changed contact - Changed reference - Removed revision '2007-10-02' - Added revision '2008-06-07' - Removed typedef asn - Changed typedef ipv4-address - Changed description - Changed typedef ipv6-address - Changed description - Added reference 'RFC 4007: IPv6 Scope...' - Changed typedef ipv4-prefix - Changed description - Changed typedef ipv6-prefix - Changed description - Changed typedef domain-name - Changed type - Changed pattern - Added typedef as-number - Added typedef uri "; } --------------030402070409000203000806 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --------------030402070409000203000806-- From netmod-bounces@ietf.org Thu Jul 17 04:56: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 BF61C3A6A20; Thu, 17 Jul 2008 04:56: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 00D2B3A69DD for ; Thu, 17 Jul 2008 04:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=0.068, 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 P5N2tZUUpsIe for ; Thu, 17 Jul 2008 04:56:04 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 377883A68B6 for ; Thu, 17 Jul 2008 04:56:04 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 33071D800CE for ; Thu, 17 Jul 2008 13:56:35 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Thu, 17 Jul 2008 13:56:35 +0200 Message-Id: <1216295795.16427.15.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] must-stmt and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, YANG draft says that the argument to must-stmt is an XPath expression. However, XPath specification considers all XML element names without a namespace prefix to have no namespace, even if the instance document declares a default namespace for them. Presumably, the reason for making the must-stmt argument an XPath is to be able to take this XPath expression and use it directly in XSLT scripts. However, this is not possible since YANG data model vocabularies have an assigned namespace and so any XPath expression with unprefixed node names won't match anything if used with standard XML software. The straighforward solution would be to require namespace prefix with all node names in the XPath expression. This is awkward but the only alternative I can see for using the XPath expressions for validation is to parse the XPath expression and add the prefixes automatically. 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 Jul 17 09:28: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 81D153A6A74; Thu, 17 Jul 2008 09:28: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 4FAC63A6A74 for ; Thu, 17 Jul 2008 09:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 haG+iQA21-+Y for ; Thu, 17 Jul 2008 09:28:36 -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 7D9A03A6A4D for ; Thu, 17 Jul 2008 09:28:36 -0700 (PDT) Received: (qmail 79951 invoked from network); 17 Jul 2008 16:29:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.173.187 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 17 Jul 2008 16:29:06 -0000 X-YMail-OSG: nMK7MuEVM1nJB1ev229aXQ8bVfOwff9rltb17I4kFxtXvE_7fmkjXgGdZf0QJ58obC4owG80NvKPlwfys5kWTbUZhPMxdW53GAllWJmQU7XrvN6tmaPbrtUlRmYA X-Yahoo-Newman-Property: ymail-3 Message-ID: <487F7350.9060102@netconfcentral.com> Date: Thu, 17 Jul 2008 09:29:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Cc: Benoit Claise Subject: [netmod] typedef asn deleted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I just noticed that the typedef 'asn' was renamed to 'as-number' in the latest inet-types module. This broke the ipfix-psamp module in draft-ietf-ipfix-configuration-model-00.txt, which uses 'asn'. Gee, netmod hasn't even had its first meeting, and already version control rears its ugly head. :-( I guess the ipfix-psamp module needs to be updated ASAP. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 17 10:01:07 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC56D3A6AC5; Thu, 17 Jul 2008 10:01:07 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A373A6B30 for ; Thu, 17 Jul 2008 09:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3DXhAoSnuAE for ; Thu, 17 Jul 2008 09:44:20 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 2E9A83A6A3F for ; Thu, 17 Jul 2008 09:44:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6HGiYi00436; Thu, 17 Jul 2008 18:44:34 +0200 (CEST) Received: from [10.61.65.235] (ams3-vpn-dhcp491.cisco.com [10.61.65.235]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6HGiTA08346; Thu, 17 Jul 2008 18:44:29 +0200 (CEST) Message-ID: <487F76ED.9060301@cisco.com> Date: Thu, 17 Jul 2008 18:44:29 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Andy Bierman References: <487F7350.9060102@netconfcentral.com> In-Reply-To: <487F7350.9060102@netconfcentral.com> X-Mailman-Approved-At: Thu, 17 Jul 2008 10:01:06 -0700 Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] typedef asn deleted X-BeenThere: netmod@ietf.org 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 Thanks Andy for the heads up. Regards, Benoit. > Hi, > > I just noticed that the typedef 'asn' was renamed to 'as-number' > in the latest inet-types module. This broke the ipfix-psamp module in > draft-ietf-ipfix-configuration-model-00.txt, which uses 'asn'. > > Gee, netmod hasn't even had its first meeting, and already > version control rears its ugly head. :-( > > I guess the ipfix-psamp module needs to be updated ASAP. > > > Andy > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 18 02: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 53D0F3A68DF; Fri, 18 Jul 2008 02: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 802D83A68DF for ; Fri, 18 Jul 2008 02:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=0.062, 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 7KAl0sKBpEFL for ; Fri, 18 Jul 2008 02:19:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B5DE53A680E for ; Fri, 18 Jul 2008 02:19:55 -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 99539D800CB; Fri, 18 Jul 2008 11:20:27 +0200 (CEST) From: Ladislav Lhotka To: David Harrington In-Reply-To: <006e01c8e755$22b7dad0$0600a8c0@china.huawei.com> References: <1216045721.6359.36.camel@missotis> <006e01c8e755$22b7dad0$0600a8c0@china.huawei.com> Organization: CESNET Date: Fri, 18 Jul 2008 11:20:27 +0200 Message-Id: <1216372827.7467.29.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: 'NETMOD Working Group' Subject: Re: [netmod] session agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org RGF2aWQgSGFycmluZ3RvbiBww63FoWUgdiBTdCAxNi4gMDcuIDIwMDggdiAxMTowMyAtMDQwMDoK Cj4gSSBkbyBjb25zaWRlciBpdCB1bmZvcnR1bmF0ZSB5b3UgZGlkIG5vdCBwbGFuIHRvIGF0dGVu ZCBJRVRGIHNlc3Npb25zCj4gdGhlIHdob2xlIHdlZWsuIEkgcmVjb21tZW5kIHlvdSBwbGFuIG9u IEZyaWRheSBtb3JuaW5nIHNlc3Npb25zIGJlaW5nCj4gd29ya2luZyBzZXNzaW9ucyBmb3IgbmV0 bW9kIGluIHRoZSBmdXR1cmUuCj4gCk9LLCBJIGFtIGdvaW5nIHRvIHN0YXkgdGlsbCBTYXR1cmRh eSBhbmQgYXR0ZW5kIHRoZSBGcmlkYXkgc2Vzc2lvbi4KClRoYW5rcywgTGFkYQoKLS0gCkxhZGlz bGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1v ZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri Jul 18 04:04: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 7449B3A69FD; Fri, 18 Jul 2008 04:04: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 7424E3A69FD for ; Fri, 18 Jul 2008 04:04:31 -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 TKZnlpVhO7gK for ; Fri, 18 Jul 2008 04:04:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 72C783A68D5 for ; Fri, 18 Jul 2008 04:04:30 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AA05920F1C for ; Fri, 18 Jul 2008 13:04:51 +0200 (CEST) X-AuditID: c1b4fb3c-ab095bb00000193b-f9-488078b7a602 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6C02020FA3 for ; Fri, 18 Jul 2008 13:04:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 13:03:33 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 13:03:32 +0200 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Fri, 18 Jul 2008 13:03:32 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807181303.32504.david.partain@ericsson.com> X-OriginalArrivalTime: 18 Jul 2008 11:03:32.0954 (UTC) FILETIME=[EB09ABA0:01C8E8C5] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Issues for discussion in Dublin X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, If you have technical issues that you think need to be discussed at the upcoming NETMOD meetings, please be prepared to lead a discussion on the topic. Sending your topics to this mailing list in advance of Dublin would be good, too. If you're not going to the IETF but have issues you think must be discussed, please bring those up here so we don't miss them! Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 18 09:59: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 3D49828C1F0; Fri, 18 Jul 2008 09:59: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 59AA228C1F0 for ; Fri, 18 Jul 2008 09:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.026, 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 P1ZMe9mnObDO for ; Fri, 18 Jul 2008 09:59:22 -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 58D1B28C1EF for ; Fri, 18 Jul 2008 09:59:20 -0700 (PDT) Received: (qmail 91272 invoked from network); 18 Jul 2008 16:59:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.173.187 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 18 Jul 2008 16:59:49 -0000 X-YMail-OSG: KU_VflYVM1lwaq4qGtv2fb2ILGDNcq.BlXlCJB6YbF5r53iIZaR.POjd9EELMDnLcOWCBsVcWyVOzmcA8ZuKd7Q0ITGCIGhbmGLOqZ5xUYtW1paXoxxVOn_lpvbWKuc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4880CC03.7030308@netconfcentral.com> Date: Fri, 18 Jul 2008 09:59:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Benoit Claise References: <487F7350.9060102@netconfcentral.com> <487F76ED.9060301@cisco.com> In-Reply-To: <487F76ED.9060301@cisco.com> Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] typedef asn deleted X-BeenThere: netmod@ietf.org 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 Benoit Claise wrote: > Thanks Andy for the heads up. > sure. ipfix-psamp.yang is the best module out there for testing YANG tools! FYI: http://www.netconfcentral.com/modulereport/ipfix-psamp > Regards, Benoit. Andy >> Hi, >> >> I just noticed that the typedef 'asn' was renamed to 'as-number' >> in the latest inet-types module. This broke the ipfix-psamp module in >> draft-ietf-ipfix-configuration-model-00.txt, which uses 'asn'. >> >> Gee, netmod hasn't even had its first meeting, and already >> version control rears its ugly head. :-( >> >> I guess the ipfix-psamp module needs to be updated ASAP. >> >> >> Andy >> >> >> > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 18 10:33: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 6E2833A6B42; Fri, 18 Jul 2008 10:33: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 59F9528C1FA for ; Fri, 18 Jul 2008 10:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.023, 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 HRHZSHDhmLeZ for ; Fri, 18 Jul 2008 10:33:22 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 9A95F3A6B42 for ; Fri, 18 Jul 2008 10:33:22 -0700 (PDT) Received: (qmail 24176 invoked from network); 18 Jul 2008 17:33:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.173.187 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 18 Jul 2008 17:33:54 -0000 X-YMail-OSG: S1F8PjYVM1kc2I66lsM8.LF7V9iZWZp.caRpPvlhvXhMgaDJTbC.rgZxGWSNfZOPZDw0wtwUhAC7AiQJdRa8QEhkXymiczKyNaeQHkN_DQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4880D401.8070405@netconfcentral.com> Date: Fri, 18 Jul 2008 10:33:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, After some implementation experience, I think Phil might be right -- import w/ optional revision date may be the easiest way to deal with an ever-changing set of modules. We need to maintain 'change freedom' within Internet drafts. It must be OK to change 'asn' to 'as-number' in an I-D module. But tools should work no matter where the module is documented. I think the rules for import-by-revision were already posted by Phil, but I will try to remember them here: - if the 'revision ' sub-statement is present in the import clause (along with the prefix), then that version must be found or none will be used - if not present, then the import is for the latest version the 'tool' knows about. If things break, too bad. - every imported symbol used from module 'foo' must be updated in module 'bar', in order to use a newer version of module 'foo'. (The import 'foo' in module bar does not have to change just because module 'bar' is updated.) Conformance is simple: everything is the revision or nothing :-) Actually, conformance for module dependencies falls out for free. I still have concerns about uses expansion (3-diff module interactions can produce the same node/type names with totally different content in the same sibling set). [It's OK if we use the mailing list right? Will every issue get covered in a 2.5 WG meeting?] Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 18 15:16: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 730483A6934; Fri, 18 Jul 2008 15:16: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 9C3913A6934 for ; Fri, 18 Jul 2008 15:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdB0FLUqz7ri for ; Fri, 18 Jul 2008 15:16:20 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id B774B3A68E3 for ; Fri, 18 Jul 2008 15:16:20 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id rXHz1Z00o0cQ2SLA5aGuoi; Fri, 18 Jul 2008 22:16:54 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id raGn1Z00E4HwxpC8WaGock; Fri, 18 Jul 2008 22:16:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=o1wiZrnMYavgFGUJZagA:9 a=3yuWFw4m3-Tfuc1vxFgA:9 a=MRnInz7SbDOBlgZT0ZkA:7 a=P7mLBu6kcJHiVWf4NEVz6H4Mj9sA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Fri, 18 Jul 2008 18:16:52 -0400 Message-ID: <00b101c8e923$fc447090$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjpI/soYyJL6p3SRYKkvkh3Z4GeUQ== Subject: [netmod] review of yang-types-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, as an individual contributor ... I have reviewed yang-types and have some comments. Overall, the document looks good, and I recommend it be adopted as a WG item. 1) The modules start with // XXX namespace to be allocated by IANA. Similar to not self-assigning an OID for a MIB module, should we be publishing with a namespace that is not yet assigned? 2) I think the organization and contact info should be the same as for IETF MIB modules: >From RFC4181: - If the module was developed by an IETF working group, then the ORGANIZATION clause MUST provide the full name of the working group, and the CONTACT-INFO clause MUST include working group mailing list information. The CONTACT-INFO clause SHOULD also provide a pointer to the working group's web page. 3) Similar to IETF MIB modules, should the revision clause include "published as RFC XXX"? 4) I think IETF documents are not supposed to make any claims about being standard. Should the description clause be "This module contains derived YANG types."? 5) typedef uri s/A uri type represents Uniform/A uri type represents a Uniform/ 6) typedef object-identifier mentions the SMIv1/v2 limit of 128 sub-ids. SMIv1/v2 should probably be mentioned in the reference clause. 7) typedef ipv4-prefix s/less than or equal 32/less than or equal to 32/ 8) typedef uri - is it necessary to have a yang:uri (p8) and an inet:uri (p17)? What's the difference? 9) typedef bridgeid - this is the equivalent of BridgeId from RFC4188. Notice the dfference in capitalization. Do we really need to be inconsistent in our naming, including the Id part? In BridgeId, the first two octets contain a priority. In bridgeid, the first four octets do. In BridgeId, there is no colon; in bridgeid, there is. In BridgeId, the last 6 octets contain the MAC address; in bridgeid, the number of octets is not specified. Is bridgeid supposed to follow the definition of BridgeId from RFC4188, as the reference says? If the definition is changed from RFC4188 to meet ieee changes, we should reference the document that provides the new specification. s/identifers/identifiers/ 10) If we are going to define types for vlans, then I recommend mirroring the textual conventions that were developed as a joint effort of the IETF Bridge WG and IEEE 802, and documented in the Q-BRIDGE-MIB (RFC4363). These would include VlanIndex, VlanId, VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone, and possibly PortList: Various Working Groups have defined standards-track MIB documents (for example, [RFC2613] and [RFC3318]), that contain objects and Textual Conventions to represent a Virtual Local Area Network Identifier (VLAN-ID) [802.1Q]. New definitions are showing up in various documents (for example, [RFC4323] and [RFC4149]). Unfortunately, the result is a set of different definitions for the same piece of management information. This may lead to confusion and unnecessary complexity. In order to address this situation, three new textual conventions are defined in the Q-BRIDGE-MIB, called VlanIdOrAny, VlanIdOrNone, and VlanIdOrAnyOrNone. These new textual conventions should be (re)used in MIB modules so that they all represent a VLAN-ID in the same way. These textual conventions provide a means to specify MIB objects that refer to a specific VLAN, to any VLAN, or to no VLAN. For an example of how these textual conventions might be used, consider a MIB object, with SYNTAX of VlanIdOrAnyOrNone, that specifies the VLAN on which to accept incoming packets of a particular protocol. Such an object would allow the device to be configured to accept packets of this protocol received with a specific 802.1q tag value, with any 802.1q tag value, or with no 802.1q tag. Note that a MIB object that is defined using one of these textual conventions should clarify the meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause. 11) References - there are "reference" clauses in the typedefs. Those references should eb included in the References section. Since many of the typedefs are representing a textual convention from other RFCs, these are probably normative references. 12) Should the IANA Considerations section discuss how new values can be added to yang-types, inet-types, and ieee-types namespaces, as per BCP26 (RFC5226)? Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Jul 20 08:09:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE07F3A690B; Sun, 20 Jul 2008 08:09:03 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23F73A67F9 for ; Sun, 20 Jul 2008 08:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPfSFimAjUOF for ; Sun, 20 Jul 2008 08:09:02 -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 365043A690B for ; Sun, 20 Jul 2008 08:09:01 -0700 (PDT) Received: (qmail 36903 invoked from network); 20 Jul 2008 15:09:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.227 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 Jul 2008 15:09:37 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4883552F.2060305@netconfcentral.com> Date: Sun, 20 Jul 2008 08:09:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <1216295795.16427.15.camel@missotis> In-Reply-To: <1216295795.16427.15.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] must-stmt and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > YANG draft says that the argument to must-stmt is an XPath expression. > However, XPath specification considers all XML element names without a > namespace prefix to have no namespace, even if the instance document > declares a default namespace for them. > > Presumably, the reason for making the must-stmt argument an XPath is to > be able to take this XPath expression and use it directly in XSLT > scripts. However, this is not possible since YANG data model > vocabularies have an assigned namespace and so any XPath expression with > unprefixed node names won't match anything if used with standard XML > software. The main reason for using XPath is to provide naming and filtering in the NETCONF protocol. I do not know the XPath spec well enough (yet), but YANG should obviously use it in a compliant way. If you are correct, then treating identifiers without prefixes as "local to the current module and all its submodules", is not compliant. They are not in the local module namespace, but rather the special empty namespace "". > > The straighforward solution would be to require namespace prefix with > all node names in the XPath expression. This is awkward but the only > alternative I can see for using the XPath expressions for validation is > to parse the XPath expression and add the prefixes automatically. A tool that blindly pulls Xpath expressions from YANG modules for XSLT consumption does not seem that likely, so requiring a YANG-aware tool (like pyang) to add in the default prefix as needed seems OK. But I don't mind if prefixes were mandatory in XPath expressions. Then the spec should be clarified that the 'no-prefix == local module' rule applies only to identifier-str. > > Lada > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Jul 20 13:15: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 4F2F83A67DF; Sun, 20 Jul 2008 13:15: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 C89493A67DF for ; Sun, 20 Jul 2008 13:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2D50RdPdN6m for ; Sun, 20 Jul 2008 13:15:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EA1943A67CE for ; Sun, 20 Jul 2008 13:15:10 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 8655D76C229; Sun, 20 Jul 2008 22:15:46 +0200 (CEST) Date: Sun, 20 Jul 2008 22:15:40 +0200 (CEST) Message-Id: <20080720.221540.214743196.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1216295795.16427.15.camel@missotis> References: <1216295795.16427.15.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] must-stmt and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Ladislav Lhotka wrote: > YANG draft says that the argument to must-stmt is an XPath expression. > However, XPath specification considers all XML element names without a > namespace prefix to have no namespace, even if the instance document > declares a default namespace for them. Right. > Presumably, the reason for making the must-stmt argument an XPath is to > be able to take this XPath expression and use it directly in XSLT > scripts. The main reason was rather to reuse a suitable technology instead of inventing a new one, and XPath is already used in NETCONF, so people probably know it already. > However, this is not possible since YANG data model > vocabularies have an assigned namespace and so any XPath expression with > unprefixed node names won't match anything if used with standard XML > software. > > The straighforward solution would be to require namespace prefix with > all node names in the XPath expression. This is awkward ... which is why we tried to avoid it. > but the only > alternative I can see for using the XPath expressions for validation is > to parse the XPath expression and add the prefixes automatically. Is this good enough for the implementations that use std software as-is? (Are there any?) Another alternative is to use XPath 1.1 which supports the concept of a default namespace. But I'd rather see that NETCONF and YANG use the same version of XPath. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 21 02:49: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 6E6B03A6918; Mon, 21 Jul 2008 02:49: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 262273A68DC for ; Mon, 21 Jul 2008 02:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=0.058, 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 t079oDAVoKAU for ; Mon, 21 Jul 2008 02:49:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 104B23A6918 for ; Mon, 21 Jul 2008 02:49:25 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 565AED800BD; Mon, 21 Jul 2008 11:50:00 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20080720.221540.214743196.mbj@tail-f.com> References: <1216295795.16427.15.camel@missotis> <20080720.221540.214743196.mbj@tail-f.com> Organization: CESNET Date: Mon, 21 Jul 2008 11:50:00 +0200 Message-Id: <1216633800.7144.41.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] must-stmt and XPath X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBOZSAyMC4gMDcuIDIwMDggdiAyMjoxNSArMDIwMDoK PiBUaGUgbWFpbiByZWFzb24gd2FzIHJhdGhlciB0byByZXVzZSBhIHN1aXRhYmxlIHRlY2hub2xv Z3kgaW5zdGVhZCBvZgo+IGludmVudGluZyBhIG5ldyBvbmUsIGFuZCBYUGF0aCBpcyBhbHJlYWR5 IHVzZWQgaW4gTkVUQ09ORiwgc28gcGVvcGxlCj4gcHJvYmFibHkga25vdyBpdCBhbHJlYWR5LgoK WWVzLCBidXQgaXQgbWFrZXMgc2Vuc2Ugb25seSBpZiBpdCBmb2xsb3dzIGV4YWN0bHkgdGhlIHNw ZWNpZmljYXRpb24uCiAKPiBJcyB0aGlzIGdvb2QgZW5vdWdoIGZvciB0aGUgaW1wbGVtZW50YXRp b25zIHRoYXQgdXNlIHN0ZCBzb2Z0d2FyZQo+IGFzLWlzPyAgKEFyZSB0aGVyZSBhbnk/KQoKSSB3 cm90ZSBhbiBYU0xUIHN0eWxlc2hlZXQgdGhhdCBleHRyYWN0cyBTY2hlbWF0cm9uIGFzc2VydHMg ZnJvbSB0aGUKcmVzdWx0IG9mIHRoZSBweWFuZyBEU0RMIHBsdWdpbiBhbmQgbWFrZXMgdGhlbSBp bnRvIGEgZnVsbC1ibG93bgpTY2hlbWF0cm9uIHNjaGVtYS4gVGhlbiB0aGUgc2tlbGV0b24gaW1w bGVtZW50YXRpb24gb2YgSVNPIFNjaGVtYXRyb24KY2FuIGJlIHVzZWQgdG8gY3JlYXRlIGEgWFNM VCBzdHlsZXNoZWV0IHRoYXQgY291bGQgaW5kZWVkIHZhbGlkYXRlCmluc3RhbmNlIGRvY3VtZW50 cyAtIGV4Y2VwdCB0aGF0IHRoZSBYUGF0aCBleHByZXNzaW9ucyBjb3BpZWQgZnJvbQptdXN0LXN0 bXQgd29uJ3QgbWF0Y2ggYW55dGhpbmcgYmVjYXVzZSBvZiB0aGUgbWlzc2luZyAoZXhwbGljaXQp Cm5hbWVzcGFjZSBwcmVmaXhlcy4gV2hlbiBJIGFkZGVkIHRoZW0gYnkgaGFuZCwgaXQgd29ya2Vk IG5pY2VseS4KCj4gCj4gQW5vdGhlciBhbHRlcm5hdGl2ZSBpcyB0byB1c2UgWFBhdGggMS4xIHdo aWNoIHN1cHBvcnRzIHRoZSBjb25jZXB0IG9mCj4gYSBkZWZhdWx0IG5hbWVzcGFjZS4gIEJ1dCBJ J2QgcmF0aGVyIHNlZSB0aGF0IE5FVENPTkYgYW5kIFlBTkcgdXNlIHRoZQo+IHNhbWUgdmVyc2lv biBvZiBYUGF0aC4KCk1lIHRvbywgYW5kIGFjdHVhbGx5IG1vc3QgdG9vbHMgY3VycmVudGx5IHN1 cHBvcnQgb25seSBYUGF0aCAxLjAuIEkKdGhpbmsgaXRzIHdvdWxkbid0IGJlIGEgYmlnIHByb2Js ZW0gdG8gcmVxdWlyZSBhIG5hbWVzcGFjZSBwcmVmaXggaW4KbXVzdCBzdGF0ZW1lbnRzIC0gdGhl IG9uZSB0aGF0IGlzIGRlY2xhcmVkIGJ5IHRoZSBZQU5HIG1vZHVsZS4KCkxhZGEKCi0tIApMYWRp c2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRt b2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Mon Jul 21 07:52: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 7CFB93A6831; Mon, 21 Jul 2008 07:52: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 74A383A6816 for ; Mon, 21 Jul 2008 07:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 AuHE-oPESJXH for ; Mon, 21 Jul 2008 07:52:35 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id B8FAF3A6813 for ; Mon, 21 Jul 2008 07:52:35 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id saER1Z00G0S2fkCA1etEgZ; Mon, 21 Jul 2008 14:53:14 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id setC1Z00A4HwxpC8VetD8B; Mon, 21 Jul 2008 14:53:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=XREoylPlxuwSkZ2MrdoA:9 a=FxONxwREL5hl0qaANK0A:9 a=UcOkpBSCHVMM2pXB_P0A:7 a=LLb9WFh3XBnbjX4GrnVR1cgxSKYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=XqebBV1NYWwA:10 a=f7GxY0FH8QIA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> <20080720.215014.171880560.mbj@tail-f.com> Date: Mon, 21 Jul 2008 10:53:12 -0400 Message-ID: <010101c8eb41$80a5a4c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080720.215014.171880560.mbj@tail-f.com> Thread-Index: AcjqodvmI47qjQX1RlyueAXUPibH3gAlSmVA Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Masrtin has asked whether we should just present the same presentation again for new people. Here is my long response, so the WG can understand my viewpoint of what the Thursday meeting should be about. This is the first meeting of the WG. I expect that will draw a number of people who have not been involved in the past. In Philadelphia, the YANG preentation was about YANG versus the CANMOD requirements. That presentation is a sales job for why YANG is needed, and why it is better than the alternatives. In Vancouver, YANG Boot Camp was presented in the OPS Open Area meeting. This showed some examples, focusing a great deal on demonstrating how human-readable YANG is as a modeling language, and sprinkled a description of YANG with sales messages. We are not in the CANMOD BOF anymore. We are not trying to convince the IAB and IESG to approve work on a netconf DML. We do not need to sell people on a "new approach to network management"; we do not need to sell people on why Netconf will revolutionize the world. The new approach to network management has been accepted by the IETF. Netconf has been approved as a proposed standard. We need to stop focusing on selling that solution. We do not need to keep focusing on why YANG is the answer for netconf data modeling. We have convinced the IETF this is a worthwhile effort on which to spend IETF resources - we have a WG. Now we need to start talking about the pieces of the solution in detail. The whole thing starts at YANG, so we need a discussion of how YANG goes about modeling things. This is all old hat to the YANG GANG, but we have a new audience - the IETF general community - to start training about how this stuff actually works. YANG is relatively mature already. But now that the WG has been approved, there are people who will begin to get more involved in the details. People from other areas that have a need for configuration will have been watching while the IETF community leaders decided whether to approve this direction, but not necessarily reading the drafts in depth. Now people from other IETF areas need to develop an understanding of how to use YANG to do modeling. Representatives from companies that have decided the Netconf solution looks promising want to know what they need to implement to also provide support for standardized models. That is where we should focus our Thursday session - on our potential new customers, not on the IAB or IESG. I suggest discussing the main modeling concepts of YANG that module users need to know: how are modules defined? how are namespaces handled? how are standard and proprietary modules differentiated? If you are the editor for a WG model, how do you get a namespace for your module? If you are the editor for a proprietary model, how do you define a neamspace? What naming conventions should be used for standard and proprietary objects? what structure are available to organize information conceptually (containers, lists, leafs) what information gets defined for objects - indices, units, must, presence, defaults, mandatory) what information gets included about relationships between structures? (uses) what information allows reuse of information? (grouping, imports, uses, augment, extensions ...) what information allows defining new operations (rpc, notification, etc. ) Many of the people who will want to use YANG already have some experience with SMIv2. For those things that are similar to SMIv2, you might want to mention the similarity. For those things that are new, such as rpcs and groupings, you might want to mention how this addresses problems that SMIv2 cannot. You also need to talk about XML-in-the-wire. I expect this will be an obvious output, and will not require much discussion in Thirsday's session. You also need to discuss YIN - why it's there, and how modelres can utilize it (maybe for things like design reviews and model validation and relationship checking using existing XML-based tools). All of this stuff is engrained in your thinking, but there are a whole bunch of new people who you need to help understand how to use YANG, YIN, and the XML-on-the-wire. You might want to mention what's available for YANG tools. You might want to quickly mention areas of YANG that still need work, like compliance. The LIB presentation should discuss what's available for standard types. How does a WG or a company define new types if needed? YANG, YIN, XML, and LIB have been available in internet-drafts for a long time already. The active participants in netmod are already in agreement that ese documents are mature enough to use as the starting documents. In Thursday's meeting, we will decide whether to adopt these as WG items, and consensus is alreadt apparent they will be adopted. The Arch presentation needs to put YANG, YIN, XMLL, LIB, and DSDL into context. It needs to discuss the inputs and outputs of YANG, the purpose of each format, and how the pieces are expected to be used, and how they fit together to provide a modeling solution for people that need to do modeling for Netconf. It should not focus on selling the new approach to network management or selling netconf; it should be a design review of how the netmod deliverables provide an environment to help modelers model. The DSDL presentations are different. they need to present the proposals and show that each document (or a proposed merged document) is mature enough to be consideed a WG item to meet the chartered DSDL deliverable. Those are my suggestions for the Thursday presentations. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Sunday, July 20, 2008 3:50 PM > To: ietfdbh@comcast.net; david.partain@ericsson.com > Subject: Re: [netmod] netmod session agendas > > Hi, > > "David Harrington" wrote: > > Can each author-team confirm that they will be able to present an > > overview powerpoint of their proposal during the Thursday session? > > Do we expect new people with no clues about YANG at this session? We > have presented YANG three times during the last two IETF meetings... > I guess I can present these same slides again if necessary, but at the > same time I know how it feels to sit in the audience listening to the > same presentation as last time again... IMO it's usually a waste of > time for the people that actually did read the draft or actually do > remember the last session. This being said, I think the other > overview presentations will be useful - we haven't heard an > architectural presentation or a yang->dsdl presentation. > > > For Friday: > > Martin has proposed driving dicussion of the YANG open issues and > > questions. > > I'm looking forward to this technical session! > > > /martin > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 21 08:06: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 59EBA3A6846; Mon, 21 Jul 2008 08:06: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 B86843A689A for ; Mon, 21 Jul 2008 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=0.054, 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 jN4u+Rz0I8y9 for ; Mon, 21 Jul 2008 08:06:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DD2A53A684A for ; Mon, 21 Jul 2008 08:06:02 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 54A1ED80098 for ; Mon, 21 Jul 2008 17:06:41 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <010101c8eb41$80a5a4c0$0600a8c0@china.huawei.com> References: <007901c8e75d$0d089460$0600a8c0@china.huawei.com> <20080720.215014.171880560.mbj@tail-f.com> <010101c8eb41$80a5a4c0$0600a8c0@china.huawei.com> Organization: CESNET Date: Mon, 21 Jul 2008 17:06:41 +0200 Message-Id: <1216652801.7144.61.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SGkgRGF2ZSwKCkRhdmlkIEhhcnJpbmd0b24gcMOtxaFlIHYgUG8gMjEuIDA3LiAyMDA4IHYgMTA6 NTMgLTA0MDA6Cgo+IFRoZSBEU0RMIHByZXNlbnRhdGlvbnMgYXJlIGRpZmZlcmVudC4gdGhleSBu ZWVkIHRvIHByZXNlbnQgdGhlCj4gcHJvcG9zYWxzIGFuZCBzaG93IHRoYXQgZWFjaCBkb2N1bWVu dCAob3IgYSBwcm9wb3NlZCBtZXJnZWQgZG9jdW1lbnQpCj4gaXMgbWF0dXJlIGVub3VnaCB0byBi ZSBjb25zaWRlZWQgYSBXRyBpdGVtIHRvIG1lZXQgdGhlIGNoYXJ0ZXJlZCBEU0RMCj4gZGVsaXZl cmFibGUuIAo+IAoKSSBjYW4gcHJlcGFyZSAyLTMgb3ZlcnZpZXcgc2xpZGVzIGRlc2NyaWJpbmcg d2hhdCB0aGUgRFNETCBvdXRwdXQgbG9va3MKbGlrZSBhbmQgd2hhdCBpdCBjYW4gYmUgdXNlZCBm b3IuCgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThD MEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1v ZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Jul 21 08:39: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 91D3C3A6813; Mon, 21 Jul 2008 08:39: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 145823A6813 for ; Mon, 21 Jul 2008 08:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrdzJXtWPTtL for ; Mon, 21 Jul 2008 08:39:15 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 22F523A680A for ; Mon, 21 Jul 2008 08:39:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Jul 2008 08:39:25 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, 21 Jul 2008 08:37:39 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 08:37:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 08:37:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6LFbWX33077; Mon, 21 Jul 2008 08:37:37 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6LFYTgv020044; Mon, 21 Jul 2008 15:34:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807211534.m6LFYTgv020044@idle.juniper.net> To: "David Harrington" In-reply-to: <010101c8eb41$80a5a4c0$0600a8c0@china.huawei.com> Date: Mon, 21 Jul 2008 11:34:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Jul 2008 15:37:38.0527 (UTC) FILETIME=[B49A36F0:01C8EB47] Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" writes: >This is all old hat to the YANG GANG, >but we have a new audience - the IETF general community - to start >training about how this stuff actually works. So Thursday is a training session for non-BOFers, meant to give the rest of the IETF a jump start on using YANG for their modeling work. You want less marketing of the ideas/history/motivation behind YANG and more training on how the parts fit together and how they work to deliver useful functionality. Am I reading you right? My concern is that non-BOFers won't understand why we need this and why they care. Yes, the IETF is onboard the YANG Love Fest, but that doesn't mean we'll automatically win over the world at large. I think there are two pieces to winning the world. Deliver a usable solution in a timely manner, and generate excitement about our solution. IMHO we should work on the former and save the latter until we are ready to deliver. Or is your take that we have a sufficiently usable solution that we should get people to start using now? Your questions list is great, and there are a number of such questions without answers. Should we spend the first session working out these answers? My concern is that we'll get the same audience as the last few IETFs, since this is by definition the folks that are interested in this topic (and are on this mailing list) and that we'll spend valuable face-2-face time listening to information we already know (while those not on this mailing list read their email ;^). How about this: we take a show of hands at the start of the session for the number of audience members that have read the YANG spec (the folks that come to the meeting prepared) who didn't attend the OPS-AREA boot camp or BOF (who already know what we're doing). If this group is sufficently small, the WG chairs can decide to skip the training agenda items and move on into open issues and real work. Otherwise the work issues are pushed to Friday's session. We can have these training materials available (and online) and if they aren't needed, no problem. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 21 13:41: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 0A61B3A6978; Mon, 21 Jul 2008 13:41: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 A49CC3A6987 for ; Mon, 21 Jul 2008 13:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 kFAtPA9ltob6 for ; Mon, 21 Jul 2008 13:41:50 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id D93DF3A6848 for ; Mon, 21 Jul 2008 13:41:50 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id shS51Z06C0QkzPwA6kiW6G; Mon, 21 Jul 2008 20:42:30 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id skiU1Z00X4HwxpC8NkiVhg; Mon, 21 Jul 2008 20:42:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=5O6RdQ8LQ5utShfKmgwA:9 a=CjTHHnsWKyN3o3wXy1cA:9 a=yQ35uP-6tlbQtb8MkmkA:7 a=H6dYchj0BvR388iX0rkg7mx7AjwA:4 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Phil Shafer'" References: <010101c8eb41$80a5a4c0$0600a8c0@china.huawei.com> <200807211534.m6LFYTgv020044@idle.juniper.net> Date: Mon, 21 Jul 2008 16:42:28 -0400 Message-ID: <012b01c8eb72$4b3b8490$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <200807211534.m6LFYTgv020044@idle.juniper.net> Thread-Index: AcjrR7Ti3cvmpoTMQLSSp3vPWvrTCQAGZ5aA Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Monday, July 21, 2008 11:34 AM > To: David Harrington > Cc: netmod@ietf.org > Subject: Re: [netmod] netmod session agendas > > "David Harrington" writes: > >This is all old hat to the YANG GANG, > >but we have a new audience - the IETF general community - to start > >training about how this stuff actually works. > > So Thursday is a training session for non-BOFers, meant to give the > rest of the IETF a jump start on using YANG for their modeling work. > You want less marketing of the ideas/history/motivation behind YANG > and more training on how the parts fit together and how they work > to deliver useful functionality. Am I reading you right? yes. > > My concern is that non-BOFers won't understand why we need this and > why they care. Yes, the IETF is onboard the YANG Love Fest, but > that doesn't mean we'll automatically win over the world at large. > > I think there are two pieces to winning the world. Deliver a usable > solution in a timely manner, and generate excitement about our > solution. IMHO we should work on the former and save the latter > until we are ready to deliver. Or is your take that we have a > sufficiently usable solution that we should get people to start > using now? I think we need to work on the first. The "generate excitement" is the purpose of vendors' marketing departments, not the IETF. I think we have a sufficiently usable proposal to start working on developing an IETF proposed standard. Standards are developed by WGs, and I think we need to let the WG get more involved. > > Your questions list is great, and there are a number of such questions > without answers. Should we spend the first session working out > these answers? I think Thursday should review what we already have proposed answers for, and which we do not. I think Friday is the session to try to work out the engineering answers. > > My concern is that we'll get the same audience as the last few > IETFs, since this is by definition the folks that are interested > in this topic (and are on this mailing list) and that we'll spend > valuable face-2-face time listening to information we already know > (while those not on this mailing list read their email ;^). Let me give you a different perspective. Huawei thinks netconf and its new approach to network management loosk like a reasonable solution to device configuration, and have started prototyping. But they have a concern about netconf data modeling. The netconf WG basically said "oh, just invent your own DML". Huawei has followed the discussions in the IETF about XSD vs RelaxNG vs YANG (to the degree those have been public discussions, and not discussions held in ad-hoc meetings or over dinners by the "inner circle" of the netconf world). It has becoe obvious that designing DMLs is not an easy thing to do, and developing one that could be approved as a standard is a highly political process. By approving the netmod WG, the IETF has signalled that "ok, now we are serious about developing a standard modeling language for use with netconf". At this point, Huawei and other companies that are considering supporting netconf know there is a reasonable chance the IETF is going to produce a standard DML for netconf. Now they want a better understanding of the design that is being considered as the starting point. Our charter actually makes the Dublin meeting an important point in deciding whether the proposed documents should be adopted as WG items. This will be the first there **is** a WG to make such decisions. > > How about this: we take a show of hands at the start of the session > for the number of audience members that have read the YANG spec > (the folks that come to the meeting prepared) who didn't attend the > OPS-AREA boot camp or BOF (who already know what we're doing). If > this group is sufficently small, the WG chairs can decide to skip > the training agenda items and move on into open issues and real > work. Otherwise the work issues are pushed to Friday's session. > We can have these training materials available (and online) and if > they aren't needed, no problem. If we were only going to discuss the technical issues, I would have only requested one session. We deliberately requested two sessions because there are two purposes we need to achieve - first we need to make new WG people aware of the work we are doing and what the design of the work is, and to allow the WG (not just the design team) to choose to adopt the starting point documents, and secondly, we need to have our engineers work through some detailed problems in the specs. Making people aware of the architectural designs greatly benefits from f2f powerpoint sessions. There is a significant barrier to entry in this WG because YANG was developed by a closed team, all of whom were implementers of the netconf/YANG solution. Any new members of this WG (and many who have been following the progress) are at a significant disadvantage as compared to the YANG team members. This is an IETF WG; as a chair, it is my job to ensure that we have a fair and open process. And jumping straight into detailed discussions of things like keyrefs and pattern statements and deprecated statements is not fair to the new members attending the first meeting of this WG. I do consider it fair to announce that the second session will be a detailed working session where contributors are expected to have fully read and understood the documents because we will be dealing with issues like keyrefs and patterns, and deprecated status. And I expect that we can require for future sessions that contributors have fully read and understood the documents. But I do not think it is fair to expect that of the first official meeting of the WG. Most of the detailed engineering work can be done effectively on the mailing list; In fact, because some of the key contributors will not be in attendance, the mailing list is probably a better place (and the IETF-required place) to reach consensus on the technical engineering issues. dbh > > Thanks, > Phil > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 21 18:58: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 D86CC3A68CC; Mon, 21 Jul 2008 18:58: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 897533A68CC for ; Mon, 21 Jul 2008 18:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G9q9NGMKTEm for ; Mon, 21 Jul 2008 18:58:06 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id BFFE43A68A6 for ; Mon, 21 Jul 2008 18:58:06 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Jul 2008 18:58:44 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 18:58:31 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 18:58:30 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 18:58:30 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6M1wTu35585; Mon, 21 Jul 2008 18:58:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6M1tVWT025250; Tue, 22 Jul 2008 01:55:31 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807220155.m6M1tVWT025250@idle.juniper.net> To: "David Harrington" In-reply-to: <012b01c8eb72$4b3b8490$0600a8c0@china.huawei.com> Date: Mon, 21 Jul 2008 21:55:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 01:58:30.0232 (UTC) FILETIME=[70594D80:01C8EB9E] Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" writes: >Let me give you a different perspective. Cool. I'm onboard. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 21 19:34: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 A98763A67A4; Mon, 21 Jul 2008 19:34: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 210393A67A4 for ; Mon, 21 Jul 2008 19:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=-0.567, 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 UAsszFm-oc3N for ; Mon, 21 Jul 2008 19:34:31 -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 468F63A65A6 for ; Mon, 21 Jul 2008 19:34:31 -0700 (PDT) Received: (qmail 90861 invoked from network); 22 Jul 2008 02:35:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.227 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 02:35:06 -0000 X-YMail-OSG: KgBF4rgVM1l_z0A0h9ZH7IsWECLCcsoe_tZKGW0FlQLfVxU7owIMVtQhE8Q.WO5_Gq3kYWutR3r2_PwDZoGBOslY9V51wE6b11S4MvYJaQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48854758.9090606@netconfcentral.com> Date: Mon, 21 Jul 2008 19:35:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I brought up these details on the yang mailing list, but they got lost... 1) mandatory-stmt within a container The container-stmt does not allow the mandatory-stmt to be specified within it. The rationale is that the presence-stmt covers the same semantics. Unfortunately, this is incorrect. Section 5.6 clearly says that the presence-stmt simply indicates whether the existence of an empty container node has meaning within the data model or not. The mandatory-stmt indicates whether the container must be present in a valid configuration. This has nothing to do with the semantics of an empty container vs. a non-empty container. 2) config-stmt within a choice It seems perfectly valid to declare a choice node to be config true/false, as other constructs that allow the config-stmt. This is the most direct way of declaring a choice where all the case contents have the same config-stmt value, which is the normal use-case. This is especially important for child node from uses or augment expansion, when the config value is designed to be derived from the parent. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 21 20:20: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 E51D23A690E; Mon, 21 Jul 2008 20:20: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 86BF93A6949 for ; Mon, 21 Jul 2008 20:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DqPkdwkvPtC for ; Mon, 21 Jul 2008 20:20:19 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id B588B3A690E for ; Mon, 21 Jul 2008 20:20:19 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Jul 2008 20:20:30 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, 21 Jul 2008 20:19:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 20:19:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 20:19:44 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6M3Jiu53134; Mon, 21 Jul 2008 20:19:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6M3Gktm026090; Tue, 22 Jul 2008 03:16:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807220316.m6M3Gktm026090@idle.juniper.net> To: Andy Bierman In-reply-to: <48854758.9090606@netconfcentral.com> Date: Mon, 21 Jul 2008 23:16:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 03:19:44.0998 (UTC) FILETIME=[C9EF9060:01C8EBA9] Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >The mandatory-stmt indicates whether the container must be >present in a valid configuration. This has nothing to >do with the semantics of an empty container vs. a >non-empty container. The idea is that a container is either organizational or meaningful. It can be used to organize related nodes in a hierarchy, or its presence can mean something to the config. If it doesn't have a specific meaning, why would you need it to be mandatory? If it does have a specific meaning, why would you want it to be mandatory, since that would mean it would always be on, which means that it's not meaningful? So either way, a mandatory container would not make sense. >It seems perfectly valid to declare a choice node to >be config true/false, as other constructs that allow >the config-stmt. This is the most direct way of >declaring a choice where all the case contents have >the same config-stmt value, which is the normal use-case. > >This is especially important for child node from >uses or augment expansion, when the config value is designed >to be derived from the parent. I understand the second sentence, and can agree that there's no point in making config inside a choice illegal, but I don't get the first sentence and the last sentence has me puzzled, since you only need 'config' to turn it off. Does your grouping want it off? If your choice turning it off? Can you explain the use case? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 00:10:27 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969CD3A6994; Tue, 22 Jul 2008 00:10:27 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352483A6994 for ; Tue, 22 Jul 2008 00:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 yhvDgaakDAY6 for ; Tue, 22 Jul 2008 00:10:25 -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 AAEF13A6977 for ; Tue, 22 Jul 2008 00:10:25 -0700 (PDT) Received: (qmail 54954 invoked from network); 22 Jul 2008 07:11:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 07:11:03 -0000 X-YMail-OSG: L76egWQVM1lhZBQFgsEkCOrjTBECOEoF44xVMGjwomineqyIhXl79EuLYPrOR.AdclC4K8Zyzz445AkyctCiJgs3DpXDBU2GuEAetTFr5A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48858805.3080502@netconfcentral.com> Date: Tue, 22 Jul 2008 00:11:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807220316.m6M3Gktm026090@idle.juniper.net> In-Reply-To: <200807220316.m6M3Gktm026090@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The mandatory-stmt indicates whether the container must be >> present in a valid configuration. This has nothing to >> do with the semantics of an empty container vs. a >> non-empty container. > > The idea is that a container is either organizational or meaningful. > It can be used to organize related nodes in a hierarchy, or its > presence can mean something to the config. If it doesn't have a > specific meaning, why would you need it to be mandatory? If > it does have a specific meaning, why would you want it to be > mandatory, since that would mean it would always be on, which > means that it's not meaningful? So either way, a mandatory > container would not make sense. > Then rewrite the draft so this text is explained. IMO, it is not important to the language structure why a node is mandatory. IMO, P and NP containers do not add much value at all to YANG. I would also add instance-identifier and keyref to that cruft pile. >> It seems perfectly valid to declare a choice node to >> be config true/false, as other constructs that allow >> the config-stmt. This is the most direct way of >> declaring a choice where all the case contents have >> the same config-stmt value, which is the normal use-case. >> >> This is especially important for child node from >> uses or augment expansion, when the config value is designed >> to be derived from the parent. > > I understand the second sentence, and can agree that there's no > point in making config inside a choice illegal, but I don't get the > first sentence and the last sentence has me puzzled, since you only > need 'config' to turn it off. Does your grouping want it off? If > your choice turning it off? Can you explain the use case? > You just need a choice between 2 non-config parameters. Expansion of groupings such as InetAddress type of nodes -- the same IP address field can be read-only or read-write, depending on where it is used. > Thanks, > Phil > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 00:39: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 140FB3A6992; Tue, 22 Jul 2008 00:39: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 DEC1E3A6972 for ; Tue, 22 Jul 2008 00:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeM6PsGtgMHD for ; Tue, 22 Jul 2008 00:39:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2DE963A6848 for ; Tue, 22 Jul 2008 00:39:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66163C000E; Tue, 22 Jul 2008 09:40:09 +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 H9axjgI+WYRf; Tue, 22 Jul 2008 09:40:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD96AC0022; Tue, 22 Jul 2008 09:40:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3454B66FF86; Tue, 22 Jul 2008 09:40:01 +0200 (CEST) Date: Tue, 22 Jul 2008 09:40:01 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080722074001.GA27760@elstar.local> Mail-Followup-To: David Harrington , netmod@ietf.org References: <00b101c8e923$fc447090$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00b101c8e923$fc447090$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-types-01 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, Jul 18, 2008 at 06:16:52PM -0400, David Harrington wrote: > Hi, > > as an individual contributor ... > > I have reviewed yang-types and have some comments. Overall, the > document looks good, and I recommend it be adopted as a WG item. > > 1) The modules start with // XXX namespace to be allocated by IANA. > Similar to not self-assigning an OID for a MIB module, should we be > publishing with a namespace that is not yet assigned? In the SMI world, IANA assigns the next free number, which is easy for IANA to do and difficult to predict. In the YANG world, IANA needs to assign a suitable name and I believe at the end the WG needs to tell IANA what a suitable name will be. The ID spells out these names in the IANA considerations sections. So my response to your comment would be to remove the comments since the IANA considerations take care of the assignment. ;-) RFC 5226 says on page 16: For values that are text strings, a specific name can be suggested. IANA will normally assign the name, unless it conflicts with a name already in use. > 2) I think the organization and contact info should be the same as for > IETF MIB modules: > From RFC4181: > - If the module was developed by an IETF working group, then the > ORGANIZATION clause MUST provide the full name of the working > group, and the CONTACT-INFO clause MUST include working group > mailing list information. The CONTACT-INFO clause SHOULD also > provide a pointer to the working group's web page. will be fixed once this becomes a WG document > 3) Similar to IETF MIB modules, should the revision clause include > "published as RFC XXX"? fixed > 4) I think IETF documents are not supposed to make any claims about > being standard. Should the description clause be "This module contains > derived YANG types."? fixed > 5) typedef uri > s/A uri type represents Uniform/A uri type represents a Uniform/ fixed > 6) typedef object-identifier mentions the SMIv1/v2 limit of 128 > sub-ids. SMIv1/v2 should probably be mentioned in the reference > clause. I suggest to only refer to SMIv2. But this raises a different question. I would prefer to use multiple reference statements if multiple references are needed, but YANG does not allow this today. I will raise this feature request in a separate thread. > 7) typedef ipv4-prefix > s/less than or equal 32/less than or equal to 32/ fixed > 8) typedef uri - is it necessary to have a yang:uri (p8) and an > inet:uri (p17)? What's the difference? oops - I have removed the yang:uri definition in favour of the inet:uri type > 9) typedef bridgeid - this is the equivalent of BridgeId from RFC4188. > Notice the dfference in capitalization. Do we really need to be > inconsistent in our naming, including the Id part? > > In BridgeId, the first two octets contain a priority. In bridgeid, the > first four octets do. The text says the "first four hexadecimal digits" which is two octets and not four. > In BridgeId, there is no colon; in bridgeid, there is. RFC 4188 does not specify a textual representation of BridgeId. I tried to follow what CLIs present but then I might be looking at the wrong CLI. In any case, we need to define the textual representation that makes most sense. RFC 4188 only specifies a binary representation. > In BridgeId, the last 6 octets contain the MAC address; in bridgeid, > the number of octets is not specified. The number of octets is defined in the pattern. > Is bridgeid supposed to follow the definition of BridgeId from > RFC4188, as the reference says? yes > If the definition is changed from RFC4188 to meet ieee changes, we > should reference the document that provides the new specification. I am not aware of any. In general, it would be good is some IEEE experts can review the ieee-types.yang module. > s/identifers/identifiers/ fixed > 10) If we are going to define types for vlans, then I recommend > mirroring the textual conventions that were developed as a joint > effort of the IETF Bridge WG and IEEE 802, and documented in the > Q-BRIDGE-MIB (RFC4363). These would include VlanIndex, VlanId, > VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone, and possibly PortList: > > Various Working Groups have defined standards-track MIB documents > (for example, [RFC2613] and [RFC3318]), that contain objects and > Textual Conventions to represent a Virtual Local Area Network > Identifier (VLAN-ID) [802.1Q]. New definitions are showing up in > various documents (for example, [RFC4323] and [RFC4149]). > Unfortunately, the result is a set of different definitions for the > same piece of management information. This may lead to confusion > and > unnecessary complexity. In order to address this situation, three > new textual conventions are defined in the Q-BRIDGE-MIB, called > VlanIdOrAny, VlanIdOrNone, and VlanIdOrAnyOrNone. These new > textual > conventions should be (re)used in MIB modules so that they all > represent a VLAN-ID in the same way. > > These textual conventions provide a means to specify MIB objects > that > refer to a specific VLAN, to any VLAN, or to no VLAN. For an > example > of how these textual conventions might be used, consider a MIB > object, with SYNTAX of VlanIdOrAnyOrNone, that specifies the VLAN > on > which to accept incoming packets of a particular protocol. Such an > object would allow the device to be configured to accept packets of > this protocol received with a specific 802.1q tag value, with any > 802.1q tag value, or with no 802.1q tag. Note that a MIB object > that > is defined using one of these textual conventions should clarify > the > meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause. I am in favour of adding things but we should represent things in a textual way suitable for XML and CLI usage. Constructs like VlanIdOrAny or VlanIdOrNone are likely not needed in YANG because you can use choices and groupings to deal with these things in a much cleaner way. The PortList uses a compact binary encoding using a bit field. On CLIs, you usually find representations such as '3,5-8,12', that is a list of port numbers and port ranges separated by colons or something like that. Or a port list might simply become a YANG grouping with a leaf-list. > 11) References - there are "reference" clauses in the typedefs. Those > references should eb included in the References section. Since many of > the typedefs are representing a textual convention from other RFCs, > these are probably normative references. will add references > 12) Should the IANA Considerations section discuss how new values can > be added to yang-types, inet-types, and ieee-types namespaces, as per > BCP26 (RFC5226)? We only allocate values - we do not setup a new registry. Which paragraph in section 5.1 of BCP26 do you think requires us to discuss how new values can be added to YANG modules? /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 Jul 22 01:10: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 3AC583A68AC; Tue, 22 Jul 2008 01:10: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 B38343A68A5 for ; Tue, 22 Jul 2008 01:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 yT6gcRK3xyFG for ; Tue, 22 Jul 2008 01:10:56 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id BF08D3A6899 for ; Tue, 22 Jul 2008 01:10:56 -0700 (PDT) Received: (qmail 6339 invoked from network); 22 Jul 2008 08:11:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 08:11:35 -0000 X-YMail-OSG: uy3CQxgVM1k4SGdw8JfHTEHBnFaoz2TxvVTBLfN1d6Kv7oCJ95cnTiPM4X3pnsydjQMkVMAN5DtSez5Rd8JzKRvvIW_30xPsL3v.iu8_IQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48859635.2020403@netconfcentral.com> Date: Tue, 22 Jul 2008 01:11:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807220316.m6M3Gktm026090@idle.juniper.net> In-Reply-To: <200807220316.m6M3Gktm026090@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The mandatory-stmt indicates whether the container must be >> present in a valid configuration. This has nothing to >> do with the semantics of an empty container vs. a >> non-empty container. > > The idea is that a container is either organizational or meaningful. > It can be used to organize related nodes in a hierarchy, or its > presence can mean something to the config. If it doesn't have a > specific meaning, why would you need it to be mandatory? If > it does have a specific meaning, why would you want it to be > mandatory, since that would mean it would always be on, which > means that it's not meaningful? So either way, a mandatory > container would not make sense. > Why doesn't this make sense? container name { mandatory true; leaf first { type string; mandatory true; } leaf middle { type string; mandatory false; } leaf last { type string; mandatory true; } } IMO, it makes sense to say the element must be present. This element is used for encapsulation. It is less important which sub-fields comprise a 'name'. The important thing in the DM is that when 'name' is used in larger constructs, it is mandatory. This makes more sense to me than presence "The presence of this container indicates a person with a name."; Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 03:16: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 747243A68F0; Tue, 22 Jul 2008 03:16: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 56B903A685F for ; Tue, 22 Jul 2008 03:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L1T8WI84g2p for ; Tue, 22 Jul 2008 03:15:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 470A03A68E1 for ; Tue, 22 Jul 2008 03:15:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC4EC2045B for ; Tue, 22 Jul 2008 12:16:36 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-72-4885b384b599 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AF30D20452 for ; Tue, 22 Jul 2008 12:16:36 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 12:16:20 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 12:14:45 +0200 Message-ID: <4885B315.1020506@ericsson.com> Date: Tue, 22 Jul 2008 12:14:45 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org X-OriginalArrivalTime: 22 Jul 2008 10:14:45.0639 (UTC) FILETIME=[C3DFD970:01C8EBE3] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Date Time formats X-BeenThere: netmod@ietf.org 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, Will the yang:date-and-time and the XSD:datetime result in the same XML on the wire? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 03:37: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 720963A691F; Tue, 22 Jul 2008 03:37: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 0A8663A6912 for ; Tue, 22 Jul 2008 03:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=0.051, 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 o2l7eQdzW-w9 for ; Tue, 22 Jul 2008 03:37:25 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 309063A68B6 for ; Tue, 22 Jul 2008 03:37:25 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E2893D80098; Tue, 22 Jul 2008 12:38:04 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <48859635.2020403@netconfcentral.com> References: <200807220316.m6M3Gktm026090@idle.juniper.net> <48859635.2020403@netconfcentral.com> Organization: CESNET Date: Tue, 22 Jul 2008 12:38:04 +0200 Message-Id: <1216723084.6691.33.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QW5keSBCaWVybWFuIHDDrcWhZSB2IMOadCAyMi4gMDcuIDIwMDggdiAwMToxMSAtMDcwMDoKPiBX aHkgZG9lc24ndCB0aGlzIG1ha2Ugc2Vuc2U/Cj4gCj4gICAgY29udGFpbmVyIG5hbWUgewo+ICAg ICAgbWFuZGF0b3J5IHRydWU7Cj4gICAgICBsZWFmIGZpcnN0IHsKPiAgICAgICAgdHlwZSBzdHJp bmc7Cj4gICAgICAgIG1hbmRhdG9yeSB0cnVlOwo+ICAgICAgfQo+ICAgICAgbGVhZiBtaWRkbGUg ewo+ICAgICAgICB0eXBlIHN0cmluZzsKPiAgICAgICAgbWFuZGF0b3J5IGZhbHNlOwo+ICAgICAg fQo+ICAgICAgbGVhZiBsYXN0IHsKPiAgICAgICAgdHlwZSBzdHJpbmc7Cj4gICAgICAgIG1hbmRh dG9yeSB0cnVlOwo+ICAgICAgfQo+ICAgIH0KPiAKPiBJTU8sIGl0IG1ha2VzIHNlbnNlIHRvIHNh eSB0aGUgPG5hbWU+IGVsZW1lbnQgbXVzdCBiZSBwcmVzZW50Lgo+IFRoaXMgZWxlbWVudCBpcyB1 c2VkIGZvciBlbmNhcHN1bGF0aW9uLiAgSXQgaXMgbGVzcyBpbXBvcnRhbnQKPiB3aGljaCBzdWIt ZmllbGRzIGNvbXByaXNlIGEgJ25hbWUnLiAgVGhlIGltcG9ydGFudCB0aGluZwo+IGluIHRoZSBE TSBpcyB0aGF0IHdoZW4gJ25hbWUnIGlzIHVzZWQgaW4gbGFyZ2VyIGNvbnN0cnVjdHMsCj4gaXQg aXMgbWFuZGF0b3J5LgoKQWN0dWFsbHksIHRoZSBhbGdvcml0aG0gdHJhbnNsYXRpbmcgWUFORyB0 byBSRUxBWCBORyBoYXMgdG8gZGVjaWRlIGZvcgplYWNoIGNvbnRhaW5lciB3aGV0aGVyIHRvIHdy YXAgdGhlIGNvcnJlc3BvbmRpbmcgZWxlbWVudCBpbiA8b3B0aW9uYWw+Cm9yIG5vdC4gRnJvbSB0 aGUgWUFORyBkcmFmdCBJIHVuZGVyc3RhbmQgdGhlIG9wdGlvbmFsaXR5IHJ1bGUgZm9yCmNvbnRh aW5lcnMgYXMgZm9sbG93czoKCkEgY29udGFpbmVyIGlzIG9wdGlvbmFsIGlmZgoxLiBpdCBpcyBh IGNvbnRhaW5lciB3aXRoIHByZXNlbmNlLCBvcgoyLiBub25lIG9mIGl0cyBkZXNjZW5kYW50IGxl YWZzIGhhcyAibWFuZGF0b3J5IHRydWU7IiBhbmQgbm9uZSBvZiAKICAgaXRzIGRlc2NlbmRhbnQg bGlzdHMgb3IgbGVhZi1saXN0cyBoYXMgbWluLWVsZW1lbnRzID4gMCwgb3IKMy4gaWYgc3VjaCBh IGxlYWYsIGxpc3Qgb3IgbGVhZi1saXN0IGV4aXN0cywgaXQgaXMgZW5jbG9zZWQgaW4gYW4gICAK ICAgaW50ZXJ2ZW5pbmcgY29udGFpbmVyIHdpdGggcHJlc2VuY2UuCgpTbyBieSB0aGlzIHJ1bGUs IGNvbnRhaW5lciAibmFtZSIgaW4geW91ciBleGFtcGxlIGlzIGltcGxpY2l0bHkKbWFuZGF0b3J5 LiBCdXQgSSBhZ3JlZSB0aGlzIHNob3VsZCBiZSBiZXR0ZXIgZXhwbGFpbmVkIGluIHRoZSBZQU5H CmRyYWZ0LgoKPiAKPiBUaGlzIG1ha2VzIG1vcmUgc2Vuc2UgdG8gbWUgdGhhbgo+IAo+ICAgIHBy ZXNlbmNlICJUaGUgcHJlc2VuY2Ugb2YgdGhpcyBjb250YWluZXIgaW5kaWNhdGVzCj4gICAgICAg ICAgICAgIGEgcGVyc29uIHdpdGggYSBuYW1lLiI7CgpCVFcsIGl0IHdvdWxkIHNlZW0gbW9yZSBs b2dpY2FsLCBhbmQgc3ltbWV0cmljIHRvIG1hbmRhdG9yeS1zdG10LCB0bwpoYXZlCgogICAgcHJl c2VuY2UgdHJ1ZTsKCm9yCgogICAgcHJlc2VuY2UgdHJ1ZSB7CiAgICAgICAgZGVzY3JpcHRpb24g IldoYXQgdGhlIHByZXNlbmNlIG1lYW5zLi4uIjsKICAgIH0KCkxhZGEKCi0tIApMYWRpc2xhdiBM aG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Tue Jul 22 03:55: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 775253A6877; Tue, 22 Jul 2008 03:55: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 79B653A6882 for ; Tue, 22 Jul 2008 03:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_38=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 xQHfZTBg+xey for ; Tue, 22 Jul 2008 03:55:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8A37C3A6867 for ; Tue, 22 Jul 2008 03:55:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12B35C0025; Tue, 22 Jul 2008 12:55:47 +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 xnSwWMcARNGA; Tue, 22 Jul 2008 12:55:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58EACC0029; Tue, 22 Jul 2008 12:55:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CE9EF6708E1; Tue, 22 Jul 2008 12:55:41 +0200 (CEST) Date: Tue, 22 Jul 2008 12:55:41 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080722105541.GA28414@elstar.local> Mail-Followup-To: Balazs Lengyel , netmod@ietf.org References: <4885B315.1020506@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4885B315.1020506@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Date Time formats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Jul 22, 2008 at 12:14:45PM +0200, Balazs Lengyel wrote: > Will the yang:date-and-time and the XSD:datetime result in the same > XML on the wire? In most cases yes. However, dateTime allows negative years and there is a note in [1] that the interpretation of negative years might change in the future. RFC 3339 does not allow negative years and I think this restriction is OK to accept for our purposes. [1] http://www.w3.org/TR/xmlschema-2/#dateTime /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 Jul 22 05:15: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 A36FF3A693C; Tue, 22 Jul 2008 05:15: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 759D83A693C for ; Tue, 22 Jul 2008 05:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXmRt2aGAflx for ; Tue, 22 Jul 2008 05:15:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 603793A68D9 for ; Tue, 22 Jul 2008 05:15:28 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F335A20555; Tue, 22 Jul 2008 14:16:07 +0200 (CEST) X-AuditID: c1b4fb3e-ac995bb000004ec0-37-4885cf87edd1 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D3F3F20277; Tue, 22 Jul 2008 14:16:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 14:16:07 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 14:16:07 +0200 Message-ID: <4885CF86.2080001@ericsson.com> Date: Tue, 22 Jul 2008 14:16:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman 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> X-OriginalArrivalTime: 22 Jul 2008 12:16:07.0294 (UTC) FILETIME=[B81439E0:01C8EBF4] X-Brightmail-Tracker: AAAAAA== 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 Hello, Some mappings/implementations, like our LDAP, will anyway need unique names, in such cases we will have effectively one big naming scope. Balazs 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. > >> >> /martin >> >> > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 06: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 9EE083A69C0; Tue, 22 Jul 2008 06: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 229743A6859 for ; Tue, 22 Jul 2008 06:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-0G1m7VtV-j for ; Tue, 22 Jul 2008 06:30:43 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 0BA3B3A69C0 for ; Tue, 22 Jul 2008 06:30:43 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 20A9A399BDB; Tue, 22 Jul 2008 06:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=lgE5egxLGcIMsKUDHLf8txfwxeo=; b=TTUK byTA1jDRYlsSkG2LYZu8MJS54P8MYGst+NX1dhdnkzApH/uoAPWg9ad0IHmsgwKq 7Tij5qbVs1v8hDqAY1SE75WmyRIskLadfW93XpRkawhEejgy2AMj+Y0kpQOxJ1XJ lwsgDjZdkFMqH0Xst1/zrihe5Rz1qoGv9fEGbME= Received: by wes.hardakers.net (Postfix, from userid 274) id 5715B399BDC; Tue, 22 Jul 2008 06:31:23 -0700 (PDT) From: Wes Hardaker To: Phil Shafer Organization: Sparta References: <200807211534.m6LFYTgv020044@idle.juniper.net> Date: Tue, 22 Jul 2008 06:31:22 -0700 In-Reply-To: <200807211534.m6LFYTgv020044@idle.juniper.net> (Phil Shafer's message of "Mon, 21 Jul 2008 11:34:29 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, 21 Jul 2008 11:34:29 -0400, Phil Shafer said: PS> How about this: we take a show of hands at the start of the session PS> for the number of audience members that have read the YANG spec PS> (the folks that come to the meeting prepared) who didn't attend the PS> OPS-AREA boot camp or BOF (who already know what we're doing). An additional two questions you might consider asking the room: How many *not in the design group or "in crowd"* have read the draft. And then ask, of those and feel they understand the specs well enough to write a YANG module without asking a lot of questions of an expert (or if they could read a moderately complex one written by someone else and understand how it would translate to an XML-encoded netconf message). If the goal of YANG is to define something simpler to use the same number of hands should ideally be up both times. -- Wes Hardaker Sparta, Inc. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 07:00:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2743A6A5F; Tue, 22 Jul 2008 07:00:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5FA3A6897 for ; Tue, 22 Jul 2008 07:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SO4bUE+EUlS for ; Tue, 22 Jul 2008 07:00:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AE2813A6861 for ; Tue, 22 Jul 2008 07:00:01 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8350C20206 for ; Tue, 22 Jul 2008 16:00:41 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-57-4885e809acb3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 666C3201EB for ; Tue, 22 Jul 2008 16:00:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 16:00:40 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 16:00:40 +0200 Message-ID: <4885E808.10607@ericsson.com> Date: Tue, 22 Jul 2008 16:00:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org X-OriginalArrivalTime: 22 Jul 2008 14:00:40.0771 (UTC) FILETIME=[535CD930:01C8EC03] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] yang-types comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I think part of the IANA considerations should go into the main YANG draft. "A registry for standard YANG modules shall be set up. Each entry shall contain the unique module name, the unique XML namespace from the YANG URI Scheme and some reference to the module's documentation." Other thoughts: You used the prefix yang. Is that not needed for anything else? I would consider adding examples for some of the more complicated patterns, or is this stuff too obvious? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 07:16: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 9D5A63A6A43; Tue, 22 Jul 2008 07:16: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 E93DC3A6A41 for ; Tue, 22 Jul 2008 07:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 1XYuv3dmWPkb for ; Tue, 22 Jul 2008 07:15:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 17F243A6987 for ; Tue, 22 Jul 2008 07:15:58 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7774CC0029; Tue, 22 Jul 2008 16:16:38 +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 tb3ftSmvB8s0; Tue, 22 Jul 2008 16:16:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 358CCC000B; Tue, 22 Jul 2008 16:16:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C956B670F16; Tue, 22 Jul 2008 16:16:32 +0200 (CEST) Date: Tue, 22 Jul 2008 16:16:32 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080722141632.GD29065@elstar.local> Mail-Followup-To: Balazs Lengyel , netmod@ietf.org References: <4885E808.10607@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4885E808.10607@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] yang-types comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Jul 22, 2008 at 04:00:40PM +0200, Balazs Lengyel wrote: > I think part of the IANA considerations should go into the main YANG draft. > > "A registry for standard YANG modules shall be set up. Each entry > shall contain the unique module name, the unique XML namespace from > the YANG URI Scheme and some reference to the module's documentation." He? This sounds like a directory which is nice to have (and easy to produce with tools) but not a needed registry since unique names are established with the existing procedures. > Other thoughts: > > You used the prefix yang. Is that not needed for anything else? Until someone tells me for what it is used/reserved, I plan to continue to use it. > I would consider adding examples for some of the more complicated > patterns, or is this stuff too obvious? This is not an examples document. Perhaps your question is whether we should add reusable groupings. I am open to that - the problem is that we have much less experience with that and hence I have not added any groupings so far. If you have concrete suggestions, please post them to the mailing list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 07:19: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 6327728B23E; Tue, 22 Jul 2008 07:19: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 38D5228C0D6 for ; Tue, 22 Jul 2008 07:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZcbPKlBKvn0 for ; Tue, 22 Jul 2008 07:19:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 144D63A69C8 for ; Tue, 22 Jul 2008 07:19:22 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 745DC208A4; Tue, 22 Jul 2008 16:20:01 +0200 (CEST) X-AuditID: c1b4fb3c-ad89abb00000193b-07-4885ec91bd99 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4F3B72045C; Tue, 22 Jul 2008 16:20:01 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 16:19:55 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 16:19:55 +0200 Message-ID: <4885EC8A.2060506@ericsson.com> Date: Tue, 22 Jul 2008 16:19:54 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <200807220316.m6M3Gktm026090@idle.juniper.net> <48859635.2020403@netconfcentral.com> In-Reply-To: <48859635.2020403@netconfcentral.com> X-OriginalArrivalTime: 22 Jul 2008 14:19:55.0064 (UTC) FILETIME=[035FFB80:01C8EC06] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, As I understand it the mandatory statement for "name" is superfluous as it has at least one mandatory child. Balazs PS. I also dislike the whole presence stuff. Andy Bierman wrote: > Phil Shafer wrote: >> Andy Bierman writes: >>> The mandatory-stmt indicates whether the container must be >>> present in a valid configuration. This has nothing to >>> do with the semantics of an empty container vs. a >>> non-empty container. >> >> The idea is that a container is either organizational or meaningful. >> It can be used to organize related nodes in a hierarchy, or its >> presence can mean something to the config. If it doesn't have a >> specific meaning, why would you need it to be mandatory? If >> it does have a specific meaning, why would you want it to be >> mandatory, since that would mean it would always be on, which >> means that it's not meaningful? So either way, a mandatory >> container would not make sense. >> > > Why doesn't this make sense? > > container name { > mandatory true; > leaf first { > type string; > mandatory true; > } > leaf middle { > type string; > mandatory false; > } > leaf last { > type string; > mandatory true; > } > } > > IMO, it makes sense to say the element must be present. > This element is used for encapsulation. It is less important > which sub-fields comprise a 'name'. The important thing > in the DM is that when 'name' is used in larger constructs, > it is mandatory. > > This makes more sense to me than > > presence "The presence of this container indicates > a person with a name."; > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 07:27: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 0E6653A6A58; Tue, 22 Jul 2008 07:27: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 4E7A53A695D for ; Tue, 22 Jul 2008 07:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 2T3EmQA5Xu-C for ; Tue, 22 Jul 2008 07:27:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 79DD728B56A for ; Tue, 22 Jul 2008 07:27:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 48039201EB for ; Tue, 22 Jul 2008 16:27:49 +0200 (CEST) X-AuditID: c1b4fb3e-af19abb000004ec0-1e-4885ee64c20a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 300362129F for ; Tue, 22 Jul 2008 16:27:48 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 16:26:12 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 16:26:12 +0200 Message-ID: <4885EE04.2080508@ericsson.com> Date: Tue, 22 Jul 2008 16:26:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , netmod@ietf.org References: <4885E808.10607@ericsson.com> <20080722141632.GD29065@elstar.local> In-Reply-To: <20080722141632.GD29065@elstar.local> X-OriginalArrivalTime: 22 Jul 2008 14:26:12.0519 (UTC) FILETIME=[E45B0B70:01C8EC06] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] yang-types comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jul 22, 2008 at 04:00:40PM +0200, Balazs Lengyel wrote: > >> I think part of the IANA considerations should go into the main YANG draft. >> >> "A registry for standard YANG modules shall be set up. Each entry >> shall contain the unique module name, the unique XML namespace from >> the YANG URI Scheme and some reference to the module's documentation." > > He? This sounds like a directory which is nice to have (and easy to > produce with tools) but not a needed registry since unique names are > established with the existing procedures. > So you will remove it? It is included today in the draft today. What existing procedures do you refer to? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 07: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 C728E3A6A41; Tue, 22 Jul 2008 07: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 F07823A68F0 for ; Tue, 22 Jul 2008 07:50:11 -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.050, 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 sd8aqXyjVVU8 for ; Tue, 22 Jul 2008 07:50:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 425CC3A6A41 for ; Tue, 22 Jul 2008 07:50:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 167CFC002A; Tue, 22 Jul 2008 16:50:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nmWnv+apPCPp; Tue, 22 Jul 2008 16:50: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 A869AC000B; Tue, 22 Jul 2008 16:50:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 451D1671053; Tue, 22 Jul 2008 16:50:40 +0200 (CEST) Date: Tue, 22 Jul 2008 16:50:40 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080722145040.GA29164@elstar.local> Mail-Followup-To: Balazs Lengyel , netmod@ietf.org References: <4885E808.10607@ericsson.com> <20080722141632.GD29065@elstar.local> <4885EE04.2080508@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4885EE04.2080508@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] yang-types comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Jul 22, 2008 at 04:26:12PM +0200, Balazs Lengyel wrote: > > Juergen Schoenwaelder wrote: >> On Tue, Jul 22, 2008 at 04:00:40PM +0200, Balazs Lengyel wrote: >> >>> I think part of the IANA considerations should go into the main YANG draft. >>> >>> "A registry for standard YANG modules shall be set up. Each entry >>> shall contain the unique module name, the unique XML namespace from >>> the YANG URI Scheme and some reference to the module's documentation." >> >> He? This sounds like a directory which is nice to have (and easy to >> produce with tools) but not a needed registry since unique names are >> established with the existing procedures. > > So you will remove it? It is included today in the draft today. > What existing procedures do you refer to? There is a mechanism to obtain a namespace so we should be fine with that. If we want to have a central registry of module names, then we have to create one. And yes, I believe such a registry should be established by the YANG specification and not in the -types document. /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 Jul 22 08:36: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 10F9D3A6A7D; Tue, 22 Jul 2008 08:36: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 8C61E3A6A65 for ; Tue, 22 Jul 2008 08:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YRohhMXqdCN for ; Tue, 22 Jul 2008 08:36:49 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id AA99D3A6A74 for ; Tue, 22 Jul 2008 08:36:49 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 08:37:26 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 08:36:56 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 08:36:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 08:36:55 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6MFatu81215; Tue, 22 Jul 2008 08:36:55 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6MFXuZx029822; Tue, 22 Jul 2008 15:33:56 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807221533.m6MFXuZx029822@idle.juniper.net> To: Andy Bierman In-reply-to: <48859635.2020403@netconfcentral.com> Date: Tue, 22 Jul 2008 11:33:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 15:36:55.0873 (UTC) FILETIME=[C5977B10:01C8EC10] Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >IMO, it makes sense to say the element must be present. The spec says: Since containers without a "presence" statement are implicitly created and deleted when needed, they are ignored when performing mandatory tests for leafs. A mandatory leaf within such a container is mandatory even if the container's data node does not exist. So you don't need to put mandatory on "name" at all, since this is implicit in having a mandatory child. You don't need (or want) a presence statement on "name", since it has no specific meaning by itself. You need the presence statement when the container has a meaning even if empty (which means it can't have mandatory children). For example, if you have a set of protocols that are simple to turn on but accept additional parameters, you could say: container mpls { presence "Enables MPLS on this interface"; container filter { description "Filter content for MPLS traffic"; leaf input { type keyref { path /firewall/filters/name; } description "Name of the input filter"; } // ditto for output } } So is all that's needed to turn it on, but additional configuration can be placed inside it. The element has no meaning by itself, but arranges the and nodes in a hierarchical organization that keeps them together in context and allows me to avoid calling them and . so-0/0/0 0
10.1.2.3
Should we add this example to the draft? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 09:04: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 A0E5728C162; Tue, 22 Jul 2008 09:04: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 270BB28C168 for ; Tue, 22 Jul 2008 09:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 iZIPydSPQy-d for ; Tue, 22 Jul 2008 09:04:16 -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 1E72628C155 for ; Tue, 22 Jul 2008 09:04:16 -0700 (PDT) Received: (qmail 68383 invoked from network); 22 Jul 2008 16:04:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 16:04:55 -0000 X-YMail-OSG: fifE22wVM1kxv5Zf9FBnTedR6QovG936yV9PJc7K3vYNx55jSKk80mf2Lj8LTq2qzayneo1XpX6hSMxJEHTCbE5OkSzAf5FDJvfVH43Kahr5lwGJ5dsHmXFR8aJC X-Yahoo-Newman-Property: ymail-3 Message-ID: <48860525.3040801@netconfcentral.com> Date: Tue, 22 Jul 2008 09:04:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807221533.m6MFXuZx029822@idle.juniper.net> In-Reply-To: <200807221533.m6MFXuZx029822@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: >> IMO, it makes sense to say the element must be present. > > The spec says: > > Since > containers without a "presence" statement are implicitly created and > deleted when needed, they are ignored when performing mandatory tests > for leafs. A mandatory leaf within such a container is mandatory > even if the container's data node does not exist. > > So you don't need to put mandatory on "name" at all, since this is > implicit in having a mandatory child. You don't need (or want) a > presence statement on "name", since it has no specific meaning by > itself. > An optional container can have mandatory leafs (and other nodes) within it. So what. That just tells me that if the container is present, then it must have these nodes in it. It does not tell me if the subtree is required on an agent or not. With the current approach, you can never add (or expand via uses/augment) a mandatory node to a container because it automatically makes the entire path back to the root mandatory. YANG does not support the concept of a mandatory sub-structure within an optional container: "If is used, then its 'first' and 'last' leafs must be present, otherwise is invalid. But itself is not required to be present." A list can have mandatory sub-nodes and that doesn't mean the list entry itself is mandatory. The min-elements controls that, independent of the sub-nodes. Why should the container behave so much differently? Andy > You need the presence statement when the container has a meaning > even if empty (which means it can't have mandatory children). > For example, if you have a set of protocols that are simple > to turn on but accept additional parameters, you could say: > > container mpls { > presence "Enables MPLS on this interface"; > container filter { > description "Filter content for MPLS traffic"; > leaf input { > type keyref { > path /firewall/filters/name; > } > description "Name of the input filter"; > } > // ditto for output > } > } > > So is all that's needed to turn it on, but additional > configuration can be placed inside it. The element has > no meaning by itself, but arranges the and nodes > in a hierarchical organization that keeps them together in context > and allows me to avoid calling them and . > > > so-0/0/0 > > 0 > > >
> 10.1.2.3 >
> > > > > > > > > Should we add this example to the draft? > > Thanks, > Phil > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 09:05: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 2A3823A6A7D; Tue, 22 Jul 2008 09:05: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 7B0CF3A6A56 for ; Tue, 22 Jul 2008 09:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jPFvgUOQgo8 for ; Tue, 22 Jul 2008 09:05:24 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 8CB103A6A53 for ; Tue, 22 Jul 2008 09:05:24 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 09:03:55 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 09:02:11 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 09:02:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 09:02:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6MG29u89030; Tue, 22 Jul 2008 09:02:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6MFxBpv030033; Tue, 22 Jul 2008 15:59:11 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807221559.m6MFxBpv030033@idle.juniper.net> To: Andy Bierman In-reply-to: <48858805.3080502@netconfcentral.com> Date: Tue, 22 Jul 2008 11:59:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 16:02:10.0194 (UTC) FILETIME=[4C328720:01C8EC14] Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >IMO, P and NP containers >do not add much value at all to YANG. I would >also add instance-identifier and keyref to that cruft pile. But we're looking to solve more problems than those you are currently modeling. We're looking to give sufficient feature richness, flexibility and extensibility that this language can be used in ways where you don't see value. We're trying to incorporate features from vendor DMLs (including mine) that have used features like presence and keyrefs to power CLI and GUI features like completion and drop-down boxes to give the user a better experience in the CLI and GUI, and (more importantly) to remove sources of misconfiguration. By producing richer meta-data, we allow folks to make richer infrastructure that can enforce model rules in a more direct and intuitive way. By putting the user in a richer environment, we help steer them in making proper choices, in helping them understand their choice, and it detecting errors as early as possible. If the keyref tells you the list of possible values, you can present this list to the user (help them make the right choice) and give them an error if their choice doesn't appear in the config (stop them from making a config error). If the config slips thru and is passed to the device, instance-identifier gives the device a way of telling you what you botched (helping you correct the error). These features allow YANG to be useful outside the world of defining IETF standards about how a management application talks to a device, but that's a Good Thing. It means folks can use it to produce better functionality into their generic config browsers, giving them better mechanisms for reducing configuration errors. On the device side, it gives better mechanisms for detecting errors from mgmt apps, and allows the same infrastructure to be used in both API and CLI bindings. This reduces the cost of adhering to standards and gives mgmt apps better access to the device proprietary informaton. It's good news all around. Promotions for everyone! Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 09:20: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 E07643A6A5E; Tue, 22 Jul 2008 09:20: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 89F2B3A6A5E for ; Tue, 22 Jul 2008 09:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.022, 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-K+x+wGAIjB for ; Tue, 22 Jul 2008 09:20:30 -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 BABA93A6A01 for ; Tue, 22 Jul 2008 09:20:30 -0700 (PDT) Received: (qmail 30433 invoked from network); 22 Jul 2008 16:21:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 22 Jul 2008 16:21:06 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <488608F1.80306@netconfcentral.com> Date: Tue, 22 Jul 2008 09:21:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807221559.m6MFxBpv030033@idle.juniper.net> In-Reply-To: <200807221559.m6MFxBpv030033@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: >> IMO, P and NP containers >> do not add much value at all to YANG. I would >> also add instance-identifier and keyref to that cruft pile. > > But we're looking to solve more problems than those you are currently > modeling. We're looking to give sufficient feature richness, > flexibility and extensibility that this language can be used in > ways where you don't see value. We're trying to incorporate features > from vendor DMLs (including mine) that have used features like > presence and keyrefs to power CLI and GUI features like completion > and drop-down boxes to give the user a better experience in the CLI > and GUI, and (more importantly) to remove sources of misconfiguration. > > By producing richer meta-data, we allow folks to make richer > infrastructure that can enforce model rules in a more direct and > intuitive way. By putting the user in a richer environment, we > help steer them in making proper choices, in helping them understand > their choice, and it detecting errors as early as possible. > > If the keyref tells you the list of possible values, you can present this > list to the user (help them make the right choice) and give them an > error if their choice doesn't appear in the config (stop them from > making a config error). If the config slips thru and is passed to > the device, instance-identifier gives the device a way of telling > you what you botched (helping you correct the error). > > These features allow YANG to be useful outside the world of defining > IETF standards about how a management application talks to a device, > but that's a Good Thing. It means folks can use it to produce > better functionality into their generic config browsers, giving > them better mechanisms for reducing configuration errors. On the > device side, it gives better mechanisms for detecting errors from > mgmt apps, and allows the same infrastructure to be used in both > API and CLI bindings. This reduces the cost of adhering to standards > and gives mgmt apps better access to the device proprietary informaton. > > It's good news all around. Promotions for everyone! > I sense from emails by DaveH and Wes that not everybody involved in the WG fully understands YANG yet, and there are concerns about the simplicity/power-feature trade-off. I consider 'deep keys' to be a power-feature that is more valuable than keyref. YANG does not support encapsulation for information hiding purpose very well at all. The value of a container is that the entire subtree can be treated as a handle by applications, and reusable code can process the contents of , which can change over time (e.g., add initials, title and suffix fields). A grouping does not provide this feature, since the node names of all the sub-fields can collide with other siblings of the 'uses name;' statement. But in YANG, that is the only option, if you want to use 'name' as a list key. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 09:30: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 BC3D63A6A7D; Tue, 22 Jul 2008 09:30: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 2949D3A6A7D for ; Tue, 22 Jul 2008 09:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T0bz9ihexcr for ; Tue, 22 Jul 2008 09:30:54 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3E5A63A6881 for ; Tue, 22 Jul 2008 09:30:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1EF3D205D0; Tue, 22 Jul 2008 18:31:34 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-47-48860b6133e3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BA262200BF; Tue, 22 Jul 2008 18:31:29 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:31:29 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:31:29 +0200 Message-ID: <48861010.2020803@ericsson.com> Date: Tue, 22 Jul 2008 18:51:28 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de, NETMOD Working Group References: <4885B315.1020506@ericsson.com> <20080722105541.GA28414@elstar.local> <4885E75E.3040601@ericsson.com> <20080722145157.GB29164@elstar.local> In-Reply-To: <20080722145157.GB29164@elstar.local> X-OriginalArrivalTime: 22 Jul 2008 16:31:29.0140 (UTC) FILETIME=[649C6340:01C8EC18] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Date Time formats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I forgot. Sorry. Balazs Juergen Schoenwaelder wrote: > On Tue, Jul 22, 2008 at 03:57:50PM +0200, Balazs Lengyel wrote: >> Hello Jurgen, >> I think this could be mentioned in the draft. >> Balazs >> >> Juergen Schoenwaelder wrote: >>> On Tue, Jul 22, 2008 at 12:14:45PM +0200, Balazs Lengyel wrote: >>> >>>> Will the yang:date-and-time and the XSD:datetime result in the same >>>> XML on the wire? >>> In most cases yes. >>> >>> However, dateTime allows negative years and there is a note in [1] >>> that the interpretation of negative years might change in the >>> future. RFC 3339 does not allow negative years and I think this >>> restriction is OK to accept for our purposes. >>> >>> [1] http://www.w3.org/TR/xmlschema-2/#dateTime >>> >>> /js > > Any reason not to CC the WG? > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 10:40: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 59DB73A6A14; Tue, 22 Jul 2008 10:40: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 CAC013A6A10 for ; Tue, 22 Jul 2008 10:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcVWwTyc1Lwb for ; Tue, 22 Jul 2008 10:40:51 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id D4D803A69C8 for ; Tue, 22 Jul 2008 10:40:50 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 10:41:06 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:07 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:06 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:37:25 -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 m6MHbPu19147; Tue, 22 Jul 2008 10:37:25 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6MHYQmp030858; Tue, 22 Jul 2008 17:34:26 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807221734.m6MHYQmp030858@idle.juniper.net> To: Andy Bierman In-reply-to: <48860525.3040801@netconfcentral.com> Date: Tue, 22 Jul 2008 13:34:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 17:37:25.0532 (UTC) FILETIME=[9ACDE5C0:01C8EC21] Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: >An optional container can have mandatory leafs (and other nodes) >within it. So what. That just tells me that if the container is >present, then it must have these nodes in it. It does not tell >me if the subtree is required on an agent or not. That's not how the spec reads. If has mandatory leafs, that tells you is required. >With the current approach, you can never add (or expand via >uses/augment) a mandatory node to a container because it automatically >makes the entire path back to the root mandatory. Adding mandatory items will break the contract of the initial module, since old module users won't know this added leaf is mandatory. >A list can have mandatory sub-nodes and that doesn't mean the >list entry itself is mandatory. The min-elements controls >that, independent of the sub-nodes. Why should the container behave >so much differently? Because the non-presence container has no meaning. It's purely organizational, and can be discarded when empty. An empty non-presence container is meaningless. In the previous example, the container contains the set of protocol families configured on an interface. If there are no protocol families, the empty element carries no meaning in the configuration. This varies greatly from lists, where the creation of a list element means something. The list instance carries a meaning. The non-presence container doesn't. They are created and deleted as needed, and so they don't carry the concept of "mandatory", since their need to exist is dependent on their children. We should definitely expand on this in the spec. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 11:23: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 DCAB328C0D0; Tue, 22 Jul 2008 11:23: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 B2B6228C0D0 for ; Tue, 22 Jul 2008 11:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 2lYQuiAlplca for ; Tue, 22 Jul 2008 11:23:16 -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 A70263A6A53 for ; Tue, 22 Jul 2008 11:23:16 -0700 (PDT) Received: (qmail 59899 invoked from network); 22 Jul 2008 18:23:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 18:23:56 -0000 X-YMail-OSG: UbmumNcVM1n6yB.OYc9vne2pHFZlWFEzJNzABa00y0.nNWbp.E2VgRv9epA7nsRY8f_Pizf5Nj7iifzj3cMHS5a3MylZLsObBBbjYS1GwA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488625BA.6070302@netconfcentral.com> Date: Tue, 22 Jul 2008 11:23:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807221734.m6MHYQmp030858@idle.juniper.net> In-Reply-To: <200807221734.m6MHYQmp030858@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: >> An optional container can have mandatory leafs (and other nodes) >> within it. So what. That just tells me that if the container is >> present, then it must have these nodes in it. It does not tell >> me if the subtree is required on an agent or not. > > That's not how the spec reads. If has mandatory leafs, > that tells you is required. > Given the usage of augments and groupings and complex nesting, it might be non-trivial for the DM reader to determine this fact. I do not like the asymmetry: If I have a grouping with mandatory fields in it: grouping name { leaf first { mandatory true; type string; } leaf middle { mandatory false; type string; } leaf last { mandatory true; type string; } } If I use this grouping in a list, it does not make the list mandatory, but if I use it in a container, it does. list X { key "last first"; uses name; leaf extra-stuff {...} } container Y { uses name; leaf extra-stuff {...} } If container Y was reusable (i.e., in a grouping) then it would be ripple upwards for containers but not for lists and choices. /Y is mandatory, but /X/Y is not. This is confusing. IMO, it is easier and more intuitive for the readers and writer to be able to control the optional/mandatory bit at each node. This is possible for list and choice, but not container. >> With the current approach, you can never add (or expand via >> uses/augment) a mandatory node to a container because it automatically >> makes the entire path back to the root mandatory. > > Adding mandatory items will break the contract of the initial > module, since old module users won't know this added leaf > is mandatory. > >> A list can have mandatory sub-nodes and that doesn't mean the >> list entry itself is mandatory. The min-elements controls >> that, independent of the sub-nodes. Why should the container behave >> so much differently? > > Because the non-presence container has no meaning. It's purely > organizational, and can be discarded when empty. An empty non-presence > container is meaningless. In the previous example, the > container contains the set of protocol families configured on an > interface. If there are no protocol families, the empty > element carries no meaning in the configuration. > > This varies greatly from lists, where the creation of a list element > means something. The list instance carries a meaning. The > non-presence container doesn't. They are created and deleted as > needed, and so they don't carry the concept of "mandatory", since > their need to exist is dependent on their children. > > We should definitely expand on this in the spec. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 12:25:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FE628C10E; Tue, 22 Jul 2008 12:25:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F9C3A6A86 for ; Tue, 22 Jul 2008 12:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utMGV+j-9f1F for ; Tue, 22 Jul 2008 12:25:57 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 62EC03A6A7D for ; Tue, 22 Jul 2008 12:25:57 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id DE72A76C229; Tue, 22 Jul 2008 21:26:36 +0200 (CEST) Date: Tue, 22 Jul 2008 21:26:35 +0200 (CEST) Message-Id: <20080722.212635.159958930.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48860525.3040801@netconfcentral.com> References: <200807221533.m6MFXuZx029822@idle.juniper.net> <48860525.3040801@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > YANG does not > support the concept of a mandatory sub-structure within an > optional container: "If is used, then its 'first' and 'last' > leafs must be present, otherwise is invalid. But > itself is not required to be present." This is supported by making 'name' a presence container with 'first' and 'last' mandatory leafs. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 12:46: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 9B15C3A6827; Tue, 22 Jul 2008 12:46: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 BADD23A6827 for ; Tue, 22 Jul 2008 12:46:11 -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.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBL1PSokNwkF for ; Tue, 22 Jul 2008 12:46:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A9DC03A67D4 for ; Tue, 22 Jul 2008 12:46:10 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 94CDB76C229; Tue, 22 Jul 2008 21:46:51 +0200 (CEST) Date: Tue, 22 Jul 2008 21:46:45 +0200 (CEST) Message-Id: <20080722.214645.135959629.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <488625BA.6070302@netconfcentral.com> References: <200807221734.m6MHYQmp030858@idle.juniper.net> <488625BA.6070302@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > I do not like the asymmetry: > > If I have a grouping with mandatory fields in it: > > grouping name { > leaf first { > mandatory true; > type string; > } > leaf middle { > mandatory false; > type string; > } > leaf last { > mandatory true; > type string; > } > } > > > If I use this grouping in a list, it does not make > the list mandatory, but if I use it in a container, it does. There are no such thing as "a mandatory list" and "a mandatory container". Presumably you mean that if you use the grouping above in a non-presence container, this container will always be present in the data store, but if you use it in a list, that doesn't magically create a list entry. > list X { > key "last first"; > uses name; > leaf extra-stuff {...} > } > > container Y { > uses name; > leaf extra-stuff {...} > } > > If container Y was reusable (i.e., in a grouping) > then it would be ripple upwards for containers > but not for lists and choices. /Y is mandatory, > but /X/Y is not. This is confusing. Here's a simpler case: leaf a { mandatory true; ... } list interface { key name; leaf name { ... } leaf b { mandatory true; ... } } Since 'a' is mandatory, /a must always exist. 'b' is also mandatory, but you don't expect /interface/b to always exist, do you? In the spec, it is explained like this: If "mandatory" is "true", the node must exist in a valid configuration if its parent node exists. [...] > IMO, it is easier and more intuitive for the readers > and writer to be able to control the optional/mandatory bit > at each node. Suppose I could make a container mandatory. When would a writer want to make a container mandatory? A container does not have a value, so it does not carry any information. It can only provide some information by its existance. But if it is mandatory, it always exists. So when I see a container with mandatory true, I know that it means that the container is purely structural. But even though it's purely structural, a manager has to create it even if it only has optional children. That would be pretty confusing IMO. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 12:48: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 644A73A68F0; Tue, 22 Jul 2008 12:48: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 7C72E3A68F0 for ; Tue, 22 Jul 2008 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cN5edK9Uo7J8 for ; Tue, 22 Jul 2008 12:48:00 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 939DC3A6827 for ; Tue, 22 Jul 2008 12:48:00 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MJmdh17432 for ; Tue, 22 Jul 2008 19:48:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 15:48:34 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41594554F@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why constrain keyref? Thread-Index: AcjsM+zfUSQeu8u7TiePdYS0x1NMMg== From: "Sharon Chisholm" To: Subject: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi The yang specification (section 8.8) says "If the leaf with the keyref type represents configuration, the list entry it refers to MUST also represent configuration. Such a leaf puts a constraint on a valid configuration. In a valid configuration, all keyref nodes MUST reference existing list entries." Why can't I have a relationship with something that isn't configuration? For example, it might make sense to model physical hardware as non-configuration if it can't be modified. Does this mean I can't associate a logical interface with a physical port? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 12:48:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01483A6900; Tue, 22 Jul 2008 12:48:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E1A3A68F0 for ; Tue, 22 Jul 2008 12:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 SvdmhzQEo1UE for ; Tue, 22 Jul 2008 12:48: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 E9EB63A67D4 for ; Tue, 22 Jul 2008 12:48:11 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BDBAC0020; Tue, 22 Jul 2008 21:48:53 +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 7+1crweCXfhP; Tue, 22 Jul 2008 21:48:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E90EAC0022; Tue, 22 Jul 2008 21:48:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 821086714AA; Tue, 22 Jul 2008 21:48:47 +0200 (CEST) Date: Tue, 22 Jul 2008 21:48:47 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080722194847.GA29877@elstar.local> Mail-Followup-To: Balazs Lengyel , NETMOD Working Group References: <4885B315.1020506@ericsson.com> <20080722105541.GA28414@elstar.local> <4885E75E.3040601@ericsson.com> <20080722145157.GB29164@elstar.local> <48861010.2020803@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48861010.2020803@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] Date Time formats X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Jul 22, 2008 at 03:57:50PM +0200, Balazs Lengyel wrote: > Hello Jurgen, > I think this could be mentioned in the draft. This makes sense. I will add the following statement: The date-and-time type is compatible with the dateTime XML schema type except that dateTime allows negative years which are not allowed by RFC 3339. /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 Jul 22 12:49: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 92E013A6900; Tue, 22 Jul 2008 12:49: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 73C2C3A6900 for ; Tue, 22 Jul 2008 12:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcQI7j1jjWbb for ; Tue, 22 Jul 2008 12:49:11 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 786DF3A68F0 for ; Tue, 22 Jul 2008 12:49:11 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MJnoh17579 for ; Tue, 22 Jul 2008 19:49:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 15:49:47 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41594555A@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why constrain keyref? Thread-Index: AcjsM+zfUSQeu8u7TiePdYS0x1NMMgAAA+NQ From: "Sharon Chisholm" To: Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Sorry, I just found Andy made the same comment. My email search tool is so slow I didn't think it found anything. Sharon -----Original Message----- From: Chisholm, Sharon (CAR:ZZ00) Sent: Tuesday, July 22, 2008 3:49 PM To: netmod@ietf.org Subject: Why constrain keyref? Hi The yang specification (section 8.8) says "If the leaf with the keyref type represents configuration, the list entry it refers to MUST also represent configuration. Such a leaf puts a constraint on a valid configuration. In a valid configuration, all keyref nodes MUST reference existing list entries." Why can't I have a relationship with something that isn't configuration? For example, it might make sense to model physical hardware as non-configuration if it can't be modified. Does this mean I can't associate a logical interface with a physical port? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 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 1783D3A69C8; Tue, 22 Jul 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 B181B3A69C8 for ; Tue, 22 Jul 2008 13:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeeX9eorv946 for ; Tue, 22 Jul 2008 13:05:34 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9FEBB3A6994 for ; Tue, 22 Jul 2008 13:05:34 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MK6Ch19979 for ; Tue, 22 Jul 2008 20:06:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 16:05:47 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41594555A@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Why constrain keyref? Thread-Index: AcjsM+zfUSQeu8u7TiePdYS0x1NMMgAAA+NQAABpkIA= References: <713043CE8B8E1348AF3C546DBE02C1B41594555A@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Having done the politically correct thing and read the original thread, it isn't clear to me what the agreed solution was. I think the only restriction we should place on the keyref is that whatever I point to must exist. The fact that it never changes or may change is not relevant. In fact, if I point at something that gets deleted or removed and this causes an error to be reported then this is a good thing in my books compared to failing silently If that is too hard, then only do referential integrity checking 1) On creation 2) When explicitly asked to by some validate command. Restricting me to just point at configuration is only solving part of the problem and probably creating a CLR. Sharon -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Tuesday, July 22, 2008 3:50 PM To: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? Sorry, I just found Andy made the same comment. My email search tool is so slow I didn't think it found anything. Sharon -----Original Message----- From: Chisholm, Sharon (CAR:ZZ00) Sent: Tuesday, July 22, 2008 3:49 PM To: netmod@ietf.org Subject: Why constrain keyref? Hi The yang specification (section 8.8) says "If the leaf with the keyref type represents configuration, the list entry it refers to MUST also represent configuration. Such a leaf puts a constraint on a valid configuration. In a valid configuration, all keyref nodes MUST reference existing list entries." Why can't I have a relationship with something that isn't configuration? For example, it might make sense to model physical hardware as non-configuration if it can't be modified. Does this mean I can't associate a logical interface with a physical port? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 13: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 724563A69A4; Tue, 22 Jul 2008 13: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 2F74E3A6A14 for ; Tue, 22 Jul 2008 13:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYNGk6xMbWN1 for ; Tue, 22 Jul 2008 13:26:07 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 600623A6982 for ; Tue, 22 Jul 2008 13:26:07 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id C8E3E76C229; Tue, 22 Jul 2008 22:26:47 +0200 (CEST) Date: Tue, 22 Jul 2008 22:26:43 +0200 (CEST) Message-Id: <20080722.222643.05065635.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B41594555A@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.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] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, "Sharon Chisholm" wrote: > Hi > > Having done the politically correct thing and read the original thread, > it isn't clear to me what the agreed solution was. I think the only > restriction we should place on the keyref is that whatever I point to > must exist. The fact that it never changes or may change is not > relevant. In fact, if I point at something that gets deleted or removed > and this causes an error to be reported then this is a good thing in my > books compared to failing silently The problem is what happens if you have a config keyref which points to some state object, and the state object is removed by the device. Now your running config is invalid. To answer your original question: > Does this mean I can't > associate a logical interface with a physical port? The answer currently is that you cannot do this association with a keyref. You would have to use the same type and describe the relationship in the description clause. > If that is too hard, then only do referential integrity checking > 1) On creation > 2) When explicitly asked to by some validate command. I don't think that would work. If e.g. the running config sometimes can be invalid but the system still works, what does the validity check give you? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 13:33:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A83A3A69A4; Tue, 22 Jul 2008 13:33:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C076C3A69A4 for ; Tue, 22 Jul 2008 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.627, 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 dOfkOEuSRmyO for ; Tue, 22 Jul 2008 13:33:31 -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 03AD53A6955 for ; Tue, 22 Jul 2008 13:33:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=obOcyeIpsp4xElhGAKOg/BLCpgYjBFxE6qt9vJNadb886K4IJsVMs9a7sIe+o4i7; 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.91.161] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KLOYi-0006Zt-2m for netmod@ietf.org; Tue, 22 Jul 2008 16:34:08 -0400 Message-ID: <000f01c8ec3a$53fb5e20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B41594555A@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> <20080722.222643.05065635.mbj@tail-f.com> Date: Tue, 22 Jul 2008 13:34: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b314cd8c107c05468f6dea83827b9af577350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.91.161 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, July 22, 2008 1:26 PM > Subject: Re: [netmod] Why constrain keyref? ... > I don't think that would work. If e.g. the running config sometimes > can be invalid but the system still works, what does the validity > check give you? Is it time for a reincarnation of draft-presuhn-referent-00.txt? The bottom line is that the most robust design is one in which the semantics of unsatisfied references are spelled out as part of the model. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 13:40: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 C3B703A67E1; Tue, 22 Jul 2008 13:40: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 F20983A67E1 for ; Tue, 22 Jul 2008 13:40:19 -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.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO99D4hNIjoP for ; Tue, 22 Jul 2008 13:40:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 36F9C3A676A for ; Tue, 22 Jul 2008 13:40:19 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id CC20376C229; Tue, 22 Jul 2008 22:40:59 +0200 (CEST) Date: Tue, 22 Jul 2008 22:40:54 +0200 (CEST) Message-Id: <20080722.224054.65339245.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000f01c8ec3a$53fb5e20$6801a8c0@oemcomputer> References: <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> <20080722.222643.05065635.mbj@tail-f.com> <000f01c8ec3a$53fb5e20$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] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > The bottom line is that the most robust design is one in which > the semantics of unsatisfied references are spelled out as > part of the model. Can you provide a use-case for something else than failing validation (which is what we do today)? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 13:49: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 28AE23A691F; Tue, 22 Jul 2008 13:49: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 A0DEB3A691F for ; Tue, 22 Jul 2008 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKZEuGyAzW8M for ; Tue, 22 Jul 2008 13:49:09 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 630CE3A69BA for ; Tue, 22 Jul 2008 13:49:09 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MKnlh25214; Tue, 22 Jul 2008 20:49:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 16:48:46 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4159456D5@zcarhxm2.corp.nortel.com> In-Reply-To: <20080722.222643.05065635.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Why constrain keyref? Thread-Index: AcjsOUXmhlu/7XbcRdSmz1kOpy0NbQAAOCTQ References: <713043CE8B8E1348AF3C546DBE02C1B41594555A@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> <20080722.222643.05065635.mbj@tail-f.com> From: "Sharon Chisholm" To: "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Resource relationships are a critical part of the data model and I think we need to step back and understand the problem a bit better. The solution we seem to have on the table falls short of solving this problem. The DSDL work describes three phases of validation that I think might be useful here. We could easily define a new verb that does referential integrity checking if people don't think the existing validate should do this. They key is that this information is in a machine readable format. Note that I have off-box tools very interested in being able to get this sort of information in the Schema definition so they can perform their own pre-validation before sending the configuration down to the box. I started to classify the type of information that a keyref would point to so we could look at each in turn, including the one you listed where I point at dynamic-static information. But I don't think this is any different then configured information. Does it really matter if the operator removed the thing I was point at or the system? Sharon -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, July 22, 2008 4:27 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? Hi, "Sharon Chisholm" wrote: > Hi > > Having done the politically correct thing and read the original > thread, it isn't clear to me what the agreed solution was. I think the > only restriction we should place on the keyref is that whatever I > point to must exist. The fact that it never changes or may change is > not relevant. In fact, if I point at something that gets deleted or > removed and this causes an error to be reported then this is a good > thing in my books compared to failing silently The problem is what happens if you have a config keyref which points to some state object, and the state object is removed by the device. Now your running config is invalid. To answer your original question: > Does this mean I can't > associate a logical interface with a physical port? The answer currently is that you cannot do this association with a keyref. You would have to use the same type and describe the relationship in the description clause. > If that is too hard, then only do referential integrity checking > 1) On creation > 2) When explicitly asked to by some validate command. I don't think that would work. If e.g. the running config sometimes can be invalid but the system still works, what does the validity check give you? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 13:50: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 9A9413A691F; Tue, 22 Jul 2008 13:50: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 3BC263A691F for ; Tue, 22 Jul 2008 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPzpNjpTDyzf for ; Tue, 22 Jul 2008 13:50:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0EF963A6881 for ; Tue, 22 Jul 2008 13:50:48 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6D8B1201A9; Tue, 22 Jul 2008 22:51:25 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-7d-4886484dcf69 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 444AC20006; Tue, 22 Jul 2008 22:51:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:51:25 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:51:24 +0200 Message-ID: <4886484C.9070606@ericsson.com> Date: Tue, 22 Jul 2008 22:51:24 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200807221734.m6MHYQmp030858@idle.juniper.net> <488625BA.6070302@netconfcentral.com> <20080722.214645.135959629.mbj@tail-f.com> In-Reply-To: <20080722.214645.135959629.mbj@tail-f.com> X-OriginalArrivalTime: 22 Jul 2008 20:51:24.0710 (UTC) FILETIME=[B44B8460:01C8EC3C] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I agree with Andy. Creating an extra (mandatory) container is just a few bits or one XML line. That is far less work then understanding the concept of presence containers. I like explicit statement: if I put mandatory there it is mandatory - simple. Implied presence is a more complicated. Balazs Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> I do not like the asymmetry: >> >> If I have a grouping with mandatory fields in it: >> >> grouping name { >> leaf first { >> mandatory true; >> type string; >> } >> leaf middle { >> mandatory false; >> type string; >> } >> leaf last { >> mandatory true; >> type string; >> } >> } >> >> >> If I use this grouping in a list, it does not make >> the list mandatory, but if I use it in a container, it does. > > There are no such thing as "a mandatory list" and "a mandatory > container". Presumably you mean that if you use the grouping above in > a non-presence container, this container will always be present in the > data store, but if you use it in a list, that doesn't magically create > a list entry. > >> list X { >> key "last first"; >> uses name; >> leaf extra-stuff {...} >> } >> >> container Y { >> uses name; >> leaf extra-stuff {...} >> } >> >> If container Y was reusable (i.e., in a grouping) >> then it would be ripple upwards for containers >> but not for lists and choices. /Y is mandatory, >> but /X/Y is not. This is confusing. > > Here's a simpler case: > > leaf a { > mandatory true; > ... > } > > list interface { > key name; > leaf name { ... } > > leaf b { > mandatory true; > ... > } > } > > Since 'a' is mandatory, /a must always exist. 'b' is also mandatory, > but you don't expect /interface/b to always exist, do you? > > In the spec, it is explained like this: > > If "mandatory" is "true", the node must exist in a valid > configuration if its parent node exists. [...] > > >> IMO, it is easier and more intuitive for the readers >> and writer to be able to control the optional/mandatory bit >> at each node. > > Suppose I could make a container mandatory. When would a writer want > to make a container mandatory? A container does not have a value, so > it does not carry any information. It can only provide some > information by its existance. But if it is mandatory, it always > exists. So when I see a container with mandatory true, I know that it > means that the container is purely structural. But even though it's > purely structural, a manager has to create it even if it only has > optional children. That would be pretty confusing IMO. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 13:53: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 225903A6A09; Tue, 22 Jul 2008 13:53: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 19EF03A6881 for ; Tue, 22 Jul 2008 13:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP2ihsnYOHtL for ; Tue, 22 Jul 2008 13:52:58 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3F5FF3A67D4 for ; Tue, 22 Jul 2008 13:52:58 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C5EEA2036E; Tue, 22 Jul 2008 22:53:38 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-bb-488648d295c0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A79FD20104; Tue, 22 Jul 2008 22:53:38 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:53:35 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:53:34 +0200 Message-ID: <488648CE.9080604@ericsson.com> Date: Tue, 22 Jul 2008 22:53:34 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200807221533.m6MFXuZx029822@idle.juniper.net> <48860525.3040801@netconfcentral.com> <20080722.212635.159958930.mbj@tail-f.com> In-Reply-To: <20080722.212635.159958930.mbj@tail-f.com> X-OriginalArrivalTime: 22 Jul 2008 20:53:34.0943 (UTC) FILETIME=[01EB7EF0:01C8EC3D] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, What if 'name' does not have a real meaning, in which case we misuse the presence statement to indicate this construct of mandatory and optional nodes. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> YANG does not >> support the concept of a mandatory sub-structure within an >> optional container: "If is used, then its 'first' and 'last' >> leafs must be present, otherwise is invalid. But >> itself is not required to be present." > > This is supported by making 'name' a presence container with 'first' > and 'last' mandatory leafs. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 13:56:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7EBE3A682A; Tue, 22 Jul 2008 13:56: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 D52713A682A for ; Tue, 22 Jul 2008 13:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMdSFPynBaWA for ; Tue, 22 Jul 2008 13:56:45 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 32E213A67E1 for ; Tue, 22 Jul 2008 13:56:43 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 13:57:17 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 13:57:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 13:57:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 13:57:23 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6MKvMu83126; Tue, 22 Jul 2008 13:57:22 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6MKsNXO032711; Tue, 22 Jul 2008 20:54:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807222054.m6MKsNXO032711@idle.juniper.net> To: Balazs Lengyel In-reply-to: <4886484C.9070606@ericsson.com> Date: Tue, 22 Jul 2008 16:54:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 20:57:23.0115 (UTC) FILETIME=[89EBC7B0:01C8EC3D] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >That is far less work then understanding the concept of presence containers. >I like explicit statement: if I put mandatory there it is mandatory - simple. >Implied presence is a more complicated. This gives us three classes of containers: - those that mean something (presence containers) - those that are optional and meaningless (non-presence containers) - those that are mandatory and meaningless (new!) I just can't see the value of saying "it doesn't mean anything but it still has to be there". Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 14:05:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79FAE3A68BE; Tue, 22 Jul 2008 14:05:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5802D3A682A for ; Tue, 22 Jul 2008 14:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiyKLwZd-dk2 for ; Tue, 22 Jul 2008 14:05:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 32E873A677D for ; Tue, 22 Jul 2008 14:05:23 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92C8A20B9B; Tue, 22 Jul 2008 23:06:03 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-fe-48864bbb83c7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F02F20B9E; Tue, 22 Jul 2008 23:06:03 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 23:06:02 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 23:06:02 +0200 Message-ID: <48864BB9.5060002@ericsson.com> Date: Tue, 22 Jul 2008 23:06:01 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <713043CE8B8E1348AF3C546DBE02C1B41594555A@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> <20080722.222643.05065635.mbj@tail-f.com> In-Reply-To: <20080722.222643.05065635.mbj@tail-f.com> X-OriginalArrivalTime: 22 Jul 2008 21:06:02.0471 (UTC) FILETIME=[BF7B3770:01C8EC3E] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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, As you can have a "must" pointing to a state variable even today a valid configuration might become invalid. E.g. The sum of reserved bandwidths on an interface must be lower then the available bandwidth (state variable). Now suddenly the available bandwidth becomes smaller. The configuration became invalid. Also it is not written anywhere (and should not) that the system itself can not change it's configuration, e.g. you pull out an interface card, it get's noticed and reflected by the system. By the way as I read it the unique constraint can also be put on state data :-) Balazs Martin Bjorklund wrote: > Hi, > > "Sharon Chisholm" wrote: >> Hi >> >> Having done the politically correct thing and read the original thread, >> it isn't clear to me what the agreed solution was. I think the only >> restriction we should place on the keyref is that whatever I point to >> must exist. The fact that it never changes or may change is not >> relevant. In fact, if I point at something that gets deleted or removed >> and this causes an error to be reported then this is a good thing in my >> books compared to failing silently > > The problem is what happens if you have a config keyref which > points to some state object, and the state object is removed by the > device. Now your running config is invalid. > > To answer your original question: > >> Does this mean I can't >> associate a logical interface with a physical port? > > The answer currently is that you cannot do this association with a > keyref. You would have to use the same type and describe the > relationship in the description clause. > >> If that is too hard, then only do referential integrity checking >> 1) On creation >> 2) When explicitly asked to by some validate command. > > I don't think that would work. If e.g. the running config sometimes > can be invalid but the system still works, what does the validity > check give you? > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 14:06: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 BCBFA3A682A; Tue, 22 Jul 2008 14:06: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 6DEEB3A67E1 for ; Tue, 22 Jul 2008 14:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-4gNhxdQFcC for ; Tue, 22 Jul 2008 14:06:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 953003A67D4 for ; Tue, 22 Jul 2008 14:06:42 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id B8B3D76C229; Tue, 22 Jul 2008 23:07:23 +0200 (CEST) Date: Tue, 22 Jul 2008 23:07:14 +0200 (CEST) Message-Id: <20080722.230714.205125391.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4159456D5@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> <20080722.222643.05065635.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B4159456D5@zcarhxm2.corp.nortel.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] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Sharon Chisholm" wrote: > Hi > > Resource relationships are a critical part of the data model [...] > They key is that this information is in a machine readable format. I fully agree. > We could easily define a new verb that does referential > integrity checking if people don't think the existing validate should do > this. I definitely think the existing validate should do this. > I started to classify the type of information that a keyref would point > to so we could look at each in turn, including the one you listed where > I point at dynamic-static information. But I don't think this is any > different then configured information. Does it really matter if the > operator removed the thing I was point at or the system? The operator will not be able to remove something which is referred to by a keyref in a valid configuration. Let's go back to your example of an interface which has a relationship to a physical port. For some devices, the physical ports might be non-expandable, so in this case a keyref to non-config data would work - if the keyref is valid once it will stay valid. But some other systems might support adding/removing ports. So suppose I have an interface which refers to port 17, and port 17 is removed. What value does the keyref give you in this case? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 14:11: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 279443A6982; Tue, 22 Jul 2008 14:11: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 BEB493A69A4 for ; Tue, 22 Jul 2008 14:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E1vtoKXibXS for ; Tue, 22 Jul 2008 14:11:06 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id A1BE63A697B for ; Tue, 22 Jul 2008 14:11:03 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 14:11:40 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, 22 Jul 2008 14:10:51 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 14:10:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 14:10:50 -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 m6MLAou87867; Tue, 22 Jul 2008 14:10:50 -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 m6ML7pJf032860; Tue, 22 Jul 2008 21:07:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807222107.m6ML7pJf032860@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B4159456D5@zcarhxm2.corp.nortel.com> Date: Tue, 22 Jul 2008 17:07:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 21:10:50.0532 (UTC) FILETIME=[6B2DD640:01C8EC3F] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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 "Sharon Chisholm" writes: >The DSDL work describes three phases of validation that I think might be >useful here. Their third phase was for full configuration validation, which the running config should always pass. >Note that I have off-box tools very interested in being able to get this >sort of information in the Schema definition so they can perform their >own pre-validation before sending the configuration down to the box. The concern is that a reference to non-config data will not be dependable and any validation that uses it will then also not be dependable. If my model requires that all configured interfaces appear in physical PICs, then the removal of one PIC can invalidate my configuration. If I remove a PIC and reboot, the config will fail validation at boot time, leaving me with a few bad choices. If you remove a PIC and I do a commit, I see an error about which I know nothing ("Hey, who broke dc-core-01's config?"). Either way, we've introduced a source of instability and error. >But I don't think this is any >different then configured information. Does it really matter if the >operator removed the thing I was point at or the system? Compare this to a firewall filter. If an interface references a filter that isn't defined, the next commit (or the itself) will fail. The conifguration should be self-consistent and shouldn't become invalid based on the state of the box. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 14:15: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 0B70E3A6A16; Tue, 22 Jul 2008 14:15: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 E6D7E3A6A14 for ; Tue, 22 Jul 2008 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vbWS-DNAXPN for ; Tue, 22 Jul 2008 14:15:36 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2F9923A6A16 for ; Tue, 22 Jul 2008 14:15:36 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 7630376C229; Tue, 22 Jul 2008 23:16:17 +0200 (CEST) Date: Tue, 22 Jul 2008 23:16:13 +0200 (CEST) Message-Id: <20080722.231613.58869200.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48864BB9.5060002@ericsson.com> References: <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com> <20080722.222643.05065635.mbj@tail-f.com> <48864BB9.5060002@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > As you can have a "must" pointing to a state variable even today a > valid configuration might become invalid. So we should fix this. A 'must' on config data should not be allowed to refer to non-config data. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 14:18:02 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711A83A6881; Tue, 22 Jul 2008 14:18:02 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADBF3A6881 for ; Tue, 22 Jul 2008 14:18:01 -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 xn1+lmDgABpl for ; Tue, 22 Jul 2008 14:18:01 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 060613A67CC for ; Tue, 22 Jul 2008 14:18:00 -0700 (PDT) Received: (qmail 30437 invoked from network); 22 Jul 2008 21:18:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 21:18:40 -0000 X-YMail-OSG: DVaYpTIVM1mVfGZ3cQz7B64OtyfUIqp6BCBZuhve4X17PbUcjh8tEK4X7rQaX5McBnC2NRODMPJ8pUcs20weRNY.hvaid8cIY0DA3hutKg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48864EAE.3020608@netconfcentral.com> Date: Tue, 22 Jul 2008 14:18:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807222054.m6MKsNXO032711@idle.juniper.net> In-Reply-To: <200807222054.m6MKsNXO032711@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: > Balazs Lengyel writes: >> That is far less work then understanding the concept of presence containers. >> I like explicit statement: if I put mandatory there it is mandatory - simple. >> Implied presence is a more complicated. > > This gives us three classes of containers: > - those that mean something (presence containers) > - those that are optional and meaningless (non-presence containers) > - those that are mandatory and meaningless (new!) > > I just can't see the value of saying "it doesn't mean anything > but it still has to be there". > This 3rd class might be called encapsulation containers. At the abstraction level of the 'name' construct, it can make sense to decide if an instance of 'name' is mandatory or optional. IMO, encapsulation for complexity hiding and semantic/code reuse is not meaningless. YANG is very weak on information hiding encapsulation -- no derived classes, no deep keys, no ability to control containers top-down instead of bottom-up. > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 16:30: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 0CB3A28C106; Tue, 22 Jul 2008 16:30: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 D26CC28C106 for ; Tue, 22 Jul 2008 16:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, MANGLED_FORM=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqETvwPGOMQx for ; Tue, 22 Jul 2008 16:30:26 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id C21D63A6994 for ; Tue, 22 Jul 2008 16:30:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aNHcQo9Eu8Elz2DDrNe18lqYk3vdsyHLNjbTLGeBe0nHjWvK1nyhl2GPtsdhD52N; 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 [66.167.78.128] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KLRK0-0000xy-1p for netmod@ietf.org; Tue, 22 Jul 2008 19:31:08 -0400 Message-ID: <000401c8ec53$0e5bd840$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B4159455D6@zcarhxm2.corp.nortel.com><20080722.222643.05065635.mbj@tail-f.com><000f01c8ec3a$53fb5e20$6801a8c0@oemcomputer> <20080722.224054.65339245.mbj@tail-f.com> Date: Tue, 22 Jul 2008 16:31: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3a71fb0cf07d97798f80fd2e506418a9a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.128 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, July 22, 2008 1:40 PM > Subject: Re: [netmod] Why constrain keyref? ... > Can you provide a use-case for something else than failing validation > (which is what we do today)? A simple case comes from VACM. One can create a vacmSecurityToGroupEntry with at vacmGroupName referring to a vacmAccessEntry which does not exist. VACM will work just fine. Suppose we put in some kind of "must exist" constraint. Then we would have had to describe what would happen to any vacmSecurityToGroupEntrys whose vacmGroupName referred to a particular vacmAccessEntry if the vacmAccessEntry was deleted. This sort of dependency cascades through the model, so that iIt is ultimately much simpler and more robust to say what it means if a pointer points to something which does not exist or is not in service at the moment, than it would be to automagically delete or take out of service configuration elements which refer to things which have gone away. A more complicated use case comes from a mux I worked on long ago. That system supported N-for-M redundancy. For a particular group of cards, it was necessary to specify which cards would be members of the backup pool for the primaries. However, it was *not* necessary that those backups had to be physically present when the system was configured. Even if one insisted on all the cards being physically present at configuration time, it's still necessary for the behaviour to be well-defined as cards are hot-swapped. For example, removing a failed backup card doesn't invalidate the configurations of the primary cards for which that card is a member of the backup pool. Pulling out a working (or failed) line card should not cause that card's configuration to be forgotten - when the replacement is inserted, the (new) card will need to be put in service with appropriate parameters, and certainly without any intervention from a management system. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 16:52: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 12EFD28C13B; Tue, 22 Jul 2008 16:52: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 9A36E28C13B for ; Tue, 22 Jul 2008 16:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.599, 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 hcs76svB2jyZ for ; Tue, 22 Jul 2008 16:52:03 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 449D828C13F for ; Tue, 22 Jul 2008 16:52:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VJPAo9KGtij0n6nooSebkXK+Yy4nmqlehxlKTnT5l2uLdnZrN8GNzGO6vDZ0/m53; 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 [66.167.78.128] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KLRes-0001Qr-Ll for netmod@ietf.org; Tue, 22 Jul 2008 19:52:42 -0400 Message-ID: <003601c8ec56$11f6f900$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200807222107.m6ML7pJf032860@idle.juniper.net> Date: Tue, 22 Jul 2008 16:52:57 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3e7a3bd6eabada7c4b5076dc869fb70de350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.128 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: "Sharon Chisholm" > Cc: > Sent: Tuesday, July 22, 2008 2:07 PM > Subject: Re: [netmod] Why constrain keyref? ... > The conifguration should be self-consistent > and shouldn't become invalid based on the state of the box. In theory,. But whenever someone says "in theory", they probably mean "not really." :-) Sharon's right about the need to look at this in terms of validation phases. Though there is a certain utility to the kind of validation that can be done in terms of self-consistency, that's hardly sufficient for many real-world cases. It doesn't matter what bit rate I've configured an RS-232 port to use if what's in that slot is actually an ethernet card. Part of the difficulty here is that we're using the words "valid" and "invalid" in several different senses. Depending on which part of the larger problem one is interested in, each of these understandings of the term can be quite reasonable or, from another perspective, problematic. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 17:19: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 27DA43A6984; Tue, 22 Jul 2008 17:19: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 94C603A694C for ; Tue, 22 Jul 2008 17:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aqhpdgaShqk for ; Tue, 22 Jul 2008 17:19:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 825BA3A6936 for ; Tue, 22 Jul 2008 17:19:06 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m6N0HrC17838; Wed, 23 Jul 2008 00:17:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 20:19:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945843@zcarhxm2.corp.nortel.com> In-Reply-To: <200807222107.m6ML7pJf032860@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Why constrain keyref? Thread-Index: AcjsP46Zy2sK8JoMSr6gYV+qA/YXFgAGT9RQ References: <713043CE8B8E1348AF3C546DBE02C1B4159456D5@zcarhxm2.corp.nortel.com> <200807222107.m6ML7pJf032860@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi It seems the problem comes down to the fact that errors during configuration can be reported directly to the person who made them and prevented from being applied while errors introduced by removing hardware need to be reported with event Notifications. But if I remove the card, aren't things just as broken from an operational perspective except that I now have no way to detect and report it? Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Tuesday, July 22, 2008 5:08 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: Martin Bjorklund; netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? "Sharon Chisholm" writes: >The DSDL work describes three phases of validation that I think might >be useful here. Their third phase was for full configuration validation, which the running config should always pass. >Note that I have off-box tools very interested in being able to get >this sort of information in the Schema definition so they can perform >their own pre-validation before sending the configuration down to the box. The concern is that a reference to non-config data will not be dependable and any validation that uses it will then also not be dependable. If my model requires that all configured interfaces appear in physical PICs, then the removal of one PIC can invalidate my configuration. If I remove a PIC and reboot, the config will fail validation at boot time, leaving me with a few bad choices. If you remove a PIC and I do a commit, I see an error about which I know nothing ("Hey, who broke dc-core-01's config?"). Either way, we've introduced a source of instability and error. >But I don't think this is any >different then configured information. Does it really matter if the >operator removed the thing I was point at or the system? Compare this to a firewall filter. If an interface references a filter that isn't defined, the next commit (or the itself) will fail. The conifguration should be self-consistent and shouldn't become invalid based on the state of the box. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 18:04:30 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECF33A691A; Tue, 22 Jul 2008 18:04:30 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FF13A691A for ; Tue, 22 Jul 2008 18:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 5AdfeBG4E-5b for ; Tue, 22 Jul 2008 18:04:27 -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 0DC7B3A6850 for ; Tue, 22 Jul 2008 18:04:26 -0700 (PDT) Received: (qmail 75073 invoked from network); 23 Jul 2008 01:05:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2008 01:05:07 -0000 X-YMail-OSG: 29w0QCAVM1nFbVx0AGWMmqtoAWhbl.WhoS2C9RXvidUe4j6lAfZsjYcWB5O9D1o50mcuPhTC.9nGE02706AuZ9lbgBWUGFJT1iZ1kK6xCA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488683C0.9020602@netconfcentral.com> Date: Tue, 22 Jul 2008 18:05:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4159456D5@zcarhxm2.corp.nortel.com> <200807222107.m6ML7pJf032860@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B415945843@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415945843@zcarhxm2.corp.nortel.com> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Sharon Chisholm wrote: > Hi > > It seems the problem comes down to the fact that errors during > configuration can be reported directly to the person who made them and > prevented from being applied while errors introduced by removing > hardware need to be reported with event Notifications. But if I remove > the card, aren't things just as broken from an operational perspective > except that I now have no way to detect and report it? > What about the larger issue of leafref? That could solve all these problems. We seriously overload the keyref, which is one of the reasons I don't like it. It does not support most of the use cases either. Use cases: 1) foreign key in a list (e.g. ifIndex) 2) foreign leaf used as a key in a list (e.g., protocolDirLocalIndex) 3) copy-by-value shadow of some key leaf (e.g., my-ifIndex) 4) copy-by-value shadow of some non-key leaf (e.g., my-ifDescr) 5) pointer to data or config in notifications (e.g., IF-MIB linkDown objects: ifIndex, ifAdminStatus, ifOperStatus) IMO, keyref should be used for (1) and (3). There should also be leafref, which is not constrained like keyref, for use cases (2), (4), and (5). Keyref will stay the same. Leafref must point at an existing leaf. The hot-swap provisioning use-case cannot be supported with either data type. Just use the EntityIndexOrZero approach instead, which should be good enough. > Sharon Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 20:09: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 D84C43A69F5; Tue, 22 Jul 2008 20:09: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 EEFFC3A69F5 for ; Tue, 22 Jul 2008 20:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmD9ZhZtnXYp for ; Tue, 22 Jul 2008 20:09:39 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id F13623A6991 for ; Tue, 22 Jul 2008 20:09:38 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 20:09:56 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, 22 Jul 2008 20:09:52 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 20:09:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 20:09: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 m6N39ou84551; Tue, 22 Jul 2008 20:09:50 -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 m6N36oiK035637; Wed, 23 Jul 2008 03:06:51 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807230306.m6N36oiK035637@idle.juniper.net> To: Andy Bierman In-reply-to: <488683C0.9020602@netconfcentral.com> Date: Tue, 22 Jul 2008 23:06:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 03:09:51.0288 (UTC) FILETIME=[92785B80:01C8EC71] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >We seriously overload the keyref, which is one of the >reasons I don't like it. It does not support most of >the use cases either. Overloaded in what sense? It only does one thing. >Use cases: > > 1) foreign key in a list (e.g. ifIndex) > 2) foreign leaf used as a key in a list > (e.g., protocolDirLocalIndex) > 3) copy-by-value shadow of some key leaf > (e.g., my-ifIndex) > 4) copy-by-value shadow of some non-key leaf > (e.g., my-ifDescr) > 5) pointer to data or config in notifications > (e.g., IF-MIB linkDown objects: > ifIndex, ifAdminStatus, ifOperStatus) Can use give a non-SNMP dude some details behind (2) - (5)? Googling for "my-inDescr" only yields lots of perl code. keyref doesn't do copying (what's copy-on-value mean?), so I don't see how it could do (3). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 22 20:34: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 E91C33A69F5; Tue, 22 Jul 2008 20:34: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 DD70F3A69E2 for ; Tue, 22 Jul 2008 20:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aon1yYnzamD for ; Tue, 22 Jul 2008 20:34:26 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 5ED413A69F5 for ; Tue, 22 Jul 2008 20:34:24 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 20:34:48 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 20:34:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 20:34:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 20:34: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 m6N3YZu89397; Tue, 22 Jul 2008 20:34: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 m6N3Vab3035982; Wed, 23 Jul 2008 03:31:36 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807230331.m6N3Vab3035982@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B415945843@zcarhxm2.corp.nortel.com> Date: Tue, 22 Jul 2008 23:31:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 03:34:36.0531 (UTC) FILETIME=[07BE7430:01C8EC75] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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 "Sharon Chisholm" writes: >But if I remove >the card, aren't things just as broken from an operational perspective >except that I now have no way to detect and report it? No breakage at all. If the interface isn't there (or is the wrong type), the configuration is ignored. When the PIC is inserted, the system sees the PIC, sees the config, and does The Right Thing. Operators have used this for eons to allow them to pre-configure PICs. They can add configuration for a non-existent PIC, knowing that the PIC will appear during the next maintenance window. We call this "ephemeral interface" internally, but I don't know the external term, or what IOS calls them, but IIRC they support the same mechanism. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 01:49: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 3EB0F3A6ACD; Wed, 23 Jul 2008 01:49: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 3FEF73A6ACD for ; Wed, 23 Jul 2008 01:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdkXFtgZsgeA for ; Wed, 23 Jul 2008 01:49:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AAC113A6AC0 for ; Wed, 23 Jul 2008 01:49:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 861F320B5C; Wed, 23 Jul 2008 10:50:18 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-36-4886f055d94e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 68D0E20EAD; Wed, 23 Jul 2008 10:48:21 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:48:04 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:48:03 +0200 Message-ID: <4886F040.7090600@ericsson.com> Date: Wed, 23 Jul 2008 10:48:00 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200807222054.m6MKsNXO032711@idle.juniper.net> In-Reply-To: <200807222054.m6MKsNXO032711@idle.juniper.net> X-OriginalArrivalTime: 23 Jul 2008 08:48:03.0994 (UTC) FILETIME=[D1DD8FA0:01C8ECA0] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: > Balazs Lengyel writes: >> That is far less work then understanding the concept of presence containers. >> I like explicit statement: if I put mandatory there it is mandatory - simple. >> Implied presence is a more complicated. > > This gives us three classes of containers: 1) > - those that mean something (presence containers) 2) > - those that are optional and meaningless (non-presence containers) 3) > - those that are mandatory and meaningless (new!) > > I just can't see the value of saying "it doesn't mean anything > but it still has to be there". > Case 2 and 3 are separate. Case 2) is when the whole sub-tree is optional, but if it exists data inside MUST be there. You might define the accounting server for your node as calls might or might not be charged, so the whole subtree is optional; only if you charge for the calls Case 3) is when the container AND the whole sub-tree is mandatory, but I still want to put it under a container just to have a nice structure. You must define a set of Home Subscriber Servers to act as a subscriber database as your IMS node will not wotrk without it Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 02:01: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 52D6C3A6AAA; Wed, 23 Jul 2008 02:01: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 F27CD28C16D for ; Wed, 23 Jul 2008 02:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 3n1FOplreuKw for ; Wed, 23 Jul 2008 02:01:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EBE5E3A68A4 for ; Wed, 23 Jul 2008 02:01:21 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 515D421334; Wed, 23 Jul 2008 11:02:03 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-72-4886f38a8910 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AC18E2135A; Wed, 23 Jul 2008 11:02:02 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 11:01:48 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 11:01:48 +0200 Message-ID: <4886F37B.8090509@ericsson.com> Date: Wed, 23 Jul 2008 11:01:47 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200807230331.m6N3Vab3035982@idle.juniper.net> In-Reply-To: <200807230331.m6N3Vab3035982@idle.juniper.net> X-OriginalArrivalTime: 23 Jul 2008 09:01:48.0389 (UTC) FILETIME=[BD3E4150:01C8ECA2] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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, But if the operator puts in the wrong type of card, the configuration will become invalid. True? Balazs Phil Shafer wrote: > "Sharon Chisholm" writes: >> But if I remove >> the card, aren't things just as broken from an operational perspective >> except that I now have no way to detect and report it? > > No breakage at all. If the interface isn't there (or is the > wrong type), the configuration is ignored. When the PIC is > inserted, the system sees the PIC, sees the config, and does > The Right Thing. So keyref would not be used to reference such a PIC. > > Operators have used this for eons to allow them to pre-configure > PICs. They can add configuration for a non-existent PIC, knowing > that the PIC will appear during the next maintenance window. > > We call this "ephemeral interface" internally, but I don't know the > external term, or what IOS calls them, but IIRC they support the > same mechanism. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 06:08: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 3475C3A69FC; Wed, 23 Jul 2008 06:08: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 0BA913A6920 for ; Wed, 23 Jul 2008 06:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=0.048, 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 d3Eu2P1CLKwY for ; Wed, 23 Jul 2008 06:08:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E4BA03A6894 for ; Wed, 23 Jul 2008 06:08:25 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 12445D800C5 for ; Wed, 23 Jul 2008 15:09:08 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 23 Jul 2008 15:09:07 +0200 Message-Id: <1216818547.6284.39.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] DSDL work X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 slides for the Friday in-depth session are here: http://staff.cesnet.cz/~lhotka/NETMOD/yang2dsdl.pdf For the public session on Thursday, it would be great to be able to propose how the two existing DSDL drafts will be integrated. In my opinion, the main difference between the two is that draft-mahy-canmod-dsdl assumes DSDL to be the primary DML that sets the stage whereas draft-lhotka-yang-dsdl-map takes YANG as primary and just translates its semantics, extension model etc. However, the NETMOD charter is quite clear in saying that YANG is primary. Therefore, I suggest the following: 1. Take the useful things from draft-mahy-... (validation phases, deep keys etc.) and implement them appropriately in YANG. 2. Reconsider the YANG idiosyncrasies that make translation to DSDL hard and adjust them where possible. 3. Concentrate on YANG->DSDL _mapping_ rather than on DSDL as a DML par excellence. I think most of the information for doing this is already available. I also have to stress that this does not preclude other improvements to YANG, this is only about YANG-DSDL relationship. Is it an acceptable scenario? 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 Jul 23 06:58:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45303A69AC; Wed, 23 Jul 2008 06:58:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3E23A69C5 for ; Wed, 23 Jul 2008 06:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 7toINnY0cRl9 for ; Wed, 23 Jul 2008 06:58:26 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 2AEC53A67D9 for ; Wed, 23 Jul 2008 06:58:26 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6NDx5S13634; Wed, 23 Jul 2008 13:59:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 09:58:24 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945CBB@zcarhxm2.corp.nortel.com> In-Reply-To: <1216818547.6284.39.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] DSDL work Thread-Index: AcjsxV8P6Mz7X5uVSFajTjLofcTPnQABcqnA References: <1216818547.6284.39.camel@missotis> From: "Sharon Chisholm" To: "Ladislav Lhotka" , "NETMOD Working Group" Subject: Re: [netmod] DSDL work X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 You need to fully understand the DSDL for NETCONF definition in order to map to it. I don't think the requirement on the quality of the definition is reduced because we are introducing yang. Part of me thinks it might mean we need to be even more rigorous in definition. But we do absolutely want to merge together the two drafts. There isn't much overlap, so that should make it fairly easy to do. Then we can prune and modify as the workgroup works through the various open issues. Sharon -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Wednesday, July 23, 2008 9:09 AM To: NETMOD Working Group Subject: [netmod] DSDL work Hi, my slides for the Friday in-depth session are here: http://staff.cesnet.cz/~lhotka/NETMOD/yang2dsdl.pdf For the public session on Thursday, it would be great to be able to propose how the two existing DSDL drafts will be integrated. In my opinion, the main difference between the two is that draft-mahy-canmod-dsdl assumes DSDL to be the primary DML that sets the stage whereas draft-lhotka-yang-dsdl-map takes YANG as primary and just translates its semantics, extension model etc. However, the NETMOD charter is quite clear in saying that YANG is primary. Therefore, I suggest the following: 1. Take the useful things from draft-mahy-... (validation phases, deep keys etc.) and implement them appropriately in YANG. 2. Reconsider the YANG idiosyncrasies that make translation to DSDL hard and adjust them where possible. 3. Concentrate on YANG->DSDL _mapping_ rather than on DSDL as a DML par excellence. I think most of the information for doing this is already available. I also have to stress that this does not preclude other improvements to YANG, this is only about YANG-DSDL relationship. Is it an acceptable scenario? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 07:04: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 90D453A696F; Wed, 23 Jul 2008 07:04: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 E1A723A6995 for ; Wed, 23 Jul 2008 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 1h1sPcRYS3xW for ; Wed, 23 Jul 2008 07:04:13 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id CB3483A6881 for ; Wed, 23 Jul 2008 07:04:12 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6NE4pe11802; Wed, 23 Jul 2008 14:04:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 10:04:47 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945CF1@zcarhxm2.corp.nortel.com> In-Reply-To: <4886F37B.8090509@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Why constrain keyref? Thread-Index: AcjsoseeH6LHm6baTgiHktGs1UWOdgAKX0Tw References: <200807230331.m6N3Vab3035982@idle.juniper.net> <4886F37B.8090509@ericsson.com> From: "Sharon Chisholm" To: "Balazs Lengyel" , "Phil Shafer" Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Pre-configuration is certainly a use case to consider. It's one where it would be nice to bake something into the solution early on. I know when we tried to glue it on afterwards in the Entity MIB (internally), we ran to some issues. I think the key is be able to differentiate between things that are configured but not present where this should not be considered an error and real error conditions. If you can differentiate this, then referential integrity algorithms might be able to pass on this case but fail when the keyref points at something that doesn't exist at all, like it should. Sharon -----Original Message----- From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] Sent: Wednesday, July 23, 2008 5:02 AM To: Phil Shafer Cc: Chisholm, Sharon (CAR:ZZ00); netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? Hello, But if the operator puts in the wrong type of card, the configuration will become invalid. True? Balazs Phil Shafer wrote: > "Sharon Chisholm" writes: >> But if I remove >> the card, aren't things just as broken from an operational >> perspective except that I now have no way to detect and report it? > > No breakage at all. If the interface isn't there (or is the wrong > type), the configuration is ignored. When the PIC is inserted, the > system sees the PIC, sees the config, and does The Right Thing. So keyref would not be used to reference such a PIC. > > Operators have used this for eons to allow them to pre-configure PICs. > They can add configuration for a non-existent PIC, knowing that the > PIC will appear during the next maintenance window. > > We call this "ephemeral interface" internally, but I don't know the > external term, or what IOS calls them, but IIRC they support the same > mechanism. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 07:17: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 212E13A69CF; Wed, 23 Jul 2008 07:17: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 9352B3A69C5 for ; Wed, 23 Jul 2008 07:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE9xR3-nWfCG for ; Wed, 23 Jul 2008 07:17:32 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id BB19C3A69A7 for ; Wed, 23 Jul 2008 07:17:32 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 07:17:43 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 07:16:11 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 07:16:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 07:16:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6NEG9u58490; Wed, 23 Jul 2008 07:16:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6NEDApr038953; Wed, 23 Jul 2008 14:13:10 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231413.m6NEDApr038953@idle.juniper.net> To: Balazs Lengyel In-reply-to: <4886F37B.8090509@ericsson.com> Date: Wed, 23 Jul 2008 10:13:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 14:16:10.0347 (UTC) FILETIME=[A7D8A3B0:01C8ECCE] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >But if the operator puts in the wrong type of card, the configuration will bec >ome invalid. True? No, it's ignored. Only if the right interface type is in the right slot will it become implemented. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 07:34: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 D3E983A68CE; Wed, 23 Jul 2008 07:34: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 615A33A68CE for ; Wed, 23 Jul 2008 07:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 LEnWFdNO8DJQ for ; Wed, 23 Jul 2008 07:34:01 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 2CF1A3A67A7 for ; Wed, 23 Jul 2008 07:34:01 -0700 (PDT) Received: (qmail 41598 invoked from network); 23 Jul 2008 14:34:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2008 14:34:41 -0000 X-YMail-OSG: 7CfyhYQVM1kyMOpb1BP5ofpI6QVg7pm.OCpOpp4deC9rdYZr6oRTKmfS8NprR53nuBDIKndBHches.RCZnwQTCm8ed5whSvBugH0GGABCQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4887417F.3020506@netconfcentral.com> Date: Wed, 23 Jul 2008 07:34:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807230306.m6N36oiK035637@idle.juniper.net> In-Reply-To: <200807230306.m6N36oiK035637@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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: >> We seriously overload the keyref, which is one of the >> reasons I don't like it. It does not support most of >> the use cases either. > > Overloaded in what sense? It only does one thing. > >> Use cases: >> >> 1) foreign key in a list (e.g. ifIndex) >> 2) foreign leaf used as a key in a list >> (e.g., protocolDirLocalIndex) >> 3) copy-by-value shadow of some key leaf >> (e.g., my-ifIndex) >> 4) copy-by-value shadow of some non-key leaf >> (e.g., my-ifDescr) >> 5) pointer to data or config in notifications >> (e.g., IF-MIB linkDown objects: >> ifIndex, ifAdminStatus, ifOperStatus) > > Can use give a non-SNMP dude some details behind (2) - (5)? Googling > for "my-inDescr" only yields lots of perl code. > How about a hybrid interfaces table: container interfaces { list interface { key name; leaf name { type string { length "1..1023"; } } leaf ifIndex { type if:InterfaceIndex; config false; } // rest of new interfaces table } } container ifTable { list ifEntry { key ifIndex; leaf ifIndex { type leafref { path "/interfaces/interface/ifIndex"; } } // rest of old ifEntry } } In the new interface table, the name (e.g., 'eth0') is the key, not ifIndex. This is an agent-assigned column, which many vendors persist after a reboot. ifIndex is not config. It is not a key in the table it is defined. But it is config, and a key, in many other tables. > keyref doesn't do copying (what's copy-on-value mean?), so I don't > see how it could do (3). I thought Martin said that if you edited the keyref, that does not change the real value, just the keyref. That is copy-by-value, not copy-by-reference. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 07:41: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 3C4CA3A68A3; Wed, 23 Jul 2008 07:41: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 730AD3A6818 for ; Wed, 23 Jul 2008 07:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj9Wy292aifs for ; Wed, 23 Jul 2008 07:41:32 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id E9B2A3A6A4A for ; Wed, 23 Jul 2008 07:41:06 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 07:41:16 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 07:41:11 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 07:41:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 07:34: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 m6NEYMu63880; Wed, 23 Jul 2008 07:34:22 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6NEVM5C039091; Wed, 23 Jul 2008 14:31:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231431.m6NEVM5C039091@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B415945CF1@zcarhxm2.corp.nortel.com> Date: Wed, 23 Jul 2008 10:31:21 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 14:34:22.0428 (UTC) FILETIME=[32C6F9C0:01C8ECD1] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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 "Sharon Chisholm" writes: >I think the key is be able to differentiate between >things that are configured but not present where this should not be >considered an error and real error conditions. If you can differentiate >this, then referential integrity algorithms might be able to pass on >this case but fail when the keyref points at something that doesn't >exist at all, like it should. Please help me understand your requirement here. Keyref gives a contraint, where the leaf refers to another leaf that must exist. The keyref path must match at least one leaf value (elsewhere in the data hierarchy) to be valid. If there is no matching value, the configuration is not valid. But you are looking for a softer version, where the constraint isn't enforced, right? This isn't referential integrity, since the integrity is not enforced. Can you explain where these soft references are useful? Are they used to generate possible values in scenarios where the user can take either these values or an unconstrained one? I understand (and love) the hard constraint for referential integrity, where the config cannot contain references that point to something that doesn't exist. This feels normal, and enforces the goal that configurations should be self-consistent, that dangling references are bad and need repaired. But I'm not getting the need for soft references, since they aren't a constraint. Are they suggestions or helpers to guide the users' choice? Or something else? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 07:44: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 98B4F3A6A4A; Wed, 23 Jul 2008 07:44: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 9B1493A6818 for ; Wed, 23 Jul 2008 07:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 LU58X67s0h7B for ; Wed, 23 Jul 2008 07:44:05 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 777B13A68CD for ; Wed, 23 Jul 2008 07:44:05 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m6NEgrM11195; Wed, 23 Jul 2008 14:42:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 10:44:44 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945E26@zcarhxm2.corp.nortel.com> In-Reply-To: <200807231431.m6NEVM5C039091@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Why constrain keyref? Thread-Index: Acjs0j80ET6g/bxiSne5xjz2yOB42wAAEZYw References: <713043CE8B8E1348AF3C546DBE02C1B415945CF1@zcarhxm2.corp.nortel.com> <200807231431.m6NEVM5C039091@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi I am actually interested in hard constraints. What I was trying to do was introduce a soft one to handle the use case you referred to. I don't want any restrictions on what I can point at. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Wednesday, July 23, 2008 10:31 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: Balazs Lengyel; netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? "Sharon Chisholm" writes: >I think the key is be able to differentiate between things that are >configured but not present where this should not be considered an error >and real error conditions. If you can differentiate this, then >referential integrity algorithms might be able to pass on this case but >fail when the keyref points at something that doesn't exist at all, >like it should. Please help me understand your requirement here. Keyref gives a contraint, where the leaf refers to another leaf that must exist. The keyref path must match at least one leaf value (elsewhere in the data hierarchy) to be valid. If there is no matching value, the configuration is not valid. But you are looking for a softer version, where the constraint isn't enforced, right? This isn't referential integrity, since the integrity is not enforced. Can you explain where these soft references are useful? Are they used to generate possible values in scenarios where the user can take either these values or an unconstrained one? I understand (and love) the hard constraint for referential integrity, where the config cannot contain references that point to something that doesn't exist. This feels normal, and enforces the goal that configurations should be self-consistent, that dangling references are bad and need repaired. But I'm not getting the need for soft references, since they aren't a constraint. Are they suggestions or helpers to guide the users' choice? Or something else? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 08:26: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 B631F3A6407; Wed, 23 Jul 2008 08:26: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 B87403A6407 for ; Wed, 23 Jul 2008 08:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trVx2pQ+QoEg for ; Wed, 23 Jul 2008 08:26:46 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id E44823A635F for ; Wed, 23 Jul 2008 08:26:45 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 08:23:14 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 08:24:31 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 08:24:30 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 08:24:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6NFOTu79441; Wed, 23 Jul 2008 08:24:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6NFLTD3039594; Wed, 23 Jul 2008 15:21:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231521.m6NFLTD3039594@idle.juniper.net> To: Andy Bierman In-reply-to: <4887417F.3020506@netconfcentral.com> Date: Wed, 23 Jul 2008 11:21:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 15:24:29.0945 (UTC) FILETIME=[3365A690:01C8ECD8] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >In the new interface table, the name (e.g., 'eth0') >is the key, not ifIndex. This is an agent-assigned column, >which many vendors persist after a reboot. If your config references non-config data, you are asking for trouble. Even though we try to make ifIndex values persist, it's not perfect and certainly not something you want to bet your box on. If you need to swap out the box, for example, these values are lost. >ifIndex is not config. It is not a key >in the table it is defined. But it is config, and a key, >in many other tables. This makes for a bad model. If you want ifIndex values to persist, you need to enforce this constraint by making them part of your configuration. Or decide that this is a bad idea and start using interface names instead of ifIndex values. Given that this is how most devices work, it's a much more dependable, well worn path. >> keyref doesn't do copying (what's copy-on-value mean?), so I don't >> see how it could do (3). >I thought Martin said that if you edited the keyref, >that does not change the real value, just the keyref. >That is copy-by-value, not copy-by-reference. I don't think this is true. Martin? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 08:56: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 9007D3A6901; Wed, 23 Jul 2008 08:56: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 C92A23A6407 for ; Wed, 23 Jul 2008 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 oNLsi+HhiDPw for ; Wed, 23 Jul 2008 08:56:27 -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 B2FD03A69A7 for ; Wed, 23 Jul 2008 08:56:27 -0700 (PDT) Received: (qmail 2749 invoked from network); 23 Jul 2008 15:57:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2008 15:57:08 -0000 X-YMail-OSG: ed_kwgIVM1kEArYGN4hvmmJiHO.pK1v4VYlpEHWEoprIRSmwPtvt2FoWmAYgOSJiMj2n2dDIPP9h3t6Av6.fEKY22y9qBXAlRXxL9JLDUWec7qWMEn5vQ3ppLiKb X-Yahoo-Newman-Property: ymail-3 Message-ID: <488754D2.7080106@netconfcentral.com> Date: Wed, 23 Jul 2008 08:57:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807231521.m6NFLTD3039594@idle.juniper.net> In-Reply-To: <200807231521.m6NFLTD3039594@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> In the new interface table, the name (e.g., 'eth0') >> is the key, not ifIndex. This is an agent-assigned column, >> which many vendors persist after a reboot. > > If your config references non-config data, you are asking for > trouble. Even though we try to make ifIndex values persist, it's > not perfect and certainly not something you want to bet your box > on. If you need to swap out the box, for example, these values > are lost. I meant ifIndex is the agent-assigned column, not 'name'. ifIndex is used in lots of tables and CLI commands. It is defined as read-only in the IF-MIB. This has been going on for decades. Maybe it's a bad idea, but it is current practice. The RMON2 protocol directory uses really complex identifiers. The agent assigns a read-only number for shorthand use as an index in all the read-only monitoring tables that report data per protocol encapsulation layer. > >> ifIndex is not config. It is not a key >> in the table it is defined. But it is config, and a key, >> in many other tables. > > This makes for a bad model. If you want ifIndex values to persist, > you need to enforce this constraint by making them part of your > configuration. Or decide that this is a bad idea and start using > interface names instead of ifIndex values. Given that this is > how most devices work, it's a much more dependable, well worn path. I don't see ifIndex going away any time soon. There are lots of dev-hours invested in it already. Persistent ifIndex support is difficult, but the work has been done already to support it. Here is a notification example from 4.2.10: notification link-failure { description "A link failure has been detected"; leaf if-index { type int32 { range "1 .. max"; } } leaf if-name { type keyref { path "/interfaces/interface/name"; } } } 1) At a systems-level, what value is there is replicating the SNMP notifications? IMO, this is pointless. We should use 'smidump -f yang IF-MIB' and use linkUp and linkDown directly. (Same goes for SMIv2 data types in YANG.) 2) Note that if-name is properly modeling the semantics of the notification, but if-index is not. This notification does not contain the real definition of if-name. It contains a reference to the real if-name. These semantics fall out for free in the SMIv2 OBJECTS clause, but they are easily lost in YANG notifications. 3) 'config false;' statements are missing from if-index and if-name in the example. > >>> keyref doesn't do copying (what's copy-on-value mean?), so I don't >>> see how it could do (3). >> I thought Martin said that if you edited the keyref, >> that does not change the real value, just the keyref. >> That is copy-by-value, not copy-by-reference. > > I don't think this is true. Martin? > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 09:12:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B7A3A6881; Wed, 23 Jul 2008 09:12:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4213A6881 for ; Wed, 23 Jul 2008 09:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzKOY86Pflkh for ; Wed, 23 Jul 2008 09:12:20 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 565B83A6407 for ; Wed, 23 Jul 2008 09:12:20 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 09:13:01 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:12:59 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:12:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:12: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 m6NGCvu94523; Wed, 23 Jul 2008 09:12:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6NG9vRX039883; Wed, 23 Jul 2008 16:09:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231609.m6NG9vRX039883@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B415945E26@zcarhxm2.corp.nortel.com> Date: Wed, 23 Jul 2008 12:09:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 16:12:57.0855 (UTC) FILETIME=[F8A580F0:01C8ECDE] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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 "Sharon Chisholm" writes: >I am actually interested in hard constraints. What I was trying to do >was introduce a soft one to handle the use case you referred to. I don't >want any restrictions on what I can point at. If you have hard constraints that refer to non-config data, you have config that won't validate due to dynamic conditions (missing FRUs, restarting subsystems, etc). If you want references to non-config data, you can't make them hard. (a) validation (b) hard constraints (c) allow non-config data You can pick only two. I want (a) and (b), and don't want (c). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 09:19: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 89C4C3A69F4; Wed, 23 Jul 2008 09:19: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 B9B493A6918 for ; Wed, 23 Jul 2008 09:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYraJHetLpVp for ; Wed, 23 Jul 2008 09:19:23 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 02A723A69F4 for ; Wed, 23 Jul 2008 09:19:20 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 09:18:20 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:20:02 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:20:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:20: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 m6NGK0u96408; Wed, 23 Jul 2008 09:20: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 m6NGH0tV039948; Wed, 23 Jul 2008 16:17:00 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231617.m6NGH0tV039948@idle.juniper.net> To: Balazs Lengyel In-reply-to: <4886F040.7090600@ericsson.com> Date: Wed, 23 Jul 2008 12:17:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 16:20:00.0641 (UTC) FILETIME=[F4A58710:01C8ECDF] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel writes: >> This gives us three classes of containers: >1) > - those that mean something (presence containers) >2) > - those that are optional and meaningless (non-presence containers) >3) > - those that are mandatory and meaningless (new!) >> >Case 2) is when the whole sub-tree is optional, but if it exists data inside M >UST be there. >You might define the accounting server for your node as calls might or might n >ot be charged, so >the whole subtree is optional; only if you charge for the calls By dig into the the question of "why is the whole sub-tree optional?" If it have no independent meaning, why whould you make it? If you only make it to contian other nodes, then the need for the child nodes is what makes you create it. The non-presence container has no meaning, and can be created and deleted as needed based on the creation and deletion of the child nodes. >Case 3) is when the container AND the whole sub-tree is mandatory, but I still > want to put it >under a container just to have a nice structure. This container is merely organizational, but contains mandatory nodes. Since the child nodes must exist, the existence of the container is implicit. >You must define a set of Home Subscriber Servers to act as a subscriber databa >se as your IMS >node will not wotrk without it I don't follow this comment. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 09:31: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 986613A69B8; Wed, 23 Jul 2008 09:31: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 A4A383A69B8 for ; Wed, 23 Jul 2008 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNd6At6fDUT2 for ; Wed, 23 Jul 2008 09:31:26 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 5E0CB3A6407 for ; Wed, 23 Jul 2008 09:31:26 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 09:31:09 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:31:12 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:31:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:25: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 m6NGPeu98057; Wed, 23 Jul 2008 09:25:40 -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 m6NGMef8040014; Wed, 23 Jul 2008 16:22:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231622.m6NGMef8040014@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <003601c8ec56$11f6f900$6801a8c0@oemcomputer> Date: Wed, 23 Jul 2008 12:22:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 16:25:40.0273 (UTC) FILETIME=[BF154210:01C8ECE0] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >> The conifguration should be self-consistent >> and shouldn't become invalid based on the state of the box. > >In theory,. But whenever someone says "in theory", they probably >mean "not really." :-) I didn't say "in theory" and I didn't mean "not really". I meant "in the (real) products that we (really) ship to (real) operators who (really) deploy them in the (real) internet". Really. ;^) >It doesn't matter what bit >rate I've configured an RS-232 port to use if what's in that slot >is actually an ethernet card. Part of the difficulty here is that >we're using the words "valid" and "invalid" in several different >senses. In YANG, these would be two distinct augmentations based on the interface type. 10m would not be in conflict with 9600. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 09:56: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 B42593A6AF0; Wed, 23 Jul 2008 09:56: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 4B5D63A6AF0 for ; Wed, 23 Jul 2008 09:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 Qhw2m6DbthMr for ; Wed, 23 Jul 2008 09:55:59 -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 5B6153A6AEE for ; Wed, 23 Jul 2008 09:55:59 -0700 (PDT) Received: (qmail 70428 invoked from network); 23 Jul 2008 16:56:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2008 16:56:39 -0000 X-YMail-OSG: G7Ra3XoVM1kGN0NSfGhAZfWQdU4YFuJRC2aWqbn1a_Sr2x4kTb0x7bL6hJklPJMkzatW7xM.M8ia1.y9zgkmNzDQwuQSzRUI4dwiAhDjN9rNVqD_fh0BsfD4iQxX X-Yahoo-Newman-Property: ymail-3 Message-ID: <488762C5.30407@netconfcentral.com> Date: Wed, 23 Jul 2008 09:56:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807231617.m6NGH0tV039948@idle.juniper.net> In-Reply-To: <200807231617.m6NGH0tV039948@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: > Balazs Lengyel writes: >>> This gives us three classes of containers: >> 1) > - those that mean something (presence containers) >> 2) > - those that are optional and meaningless (non-presence containers) >> 3) > - those that are mandatory and meaningless (new!) >> Case 2) is when the whole sub-tree is optional, but if it exists data inside M >> UST be there. >> You might define the accounting server for your node as calls might or might n >> ot be charged, so >> the whole subtree is optional; only if you charge for the calls > > By dig into the the question of "why is the whole sub-tree optional?" > If it have no independent meaning, why whould you make it? If > you only make it to contian other nodes, then the need for the > child nodes is what makes you create it. The non-presence container > has no meaning, and can be created and deleted as needed based on > the creation and deletion of the child nodes. > You seem to be focusing on direct, inline definitions without considering object reuse. When one attempts to use groupings and containers for encapsulation and reuse, YANG is not very powerful. These 'building block' sort of sub-structures need to be designed independently of the parent context. Some properties need to be inherited from the parent node, by design. IMO, 'mandatory' is one of them. The parent node should decide if the child node is mandatory, not the other way around. IMO, it is more intuitive and reusable to be able to define a container as mandatory true/false in a top-down manner, rather than track down all the child nodes, read all the presence-stmt clauses, augment-when clauses, and eventually figure out the mandatory status. Of course the compiler can do that fairly quickly, but not the DM reader or writer. >> Case 3) is when the container AND the whole sub-tree is mandatory, but I still >> want to put it >> under a container just to have a nice structure. > > This container is merely organizational, but contains mandatory nodes. > Since the child nodes must exist, the existence of the container is > implicit. > >> You must define a set of Home Subscriber Servers to act as a subscriber databa >> se as your IMS >> node will not wotrk without it > > I don't follow this comment. > > Thanks, > Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 10:07: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 B249A3A6901; Wed, 23 Jul 2008 10:07: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 C112D3A6407 for ; Wed, 23 Jul 2008 10:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.701, 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 YAyiyq+zhQ3n for ; Wed, 23 Jul 2008 10:07:03 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 96AEC3A6901 for ; Wed, 23 Jul 2008 10:07:03 -0700 (PDT) X-Trace: 5664793/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.134.171 X-SBRS: None X-RemoteIP: 62.188.134.171 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAD0Ch0g+vIar/2dsb2JhbACDXTWHV6coAw X-IronPort-AV: E=Sophos;i="4.31,239,1215385200"; d="scan'208";a="5664793" X-IP-Direction: IN Received: from 1cust171.tnt5.lnd4.gbr.da.uu.net (HELO allison) ([62.188.134.171]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Jul 2008 18:07:44 +0100 Message-ID: <001401c8ecdd$69804280$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "Phil Shafer" References: <200807211534.m6LFYTgv020044@idle.juniper.net> Date: Wed, 23 Jul 2008 17:24:22 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Phil Shafer" To: "David Harrington" Cc: Sent: Monday, July 21, 2008 5:34 PM Subject: Re: [netmod] netmod session agendas > How about this: we take a show of hands at the start of the session > for the number of audience members that have read the YANG spec > (the folks that come to the meeting prepared) who didn't attend the > OPS-AREA boot camp or BOF (who already know what we're doing). If > this group is sufficently small, the WG chairs can decide to skip > the training agenda items and move on into open issues and real > work. Otherwise the work issues are pushed to Friday's session. > We can have these training materials available (and online) and if > they aren't needed, no problem. There seems to be an assumption here that reading the YANG spec will obviate the need for training, something of which I have yet to be convinced:-) Look at dbh's list, and tell me where the answers are in the YANG spec: eg how are modules defined? how are namespaces handled? how are standard and proprietary modules differentiated? If you are the editor for a WG model, how do you get a namespace for your module? If you are the editor for a proprietary model, how do you define a neamspace? What naming conventions should be used for standard and proprietary objects? Do you notice something? There is an awful lot of names and namespaces, something that XML has got badly wrong (IMHO) and which I am unclear how much YANG has improved on. But reading 263kbyte of the YANG spec does not enlighten me much:-( And I would see the discussions on the list on mandatory, default, config, presence etc as a symptom not that the YANG spec is unclear, but that the concepts need spelling out, and I wonder if that is done, then those concepts may turn out to be unclear By contrast, I recall when first I read RFC1155 - in some ways, an analogous document - and immediately getting a clear idea of the key concepts. I think you need something else, an RFC that enables people to understand the concepts of YANG before they dive into the encyclopaedia that this I-D is. Answers to dbh's questions would provide a start. Tom Petch > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 10:29:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F953A6900; Wed, 23 Jul 2008 10:29:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E163A6825 for ; Wed, 23 Jul 2008 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_FORM=2.3, 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 sKBfSUY4AyZv for ; Wed, 23 Jul 2008 10:29:46 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 960CA3A6966 for ; Wed, 23 Jul 2008 10:29:45 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 10:30:03 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 10:30:08 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 10:30:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:30:07 -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 m6NHU1u21892; Wed, 23 Jul 2008 10:30: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 m6NHR1qT040572; Wed, 23 Jul 2008 17:27:01 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231727.m6NHR1qT040572@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <000401c8ec53$0e5bd840$6801a8c0@oemcomputer> Date: Wed, 23 Jul 2008 13:27:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 17:30:07.0973 (UTC) FILETIME=[C0697150:01C8ECE9] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >Suppose we put in some kind of "must exist" constraint. Then we >would have had to describe what would happen to any vacmSecurityToGroupEntrys >whose vacmGroupName referred to a particular vacmAccessEntry if >the vacmAccessEntry was deleted. This is the logic behind languages that don't require you to declare variables before using them, like Perl. And, like Perl, users revolt and want stronger enforcement to avoid scenarios where they make a typo and their program stops working. The same is true for config. By allowing dangling references, you allow errors to be introduced. A user says "fooo" instead of "foo" and there's no error. Or they delete "foo" and there's no error. Users want strong constraints to help detect errors early and to prevent new hires from making mistakes that cost money. >This sort of dependency cascades >through the model, so that iIt is ultimately much simpler and more robust to >say what it means if a pointer points to something which does not >exist or is not in service at the moment, than it would be to automagically >delete or take out of service configuration elements which refer to things >which have gone away. This is a simple matter, programmatically, once you have keyref. "set anything that referenced 'foo' to now reference 'goo'" is a simple xslt script. >A more complicated use case comes from a mux I worked on long ago. >That system supported N-for-M redundancy. For a particular group >of cards, it was necessary to specify which cards would be members of >the backup pool for the primaries. However, it was *not* necessary that those >backups had to be physically present when the system was configured. This is exactly the sort of ephemeral configuration we are talking about. If your backup pool lists a card, that card should be configured (assuming the card has its own config), but it need not be physically present. When it arrives, the system configures it as instructed. But allowing the pool to reference a card that isn't configured (or allowing invalid card names) creates a source of detectable errors. Which creates a bug report ;^) >Pulling out a working (or failed) >line card should not cause that card's configuration to be forgotten - when >the replacement is inserted, the (new) card will need to be put in service >with appropriate parameters, and certainly without any intervention from >a management system. Amen. FRUs aren't config. Config tells the system how it should behave, and these rules should be self-consistent. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 10:44:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308783A6AFD; Wed, 23 Jul 2008 10:44:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1693A69C8 for ; Wed, 23 Jul 2008 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 hb7p9NWjVIVK for ; Wed, 23 Jul 2008 10:44:19 -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 074913A6907 for ; Wed, 23 Jul 2008 10:44:18 -0700 (PDT) Received: (qmail 76728 invoked from network); 23 Jul 2008 17:45:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2008 17:44:59 -0000 X-YMail-OSG: A43BMCwVM1lQ3RJmyjwPD3TOwubKg13whzWEOoqzpPPTdkAYpYMmtd4I.ObqBlSKoeVZMt9v.VFD2VPZjaPDLSj9WCmQ.SFNYSLQVqTbW2nyn.b0N5AGor9LceX9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48876E19.7090304@netconfcentral.com> Date: Wed, 23 Jul 2008 10:44:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "tom.petch" References: <200807211534.m6LFYTgv020044@idle.juniper.net> <001401c8ecdd$69804280$0601a8c0@allison> In-Reply-To: <001401c8ecdd$69804280$0601a8c0@allison> Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org tom.petch wrote: > ----- Original Message ----- > From: "Phil Shafer" > To: "David Harrington" > Cc: > Sent: Monday, July 21, 2008 5:34 PM > Subject: Re: [netmod] netmod session agendas > I don't really understand this whole thread. NETMOD has a complicated problem to solve. There exists a draft-00 for the main component, and a draft-01 for the spun-off data types. The WG has yet to meet even once. Of course the specifications are unclear. Of course they are not ready to be training manuals for novice data modelers. People with the proper expertise to complete the WG charter items should be involved at this point, not novice data modelers. This WG will never finish anything if it has to train people how to design data modeling languages which support real world NE devices and operator requirements. I think Dave's idea of 1 session to bring more people up to speed is fine. I also think the open issue list, and the job ahead, is rather non-trivial. Anyone who thinks that we'll knock it out in 2.5 hours is not paying attention. Try 25 or 50 hours of f2f meetings. >> How about this: we take a show of hands at the start of the session >> for the number of audience members that have read the YANG spec >> (the folks that come to the meeting prepared) who didn't attend the >> OPS-AREA boot camp or BOF (who already know what we're doing). If >> this group is sufficently small, the WG chairs can decide to skip >> the training agenda items and move on into open issues and real >> work. Otherwise the work issues are pushed to Friday's session. >> We can have these training materials available (and online) and if >> they aren't needed, no problem. > > There seems to be an assumption here that reading the YANG spec will obviate the > need for training, something of which I have yet to be convinced:-) Look at > dbh's list, and tell me where the answers are > in the YANG spec: eg > > how are modules defined? > how are namespaces handled? > how are standard and proprietary modules differentiated? > If you are the editor for a WG model, how do you get a namespace for > your module? > If you are the editor for a proprietary model, how do you define a > neamspace? > What naming conventions should be used for standard and proprietary > objects? > > Do you notice something? There is an awful lot of names and namespaces, > something that XML has got badly wrong (IMHO) and which I am unclear how much > YANG has improved on. But reading 263kbyte of the YANG spec does not enlighten > me > much:-( What is the alternative? OIDs? At least YANG abstracts away the namespace by equating it with the module naming scope. At least XPath absolute paths are readable, and happen to look exactly like the unix pathspec operators already know. > > And I would see the discussions on the list on mandatory, default, config, > presence etc as a symptom not that the YANG spec is unclear, but that the > concepts need spelling out, and I wonder if that is done, then those concepts > may turn out to be > unclear > > By contrast, I recall when first I read RFC1155 - in some ways, an analogous > document - and immediately getting a clear idea of the key concepts. > > I think you need something else, an RFC that enables people to understand the > concepts of YANG before they dive into the encyclopaedia that this I-D is. > I sure hope we don't need an RFC to read before you can read the YANG RFC. I agree that a newbie would have no hope of figuring out the complex concepts and constructs by reading the current -00 spec. We have to decide how much of the training is really in scope for the YANG standard. Maybe a companion Information RFC with lots more examples and guidelines would be a good idea, but this is not usually part of the standard. > Answers to dbh's questions would provide a start. How are modules defined? RTFM! > > Tom Petch > >> Thanks, >> Phil Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 10:52: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 7B7683A6A46; Wed, 23 Jul 2008 10:52: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 14E363A6A46 for ; Wed, 23 Jul 2008 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 heXcrAE4PA0N for ; Wed, 23 Jul 2008 10:52:13 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 20AA03A6405 for ; Wed, 23 Jul 2008 10:52:13 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 10:52:03 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 10:52:09 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 10:52:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:52:08 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6NHq7u29996; Wed, 23 Jul 2008 10:52:07 -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 m6NHn7Eu040974; Wed, 23 Jul 2008 17:49:07 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231749.m6NHn7Eu040974@idle.juniper.net> To: "tom.petch" In-reply-to: <001401c8ecdd$69804280$0601a8c0@allison> Date: Wed, 23 Jul 2008 13:49:07 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 17:52:08.0013 (UTC) FILETIME=[D3378FD0:01C8ECEC] Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "tom.petch" writes: >There seems to be an assumption here that reading the YANG spec will obviate t >he >need for training, something of which I have yet to be convinced:-) Look at >dbh's list, and tell me where the answers are >in the YANG spec: eg I think there are a lots of open questions, including many on dbh's list. My concern is that the training dbh is after is the level of "tell me what the spec says", not the "I read the spec and still have questions". >Do you notice something? There is an awful lot of names and namespaces, >something that XML has got badly wrong (IMHO) and which I am unclear how much >YANG has improved on. But reading 263kbyte of the YANG spec does not enlighten >me >much:-( We didn't fix XML namespace issues :-( >And I would see the discussions on the list on mandatory, default, config, >presence etc as a symptom not that the YANG spec is unclear, but that the >concepts need spelling out, and I wonder if that is done, then those concepts >may turn out to be >unclear The spec definitely needs work, which is my concern about burning face time on training, versus finding problems in the spec and correcting them. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 10:56: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 2F9683A69FC; Wed, 23 Jul 2008 10:56: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 186433A691A for ; Wed, 23 Jul 2008 10:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 TnoJFu2RSck2 for ; Wed, 23 Jul 2008 10:56:13 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 90DE83A6AF0 for ; Wed, 23 Jul 2008 10:56:06 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 10:52:08 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 10:56:34 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 10:56:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:56:34 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6NHuXu31490; Wed, 23 Jul 2008 10:56:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6NHrXnP041031; Wed, 23 Jul 2008 17:53:33 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231753.m6NHrXnP041031@idle.juniper.net> To: Andy Bierman In-reply-to: <488762C5.30407@netconfcentral.com> Date: Wed, 23 Jul 2008 13:53:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 17:56:34.0170 (UTC) FILETIME=[71DBE5A0:01C8ECED] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >You seem to be focusing on direct, inline definitions >without considering object reuse. When one attempts to use >groupings and containers for encapsulation and reuse, >YANG is not very powerful. These 'building block' >sort of sub-structures need to be designed independently >of the parent context. Some properties need to be inherited from >the parent node, by design. IMO, 'mandatory' is one of them. >The parent node should decide if the child node is mandatory, >not the other way around. The parent uses refinement to make child nodes mandatory. >IMO, it is more intuitive and reusable to be >able to define a container as mandatory true/false >in a top-down manner, rather than track down all the >child nodes, read all the presence-stmt clauses, >augment-when clauses, and eventually figure out >the mandatory status. > >Of course the compiler can do that fairly quickly, >but not the DM reader or writer. So you want mandatory on containers as a hint to the reader, not as this third kind of container? Would it be a compiler error to have a container that doesn't contain anything mandatory? If not, you still have to decide why you want a meaningless mandatory node. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 11:11: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 935C23A69F2; Wed, 23 Jul 2008 11:11: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 590253A69F2 for ; Wed, 23 Jul 2008 11:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTMZhcEHbW5U for ; Wed, 23 Jul 2008 11:11:23 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 887FA3A691A for ; Wed, 23 Jul 2008 11:11:23 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 11:11:11 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 11:11:11 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 11:11:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 11:05: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 m6NI5Ru35050; Wed, 23 Jul 2008 11:05: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 m6NI2QvT041216; Wed, 23 Jul 2008 18:02:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231802.m6NI2QvT041216@idle.juniper.net> To: Andy Bierman In-reply-to: <488754D2.7080106@netconfcentral.com> Date: Wed, 23 Jul 2008 14:02:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 18:05:27.0537 (UTC) FILETIME=[AFC53E10:01C8ECEE] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >ifIndex is used in lots of tables and CLI commands. I'm no IOS guru, but "lots of .. CLI commands" doesn't jibe with what I know. The ifIndex is displayed in output, but it's not config for JUNOS or IOS and IOS have knobs to force persistence, but it doesn't give a value, just "persist". >It is defined as read-only in the IF-MIB. This has >been going on for decades. Maybe it's a bad idea, but >it is current practice. Are we really somehow required to carry ifIndex into the NETCONF world? Is using interface name not acceptable? >The RMON2 protocol directory uses really complex identifiers. >The agent assigns a read-only number for shorthand use >as an index in all the read-only monitoring tables that >report data per protocol encapsulation layer. This is an SNMP hook that need not be carried forward. >I don't see ifIndex going away any time soon. >There are lots of dev-hours invested in it already. Ditto for SNMP, but there's no need to burden NETCONF with SNMP design choices. ifIndex make OIDs simpler. XML doesn't have that need. so-0/0/0.0 is simpler, more direct, more informative, and is the way config works in the real world. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 11:15: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 F26033A6AE2; Wed, 23 Jul 2008 11:15: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 8B5603A6AFE for ; Wed, 23 Jul 2008 11:15:04 -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 McwZSz8LAkrm for ; Wed, 23 Jul 2008 11:15:03 -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 B1DFA3A69F2 for ; Wed, 23 Jul 2008 11:15:03 -0700 (PDT) Received: (qmail 65807 invoked from network); 23 Jul 2008 18:15:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2008 18:15:43 -0000 X-YMail-OSG: gukXUCsVM1lxT7SKgFuLi4CegdaR2OlfCeFagd9ed905vDQOE5.y7iK2h.Cf6xQazhsxJ_tHHtbhmsJspOXPF8oRV32FyHOT6ZBV4eDIBA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4887754D.4090204@netconfcentral.com> Date: Wed, 23 Jul 2008 11:15:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807231753.m6NHrXnP041031@idle.juniper.net> In-Reply-To: <200807231753.m6NHrXnP041031@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> You seem to be focusing on direct, inline definitions >> without considering object reuse. When one attempts to use >> groupings and containers for encapsulation and reuse, >> YANG is not very powerful. These 'building block' >> sort of sub-structures need to be designed independently >> of the parent context. Some properties need to be inherited from >> the parent node, by design. IMO, 'mandatory' is one of them. >> The parent node should decide if the child node is mandatory, >> not the other way around. > > The parent uses refinement to make child nodes mandatory. As written in the -00 draft. Not cast in stone. Uses refinement is by definition not information encapsulation, and much more work than the mandatory-stmt. > >> IMO, it is more intuitive and reusable to be >> able to define a container as mandatory true/false >> in a top-down manner, rather than track down all the >> child nodes, read all the presence-stmt clauses, >> augment-when clauses, and eventually figure out >> the mandatory status. >> >> Of course the compiler can do that fairly quickly, >> but not the DM reader or writer. > > So you want mandatory on containers as a hint to the reader, not > as this third kind of container? Would it be a compiler error to > have a container that doesn't contain anything mandatory? If not, > you still have to decide why you want a meaningless mandatory node. > I want the mandatory property to be relative to the containment level, and the mandatory-stmt to be allowed in the container-stmt. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 11:22:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8963A6918; Wed, 23 Jul 2008 11:22:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3273A6918 for ; Wed, 23 Jul 2008 11:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 CDwMKfnASDqQ for ; Wed, 23 Jul 2008 11:22:56 -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 EA2DE3A67D6 for ; Wed, 23 Jul 2008 11:22:55 -0700 (PDT) Received: (qmail 66410 invoked from network); 23 Jul 2008 18:23:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2008 18:23:36 -0000 X-YMail-OSG: s5RLTGEVM1n3k8ucnVvZfPMx1idXzVOBPp10fvS.q360NW4dvks4xAoe6yvOpNtxan9HH2PyjdtoonIJfdpeqHp.sOen5dyDXyEML3EWdQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48877726.8040106@netconfcentral.com> Date: Wed, 23 Jul 2008 11:23:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807231802.m6NI2QvT041216@idle.juniper.net> In-Reply-To: <200807231802.m6NI2QvT041216@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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: >> ifIndex is used in lots of tables and CLI commands. > > I'm no IOS guru, but "lots of .. CLI commands" doesn't jibe with > what I know. The ifIndex is displayed in output, but it's not > config for JUNOS or IOS and IOS have knobs to force persistence, > but it doesn't give a value, just "persist". > >> It is defined as read-only in the IF-MIB. This has >> been going on for decades. Maybe it's a bad idea, but >> it is current practice. > > Are we really somehow required to carry ifIndex into the NETCONF > world? Is using interface name not acceptable? > >> The RMON2 protocol directory uses really complex identifiers. >> The agent assigns a read-only number for shorthand use >> as an index in all the read-only monitoring tables that >> report data per protocol encapsulation layer. > > This is an SNMP hook that need not be carried forward. > >> I don't see ifIndex going away any time soon. >> There are lots of dev-hours invested in it already. > > Ditto for SNMP, but there's no need to burden NETCONF with SNMP > design choices. ifIndex make OIDs simpler. XML doesn't have that > need. so-0/0/0.0 is simpler, more direct, > more informative, and is the way config works in the real world. > I agree we should index interfaces by name, but I also think it would be very useful to create an integrated multi-protocol NM standards suite, instead of the ad-hoc free-for-all the IETF is so good at. For example, many SMIv2-to-YANG translated lists will expect the ifIndex and other essential ifTable fields to be available. Integrating SNMP and YANG management data is a useful way to get some standard YANG content. At the current rate of delivery, the IETF will take about 140 years to have the number of standard YANG objects to match the number of standard MIB objects. > Thanks, > Phil > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 11:51: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 7D95B3A6AFC; Wed, 23 Jul 2008 11:51: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 2A1263A6AE7 for ; Wed, 23 Jul 2008 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 n-BWJUzKCwuc for ; Wed, 23 Jul 2008 11:51:33 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 53FF33A6A72 for ; Wed, 23 Jul 2008 11:51:33 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 11:52:02 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 11:52:04 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 11:52:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 11:52:03 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6NIq2u51003; Wed, 23 Jul 2008 11:52: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 m6NIn2Al041805; Wed, 23 Jul 2008 18:49:02 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807231849.m6NIn2Al041805@idle.juniper.net> To: Andy Bierman In-reply-to: <48876E19.7090304@netconfcentral.com> Date: Wed, 23 Jul 2008 14:49:02 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 18:52:03.0294 (UTC) FILETIME=[322BE7E0:01C8ECF5] Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.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: >Anyone who thinks that we'll knock it out >in 2.5 hours is not paying attention. >Try 25 or 50 hours of f2f meetings. Right, so if we spend 2.5 hours on real issues each IETF, we can plan on 20 IETFs (7 years). If we use both sessions (5 hrs) we need only 10 IETFs (3.5 years). Guess which one I'm rooting for? ;^) Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 12:07: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 B037A3A6832; Wed, 23 Jul 2008 12:07: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 0BE0C3A6832 for ; Wed, 23 Jul 2008 12:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 w-dyfyyAEB+v for ; Wed, 23 Jul 2008 12:07:36 -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 601EE3A67D6 for ; Wed, 23 Jul 2008 12:07:36 -0700 (PDT) Received: (qmail 95822 invoked from network); 23 Jul 2008 19:08:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 23 Jul 2008 19:08:17 -0000 X-YMail-OSG: TGvEwc0VM1nXHGk9tGq1oAdbv5PrM0r2OYtzkKGJ9_Sd.jL6eHWe5G59IbGoDFjbqkgwuFz5dUzcw39ub5h34jj8p7jS2O.HPlaoY0YSmw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488781A0.7020308@netconfcentral.com> Date: Wed, 23 Jul 2008 12:08:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200807231849.m6NIn2Al041805@idle.juniper.net> In-Reply-To: <200807231849.m6NIn2Al041805@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org 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: >> Anyone who thinks that we'll knock it out >> in 2.5 hours is not paying attention. >> Try 25 or 50 hours of f2f meetings. > > Right, so if we spend 2.5 hours on real issues each IETF, we can > plan on 20 IETFs (7 years). If we use both sessions (5 hrs) we > need only 10 IETFs (3.5 years). Guess which one I'm rooting for? > > ;^) > I'm OK with slideware for the missing drafts and the complex issues for the first meeting, but not for overviews of the current drafts. 2 years + a 3-day interim meeting 1 year + 2 3-day interim meetings > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 12:16: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 6A2AF3A68BC; Wed, 23 Jul 2008 12:16: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 59A6E3A6A6B for ; Wed, 23 Jul 2008 12:16:22 -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 4Tv04SN4R9K4 for ; Wed, 23 Jul 2008 12:16:21 -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 54E9B3A68BC for ; Wed, 23 Jul 2008 12:16:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=S0v8lj3y+0UGZLximaZ+Q73x493GP7ABqBu5N5CkaQ2nG9IchZYbUPUT+SfBUTWd; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.145.179] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KLjpg-0000JY-C7 for netmod@ietf.org; Wed, 23 Jul 2008 15:17:04 -0400 Message-ID: <002001c8ecf8$b97bc500$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200807231727.m6NHR1qT040572@idle.juniper.net> Date: Wed, 23 Jul 2008 12:17: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3890305cc9109fcaabe58c05284a35f77350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.145.179 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: "Randy Presuhn" > Cc: > Sent: Wednesday, July 23, 2008 10:27 AM > Subject: Re: [netmod] Why constrain keyref? ... > >Pulling out a working (or failed) > >line card should not cause that card's configuration to be forgotten - when > >the replacement is inserted, the (new) card will need to be put in service > >with appropriate parameters, and certainly without any intervention from > >a management system. > > Amen. FRUs aren't config. Config tells the system how it > should behave, and these rules should be self-consistent. But this is the crux of the need to look at validation in terms of phases. The configuration for that card is operationally valid IFF the card inserted into that slot is of a type compatible with that configuration. If someone replaces a failed RS-232 mux card with an ethernet card, the old configuration (which is what the system should have remembered) won't work. However, if "referential integrity" causes that portion of the configuration to be forgotten / deleted, then when the tech finally does insert the correct card type the system will still not be fully operational. The point where we agree is that there are cases where *self*-consistency constraints are possible and useful. Where I think we disagree is the question of just how much ground is covered by such constraints. If onw comes from the world of dynamically reconfigurable systems with a variety of hot-swappable hardware and software components, or distributed processing elements collaborating through some kind of network (even if that network is the box's backplane) the "self- consistency" constraints are much "softer", as someone else put it. The simply can't be fully evaluated without looking at a hardware configuration, and possibly with collaboration from other systems. Detection of such a constraint violation probably will initiate some hardware / software action, such as telling a tech pull the offending card or announcing a run-time configuration conflict, but it almost never would be correct for it to initiate side-effects like deleting the "offending" portions of the configuration or declaring it invalid. In a sense the configuration is operationally invalid, because it isn't working at the moment, but it doesn't mean that there is anything at all wrong with the configuration itself. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 14:44: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 553AB28C1BD; Wed, 23 Jul 2008 14:44: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 3469F28C1B8 for ; Wed, 23 Jul 2008 14:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 kPWhdUBOgZTV for ; Wed, 23 Jul 2008 14:44:04 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id AE9F928C1B7 for ; Wed, 23 Jul 2008 14:44:03 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 14:44:37 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 14:44:37 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 14:44:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 14:44: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 m6NLiau02675; Wed, 23 Jul 2008 14:44:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6NLfaRB043066; Wed, 23 Jul 2008 21:41:36 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807232141.m6NLfaRB043066@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <002001c8ecf8$b97bc500$6801a8c0@oemcomputer> Date: Wed, 23 Jul 2008 17:41:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2008 21:44:36.0388 (UTC) FILETIME=[4D18AE40:01C8ED0D] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >But this is the crux of the need to look at validation in terms of >phases. The canmod-dsdl draft defines its phases as: - fragment phase (is the xml in the operation valid?) - standard phase (is the entire config valid with the exception of keyrefs?) - full validation phase (is the entire config valid including keyrefs?) I don't see the value in avoiding the keyref tests. If they aren't enforced at commit time, you are commiting a configuration that doesn't pass referential integrity tests. If you don't enforce these rules during commit, how can you come back and enforce them later? Are you seeing these rules as "lint" (where you allow mistakes during software development and just plan on fixing them before the project ships)? To me, the three different phases in the life of config are: - when you enter it (could the data ever be valid?) - validation/commit (is the entire config valid?) - event (how do I do what I need to do?) At event may be something like: - sw install (added new IDP module) - FRU install (added new PIC) - protocol event (received BGP connection from 10.1.2.3) - internal event (cron rotates log files) In each of these events, the system needs instructions to know how it should perform. Should it enable IDP? Should it put an IP address on the PIC? Should it close the BGP connection? Should it discard old log files? >The configuration for that card is operationally valid IFF >the card inserted into that slot is of a type compatible with that >configuration. If someone replaces a failed RS-232 mux card with an ethernet >card, the old configuration (which is what the system should have >remembered) won't work. However, if "referential integrity" causes >that portion of the configuration to be forgotten / deleted, then when >the tech finally does insert the correct card type the system will >still not be fully operational. "forgotten / deleted"? Who would do this? Config shouldn't be discarded, but should only be implemented when it matches the installed hardware. You can pre-configure multiple cards, like: so-0/0/0 sonet ... at-0/0/0 atm ... ge-0/0/0 gig-e ... All three co-exist peacefully in the configuration, and when a PIC is inserted, the proper config is selected and implemented on the PIC. >The point where we agree is that there are cases where *self*-consistency >constraints are possible and useful. Where I think we disagree is the >question of just how much ground is covered by such constraints. If >onw comes from the world of dynamically reconfigurable systems with >a variety of hot-swappable hardware and software components, or >distributed processing elements collaborating through some kind of >network (even if that network is the box's backplane) the "self- >consistency" constraints are much "softer", as someone else put it. The odd part is that I come from that hot-swap world, but I have strong constraints. And customers that want stronger constraint. Configuration mistakes are expensive. Avoiding them saves money. >Detection of such a constraint violation probably will initiate some >hardware / software action, such as telling a tech pull the offending >card or announcing a run-time configuration conflict, but it >almost never would be correct for it to initiate side-effects like >deleting the "offending" portions of the configuration or declaring it >invalid. In a sense the configuration is operationally invalid, because >it isn't working at the moment, but it doesn't mean that there is >anything at all wrong with the configuration itself. There must be some confusion. I'm not suggesting deleting configuration. I ignore configuration for FRUs that don't exist. If you config a sonet card, an ATM card, and a Gig-E card all in the same slot, the config is will only drive the configuration of a PIC of that type. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 22:45: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 CCF633A6802; Wed, 23 Jul 2008 22:45: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 50AB13A6802 for ; Wed, 23 Jul 2008 22:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.449, 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 SscQG3i2d7-p for ; Wed, 23 Jul 2008 22:45:45 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id AD1903A67EF for ; Wed, 23 Jul 2008 22:45:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KhSQaAl0Rw/JPI6JbYKbER9lCUZ850KQ1BzBeZRAdolUp64M/2dpNUbsw0TwwHUJ; 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 [66.167.206.160] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KLtel-0000YH-GA for netmod@ietf.org; Thu, 24 Jul 2008 01:46:27 -0400 Message-ID: <000801c8ed50$a76a7e80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200807232141.m6NLfaRB043066@idle.juniper.net> Date: Wed, 23 Jul 2008 22:46:42 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3c5d9c28d2f5b1d02a218465c56f55aa7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.160 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: "Randy Presuhn" > Cc: > Sent: Wednesday, July 23, 2008 2:41 PM > Subject: Re: [netmod] Why constrain keyref? > > "Randy Presuhn" writes: > >But this is the crux of the need to look at validation in terms of > >phases. > > The canmod-dsdl draft defines its phases as: > - fragment phase (is the xml in the operation valid?) > - standard phase (is the entire config valid with the exception of keyrefs?) > - full validation phase (is the entire config valid including keyrefs?) There's more. Additional phases (which may be beyond the scope of netconf, but which are nonetheless operationally useful) include validation with respect to the hardware configuration, installed / available software, and "peer" components on other systems. > I don't see the value in avoiding the keyref tests. If they aren't > enforced at commit time, you are commiting a configuration that > doesn't pass referential integrity tests. If you don't enforce > these rules during commit, how can you come back and enforce them > later? Are you seeing these rules as "lint" (where you allow > mistakes during software development and just plan on fixing them > before the project ships)? No, my concern is that these tests are both too little and too much, depending on what one is trying to do. They are too much when provisioning a system, and too little when one is concerned whether the proposed configuration will actually work given the constellation of installed hardware / software / firmware. > To me, the three different phases in the life of config are: > - when you enter it (could the data ever be valid?) > - validation/commit (is the entire config valid?) We need to nail down what "valid" means here... > - event (how do I do what I need to do?) > > At event may be something like: > - sw install (added new IDP module) > - FRU install (added new PIC) > - protocol event (received BGP connection from 10.1.2.3) > - internal event (cron rotates log files) > > In each of these events, the system needs instructions to > know how it should perform. Should it enable IDP? Should > it put an IP address on the PIC? Should it close the BGP > connection? Should it discard old log files? > > >The configuration for that card is operationally valid IFF > >the card inserted into that slot is of a type compatible with that > >configuration. If someone replaces a failed RS-232 mux card with an ethernet > >card, the old configuration (which is what the system should have > >remembered) won't work. However, if "referential integrity" causes > >that portion of the configuration to be forgotten / deleted, then when > >the tech finally does insert the correct card type the system will > >still not be fully operational. > > "forgotten / deleted"? Who would do this? No one in their right mind, I hope. > Config shouldn't be discarded, but should only be implemented when > it matches the installed hardware. You can pre-configure multiple > cards, like: > > > > so-0/0/0 > sonet > ... > > > at-0/0/0 > atm > ... > > > ge-0/0/0 > gig-e > ... > > > > All three co-exist peacefully in the configuration, and when > a PIC is inserted, the proper config is selected and implemented > on the PIC. This is an interesting feature. How does the software responsible for validating the configuration know that this sort of conditional behaviour is what is intended, and that it's not a configuration error? I would have thought that this was precisely the kind of thing that should be rejected by a self-consistency check. > >The point where we agree is that there are cases where *self*-consistency > >constraints are possible and useful. Where I think we disagree is the > >question of just how much ground is covered by such constraints. If > >onw comes from the world of dynamically reconfigurable systems with > >a variety of hot-swappable hardware and software components, or > >distributed processing elements collaborating through some kind of > >network (even if that network is the box's backplane) the "self- > >consistency" constraints are much "softer", as someone else put it. > > The odd part is that I come from that hot-swap world, but I > have strong constraints. And customers that want stronger > constraint. Configuration mistakes are expensive. Avoiding > them saves money. > > >Detection of such a constraint violation probably will initiate some > >hardware / software action, such as telling a tech pull the offending > >card or announcing a run-time configuration conflict, but it > >almost never would be correct for it to initiate side-effects like > >deleting the "offending" portions of the configuration or declaring it > >invalid. In a sense the configuration is operationally invalid, because > >it isn't working at the moment, but it doesn't mean that there is > >anything at all wrong with the configuration itself. > > There must be some confusion. I'm not suggesting deleting > configuration. I ignore configuration for FRUs that don't > exist. *Some* validation of that configuration is still possible, to the extent that one can figure out what schema to use to validate it. But if there's another chunk of configuration that refers to one of these "contingent" bits that's being "ignored" because the card isn't there at the moment, what happens? I still think it's simplest to just say what it means to have an "unsatisfied" pointer. > If you config a sonet card, an ATM card, and a Gig-E > card all in the same slot, the config is will only drive the > configuration of a PIC of that type. Concrete example, using my understanding of your framework: I have a performance monitor piece of software. (let's not call it RMON) It is configured to monitor specific interface characterstics. The exact bits might be different for sonet, ATM, and GIG-E. it would be configured to monitor all the possible cards described in your example slot above. This would seem to be a perfectly valid configuration, even though at least 2 of the three pointers would be in some sense bogus at any point in time. Though I can see the value of having this "contingent" configuration capability, I can also see the value of being able to enforce a discipline of allowing only a single configuration for a particular slot - particularly when that slot corresponds to particular physical connectors, etc. It's not clear to me how one indicates which is the desired behaviour for a slot. Would this be done in Yang or by some other means? Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 23:43: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 119903A693A; Wed, 23 Jul 2008 23:43: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 2A3ED3A693A for ; Wed, 23 Jul 2008 23:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3-CIp5SiTi9 for ; Wed, 23 Jul 2008 23:43:38 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id B84103A67A4 for ; Wed, 23 Jul 2008 23:43:37 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 23:44:18 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 23:43:37 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 23:43:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 23:43: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 m6O6hau30642; Wed, 23 Jul 2008 23:43:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6O6eaNk048651; Thu, 24 Jul 2008 06:40:36 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807240640.m6O6eaNk048651@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <000801c8ed50$a76a7e80$6801a8c0@oemcomputer> Date: Thu, 24 Jul 2008 02:40:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jul 2008 06:43:36.0902 (UTC) FILETIME=[998B7E60:01C8ED58] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >*Some* validation of that configuration is still possible, to >the extent that one can figure out what schema to use to validate >it. But if there's another chunk of configuration that refers >to one of these "contingent" bits that's being "ignored" because >the card isn't there at the moment, what happens? I still think >it's simplest to just say what it means to have an "unsatisfied" >pointer. But how does one determine the when an "unsatified" reference is just a typo? Yes, it's simpler for software to say "That's not a problem and the user will figure it out eventually", but it's not simpler for the user. We use languages that require us to declare variables so that we can detect errors as soon as possible. Operators are the same. Telling them "error: filter 'customer-intput' is not defined at commit time beats leaving them on their own to find that extra 't'. >Though I can see the value of having this "contingent" configuration >capability, I can also see the value of being able to enforce a >discipline of allowing only a single configuration for a particular >slot - particularly when that slot corresponds to particular physical >connectors, etc. It's not clear to me how one indicates which is the >desired behaviour for a slot. Would this be done in Yang or by some >other means? The key idea is that the configuration needs to be valid regardless of what cards are plugged in. Once you buy this, you buy that you can't have config reference non-config, since it's dynamic. It doesn't really matter that you buy into the JUNOS/IOS pre-provisioning scheme/"contingent configuration". If you want a rule that says only one interface can be configured for each card slot, that's fine. You are still only constaining the configuration ('must count(../*/slot[name = .]) == 1'?), and this constraint does not refer to non-config data. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 23 23:52: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 25F0A3A6966; Wed, 23 Jul 2008 23:52: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 AAE7B3A6966 for ; Wed, 23 Jul 2008 23:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=0.045, 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 kmJZgow8ohe3 for ; Wed, 23 Jul 2008 23:52:56 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E28083A67A4 for ; Wed, 23 Jul 2008 23:52:55 -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 BF0BBD800D2 for ; Thu, 24 Jul 2008 08:53:39 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200807231727.m6NHR1qT040572@idle.juniper.net> References: <200807231727.m6NHR1qT040572@idle.juniper.net> Organization: CESNET Date: Thu, 24 Jul 2008 08:53:38 +0200 Message-Id: <1216882418.6678.6.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMjMuIDA3LiAyMDA4IHYgMTM6MjcgLTA0MDA6Cj4gVGhp cyBpcyB0aGUgbG9naWMgYmVoaW5kIGxhbmd1YWdlcyB0aGF0IGRvbid0IHJlcXVpcmUgeW91IHRv IGRlY2xhcmUKPiB2YXJpYWJsZXMgYmVmb3JlIHVzaW5nIHRoZW0sIGxpa2UgUGVybC4gIEFuZCwg bGlrZSBQZXJsLCB1c2Vycwo+IHJldm9sdCBhbmQgd2FudCBzdHJvbmdlciBlbmZvcmNlbWVudCB0 byBhdm9pZCBzY2VuYXJpb3Mgd2hlcmUgdGhleQo+IG1ha2UgYSB0eXBvIGFuZCB0aGVpciBwcm9n cmFtIHN0b3BzIHdvcmtpbmcuCgpJIGJlZyB0byBkaWZmZXIuIEkgZG9uJ3QgdXNlIFBlcmwgYW55 bW9yZSBidXQgaW4gUHl0aG9uIGl0J3MgdGhlIHNhbWUKYW5kIEkgaGF2ZW4ndCBzZWVuIGFueSBQ eXRob24gcHJvZ3JhbW1lciByZXZvbHRpbmcuIEFuZCBHb29nbGUgZm9yCmV4YW1wbGUgaXMgZXNz ZW50aWFsbHkgYSBQeXRob24gc2hvcC4gSXQncyBtb3JlIGFuIGlzc3VlIGZvciBsYW5ndWFnZQps YXd5ZXJzLCBpbiBwcmFjdGljYWwgcHJvZ3JhbW1pbmcgdGhpcyBpcyB2ZXJ5IGNvbnZlbmllbnQu CgpMYWRhCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBt YWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Jul 24 00:14: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 D53933A693B; Thu, 24 Jul 2008 00:14: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 6E2EC3A693B for ; Thu, 24 Jul 2008 00:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=0.043, 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 6I5A02jVp1HD for ; Thu, 24 Jul 2008 00:13:59 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A13B93A68B7 for ; Thu, 24 Jul 2008 00:13:59 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A8423D800CA for ; Thu, 24 Jul 2008 09:14:39 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200807232141.m6NLfaRB043066@idle.juniper.net> References: <200807232141.m6NLfaRB043066@idle.juniper.net> Organization: CESNET Date: Thu, 24 Jul 2008 09:14:39 +0200 Message-Id: <1216883679.6678.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMjMuIDA3LiAyMDA4IHYgMTc6NDEgLTA0MDA6Cj4gIlJh bmR5IFByZXN1aG4iIHdyaXRlczoKPiA+QnV0IHRoaXMgaXMgdGhlIGNydXggb2YgdGhlIG5lZWQg dG8gbG9vayBhdCB2YWxpZGF0aW9uIGluIHRlcm1zIG9mCj4gPnBoYXNlcy4KPiAKPiBUaGUgY2Fu bW9kLWRzZGwgZHJhZnQgZGVmaW5lcyBpdHMgcGhhc2VzIGFzOgo+IC0gZnJhZ21lbnQgcGhhc2Ug KGlzIHRoZSB4bWwgaW4gdGhlIG9wZXJhdGlvbiB2YWxpZD8pCj4gLSBzdGFuZGFyZCBwaGFzZSAo aXMgdGhlIGVudGlyZSBjb25maWcgdmFsaWQgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIGtleXJlZnM/ KQo+IC0gZnVsbCB2YWxpZGF0aW9uIHBoYXNlIChpcyB0aGUgZW50aXJlIGNvbmZpZyB2YWxpZCBp bmNsdWRpbmcga2V5cmVmcz8pCj4gCj4gSSBkb24ndCBzZWUgdGhlIHZhbHVlIGluIGF2b2lkaW5n IHRoZSBrZXlyZWYgdGVzdHMuICBJZiB0aGV5IGFyZW4ndAo+IGVuZm9yY2VkIGF0IGNvbW1pdCB0 aW1lLCB5b3UgYXJlIGNvbW1pdGluZyBhIGNvbmZpZ3VyYXRpb24gdGhhdAo+IGRvZXNuJ3QgcGFz cyByZWZlcmVudGlhbCBpbnRlZ3JpdHkgdGVzdHMuICBJZiB5b3UgZG9uJ3QgZW5mb3JjZQoKVGhp cyBpcyBhIHByb2JsZW0gb25seSBmb3IgdGhlICJydW5uaW5nIiBjb25maWd1cmF0aW9uLiBUaGUg ImNhbmRpZGF0ZSIKY29uZmlndXJhdGlvbiBtdXN0IGFsbG93IGZvciByZWZlcmVudGlhbCBpbmNv bnNpc3RlbmNpZXMgYW5kICJzdGFydHVwIgpwcm9iYWJseSB0b28uCgpMYWRhCgotLSAKTGFkaXNs YXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9k QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Jul 24 00:41: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 E51803A691C; Thu, 24 Jul 2008 00:41: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 09CEC3A691C for ; Thu, 24 Jul 2008 00:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Q-EZ2KaNRhIS for ; Thu, 24 Jul 2008 00:41:41 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 7D85A3A67A4 for ; Thu, 24 Jul 2008 00:41:37 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jul 2008 00:41:50 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 00:41:52 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 00:41:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 00:36:23 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6O7aMu44974; Thu, 24 Jul 2008 00:36:22 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6O7XMew049053; Thu, 24 Jul 2008 07:33:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807240733.m6O7XMew049053@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1216882418.6678.6.camel@missotis> Date: Thu, 24 Jul 2008 03:33:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jul 2008 07:36:23.0383 (UTC) FILETIME=[F8EA2670:01C8ED5F] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >I beg to differ. I don't use Perl anymore but in Python it's the same >and I haven't seen any Python programmer revolting. And Google for >example is essentially a Python shop. It's more an issue for language >lawyers, in practical programming this is very convenient. Python doesn't have "use strict" yet, so folks use lint-style tools like PyChecker: http://pychecker.sourceforge.net/ Hmmm... looks like you can now add "import pychecker.checker" to your code now, in a more 'use strict' manner. Point is that no one likes getting bitten by minor dumb mistakes so we teach computers to catch these for us. Detecting typos as early as possible reduces the cost of mistakes and can eliminates some classes of errors completely. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 24 00:41: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 38CF03A6966; Thu, 24 Jul 2008 00:41: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 17E3D3A6966 for ; Thu, 24 Jul 2008 00:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jg3pdFTay4K for ; Thu, 24 Jul 2008 00:41:42 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id C52DB3A6837 for ; Thu, 24 Jul 2008 00:41:39 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Jul 2008 00:41:50 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 00:41:55 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 00:41:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 00:40:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6O7eju46230; Thu, 24 Jul 2008 00:40:45 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6O7bjqN049091; Thu, 24 Jul 2008 07:37:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807240737.m6O7bjqN049091@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1216883679.6678.13.camel@missotis> Date: Thu, 24 Jul 2008 03:37:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Jul 2008 07:40:46.0189 (UTC) FILETIME=[958F29D0:01C8ED60] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >This is a problem only for the "running" configuration. The "candidate" >configuration must allow for referential inconsistencies and "startup" >probably too. Candidate delays validation until commit time, so you can have inconsistencies that are resolved before commit. Startup behaves in a third way, since you can't edit startup. What you copy to it is that you get. If you copy a config with inconsistencies, you should avoid rebooting. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 24 00:48: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 38FE73A6979; Thu, 24 Jul 2008 00:48: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 040C83A6979 for ; Thu, 24 Jul 2008 00:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.041, 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 viCmAdE6DKGi for ; Thu, 24 Jul 2008 00:48:00 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 225A63A6972 for ; Thu, 24 Jul 2008 00:48:00 -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 19D98D800C0; Thu, 24 Jul 2008 09:48:44 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200807240737.m6O7bjqN049091@idle.juniper.net> References: <200807240737.m6O7bjqN049091@idle.juniper.net> Organization: CESNET Date: Thu, 24 Jul 2008 09:48:43 +0200 Message-Id: <1216885723.6678.21.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDI0LiAwNy4gMjAwOCB2IDAzOjM3IC0wNDAwOgo+IExh ZGlzbGF2IExob3RrYSB3cml0ZXM6Cj4gPlRoaXMgaXMgYSBwcm9ibGVtIG9ubHkgZm9yIHRoZSAi cnVubmluZyIgY29uZmlndXJhdGlvbi4gVGhlICJjYW5kaWRhdGUiCj4gPmNvbmZpZ3VyYXRpb24g bXVzdCBhbGxvdyBmb3IgcmVmZXJlbnRpYWwgaW5jb25zaXN0ZW5jaWVzIGFuZCAic3RhcnR1cCIK PiA+cHJvYmFibHkgdG9vLgo+IAo+IENhbmRpZGF0ZSBkZWxheXMgdmFsaWRhdGlvbiB1bnRpbCBj b21taXQgdGltZSwgc28geW91IGNhbiBoYXZlCgpHcmFtbWFyLCBkYXRhdHlwZSB2YWxpZGF0aW9u IGFuZCBzZW1hbnRpYyBjb25zdHJhaW50cyBjYW4gYmUgcGVyZm9ybWVkCm9uIGNhbmRpZGF0ZSBh cyB3ZWxsLiBUaGlzIGlzIGV4YWN0bHkgd2hhdCB0aGUgdmFsaWRhdGlvbiBwaGFzZXMgYXJlCmFi b3V0LgoKTGFkYQoKPiBpbmNvbnNpc3RlbmNpZXMgdGhhdCBhcmUgcmVzb2x2ZWQgYmVmb3JlIGNv bW1pdC4gIFN0YXJ0dXAgYmVoYXZlcwo+IGluIGEgdGhpcmQgd2F5LCBzaW5jZSB5b3UgY2FuJ3Qg ZWRpdCBzdGFydHVwLiAgV2hhdCB5b3UgY29weSB0byBpdAo+IGlzIHRoYXQgeW91IGdldC4gIElm IHlvdSBjb3B5IGEgY29uZmlnIHdpdGggaW5jb25zaXN0ZW5jaWVzLCB5b3UKPiBzaG91bGQgYXZv aWQgcmVib290aW5nLgo+IAo+IFRoYW5rcywKPiAgUGhpbAotLSAKTGFkaXNsYXYgTGhvdGthLCBD RVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Jul 24 00:59: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 CB6863A697C; Thu, 24 Jul 2008 00:59: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 E0DAF3A6902 for ; Thu, 24 Jul 2008 00:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=0.039, 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 jBV+W62h8oKC for ; Thu, 24 Jul 2008 00:59:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 16E963A6966 for ; Thu, 24 Jul 2008 00:59: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 6ACC3D800C0; Thu, 24 Jul 2008 10:00:42 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200807240733.m6O7XMew049053@idle.juniper.net> References: <200807240733.m6O7XMew049053@idle.juniper.net> Organization: CESNET Date: Thu, 24 Jul 2008 10:00:41 +0200 Message-Id: <1216886441.6678.30.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgxIx0IDI0LiAwNy4gMjAwOCB2IDAzOjMzIC0wNDAwOgo+IExh ZGlzbGF2IExob3RrYSB3cml0ZXM6Cj4gPkkgYmVnIHRvIGRpZmZlci4gSSBkb24ndCB1c2UgUGVy bCBhbnltb3JlIGJ1dCBpbiBQeXRob24gaXQncyB0aGUgc2FtZQo+ID5hbmQgSSBoYXZlbid0IHNl ZW4gYW55IFB5dGhvbiBwcm9ncmFtbWVyIHJldm9sdGluZy4gQW5kIEdvb2dsZSBmb3IKPiA+ZXhh bXBsZSBpcyBlc3NlbnRpYWxseSBhIFB5dGhvbiBzaG9wLiBJdCdzIG1vcmUgYW4gaXNzdWUgZm9y IGxhbmd1YWdlCj4gPmxhd3llcnMsIGluIHByYWN0aWNhbCBwcm9ncmFtbWluZyB0aGlzIGlzIHZl cnkgY29udmVuaWVudC4KPiAKPiBQeXRob24gZG9lc24ndCBoYXZlICJ1c2Ugc3RyaWN0IiB5ZXQs IHNvIGZvbGtzIHVzZSBsaW50LXN0eWxlIHRvb2xzCj4gbGlrZSBQeUNoZWNrZXI6CgpQZW9wbGUg dXNlIGxpbnQgZm9yIEMgY29kZSwgdG9vLiBQeWNoZWNrZXIgYnV5cyB5b3Ugbm90aGluZyBoZXJl IC0gaXQKd2lsbCBvbmx5IHRlbGwgeW91IHRoYXQgeW91IHVzZSBhbiB1bmluaXRpYWxpemVkIHZh cmlhYmxlLCBidXQgUHl0aG9uCmNvbXBpbGVyIHdpbGwgZG8gdGhlIHNhbWUuCgo+IAo+IFBvaW50 IGlzIHRoYXQgbm8gb25lIGxpa2VzIGdldHRpbmcgYml0dGVuIGJ5IG1pbm9yIGR1bWIgbWlzdGFr ZXMKCkkgcHJlZmVyIGdldHRpbmcgb2NjYXNzaW9uYWxseSBiaXR0ZW4gYnkgbWlub3IgZHVtYiBt aXN0YWtlcyB0aGF0IGFyZQphbG1vc3QgYWx3YXlzIGNhdWdodCBieSB0aGUgY29tcGlsZXIgYW55 d2F5IHRoYW4gYmVpbmcgZm9yY2VkIHRvIHdyaXRlCmRlY2xhcmF0aW9ucyBmb3IgYWxsIHZhcmlh Ymxlcy4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRF OEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0 bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Jul 24 06:03: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 883763A69D8; Thu, 24 Jul 2008 06:03: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 6D14D3A69E3 for ; Thu, 24 Jul 2008 06:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 fBtBrp1aeA5q for ; Thu, 24 Jul 2008 06:03:51 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 83ABF3A6947 for ; Thu, 24 Jul 2008 06:03:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,246,1215403200"; d="scan'208";a="128487018" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jul 2008 09:04:34 -0400 X-IronPort-AV: E=Sophos;i="4.31,246,1215403200"; d="scan'208";a="241835618" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jul 2008 09:04:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 15:04:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: date of initial revision of module yang-types Thread-Index: AcjtjdBjCW5FkRZnSJeRuOOjal6jyg== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] date of initial revision of module yang-types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Maybe somebody already saw this. In draft-schoenw-netmod-yang-types-01.txt, Section 3 in module yang-types we have revision 2009-05-22 { description "Initial revision."; Assuming Juergen did not use a time machine, this needs to be corrected. Is the date of further revisions checked to be successive to the initial revision date? Maybe parsers need to check dates versus current. Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 24 06:35:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D42C3A68DE; Thu, 24 Jul 2008 06:35:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9F73A67F8 for ; Thu, 24 Jul 2008 06:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 ZJxI-CH3B2OO for ; Thu, 24 Jul 2008 06:35:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C03DE3A68DE for ; Thu, 24 Jul 2008 06:35:22 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27CD1C001D; Thu, 24 Jul 2008 15:36: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 br6vVcyzm8ne; Thu, 24 Jul 2008 15:36:01 +0200 (CEST) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0D5DC0038; Thu, 24 Jul 2008 15:36:00 +0200 (CEST) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id D8771674821; Thu, 24 Jul 2008 15:35:59 +0200 (CEST) Date: Thu, 24 Jul 2008 15:35:59 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080724133559.GD948@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Romascanu, Dan (Dan)" , netmod@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] date of initial revision of module yang-types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thu, Jul 24, 2008 at 03:04:32PM +0200, Romascanu, Dan (Dan) wrote: > Maybe somebody already saw this. In > draft-schoenw-netmod-yang-types-01.txt, Section 3 in module yang-types > we have > > revision 2009-05-22 { > description "Initial revision."; > > Assuming Juergen did not use a time machine, this needs to be corrected. This has already been reported and is already fixed in my sources. /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 Jul 24 08:57: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 165C63A689A; Thu, 24 Jul 2008 08:57: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 79F523A689A for ; Thu, 24 Jul 2008 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 DGP3g92SXjaW for ; Thu, 24 Jul 2008 08:57:53 -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 8222F3A6876 for ; Thu, 24 Jul 2008 08:57:53 -0700 (PDT) Received: (qmail 30501 invoked from network); 24 Jul 2008 15:58:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 24 Jul 2008 15:58:36 -0000 X-YMail-OSG: Zm0b5oAVM1l4W2kamKTKINu.rZuRwVPmC6lTftK_OJOUBNjEPDkg3q8O.CJQPjeCJpjjgc6QBcGUBapB4qCXm7GynQCJvBeGq14osY4DKI_mH12VGmGzgXPuXjkl X-Yahoo-Newman-Property: ymail-3 Message-ID: <4888A6A9.5010704@netconfcentral.com> Date: Thu, 24 Jul 2008 08:58:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200807240733.m6O7XMew049053@idle.juniper.net> <1216886441.6678.30.camel@missotis> In-Reply-To: <1216886441.6678.30.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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+IFBoaWwgU2hhZmVyIHDDrcWhZSB2IMSMdCAyNC4gMDcu IDIwMDggdiAwMzozMyAtMDQwMDoKPj4gTGFkaXNsYXYgTGhvdGthIHdyaXRlczoKPj4+IEkgYmVn IHRvIGRpZmZlci4gSSBkb24ndCB1c2UgUGVybCBhbnltb3JlIGJ1dCBpbiBQeXRob24gaXQncyB0 aGUgc2FtZQo+Pj4gYW5kIEkgaGF2ZW4ndCBzZWVuIGFueSBQeXRob24gcHJvZ3JhbW1lciByZXZv bHRpbmcuIEFuZCBHb29nbGUgZm9yCj4+PiBleGFtcGxlIGlzIGVzc2VudGlhbGx5IGEgUHl0aG9u IHNob3AuIEl0J3MgbW9yZSBhbiBpc3N1ZSBmb3IgbGFuZ3VhZ2UKPj4+IGxhd3llcnMsIGluIHBy YWN0aWNhbCBwcm9ncmFtbWluZyB0aGlzIGlzIHZlcnkgY29udmVuaWVudC4KPj4gUHl0aG9uIGRv ZXNuJ3QgaGF2ZSAidXNlIHN0cmljdCIgeWV0LCBzbyBmb2xrcyB1c2UgbGludC1zdHlsZSB0b29s cwo+PiBsaWtlIFB5Q2hlY2tlcjoKPiAKPiBQZW9wbGUgdXNlIGxpbnQgZm9yIEMgY29kZSwgdG9v LiBQeWNoZWNrZXIgYnV5cyB5b3Ugbm90aGluZyBoZXJlIC0gaXQKPiB3aWxsIG9ubHkgdGVsbCB5 b3UgdGhhdCB5b3UgdXNlIGFuIHVuaW5pdGlhbGl6ZWQgdmFyaWFibGUsIGJ1dCBQeXRob24KPiBj b21waWxlciB3aWxsIGRvIHRoZSBzYW1lLgo+IAo+PiBQb2ludCBpcyB0aGF0IG5vIG9uZSBsaWtl cyBnZXR0aW5nIGJpdHRlbiBieSBtaW5vciBkdW1iIG1pc3Rha2VzCj4gCj4gSSBwcmVmZXIgZ2V0 dGluZyBvY2Nhc3Npb25hbGx5IGJpdHRlbiBieSBtaW5vciBkdW1iIG1pc3Rha2VzIHRoYXQgYXJl Cj4gYWxtb3N0IGFsd2F5cyBjYXVnaHQgYnkgdGhlIGNvbXBpbGVyIGFueXdheSB0aGFuIGJlaW5n IGZvcmNlZCB0byB3cml0ZQo+IGRlY2xhcmF0aW9ucyBmb3IgYWxsIHZhcmlhYmxlcy4KPiAKCkFj dHVhbGx5LCB0aGUgcHl0aG9uIGNvbXBpbGVyIHdpbGwgYWNjZXB0IGFsbCBraW5kcwpvZiAnd3Jv bmcgY29kZScsIHN1Y2ggYXMgZnVuY3Rpb24gY2FsbHMsCndoaWNoIG1pZ2h0IGJlIHdlbGwtZm9y bWVkIFB5dGhvbi4KVGhlIGludGVycHJldGVyIHdvbid0IHZhbGlkYXRlIHRoYXQgcGllY2Ugb2Yg Y29kZSB1bmxlc3MgYW5kCnVudGlsIGl0IGlzIGNhbGxlZC4gIFl1Y2guCgpBcyBhIEMgcHJvZ3Jh bW1lciBuZXcgdG8gUHl0aG9uLCBJIG11Y2ggcHJlZmVyIHRoZSBwaWNreSBDIGNvbXBpbGVyLgpQ aGlsJ3MgYW5hbG9neSBpcyBhY3R1YWxseSByZWxldmFudCB0byBZQU5HLiAgSSB3b3VsZCBtdWNo IHJhdGhlcgpoYXZlIHRvIHRlbGwgdGhlIGNvbXBpbGVyIHdoYXQgSSBhbSBkb2luZywgcmF0aGVy IHRoYW4gaGF2ZSBpdApzaWxlbnRseSBndWVzcy4KCkkgd2FudCBrZXlyZWYgdG8gYmUgYXMgcGlj a3kgYXMgcG9zc2libGUuCkkgd2FudCBhIGRpZmZlcmVudCBjb25zdHJ1Y3QsCmZvciB0aGUgbm90 LXBpY2t5IHVzZS1jYXNlcyBsaWtlIHByZS1wcm92aXNpb25pbmcuCgpBcyBJIHN0YXRlZCBpbiBh biBlYXJsaWVyIG1haWwsIGtleXJlZiBpcyBvdmVybG9hZGVkLgpJbiB0aGlzIGNhc2UsIHRoZSBs YW5ndWFnZSBpcyBub3QgY2FwYWJsZSBvZiBkaXN0aW5ndWlzaGluZwp0aGUgb2JqZWN0IGluc3Rh bmNlIGNvbnN0cmFpbnRzIGRlc2lyZWQgYnkgdGhlIERNIHdyaXRlci4KCkVpdGhlciB3ZSBkZWNp ZGUgdGhlIHVuc3VwcG9ydGVkIGNvbnN0cmFpbnRzIGFyZSBub3QgaW1wb3J0YW50Cihub3QgbGlr ZWx5KSwgb3Igd2UgYWx0ZXIgdGhlIGxhbmd1YWdlIHRvIHByb3Blcmx5IHN1cHBvcnQKdGhlIHJl cXVpcmVtZW50cy4KCldoYXQgYWJvdXQgYWRkaW5nIGEgYm9vbGVhbiB0byB0aGUga2V5cmVmOgoK ICAgdHlwZSBrZXlyZWYgewogICAgICBwYXRoICIvc29tZS9wYXRoIjsKICAgICAgY29uc3RyYWlu ZWQgdHJ1ZTsKICAgfQoKQ29uc3RyYWluZWQgPSB0cnVlOgogICAgcGF0aCBtdXN0IG1hdGNoIGV4 aXN0aW5nIGxlYWYgb2JqZWN0LCB3aGljaCBtdXN0IGJlIGEga2V5CiAgICBrZXlyZWYgb2JqZWN0 IG11c3QgbWF0Y2ggZXhpc3RpbmcgaW5zdGFuY2VzIG9mIGtleSBvYmplY3QKICAgIGtleXJlZiBv YmplY3QgbXVzdCBtYXRjaCBjb25maWctc3RtdCBwcm9wZXJ0eQoKQ29uc3RyYWluZWQgPSBmYWxz ZToKICAgIHBhdGggbXVzdCBtYXRjaCBleGlzdGluZyBsZWFmIG9iamVjdCwgd2hpY2ggbWF5IGJl IGFueSBsZWFmCiAgICBpbnN0YW5jZSBtdXN0IGJlIHZhbGlkLCBidXQgbWF5IG5vdCBleGlzdCBh dCB0aGUgbW9tZW50CiAgICBjb25maWctc3RtdCBwcm9wZXJ0eSBkb2VzIG5vdCBoYXZlIHRvIG1h dGNoCgoKSW4gZWl0aGVyIGNhc2UsIHR5cG9zIHdpbGwgYmUgZGV0ZWN0ZWQgYnkgdGhlIGNvbXBp bGVyLgpUaGUgZGVmYXVsdCBmb3IgY29uc3RyYWluZWQgPT0gdHJ1ZSAoY3VycmVudCBzZW1hbnRp Y3MpLgoKSXMgdGhpcyBsZXNzIGNvbmZ1c2luZyB0aGFuIGFkZGluZyBhbm90aGVyIGRhdGEgdHlw ZSwgbGlrZSBsZWFmcmVmPwoKV2hhdCBhYm91dCBvdGhlciBwcm9wZXJ0aWVzIG9mIGtleXJlZj8K ICAqIElzIGl0IE9LIGZvciBhICdjdXJyZW50JyBrZXlyZWYgdG8gcG9pbnQgYXQgYSAnZGVwcmVj YXRlZCcKICAgICBvciAnb2Jzb2xldGUnIGtleT8KICAqIFdoYXQgaWYgdGhlIGtleSBpcyBjb250 cm9sbGVkIGJ5IGEgY2FwYWJpbGl0eSwgZGlmZmVyZW50CiAgICB0aGFuIHRoZSBrZXlyZWY/ICBE b2VzIHRoZSBrZXlyZWYgbmVlZCB0byBhY2NvdW50IGZvcgogICAgY2FwYWJpbGl0eS1wYXJ0aXRp b25lZCBkYXRhIG1vZGVscz8KCgo+IExhZGEKPiAKCkFuZHkKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Jul 24 10:08: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 43CE73A6831; Thu, 24 Jul 2008 10:08: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 C718A3A6831 for ; Thu, 24 Jul 2008 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.037, 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 w9j2CebvSOIR for ; Thu, 24 Jul 2008 10:08:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EECC23A6806 for ; Thu, 24 Jul 2008 10:08:05 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id BA310D800CB; Thu, 24 Jul 2008 19:08:49 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4888A6A9.5010704@netconfcentral.com> References: <200807240733.m6O7XMew049053@idle.juniper.net> <1216886441.6678.30.camel@missotis> <4888A6A9.5010704@netconfcentral.com> Organization: CESNET Date: Thu, 24 Jul 2008 19:08:50 +0200 Message-Id: <1216919330.6678.109.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAyNC4gMDcuIDIwMDggdiAwODo1OCAtMDcwMDoKPiBX aGF0IGFib3V0IGFkZGluZyBhIGJvb2xlYW4gdG8gdGhlIGtleXJlZjoKPiAKPiAgICB0eXBlIGtl eXJlZiB7Cj4gICAgICAgcGF0aCAiL3NvbWUvcGF0aCI7Cj4gICAgICAgY29uc3RyYWluZWQgdHJ1 ZTsKPiAgICB9IAo+IAo+IENvbnN0cmFpbmVkID0gdHJ1ZToKPiAgICAgcGF0aCBtdXN0IG1hdGNo IGV4aXN0aW5nIGxlYWYgb2JqZWN0LCB3aGljaCBtdXN0IGJlIGEga2V5Cj4gICAgIGtleXJlZiBv YmplY3QgbXVzdCBtYXRjaCBleGlzdGluZyBpbnN0YW5jZXMgb2Yga2V5IG9iamVjdAo+ICAgICBr ZXlyZWYgb2JqZWN0IG11c3QgbWF0Y2ggY29uZmlnLXN0bXQgcHJvcGVydHkKPiAKPiBDb25zdHJh aW5lZCA9IGZhbHNlOgo+ICAgICBwYXRoIG11c3QgbWF0Y2ggZXhpc3RpbmcgbGVhZiBvYmplY3Qs IHdoaWNoIG1heSBiZSBhbnkgbGVhZgo+ICAgICBpbnN0YW5jZSBtdXN0IGJlIHZhbGlkLCBidXQg bWF5IG5vdCBleGlzdCBhdCB0aGUgbW9tZW50Cj4gICAgIGNvbmZpZy1zdG10IHByb3BlcnR5IGRv ZXMgbm90IGhhdmUgdG8gbWF0Y2gKCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIC0gZG9lcyBpdCBt ZWFuIHRoYXQgImNvbnN0cmFpbmVkIGZhbHNlOyIgd2lsbApuZXZlciBlbmZvcmNlIHJlZmVyZW50 aWFsIGludGVncml0eSBvZiB0aGUga2V5cmVmPwrvu79JIHdvdWxkIHJhdGhlciBwcmVmZXIgdG8g aW1wbGVtZW50IHZhbGlkYXRpb24gcGhhc2VzLCBlLmcuLAoKICAgIHR5cGUga2V5cmVmIHsKICAg ICAgIHBhdGggIi9zb21lL3BhdGgiOwogICAgICAgdmFsaWRhdGlvbi1waGFzZSBmdWxsOwogICAg fQoKSGVyZSwgbWlzc2luZyB0YXJnZXQgb2YgdGhpcyBrZXlyZWYgd291bGQgcmVzdWx0IGluIGFu IGVycm9yIG9ubHkgaWYgdGhlCnZhbGlkYXRpb24gcGhhc2UgaXMgImZ1bGwiLCB3aGljaCBjb3Vs ZCBiZSB3aGVuIHZhbGlkYXRpbmcgdGhlIHJ1bm5pbmcKY29uZmlndXJhdGlvbi4gT3RoZXJ3aXNl IGp1c3QgYSB3YXJuaW5nIGNvdWxkIGJlIGlzc3VlZC4KClRoZSB2YWxpZGF0aW9uIHBoYXNlcyB3 b3VsZCBiZSBvcmRlcmVkIGxpa2Ugc3lzbG9nIHByaW9yaXRpZXMgc28gdGhhdAphbnkgcGhhc2Ug YWxzbyBpbmNsdWRlcyBhbGwgc3RyaWN0ZXIgcGhhc2VzLgoKTGFkYQoKLS0gCkxhZGlzbGF2IExo b3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jul 24 10:38: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 ACB653A6990; Thu, 24 Jul 2008 10:38: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 4E10A3A691D for ; Thu, 24 Jul 2008 10:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 2wfhRwBYXOq2 for ; Thu, 24 Jul 2008 10:38:24 -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 6025C3A6977 for ; Thu, 24 Jul 2008 10:38:24 -0700 (PDT) Received: (qmail 47042 invoked from network); 24 Jul 2008 17:39:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 24 Jul 2008 17:39:07 -0000 X-YMail-OSG: U4aZeL8VM1mAS2Oh5uvN0tSYPpY9pS8_2t1uF21JiilK8e7QIHPQbVvKemim570AyMiAMGB57NGC0vFhfpl2QHhWgpbHCP._xdw18Y5heg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4888BE38.3070207@netconfcentral.com> Date: Thu, 24 Jul 2008 10:39:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200807240733.m6O7XMew049053@idle.juniper.net> <1216886441.6678.30.camel@missotis> <4888A6A9.5010704@netconfcentral.com> <1216919330.6678.109.camel@missotis> In-Reply-To: <1216919330.6678.109.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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+IEFuZHkgQmllcm1hbiBww63FoWUgdiDEjHQgMjQuIDA3 LiAyMDA4IHYgMDg6NTggLTA3MDA6Cj4+IFdoYXQgYWJvdXQgYWRkaW5nIGEgYm9vbGVhbiB0byB0 aGUga2V5cmVmOgo+Pgo+PiAgICB0eXBlIGtleXJlZiB7Cj4+ICAgICAgIHBhdGggIi9zb21lL3Bh dGgiOwo+PiAgICAgICBjb25zdHJhaW5lZCB0cnVlOwo+PiAgICB9IAo+Pgo+PiBDb25zdHJhaW5l ZCA9IHRydWU6Cj4+ICAgICBwYXRoIG11c3QgbWF0Y2ggZXhpc3RpbmcgbGVhZiBvYmplY3QsIHdo aWNoIG11c3QgYmUgYSBrZXkKPj4gICAgIGtleXJlZiBvYmplY3QgbXVzdCBtYXRjaCBleGlzdGlu ZyBpbnN0YW5jZXMgb2Yga2V5IG9iamVjdAo+PiAgICAga2V5cmVmIG9iamVjdCBtdXN0IG1hdGNo IGNvbmZpZy1zdG10IHByb3BlcnR5Cj4+Cj4+IENvbnN0cmFpbmVkID0gZmFsc2U6Cj4+ICAgICBw YXRoIG11c3QgbWF0Y2ggZXhpc3RpbmcgbGVhZiBvYmplY3QsIHdoaWNoIG1heSBiZSBhbnkgbGVh Zgo+PiAgICAgaW5zdGFuY2UgbXVzdCBiZSB2YWxpZCwgYnV0IG1heSBub3QgZXhpc3QgYXQgdGhl IG1vbWVudAo+PiAgICAgY29uZmlnLXN0bXQgcHJvcGVydHkgZG9lcyBub3QgaGF2ZSB0byBtYXRj aAo+IAo+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIC0gZG9lcyBpdCBtZWFuIHRoYXQgImNvbnN0 cmFpbmVkIGZhbHNlOyIgd2lsbAo+IG5ldmVyIGVuZm9yY2UgcmVmZXJlbnRpYWwgaW50ZWdyaXR5 IG9mIHRoZSBrZXlyZWY/CgpXaGljaCByZWZlcmVudGlhbCBpbnRlZ3JpdHkgdGVzdHMgZG8geW91 IG1lYW4/ClVuY29uc3RyYWluZWQgbWVhbnMgdGhlIERNIHdyaXRlciBkb2VzIG5vdCB3YW50IHRv IGNoZWNrCnRoYXQgdGhlIGluc3RhbmNlIChpZiBzcGVjaWZpZWQpIG1hdGNoZXMgYW4gZXhpc3Rp bmcKaW5zdGFuY2Ugb2YgdGhlIGtleS4gIEl0IGp1c3QgaGFzIHRvIG1hdGNoIGEgcHJvcGVybHkK c3BlY2lmaWVkIGluc3RhbmNlLgoKSWYgY29uZmlnIGRhdGEgZm9yIG1pc3NpbmcgaGFyZHdhcmUg aXMga2VwdCBhcm91bmQKaW4gdGhlIGRldmljZSwgdGhlIG9wZXJhdG9yIG5lZWRzIHRvIGtub3cg aWYgaXQgaXMgdGhlcmUgb3Igbm90LgpDb25maWcgZGF0YSB0aGF0IG1hZ2ljYWxseSBhcHBlYXJz IGFuZCBkaXNhcHBlYXJzIGFzIEhXIGlzCmluc2VydGVkIG9yIHJlbW92ZWQgaXMgYSBiYWQgaWRl YS4KCj4g77u/SSB3b3VsZCByYXRoZXIgcHJlZmVyIHRvIGltcGxlbWVudCB2YWxpZGF0aW9uIHBo YXNlcywgZS5nLiwKPiAKPiAgICAgdHlwZSBrZXlyZWYgewo+ICAgICAgICBwYXRoICIvc29tZS9w YXRoIjsKPiAgICAgICAgdmFsaWRhdGlvbi1waGFzZSBmdWxsOwo+ICAgICB9Cj4gCj4gSGVyZSwg bWlzc2luZyB0YXJnZXQgb2YgdGhpcyBrZXlyZWYgd291bGQgcmVzdWx0IGluIGFuIGVycm9yIG9u bHkgaWYgdGhlCj4gdmFsaWRhdGlvbiBwaGFzZSBpcyAiZnVsbCIsIHdoaWNoIGNvdWxkIGJlIHdo ZW4gdmFsaWRhdGluZyB0aGUgcnVubmluZwo+IGNvbmZpZ3VyYXRpb24uIE90aGVyd2lzZSBqdXN0 IGEgd2FybmluZyBjb3VsZCBiZSBpc3N1ZWQuCj4gCj4gVGhlIHZhbGlkYXRpb24gcGhhc2VzIHdv dWxkIGJlIG9yZGVyZWQgbGlrZSBzeXNsb2cgcHJpb3JpdGllcyBzbyB0aGF0Cj4gYW55IHBoYXNl IGFsc28gaW5jbHVkZXMgYWxsIHN0cmljdGVyIHBoYXNlcy4KPiAKCkkgZG8gbm90IHRoaW5rIHRo aXMgb2ZmZXJzIGFueSB2YWx1ZSBvciBwcmVjaXNpb24uCkkgd291bGQgcmF0aGVyIG5vdCBpbnRy b2R1Y2UgZXh0ZXJuYWwgcmVmZXJlbmNlcyBmb3IgJ2Z1bGwnLApvciAncGFydGlhbCcsIG9yIHdo YXRldmVyLgoKVGhlIE5FVENPTkYgV0cgY291bGQgbm90IHJlYWNoIGFueSBhZ3JlZW1lbnQgb24g dGhlIHByZWNpc2UKbWVhbmluZyBvZiB0aGUgPHZhbGlkYXRlPiBvcGVyYXRpb24uICBJbiBwYXJ0 aWN1bGFyLCBpbgpkYXRhYmFzZSB0ZXJtcywgIHRoZXJlIGlzIG5vIGFzc3VyYW5jZSB3aGF0c29l dmVyIHRoYXQKYSBjb25maWcgdGhhdCBwYXNzZXMgYSA8dmFsaWRhdGU+IHdpbGwgcGFzcyBhIDxj b21taXQ+CmF0IGFueSBhcmJpdHJhcnkgdGltZS4gIE5vIDIgYWdlbnQgaW1wbGVtZW50YXRpb25z CmFyZSByZXF1aXJlZCB0byBkbyB0aGUgc2FtZSB0ZXN0cyBvbiB0aGUgc2FtZSBjb25maWcgZnJh Z21lbnQuCgpUaGUgcHJvYmxlbSBpcyBqdXN0IHRvbyBoYXJkLgpVbmxpa2UgdGhlIGRhdGFiYXNl IHdvcmxkLCB0aGVyZSBpcyBhY3R1YWxseSBhIHdob2xlCmxvdCBvZiAnc3R1ZmYnIHRoYXQgZ29l cyBvbiBpbiBhbiBORSBjb25maWcgYmVzaWRlcwptYWludGFpbmluZyB0aGUgZGF0YWJhc2UgZGF0 YS4gIFNvbWUgY29uZmlnIGludGVyYWN0cwp3aXRoIHRoZSBuZXR3b3JrLCBiZXNpZGVzIHRoZSBh ZGRpdGlvbmFsIGludGVybmFsCmRhdGEgc3RydWN0dXJlcy4gIFlvdSBzaW1wbHkgY2Fubm90IHJ1 biBhbGwgdGhlIHNhbWUgY29kZQpmb3IgdmFsaWRhdGUgYXMgY29tbWl0IGluIGEgcm91dGVyLgoK PiBMYWRhCj4gCgpBbmR5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jul 24 12:23: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 9459D3A691D; Thu, 24 Jul 2008 12:23: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 246133A6780 for ; Thu, 24 Jul 2008 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.349 X-Spam-Level: * X-Spam-Status: No, score=1.349 tagged_above=-999 required=5 tests=[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 rMK0GrAGN9sn for ; Thu, 24 Jul 2008 12:23:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 07CDE3A6928 for ; Thu, 24 Jul 2008 12:23:33 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 91340D800C7; Thu, 24 Jul 2008 21:23:31 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4888BE38.3070207@netconfcentral.com> References: <200807240733.m6O7XMew049053@idle.juniper.net> <1216886441.6678.30.camel@missotis> <4888A6A9.5010704@netconfcentral.com> <1216919330.6678.109.camel@missotis> <4888BE38.3070207@netconfcentral.com> Organization: CESNET Date: Thu, 24 Jul 2008 21:23:32 +0200 Message-Id: <1216927413.6678.133.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAyNC4gMDcuIDIwMDggdiAxMDozOSAtMDcwMDoKPiAK PiBXaGljaCByZWZlcmVudGlhbCBpbnRlZ3JpdHkgdGVzdHMgZG8geW91IG1lYW4/CgpJIG1lYW4g dGhhdCB0aGUga2V5IGxlYWYgdGhhdCB0aGUga2V5cmVmIHBvaW50cyB0byBtYXkgbm90IGJlIHBy ZXNlbnQuCiAKPiBVbmNvbnN0cmFpbmVkIG1lYW5zIHRoZSBETSB3cml0ZXIgZG9lcyBub3Qgd2Fu dCB0byBjaGVjawo+IHRoYXQgdGhlIGluc3RhbmNlIChpZiBzcGVjaWZpZWQpIG1hdGNoZXMgYW4g ZXhpc3RpbmcKPiBpbnN0YW5jZSBvZiB0aGUga2V5LiAgSXQganVzdCBoYXMgdG8gbWF0Y2ggYSBw cm9wZXJseQo+IHNwZWNpZmllZCBpbnN0YW5jZS4KCldoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiAiZXhpc3RpbmcgaW5zdGFuY2Ugb2YgdGhlIGtleSIgYW5kCiJwcm9wZXJseSBzcGVjaWZp ZWQgaW5zdGFuY2UiPwoKPiAKPiA+IO+7v0kgd291bGQgcmF0aGVyIHByZWZlciB0byBpbXBsZW1l bnQgdmFsaWRhdGlvbiBwaGFzZXMsIGUuZy4sCj4gPiAKPiA+ICAgICB0eXBlIGtleXJlZiB7Cj4g PiAgICAgICAgcGF0aCAiL3NvbWUvcGF0aCI7Cj4gPiAgICAgICAgdmFsaWRhdGlvbi1waGFzZSBm dWxsOwo+ID4gICAgIH0KPiA+IAo+ID4gSGVyZSwgbWlzc2luZyB0YXJnZXQgb2YgdGhpcyBrZXly ZWYgd291bGQgcmVzdWx0IGluIGFuIGVycm9yIG9ubHkgaWYgdGhlCj4gPiB2YWxpZGF0aW9uIHBo YXNlIGlzICJmdWxsIiwgd2hpY2ggY291bGQgYmUgd2hlbiB2YWxpZGF0aW5nIHRoZSBydW5uaW5n Cj4gPiBjb25maWd1cmF0aW9uLiBPdGhlcndpc2UganVzdCBhIHdhcm5pbmcgY291bGQgYmUgaXNz dWVkLgo+ID4gCj4gPiBUaGUgdmFsaWRhdGlvbiBwaGFzZXMgd291bGQgYmUgb3JkZXJlZCBsaWtl IHN5c2xvZyBwcmlvcml0aWVzIHNvIHRoYXQKPiA+IGFueSBwaGFzZSBhbHNvIGluY2x1ZGVzIGFs bCBzdHJpY3RlciBwaGFzZXMuCj4gPiAKPiAKPiBJIGRvIG5vdCB0aGluayB0aGlzIG9mZmVycyBh bnkgdmFsdWUgb3IgcHJlY2lzaW9uLgoKSXQgb2ZmZXJzIGZsZXhpYmlsaXR5LiBUaGUgc2FtZSBj b25maWd1cmF0aW9uIGRhdGEgY2FuIGJlIGhhbmRsZWQKZGlmZmVyZW50bHkgaW4gZGlmZmVyZW50 IGNvbnRleHRzLgoKPiBJIHdvdWxkIHJhdGhlciBub3QgaW50cm9kdWNlIGV4dGVybmFsIHJlZmVy ZW5jZXMgZm9yICdmdWxsJywKPiBvciAncGFydGlhbCcsIG9yIHdoYXRldmVyLgo+IAo+IFRoZSBO RVRDT05GIFdHIGNvdWxkIG5vdCByZWFjaCBhbnkgYWdyZWVtZW50IG9uIHRoZSBwcmVjaXNlCj4g bWVhbmluZyBvZiB0aGUgPHZhbGlkYXRlPiBvcGVyYXRpb24uICBJbiBwYXJ0aWN1bGFyLCBpbgoK SSBhY3R1YWxseSBzZWUgdGhpcyBhcyBhIGJpZyBwcm9ibGVtIG9mIFlBTkcgLSBhIG1vZHVsZSBp dCBjbGVhcmx5CnNwZWNpZmllcyB2YXJpb3VzIGNvbnN0cmFpbnRzIGJ1dCBpdCBpcyBub3QgY2xl YXIgYXQgYWxsIHdoYXQgdGhlIG9iamVjdAppcyB0aGF0IGlzIHRvIGJlIHZhbGlkYXRlZCBhZ2Fp bnN0IHRoZW0gLSBhbmQgbW9zdCBsaWtlbHkgaXQgaXMgbm90IGp1c3QKYSBzaW5nbGUgb2JqZWN0 IChmdWxsIGRhdGFzdG9yZSwgZ2V0LWNvbmZpZyByZXBseSwgcnBjLCBub3RpZmljYXRpb24pLgoK TGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFp bGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jul 24 12:55: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 616143A6A29; Thu, 24 Jul 2008 12:55: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 0EA923A6921 for ; Thu, 24 Jul 2008 12:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt3nVflrpuOj for ; Thu, 24 Jul 2008 12:55:14 -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 2ECB13A6A67 for ; Thu, 24 Jul 2008 12:55:14 -0700 (PDT) Received: (qmail 36296 invoked from network); 24 Jul 2008 19:55:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 24 Jul 2008 19:55:12 -0000 X-YMail-OSG: 6n57hK8VM1lmhBCY5oNGelBLF1MvrdPC7YMe.v83sshozMM_55GvXvTsKmP7XyjBXoSewN20wx6hih0b8gl4wxakds_RbJnjXvY3e_USvw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4888DE1E.5050800@netconfcentral.com> Date: Thu, 24 Jul 2008 12:55:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ladislav Lhotka References: <200807240733.m6O7XMew049053@idle.juniper.net> <1216886441.6678.30.camel@missotis> <4888A6A9.5010704@netconfcentral.com> <1216919330.6678.109.camel@missotis> <4888BE38.3070207@netconfcentral.com> <1216927413.6678.133.camel@missotis> In-Reply-To: <1216927413.6678.133.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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+IEFuZHkgQmllcm1hbiBww63FoWUgdiDEjHQgMjQuIDA3 LiAyMDA4IHYgMTA6MzkgLTA3MDA6Cj4+IFdoaWNoIHJlZmVyZW50aWFsIGludGVncml0eSB0ZXN0 cyBkbyB5b3UgbWVhbj8KPiAKPiBJIG1lYW4gdGhhdCB0aGUga2V5IGxlYWYgdGhhdCB0aGUga2V5 cmVmIHBvaW50cyB0byBtYXkgbm90IGJlIHByZXNlbnQuCj4gIAo+PiBVbmNvbnN0cmFpbmVkIG1l YW5zIHRoZSBETSB3cml0ZXIgZG9lcyBub3Qgd2FudCB0byBjaGVjawo+PiB0aGF0IHRoZSBpbnN0 YW5jZSAoaWYgc3BlY2lmaWVkKSBtYXRjaGVzIGFuIGV4aXN0aW5nCj4+IGluc3RhbmNlIG9mIHRo ZSBrZXkuICBJdCBqdXN0IGhhcyB0byBtYXRjaCBhIHByb3Blcmx5Cj4+IHNwZWNpZmllZCBpbnN0 YW5jZS4KPiAKPiBXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gImV4aXN0aW5nIGluc3Rh bmNlIG9mIHRoZSBrZXkiIGFuZAo+ICJwcm9wZXJseSBzcGVjaWZpZWQgaW5zdGFuY2UiPwo+IAoK cHJvcGVybHkgc3BlY2lmaWVkIG1lYW5zIHRoYXQgdGhlIHZhbHVlIGNvdWxkIGJlCmEgdmFsaWQg a2V5IHZhbHVlLCBhY2NvcmRpbmcgdG8gdGhlIHN5bnRheCBmb3IgdGhlIGxlYWYuCgoKPj4+IO+7 v0kgd291bGQgcmF0aGVyIHByZWZlciB0byBpbXBsZW1lbnQgdmFsaWRhdGlvbiBwaGFzZXMsIGUu Zy4sCj4+Pgo+Pj4gICAgIHR5cGUga2V5cmVmIHsKPj4+ICAgICAgICBwYXRoICIvc29tZS9wYXRo IjsKPj4+ICAgICAgICB2YWxpZGF0aW9uLXBoYXNlIGZ1bGw7Cj4+PiAgICAgfQo+Pj4KPj4+IEhl cmUsIG1pc3NpbmcgdGFyZ2V0IG9mIHRoaXMga2V5cmVmIHdvdWxkIHJlc3VsdCBpbiBhbiBlcnJv ciBvbmx5IGlmIHRoZQo+Pj4gdmFsaWRhdGlvbiBwaGFzZSBpcyAiZnVsbCIsIHdoaWNoIGNvdWxk IGJlIHdoZW4gdmFsaWRhdGluZyB0aGUgcnVubmluZwo+Pj4gY29uZmlndXJhdGlvbi4gT3RoZXJ3 aXNlIGp1c3QgYSB3YXJuaW5nIGNvdWxkIGJlIGlzc3VlZC4KPj4+Cj4+PiBUaGUgdmFsaWRhdGlv biBwaGFzZXMgd291bGQgYmUgb3JkZXJlZCBsaWtlIHN5c2xvZyBwcmlvcml0aWVzIHNvIHRoYXQK Pj4+IGFueSBwaGFzZSBhbHNvIGluY2x1ZGVzIGFsbCBzdHJpY3RlciBwaGFzZXMuCj4+Pgo+PiBJ IGRvIG5vdCB0aGluayB0aGlzIG9mZmVycyBhbnkgdmFsdWUgb3IgcHJlY2lzaW9uLgo+IAo+IEl0 IG9mZmVycyBmbGV4aWJpbGl0eS4gVGhlIHNhbWUgY29uZmlndXJhdGlvbiBkYXRhIGNhbiBiZSBo YW5kbGVkCj4gZGlmZmVyZW50bHkgaW4gZGlmZmVyZW50IGNvbnRleHRzLgo+IAo+PiBJIHdvdWxk IHJhdGhlciBub3QgaW50cm9kdWNlIGV4dGVybmFsIHJlZmVyZW5jZXMgZm9yICdmdWxsJywKPj4g b3IgJ3BhcnRpYWwnLCBvciB3aGF0ZXZlci4KPj4KPj4gVGhlIE5FVENPTkYgV0cgY291bGQgbm90 IHJlYWNoIGFueSBhZ3JlZW1lbnQgb24gdGhlIHByZWNpc2UKPj4gbWVhbmluZyBvZiB0aGUgPHZh bGlkYXRlPiBvcGVyYXRpb24uICBJbiBwYXJ0aWN1bGFyLCBpbgo+IAo+IEkgYWN0dWFsbHkgc2Vl IHRoaXMgYXMgYSBiaWcgcHJvYmxlbSBvZiBZQU5HIC0gYSBtb2R1bGUgaXQgY2xlYXJseQo+IHNw ZWNpZmllcyB2YXJpb3VzIGNvbnN0cmFpbnRzIGJ1dCBpdCBpcyBub3QgY2xlYXIgYXQgYWxsIHdo YXQgdGhlIG9iamVjdAo+IGlzIHRoYXQgaXMgdG8gYmUgdmFsaWRhdGVkIGFnYWluc3QgdGhlbSAt IGFuZCBtb3N0IGxpa2VseSBpdCBpcyBub3QganVzdAo+IGEgc2luZ2xlIG9iamVjdCAoZnVsbCBk YXRhc3RvcmUsIGdldC1jb25maWcgcmVwbHksIHJwYywgbm90aWZpY2F0aW9uKS4KPiAKCk9uZSBw YXJhZ3JhcGggdXAgeW91IGFyZSBhcmd1aW5nIGZvciBmbGV4aWJpbGl0eS4KTm93IGZsZXhpYmls aXR5IGlzIGEgYmlnIHByb2JsZW0uCgpXaGF0IGFib3V0IHJlc291cmNlIGNvbnN0cmFpbnRzPwpU aGUgdmFsaWRhdGUgcGhhc2UgbWF5IG5vdCBhbGxvY2F0ZSBhbGwgdGhlIGludGVybmFsCmRhdGEg c3RydWN0dXJlcyBpbiBhZHZhbmNlIGFuZCBob2xkIHRoZW0uICBJdCBwcm9iYWJseQphbGxvY2F0 ZXMgbm9uZSBvZiB0aGVtLCBhbmQgdXNlcyBzb21lIGhldXJpc3RpYyBpbnN0ZWFkCihpZiBpdCBi b3RoZXJzIHRvIGNoZWNrIGF0IGFsbCkuCgpDb25maWcgY2hhbmdlcyB0aGF0IG1heSBjYXVzZSBQ RFVzIGZvciB2YXJpb3VzIHByb3RvY29scwp0byBiZSBnZW5lcmF0ZWQgYXJlIG5ldmVyIGV4ZWN1 dGVkIGluIHZhbGlkYXRlIHBoYXNlLgoKWUFORyBpcyBncmVhdCBmb3IgZGVmaW5pbmcgdGhlIGNv bmZpZyBkYXRhYmFzZSBjb250ZW50cywKYnV0IHdlIGNhbiBuZXZlciBmb3JnZXQgdGhhdCB0aGlz IGlzIHJ1bm5pbmcgb24gYSBuZXR3b3JrCmVsZW1lbnQsIG5vdCBhIGRhdGFiYXNlIHNlcnZlci4K Cj4gTGFkYQo+IAoKQW5keQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Jul 24 14:36: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 61C3B3A69F6; Thu, 24 Jul 2008 14:36: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 AC5FE3A6910 for ; Thu, 24 Jul 2008 14:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdFgkjPc9gjJ for ; Thu, 24 Jul 2008 14:36:03 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 49A0B3A685A for ; Thu, 24 Jul 2008 14:36:03 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id D502976C227; Thu, 24 Jul 2008 23:36:02 +0200 (CEST) Date: Thu, 24 Jul 2008 23:35:52 +0200 (CEST) Message-Id: <20080724.233552.48917833.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200807231521.m6NFLTD3039594@idle.juniper.net> References: <4887417F.3020506@netconfcentral.com> <200807231521.m6NFLTD3039594@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] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >> keyref doesn't do copying (what's copy-on-value mean?), so I don't > >> see how it could do (3). > >I thought Martin said that if you edited the keyref, > >that does not change the real value, just the keyref. > >That is copy-by-value, not copy-by-reference. > > I don't think this is true. Martin? I wouldn't use these terms; it's much simpler than that. A keyref is a normal leaf that has its own value just like all leafs. If you change the value of the leaf, nothing but the leaf is modified. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 24 14:45: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 1BF9D28C10D; Thu, 24 Jul 2008 14:45: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 154C428C14F for ; Thu, 24 Jul 2008 14:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+qGRzB42xx0 for ; Thu, 24 Jul 2008 14:45:17 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6420328C10D for ; Thu, 24 Jul 2008 14:45:16 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id A3B7B76C227; Thu, 24 Jul 2008 23:45:15 +0200 (CEST) Date: Thu, 24 Jul 2008 23:45:12 +0200 (CEST) Message-Id: <20080724.234512.129459950.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4887754D.4090204@netconfcentral.com> References: <200807231753.m6NHrXnP041031@idle.juniper.net> <4887754D.4090204@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: > >> IMO, it is more intuitive and reusable to be > >> able to define a container as mandatory true/false > >> in a top-down manner, rather than track down all the > >> child nodes, read all the presence-stmt clauses, > >> augment-when clauses, and eventually figure out > >> the mandatory status. > >> > >> Of course the compiler can do that fairly quickly, > >> but not the DM reader or writer. > > So you want mandatory on containers as a hint to the reader, not > > as this third kind of container? Would it be a compiler error to > > have a container that doesn't contain anything mandatory? If not, > > you still have to decide why you want a meaningless mandatory node. > > > > I want the mandatory property to be relative to the containment > level Does this answer Phil's two questions above? Can you elaborate a bit? > and the mandatory-stmt to be allowed in the container-stmt. I got that one. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 24 14:47: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 871F93A6A38; Thu, 24 Jul 2008 14:47: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 BF4BA3A6A38 for ; Thu, 24 Jul 2008 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2vDDmcCjS4z for ; Thu, 24 Jul 2008 14:47:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0BB093A685A for ; Thu, 24 Jul 2008 14:47:42 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id A2EAD76C227; Thu, 24 Jul 2008 23:47:41 +0200 (CEST) Date: Thu, 24 Jul 2008 23:47:38 +0200 (CEST) Message-Id: <20080724.234738.175261842.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <488762C5.30407@netconfcentral.com> References: <200807231617.m6NGH0tV039948@idle.juniper.net> <488762C5.30407@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > The parent node should decide if the child node is mandatory, > not the other way around. Are you proposing that if a container is marked as mandatory, *all* its children are also mandatory? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 24 17:33: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 9CBE83A6845; Thu, 24 Jul 2008 17:33: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 F39B03A67B2 for ; Thu, 24 Jul 2008 17:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 mZwyjBxImVnZ for ; Thu, 24 Jul 2008 17:33:25 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 1CD583A6A2D for ; Thu, 24 Jul 2008 17:33:24 -0700 (PDT) Received: (qmail 52571 invoked from network); 25 Jul 2008 00:33:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 00:33:22 -0000 X-YMail-OSG: KGAwjWkVM1nbNmrj_A5Q.h_wCMVdQhDE1gH1dhPixiQnnGtKFxxqx2fhvF4MlC5S4H63Cv0kEXFCm7kQi_gVw.1_jFN8ptswjz2vyedilg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48891F50.7080609@netconfcentral.com> Date: Thu, 24 Jul 2008 17:33:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200807231617.m6NGH0tV039948@idle.juniper.net> <488762C5.30407@netconfcentral.com> <20080724.234738.175261842.mbj@tail-f.com> In-Reply-To: <20080724.234738.175261842.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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 parent node should decide if the child node is mandatory, >> not the other way around. > > Are you proposing that if a container is marked as mandatory, *all* > its children are also mandatory? > no. going back to the 'name' example: grouping Name { container name { .... } } YANG has no way to control how Name is used in different contexts. If I had a data model designed with a 'default administrator name', then the entire 'name' container would be optional in that data model. In another data model, the 'name' container may be mandatory because there is no default to use instead. But I can't design a grouping with a container in it, because if that container has any mandatory fields, it ripples up and makes the parent container mandatory. Unless I could do this: container admin { container sys-admin { uses Name { container name { mandatory true; } } uses Email; } container guest-admin { uses Name { container name { mandatory false; } } uses Email; } } > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 02: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 807753A689D; Fri, 25 Jul 2008 02: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 7B2DD3A69BE for ; Fri, 25 Jul 2008 02:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=1.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 r1JwO39552pp for ; Fri, 25 Jul 2008 02:22:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9B2EA3A689D for ; Fri, 25 Jul 2008 02:22: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 17553D800C8; Fri, 25 Jul 2008 11:22:49 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4888DE1E.5050800@netconfcentral.com> References: <200807240733.m6O7XMew049053@idle.juniper.net> <1216886441.6678.30.camel@missotis> <4888A6A9.5010704@netconfcentral.com> <1216919330.6678.109.camel@missotis> <4888BE38.3070207@netconfcentral.com> <1216927413.6678.133.camel@missotis> <4888DE1E.5050800@netconfcentral.com> Organization: CESNET Date: Fri, 25 Jul 2008 11:22:48 +0200 Message-Id: <1216977768.6521.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAyNC4gMDcuIDIwMDggdiAxMjo1NSAtMDcwMDoKPiAK PiBPbmUgcGFyYWdyYXBoIHVwIHlvdSBhcmUgYXJndWluZyBmb3IgZmxleGliaWxpdHkuCj4gTm93 IGZsZXhpYmlsaXR5IGlzIGEgYmlnIHByb2JsZW0uCgpPbmUgdGhpbmcgaXMgdGhlIGFiaWxpdHkg dG8gdmFsaWRhdGUgdGhlIGRhdGEgZGlmZmVyZW50bHkgaW4gZGlmZmVyZW50LApidXQgcHJlY2lz ZWx5IGRlZmluZWQsIGNvbnRleHRzLCBhbmQgYW5vdGhlciB0aGluZyBpcyB0aGUgZnV6emluZXNz IG9mCnRoZSBub3Rpb24gb2YgdmFsaWRpdHkuCgo+IAo+IFdoYXQgYWJvdXQgcmVzb3VyY2UgY29u c3RyYWludHM/Cj4gVGhlIHZhbGlkYXRlIHBoYXNlIG1heSBub3QgYWxsb2NhdGUgYWxsIHRoZSBp bnRlcm5hbAo+IGRhdGEgc3RydWN0dXJlcyBpbiBhZHZhbmNlIGFuZCBob2xkIHRoZW0uICBJdCBw cm9iYWJseQo+IGFsbG9jYXRlcyBub25lIG9mIHRoZW0sIGFuZCB1c2VzIHNvbWUgaGV1cmlzdGlj IGluc3RlYWQKPiAoaWYgaXQgYm90aGVycyB0byBjaGVjayBhdCBhbGwpLgo+IAo+IENvbmZpZyBj aGFuZ2VzIHRoYXQgbWF5IGNhdXNlIFBEVXMgZm9yIHZhcmlvdXMgcHJvdG9jb2xzCj4gdG8gYmUg Z2VuZXJhdGVkIGFyZSBuZXZlciBleGVjdXRlZCBpbiB2YWxpZGF0ZSBwaGFzZS4KPiAKPiBZQU5H IGlzIGdyZWF0IGZvciBkZWZpbmluZyB0aGUgY29uZmlnIGRhdGFiYXNlIGNvbnRlbnRzLAo+IGJ1 dCB3ZSBjYW4gbmV2ZXIgZm9yZ2V0IHRoYXQgdGhpcyBpcyBydW5uaW5nIG9uIGEgbmV0d29yawo+ IGVsZW1lbnQsIG5vdCBhIGRhdGFiYXNlIHNlcnZlci4KCkkgZnVsbHkgYWdyZWUuIFlBTkcgbW9k dWxlcyBhcmUgb2Z0ZW4gcHJlc2VudGVkIGFzIGNvbnRyYWN0cyBiZXR3ZWVuIHRoZQphZ2VudCBh bmQgbWFuYWdlci4gSXQgd291bGQgdGhlbiBiZSBxdWl0ZSBuYXR1cmFsIHRvIHZpZXcgc3VjaCBh CmNvbnRyYWN0IGFzIGEgcHJvdG9jb2wgdGhhdCBzYXlzOiBpZiB0aGUgbWFuYWdlciBzZW5kcyBt ZXNzYWdlIFgsIGl0CndpbGwgcmVjZWl2ZSBhIHJlcGx5IFIoWCkgYW5kIGl0IG1lYW5zIHRoaXMg YW5kIHRoaXMuIFRoaXMgTkVUQ09ORiBQRFUKcGVyc3BlY3RpdmUgaGFzIHRoZSBhZHZhbnRhZ2Ug dGhhdCB0aGUgcmVwcmVzZW50YXRpb24gb2YgZGF0YSBpcyBnaXZlbiAtClhNTC4gSXQgbWF5IG5v dCBjb3ZlciBldmVyeXRoaW5nIHdoYXQgcGVvcGxlIGV4cGVjdCBmcm9tIFlBTkcsIGJ1dCBpdAp3 b3VsZCBiZSBxdWl0ZSBwcmVjaXNlbHkgZGVmaW5lZCBhbmQgbXVjaCBlYXNpZXIgdG8gZGVhbCB3 aXRoIGNvbmNlcHRzCmxpa2UgbWFuZGF0b3J5LCBkZWZhdWx0cyBldGMuLCBhbmQgcHJvYmxlbXMg b2YgZGF0YWJhc2UgYmFja2VuZHMgd291bGQKYmUgbGVmdCB0byBpbXBsZW1lbnRvcnMuCgpMYWRh ICAKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxp bmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri Jul 25 07: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 27B7F3A67FB; Fri, 25 Jul 2008 07: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 D57933A67FB for ; Fri, 25 Jul 2008 07:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEsDrKxiRUw2 for ; Fri, 25 Jul 2008 07:24:03 -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 ADE6B3A686B for ; Fri, 25 Jul 2008 07:24:03 -0700 (PDT) Received: (qmail 86262 invoked from network); 25 Jul 2008 14:24:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 14:24:03 -0000 X-YMail-OSG: VA5q7D8VM1nFrSSqXL3cKz8AhixIYJrOcTRtJp_duVgKqUeVPmvlKOW5PSxc.kch90WU2a2Vzt3VN3D0soK8aHoFFG.zssKefId0S3EvjsuwldLj07vGA1cL6Ooy X-Yahoo-Newman-Property: ymail-3 Message-ID: <4889E201.6080901@netconfcentral.com> Date: Fri, 25 Jul 2008 07:24:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <200807240733.m6O7XMew049053@idle.juniper.net> <1216886441.6678.30.camel@missotis> <4888A6A9.5010704@netconfcentral.com> <1216919330.6678.109.camel@missotis> <4888BE38.3070207@netconfcentral.com> <1216927413.6678.133.camel@missotis> <4888DE1E.5050800@netconfcentral.com> <1216977768.6521.35.camel@missotis> In-Reply-To: <1216977768.6521.35.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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+IEFuZHkgQmllcm1hbiBww63FoWUgdiDEjHQgMjQuIDA3 LiAyMDA4IHYgMTI6NTUgLTA3MDA6Cj4+IE9uZSBwYXJhZ3JhcGggdXAgeW91IGFyZSBhcmd1aW5n IGZvciBmbGV4aWJpbGl0eS4KPj4gTm93IGZsZXhpYmlsaXR5IGlzIGEgYmlnIHByb2JsZW0uCj4g Cj4gT25lIHRoaW5nIGlzIHRoZSBhYmlsaXR5IHRvIHZhbGlkYXRlIHRoZSBkYXRhIGRpZmZlcmVu dGx5IGluIGRpZmZlcmVudCwKPiBidXQgcHJlY2lzZWx5IGRlZmluZWQsIGNvbnRleHRzLCBhbmQg YW5vdGhlciB0aGluZyBpcyB0aGUgZnV6emluZXNzIG9mCj4gdGhlIG5vdGlvbiBvZiB2YWxpZGl0 eS4KPiAKCkJ1dCB0aGUgdmFsaWRhdGlvbiBzdGVwcyBhcmUgbm90IHByZWNpc2VseSBkZWZpbmVk CmluIHJlYWwgaW1wbGVtZW50YXRpb25zLiAgTWF5YmUgb24gcGFwZXIgZm9yIGEgZGlydC1zaW1w bGUKZGV2aWNlLCBidXQgbm90IGEgcmVhbCByb3V0ZXIuCgo+PiBXaGF0IGFib3V0IHJlc291cmNl IGNvbnN0cmFpbnRzPwo+PiBUaGUgdmFsaWRhdGUgcGhhc2UgbWF5IG5vdCBhbGxvY2F0ZSBhbGwg dGhlIGludGVybmFsCj4+IGRhdGEgc3RydWN0dXJlcyBpbiBhZHZhbmNlIGFuZCBob2xkIHRoZW0u ICBJdCBwcm9iYWJseQo+PiBhbGxvY2F0ZXMgbm9uZSBvZiB0aGVtLCBhbmQgdXNlcyBzb21lIGhl dXJpc3RpYyBpbnN0ZWFkCj4+IChpZiBpdCBib3RoZXJzIHRvIGNoZWNrIGF0IGFsbCkuCj4+Cj4+ IENvbmZpZyBjaGFuZ2VzIHRoYXQgbWF5IGNhdXNlIFBEVXMgZm9yIHZhcmlvdXMgcHJvdG9jb2xz Cj4+IHRvIGJlIGdlbmVyYXRlZCBhcmUgbmV2ZXIgZXhlY3V0ZWQgaW4gdmFsaWRhdGUgcGhhc2Uu Cj4+Cj4+IFlBTkcgaXMgZ3JlYXQgZm9yIGRlZmluaW5nIHRoZSBjb25maWcgZGF0YWJhc2UgY29u dGVudHMsCj4+IGJ1dCB3ZSBjYW4gbmV2ZXIgZm9yZ2V0IHRoYXQgdGhpcyBpcyBydW5uaW5nIG9u IGEgbmV0d29yawo+PiBlbGVtZW50LCBub3QgYSBkYXRhYmFzZSBzZXJ2ZXIuCj4gCj4gSSBmdWxs eSBhZ3JlZS4gWUFORyBtb2R1bGVzIGFyZSBvZnRlbiBwcmVzZW50ZWQgYXMgY29udHJhY3RzIGJl dHdlZW4gdGhlCj4gYWdlbnQgYW5kIG1hbmFnZXIuIEl0IHdvdWxkIHRoZW4gYmUgcXVpdGUgbmF0 dXJhbCB0byB2aWV3IHN1Y2ggYQo+IGNvbnRyYWN0IGFzIGEgcHJvdG9jb2wgdGhhdCBzYXlzOiBp ZiB0aGUgbWFuYWdlciBzZW5kcyBtZXNzYWdlIFgsIGl0Cj4gd2lsbCByZWNlaXZlIGEgcmVwbHkg UihYKSBhbmQgaXQgbWVhbnMgdGhpcyBhbmQgdGhpcy4gVGhpcyBORVRDT05GIFBEVQo+IHBlcnNw ZWN0aXZlIGhhcyB0aGUgYWR2YW50YWdlIHRoYXQgdGhlIHJlcHJlc2VudGF0aW9uIG9mIGRhdGEg aXMgZ2l2ZW4gLQo+IFhNTC4gSXQgbWF5IG5vdCBjb3ZlciBldmVyeXRoaW5nIHdoYXQgcGVvcGxl IGV4cGVjdCBmcm9tIFlBTkcsIGJ1dCBpdAo+IHdvdWxkIGJlIHF1aXRlIHByZWNpc2VseSBkZWZp bmVkIGFuZCBtdWNoIGVhc2llciB0byBkZWFsIHdpdGggY29uY2VwdHMKPiBsaWtlIG1hbmRhdG9y eSwgZGVmYXVsdHMgZXRjLiwgYW5kIHByb2JsZW1zIG9mIGRhdGFiYXNlIGJhY2tlbmRzIHdvdWxk Cj4gYmUgbGVmdCB0byBpbXBsZW1lbnRvcnMuCgpJIGRvbid0IHRoaW5rIHRoaXMgd291bGQgYmUg d29ydGh3aGlsZSB0byBkb2N1bWVudCBpbiBhIFlBTkcgbW9kdWxlLgpZb3UgY291bGQgZmlsbCA1 MDAgcGFnZXMgd2l0aCBwcm90b2NvbCBQRFUgaW50ZXJhY3Rpb25zLgpZQU5HIGp1c3QgbmVlZHMg dG8gZGVzY3JpYmUgdGhlICd2YWxpZCcgY29uZmlndXJhdGlvbiBlbmQtc3RhdGUsCm5vdCBkZWZp bmUgZXZlcnkgbGl0dGxlIHdheSBhbiBORSBjb25maWcgZGF0YWJhc2UgY2FuIGJyZWFrCndoaWxl IGl0IGlzIGJlaW5nIGVkaXRlZC4KCgo+IAo+IExhZGEgIAo+IAoKQW5keQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApu ZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QK From netmod-bounces@ietf.org Fri Jul 25 07:51: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 76CFB3A685C; Fri, 25 Jul 2008 07:51: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 B737128B23E for ; Fri, 25 Jul 2008 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av2VhMmA8rlt for ; Fri, 25 Jul 2008 07:51:53 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 097F628C1E7 for ; Fri, 25 Jul 2008 07:51:23 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 07:51:11 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 07:51:13 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 07:51:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 07:49:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PEnou52386; Fri, 25 Jul 2008 07:49:55 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6PEkn4P061259; Fri, 25 Jul 2008 14:46:49 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807251446.m6PEkn4P061259@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1216977768.6521.35.camel@missotis> Date: Fri, 25 Jul 2008 10:46:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 14:49:56.0479 (UTC) FILETIME=[B45758F0:01C8EE65] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >I fully agree. YANG modules are often presented as contracts between the >agent and manager. It would then be quite natural to view such a >contract as a protocol that says: if the manager sends message X, it >will receive a reply R(X) and it means this and this. A YANG module defines the final hierarchy of config, so the contract is more like: if the manager builds content X (in any number of protocol operations), the device will perform the function F(X). How you build the data is less important than the final state. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 07:51: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 283533A69CD; Fri, 25 Jul 2008 07:51: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 CC64B28B23E for ; Fri, 25 Jul 2008 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXW7nXwpU9LS for ; Fri, 25 Jul 2008 07:51:53 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 0983F28C1E8 for ; Fri, 25 Jul 2008 07:51:23 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 07:51:17 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 07:51:13 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 07:51:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 07:42:12 -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 m6PEgBu46592; Fri, 25 Jul 2008 07:42: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 m6PEd9Zp061153; Fri, 25 Jul 2008 14:39:09 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807251439.m6PEd9Zp061153@idle.juniper.net> To: Andy Bierman In-reply-to: <4889E201.6080901@netconfcentral.com> Date: Fri, 25 Jul 2008 10:39:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 14:42:12.0110 (UTC) FILETIME=[9F8E42E0:01C8EE64] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >But the validation steps are not precisely defined >in real implementations. Maybe on paper for a dirt-simple >device, but not a real router. Can you explain this comment? I'm not following you. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 07:56:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7FA3A688E; Fri, 25 Jul 2008 07:56:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967DB3A6862 for ; Fri, 25 Jul 2008 07:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN0xSQhG1JDw for ; Fri, 25 Jul 2008 07:56:41 -0700 (PDT) Received: from psmtp.com (exprod7ob113.obsmtp.com [64.18.2.178]) by core3.amsl.com (Postfix) with ESMTP id 5F5E93A688E for ; Fri, 25 Jul 2008 07:56:39 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 07:56:38 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 07:56:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 07:56:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 07:56:37 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PEuau59860; Fri, 25 Jul 2008 07:56:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6PErYGa061330; Fri, 25 Jul 2008 14:53:35 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807251453.m6PErYGa061330@idle.juniper.net> To: Andy Bierman In-reply-to: <48891F50.7080609@netconfcentral.com> Date: Fri, 25 Jul 2008 10:53:34 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 14:56:37.0194 (UTC) FILETIME=[A32F9AA0:01C8EE66] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: >Unless I could do this: >container admin { > container sys-admin { > uses Name { > container name { > mandatory true; > } > } So the issue that you want the above instead of refining down to the level of the members of name, like: container admin { container sys-admin { uses Name { container name { leaf last-name { // Adding this one level mandatory true; } } } ... Getting your desired outcome requires that you change the individual leafs of name, not merely change name. The current behavior give you better control (for, say, scenarios where the first and last names are mandatory but the middle is not), but does require that the "use"r know which leafs need tuning. IMHO, this isn't a horrible burden and the flexibility and control of the current approach is more valuable than trying to answer the question "it it's meaningless and empty, why is it mandatory?". Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 08:00: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 0B43428C1E5; Fri, 25 Jul 2008 08:00: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 2715B28C1EC for ; Fri, 25 Jul 2008 08:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrb4GKhoBby8 for ; Fri, 25 Jul 2008 08:00:53 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 1E11F28C1C5 for ; Fri, 25 Jul 2008 08:00:52 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 08:00:51 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:00:20 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:00:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:00:19 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PF0Ju63103; Fri, 25 Jul 2008 08:00: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 m6PEvHoq061424; Fri, 25 Jul 2008 14:57:17 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807251457.m6PEvHoq061424@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1216927413.6678.133.camel@missotis> Date: Fri, 25 Jul 2008 10:57:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 15:00:19.0947 (UTC) FILETIME=[27F503B0:01C8EE67] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >I actually see this as a big problem of YANG - a module it clearly >specifies various constraints but it is not clear at all what the object >is that is to be validated against them - and most likely it is not just >a single object (full datastore, get-config reply, rpc, notification). The spec definitely needs to add/refine words to say when various elements are required for protocol operations (like keys) and some words about when the various constraints can be checked (type constraints when the element is parsed, must constraint when the containing element's close tag is seen, etc). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 08:03:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96743A6A43; Fri, 25 Jul 2008 08:03:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56C528C1E7 for ; Fri, 25 Jul 2008 08:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 RuSsrVt6Ej8U for ; Fri, 25 Jul 2008 08:03:46 -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 188E03A6A43 for ; Fri, 25 Jul 2008 08:03:45 -0700 (PDT) Received: (qmail 72903 invoked from network); 25 Jul 2008 15:03:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 15:03:45 -0000 X-YMail-OSG: mXgPrkYVM1lyRUkC5MD6_5w3UnQPxlCtO2kA0BKGZRwt.bPozk3h88ub.V0eQwCjNr8CtS_9bs66TCFX19Y2vVe6iOU9Fa5d6cOuUZ5lHg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4889EB4F.3050100@netconfcentral.com> Date: Fri, 25 Jul 2008 08:03:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807251439.m6PEd9Zp061153@idle.juniper.net> In-Reply-To: <200807251439.m6PEd9Zp061153@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org 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: >> But the validation steps are not precisely defined >> in real implementations. Maybe on paper for a dirt-simple >> device, but not a real router. > > Can you explain this comment? I'm not following you. > The actual validation steps performed are totally dependent on the particular data structure, and possibly platform/version as well. Just declaring 'full' or 'partial' validation is never going to be uniformly applied to every data structure. Some data structures are dependent on the config of other devices, or just the state of the network, so validation of such config data may need to be in synch with data on other devices. In other words, passing a at time t(0) may not mean you will pass a at time t(1). > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 08:20: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 24CE43A67D0; Fri, 25 Jul 2008 08:20: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 BFDDC3A6961 for ; Fri, 25 Jul 2008 08:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 6q9uUIUB4xX0 for ; Fri, 25 Jul 2008 08:20:06 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id C9EB53A67D0 for ; Fri, 25 Jul 2008 08:20:06 -0700 (PDT) Received: (qmail 62684 invoked from network); 25 Jul 2008 15:20:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 15:20:06 -0000 X-YMail-OSG: VKUgiEMVM1kxS7Kv_hiUVlpLVcu5LaAb2SJJQgUJBuIaQ3no6hN4gcqn4gzzbNUysYNN_9UEgP403NvPZvYoLq5XzsbcZcQlAz7o9LPqZg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4889EF25.7000308@netconfcentral.com> Date: Fri, 25 Jul 2008 08:20:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807251453.m6PErYGa061330@idle.juniper.net> In-Reply-To: <200807251453.m6PErYGa061330@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: >> Unless I could do this: >> container admin { >> container sys-admin { >> uses Name { >> container name { >> mandatory true; >> } >> } > > So the issue that you want the above instead of refining > down to the level of the members of name, like: > > container admin { > container sys-admin { > uses Name { > container name { > leaf last-name { // Adding this one level > mandatory true; > } > } > } > ... > > Getting your desired outcome requires that you change the individual > leafs of name, not merely change name. The current behavior give > you better control (for, say, scenarios where the first and last > names are mandatory but the middle is not), but does require that > the "use"r know which leafs need tuning. > no -- this misses the whole point of information hiding. YANG has no real support for that. Groupings are pretty worthless, since I have to be totally aware of the context of the uses when writing the grouping, and also need to be totally aware of the grouping contents when I write the uses. This isn't encapsulation at all. > IMHO, this isn't a horrible burden and the flexibility and control > of the current approach is more valuable than trying to answer the > question "it it's meaningless and empty, why is it mandatory?". > You removed the rest of the example, which pointed out that for the sys-admin, a name and an email address were mandatory, but for the guest admin, just an email address is mandatory. The point of this contrived example is that sometimes the DM writer needs to decide all-or-nothing to use , not just uses refinement of the sub-nodes. Change to if you want a better example. CLI and SMIv2 are both awful when it comes to definition reuse. Maybe YANG doesn't need to do any better, because nobody cares about code/definition reuse for NETCONF. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 08:28:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7CB3A694F; Fri, 25 Jul 2008 08:28:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D133A6AFE for ; Fri, 25 Jul 2008 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzPTb3qJP7oV for ; Fri, 25 Jul 2008 08:28:37 -0700 (PDT) Received: from psmtp.com (exprod7ob113.obsmtp.com [64.18.2.178]) by core3.amsl.com (Postfix) with ESMTP id A963C3A694F for ; Fri, 25 Jul 2008 08:28:36 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 08:28:29 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:28:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:28:22 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:28: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 m6PFSLu89005; Fri, 25 Jul 2008 08:28: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 m6PFPJgB062086; Fri, 25 Jul 2008 15:25:20 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807251525.m6PFPJgB062086@idle.juniper.net> To: Andy Bierman In-reply-to: <4889EB4F.3050100@netconfcentral.com> Date: Fri, 25 Jul 2008 11:25:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 15:28:22.0138 (UTC) FILETIME=[129EFDA0:01C8EE6B] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >The actual validation steps performed are totally dependent >on the particular data structure, and possibly platform/version >as well. Just declaring 'full' or 'partial' validation >is never going to be uniformly applied to every data structure. Totally agree. >Some data structures are dependent on the config of >other devices, or just the state of the network, so validation >of such config data may need to be in synch with data on other >devices. In other words, passing a at time t(0) >may not mean you will pass a at time t(1). Totally disagree. If your config validation depends on external factors, then your system is incredibly fragile. Imagine when your Genius Routing Guy does something a 2pm and the config works. But when the midnight operator turns up an interface during a 2am maintenance window, the config fails for reasons unrelated to the interface. The operator is lost. He calls up Genius Routing Guy, who isn't happy to be pulled away from This Month's Awesome video game (what? you thought we was asleep?) and immediately starts sticking pins in his Vender Voodoo Doll. Or the person answering the phone at 1800MYCABLE needs to change some subscriber service contract from "silver" to "gold". They enter the data into some web form, which goes into the billing database, which opens a change ticket, which triggers an NETCONF operation to change that subscriber information on the right box. But instead the phone person sees a message about whatever config worked for Genius Routing Guy at time t(0) but no longer works at time t(1). You can't build dependable automation around a system that is not dependable. If the config is valid, it works today, tomorrow, next year. It works on this box and on one I hot-swap in for it. It works when I pull a PIC, it works when I stuff in a new one. The config has to be dependable. It's the bedrock upon which all this automation is built. If we view config validation as shifting sand, we're in for trouble. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 08:43: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 782B728C219; Fri, 25 Jul 2008 08:43: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 3D86C28C214 for ; Fri, 25 Jul 2008 08:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UFPMikWWYOq for ; Fri, 25 Jul 2008 08:42:58 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 2389B28C219 for ; Fri, 25 Jul 2008 08:42:58 -0700 (PDT) Received: (qmail 1680 invoked from network); 25 Jul 2008 15:42:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 15:42:58 -0000 X-YMail-OSG: HsyCw64VM1lmw02LRR4N.UloUcFtlfzqrTDTRvWS_fH_mLLfVCmLCd1jKmBtn2V4RihhvGJpO25hxXN5WsPidn0dK7UFp4gkIer_4t4dy6sjeD_d_2DIyUF8z.Ct X-Yahoo-Newman-Property: ymail-3 Message-ID: <4889F47F.2030100@netconfcentral.com> Date: Fri, 25 Jul 2008 08:42:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807251525.m6PFPJgB062086@idle.juniper.net> In-Reply-To: <200807251525.m6PFPJgB062086@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The actual validation steps performed are totally dependent >> on the particular data structure, and possibly platform/version >> as well. Just declaring 'full' or 'partial' validation >> is never going to be uniformly applied to every data structure. > > Totally agree. > >> Some data structures are dependent on the config of >> other devices, or just the state of the network, so validation >> of such config data may need to be in synch with data on other >> devices. In other words, passing a at time t(0) >> may not mean you will pass a at time t(1). > > Totally disagree. If your config validation depends on external > factors, then your system is incredibly fragile. > > Imagine when your Genius Routing Guy does something a 2pm and the > config works. But when the midnight operator turns up an interface > during a 2am maintenance window, the config fails for reasons > unrelated to the interface. The operator is lost. He calls up > Genius Routing Guy, who isn't happy to be pulled away from This > Month's Awesome video game (what? you thought we was asleep?) and > immediately starts sticking pins in his Vender Voodoo Doll. > > Or the person answering the phone at 1800MYCABLE needs to change > some subscriber service contract from "silver" to "gold". They > enter the data into some web form, which goes into the billing > database, which opens a change ticket, which triggers an NETCONF > operation to change that subscriber information on the right box. > But instead the phone person sees a message about whatever config > worked for Genius Routing Guy at time t(0) but no longer works at > time t(1). > > You can't build dependable automation around a system that is not > dependable. If the config is valid, it works today, tomorrow, next > year. It works on this box and on one I hot-swap in for it. It > works when I pull a PIC, it works when I stuff in a new one. The > config has to be dependable. It's the bedrock upon which all this > automation is built. > > If we view config validation as shifting sand, we're in for trouble. > I think you misunderstood my comment. If the router needs 'fresh' data from the network in order to validate the config, where fresh < (t(1) - t(0)), then the validation done at commit time will fail if the data is unavailable at t(1), but it was available to the operation at t(0). > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 08:51: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 20DA33A694F; Fri, 25 Jul 2008 08:51: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 17E323A69A1 for ; Fri, 25 Jul 2008 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlgcxmlQZdAo for ; Fri, 25 Jul 2008 08:51:25 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 3402B3A694F for ; Fri, 25 Jul 2008 08:51:25 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 08:51:15 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:51:13 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:51:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:49:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PFnNu05142; Fri, 25 Jul 2008 08:49:23 -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 m6PFkMIi062312; Fri, 25 Jul 2008 15:46:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807251546.m6PFkMIi062312@idle.juniper.net> To: Andy Bierman In-reply-to: <4889EF25.7000308@netconfcentral.com> Date: Fri, 25 Jul 2008 11:46:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 15:49:24.0325 (UTC) FILETIME=[02F17150:01C8EE6E] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >You removed the rest of the example, which pointed out >that for the sys-admin, a name and an email address were >mandatory, but for the guest admin, just an email address >is mandatory. The point of this contrived example >is that sometimes the DM writer needs to decide all-or-nothing >to use , not just uses refinement of the sub-nodes. I deleted the part because I thought it was making the same point, which is that many times the "use"r of the grouping needs the control, not the definer of the grouping. In your example, the grouping worked as written so the use statement had to refine it. >Change to if you want a better example. Put inside a grouping and try to reuse that. You need visibility into groupings to control these aspects. >Maybe YANG doesn't need to do any better, because nobody >cares about code/definition reuse for NETCONF. Control is more important that reuse, so being able to tune groupings is more important that seeing them as all-or-nothing. If you make it all-or-nothing, its utility is demolished. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 09:00: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 8A2EB3A6A48; Fri, 25 Jul 2008 09:00: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 EFC9C3A69BF for ; Fri, 25 Jul 2008 09:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq8yiATZuaCw for ; Fri, 25 Jul 2008 09:00:32 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 2DA6728C20D for ; Fri, 25 Jul 2008 09:00:03 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 08:58:24 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:59:48 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:59:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:59:47 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PFxku15221; Fri, 25 Jul 2008 08:59:46 -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 m6PFuiWk062478; Fri, 25 Jul 2008 15:56:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807251556.m6PFuiWk062478@idle.juniper.net> To: Andy Bierman In-reply-to: <4889F47F.2030100@netconfcentral.com> Date: Fri, 25 Jul 2008 11:56:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 15:59:47.0028 (UTC) FILETIME=[761A6140:01C8EE6F] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I think you misunderstood my comment. I don't think I did. You said that a config that commits successfully at one point in time may not commit at some later time, due to conditions outside the configuration. >If the router needs 'fresh' data from the network >in order to validate the config, where fresh < (t(1) - t(0)), >then the validation done at commit time will fail if >the data is unavailable at t(1), but it was available >to the operation at t(0). This will lead to scenarios like I listed. If you need "'fresh' data from the network" and can't get it, the validation will work differently than it will on the next commit. This means I would have no expectation that the next commit would work, even if the previous one did. When the network changes, my config may no longer commit. If the network is unreachable, I can't commit the fix. If there's a route flapping, my phone operator can't sell new services. A device can't depend on anything external during the commit process, because that external thing won't be there when you need it. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 09:02: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 22A4C3A67D0; Fri, 25 Jul 2008 09:02: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 7B1133A68F4 for ; Fri, 25 Jul 2008 09:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zcLkG-p4+FuO for ; Fri, 25 Jul 2008 09:02:48 -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 AB8053A67D0 for ; Fri, 25 Jul 2008 09:02:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Bj3/3M0ECnMFa0uSb3WlqBWYi5WnQJzKQ7h4XLKsWHr6d5kM8pRFWdkIlWZ3aI/W; 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 [66.167.204.25] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KMPkj-0003Br-Pp for netmod@ietf.org; Fri, 25 Jul 2008 12:02:46 -0400 Message-ID: <007501c8ee6f$edb1eb60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200807251525.m6PFPJgB062086@idle.juniper.net> <4889F47F.2030100@netconfcentral.com> Date: Fri, 25 Jul 2008 09:03:06 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3977036f94c87bc4c54cf5abbf124b49b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.25 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: Friday, July 25, 2008 8:42 AM > Subject: Re: [netmod] Why constrain keyref? ... > > If we view config validation as shifting sand, we're in for trouble. > > > > I think you misunderstood my comment. > If the router needs 'fresh' data from the network > in order to validate the config, where fresh < (t(1) - t(0)), > then the validation done at commit time will fail if > the data is unavailable at t(1), but it was available > to the operation at t(0). ... Expanding just a bit... The "configuration" that needs to be *operationally* validated is more than the little bit of XML shovelled around by Netconf protocol. A network's configuration also includes the specific bits of hardware, their hardware / firmware / software versions, what's plugged in where, which cables go where, what SLAs are in place with the carriers, and so on. If one has this complete picture, then the "shifting sand" metaphor doesn't apply. But to the extent that all this configuration data is ignored, ":netconf" is really a misnomer, and is merely "devconf". And if all we have validated is the XML that goes into a device, and not verified that the device has the correct hardware configuration and cabling and correctly configured peers, then "shifting sand" is indeed the correct image. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 09:05: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 80C663A6A48; Fri, 25 Jul 2008 09:05: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 D41EB3A6A21 for ; Fri, 25 Jul 2008 09:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, 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 0pz+uc+DJP5q for ; Fri, 25 Jul 2008 09:05:08 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 21C5628C17A for ; Fri, 25 Jul 2008 09:05:08 -0700 (PDT) Received: (qmail 7113 invoked from network); 25 Jul 2008 16:05:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 25 Jul 2008 16:05:05 -0000 X-YMail-OSG: AP3SUZQVM1mjFxTecEwfS1AH2nDeIE0V5ICceyf5KRuM_gy2.TYQEG2WJIuxB6Q8UpPGFciQ7tl39i9SqMe__z8Ic8HXtcyaii0kXZn_MQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4889F9B0.8000006@netconfcentral.com> Date: Fri, 25 Jul 2008 09:05:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807251546.m6PFkMIi062312@idle.juniper.net> In-Reply-To: <200807251546.m6PFkMIi062312@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> You removed the rest of the example, which pointed out >> that for the sys-admin, a name and an email address were >> mandatory, but for the guest admin, just an email address >> is mandatory. The point of this contrived example >> is that sometimes the DM writer needs to decide all-or-nothing >> to use , not just uses refinement of the sub-nodes. > > I deleted the part because I thought it was making the same point, > which is that many times the "use"r of the grouping needs the > control, not the definer of the grouping. In your example, the > grouping worked as written so the use statement had to refine it. > >> Change to if you want a better example. > > Put inside a grouping and try to reuse that. > You need visibility into groupings to control these aspects. > >> Maybe YANG doesn't need to do any better, because nobody >> cares about code/definition reuse for NETCONF. > > Control is more important that reuse, so being able to tune groupings > is more important that seeing them as all-or-nothing. If you make > it all-or-nothing, its utility is demolished. > groupings are like XSD groups, which are basically assembly or C language macro expansions. You are correct in that this construct provides no encapsulation features at all. But C and XSD also have complex data types, that do provide encapsulation features. When I read the ipfix-psamp data model, it sure looks like the authors wanted reusable complex types in some places but were forced to use groupings instead. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 09:11: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 CB1693A6A21; Fri, 25 Jul 2008 09:11: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 68EDD3A6A21 for ; Fri, 25 Jul 2008 09:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 6TP8nCDysAEe for ; Fri, 25 Jul 2008 09:11:42 -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 64BE93A6838 for ; Fri, 25 Jul 2008 09:11:42 -0700 (PDT) Received: (qmail 34736 invoked from network); 25 Jul 2008 16:11:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 16:11:42 -0000 X-YMail-OSG: tIr3WmAVM1knVCgawVJHdkG7xVO.IGxIGLfrgG.av5e4Mfss6otZ2P9UphWglgNWRCrpAw5QXRGJXxDtVL5.KtlV3tQOd4KJMqMQLYxoCg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4889FB3C.4020207@netconfcentral.com> Date: Fri, 25 Jul 2008 09:11:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807251556.m6PFuiWk062478@idle.juniper.net> In-Reply-To: <200807251556.m6PFuiWk062478@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I think you misunderstood my comment. > > I don't think I did. You said that a config that commits successfully > at one point in time may not commit at some later time, due to conditions > outside the configuration. > >> If the router needs 'fresh' data from the network >> in order to validate the config, where fresh < (t(1) - t(0)), >> then the validation done at commit time will fail if >> the data is unavailable at t(1), but it was available >> to the operation at t(0). > > This will lead to scenarios like I listed. If you need "'fresh' > data from the network" and can't get it, the validation will work > differently than it will on the next commit. This means I would > have no expectation that the next commit would work, even if the > previous one did. > > When the network changes, my config may no longer commit. If the > network is unreachable, I can't commit the fix. If there's a route > flapping, my phone operator can't sell new services. > > A device can't depend on anything external during the commit process, > because that external thing won't be there when you need it. > Here's a simple example: At time t(0), I set the VLAN assignment for an unused port, in the candidate config. It validates just fine. Later on, after that VLAN was removed from the network by somebody else, I the candidate, and it fails. > Thanks, > Phil > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 11:14: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 53DE63A6950; Fri, 25 Jul 2008 11:14: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 1EAF43A698A for ; Fri, 25 Jul 2008 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slYujT28oVxz for ; Fri, 25 Jul 2008 11:14:12 -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 99F393A6950 for ; Fri, 25 Jul 2008 11:14:12 -0700 (PDT) Received: (qmail 39332 invoked from network); 25 Jul 2008 18:14:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 18:14:13 -0000 X-YMail-OSG: ubNQuZ0VM1lh4lm9wy9OMa91PAjf.5JRJdmPAPqcR_QPPs5gYZoCV5Gw64tpCS8KH38EeTWygLwBpNsaXxQzASfvFYwdwDxrSdnnGpCR8g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A17F3.1040705@netconfcentral.com> Date: Fri, 25 Jul 2008 11:14:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] mandatory-stmt (again) X-BeenThere: netmod@ietf.org 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 From 4.2.7: choice snack { mandatory true; case sports-arena { leaf pretzel { type empty; } leaf beer { type empty; } } case late-night { leaf chocolate { type enumeration { enum dark; enum milk; enum first-available; } } } } This 'mandatory' seems to mean that 1 of the 2 cases must be present, but both cases are inline, and contain only optional leafs. If a uses-stmt was present instead, then every mandatory node within it would need to be undone with refinement statements. There is no control at the 'case' level or the 'choice' level. Since all the leafs are optional, then it seems like a completely missing value would be considered valid. But it's not. Sec 7.9 says: If a choice is marked with "mandatory true", at least one node from one of the cases must be present in a valid configuration. So the choice mandatory-stmt overrides the mandatory-stmt in the leafs. Why is this OK for 'choice' but not 'container'? From 7.6.4: If "mandatory" is "true", the node must exist in a valid configuration if its parent node exists. Since containers without a "presence" statement are implicitly created and deleted when needed, they are ignored when performing mandatory tests for leafs. A mandatory leaf within such a container is mandatory even if the container's data node does not exist. This text seems to support my notion of how mandatory-stmt is supposed to work within the data tree. Note the key phrase, "if its parent node exists". So a mandatory leaf does not ripple upwards in the object tree. It is enforced down the tree, whenever a given value node (e.g., name) is actually created. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 11:25: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 CAE1628C11D; Fri, 25 Jul 2008 11:25: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 9A09D28C108 for ; Fri, 25 Jul 2008 11:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATc44n+TPpgw for ; Fri, 25 Jul 2008 11:25:25 -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 110A73A6929 for ; Fri, 25 Jul 2008 11:25:24 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA07.westchester.pa.mail.comcast.net with comcast id uA7T1Z00L1GhbT857JRSAY; Fri, 25 Jul 2008 18:25:26 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id uJRS1Z0014HwxpC3TJRSWZ; Fri, 25 Jul 2008 18:25:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=t40o1_5MdO8aR_ek8S8A:9 a=mIv3QzdzArL5BmQ4vP4A:9 a=dleqMoohQfIN5IQiTaYA:7 a=OY6S40aIMTNJKDsN5HVl6EsGCRwA:4 a=OnwlB_Fi9scA:10 a=f7GxY0FH8QIA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , , References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> <48887808.4020205@ericsson.com> Date: Fri, 25 Jul 2008 14:25:25 -0400 Message-ID: <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjtioCqQYS/EgQBScqLI7Te+IDEUQA5wUbw In-Reply-To: <48887808.4020205@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [netmod] SMIv2->XSD X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 copied this to the netmod and opsawg WG mailing lists, since that is where datatype libraries should be discussed. You only see two immediate uses for SMIv2 datatypes in XSD because you only work on netconf standards. How about datatypes for my SNMP NMS that has an XML/XSD-capable database? Why do I have to wait for the Netmod WG to finish designing a language **specifically for use with netconf** before I can have a standard XSD to work with my SMIv2 datatypes in an SNMP-focused application? How about the implementing netconf that needs/wants to define XML-based datamodels to use with netconf, as suggested by RFC4741, and the company wants to leverage all the SMIv2 MIB support it already has available in its products and wants a standardized translation of SMIv2 datatypes NOW, not in 3-5 more years. Real world: the IETF network management world does not revolve around YANG. For 20 years, it has revolved around SMI datatypes, not YANG datatypes. XSDMI is an OPSAWG work item. We have already had this discussion mutliple times, and reached consensus to do XSDMI independent of YANG, but with an effort to coordinate with YANG. XSDMI is just about ready for WGLC. Netmod WG is finally going to have its first WG meeting. Netmod WG will not realistically finish anytime soon. And the IESG might eventually decide to not approve netmod's YANG language as a standard. So why does the whole SNMP community need to wait for SMIv2->YANG->XSD? If the available tools generate SMIv2->XSD translations that are valid, and the tools generate SMIv2->YANG->XSD translations that are valid but different, then either the YANG translation rules got it wrong or the YANG tools are trying to solve a different problam than the SMIv2->XSD translation. If I want a direct translation from SMIv2->XSD, why do I have to use YANG tools to do this? Juergen's suggested approaches include b) which is "coordinated" and c) which is "painful". I think this is a false characterization. b) is "painful" to those who have to wait possibly much longer for standard datatypes, especially for non-netconf applications, and c) and d) still have "coordination" so that the result is consistent. XSDMI has already slowed down its work by months to deliberately coordinate its work with the YANG datatypes work, so the two are very close already. Why don't we eliminate YANG-LIB and DSDL datatype work from netmod, and standardize SMIv2 "faithful" datatypes (i.e., with no netconf-specific "improvements") in XSDMI/OPSAWG (possibly using translation rules rather than hand translations) and then netmod (YANG, XML-on-the-wire, and the DSDL mapping) can use the OPSAWG standard datatype library? That way, a standard datatypes library could be available much sooner for applicability to netconf, non-netconf, netmod and non-netmod uses rather than making everybody wait for netmod. If you are convinced that netmod will add some specific requirements that we don't even know about yet, then let's not make XSDMI and the SNMP community and the non-YANG Netconf community wait for netmod to decide what those are since they are obviously not requirements of SMIv2, and XSDMI is all about SMIv2, not netmod. dbh > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Thursday, July 24, 2008 8:40 AM > To: Romascanu, Dan (Dan); David Harrington; Natale, Bob; > Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hello, > I see two immediate users of the datatypes: XSD in new drafts > e.g. Netconf Monitoring, and the > DSDL mapping. They can either: > - Assume solution b) coordinated, consistent datatypes > - Start working on draft-wonderful-xsd-datatypes-for-netconf > The latter will need extra work, time and authors. > balazs > > Juergen Schoenwaelder wrote: > > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan > (Dan) wrote: > > > >> So, in your opinion, the specification of the translation > rules should > >> be the sole (principal?) scope of standardization in this > area? Or is > >> there a need to optimize the output to get that 'better > quality' level > >> for some of the commonly used structures? > > > > There are two work items we have to distinguish: > > > > a] The first work item is reuse of existing SMIv2 definitions in XML > > based protocols and for this we need translation rules. > Whether the > > rules contain very specific rules to deal with some specific but > > frequently occuring constructs is subject to the group > defining the > > rules. At the end, however, everything has to be automatic since > > nobody is going to hand translate stuff that is out there. > > > > b] The second work item are data types for new definitions. In some > > cases, translation rules will not produce reasonable results (a > > good example is the InetAddress family of TCs that try to work > > around the lack of proper unions in the SMIv2). While any new > > definitions should align to existing definitions as much as > > possible, there will be cases where this requires discussion. For > > me, the BridgeID is a good example of this kind of discussion and > > there is in my view no way to avoid these discussions for cases > > where the binary representation implied by the SMIv2 > does not match > > the more textual XSD approach or where the SMIv2 > representation is > > specific to SNMP and SMIv2 limitations which do not > exist in other > > XML based protocols such as NETCONF. > > > > My understanding was that XSDMI is addressing a] while NETMOD will > > work on b] to produce reusable constructs for new configuration data > > models. > > > > Excursion to the real world: I am familiar with a particular > > implementation that has translation rules to directly translate > > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > > efforts to specify how to translate YANG->XSD. So given > FOO-MIB, I can > > do already today: > > > > 1) FOO-MIB -> FOO-MIB.xsd > > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > > > And the result is not the same. Assuming that NETCONF will > be used to > > provide access to SMIv2 instrumentation, I believe we are > in trouble. > > > > Back from the real world to the IETF: There is a work item in the > > OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG > > (the YANG->XSD mapping). So from your perspective, you can say there > > is no problem as of now. ;-) > > > > In practice, there is already running code for all of this and if we > > do not find a way to make the translation rules consistent in time > > (whatever that means in the IETF ;-), I believe we will see that > > people use differnet translation rules and we are going to pay the > > bill later on. > > > > There are different solutions possible to deal with this issue. Some > > solutions I quickly can come up with (but this is not meant to be a > > complete list): > > > > a) Translation of SMIv2 to YANG is simply forbitten, only the direct > > translation to XSD is allowed. > > > > b) Both translations are developed at the same time and we > ensure that > > things are coordinated and that at the end that the > outcome of the > > two translation paths is consistent. > > > > c) Both translation roads are engineered in parallel and > who completes > > first wins and the other one has to adapt to the winner, > regardless > > how painful this will be. > > > > d) Settle on a single translation approach but make sure > that everyone > > interested in the other approach is made aware to follow > it closely > > to ensure that problems are avoided (this is essentially > b) without > > managed coordination). > > > > e) Declare that this problem is not worth solving since XML > namespaces > > will take care of the differences and application > writers can deal > > with it. > > > > f) Postpone the problem. > > > > All I am suggesting is to discuss this issue openly and fairly on > > technical grounds with the goal to avoid incompatible XSD > translations > > of SMIv2 modules. > > > > /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 Jul 25 11:38: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 1E44D3A69B6; Fri, 25 Jul 2008 11:38: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 3740A3A69A9 for ; Fri, 25 Jul 2008 11:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrjejBB6391z for ; Fri, 25 Jul 2008 11:38:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6CDF628C16A for ; Fri, 25 Jul 2008 11:38:44 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id D240676C22D; Fri, 25 Jul 2008 20:38:45 +0200 (CEST) Date: Fri, 25 Jul 2008 20:38:40 +0200 (CEST) Message-Id: <20080725.203840.196866943.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4889F9B0.8000006@netconfcentral.com> References: <200807251546.m6PFkMIi062312@idle.juniper.net> <4889F9B0.8000006@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > groupings are like XSD groups, which are basically assembly or C > language macro expansions. You are correct in that this construct > provides no encapsulation features at all. > > But C and XSD also have complex data types, that do provide > encapsulation features. When I read the ipfix-psamp data model, > it sure looks like the authors wanted reusable complex types > in some places but were forced to use groupings instead. Can you make a proposal for what you want? Are you suggesting that if we allow mandatory in containers, then groupings are better complex types?? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 11:48:59 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3EA28C16A; Fri, 25 Jul 2008 11:48:59 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E8328C188 for ; Fri, 25 Jul 2008 11:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 OIyqVjC+3xRT for ; Fri, 25 Jul 2008 11:48:57 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id ADE8528C16A for ; Fri, 25 Jul 2008 11:48:57 -0700 (PDT) Received: (qmail 4724 invoked from network); 25 Jul 2008 18:48:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 18:48:51 -0000 X-YMail-OSG: IT8HwZYVM1mrot9o5raYNNcVpbYwc433j7yUcIplEE_pfxaVCUJhY.YOrvlsEOnM8eiGVtPHog1DATOqLj1u4vvWFjWQiQopgkVhztApvg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A2012.3080505@netconfcentral.com> Date: Fri, 25 Jul 2008 11:48:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200807251546.m6PFkMIi062312@idle.juniper.net> <4889F9B0.8000006@netconfcentral.com> <20080725.203840.196866943.mbj@tail-f.com> In-Reply-To: <20080725.203840.196866943.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: >> groupings are like XSD groups, which are basically assembly or C >> language macro expansions. You are correct in that this construct >> provides no encapsulation features at all. >> >> But C and XSD also have complex data types, that do provide >> encapsulation features. When I read the ipfix-psamp data model, >> it sure looks like the authors wanted reusable complex types >> in some places but were forced to use groupings instead. > > Can you make a proposal for what you want? Are you suggesting that if > we allow mandatory in containers, then groupings are better complex > types?? > I do not want complex types. I already said I don't like presence-stmt and prefer mandatory-stmt instead. > > /martin > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 13: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 F2C123A694F; Fri, 25 Jul 2008 13:38: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 578893A68C3; Fri, 25 Jul 2008 13:38:20 -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.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-AHk2zhfjYB; Fri, 25 Jul 2008 13:38:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 850CD3A68AE; Fri, 25 Jul 2008 13:38:19 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 03BC476C22D; Fri, 25 Jul 2008 22:38:20 +0200 (CEST) Date: Fri, 25 Jul 2008 22:38:17 +0200 (CEST) Message-Id: <20080725.223817.240580203.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> References: <20080724083958.GC5161@elstar.local> <48887808.4020205@ericsson.com> <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: opsawg@ietf.org, netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [OPSAWG] SMIv2->XSD X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "David Harrington" wrote: > How about the implementing netconf that needs/wants > to define XML-based datamodels to use with netconf, as suggested by > RFC4741, and the company wants to leverage all the SMIv2 MIB support > it already has available in its products and wants a standardized > translation of SMIv2 datatypes NOW, not in 3-5 more years. Several companies already do this, in proprietary ways. But the datatype translation is just one part (maybe the easy one). Other things to consider for a standard SMIv2->XML mapping are: what does the XML structure look like? What is the top-level element for a given MIB? Which namespace URI is used? How are INDEXes encoded? How are INDEXes in foreign tables encoded? How is RowStatus handled? How is StorageType handled? I think it has been said before, but I would rather see a mapping of SMIv2 (types and structure) to XML, than XSD. If there was a mapping to XML, tools could generate compliant XSD, RNG, or YANG. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 13:42:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44913A6965; Fri, 25 Jul 2008 13:42:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E006A3A69A1 for ; Fri, 25 Jul 2008 13:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrkuzmp9LjB8 for ; Fri, 25 Jul 2008 13:42:04 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 4B6DA3A6965 for ; Fri, 25 Jul 2008 13:42:02 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 13:41:14 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, 25 Jul 2008 13:41:14 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 13:41:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 13:38:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PKchu46503; Fri, 25 Jul 2008 13:38:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6PKZfRC064255; Fri, 25 Jul 2008 20:35:41 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807252035.m6PKZfRC064255@idle.juniper.net> To: Andy Bierman In-reply-to: <488A2012.3080505@netconfcentral.com> Date: Fri, 25 Jul 2008 16:35:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 20:38:43.0849 (UTC) FILETIME=[6E069790:01C8EE96] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I already said I don't like presence-stmt and >prefer mandatory-stmt instead. The confusing part is that this isn't an "either-or". These are two different concepts. The "precence" statement tells us that the container has a meaning, and isn't merely there to organize/scope other nodes. Mandatory means the node must exist in order for the configuration to be considered valid. Consider: Does this container mean something if it appears? yes no +-----+-----+ Does this yes| A | B | container +-----+-----+ have to no | C | D | exist? +-----+-----+ A : meaningful and mandatory B : organizational and mandatory C : meaningful D : organizational D is the default case C is the "presence" case B is implicit if one child is mandatory A is nonsensical (If it means something, you can't force it to appear) What you want (what I think you want anyway) is for case B to be explicit. This is unrelated to presence. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 13:48:48 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7FF3A685F; Fri, 25 Jul 2008 13:48:48 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3809F3A685F for ; Fri, 25 Jul 2008 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id istKwGAXqHZj for ; Fri, 25 Jul 2008 13:48:46 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 457703A6965 for ; Fri, 25 Jul 2008 13:48:45 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 13:48:43 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, 25 Jul 2008 13:48:32 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 13:48:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 13:48:30 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PKmUu49382; Fri, 25 Jul 2008 13:48: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 m6PKjSxl064351; Fri, 25 Jul 2008 20:45:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807252045.m6PKjSxl064351@idle.juniper.net> To: Andy Bierman In-reply-to: <4889FB3C.4020207@netconfcentral.com> Date: Fri, 25 Jul 2008 16:45:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 20:48:30.0897 (UTC) FILETIME=[CBEF0210:01C8EE97] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >At time t(0), I set the VLAN assignment for an unused port, >in the candidate config. It validates just fine. >Later on, after that VLAN was removed from the network by >somebody else, I the candidate, and it fails. So your view is that I shouldn't be able to add a VLAN to an in-use port if the other side doesn't have that VLAN configured? If my device is a CPE router attached to a customer-owned switch, and they change the config on their switch, my device config will no longer commit? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 13:49: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 17D313A685F; Fri, 25 Jul 2008 13:49: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 3548A3A69E5 for ; Fri, 25 Jul 2008 13:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0Ktbrc1WdqR for ; Fri, 25 Jul 2008 13:49:23 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 68C693A685F for ; Fri, 25 Jul 2008 13:49:23 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 8110976C22D; Fri, 25 Jul 2008 22:49:25 +0200 (CEST) Date: Fri, 25 Jul 2008 22:49:22 +0200 (CEST) Message-Id: <20080725.224922.50092172.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4889EF25.7000308@netconfcentral.com> References: <200807251453.m6PErYGa061330@idle.juniper.net> <4889EF25.7000308@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Groupings are pretty > worthless, since I have to be totally aware of the context > of the uses when writing the grouping Can you expand on this a bit? Which "context of the uses" do I have to be aware of when I write my grouping? > and also > need to be totally aware of the grouping contents > when I write the uses. You probably *should* be aware of the grouping's contents if you use the grouping. But nothing forces you to. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 13:57: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 B82BF3A685F; Fri, 25 Jul 2008 13:57: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 B40C43A687D for ; Fri, 25 Jul 2008 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLrWaAC4iHAp for ; Fri, 25 Jul 2008 13:57:30 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4BF3C3A685F for ; Fri, 25 Jul 2008 13:57:30 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 13:57:32 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, 25 Jul 2008 13:56:54 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 13:56:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 13:56:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PKuru51848; Fri, 25 Jul 2008 13:56:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6PKrlZo064451; Fri, 25 Jul 2008 20:53:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807252053.m6PKrlZo064451@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <007501c8ee6f$edb1eb60$6801a8c0@oemcomputer> Date: Fri, 25 Jul 2008 16:53:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 20:56:53.0806 (UTC) FILETIME=[F7B0D4E0:01C8EE98] Cc: netmod@ietf.org Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.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: >The "configuration" that needs to be *operationally* validated is more >than the little bit of XML shovelled around by Netconf protocol. A >network's configuration also includes the specific bits of hardware, >their hardware / firmware / software versions, what's plugged in >where, which cables go where, what SLAs are in place with the >carriers, and so on. Absolutely. Device config is only part of network config, and the network won't work if the whole thing isn't set up correctly. But the bit we're discussing is what happens when you make a device's config depend on transient things like FRU state and the state of other devices. If you let the device config fail commit in such scenarios, you increase the fragility of the device and remove the idea that incremental changes will succeed incrementally. If I add a piece of interface config, I'm not expecting unrelated BGP config to fail. I can't even rollback my changes and commit. I'm totally broken. >If one has this complete picture, then the >"shifting sand" metaphor doesn't apply. But to the extent that all >this configuration data is ignored, ":netconf" is really a misnomer, >and is merely "devconf". And if all we have validated is the XML >that goes into a device, and not verified that the device has the correct >hardware configuration and cabling and correctly configured peers, >then "shifting sand" is indeed the correct image. This topic is unrelated to XML. The same issues are present if you change config via expect-over-cli. If you can't depend on the same config to commit twice in a row, you can't build dependable automation. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 14:04: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 94FF53A685F; Fri, 25 Jul 2008 14:04: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 0A5723A687D for ; Fri, 25 Jul 2008 14:04:52 -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.034, 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 CZFSa013sFrl for ; Fri, 25 Jul 2008 14:04:51 -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 577943A685F for ; Fri, 25 Jul 2008 14:04:51 -0700 (PDT) Received: (qmail 27892 invoked from network); 25 Jul 2008 21:04:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 25 Jul 2008 21:04:44 -0000 X-YMail-OSG: 6v.LioIVM1nMbuWu7QE4_vdeZPWOWGvX0EIH8boXg2F1ICHCu6N8.auJMFvDP9jR2zNNFpzwyt70RbQ3iUaemowyafRABqcecCZqDdwxYQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A3FEA.9010202@netconfcentral.com> Date: Fri, 25 Jul 2008 14:04:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807252035.m6PKZfRC064255@idle.juniper.net> In-Reply-To: <200807252035.m6PKZfRC064255@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I already said I don't like presence-stmt and >> prefer mandatory-stmt instead. > > The confusing part is that this isn't an "either-or". These > are two different concepts. The "precence" statement tells > us that the container has a meaning, and isn't merely there > to organize/scope other nodes. Mandatory means the node must > exist in order for the configuration to be considered valid. > Consider: > > Does this container > mean something if it appears? > yes no > +-----+-----+ > Does this yes| A | B | > container +-----+-----+ > have to no | C | D | > exist? +-----+-----+ > > > A : meaningful and mandatory > B : organizational and mandatory > C : meaningful > D : organizational > > D is the default case > C is the "presence" case > B is implicit if one child is mandatory > A is nonsensical (If it means something, you can't force it to appear) > > What you want (what I think you want anyway) is for > case B to be explicit. This is unrelated to presence. > I want to be able to control a data model sub-structure at any point in the tree. I can do that for the other interior node types (list and choice) but not container. You cannot turn the presence-stmt off in a uses refinement like you can with must-stmt. I do not agree that the presence-stmt adds much value at all. Why do we need a special description clause for this? Why can't the description clause for the list itself say what it means for an empty container to be present. This special case makes YANG confusing, not better. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 14:12: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 DC2903A69E5; Fri, 25 Jul 2008 14:12: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 C048A3A69E9 for ; Fri, 25 Jul 2008 14:12:10 -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.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpfhXuxE9ZO5 for ; Fri, 25 Jul 2008 14:12:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 054313A69E5 for ; Fri, 25 Jul 2008 14:12:09 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id ECC5976C22D; Fri, 25 Jul 2008 23:12:11 +0200 (CEST) Date: Fri, 25 Jul 2008 23:12:07 +0200 (CEST) Message-Id: <20080725.231207.143633622.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <488A3FEA.9010202@netconfcentral.com> References: <200807252035.m6PKZfRC064255@idle.juniper.net> <488A3FEA.9010202@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I want to be able to control a data model sub-structure > at any point in the tree. I can do that for the > other interior node types (list and choice) > but not container. Are you thinking about something else than turning off presence? > You cannot turn the presence-stmt off in a uses refinement > like you can with must-stmt. > > I do not agree that the presence-stmt adds much value at > all. Why do we need a special description clause for this? This can be solved by changing presence to presence , which we have discussed a couple of times before. Can you think of a use case where you would like to change a presence container into an organizational? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 14:29: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 AF7E83A69E5; Fri, 25 Jul 2008 14:29: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 BD54F28C0EE for ; Fri, 25 Jul 2008 14:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dd8DN2rH4q9 for ; Fri, 25 Jul 2008 14:29:17 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 490B53A69E5 for ; Fri, 25 Jul 2008 14:29:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 14:27:30 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, 25 Jul 2008 14:28:48 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 14:28:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 14:28:47 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PLSlu61967; Fri, 25 Jul 2008 14:28: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 m6PLPjdP064856; Fri, 25 Jul 2008 21:25:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807252125.m6PLPjdP064856@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080725.231207.143633622.mbj@tail-f.com> Date: Fri, 25 Jul 2008 17:25:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 21:28:47.0366 (UTC) FILETIME=[6C42EA60:01C8EE9D] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: >This can be solved by changing presence to presence , >which we have discussed a couple of times before. Perhaps the fix should be to use a different term for these meaningful containers. I suggest "block", but am open to any other name. This would give us: container system { container services { block ssh { description "Secure Shell"; presence "Enable SSH server"; leaf rate-limit { description " Maximum number of connections per minute" type int { range 1..250; } } container protocol-version { description "Define version of the SSH protocol are allowed"; leaf v1 { description "Allow SSH V1"; type empty; } leaf v2 { type empty; description "Allow SSH V2"; } } } } } The CLI and GUI can "know" that system/services/ssh means something. The "presence" statement remains, to tell the user what this statement's presence indicates. This segregates meaningful containers away from organizational ones, which isn't completely a good thing. Another option would be to add a "type" statement to containers that defaults to "organizational" but can be set to "meaningful" when needed. (Not hung up on the terms at all; totally open to better words.) container ssh { type meaningful; // "type presence"? ... } Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 14:36: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 BFAE93A68AE; Fri, 25 Jul 2008 14:36: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 BE1603A6948 for ; Fri, 25 Jul 2008 14:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNvApzh8jTjg for ; Fri, 25 Jul 2008 14:36:17 -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 DA4413A68AE for ; Fri, 25 Jul 2008 14:36:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pYO53ZuuKebTz//10jqq1xV+YRnZ+OgtxJQJDqIM29R/VTAI5bBN+Xx06LFJm0hM; 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.88.178] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KMUxN-0005t3-0b for netmod@ietf.org; Fri, 25 Jul 2008 17:36:09 -0400 Message-ID: <004b01c8ee9e$71f84a80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200807252053.m6PKrlZo064451@idle.juniper.net> Date: Fri, 25 Jul 2008 14:35:40 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3a36a020250b8e704fc58b19fdf0de0d7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.88.178 Subject: Re: [netmod] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: "Randy Presuhn" > Cc: > Sent: Friday, July 25, 2008 1:53 PM > Subject: Re: [netmod] Why constrain keyref? ... > This topic is unrelated to XML. The same issues are present if you > change config via expect-over-cli. If you can't depend on the same > config to commit twice in a row, you can't build dependable automation. I agree that the topic is independent of XML. It arises for *any* kind of configuration data modeling effort. But it's not safe to ignore it just because it's a generic problem. This discussion is spiraling in on these questions: 1) what are the expectations when a configuration is proclaimed "valid" 2) is a deviced allowed to reject the commit of a configuration which is valid according to the schema, but which is "operationally" invalid 3) are the conditions used to determine whether a commit will succeed allowed to change over time? Whatever (1) is, it needs to be clearly stated, particularly regarding whether the notion of "valid" is defined *purely" in terms of the schema definition, and can be evaluated by looking only at the schema and the configuration document. Whether one likes it or not, (2) is going to happen. To the extent that things like out-of-memory or required-interface-missing- from-hardware do change over time, we're also stuck with (3). If hardware and inter/intra-system dependencies were static, then it would be reasonable to assume that if a config commits once it will commit again. But if someone has swapped out the boards for wrong rev-level replacements, it shouldn't surprise anyone if the commit fails. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 14:39:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267F83A6996; Fri, 25 Jul 2008 14:39:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A8B3A6996 for ; Fri, 25 Jul 2008 14:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kERjXn3PDdOo for ; Fri, 25 Jul 2008 14:39:36 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 751983A69F8 for ; Fri, 25 Jul 2008 14:39:36 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id F2A6276C22D; Fri, 25 Jul 2008 23:39:37 +0200 (CEST) Date: Fri, 25 Jul 2008 23:39:32 +0200 (CEST) Message-Id: <20080725.233932.77915370.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48891F50.7080609@netconfcentral.com> References: <488762C5.30407@netconfcentral.com> <20080724.234738.175261842.mbj@tail-f.com> <48891F50.7080609@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > going back to the 'name' example: > > grouping Name { > container name { > .... > } > } > > YANG has no way to control how Name is used in different > contexts. I don't understand this comment. You can control how Name is used down to every leaf in the refinment part of 'uses'. > If I had a data model designed with a 'default > administrator name', then the entire 'name' container > would be optional in that data model. > > In another data model, the 'name' container may be mandatory > because there is no default to use instead. > > But I can't design a grouping with a container in it, > because if that container has any mandatory fields, > it ripples up and makes the parent container mandatory. I don't agree with your terminology, but wouldn't you get the same effect if you make a container mandatory? In your example: > Unless I could do this: > > > container admin { > container sys-admin { > uses Name { > container name { > mandatory true; > } > } > uses Email; > } Since you marked the 'name' container mandatory, 'sys-admin' is now "mandatory" etc. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 14:47: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 BF2D33A6862; Fri, 25 Jul 2008 14:47: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 F0CE53A68AE for ; Fri, 25 Jul 2008 14:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 907rLJS1jQRD for ; Fri, 25 Jul 2008 14:47:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B09A3A6862 for ; Fri, 25 Jul 2008 14:47:35 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 6BAD576C22D; Fri, 25 Jul 2008 23:47:37 +0200 (CEST) Date: Fri, 25 Jul 2008 23:47:34 +0200 (CEST) Message-Id: <20080725.234734.200525085.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <004b01c8ee9e$71f84a80$6801a8c0@oemcomputer> References: <200807252053.m6PKrlZo064451@idle.juniper.net> <004b01c8ee9e$71f84a80$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] Why constrain keyref? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > This discussion is spiraling in on these questions: > 1) what are the expectations when a configuration is proclaimed "valid" > 2) is a deviced allowed to reject the commit of a configuration which > is valid according to the schema, but which is "operationally" invalid > 3) are the conditions used to determine whether a commit will succeed > allowed to change over time? > > Whatever (1) is, it needs to be clearly stated, particularly regarding > whether the notion of "valid" is defined *purely" in terms of the > schema definition, and can be evaluated by looking only at the > schema and the configuration document. Currently in YANG we give necessary conditions for a configuration to be valid (keyref, unique, must, min/max elements). We never say that they are sufficient. > Whether one likes it or not, (2) is going to happen. > To the extent that things like out-of-memory or required-interface-missing- > from-hardware do change over time, we're also stuck with (3). Agreed. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 14:48:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38CE13A6862; Fri, 25 Jul 2008 14:48:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D2F3A69CD for ; Fri, 25 Jul 2008 14:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 sgYmlekdI1p1 for ; Fri, 25 Jul 2008 14:48:51 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 0082D3A68AE for ; Fri, 25 Jul 2008 14:48:50 -0700 (PDT) Received: (qmail 28051 invoked from network); 25 Jul 2008 21:48:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 21:48:51 -0000 X-YMail-OSG: xujEwZYVM1lm.TVt_FVridnD7xr2va0puBvoVTRuMtIlDzFvbKOJppl2RET5kzAki0OY55LJlJfJZWA0giRF5SObTeAfjAgD.F91X37WPw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A4A42.40103@netconfcentral.com> Date: Fri, 25 Jul 2008 14:48:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <488762C5.30407@netconfcentral.com> <20080724.234738.175261842.mbj@tail-f.com> <48891F50.7080609@netconfcentral.com> <20080725.233932.77915370.mbj@tail-f.com> In-Reply-To: <20080725.233932.77915370.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: >> going back to the 'name' example: >> >> grouping Name { >> container name { >> .... >> } >> } >> >> YANG has no way to control how Name is used in different >> contexts. > > I don't understand this comment. You can control how Name is used > down to every leaf in the refinment part of 'uses'. That isn't really control over the element at all. Turning off every mandatory leaf is not user-friendly. > >> If I had a data model designed with a 'default >> administrator name', then the entire 'name' container >> would be optional in that data model. >> >> In another data model, the 'name' container may be mandatory >> because there is no default to use instead. >> >> But I can't design a grouping with a container in it, >> because if that container has any mandatory fields, >> it ripples up and makes the parent container mandatory. > > I don't agree with your terminology, but wouldn't you get the same > effect if you make a container mandatory? In your example: > >> Unless I could do this: >> >> >> container admin { >> container sys-admin { >> uses Name { >> container name { >> mandatory true; >> } >> } >> uses Email; >> } > > Since you marked the 'name' container mandatory, 'sys-admin' is now > "mandatory" etc. Yes, by the rules in the draft-00 I do not agree with, it is. I would rather that sys-admin have its own mandatory-flag, which is still default false. I do not like the presence-stmt and its special rules at all. The draft says "if the parent is present", which makes sense to me. All the rules about ignoring this kind of container or that kind, based on the sub-tree mandatory flags and the presence-stmt -- it's seems too complicated to be correct. > > > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 15:04: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 20E263A6859; Fri, 25 Jul 2008 15:04: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 BBE163A68AE for ; Fri, 25 Jul 2008 15:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 HRUExYruz3xO for ; Fri, 25 Jul 2008 15:04:50 -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 CC9953A6859 for ; Fri, 25 Jul 2008 15:04:49 -0700 (PDT) Received: (qmail 4400 invoked from network); 25 Jul 2008 22:04:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 22:04:51 -0000 X-YMail-OSG: 4UsfE64VM1n1KblQou_VYFWxZGqrOM5REnHLCLcf27o7cdOCX2quHFyaiGgPPlH77rKi2WIvhKS.w60k1ig4y3MEz6T9t41_89e5OMV00Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A4E00.8050709@netconfcentral.com> Date: Fri, 25 Jul 2008 15:04:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807252125.m6PLPjdP064856@idle.juniper.net> In-Reply-To: <200807252125.m6PLPjdP064856@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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: >> This can be solved by changing presence to presence , >> which we have discussed a couple of times before. > > Perhaps the fix should be to use a different term for these > meaningful containers. I suggest "block", but am open to > any other name. This would give us: > > container system { > container services { > block ssh { > description "Secure Shell"; > presence "Enable SSH server"; > leaf rate-limit { > description " Maximum number of connections per minute" > type int { > range 1..250; > } > } > container protocol-version { > description "Define version of the SSH protocol are allowed"; > leaf v1 { > description "Allow SSH V1"; > type empty; > } > leaf v2 { > type empty; > description "Allow SSH V2"; > } > } > } > } > } > I am interested in the ability to create arbitrary-sized building blocks, or sub-structures, out of containers. They are not meaningless. They provide permanent name collision protection, so they are much more bullet-proof when used in groupings. What if I wanted protocol-version above to be a reusable construct called SshProtocolVersion, without having to muck with the entire contents everywhere a uses-stmt for the grouping exists? I just want to write uses SshProtocolVersion { mandatory false; } or maybe: uses SshProtocolVersion { mandatory true; } and let the compiler do all the low-level revisions. One of the biggest complaints I got from SNMP NMS developers during all the years I wrote agent code was that SNMP had no reuse. No 2 MIBs seem to do the same similar thing in the same way. At every level, all the way down to how an address or a protocol version is specified. Every MIB was a 'hard-craft or nothing' kind of project. Just like CLI. I was hoping YANG could do better than that. > The CLI and GUI can "know" that system/services/ssh means > something. The "presence" statement remains, to tell the > user what this statement's presence indicates. > > This segregates meaningful containers away from organizational > ones, which isn't completely a good thing. > > Another option would be to add a "type" statement to containers > that defaults to "organizational" but can be set to "meaningful" > when needed. (Not hung up on the terms at all; totally open to > better words.) > > container ssh { > type meaningful; // "type presence"? > ... > } > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 16:11: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 1AF013A67AD; Fri, 25 Jul 2008 16:11: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 A22413A68AE for ; Fri, 25 Jul 2008 16:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftfSWyR-200A for ; Fri, 25 Jul 2008 16:11:42 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id AAC843A67AD for ; Fri, 25 Jul 2008 16:11:40 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 16:11:12 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 16:11:13 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 16:11:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 16:02:16 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6PN2Fu91214; Fri, 25 Jul 2008 16:02:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6PMxDN4065739; Fri, 25 Jul 2008 22:59:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807252259.m6PMxDN4065739@idle.juniper.net> To: Andy Bierman In-reply-to: <488A4E00.8050709@netconfcentral.com> Date: Fri, 25 Jul 2008 18:59:13 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2008 23:02:16.0058 (UTC) FILETIME=[7B4D65A0:01C8EEAA] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman writes: >I am interested in the ability to create arbitrary-sized >building blocks, or sub-structures, out of containers. >They are not meaningless. They provide permanent >name collision protection, so they are much more bullet-proof >when used in groupings. When I say "meaningful" I mean the appearance of the node in a configuration conveys a specific meaning. In my example, the "ssh" node turns on the ssh server. When I say "meaningless", I mean the appearance of the node in a configuration conveys no meaning. In my example, the "services" no has no meaning of its own. It serves as a container to hold the "services" offer by the system. Use of this term is not meant to bequeath or demolish the inherent nobility of nodes of any class, color, or modeling language. > uses SshProtocolVersion { > mandatory true; > } What does it mean to make the "use" of a grouping mandatory? Is every node in that grouping now mandatory? Are you seeing this as a serious modeling need? Even if "protocol-version" were the only thing inside the grouping SshProtocolVersion, what would marking it mandatory mean? "protocol-version" has two child nodes, neither of which is mandatory. This means I now have to create the node, even though it has no intrinsic meaning. This means that a device has to throw an error if the application fails to create a node that both the client and the server agree has no intrinsic value. Is that what you are wanting? >Every MIB was a 'hard-craft or nothing' kind of project. >Just like CLI. >I was hoping YANG could do better than that. This was not a technology problem. YANG will not stop 60 cooks from making 60 recipes for spaghetti sauce. My experience is that backbone, hard work, and endless meetings are the only say to convince people that their sauce is not sufficiently different from the standard sauce to cover the cost of making it, bottling it, and selling it. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 16:41: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 AE70B3A6879; Fri, 25 Jul 2008 16:41: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 CEE563A6879 for ; Fri, 25 Jul 2008 16:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 39QqAQEBQ4Cp for ; Fri, 25 Jul 2008 16:41:20 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id D19443A63EC for ; Fri, 25 Jul 2008 16:41:19 -0700 (PDT) Received: (qmail 24188 invoked from network); 25 Jul 2008 23:41:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 23:41:21 -0000 X-YMail-OSG: 5nFcJxkVM1kojN_9AamR7zVrYf2NTiYGnQEQCzU2teMsn22LHQi9bikIGrQQs9y1KBnLk5rTTz041wBrn9BogN8ZnL52GeyNH7TcEIjMVA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A649E.8040104@netconfcentral.com> Date: Fri, 25 Jul 2008 16:41:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807252259.m6PMxDN4065739@idle.juniper.net> In-Reply-To: <200807252259.m6PMxDN4065739@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> I am interested in the ability to create arbitrary-sized >> building blocks, or sub-structures, out of containers. >> They are not meaningless. They provide permanent >> name collision protection, so they are much more bullet-proof >> when used in groupings. > > When I say "meaningful" I mean the appearance of the node > in a configuration conveys a specific meaning. In my example, > the "ssh" node turns on the ssh server. > > When I say "meaningless", I mean the appearance of the node > in a configuration conveys no meaning. In my example, the > "services" no has no meaning of its own. It serves as a > container to hold the "services" offer by the system. > > Use of this term is not meant to bequeath or demolish > the inherent nobility of nodes of any class, color, or > modeling language. > >> uses SshProtocolVersion { >> mandatory true; >> } > > What does it mean to make the "use" of a grouping mandatory? > Is every node in that grouping now mandatory? Are you seeing > this as a serious modeling need? > What I really need to make the abstraction in the data model match the conceptual data model is a complex data type, but I'm willing to try the grouping approach instead. In this example, I may want different properties for different usages: container ssh-client { uses SshProtocolVersion { mandatory false; description "If missing, then the SSH client software will use any SSH protocol version. If present, then only the specified protocol versions will be used."; } // more fields here... } container ssh-server { uses SshProtocolVersion { mandatory true; description "The SSH server will only use the specified protocol versions."; } // more fields here... } In a data model for monitoring, I may want to report an SSH protocol version, and might want a non-config version: container host-ssh-versions { uses SshProtocolVersion { config false; } } > Even if "protocol-version" were the only thing inside the grouping > SshProtocolVersion, what would marking it mandatory mean? > "protocol-version" has two child nodes, neither of which is mandatory. > This means I now have to create the node, even > though it has no intrinsic meaning. This means that a device has > to throw an error if the application fails to create a node that > both the client and the server agree has no intrinsic value. Is > that what you are wanting? > >> Every MIB was a 'hard-craft or nothing' kind of project. >> Just like CLI. >> I was hoping YANG could do better than that. > > This was not a technology problem. YANG will not stop 60 cooks > from making 60 recipes for spaghetti sauce. My experience is that > backbone, hard work, and endless meetings are the only say to > convince people that their sauce is not sufficiently different from > the standard sauce to cover the cost of making it, bottling it, and > selling it. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 19:09: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 35B7D3A67E1; Fri, 25 Jul 2008 19:09: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 9F88C3A6870 for ; Fri, 25 Jul 2008 19:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 PiaIkIISqH1z for ; Fri, 25 Jul 2008 19:09:00 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id CEDB63A67E1 for ; Fri, 25 Jul 2008 19:08:59 -0700 (PDT) Received: (qmail 96335 invoked from network); 26 Jul 2008 02:09:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 26 Jul 2008 02:09:01 -0000 X-YMail-OSG: s7RnjaAVM1mY_HDOsmgzIm1Nq6zeNQNpqNUWcxIIYjzhwEnK7HfmDPmMCGAoGlrhbTAoaw9EE0W822vSei3mQ5QtQAppwxtp_iK7fburWg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A873B.3040601@netconfcentral.com> Date: Fri, 25 Jul 2008 19:08:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807252259.m6PMxDN4065739@idle.juniper.net> <488A649E.8040104@netconfcentral.com> In-Reply-To: <488A649E.8040104@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Phil Shafer wrote: It's just a coincidence, but this example works much better when it is defined with bits: typedef SshProtocolVersion { description "Define versions of the SSH protocol are allowed"; type bits { bit v1 { description "Allow SSH V1"; } bit v2 { description "Allow SSH V2"; } } } leaf ssh-client { type SshProtocolVersion; mandatory false; } leaf ssh-server { type SshProtocolVersion; mandatory true; } This same sort of reuse should be possible for containers and not just the special subtree called bits. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Jul 25 23:01: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 AD7273A6923; Fri, 25 Jul 2008 23:01: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 ABB593A6923 for ; Fri, 25 Jul 2008 23:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 PnpIPyESdXA9 for ; Fri, 25 Jul 2008 23:01:18 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id BCC2F3A67D2 for ; Fri, 25 Jul 2008 23:01:18 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Fri, 25 Jul 2008 23:01:14 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, 25 Jul 2008 23:01:14 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 23:01:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 22:53:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6Q5rDu74886; Fri, 25 Jul 2008 22:53:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6Q5oB4u067688; Sat, 26 Jul 2008 05:50:11 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807260550.m6Q5oB4u067688@idle.juniper.net> To: Andy Bierman In-reply-to: <488A873B.3040601@netconfcentral.com> Date: Sat, 26 Jul 2008 01:50:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Jul 2008 05:53:13.0995 (UTC) FILETIME=[E493FDB0:01C8EEE3] Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 same sort of reuse should be possible for >containers and not just the special subtree called bits. This sort of reuse is possible for containers using refinements. The issue is that currently you are required to refine the nodes you want to change, where you want to mark the use as mandatory and let the solution magically work it out. You don't want visibility into the grouping, but something has to decide _why_ the container is mandatory. I don't think we have enough magic to make it work out. I also dislike the idea of giving an error when a config doesn't contain a node that has no meaning and no children. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 26 10:34:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529273A6920; Sat, 26 Jul 2008 10:34:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1AA28C198 for ; Sat, 26 Jul 2008 10:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 pWajIxErOpJF for ; Sat, 26 Jul 2008 10:34:12 -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 0CDD43A6920 for ; Sat, 26 Jul 2008 10:34:11 -0700 (PDT) Received: (qmail 62666 invoked from network); 26 Jul 2008 17:34:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 26 Jul 2008 17:34:15 -0000 X-YMail-OSG: 45Ki74MVM1mFUmY1TS8OKE682Ub9R0x2OTnW1fFxgaJ5SSUrM265dpL3bAqqpJTswlxxP8gq669Fdtap.i5.VtIIzOrUr7wwEWFuNjotoA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488B6015.6090200@netconfcentral.com> Date: Sat, 26 Jul 2008 10:34:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807260550.m6Q5oB4u067688@idle.juniper.net> In-Reply-To: <200807260550.m6Q5oB4u067688@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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 same sort of reuse should be possible for >> containers and not just the special subtree called bits. > > This sort of reuse is possible for containers using refinements. > The issue is that currently you are required to refine the nodes > you want to change, where you want to mark the use as mandatory and > let the solution magically work it out. > No more magic than the rest of the work a YANG compiler needs to do. All your examples seem to be inline, which is how CLI and MIBs are defined as well. NETCONF exists because the programmatic interface provided by CLI and/or SMIv2 based data models have not worked very well for standards-based configuration. We should examine the reasons for that problem, as we tweak a clause here and there. I completely understand why DaveH wants to get everybody looking at the same picture on the same page. We cannot possibly agree on the language tweaks without agreeing on the big picture. > You don't want visibility into the grouping, but something has to > decide _why_ the container is mandatory. I don't think we have > enough magic to make it work out. If the grouping represents an abstract construct, then it is easy to decide how that abstraction is being used in any given context. I do this everyday with C pointers, eg., 'const', 'static', 'volatile'. The draft says mandatory has no effect for a set of sibling nodes unless their parent is present. This is correct, and it should work this way for all nodes, and it does, except for NP containers. So my workaround is to always use the presence-stmt. E.g., grouping Name { container name { presence "If present, then the parent entity has a name."; // 3 - 5 leafs breaking out all the name field components // 2 mandatory, and 3 not mandatory } } If I want an optional name, then I can create a new grouping: grouping OptName { uses Name { container name { leaf first { mandatory false; } leaf last { mandatory false; } } } } This is OK I guess. I still think we will want a more powerful (less verbose) syntax in the end to override a property for an entire subtree, but this brute force method can be done just once in a new grouping, so it's not so bad. And yes, the DM modeler for some piece of code will need to know the exact differences between Name and OptName, but not everybody will care. > > I also dislike the idea of giving an error when a config doesn't > contain a node that has no meaning and no children. Do you just want to outlaw NP containers all together? All containers would be presence containers? I don't really think they are worth worrying about. An empty NP container amounts to garbage-in/garbage out in the end, and if the agent wants to prune it (since is has no impact on the config) then it should do that. Otherwise, it is just wasting a little memory, and not really a problem. > > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 26 11:41: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 7F9CA28C1D0; Sat, 26 Jul 2008 11:41: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 66DB228C1CD for ; Sat, 26 Jul 2008 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 h8ZFGzQJk1UK for ; Sat, 26 Jul 2008 11:40:59 -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 7764228C178 for ; Sat, 26 Jul 2008 11:40:59 -0700 (PDT) Received: (qmail 48180 invoked from network); 26 Jul 2008 18:41:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 26 Jul 2008 18:41:02 -0000 X-YMail-OSG: 5n8TbOgVM1nIHj2yKPLyKuRQ1vVKeJT5kUE82NNIs7A2uGV7DYkkaGwezMA9kl0GqtPlZcLo2XaC7gwtGC1uoWCqNzCHbwkaNwpW3RI7EA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488B6FBD.9010007@netconfcentral.com> Date: Sat, 26 Jul 2008 11:41:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200807260550.m6Q5oB4u067688@idle.juniper.net> <488B6015.6090200@netconfcentral.com> In-Reply-To: <488B6015.6090200@netconfcentral.com> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, >... > So my workaround is to always use the presence-stmt. E.g., > > grouping Name { > container name { > presence "If present, then the parent entity has a name."; > > // 3 - 5 leafs breaking out all the name field components > // 2 mandatory, and 3 not mandatory > } > } > > If I want an optional name, then I can create a new grouping: > > grouping OptName { > uses Name { > container name { > leaf first { > mandatory false; > } > leaf last { > mandatory false; > } > } > } > } > I don't really need OptName, right? It would only be useful if I had a use for , and to properly refine a presence container like this, I would have to define what it means to have just an empty element in the config. (E.g., use the site-specific default instead.) This is reasonable. I still don't think it is worth a separate description clause. Multiple description clauses will lead to multiple CLRs to decide what kind of text goes in each one. I would rather have 1 description clause with zero CLRs. The presence-stmt is still not a great model for an encapsulation container. In this example, I want either a valid subtree or no element at all. I think the rules for presence container give me that, as long as at least one child node is mandatory. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 26 11:50: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 29F263A696F; Sat, 26 Jul 2008 11:50:36 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3413A68E7 for ; Sat, 26 Jul 2008 11:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqY586K+EMXS for ; Sat, 26 Jul 2008 11:50:33 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0FE413A696F for ; Sat, 26 Jul 2008 11:50:31 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 0A85676C22F; Sat, 26 Jul 2008 20:50:36 +0200 (CEST) Date: Sat, 26 Jul 2008 20:52:12 +0200 (CEST) Message-Id: <20080726.205212.256318705.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <488B6FBD.9010007@netconfcentral.com> References: <200807260550.m6Q5oB4u067688@idle.juniper.net> <488B6015.6090200@netconfcentral.com> <488B6FBD.9010007@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Andy Bierman wrote: > Hi, > > >... > > So my workaround is to always use the presence-stmt. E.g., > > grouping Name { > > container name { > > presence "If present, then the parent entity has a name."; > > // 3 - 5 leafs breaking out all the name field components > > // 2 mandatory, and 3 not mandatory > > } > > } > > If I want an optional name, then I can create a new grouping: > > grouping OptName { > > uses Name { > > container name { > > leaf first { > > mandatory false; > > } > > leaf last { > > mandatory false; > > } > > } > > } > > } > > > > > I don't really need OptName, right? No, I was just going to suggest that. > In this example, I want > either a valid subtree or no element > at all. I think the rules for presence container > give me that, as long as at least one child node > is mandatory. Yes. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 26 12:05: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 B79123A6858; Sat, 26 Jul 2008 12:05: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 AB1F93A6886 for ; Sat, 26 Jul 2008 12:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 gVF5L7LYlKHC for ; Sat, 26 Jul 2008 12:05:42 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 07A5D3A6858 for ; Sat, 26 Jul 2008 12:05:42 -0700 (PDT) Received: (qmail 17161 invoked from network); 26 Jul 2008 19:05:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 26 Jul 2008 19:05:45 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <488B7587.5060800@netconfcentral.com> Date: Sat, 26 Jul 2008 12:05:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200807260550.m6Q5oB4u067688@idle.juniper.net> <488B6015.6090200@netconfcentral.com> <488B6FBD.9010007@netconfcentral.com> <20080726.205212.256318705.mbj@tail-f.com> In-Reply-To: <20080726.205212.256318705.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> >... >>> So my workaround is to always use the presence-stmt. E.g., >>> grouping Name { >>> container name { >>> presence "If present, then the parent entity has a name."; >>> // 3 - 5 leafs breaking out all the name field components >>> // 2 mandatory, and 3 not mandatory >>> } >>> } >>> If I want an optional name, then I can create a new grouping: >>> grouping OptName { >>> uses Name { >>> container name { >>> leaf first { >>> mandatory false; >>> } >>> leaf last { >>> mandatory false; >>> } >>> } >>> } >>> } >>> >> >> I don't really need OptName, right? > > No, I was just going to suggest that. > >> In this example, I want >> either a valid subtree or no element >> at all. I think the rules for presence container >> give me that, as long as at least one child node >> is mandatory. > > Yes. > > I like your idea of changing the presence-stmt argument from a string to a boolean. It may not be clear to people why conceptualizing this particular portion of the XML tree in this manner is a feature. The rules for mandatory within a 'choice' subtree are still a little unclear to me, for example. If I have mandatory false on the choice, and there are mandatory leafs within at least one case, does that make the choice mandatory anyway? I hope not. The mandatory property should just mean "if you use this case arm, this leaf is mandatory". The draft should explain the upward ripple on NP containers better, and why it works this way. > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 26 12:12: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 C4ECF3A6858; Sat, 26 Jul 2008 12:12: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 542773A690B for ; Sat, 26 Jul 2008 12:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpL6NUZt28q6 for ; Sat, 26 Jul 2008 12:12:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 590F23A6886 for ; Sat, 26 Jul 2008 12:12:35 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 078FD76C227; Sat, 26 Jul 2008 21:12:40 +0200 (CEST) Date: Sat, 26 Jul 2008 21:14:14 +0200 (CEST) Message-Id: <20080726.211414.48594209.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <488B7587.5060800@netconfcentral.com> References: <488B6FBD.9010007@netconfcentral.com> <20080726.205212.256318705.mbj@tail-f.com> <488B7587.5060800@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] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I like your idea of changing the presence-stmt argument > from a string to a boolean. This (could) allow you to turn off presence in 'uses', but I'm not sure that would be a feature... > It may not be clear to people why conceptualizing this > particular portion of the XML tree in this manner is > a feature. > > The rules for mandatory within a 'choice' subtree are still > a little unclear to me, for example. If I have mandatory false > on the choice, and there are mandatory leafs within at least > one case, does that make the choice mandatory anyway? No. I agree that the spec is not very clear on this, and that we should fix this. > I hope not. The mandatory property should just mean > "if you use this case arm, this leaf is mandatory". Right. > The draft should explain the upward ripple on NP containers > better, and why it works this way. Ok. But how much of the "why" questions should really be answered in the spec? Should we discuss rejected design alternatives (I hope not). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 26 12:35: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 A83133A69FE; Sat, 26 Jul 2008 12:35: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 619C23A69FE for ; Sat, 26 Jul 2008 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 wrsD781Ru3J4 for ; Sat, 26 Jul 2008 12:35:30 -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 544593A6913 for ; Sat, 26 Jul 2008 12:35:30 -0700 (PDT) Received: (qmail 19469 invoked from network); 26 Jul 2008 19:35:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 26 Jul 2008 19:35:33 -0000 X-YMail-OSG: AIinqjMVM1mLw.eNta652I14MGT1P_yBBRJmz8prm1IWykGVrcgyNQX3hOWJWxxKVVo1lv_myvNz03rdsc7RALfjer41wuzCZQ3SjuhllUx37K.i9yEYDdrTqo8L X-Yahoo-Newman-Property: ymail-3 Message-ID: <488B7C83.9090803@netconfcentral.com> Date: Sat, 26 Jul 2008 12:35:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <488B6FBD.9010007@netconfcentral.com> <20080726.205212.256318705.mbj@tail-f.com> <488B7587.5060800@netconfcentral.com> <20080726.211414.48594209.mbj@tail-f.com> In-Reply-To: <20080726.211414.48594209.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 2 more YANG details X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> I like your idea of changing the presence-stmt argument >> from a string to a boolean. > > This (could) allow you to turn off presence in 'uses', but I'm not > sure that would be a feature... A P container with mandatory fields is not mandatory itself. Setting presence to false would be the only way to for an implementation to say "this container must be present in a valid config" instead of "if it is present, it must have all the mandatory fields." The implementation may not support the semantics for the empty container either. What then? Can it refine a P container? > >> It may not be clear to people why conceptualizing this >> particular portion of the XML tree in this manner is >> a feature. >> >> The rules for mandatory within a 'choice' subtree are still >> a little unclear to me, for example. If I have mandatory false >> on the choice, and there are mandatory leafs within at least >> one case, does that make the choice mandatory anyway? > > No. I agree that the spec is not very clear on this, and that we > should fix this. > >> I hope not. The mandatory property should just mean >> "if you use this case arm, this leaf is mandatory". > > Right. > >> The draft should explain the upward ripple on NP containers >> better, and why it works this way. > > Ok. But how much of the "why" questions should really be answered in > the spec? Should we discuss rejected design alternatives (I hope > not). > No -- just the accepted design. That's enough work. :-) > > /martin > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Jul 26 13:13: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 789E33A67E1; Sat, 26 Jul 2008 13:13: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 457F23A68E7 for ; Sat, 26 Jul 2008 13:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 ZoJARjWdPsVl for ; Sat, 26 Jul 2008 13:13:52 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id A0BE33A67E1 for ; Sat, 26 Jul 2008 13:13:52 -0700 (PDT) Received: (qmail 52044 invoked from network); 26 Jul 2008 20:13:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Jul 2008 20:13:55 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <488B8582.2090008@netconfcentral.com> Date: Sat, 26 Jul 2008 13:13:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] 7.9.3 and 7.9.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, It seems like a choice-stmt should have the same rules for default and mandatory as a leaf. Zero or one can be present, but not both. Isn't it illegal to have a mandatory-stmt and a default-stmt within the same choice? 7.9.4 should mention that. 7.9.3, para 3 says: There MUST NOT be any mandatory child nodes under the default case. The exact definition of a 'mandatory child' should be clarified somewhere. Sometimes we mean a direct child node, and sometimes we mean a leaf which has mandatory-stmt set to true, nested within 1 or more NP containers. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Jul 27 07:09: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 873E23A680B; Sun, 27 Jul 2008 07:09: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 0401D3A68C0 for ; Sun, 27 Jul 2008 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8xLf13wYCgi for ; Sun, 27 Jul 2008 07:09:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EE84B3A6812 for ; Sun, 27 Jul 2008 07:09:45 -0700 (PDT) Received: from localhost (guestroom-nat.meeting.ietf.org [130.129.64.64]) by mail.tail-f.com (Postfix) with ESMTPSA id D0AD676C22D; Sun, 27 Jul 2008 16:09:51 +0200 (CEST) Date: Sun, 27 Jul 2008 15:09:48 +0100 (IST) Message-Id: <20080727.150948.115314775.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <488B8582.2090008@netconfcentral.com> References: <488B8582.2090008@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] 7.9.3 and 7.9.4 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > It seems like a choice-stmt should have the same rules for > default and mandatory as a leaf. Zero or one can be present, > but not both. > > Isn't it illegal to have a mandatory-stmt and a default-stmt > within the same choice? 7.9.4 should mention that. Yes, fixed. > 7.9.3, para 3 says: > > There MUST NOT be any mandatory child nodes under the default case. > > The exact definition of a 'mandatory child' should be > clarified somewhere. I agree. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Jul 27 13:56:44 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE183A6921; Sun, 27 Jul 2008 13:56:44 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E9F3A6921 for ; Sun, 27 Jul 2008 13:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 q2uXQftHCDTW for ; Sun, 27 Jul 2008 13:56:38 -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 662503A6914 for ; Sun, 27 Jul 2008 13:56:35 -0700 (PDT) Received: (qmail 87406 invoked from network); 27 Jul 2008 20:56:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 27 Jul 2008 20:56:41 -0000 X-YMail-OSG: jJE7K2wVM1nrJVGNOeWJuHIyx6zuiNwVnKl7zLyjbnaMqbaGwWaAc3os4PPx4PwbdQ8n15f.L4WMC7T06FhEgO50G.k6tLiMU4lBB.lYjg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488CE107.1090509@netconfcentral.com> Date: Sun, 27 Jul 2008 13:56:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] config-stmt on choice and/or case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Remind me again why we don't need config-stmt within choice-stmt or case-stmt? It seems to make sense to me. Without it, you cannot control a choice between multiple reusable case arm contents (via uses). I want to be able to define building blocks like InetAddress or maybe ConnectionEndpoint or whatever, and not declare any config-stmts at all in the groupings. Instead an ancestor of the uses-stmt is expected to provide the config-stmt. It would be tedious to read and write all the uses refinement statements, rather than use the mechanism already in place for this very problem. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 28 00:07:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D3D3A6826; Mon, 28 Jul 2008 00:07:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465523A6A5B; Sun, 27 Jul 2008 22:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHqJRCpGDf3k; Sun, 27 Jul 2008 22:15:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 71F953A685C; Sun, 27 Jul 2008 22:15:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6S5FKnY021333; Mon, 28 Jul 2008 01:15:20 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6S5FKlc021327; Mon, 28 Jul 2008 01:15:20 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 01:15:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 01:13:50 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted Thread-Index: AchshrU9Eh9mtU+dQEyJvMbrsqa/2wK9u9bgG6JDzkACmju30A== References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> From: "Natale, Bob" To: X-OriginalArrivalTime: 28 Jul 2008 05:15:20.0419 (UTC) FILETIME=[EE3F5330:01C8F070] X-Mailman-Approved-At: Mon, 28 Jul 2008 00:07:46 -0700 Cc: mib2rdml@ietf.org Subject: [netmod] Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1100028397==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --===============1100028397== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F070.BAA7AC6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F070.BAA7AC6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have submitted an updated version (-03) of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", via the Internet-Drafts submission tool, but it will likely not get processed until following IETF-72. =20 In the meantime, interested parties can download a copy from: http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-x sd-03.txt =20 The -03 version has some minor fix-ups (documented in the change log) and is being submitted now because the -02 version (which was posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) technical problem with the tool (apparently). =20 I hope that this version may be ready for WG last call. I will not be in Dublin, however - but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there. =20 If anything is a hang-up, I suspect it will be in the XML registration section ("IANA Considerations"). =20 Please let me know your observations, etc. =20 [I've included a couple of the NETCONF-related lists as bcc: addressees on this, since several recent threads on those lists have mentioned the XSDMI work. Further discussion about this draft, however, should be on the OPSAWG list.] =20 Cheers, BobN =20 From: Natale, Bob=20 Sent: Monday, July 14, 2008 7:17 PM To: opsawg@ietf.org Cc: mib2rdml@ietf.org Subject: Expressing SNMP SMI Datatypes in XML Schema Definition Language -02 draft submitted =20 Hi, =20 I have submitted an updated version of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via the Internet-Drafts submission tool ahead of today's deadline, but had to do it via a "manual entry" due to administrative complications (once again!), which imposes some delays in the formal announcement process. =20 Pending formal publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-opsawg-smi-datatypes -in-xsd-02.txt. If that presents any problems for you, please let me know and I will forward you a copy directly. =20 This draft includes changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups noted in the Change Log section. =20 I hope that this version may be ready for WG last call. I will not be in Dublin, however - but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there. =20 If anything is a hang-up, I suspect it will be in the XML registration section ("IANA Considerations"). =20 Please let me know your observations, etc. =20 Cheers, BobN =20 ------_=_NextPart_001_01C8F070.BAA7AC6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have submitted an updated version (-03) of = “Expressing SNMP SMI Datatypes in XML Schema Definition Language”, via the = Internet-Drafts submission tool, but it will likely not get processed until following = IETF-72.

 

In the meantime, interested parties can download a copy = from:

http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi= -datatypes-in-xsd-03.txt

 

The -03 version has some minor fix-ups (documented in the = change log) and is being submitted now because the -02 version (which was = posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) = technical problem with the tool (apparently).

 

I hope that this version may be ready for WG last = call.  I will not be in Dublin, however – but will try to participate = remotely if possible if this topic is discussed in the OPSAWG session = there.

 

If anything is a hang-up, I suspect it will be in the XML registration section (“IANA = Considerations”).

 

Please let me know your observations, = etc.

 

[I’ve included a couple of the NETCONF-related lists = as bcc: addressees on this, since several recent threads on those lists = have mentioned the XSDMI work.  Further discussion about this draft, = however, should be on the OPSAWG list.]

 

Cheers,

BobN

 

From: Natale, Bob
Sent: Monday, July 14, 2008 7:17 PM
To: opsawg@ietf.org
Cc: mib2rdml@ietf.org
Subject: Expressing SNMP SMI Datatypes in XML Schema Definition = Language -02 draft submitted

 

Hi,=

 

I have submitted = an updated version of "Expressing SNMP SMI Datatypes in XML Schema = Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via = the Internet-Drafts submission tool ahead of today’s deadline, but had = to do it via a "manual entry" due to administrative complications = (once again!), which imposes some delays in the formal announcement = process.

 =

Pending formal = publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-= opsawg-smi-datatypes-in-xsd-02.txt.  If that presents any problems for you, = please let me know and I will forward you a copy = directly.

 

This draft includes = changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups = noted in the Change Log section.

 

I hope that this = version may be ready for WG last call.  I will not be in Dublin, however = – but will try to participate remotely if possible if this topic is discussed = in the OPSAWG session there.

 =

If anything is a = hang-up, I suspect it will be in the XML registration section (“IANA Considerations”).

 =

Please let me know your observations, etc.=

 

Cheers,=

BobN=

 =

------_=_NextPart_001_01C8F070.BAA7AC6E-- --===============1100028397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --===============1100028397==-- From netmod-bounces@ietf.org Mon Jul 28 02:26:11 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D2A3A6808; Mon, 28 Jul 2008 02:26:11 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5543A6809 for ; Mon, 28 Jul 2008 02:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkpqJYhXjyjm for ; Mon, 28 Jul 2008 02:26:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E8DD03A6808 for ; Mon, 28 Jul 2008 02:26:09 -0700 (PDT) Received: from localhost (guestroom-nat.meeting.ietf.org [130.129.64.64]) by mail.tail-f.com (Postfix) with ESMTPSA id 2ECC8616009; Mon, 28 Jul 2008 11:26:18 +0200 (CEST) Date: Mon, 28 Jul 2008 10:26:12 +0100 (IST) Message-Id: <20080728.102612.142840307.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <488CE107.1090509@netconfcentral.com> References: <488CE107.1090509@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] config-stmt on choice and/or case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > Remind me again why we don't need config-stmt within choice-stmt > or case-stmt? I don't see any reasons for not allowing config under choice and case. If no one objects, I'll make this change. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 28 03:11:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FBB3A69B3; Mon, 28 Jul 2008 03:11:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0383A69B3 for ; Mon, 28 Jul 2008 03:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S73wg3SNF8oK for ; Mon, 28 Jul 2008 03:11:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 174F73A6839 for ; Mon, 28 Jul 2008 03:11:03 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3B8FE20521 for ; Mon, 28 Jul 2008 12:11:11 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-60-488d9b3fae37 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 07842203EC for ; Mon, 28 Jul 2008 12:11:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 12:11:11 +0200 Received: from [153.88.49.145] ([153.88.49.145]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 12:11:10 +0200 From: David Partain Organization: Ericsson AB To: NETMOD Working Group Date: Mon, 28 Jul 2008 12:09:36 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807281209.36408.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Jul 2008 10:11:10.0661 (UTC) FILETIME=[42374F50:01C8F09A] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Interim in October? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings all, Yes, I know we haven't had our first working group meetings yet, but... The co-chairs are considering requesting that our ADs approve a three-day interim meeting in October. We both believe that this is an effective way to tackle open technical issues. Suggested meeting time is October 8 - 10. This follows the "interim meeting rules" by not putting us within 30 days of the fall IETF but also gives us time between now and then to narrow the issues list to the ones that really need face time. Unless the attendee list is different than I expect, the east coast of the U.S. seems a good place for a meeting. I believe that I have a possible location lined up 20 miles north of Pittsburgh, Pennysylvania, but other suggestions are welcome. Please let me and David Harrington know which of these apply: - you would likely come to an interim on the east coast on October 8 - 10 - you would like to come but can't on those dates. - you'd like to come, but that location is prohibitive. In that case, please tell us where you could meet instead. Feel free to suggest other locations, particularly if you can volunteer to host the meeting. (I'm sure I'll be told there are other questions I should have asked :-) ). No need to send your response to the list unless you just want to. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Jul 28 10:46: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 3610A28C13E; Mon, 28 Jul 2008 10:46: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 7DF0528C237 for ; Mon, 28 Jul 2008 10:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuKGFFLMSYi3 for ; Mon, 28 Jul 2008 10:46:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2C39B28C276 for ; Mon, 28 Jul 2008 10:46:27 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1D74B21158; Mon, 28 Jul 2008 19:46:36 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-b1-488e05fc2bbe Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 01CFB20D63; Mon, 28 Jul 2008 19:46:36 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 19:46:35 +0200 Received: from [153.88.52.76] ([153.88.52.76]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 19:46:35 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 28 Jul 2008 19:46:59 +0200 User-Agent: KMail/1.9.9 References: <1216818547.6284.39.camel@missotis> In-Reply-To: <1216818547.6284.39.camel@missotis> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807281946.59123.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Jul 2008 17:46:35.0596 (UTC) FILETIME=[E12580C0:01C8F0D9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] DSDL work X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, On Wednesday 23 July 2008 15.09.07 Ladislav Lhotka wrote: > my slides for the Friday in-depth session are here: > http://staff.cesnet.cz/~lhotka/NETMOD/yang2dsdl.pdf > > For the public session on Thursday, it would be great to be able to > propose how the two existing DSDL drafts will be integrated. In my > opinion, the main difference between the two is that > draft-mahy-canmod-dsdl assumes DSDL to be the primary DML that sets the > stage whereas draft-lhotka-yang-dsdl-map takes YANG as primary and just > translates its semantics, extension model etc. > > However, the NETMOD charter is quite clear in saying that YANG is > primary. Therefore, I suggest the following: > > 1. Take the useful things from draft-mahy-... (validation phases, deep > keys etc.) and implement them appropriately in YANG. > > 2. Reconsider the YANG idiosyncrasies that make translation to DSDL hard > and adjust them where possible. > > 3. Concentrate on YANG->DSDL _mapping_ rather than on DSDL as a DML par > excellence. > > I think most of the information for doing this is already available. I > also have to stress that this does not preclude other improvements to > YANG, this is only about YANG-DSDL relationship. > > Is it an acceptable scenario? Thanks very much to all the DSDL authors for this work. The charter says the following about this deliverable: In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. That means that YANG is the canonical representation of the model. That canonical representation then gets mapped into DSDL using the rules specified in this deliverable. If there are things needed in DSDL that do not exist in YANG today, if there is WG consensus, those need to be pushed upstream into YANG. They must not only exist in the DSDL representation of the model. That is, if it's not in YANG, it's not going to be in the DSDL representation, either. Cheers, David^2 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 29 07:09: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 3A2CA3A680B; Tue, 29 Jul 2008 07:09: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 53A1A3A6958 for ; Tue, 29 Jul 2008 07:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNwPlBs+N72J for ; Tue, 29 Jul 2008 07:09:51 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3F47F3A68C1 for ; Tue, 29 Jul 2008 07:09:51 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6TE9Yx10782 for ; Tue, 29 Jul 2008 14:09:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 10:06:04 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification: No inline operation definition? Thread-Index: AcjxhB9wo3vhzB/ZR6Kikq9847kv8g== From: "Sharon Chisholm" To: Subject: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi In NETMOD, we don't really have a requirement to support definition of NETCONF protocol operations inline in a data model do we? It wasn't clear in reading the section in the yang document whether that was encouraged or forbidden. Just in case it is permitted, I just want to say that I don't think it adds any value to be able to do this and it seems to discourage re-use of verbs across different types of data, which is bad. I don't think we really need 47 definitions of the 'reboot' operation, for example. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 29 07:24: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 808D53A6B4D; Tue, 29 Jul 2008 07:24: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 9E8B13A6B84 for ; Tue, 29 Jul 2008 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.206, 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 hldnXWsvFNOa for ; Tue, 29 Jul 2008 07:24:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A1CAD3A6B4D for ; Tue, 29 Jul 2008 07:24:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 028EAC0032; Tue, 29 Jul 2008 16:24:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fMuiFS+wVNyg; Tue, 29 Jul 2008 16:24: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 E1137C0005; Tue, 29 Jul 2008 16:24:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BC17167A6B1; Tue, 29 Jul 2008 16:24:10 +0200 (CEST) Date: Tue, 29 Jul 2008 16:24:10 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080729142410.GA11405@elstar.local> Mail-Followup-To: Sharon Chisholm , netmod@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Tue, Jul 29, 2008 at 10:06:04AM -0400, Sharon Chisholm wrote: > In NETMOD, we don't really have a requirement to support definition of > NETCONF protocol operations inline in a data model do we? It wasn't > clear in reading the section in the yang document whether that was > encouraged or forbidden. Can you clarify please what the issue is? Which section of the YANG document should I look at? > Just in case it is permitted, I just want to say that I don't think it > adds any value to be able to do this and it seems to discourage re-use > of verbs across different types of data, which is bad. I don't think we > really need 47 definitions of the 'reboot' operation, for example. I need some help to understand the issue. /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 Jul 29 07:33: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 5C9183A6B8C; Tue, 29 Jul 2008 07:33: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 76AC53A6B84 for ; Tue, 29 Jul 2008 07:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 1g5Zr60ZBx9U for ; Tue, 29 Jul 2008 07:33:32 -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 7E71428C231 for ; Tue, 29 Jul 2008 07:33:32 -0700 (PDT) Received: (qmail 83850 invoked from network); 29 Jul 2008 14:33:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2008 14:33:30 -0000 X-YMail-OSG: VEtQKTkVM1kfcEotCdy035mB17U_z02Tg9aR7zE6K55NhOHzFmFfxXWZk3GWh19zU.BNTWQ1MGgK4UCYepTYfVMZ3drvx5jHWWj5SHb2TA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488F2A38.10303@netconfcentral.com> Date: Tue, 29 Jul 2008 07:33:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Sharon Chisholm , netmod@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> In-Reply-To: <20080729142410.GA11405@elstar.local> Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jul 29, 2008 at 10:06:04AM -0400, Sharon Chisholm wrote: > >> In NETMOD, we don't really have a requirement to support definition of >> NETCONF protocol operations inline in a data model do we? It wasn't >> clear in reading the section in the yang document whether that was >> encouraged or forbidden. > > Can you clarify please what the issue is? Which section of the YANG > document should I look at? > >> Just in case it is permitted, I just want to say that I don't think it >> adds any value to be able to do this and it seems to discourage re-use >> of verbs across different types of data, which is bad. I don't think we >> really need 47 definitions of the 'reboot' operation, for example. > > I need some help to understand the issue. > Me too. The YANG language allows the definition of any RPC method (conforming to the YANG data types). If you choose to write 47 versions of the reboot operation, or if you choose to define inline data instead of reusable groupings, this is not a problem with the language, but rather the people using the language. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 29 07:47: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 DE24F3A6B8F; Tue, 29 Jul 2008 07:47: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 0AB173A6A60 for ; Tue, 29 Jul 2008 07:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTSCPyp6kb0W for ; Tue, 29 Jul 2008 07:47:22 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id C40FC3A6B92 for ; Tue, 29 Jul 2008 07:47:21 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6TElRx18062; Tue, 29 Jul 2008 14:47:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 10:47:24 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> In-Reply-To: <488F2A38.10303@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Clarification: No inline operation definition? Thread-Index: AcjxiBZNx3uV+3oqTjqrOWdbhwRbtwAAVFsw References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> <488F2A38.10303@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" , Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi I am talking about section 4.2.9 I guess. My point is, I don't think we don't need the ability to define operations inline, so why do we have it? What use case does this support? It would also be nice and human-friendly if it was easier to do the right thing (common operations) then the wrong thing (47 different reboot operations). I propose we just allow for global operations. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Tuesday, July 29, 2008 10:33 AM To: Chisholm, Sharon (CAR:ZZ00); netmod@ietf.org Subject: Re: [netmod] Clarification: No inline operation definition? Juergen Schoenwaelder wrote: > On Tue, Jul 29, 2008 at 10:06:04AM -0400, Sharon Chisholm wrote: > >> In NETMOD, we don't really have a requirement to support definition >> of NETCONF protocol operations inline in a data model do we? It >> wasn't clear in reading the section in the yang document whether that >> was encouraged or forbidden. > > Can you clarify please what the issue is? Which section of the YANG > document should I look at? > >> Just in case it is permitted, I just want to say that I don't think >> it adds any value to be able to do this and it seems to discourage >> re-use of verbs across different types of data, which is bad. I don't >> think we really need 47 definitions of the 'reboot' operation, for example. > > I need some help to understand the issue. > Me too. The YANG language allows the definition of any RPC method (conforming to the YANG data types). If you choose to write 47 versions of the reboot operation, or if you choose to define inline data instead of reusable groupings, this is not a problem with the language, but rather the people using the language. > /js > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 29 07:59: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 AF6013A6AF8; Tue, 29 Jul 2008 07:59: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 3B73C3A6AF8 for ; Tue, 29 Jul 2008 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 vAX31GCCFOjm for ; Tue, 29 Jul 2008 07:59:20 -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 E42683A6B9A for ; Tue, 29 Jul 2008 07:59:19 -0700 (PDT) Received: (qmail 69243 invoked from network); 29 Jul 2008 14:59:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2008 14:59:26 -0000 X-YMail-OSG: 7CmB2y4VM1l3cBUevG5i5Mg7fMfbmXZbYYq9Gp7jl_KsN3MdX8buBq9ofxtRkV0VooclwjEacP43cnY5IkDLVykSg.3X22XfnUSJua1JJg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488F304C.2000204@netconfcentral.com> Date: Tue, 29 Jul 2008 07:59:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> <488F2A38.10303@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> Cc: netmod@ietf.org Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I am talking about section 4.2.9 I guess. > > My point is, I don't think we don't need the ability to define > operations inline, so why do we have it? What use case does this > support? > I don't understand. Every document the NETCONF WG creates seem to define new RPC methods in it. Vendor RPC methods are also important. I'll repeat my argument for keeping rpc (and notification) in the YANG language: - The DM reader must understand the entire API embodied in the NETCONF data model module. This applies to config data, monitoring data, event notifications, and protocol verbs defined to manage some network service. - There needs to be 1 data modeling language to define the entire data model API for consistency and coherence. - If XSD or RNG is user-friendly enough to define part of this API, then they are good enough for all of it, and we don't need YANG at all. (Given that lack of expertise demonstrated in either language by the IETF, I think we need YANG.) > It would also be nice and human-friendly if it was easier to do the > right thing (common operations) then the wrong thing (47 different > reboot operations). > > I propose we just allow for global operations. We do not have local operations in YANG. The rpc-stmt can only appear at the top-level (body-stmts). > > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, July 29, 2008 10:33 AM > To: Chisholm, Sharon (CAR:ZZ00); netmod@ietf.org > Subject: Re: [netmod] Clarification: No inline operation definition? > > Juergen Schoenwaelder wrote: >> On Tue, Jul 29, 2008 at 10:06:04AM -0400, Sharon Chisholm wrote: >> >>> In NETMOD, we don't really have a requirement to support definition >>> of NETCONF protocol operations inline in a data model do we? It >>> wasn't clear in reading the section in the yang document whether that > >>> was encouraged or forbidden. >> Can you clarify please what the issue is? Which section of the YANG >> document should I look at? >> >>> Just in case it is permitted, I just want to say that I don't think >>> it adds any value to be able to do this and it seems to discourage >>> re-use of verbs across different types of data, which is bad. I don't > >>> think we really need 47 definitions of the 'reboot' operation, for > example. >> I need some help to understand the issue. >> > > Me too. > > The YANG language allows the definition of any RPC method (conforming to > the YANG data types). If you choose to write 47 versions of the reboot > operation, or if you choose to define inline data instead of reusable > groupings, this is not a problem with the language, but rather the > people using the language. > > >> /js >> > > Andy > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 29 08:04:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC01C3A696B; Tue, 29 Jul 2008 08:04: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 6DAFF3A67EB for ; Tue, 29 Jul 2008 08:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOrqprhqw+46 for ; Tue, 29 Jul 2008 08:04:54 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 01F0A3A6875 for ; Tue, 29 Jul 2008 08:04:42 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6TF4kx22035; Tue, 29 Jul 2008 15:04:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:04:44 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> In-Reply-To: <488F304C.2000204@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Clarification: No inline operation definition? Thread-Index: Acjxi7RSVwYcqj7YTlqKwHEl3tr9PAAADuqg References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> <488F2A38.10303@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> <488F304C.2000204@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netmod@ietf.org Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi Ok. I did call the thread 'clarification' and it sounds like you have just confirmed yang does not support inline operations? Let me give an example of what I don't want to see to ensure I'm clear (sorry, XSD is my pseudo code) Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Tuesday, July 29, 2008 10:59 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: netmod@ietf.org Subject: Re: [netmod] Clarification: No inline operation definition? Sharon Chisholm wrote: > Hi > > I am talking about section 4.2.9 I guess. > > My point is, I don't think we don't need the ability to define > operations inline, so why do we have it? What use case does this > support? > I don't understand. Every document the NETCONF WG creates seem to define new RPC methods in it. Vendor RPC methods are also important. I'll repeat my argument for keeping rpc (and notification) in the YANG language: - The DM reader must understand the entire API embodied in the NETCONF data model module. This applies to config data, monitoring data, event notifications, and protocol verbs defined to manage some network service. - There needs to be 1 data modeling language to define the entire data model API for consistency and coherence. - If XSD or RNG is user-friendly enough to define part of this API, then they are good enough for all of it, and we don't need YANG at all. (Given that lack of expertise demonstrated in either language by the IETF, I think we need YANG.) > It would also be nice and human-friendly if it was easier to do the > right thing (common operations) then the wrong thing (47 different > reboot operations). > > I propose we just allow for global operations. We do not have local operations in YANG. The rpc-stmt can only appear at the top-level (body-stmts). > > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, July 29, 2008 10:33 AM > To: Chisholm, Sharon (CAR:ZZ00); netmod@ietf.org > Subject: Re: [netmod] Clarification: No inline operation definition? > > Juergen Schoenwaelder wrote: >> On Tue, Jul 29, 2008 at 10:06:04AM -0400, Sharon Chisholm wrote: >> >>> In NETMOD, we don't really have a requirement to support definition >>> of NETCONF protocol operations inline in a data model do we? It >>> wasn't clear in reading the section in the yang document whether >>> that > >>> was encouraged or forbidden. >> Can you clarify please what the issue is? Which section of the YANG >> document should I look at? >> >>> Just in case it is permitted, I just want to say that I don't think >>> it adds any value to be able to do this and it seems to discourage >>> re-use of verbs across different types of data, which is bad. I >>> don't > >>> think we really need 47 definitions of the 'reboot' operation, for > example. >> I need some help to understand the issue. >> > > Me too. > > The YANG language allows the definition of any RPC method (conforming > to the YANG data types). If you choose to write 47 versions of the > reboot operation, or if you choose to define inline data instead of > reusable groupings, this is not a problem with the language, but > rather the people using the language. > > >> /js >> > > Andy > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 29 08:26: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 7D83828C155; Tue, 29 Jul 2008 08:26: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 324E328C155 for ; Tue, 29 Jul 2008 08:26:46 -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 Qd9yCn3bAbyk for ; Tue, 29 Jul 2008 08:26:45 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EA16E28C33F for ; Tue, 29 Jul 2008 08:26:44 -0700 (PDT) Received: from [172.16.13.166] (unknown [130.129.65.89]) by office2.cesnet.cz (Postfix) with ESMTP id 5A585D800C5 for ; Tue, 29 Jul 2008 17:26:56 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> <488F2A38.10303@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> <488F304C.2000204@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> Organization: CESNET Date: Tue, 29 Jul 2008 17:26:55 +0200 Message-Id: <1217345216.6741.53.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org U2hhcm9uIENoaXNob2xtIHDDrcWhZSB2IMOadCAyOS4gMDcuIDIwMDggdiAxMTowNCAtMDQwMDoK PiBIaQo+IAo+IE9rLiBJIGRpZCBjYWxsIHRoZSB0aHJlYWQgJ2NsYXJpZmljYXRpb24nIGFuZCBp dCBzb3VuZHMgbGlrZSB5b3UgaGF2ZQo+IGp1c3QgY29uZmlybWVkIHlhbmcgZG9lcyBub3Qgc3Vw cG9ydCBpbmxpbmUgb3BlcmF0aW9ucz8KPiAKPiBMZXQgbWUgZ2l2ZSBhbiBleGFtcGxlIG9mIHdo YXQgSSBkb24ndCB3YW50IHRvIHNlZSB0byBlbnN1cmUgSSdtIGNsZWFyCj4gKHNvcnJ5LCBYU0Qg aXMgbXkgcHNldWRvIGNvZGUpCj4gCj4gPGVsZW1lbnQgbmFtZT0iYmdwIj4KPiAgIDxlbGVtZW50 IG5hbWU9InJvdXRlcyIvPiAgCj4gICA8ZWxlbWVudCBuYW1lPSJzdGF0aXN0aWNzIiAvPgo+ICAg PGVsZW1lbnQgbmFtZT0iY29uZmlndXJhdGlvbj4gLz4gCj4gICA8ZWxlbWVudCBuYW1lPSJycGNP cGVyYXRpb25fRm9vIi8+Cj4gPC9lbGVtZW50PgoKTm8sIHRoaXMgd2lsbCBuZXZlciBoYXBwZW4u IFRoZSBycGMgYW5kIG5vdGlmaWNhdGlvbiBzdGF0ZW1lbnRzIGluIFlBTkcKZGVzY3JpYmUgc29t ZXRoaW5nIGVsc2UgdGhhbiB0aGUgY29uZmlndXJhdGlvbiBzY2hlbWEgdHJlZS4gTXkgRFNETAp0 cmFuc2xhdG9yIGN1cnJlbnRseSBpZ25vcmVzIHRoZW0gYnV0IEkgd2FudCB0byBkaXNjdXNzIGJl dHRlciBvcHRpb25zLgoKTGFkYQoKPiAKPiBTaGFyb24KPiAKPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQo+IEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAbmV0Y29uZmNlbnRyYWwu Y29tXSAKPiBTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDA4IDEwOjU5IEFNCj4gVG86IENoaXNo b2xtLCBTaGFyb24gKENBUjpaWjAwKQo+IENjOiBuZXRtb2RAaWV0Zi5vcmcKPiBTdWJqZWN0OiBS ZTogW25ldG1vZF0gQ2xhcmlmaWNhdGlvbjogTm8gaW5saW5lIG9wZXJhdGlvbiBkZWZpbml0aW9u Pwo+IAo+IFNoYXJvbiBDaGlzaG9sbSB3cm90ZToKPiA+IEhpCj4gPiAKPiA+IEkgYW0gdGFsa2lu ZyBhYm91dCBzZWN0aW9uIDQuMi45IEkgZ3Vlc3MuCj4gPiAKPiA+IE15IHBvaW50IGlzLCBJIGRv bid0IHRoaW5rIHdlIGRvbid0IG5lZWQgdGhlIGFiaWxpdHkgdG8gZGVmaW5lIAo+ID4gb3BlcmF0 aW9ucyBpbmxpbmUsIHNvIHdoeSBkbyB3ZSBoYXZlIGl0PyBXaGF0IHVzZSBjYXNlIGRvZXMgdGhp cyAKPiA+IHN1cHBvcnQ/Cj4gPiAKPiAKPiBJIGRvbid0IHVuZGVyc3RhbmQuCj4gRXZlcnkgZG9j dW1lbnQgdGhlIE5FVENPTkYgV0cgY3JlYXRlcyBzZWVtIHRvIGRlZmluZSBuZXcgUlBDIG1ldGhv ZHMgaW4KPiBpdC4gIFZlbmRvciBSUEMgbWV0aG9kcyBhcmUgYWxzbyBpbXBvcnRhbnQuCj4gCj4g SSdsbCByZXBlYXQgbXkgYXJndW1lbnQgZm9yIGtlZXBpbmcgcnBjIChhbmQgbm90aWZpY2F0aW9u KSBpbiB0aGUgWUFORwo+IGxhbmd1YWdlOgo+IAo+ICAgIC0gVGhlIERNIHJlYWRlciBtdXN0IHVu ZGVyc3RhbmQgdGhlIGVudGlyZSBBUEkgZW1ib2RpZWQKPiAgICAgIGluIHRoZSBORVRDT05GIGRh dGEgbW9kZWwgbW9kdWxlLiAgVGhpcyBhcHBsaWVzIHRvCj4gICAgICBjb25maWcgZGF0YSwgbW9u aXRvcmluZyBkYXRhLCBldmVudCBub3RpZmljYXRpb25zLAo+ICAgICAgYW5kIHByb3RvY29sIHZl cmJzIGRlZmluZWQgdG8gbWFuYWdlIHNvbWUgbmV0d29yayBzZXJ2aWNlLgo+IAo+ICAgIC0gVGhl cmUgbmVlZHMgdG8gYmUgMSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIHRvIGRlZmluZQo+ICAgICAg dGhlIGVudGlyZSBkYXRhIG1vZGVsIEFQSSBmb3IgY29uc2lzdGVuY3kgYW5kIGNvaGVyZW5jZS4K PiAKPiAgICAtIElmIFhTRCBvciBSTkcgaXMgdXNlci1mcmllbmRseSBlbm91Z2ggdG8gZGVmaW5l IHBhcnQgb2YgdGhpcwo+ICAgICAgQVBJLCB0aGVuIHRoZXkgYXJlIGdvb2QgZW5vdWdoIGZvciBh bGwgb2YgaXQsIGFuZCB3ZSBkb24ndCBuZWVkCj4gICAgICBZQU5HIGF0IGFsbC4gIChHaXZlbiB0 aGF0IGxhY2sgb2YgZXhwZXJ0aXNlIGRlbW9uc3RyYXRlZCBpbiBlaXRoZXIKPiAgICAgIGxhbmd1 YWdlIGJ5IHRoZSBJRVRGLCBJIHRoaW5rIHdlIG5lZWQgWUFORy4pCj4gCj4gCj4gCj4gPiBJdCB3 b3VsZCBhbHNvIGJlIG5pY2UgYW5kIGh1bWFuLWZyaWVuZGx5IGlmIGl0IHdhcyBlYXNpZXIgdG8g ZG8gdGhlIAo+ID4gcmlnaHQgdGhpbmcgKGNvbW1vbiBvcGVyYXRpb25zKSB0aGVuIHRoZSB3cm9u ZyB0aGluZyAoNDcgZGlmZmVyZW50IAo+ID4gcmVib290IG9wZXJhdGlvbnMpLgo+ID4gCj4gPiBJ IHByb3Bvc2Ugd2UganVzdCBhbGxvdyBmb3IgZ2xvYmFsIG9wZXJhdGlvbnMuCj4gCj4gV2UgZG8g bm90IGhhdmUgbG9jYWwgb3BlcmF0aW9ucyBpbiBZQU5HLgo+IFRoZSBycGMtc3RtdCBjYW4gb25s eSBhcHBlYXIgYXQgdGhlIHRvcC1sZXZlbCAoYm9keS1zdG10cykuCj4gCj4gPiAKPiA+IFNoYXJv bgo+IAo+IEFuZHkKPiAKPiAKPiA+IAo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+ IEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAbmV0Y29uZmNlbnRyYWwuY29tXQo+ID4g U2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAwOCAxMDozMyBBTQo+ID4gVG86IENoaXNob2xtLCBT aGFyb24gKENBUjpaWjAwKTsgbmV0bW9kQGlldGYub3JnCj4gPiBTdWJqZWN0OiBSZTogW25ldG1v ZF0gQ2xhcmlmaWNhdGlvbjogTm8gaW5saW5lIG9wZXJhdGlvbiBkZWZpbml0aW9uPwo+ID4gCj4g PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6Cj4gPj4gT24gVHVlLCBKdWwgMjksIDIwMDgg YXQgMTA6MDY6MDRBTSAtMDQwMCwgU2hhcm9uIENoaXNob2xtIHdyb3RlOgo+ID4+ICAKPiA+Pj4g SW4gTkVUTU9ELCB3ZSBkb24ndCByZWFsbHkgaGF2ZSBhIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQg ZGVmaW5pdGlvbiAKPiA+Pj4gb2YgTkVUQ09ORiBwcm90b2NvbCBvcGVyYXRpb25zIGlubGluZSBp biBhIGRhdGEgbW9kZWwgZG8gd2U/IEl0IAo+ID4+PiB3YXNuJ3QgY2xlYXIgaW4gcmVhZGluZyB0 aGUgc2VjdGlvbiBpbiB0aGUgeWFuZyBkb2N1bWVudCB3aGV0aGVyIAo+ID4+PiB0aGF0Cj4gPiAK PiA+Pj4gd2FzIGVuY291cmFnZWQgb3IgZm9yYmlkZGVuLgo+ID4+IENhbiB5b3UgY2xhcmlmeSBw bGVhc2Ugd2hhdCB0aGUgaXNzdWUgaXM/IFdoaWNoIHNlY3Rpb24gb2YgdGhlIFlBTkcgCj4gPj4g ZG9jdW1lbnQgc2hvdWxkIEkgbG9vayBhdD8KPiA+Pgo+ID4+PiBKdXN0IGluIGNhc2UgaXQgaXMg cGVybWl0dGVkLCBJIGp1c3Qgd2FudCB0byBzYXkgdGhhdCBJIGRvbid0IHRoaW5rIAo+ID4+PiBp dCBhZGRzIGFueSB2YWx1ZSB0byBiZSBhYmxlIHRvIGRvIHRoaXMgYW5kIGl0IHNlZW1zIHRvIGRp c2NvdXJhZ2UgCj4gPj4+IHJlLXVzZSBvZiB2ZXJicyBhY3Jvc3MgZGlmZmVyZW50IHR5cGVzIG9m IGRhdGEsIHdoaWNoIGlzIGJhZC4gSSAKPiA+Pj4gZG9uJ3QKPiA+IAo+ID4+PiB0aGluayB3ZSBy ZWFsbHkgbmVlZCA0NyBkZWZpbml0aW9ucyBvZiB0aGUgJ3JlYm9vdCcgb3BlcmF0aW9uLCBmb3IK PiA+IGV4YW1wbGUuCj4gPj4gSSBuZWVkIHNvbWUgaGVscCB0byB1bmRlcnN0YW5kIHRoZSBpc3N1 ZS4KPiA+Pgo+ID4gCj4gPiBNZSB0b28uCj4gPiAKPiA+IFRoZSBZQU5HIGxhbmd1YWdlIGFsbG93 cyB0aGUgZGVmaW5pdGlvbiBvZiBhbnkgUlBDIG1ldGhvZCAoY29uZm9ybWluZyAKPiA+IHRvIHRo ZSBZQU5HIGRhdGEgdHlwZXMpLiAgSWYgeW91IGNob29zZSB0byB3cml0ZSA0NyB2ZXJzaW9ucyBv ZiB0aGUgCj4gPiByZWJvb3Qgb3BlcmF0aW9uLCBvciBpZiB5b3UgY2hvb3NlIHRvIGRlZmluZSBp bmxpbmUgZGF0YSBpbnN0ZWFkIG9mIAo+ID4gcmV1c2FibGUgZ3JvdXBpbmdzLCB0aGlzIGlzIG5v dCBhIHByb2JsZW0gd2l0aCB0aGUgbGFuZ3VhZ2UsIGJ1dCAKPiA+IHJhdGhlciB0aGUgcGVvcGxl IHVzaW5nIHRoZSBsYW5ndWFnZS4KPiA+IAo+ID4gCj4gPj4gL2pzCj4gPj4KPiA+IAo+ID4gQW5k eQo+ID4gCj4gPiAKPiA+IAo+ID4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYu b3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0gCkxh ZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5l dG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZAo= From netmod-bounces@ietf.org Tue Jul 29 08:27:53 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AA93A67B7; Tue, 29 Jul 2008 08:27:53 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B6F28C155 for ; Tue, 29 Jul 2008 08:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 yJZy7n+Cpxkq for ; Tue, 29 Jul 2008 08:27:52 -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 D5A2E3A67B7 for ; Tue, 29 Jul 2008 08:27:51 -0700 (PDT) Received: (qmail 24005 invoked from network); 29 Jul 2008 15:28:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2008 15:28:02 -0000 X-YMail-OSG: SWwvCqMVM1m77oaM78sneaV3rVztMa5hHHwc_r8WgrCvjmFmmyLFo6pNQ_Rja0Pp5WhN4wIOvUeC5GCNQbEC3.6cc0W0D_6rfHldwhaeEg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488F3701.8050400@netconfcentral.com> Date: Tue, 29 Jul 2008 08:28:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> <488F2A38.10303@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> <488F304C.2000204@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> Cc: netmod@ietf.org Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Ok. I did call the thread 'clarification' and it sounds like you have > just confirmed yang does not support inline operations? > > Let me give an example of what I don't want to see to ensure I'm clear > (sorry, XSD is my pseudo code) > > > > > Thanks for pointing out how XSD and RNG model the XML language itself, and nothing more. Except for your naming conventions, I would have no idea which XSD construct was the RPC method in the bunch. > > body-stmts = *((extension-stmt / typedef-stmt / grouping-stmt / data-def-stmt / rpc-stmt / notification-stmt) stmtsep) data-def-stmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / choice-stmt / anyxml-stmt / uses-stmt / augment-stmt See how rpc-stmt is not in data-def-stmt? It can never appear inside another definition. > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, July 29, 2008 10:59 AM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netmod@ietf.org > Subject: Re: [netmod] Clarification: No inline operation definition? > > Sharon Chisholm wrote: >> Hi >> >> I am talking about section 4.2.9 I guess. >> >> My point is, I don't think we don't need the ability to define >> operations inline, so why do we have it? What use case does this >> support? >> > > I don't understand. > Every document the NETCONF WG creates seem to define new RPC methods in > it. Vendor RPC methods are also important. > > I'll repeat my argument for keeping rpc (and notification) in the YANG > language: > > - The DM reader must understand the entire API embodied > in the NETCONF data model module. This applies to > config data, monitoring data, event notifications, > and protocol verbs defined to manage some network service. > > - There needs to be 1 data modeling language to define > the entire data model API for consistency and coherence. > > - If XSD or RNG is user-friendly enough to define part of this > API, then they are good enough for all of it, and we don't need > YANG at all. (Given that lack of expertise demonstrated in either > language by the IETF, I think we need YANG.) > > > >> It would also be nice and human-friendly if it was easier to do the >> right thing (common operations) then the wrong thing (47 different >> reboot operations). >> >> I propose we just allow for global operations. > > We do not have local operations in YANG. > The rpc-stmt can only appear at the top-level (body-stmts). > >> Sharon > > Andy > > >> -----Original Message----- >> From: Andy Bierman [mailto:andy@netconfcentral.com] >> Sent: Tuesday, July 29, 2008 10:33 AM >> To: Chisholm, Sharon (CAR:ZZ00); netmod@ietf.org >> Subject: Re: [netmod] Clarification: No inline operation definition? >> >> Juergen Schoenwaelder wrote: >>> On Tue, Jul 29, 2008 at 10:06:04AM -0400, Sharon Chisholm wrote: >>> >>>> In NETMOD, we don't really have a requirement to support definition >>>> of NETCONF protocol operations inline in a data model do we? It >>>> wasn't clear in reading the section in the yang document whether >>>> that >>>> was encouraged or forbidden. >>> Can you clarify please what the issue is? Which section of the YANG >>> document should I look at? >>> >>>> Just in case it is permitted, I just want to say that I don't think >>>> it adds any value to be able to do this and it seems to discourage >>>> re-use of verbs across different types of data, which is bad. I >>>> don't >>>> think we really need 47 definitions of the 'reboot' operation, for >> example. >>> I need some help to understand the issue. >>> >> Me too. >> >> The YANG language allows the definition of any RPC method (conforming >> to the YANG data types). If you choose to write 47 versions of the >> reboot operation, or if you choose to define inline data instead of >> reusable groupings, this is not a problem with the language, but >> rather the people using the language. >> >> >>> /js >>> >> Andy >> >> >> >> > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Jul 29 08:32:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0236B3A688A; Tue, 29 Jul 2008 08:32:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2303A6B7F for ; Tue, 29 Jul 2008 08:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 cdLNxUreGGLk for ; Tue, 29 Jul 2008 08:32:45 -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 64F6A3A6A4F for ; Tue, 29 Jul 2008 08:32:45 -0700 (PDT) Received: (qmail 25277 invoked from network); 29 Jul 2008 15:32:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 29 Jul 2008 15:32:55 -0000 X-YMail-OSG: a0bf2nEVM1maZGqMtP6Lq7qWHf7rIakeXaXic1v.SVoMkgae4SY25_3mHcmibWSdotqXiz3lX9oSL504B.ndRlRONSN182Bqd0w8yBuKVg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488F3824.7090302@netconfcentral.com> Date: Tue, 29 Jul 2008 08:32:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ladislav Lhotka References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> <488F2A38.10303@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> <488F304C.2000204@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> <1217345216.6741.53.camel@missotis> In-Reply-To: <1217345216.6741.53.camel@missotis> Cc: NETMOD Working Group Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IFNoYXJvbiBDaGlzaG9sbSBww63FoWUgdiDDmnQgMjku IDA3LiAyMDA4IHYgMTE6MDQgLTA0MDA6Cj4+IEhpCj4+Cj4+IE9rLiBJIGRpZCBjYWxsIHRoZSB0 aHJlYWQgJ2NsYXJpZmljYXRpb24nIGFuZCBpdCBzb3VuZHMgbGlrZSB5b3UgaGF2ZQo+PiBqdXN0 IGNvbmZpcm1lZCB5YW5nIGRvZXMgbm90IHN1cHBvcnQgaW5saW5lIG9wZXJhdGlvbnM/Cj4+Cj4+ IExldCBtZSBnaXZlIGFuIGV4YW1wbGUgb2Ygd2hhdCBJIGRvbid0IHdhbnQgdG8gc2VlIHRvIGVu c3VyZSBJJ20gY2xlYXIKPj4gKHNvcnJ5LCBYU0QgaXMgbXkgcHNldWRvIGNvZGUpCj4+Cj4+IDxl bGVtZW50IG5hbWU9ImJncCI+Cj4+ICAgPGVsZW1lbnQgbmFtZT0icm91dGVzIi8+ICAKPj4gICA8 ZWxlbWVudCBuYW1lPSJzdGF0aXN0aWNzIiAvPgo+PiAgIDxlbGVtZW50IG5hbWU9ImNvbmZpZ3Vy YXRpb24+IC8+IAo+PiAgIDxlbGVtZW50IG5hbWU9InJwY09wZXJhdGlvbl9Gb28iLz4KPj4gPC9l bGVtZW50Pgo+IAo+IE5vLCB0aGlzIHdpbGwgbmV2ZXIgaGFwcGVuLiBUaGUgcnBjIGFuZCBub3Rp ZmljYXRpb24gc3RhdGVtZW50cyBpbiBZQU5HCj4gZGVzY3JpYmUgc29tZXRoaW5nIGVsc2UgdGhh biB0aGUgY29uZmlndXJhdGlvbiBzY2hlbWEgdHJlZS4gTXkgRFNETAo+IHRyYW5zbGF0b3IgY3Vy cmVudGx5IGlnbm9yZXMgdGhlbSBidXQgSSB3YW50IHRvIGRpc2N1c3MgYmV0dGVyIG9wdGlvbnMu Cj4gCgpMb29rIGF0IHRoZSBYU0Qgb3V0cHV0IGZyb20geWFuZ2R1bXAgb3IgcHlhbmcuClRoZSBO RVRDT05GIFhTRCBoYXMgaG9va3MgdG8gJ2Nvbm5lY3QnIGFueSBSUEMgY29udGVudAp0byBpdHMg bG9jYXRpb24gaW4gdGhlIHByb3RvY29sIFBEVXMuICBEaXR0byBmb3IgdGhlCk5vdGlmaWNhdGlv bnMgWFNELgoKCj4gTGFkYQo+IAo+PiBTaGFyb24KPj4KCkFuZHkKCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1v ZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Tue Jul 29 10:46: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 D0C323A690F; Tue, 29 Jul 2008 10:46: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 32B853A6ADF for ; Tue, 29 Jul 2008 10:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6uELeBrE9nf for ; Tue, 29 Jul 2008 10:46:39 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 428F33A6AAE for ; Tue, 29 Jul 2008 10:46:39 -0700 (PDT) X-Trace: 116815609/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.120.174 X-SBRS: None X-RemoteIP: 62.188.120.174 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAP7zjkg+vHiu/2dsb2JhbACDWzWHWqV1Aw X-IronPort-AV: E=Sophos;i="4.31,273,1215385200"; d="scan'208";a="116815609" X-IP-Direction: IN Received: from 1cust174.tnt29.lnd3.gbr.da.uu.net (HELO allison) ([62.188.120.174]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Jul 2008 18:46:48 +0100 Message-ID: <004901c8f199$d8a8f1a0$0601a8c0@allison> From: "tom.petch" To: "Phil Shafer" References: <200807231749.m6NHn7Eu040974@idle.juniper.net> Date: Tue, 29 Jul 2008 18:24:45 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] netmod session agendas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org ----- Original Message ----- From: "Phil Shafer" To: "tom.petch" Cc: "David Harrington" ; Sent: Wednesday, July 23, 2008 7:49 PM Subject: Re: [netmod] netmod session agendas > > >And I would see the discussions on the list on mandatory, default, config, > >presence etc as a symptom not that the YANG spec is unclear, but that the > >concepts need spelling out, and I wonder if that is done, then those concepts > >may turn out to be > >unclear > > The spec definitely needs work, which is my concern about burning > face time on training, versus finding problems in the spec and > correcting them. > I think that what is needed, what would speed the process of developing yang, is another I-D which focuses on the concepts. The current one is great on the detail but hard to use to understand the approach that yang is taking - on names, reuse, groupings/containers, OO v .... the topics I see generating discussion on the mailing lists. What I have seen more than once is a discussion starting out as a point of detail in the spec and ending up some time later as a discussion of a point of principle, of approach. Were the principles spelt out more clearly to start with, then I think that you would shorten those discussions, get more involvement in the discussion, with prospects of reaching a rough consensus faster. Andy has made the point that yang is a bottom up language, that you have to start at the lowest leaf and apply all the various refinements etc in order to arrive at the actual data definitions. This may - may not - be the best way to model network data but I do not see it as the best way to communicate what the language is; that should be top down. And of course, I am thinking of a document whose target audience is experienced data modellers, who now want to get up to speed in yang. Tom Petch > > Thanks, > Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 30 06:03: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 78CE93A6953; Wed, 30 Jul 2008 06:03: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 6C3AE3A689D for ; Wed, 30 Jul 2008 06:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqbDUshYoRjI for ; Wed, 30 Jul 2008 06:03:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 365DA3A6953 for ; Wed, 30 Jul 2008 06:03:06 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8CA4320C9F; Wed, 30 Jul 2008 15:02:32 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-d1-48906666d501 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D0B0520971; Wed, 30 Jul 2008 15:02:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 15:02:26 +0200 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 15:02:26 +0200 Message-ID: <48904BD9.7010303@ericsson.com> Date: Wed, 30 Jul 2008 13:09:13 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B415A80FCD@zcarhxm2.corp.nortel.com> <20080729142410.GA11405@elstar.local> <488F2A38.10303@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A810D4@zcarhxm2.corp.nortel.com> <488F304C.2000204@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415A81150@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 30 Jul 2008 13:02:26.0454 (UTC) FILETIME=[83E46360:01C8F244] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Clarification: No inline operation definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, Netmod charter does not specify all the details of YANG (naturally). It does not mention inline operations either. Whether we need some new feature is up to the working group (as always) as long as we don't change something that is explicitly stated in the charter. Balazs Sharon Chisholm wrote: > Hi > > Ok. I did call the thread 'clarification' and it sounds like you have > just confirmed yang does not support inline operations? > > Let me give an example of what I don't want to see to ensure I'm clear > (sorry, XSD is my pseudo code) > > > > > > > > Sharon > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, July 29, 2008 10:59 AM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netmod@ietf.org > Subject: Re: [netmod] Clarification: No inline operation definition? > > Sharon Chisholm wrote: >> Hi >> >> I am talking about section 4.2.9 I guess. >> >> My point is, I don't think we don't need the ability to define >> operations inline, so why do we have it? What use case does this >> support? >> > > I don't understand. > Every document the NETCONF WG creates seem to define new RPC methods in > it. Vendor RPC methods are also important. > > I'll repeat my argument for keeping rpc (and notification) in the YANG > language: > > - The DM reader must understand the entire API embodied > in the NETCONF data model module. This applies to > config data, monitoring data, event notifications, > and protocol verbs defined to manage some network service. > > - There needs to be 1 data modeling language to define > the entire data model API for consistency and coherence. > > - If XSD or RNG is user-friendly enough to define part of this > API, then they are good enough for all of it, and we don't need > YANG at all. (Given that lack of expertise demonstrated in either > language by the IETF, I think we need YANG.) > > > >> It would also be nice and human-friendly if it was easier to do the >> right thing (common operations) then the wrong thing (47 different >> reboot operations). >> >> I propose we just allow for global operations. > > We do not have local operations in YANG. > The rpc-stmt can only appear at the top-level (body-stmts). > >> Sharon > > Andy > > >> -----Original Message----- >> From: Andy Bierman [mailto:andy@netconfcentral.com] >> Sent: Tuesday, July 29, 2008 10:33 AM >> To: Chisholm, Sharon (CAR:ZZ00); netmod@ietf.org >> Subject: Re: [netmod] Clarification: No inline operation definition? >> >> Juergen Schoenwaelder wrote: >>> On Tue, Jul 29, 2008 at 10:06:04AM -0400, Sharon Chisholm wrote: >>> >>>> In NETMOD, we don't really have a requirement to support definition >>>> of NETCONF protocol operations inline in a data model do we? It >>>> wasn't clear in reading the section in the yang document whether >>>> that >>>> was encouraged or forbidden. >>> Can you clarify please what the issue is? Which section of the YANG >>> document should I look at? >>> >>>> Just in case it is permitted, I just want to say that I don't think >>>> it adds any value to be able to do this and it seems to discourage >>>> re-use of verbs across different types of data, which is bad. I >>>> don't >>>> think we really need 47 definitions of the 'reboot' operation, for >> example. >>> I need some help to understand the issue. >>> >> Me too. >> >> The YANG language allows the definition of any RPC method (conforming >> to the YANG data types). If you choose to write 47 versions of the >> reboot operation, or if you choose to define inline data instead of >> reusable groupings, this is not a problem with the language, but >> rather the people using the language. >> >> >>> /js >>> >> Andy >> >> >> >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 30 12:11: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 BC36E28C3DC; Wed, 30 Jul 2008 12:11: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 5E18528C3E8 for ; Wed, 30 Jul 2008 12:11:07 -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 YsQaEKK2wOOT for ; Wed, 30 Jul 2008 12:11:06 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 120EC28C3E2 for ; Wed, 30 Jul 2008 12:11:05 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA19634 for ; Wed, 30 Jul 2008 15:11:19 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA13028 for ; Wed, 30 Jul 2008 15:11:19 -0400 (EDT) Message-Id: <200807301911.PAA13028@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 30 Jul 2008 15:11:18 -0400 From: David Reid Subject: [netmod] slides for ietf 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org If any of you who are making presentations at the meeting tomorrow or Friday could make your slides available in advance, that would be very helpful to those of us listening on the audio feed from home. Thanks, -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 30 14:50:08 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B233A6818; Wed, 30 Jul 2008 14:50:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538183A68B6 for ; Wed, 30 Jul 2008 14: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=[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 5OtdSSMZD7wx for ; Wed, 30 Jul 2008 14:50:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B79D63A6818 for ; Wed, 30 Jul 2008 14:50:05 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3B95C2182B; Wed, 30 Jul 2008 23:50:20 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-8a-4890e21c3e03 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2082520440; Wed, 30 Jul 2008 23:50:20 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 23:50:19 +0200 Received: from [153.88.45.63] ([153.88.45.63]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 23:50:19 +0200 From: David Partain Organization: Ericsson AB To: David Reid Date: Wed, 30 Jul 2008 23:50:54 +0200 User-Agent: KMail/1.9.9 References: <200807301911.PAA13028@adminfs.snmp.com> In-Reply-To: <200807301911.PAA13028@adminfs.snmp.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807302350.54585.david.partain@ericsson.com> X-OriginalArrivalTime: 30 Jul 2008 21:50:19.0509 (UTC) FILETIME=[42810A50:01C8F28E] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] slides for ietf 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 On Wednesday 30 July 2008 21.11.18 David Reid wrote: > If any of you who are making presentations at the meeting tomorrow or > Friday could make your slides available in advance, that would be very > helpful to those of us listening on the audio feed from home. Greetings, All materials will be available at https://datatracker.ietf.org/meeting/72/materials.html In fact, most of them already are :-) Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Jul 30 15: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 936793A6893; Wed, 30 Jul 2008 15: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 5757A3A6804 for ; Wed, 30 Jul 2008 15:26:21 -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 Q8j1vRDTJq8P for ; Wed, 30 Jul 2008 15:26:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8478D3A6782 for ; Wed, 30 Jul 2008 15:26:20 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5BA0D20322 for ; Thu, 31 Jul 2008 00:26:35 +0200 (CEST) X-AuditID: c1b4fb3e-aa991bb000004ec0-13-4890ea9b5a75 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FE5C2014A for ; Thu, 31 Jul 2008 00:26:35 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 00:26:35 +0200 Received: from [153.88.45.63] ([153.88.45.63]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 00:26:34 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 31 Jul 2008 00:27:10 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807310027.10085.david.partain@ericsson.com> X-OriginalArrivalTime: 30 Jul 2008 22:26:34.0953 (UTC) FILETIME=[532B7390:01C8F293] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] jabber scribe and two notetakers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, We'll need three volunteers tomorrow. I'd rather not waste time at the beginning trying to coerce people into doing the job, so please respond directly to me if you'll volunteer for one of these jobs. Thanks. David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 02:43: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 9CC983A6AB8; Thu, 31 Jul 2008 02:43: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 D2C513A6A60 for ; Thu, 31 Jul 2008 02:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.343 X-Spam-Level: X-Spam-Status: No, score=-5.343 tagged_above=-999 required=5 tests=[AWL=0.906, 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 0YRlG3CxdNbW for ; Thu, 31 Jul 2008 02:43:37 -0700 (PDT) Received: from smtp.su.se (smtp1.su.se [130.237.162.112]) by core3.amsl.com (Postfix) with ESMTP id 1C8703A6B2E for ; Thu, 31 Jul 2008 02:43:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id C16E274225 for ; Thu, 31 Jul 2008 11:43:51 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22496-01-63 for ; Thu, 31 Jul 2008 11:43:51 +0200 (CEST) Received: from [130.129.23.177] (unknown [130.129.23.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 9D36574221 for ; Thu, 31 Jul 2008 11:43:51 +0200 (CEST) To: netmod@ietf.org Content-Disposition: inline From: Leif Johansson Date: Thu, 31 Jul 2008 11:43:45 +0200 MIME-Version: 1.0 Message-Id: <200807311143.45922.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Subject: [netmod] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Here are the questions I asked at the mic just now in Dublin: - Is a yang 'list' a set - i.e can a value only occur once? - Is a yang 'leaf-list' then also a set? The implication of that would be that it cannot be used to model an array of primitive types - i.e the array of two occurences of the integer 1 would be illegal. Cheers Leif _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 03:05: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 BD2123A682C; Thu, 31 Jul 2008 03:05: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 DEE7C3A683B for ; Thu, 31 Jul 2008 03:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmZthj-LcYww for ; Thu, 31 Jul 2008 03:05:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id ED2863A682C for ; Thu, 31 Jul 2008 03:05:03 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D99C120E58; Thu, 31 Jul 2008 12:05:19 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-d9-48918e5f90eb Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C047620E44; Thu, 31 Jul 2008 12:05:19 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 12:05:13 +0200 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 12:05:13 +0200 Message-ID: <48916ECD.2040908@ericsson.com> Date: Thu, 31 Jul 2008 09:50:37 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Leif Johansson References: <200807311143.45922.leifj@it.su.se> In-Reply-To: <200807311143.45922.leifj@it.su.se> X-OriginalArrivalTime: 31 Jul 2008 10:05:13.0614 (UTC) FILETIME=[ECA382E0:01C8F2F4] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, All leafs in the leaf-list must be unique. All keys (key-combinations) in a list must be unique. I think the best solution today is to have a list list mySet { key index; leaf index { type int32; } leaf setMember { type xxx;} } setMembers do not have to be unique. 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 Leif Johansson wrote: > > Here are the questions I asked at the mic just now in Dublin: > > - Is a yang 'list' a set - i.e can a value only occur once? > > - Is a yang 'leaf-list' then also a set? The implication of that would be that > it cannot be used to model an array of primitive types - i.e the array of > two occurences of the integer 1 would be illegal. > > Cheers Leif > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 03:12:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365B528C106; Thu, 31 Jul 2008 03:12:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728DC28C11D for ; Thu, 31 Jul 2008 03:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.494 X-Spam-Level: X-Spam-Status: No, score=-5.494 tagged_above=-999 required=5 tests=[AWL=0.755, 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 MFVW369yaixL for ; Thu, 31 Jul 2008 03:12:54 -0700 (PDT) Received: from smtp.su.se (smtp1.su.se [130.237.162.112]) by core3.amsl.com (Postfix) with ESMTP id 2B09028C116 for ; Thu, 31 Jul 2008 03:12:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 1835474248; Thu, 31 Jul 2008 12:13:02 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28487-01-3; Thu, 31 Jul 2008 12:13:01 +0200 (CEST) Received: from [130.129.23.177] (unknown [130.129.23.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id A7BE77408A; Thu, 31 Jul 2008 12:13:01 +0200 (CEST) From: Leif Johansson To: balazs.lengyel@ericsson.com Date: Thu, 31 Jul 2008 12:12:55 +0200 User-Agent: KMail/1.9.9 References: <200807311143.45922.leifj@it.su.se> <48916ECD.2040908@ericsson.com> In-Reply-To: <48916ECD.2040908@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807311212.55146.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: netmod@ietf.org Subject: Re: [netmod] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thursday 31 July 2008 09:50:37 Balazs Lengyel wrote: > Hello, > All leafs in the leaf-list must be unique. All keys (key-combinations) in a > list must be unique. I think the best solution today is to have a list > > list mySet { > key index; > leaf index { type int32; } > leaf setMember { type xxx;} > } > > setMembers do not have to be unique. > > Balazs Hi I'm not sure I parse your answer. It sounds to me that you're saying that "Yes, a yang list is a set." and that "Here is now to model an member of an array of type xxx in yang". Is that correct? Cheers Leif _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 05:44:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6483A63D2; Thu, 31 Jul 2008 05:44: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 2F1043A6809 for ; Thu, 31 Jul 2008 05:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9d1yTNVOxuo for ; Thu, 31 Jul 2008 05:44:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 402B53A63D2 for ; Thu, 31 Jul 2008 05:44:53 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 437AE209CA for ; Thu, 31 Jul 2008 14:44:43 +0200 (CEST) X-AuditID: c1b4fb3c-ab095bb00000193b-36-4891b3bb8304 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 379DA20924 for ; Thu, 31 Jul 2008 14:44:43 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 14:44:42 +0200 Received: from [153.88.45.126] ([153.88.45.126]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 14:44:42 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 31 Jul 2008 14:45:20 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807311445.20904.david.partain@ericsson.com> X-OriginalArrivalTime: 31 Jul 2008 12:44:42.0632 (UTC) FILETIME=[3437C880:01C8F30B] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call: YIN mapping to remain in YANG spec X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, Based upon previous mailing list discussion (see the thread beginning with http://www.ietf.org/mail-archive/web/netmod/current/msg00147.html) and the discussion in the WG meeting this morning, the chairs believe that the consensus of the WG is to keep YIN in the YANG specification rather than putting it into a separate document. Please speak up now if you object. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 05:45: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 838393A6C1E; Thu, 31 Jul 2008 05:45: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 79CBF3A6C38 for ; Thu, 31 Jul 2008 05:45: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=[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 tDuGh9sDmOuy for ; Thu, 31 Jul 2008 05:45:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7E6F73A63D2 for ; Thu, 31 Jul 2008 05:45:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A896820C23 for ; Thu, 31 Jul 2008 14:45:22 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-92-4891b3e20fd6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 952EC2098C for ; Thu, 31 Jul 2008 14:45:22 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 14:45:22 +0200 Received: from [153.88.45.126] ([153.88.45.126]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 14:45:22 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 31 Jul 2008 14:46:00 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807311446.00401.david.partain@ericsson.com> X-OriginalArrivalTime: 31 Jul 2008 12:45:22.0178 (UTC) FILETIME=[4BCA0620:01C8F30B] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call: XML on-the-wire mapping to remain in YANG spec X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, Based upon the discussion in the WG meeting this morning, the chairs believe that the consensus of the WG is to keep XML on-the-wire mapping in the YANG specification rather than putting it into a separate document. Please speak up now if you object. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 05:51: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 F3F273A6C1F; Thu, 31 Jul 2008 05:51: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 F153C3A6AC8 for ; Thu, 31 Jul 2008 05:51:01 -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 zQVaKQx9Oa+J for ; Thu, 31 Jul 2008 05:50:57 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5C7F03A6C64 for ; Thu, 31 Jul 2008 05:50:28 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F2E8D2113B for ; Thu, 31 Jul 2008 14:50:43 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-99-4891b523462a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6E13C20411 for ; Thu, 31 Jul 2008 14:50:43 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 14:50:43 +0200 Received: from [153.88.45.126] ([153.88.45.126]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 14:50:43 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 31 Jul 2008 14:51:21 +0200 User-Agent: KMail/1.9.9 References: <200807311445.20904.david.partain@ericsson.com> In-Reply-To: <200807311445.20904.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807311451.21165.david.partain@ericsson.com> X-OriginalArrivalTime: 31 Jul 2008 12:50:43.0205 (UTC) FILETIME=[0B22DB50:01C8F30C] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call: Accept draft-schoenw-netmod-yang-types-01.txt as WG document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, Based upon the discussion in the WG meeting this morning, the chairs believe that the consensus of the WG to accept draft-schoenw-netmod-yang-types-01.txt as the starting point for our deliverable: 6. A standard type library for use by YANG (proposed standard) Please speak up now if you object. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 08:56: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 C01173A6C81; Thu, 31 Jul 2008 08:56: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 6059E3A6C81 for ; Thu, 31 Jul 2008 08:56:39 -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 V84C2Ldr7Ajw for ; Thu, 31 Jul 2008 08:56:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 84F5A3A69DE for ; Thu, 31 Jul 2008 08:56:36 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 547CF206F6; Thu, 31 Jul 2008 17:54:10 +0200 (CEST) X-AuditID: c1b4fb3e-ac995bb000004ec0-c6-4891e022fb9d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3EE3F20104; Thu, 31 Jul 2008 17:54:10 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:54:10 +0200 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:54:09 +0200 Message-ID: <4891C03E.2090703@ericsson.com> Date: Thu, 31 Jul 2008 15:38:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Leif Johansson References: <200807311143.45922.leifj@it.su.se> <48916ECD.2040908@ericsson.com> <200807311212.55146.leifj@it.su.se> In-Reply-To: <200807311212.55146.leifj@it.su.se> X-OriginalArrivalTime: 31 Jul 2008 15:54:09.0861 (UTC) FILETIME=[AB9D4750:01C8F325] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, Yes you are right. Balazs Leif Johansson wrote: > On Thursday 31 July 2008 09:50:37 Balazs Lengyel wrote: >> Hello, >> All leafs in the leaf-list must be unique. All keys (key-combinations) in a >> list must be unique. I think the best solution today is to have a list >> >> list mySet { >> key index; >> leaf index { type int32; } >> leaf setMember { type xxx;} >> } >> >> setMembers do not have to be unique. >> >> Balazs > > > Hi > > I'm not sure I parse your answer. It sounds to me that you're saying that > > "Yes, a yang list is a set." > > and that > > "Here is now to model an member of an array of type xxx in yang". Is that > correct? > > Cheers Leif _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 08:59: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 F0BB03A69DE; Thu, 31 Jul 2008 08:59:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A211328C1A0 for ; Thu, 31 Jul 2008 08:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 R6vdRtpKJpTk for ; Thu, 31 Jul 2008 08:59:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2F0FD3A69DE for ; Thu, 31 Jul 2008 08:59:15 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5A3FC20557 for ; Thu, 31 Jul 2008 17:58:32 +0200 (CEST) X-AuditID: c1b4fb3c-ab896bb00000193b-14-4891e1283fea Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3C2C820023 for ; Thu, 31 Jul 2008 17:58:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:58:31 +0200 Received: from [153.88.53.140] ([153.88.53.140]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:58:31 +0200 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 31 Jul 2008 17:59:10 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Message-Id: <200807311759.10111.david.partain@ericsson.com> X-OriginalArrivalTime: 31 Jul 2008 15:58:31.0780 (UTC) FILETIME=[47BAF240:01C8F326] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Interim on Oct 8 - 10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, After discussion at the WG meeting this morning, the following seems clear... There was a large-ish number of people (12-ish in the meeting room plus at least 3 not in attendance that I know of) who would attend an interim on 8-10 October. Several people stated that it is important to have an interim SINCE we are going to meet our aggressive deadlines. Given that, the chairs are going to try to make this happen. Please set this time aside in your calendars now. The chairs are trying to find a good location near a major airline hub on the east coast of the U.S. We will nail that down ASAP so people can book tickets. That being said, there was also a fair bit of discussion about trying to find good ways to make use of "virtual" meetings. I will start that thread separately. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 09:00:09 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D6E3A6CDD; Thu, 31 Jul 2008 09:00:08 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209043A6CD3 for ; Thu, 31 Jul 2008 09:00: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=[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 3IswxFdJQvVf for ; Thu, 31 Jul 2008 09:00:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2AAF83A6CD6 for ; Thu, 31 Jul 2008 08:59:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 31E092060F for ; Thu, 31 Jul 2008 17:59:31 +0200 (CEST) X-AuditID: c1b4fb3c-ae89cbb00000193b-65-4891e163c0d1 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 20F502058A for ; Thu, 31 Jul 2008 17:59:31 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:59:31 +0200 Received: from [153.88.53.140] ([153.88.53.140]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:59:30 +0200 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 31 Jul 2008 18:00:08 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Message-Id: <200807311800.09011.david.partain@ericsson.com> X-OriginalArrivalTime: 31 Jul 2008 15:59:30.0801 (UTC) FILETIME=[6AE8D610:01C8F326] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Virtual meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, David Kessens and Sharon Chisholm (amongst others) brought up the use of "virtual meetings" as a complement to face-to-face meetings (like the interim). I also think this is something we could do much better in the IETF _and_ it will help SINCE we are going to meet our aggressive deadlines. Firstly, with respect to the interim, I think it might be difficult to participate remotely for _three_ days. Once we find a host, we can see if it would make sense to provide a phone bridge, jabber, etc. for those who absolutely cannot be there. However, face-to-face in combination with virtual is hard and may not be very productive. However, I completely agree that we should find ways to complement our other work using virtual meetings. Some ideas: 1. If there's a "hot topic" going round and round on the list (nah...), we set up a conference call where interested parties can discuss and reach agreement to be taken back to the WG mailing list. Clearly, such meetings would have to be announced on the list, open to all, and documented. I recognize the timezone issues, which might make it very difficult for everyone to join such calls. This is mitigated by ensuring that the meeting is documented and issue resolution is then verified on the mailing list. 2. Perhaps we can come up with a set of tools (whiteboard app, etc) that could be used in such virtual meetings. 3. We have a jabber room available to us whenever we want to use it (xmpp:netmod@jabber.ietf.org). Perhaps we could have a well-known jabber session once per week or at some other interval? Other ideas? David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 09:24: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 724673A6BF2; Thu, 31 Jul 2008 09:24: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 A4ADA3A6A49 for ; Thu, 31 Jul 2008 09:24:05 -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 JwCGiPu4IMMC for ; Thu, 31 Jul 2008 09:24:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BCBFF3A6BAE for ; Thu, 31 Jul 2008 09:24:04 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B1CDC2071C for ; Thu, 31 Jul 2008 17:57:24 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-dd-4891e0e418e7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 929D62058A for ; Thu, 31 Jul 2008 17:57:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:57:24 +0200 Received: from [153.88.53.140] ([153.88.53.140]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 17:57:23 +0200 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 31 Jul 2008 17:58:01 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Message-Id: <200807311758.02068.david.partain@ericsson.com> X-OriginalArrivalTime: 31 Jul 2008 15:57:24.0140 (UTC) FILETIME=[1F69E6C0:01C8F326] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] The architecture and DSDL deliverables X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, The following is the plan for the two deliverables for which we do not have IDs at the moment. With respect to: 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) Phil Shafer and Ladislav Lhotka have kindly volunteered to publish an individual draft ASAP to cover (essentially) what was covered by Phil's presentation this morning. Others who wish to contribute should contact the authors. Once published, the WG will then be asked to consider if we wish to accept the document as a starting point for this WG deliverable. Other individual contributions will, of course, be considered as well, but it would seem most constructive at this point to help Phil and Ladislav rather than creating an alternative. With respect to: 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). Sharon Chisholm and Ladislav Lhotka have kindly volunteered to publish an individual draft during September to cover this deliverable. That means they are merging their two documents to create a new document focusing entirely on mapping YANG to DSDL. Others who wish to contribute should contact the authors. Once published, the WG will then be asked to consider if we wish to accept the document as a starting point for this WG deliverable. Other individual contributions will, of course, be considered as well, but it would seem most constructive at this point to help Sharon and Ladislav rather than creating an alternative. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 09:28:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC81E3A68DD; Thu, 31 Jul 2008 09:28: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 700433A68DD for ; Thu, 31 Jul 2008 09:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.178, 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 PRKMF+fHvXTk for ; Thu, 31 Jul 2008 09:28:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 701203A6A49 for ; Thu, 31 Jul 2008 09:28:04 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17589C0045; Thu, 31 Jul 2008 18:17:37 +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 5yEri7p0q00G; Thu, 31 Jul 2008 18:17: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 B9E09C003F; Thu, 31 Jul 2008 18:17:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 885F567F6DE; Thu, 31 Jul 2008 18:17:29 +0200 (CEST) Date: Thu, 31 Jul 2008 18:17:29 +0200 From: Juergen Schoenwaelder To: David Partain Message-ID: <20080731161729.GB24304@elstar.local> Mail-Followup-To: David Partain , netmod@ietf.org References: <200807311800.09011.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200807311800.09011.david.partain@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Virtual meetings 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, Jul 31, 2008 at 06:00:08PM +0200, David Partain wrote: > 3. We have a jabber room available to us whenever we want to use it > (xmpp:netmod@jabber.ietf.org). Perhaps we could have a well-known jabber > session once per week or at some other interval? I would be fine trying to make more use of jabber. Something like jabber allows us to cut'n'paste little YANG snippets, the stuff we used to write a lot on the whiteboard during in the past. The other benefit of jabber is that it slows down native speakers and creates automatically a record of the exchange. /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 Jul 31 09:49: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 E1CAA28C0F1; Thu, 31 Jul 2008 09:49: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 E834E28C0F1 for ; Thu, 31 Jul 2008 09:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.602 X-Spam-Level: X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=0.647, 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 vs5ZBu1cgH5K for ; Thu, 31 Jul 2008 09:49:48 -0700 (PDT) Received: from smtp.su.se (smtp1.su.se [130.237.162.112]) by core3.amsl.com (Postfix) with ESMTP id 153BC3A6CE7 for ; Thu, 31 Jul 2008 09:49:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id D3314742AE; Thu, 31 Jul 2008 18:50:04 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32323-01-9; Thu, 31 Jul 2008 18:50:04 +0200 (CEST) Received: from [130.129.23.177] (unknown [130.129.23.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 6A0CC7406E; Thu, 31 Jul 2008 18:50:04 +0200 (CEST) From: Leif Johansson To: balazs.lengyel@ericsson.com Date: Thu, 31 Jul 2008 18:49:56 +0200 User-Agent: KMail/1.9.9 References: <200807311143.45922.leifj@it.su.se> <200807311212.55146.leifj@it.su.se> <4891C03E.2090703@ericsson.com> In-Reply-To: <4891C03E.2090703@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807311849.56167.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: netmod@ietf.org Subject: Re: [netmod] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Thursday 31 July 2008 15:38:06 Balazs Lengyel wrote: > Hello, > Yes you are right. > Balazs > > Leif Johansson wrote: > > On Thursday 31 July 2008 09:50:37 Balazs Lengyel wrote: > >> Hello, > >> All leafs in the leaf-list must be unique. All keys (key-combinations) > >> in a list must be unique. I think the best solution today is to have a > >> list > >> > >> list mySet { > >> key index; > >> leaf index { type int32; } > >> leaf setMember { type xxx;} > >> } > >> > >> setMembers do not have to be unique. > >> > >> Balazs > > > > Hi > > > > I'm not sure I parse your answer. It sounds to me that you're saying that > > > > "Yes, a yang list is a set." > > > > and that > > > > "Here is now to model an member of an array of type xxx in yang". Is that > > correct? > > > > Cheers Leif In that case could someone explain a use-case for leaf-list? Cheers Leif _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 10:18:40 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75B028C24F; Thu, 31 Jul 2008 10:18:40 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE5628C296 for ; Thu, 31 Jul 2008 10:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HDwXeCIB7Pr for ; Thu, 31 Jul 2008 10:18:38 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F0AC928C288 for ; Thu, 31 Jul 2008 10:18:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6VHIn8B019033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 19:18:49 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6VHInev010162; Thu, 31 Jul 2008 19:18:49 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 19:18:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 19:18:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [netmod] Virtual meetings Thread-Index: AcjzMX4+MjVgauMlT8a3i9YghouOaQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David Partain" , X-OriginalArrivalTime: 31 Jul 2008 17:18:49.0423 (UTC) FILETIME=[7F44EDF0:01C8F331] Subject: Re: [netmod] Virtual meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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, I think virtual meetings make great sense, but we should find a way to ... - keep the meeting foused on solving specific issues - find the right time-zone for the registered participants - handle the virtual meetings like an IETF meeting, i.e. provide minutes af= ter and slides before the meeting. Even if it is possible to provide an aud= io streaming or an mp3 file after the meeting. Mehmet = -----Urspr=FCngliche Nachricht----- Von: ext David Partain Gesendet: 31.07.2008 17:00:33 An: ext David Partain;netmod@ietf.org Betreff: [netmod] Virtual meetings Greetings, David Kessens and Sharon Chisholm (amongst others) brought up the use = of "virtual meetings" as a complement to face-to-face meetings (like the = interim). I also think this is something we could do much better in the IE= TF = _and_ it will help SINCE we are going to meet our aggressive deadlines. Firstly, with respect to the interim, I think it might be difficult to = participate remotely for _three_ days. Once we find a host, we can see if = it = would make sense to provide a phone bridge, jabber, etc. for those who = absolutely cannot be there. However, face-to-face in combination with = virtual is hard and may not be very productive. However, I completely agree that we should find ways to complement our othe= r = work using virtual meetings. Some ideas: 1. If there's a "hot topic" going round and round on the list (nah...), we = set = up a conference call where interested parties can discuss and reach agreeme= nt = to be taken back to the WG mailing list. Clearly, such meetings would have = to be announced on the list, open to all, and documented. I recognize the = timezone issues, which might make it very difficult for everyone to join su= ch = calls. This is mitigated by ensuring that the meeting is documented and = issue resolution is then verified on the mailing list. 2. Perhaps we can come up with a set of tools (whiteboard app, etc) that co= uld = be used in such virtual meetings. 3. We have a jabber room available to us whenever we want to use it = (xmpp:netmod@jabber.ietf.org). Perhaps we could have a well-known jabber = session once per week or at some other interval? Other ideas? David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 10:47: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 A5C3D3A6CE5; Thu, 31 Jul 2008 10:47: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 276C53A6D15 for ; Thu, 31 Jul 2008 10:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crsC+UbQxGRU for ; Thu, 31 Jul 2008 10:47:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id ED1923A6CE5 for ; Thu, 31 Jul 2008 10:47:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6VHmDRm003903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 19:48:13 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6VHmD0g017679; Thu, 31 Jul 2008 19:48:13 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 19:48:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 19:48:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: Re: [netmod] Virtual meetings Thread-Index: AcjzNZowLWUfTREmQ36GgLXiSiFYsQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David Partain" , X-OriginalArrivalTime: 31 Jul 2008 17:48:13.0242 (UTC) FILETIME=[9A9659A0:01C8F335] Subject: Re: [netmod] Virtual meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 Another point where I can help is to arrange a conference switch with local= access numbers. cheers, Mehmet = -----Urspr=FCngliche Nachricht----- Von: ext Ersue, Mehmet (NSN - DE/Muenich) Gesendet: 31.07.2008 18:19:15 An: ext Ersue, Mehmet (NSN - DE/Muenich);ext David Partain;netmod@ietf.org Betreff: Re: [netmod] Virtual meetings Hi, I think virtual meetings make great sense, but we should find a way to ... - keep the meeting foused on solving specific issues - find the right time-zone for the registered participants - handle the virtual meetings like an IETF meeting, i.e. provide minutes af= ter and slides before the meeting. Even if it is possible to provide an aud= io streaming or an mp3 file after the meeting. Mehmet = -----Urspr=FCngliche Nachricht----- Von: ext David Partain Gesendet: 31.07.2008 17:00:33 An: ext David Partain;netmod@ietf.org Betreff: [netmod] Virtual meetings Greetings, David Kessens and Sharon Chisholm (amongst others) brought up the use = of "virtual meetings" as a complement to face-to-face meetings (like the = interim). I also think this is something we could do much better in the IE= TF = _and_ it will help SINCE we are going to meet our aggressive deadlines. Firstly, with respect to the interim, I think it might be difficult to = participate remotely for _three_ days. Once we find a host, we can see if = it = would make sense to provide a phone bridge, jabber, etc. for those who = absolutely cannot be there. However, face-to-face in combination with = virtual is hard and may not be very productive. However, I completely agree that we should find ways to complement our othe= r = work using virtual meetings. Some ideas: 1. If there's a "hot topic" going round and round on the list (nah...), we = set = up a conference call where interested parties can discuss and reach agreeme= nt = to be taken back to the WG mailing list. Clearly, such meetings would have = to be announced on the list, open to all, and documented. I recognize the = timezone issues, which might make it very difficult for everyone to join su= ch = calls. This is mitigated by ensuring that the meeting is documented and = issue resolution is then verified on the mailing list. 2. Perhaps we can come up with a set of tools (whiteboard app, etc) that co= uld = be used in such virtual meetings. 3. We have a jabber room available to us whenever we want to use it = (xmpp:netmod@jabber.ietf.org). Perhaps we could have a well-known jabber = session once per week or at some other interval? Other ideas? David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 13:05:19 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632993A6838; Thu, 31 Jul 2008 13:05:19 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2E13A6838 for ; Thu, 31 Jul 2008 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 jImtSNv51q9B for ; Thu, 31 Jul 2008 13:05:17 -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 467953A6889 for ; Thu, 31 Jul 2008 13:05:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SSEMnmRU14RWlIPazpB0TX+ZglLuLxB6vWNAwYwo80CGqilWXPCtPwcadD2tMN0F; 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.153] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KOeOy-0001qP-7h for netmod@ietf.org; Thu, 31 Jul 2008 16:05:32 -0400 Message-ID: <006f01c8f348$de3884e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200807311143.45922.leifj@it.su.se> <48916ECD.2040908@ericsson.com><200807311212.55146.leifj@it.su.se> <4891C03E.2090703@ericsson.com> Date: Thu, 31 Jul 2008 13:06:06 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3af44eaeb2a8fcd4f998526726396a739350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.153 Subject: Re: [netmod] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - It sounds like it's a question of the distinction between a "bag" and a mathematical "set". The former allows duplicates, and requires additional information to uniquely identify an element. The latter (by definition) does not allow duplicates, so providing an element's value is sufficient to uniquely identify that element. Randy ----- Original Message ----- > From: "Balazs Lengyel" > To: "Leif Johansson" > Cc: > Sent: Thursday, July 31, 2008 6:38 AM > Subject: Re: [netmod] is list set or not? > > Hello, > Yes you are right. > Balazs > > Leif Johansson wrote: > > On Thursday 31 July 2008 09:50:37 Balazs Lengyel wrote: > >> Hello, > >> All leafs in the leaf-list must be unique. All keys (key-combinations) in a > >> list must be unique. I think the best solution today is to have a list > >> > >> list mySet { > >> key index; > >> leaf index { type int32; } > >> leaf setMember { type xxx;} > >> } > >> > >> setMembers do not have to be unique. > >> > >> Balazs > > > > > > Hi > > > > I'm not sure I parse your answer. It sounds to me that you're saying that > > > > "Yes, a yang list is a set." > > > > and that > > > > "Here is now to model an member of an array of type xxx in yang". Is that > > correct? > > > > Cheers Leif > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 13:28: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 4CDD33A6889; Thu, 31 Jul 2008 13:28: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 1AA2F3A6889 for ; Thu, 31 Jul 2008 13:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGZEK6KD0wTi for ; Thu, 31 Jul 2008 13:28:08 -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 6385B3A6816 for ; Thu, 31 Jul 2008 13:28:08 -0700 (PDT) Received: (qmail 21684 invoked from network); 31 Jul 2008 20:21:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 31 Jul 2008 20:21:45 -0000 X-YMail-OSG: aSdKrdwVM1m6cGODrnp94KvlIq9m3MKPMBEOgy3zwqVPlra13ZLnylTCejNa0x9_G2mtm9XptCE7IeM0YvhyzuyeqqRaEi7C5zIU3cLBdQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48921ED7.1050604@netconfcentral.com> Date: Thu, 31 Jul 2008 13:21:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Randy Presuhn References: <200807311143.45922.leifj@it.su.se> <48916ECD.2040908@ericsson.com><200807311212.55146.leifj@it.su.se> <4891C03E.2090703@ericsson.com> <006f01c8f348$de3884e0$6801a8c0@oemcomputer> In-Reply-To: <006f01c8f348$de3884e0$6801a8c0@oemcomputer> Cc: netmod@ietf.org Subject: Re: [netmod] is list set or not? X-BeenThere: netmod@ietf.org 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 - > > It sounds like it's a question of the distinction between a "bag" > and a mathematical "set". The former allows duplicates, and > requires additional information to uniquely identify an element. > The latter (by definition) does not allow duplicates, so providing > an element's value is sufficient to uniquely identify that element. > I use a proprietary extension called 'no-duplicates' for this purpose. IMO, the leaf-list would benefit from the following sub-clause: ignore-duplicates true/false; [default: false] It should not be an error to have duplicates, just as it is not an error for the unique-stmt or must-stmt; > Randy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 13:43: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 BE90E3A68FB; Thu, 31 Jul 2008 13:43: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 ECE5E3A6993 for ; Thu, 31 Jul 2008 13:43:16 -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 L69SQUkAJ1E9 for ; Thu, 31 Jul 2008 13:43:16 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2113C28C29E for ; Thu, 31 Jul 2008 13:43:16 -0700 (PDT) Received: from [172.16.13.166] (unknown [130.129.65.14]) by office2.cesnet.cz (Postfix) with ESMTP id DA6C6D800BD for ; Thu, 31 Jul 2008 22:42:50 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4891EB52.1010201@netconfcentral.com> References: <200807291149.27200.david.partain@ericsson.com> <200807311818.07768.david.partain@ericsson.com> <4891EB52.1010201@netconfcentral.com> Organization: CESNET Date: Thu, 31 Jul 2008 21:42:50 +0100 Message-Id: <1217536970.6286.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] A whacked out idea in conjunction with the Interim? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 QW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAzMS4gMDcuIDIwMDggdiAwOTo0MSAtMDcwMDoKPiBP SyAtLSB0aGVuIGNhbiBJIGhpamFjayB0aGUgdGhyZWFkIGZvciBhIHJlbGF0ZWQgdG9waWM/Cj4g Cj4gVGhlICd1c2UgY2FzZSAyJyBzbGlkZSBhdCB0aGUgbWVldGluZyBzZWVtZWQgdG8gc2hvdyBh Cj4gTkVUQ09ORiBhZ2VudCB1c2luZyBEU0RMIHZhbGlkYXRpb24gdG9vbHMuICBJbiBwcmV2aW91 cwo+IGRpc2N1c3Npb25zLCBEU0RMIHdhcyBwb3NpdGlvbmVkIGFzIGFuIG9mZmxpbmUgdmFsaWRh dGlvbiB0b29sCj4gZm9yIG1hbmFnZXJzLgoKVGhpcyBpZGVhIGFib3V0IG1hbmFnZXJzIGlzIG5l dyB0byBtZS4KCj4gCj4gSSBjYW5ub3QgaW1hZ2luZSBhIHVzYWdlIHNjZW5hcmlvIHdoZXJlIHRo ZSBhcHBsaWNhdGlvbgo+IGNhbiBnZXQgYnkgd2l0aCBhIHllcy9ubyBhbnN3ZXIgb24gTkVUQ09O RiBQRFUgdmFsaWRhdGlvbi4KPiBFdmVuIHdoZW4gZGl2aWRlZCBpbnRvIHN0YWdlcywgYSB5ZXMv bm8gYW5zd2VyIGlzIG5vdAo+IGdvb2QgZW5vdWdoLiAgQWdlbnRzIG5lZWQgdG8gZ2VuZXJhdGUg PHJwYy1lcnJvcj4gZWxlbWVudHMuCj4gVmFsaWRhdGlvbiB0b29scyBuZWVkIHRvIGdlbmVyYXRl IGRldGFpbGVkIGVycm9yIGFuZCB3YXJuaW5nIG1lc3NhZ2VzLgo+IE1hbmFnZXIgdG9vbHMgbmVl ZCB0byBoZWxwIHRoZSBvcGVyYXRvciBmaWd1cmUgb3V0IHdoeQo+IHRoZSBQRFUgZGlkIG5vdCB3 b3JrLgoKSWYgeW91IGhhdmUgYSBnb29kIGxpYnJhcnkgZm9yIGEgbGFuZ3VhZ2UgdGhhdCBzdXBw b3J0cyBleGNlcHRpb25zLCBsaWtlClB5dGhvbiwgeW91IGNhbiBkbyBhbGwgdGhpcyAtIGFuZCBJ IGFjdHVhbGx5IHBsYW4gdG8gaW1wbGVtZW50IGl0IGluCnRoaXMgd2F5IGZvciBvdXIgZGV2aWNl cy4gSXQgd2lsbCBwcm9iYWJseSBub3QgYmUgdGhlIG9ubHkgb3IgdWx0aW1hdGUKdmFsaWRhdGlv biBzdGVwIGJ1dCBqdXN0IGJlaW5nIHN1cmUgdGhhdCB0aGUgc3RydWN0dXJlIGFuZCBkYXRhdHlw ZXMgYXJlCnZhbGlkIG1ha2VzIHRoaW5ncyBtdWNoIGVhc2llci4KCj4gCj4gSU1PLCB3ZSBhcmUg Z2V0dGluZyB3YXkgdG9vIGRlZXAgaW50byBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzCj4gaW4gTkVU TU9ELiAgWWVzIHRoZXJlIGFyZSBYU0xUIHRvb2xzIGFuZCBtYXliZSBldmVuIGEgZmV3CgpJIGN1 cnJlbnRseSBkb24ndCBzZWUgYW55IGltcGxlbWVudGF0aW9uIGRldGFpbHMgYXJvdW5kIHRoZSBZ QU5HLT5EU0RMCm1hcHBpbmcuIFdlIGp1c3QgcHJvdmlkZSBhIG1ldGhvZCBmb3IgbWFraW5nIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBhCllBTkcgbW9kdWxlIGFjY2Vzc2libGUgdG8gbW9yZSBn ZW5lcmljIGFuZCBzdGFuZGFyZGl6ZWQgdG9vbHMuIEkKYWN0dWFsbHkgZG9uJ3Qga25vdyBhbGwg dGhlIGFwcGxpY2F0aW9ucyB0aGF0IG1heSBmaW5kIGl0IHVzZWZ1bCAtIEkKaG9wZSB0aGVyZSB3 aWxsIGJlIGFueSwgYW5kIHRoZXkgbWF5IHdlbGwgYmUgb3V0c2lkZSB0aGUgdHJhZGl0aW9uYWwK U05NUC9NSUIvU01JIHdvcmtmbG93LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVU ClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Thu Jul 31 16:31:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2413A69F7; Thu, 31 Jul 2008 16:31:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F413A6A2D for ; Thu, 31 Jul 2008 16:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQa2MNdIElIb for ; Thu, 31 Jul 2008 16:31:56 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 605183A69F7 for ; Thu, 31 Jul 2008 16:31:56 -0700 (PDT) Received: from localhost (unknown [130.129.65.2]) by mail.tail-f.com (Postfix) with ESMTPSA id 53DCD76C252; Fri, 1 Aug 2008 01:31:43 +0200 (CEST) Date: Thu, 31 Jul 2008 17:56:11 +0100 (IST) Message-Id: <20080731.175611.100070878.mbj@tail-f.com> To: leifj@it.su.se From: Martin Bjorklund In-Reply-To: <200807311849.56167.leifj@it.su.se> References: <200807311212.55146.leifj@it.su.se> <4891C03E.2090703@ericsson.com> <200807311849.56167.leifj@it.su.se> 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] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Leif Johansson wrote: > On Thursday 31 July 2008 15:38:06 Balazs Lengyel wrote: > > Hello, > > Yes you are right. > > Balazs > > > > Leif Johansson wrote: > > > On Thursday 31 July 2008 09:50:37 Balazs Lengyel wrote: > > >> Hello, > > >> All leafs in the leaf-list must be unique. All keys (key-combinations) > > >> in a list must be unique. I think the best solution today is to have a > > >> list > > >> > > >> list mySet { > > >> key index; > > >> leaf index { type int32; } > > >> leaf setMember { type xxx;} > > >> } > > >> > > >> setMembers do not have to be unique. > > >> > > >> Balazs > > > > > > Hi > > > > > > I'm not sure I parse your answer. It sounds to me that you're saying that > > > > > > "Yes, a yang list is a set." > > > > > > and that > > > > > > "Here is now to model an member of an array of type xxx in yang". Is that > > > correct? > > > > > > Cheers Leif > > > In that case could someone explain a use-case for leaf-list? Whenever you need to configure not one single value, but many values. For example, here's one from the YANG draft: leaf-list domain-search { type string; description "List of domain names to search"; } And here are two from the ipfix data model: leaf-list ipAddress { description "List of eligible local IP addresses to be used by the SCTP endpoint. If omitted, all locally assigned IP addresses are used by the SCTP endpoint."; type inet:ip-address; } leaf-list exportingProcess { description "Export of received records without any modifications. Records are processed by all Exporting Processes in the list."; type keyref { path "/ipfix/exportingProcess/name"; } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 16:37: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 F3B3F3A6B2F; Thu, 31 Jul 2008 16:37: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 3176928C2B9 for ; Thu, 31 Jul 2008 16:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU68h4hQQQD8 for ; Thu, 31 Jul 2008 16:37:13 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CAB573A6A2D for ; Thu, 31 Jul 2008 16:37:08 -0700 (PDT) Received: from localhost (unknown [130.129.65.2]) by mail.tail-f.com (Postfix) with ESMTPSA id CBB6C76C4DA; Fri, 1 Aug 2008 01:37:26 +0200 (CEST) Date: Fri, 01 Aug 2008 00:37:22 +0100 (IST) Message-Id: <20080801.003722.197866494.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48921ED7.1050604@netconfcentral.com> References: <4891C03E.2090703@ericsson.com> <006f01c8f348$de3884e0$6801a8c0@oemcomputer> <48921ED7.1050604@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] is list set or not? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > Randy Presuhn wrote: > > Hi - > > It sounds like it's a question of the distinction between a "bag" > > and a mathematical "set". The former allows duplicates, and > > requires additional information to uniquely identify an element. > > The latter (by definition) does not allow duplicates, so providing > > an element's value is sufficient to uniquely identify that element. > > > > I use a proprietary extension called 'no-duplicates' for this purpose. Do you allow this for ordered-by system leaf-lists? Can you give a use case for these kinds of lists? If the leaf-list is 1 2 3 3 1 2 how do you delete the second "1"? If this is useful for leaf-list, do you also support it on normal lists? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 17:49: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 53D2F28C310; Thu, 31 Jul 2008 17:49: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 4AD8028C353 for ; Thu, 31 Jul 2008 17:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQyQn7dnPKnp for ; Thu, 31 Jul 2008 17:49:39 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id BEF1028C310 for ; Thu, 31 Jul 2008 17:49:37 -0700 (PDT) Received: (qmail 66337 invoked from network); 1 Aug 2008 00:49:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 1 Aug 2008 00:49:53 -0000 X-YMail-OSG: jtA7Q7QVM1muCyriP8_RnEcsAkQWWeobHVSeo_nro7Fzj5bNXPiwuG0XSWGDBdT5hXuv3REgdpzedQiRpiOGEMnwZyBez54kMthPvOcK2w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48925DAE.1050108@netconfcentral.com> Date: Thu, 31 Jul 2008 17:49:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <4891C03E.2090703@ericsson.com> <006f01c8f348$de3884e0$6801a8c0@oemcomputer> <48921ED7.1050604@netconfcentral.com> <20080801.003722.197866494.mbj@tail-f.com> In-Reply-To: <20080801.003722.197866494.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] is list set or not? X-BeenThere: netmod@ietf.org 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: >> Randy Presuhn wrote: >>> Hi - >>> It sounds like it's a question of the distinction between a "bag" >>> and a mathematical "set". The former allows duplicates, and >>> requires additional information to uniquely identify an element. >>> The latter (by definition) does not allow duplicates, so providing >>> an element's value is sufficient to uniquely identify that element. >>> >> I use a proprietary extension called 'no-duplicates' for this purpose. > > Do you allow this for ordered-by system leaf-lists? > have not implemented it yet > Can you give a use case for these kinds of lists? > not really -- 'bits' covers it pretty well > If the leaf-list is > > 1 2 3 3 1 2 > > how do you delete the second "1"? > YANG ordered-by user > If this is useful for leaf-list, do you also support it on normal > lists? no -- lists already have a key-stmt > > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 22:37:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748933A6836; Thu, 31 Jul 2008 22:37:47 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DF63A69D4 for ; Thu, 31 Jul 2008 22:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPr+4cQWcou2 for ; Thu, 31 Jul 2008 22:37:45 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E42803A6836 for ; Thu, 31 Jul 2008 22:37:44 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m715c0M12613 for ; Fri, 1 Aug 2008 05:38:00 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 01:37:27 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415B6F4CD@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSDL: Embedded or Standalone Schematron Thread-Index: AcjzmK7HQ8I/8EsFTVGN2lxqePeNVw== From: "Sharon Chisholm" To: Subject: [netmod] DSDL: Embedded or Standalone Schematron X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi I'm going to be posting a series of issues that have come up in offline DSDL discussions to the list. This is intended to start the discussion to bring about the resolution. Schematron supports both standalone and embedded definitions. By embedded I mean the definitions can be inline in the Relax NG specification. There are a couple of choices of how our DSDL can end up looking. I personally like the approach where common rules, like key and keyref handling are done in separate schema so they can be defined once and uses many times. I think schema specific rules should be embedded in the Relax NG since I think this is the most readable and makes it a bit simpler for someone using and validating the schema in some existing tools. I know Lada has some views on this based on his translation work, but I'll let him post them himself so I don't mangle them. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 22:58: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 C7B083A6A0F; Thu, 31 Jul 2008 22:58: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 E1FF63A6A0F for ; Thu, 31 Jul 2008 22:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjAJB0ykz5hG for ; Thu, 31 Jul 2008 22:58:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F1A713A69CC for ; Thu, 31 Jul 2008 22:58:33 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m715woM14546 for ; Fri, 1 Aug 2008 05:58:50 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 01:58:47 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415B6F4D3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSDL: Mapping Protocol Operations Thread-Index: Acjzm6nvsVJKdfPeR3W7ksg6U5c5wg== From: "Sharon Chisholm" To: Subject: [netmod] DSDL: Mapping Protocol Operations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 are a couple options for mapping protocol operations defined in yang into DSDL. Options: 1) generate separate schemas for validating data store content and individual RPC/notification messages. 2) one schema with multiple parts as above under a dummy root element in a special "NETMOD-tree" namespace (e.g., ). Lada's slides for today's session give an example conceptual tree. I suspect we should decouple the question of how to get a DSDL definition of the protocol operations with parity with what we have in XSD today from the question of validating content. Wouldn't the latter be more a question for when we are translating the content not the protocol operations? Note for that part, there is an interesting solution proposed in the XSD draft. I'll start a separate thread on that one. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 23:07: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 D19603A69CC; Thu, 31 Jul 2008 23:07: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 C3B983A69CC for ; Thu, 31 Jul 2008 23:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oguu2GXU3N+O for ; Thu, 31 Jul 2008 23:07:12 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id BADE63A6A2F for ; Thu, 31 Jul 2008 23:07:11 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7167R806100 for ; Fri, 1 Aug 2008 06:07:27 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 02:07:13 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415B6F4D4@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSDL: Validating both configuration store and PDUs Thread-Index: AcjznNcT3X2X2FD2QlWlO+ECKb1CkA== From: "Sharon Chisholm" To: Subject: [netmod] DSDL: Validating both configuration store and PDUs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 In the last issues I promised to create a separate thread on validating the content in an RPC operation compared to validating the configuration store. From my perspective we need to be able to do both. Some options for this: 1) Make a clear distinction between client and server side conformance. Use the tags to indicate server side conformance, which becomes the configuration store requirements. Then introduce another mechanism to define client side configuration. This indicates what must be present in an individual PDU - i.e., you can't create one of these unless you include the following fields. 2) Generate different flavours of the schema with modified tags to indicate conformance. Pretty much everything would be optional with a operation while for all keys would be mandatory. I suspect you need different schema for creation versus modification, which is where this might get a bit complicated. 3) Someone recently suggested that we define a wrapper PDU to represent the configuration store. I'm not exactly sure the details of this proposal. I think 1) is the simplest, but that option 2) probably best serves off-the-shelf tools and libraries. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Jul 31 23:13: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 A969E3A698A; Thu, 31 Jul 2008 23:13: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 671013A6A1D for ; Thu, 31 Jul 2008 23:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVtN4mFli0RS for ; Thu, 31 Jul 2008 23:13:39 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 7BD073A698A for ; Thu, 31 Jul 2008 23:13:39 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m716Dt806230 for ; Fri, 1 Aug 2008 06:13:55 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 02:13:53 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415B6F4D6@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSDL: Extensions in foreign namespaces Thread-Index: AcjzncWNTLisgqWOQ5WrWWNOey+AeA== From: "Sharon Chisholm" To: Subject: [netmod] DSDL: Extensions in foreign namespaces X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 to confess I don't fully understand this one yet. "YANG language extensions with statement keywords in foreign namespaces can be freely inserted (e.g., in the YIN form) into the RELAX NG schema but it doesn't seem to make much sense without knowing the semantics. An appropriate decision should be taken after gaining some experience with real-world YANG extensions." Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 1 00:18: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 269BA3A6CD2; Fri, 1 Aug 2008 00:18: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 8D6BD28C381 for ; Fri, 1 Aug 2008 00:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwGjcjWUll9a for ; Fri, 1 Aug 2008 00:18:26 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 948933A6D2C for ; Fri, 1 Aug 2008 00:18:26 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m717IZf00703 for ; Fri, 1 Aug 2008 07:18:35 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 03:18:32 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415B6F4DA@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSDL: Annotations versus element attributes Thread-Index: Acjzps21IH6tipjPSj2WunEJq6+e1g== From: "Sharon Chisholm" To: Subject: [netmod] DSDL: Annotations versus element attributes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi It is necessary to define a small set of NETMOD specific extensions. We currently have two different proposals for doing this: via application annotations and via attributes on elements. Some factors that will effect which way we go - do we require any structure to our extensions? Attributes will be more flat. - does it make a difference in the validation with off-the-shelf tools? - which is more readable? - what is the more DSDL-like approach? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 1 00:33: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 E33AB3A6A82; Fri, 1 Aug 2008 00:33: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 4390A3A6A82 for ; Fri, 1 Aug 2008 00:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWjjVbYkg+y2 for ; Fri, 1 Aug 2008 00:33:33 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 583F33A6AAD for ; Fri, 1 Aug 2008 00:33:33 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m717XnM25685 for ; Fri, 1 Aug 2008 07:33:50 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 03:33:47 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415B6F4E0@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSDL: keyref - annotation/attribute versus Schematron Thread-Index: AcjzqO8/A9DfEtV+T4eQBMaIskBevA== From: "Sharon Chisholm" To: Subject: [netmod] DSDL: keyref - annotation/attribute versus Schematron X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi We currently have two different approaches for keyref on the table (presumably where the value of the keyref is the same and aligns to the yang value) - Using a keyref application annotation plus Schematron - Using just Schematron I think there are two factors in this decision: 1) We need to be able to support sending the instance that a keyref points to on the wire, like the example in section 8.8.4 of the yang document. 2) There are sort of two layering approaches, which lead to slightly different conclusions 2.1) Avoid NETMOD-specifics at all costs 2.2) Define core constraints in a way that they can be validated by off-the-shelf tools, but do not force other implementations to use Schematron to do their validation. By this I mean by having a separate annotation plus the Schematron it supports both use cases. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Aug 1 01:06: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 17F353A6B09; Fri, 1 Aug 2008 01:06: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 CD41E3A6AF6 for ; Fri, 1 Aug 2008 01:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Sz+UjfbvGGt for ; Fri, 1 Aug 2008 01:06:18 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id C7E5D28C183 for ; Fri, 1 Aug 2008 01:06:17 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m71862f04985 for ; Fri, 1 Aug 2008 08:06:02 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 04:05:49 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415B6F4E1@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: minAccess/maxAccess Thread-Index: AcjzrWjqd2pEEtthQ0W4E88Jo1Njaw== From: "Sharon Chisholm" To: Subject: [netmod] minAccess/maxAccess X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi While inheriting minAccess and maxAccess is a good approach, it is important to be able to override this to support things like create-only or the ability to modify, but not create or delete. I propose then that we need a minAccess/maxAccess mechanism that optionally overrides the access provided by the config/non-config bit. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod